neděle 4. října 2020

Režimy hladin v twiGISu - nejprve ty původní

... tak tu máme zase vyjímečný stav, tak je možné se pořádně začíst ...

V rámci seriálu o nových možnostech publikace dat prostřednictvím mapových hladin v twiGISu začneme úplně od začátku, od vlastních mechanismů fungování hladin.

V twiGISu byly historicky k dispozici dva hlavní způsoby publikace vlastních mapových dat: buď byla hladina vektorová, nebo se jednalo o tzv. dlaždicové keše. Jednalo se o dva krajní a vlastně protichůdné principy. 

Jednoduché vektorové hladiny

Základní vektorové hladiny jsou založeny vždy na jedné datové entitě (databázové tabulce), např. "Potrubí vodovodu", nebo "Místnosti". Vektorová data se načítají z databáze, do webové aplikace putují ve formě GeoJSON a vykreslují (nebo renderují, tzn. proměňují z vektorů na pixely podle dané stylizace) až v prohlížeči. 

Mezi výhody patří zejména to, že aplikace v prohlížeči má k dispozici vlastní vektorová data - prvky se dají snadno a rychle vybírat a zvýrazňovat v mapě, dají se přímo editovat, je možné snadno uživatelsky měnit či přepínat stylizaci, na vektory se při editacích či měření a kreslení dají používat úchopové režimy (snapovat). Výhodou je rovněž to, že se distribuuje výkon CPU požadovaný na vykreslování na koncová zařízení.

Mezi hlavní nevýhody patří omezené možnosti stylizace, které umí prohlížeč efektivně vykreslit (typický problém "čáry s blesky" pro znázornění elektrického vedení). Vykreslování začne rovněž drhnout, když je v zobrazeném výřezu mapy těch prvků už příliš - například v přehledových mapách území, v malých měřítcích, nebo když se jedná o opravdu četná a hustá data. Čas zabere přenos vektorů na klienta i jejich vykreslení v prohlížeči.

Dlaždicové keše (rastrové)

Jedná se již o poměrně starý koncept, který vznikl zejména kvůli veřejným mapovým službám, které publikovaly poměrně malý počet hladin pro velké množství uživatelů. V takovém případě bylo velmi neefektivní vykreslovat daný mapový výřez pro každého uživatele znovu a znovu, a data byla proto předgenerována do mapových dlaždic v daném schématu (tzv. tilegrid). Zobrazení mapy v konkrétním měřítku pak znamenalo jen stažení a zobrazení potřebného množství malých obrázků, tedy akci poměrně nenáročnou, kterou zvládly tehdejší prohlížeče i první mobilní zařízení. Generování keší probíhá asynchronně na serveru, vykreslování tedy zatěžuje CPU serveru. 

Pravé peklo s dlaždicemi ale nastává při potřebě jejich skladování a potřebné údržbě keší v aktuální podobě. To nemusí být problém pro nějakou obecnou podkladovou mapu, kde není příliš změn ani velká potřeba aktuálnosti. V případě dokumentace např. inženýrské sítě je ale aktuálnost keší zobrazujících průběhy potrubí a polohy zařízení dost klíčová a aktualizace se řeší i v řádu desítek minut od provedení změny v datech. Pro účel generování keší musí být na serveru nějaký renderovací software, typicky mapový server, který mění vektory na pixely podle stylizace. Plus software, který aktualizaci keší podle nějaké strategie (o tom někdy později) dokáže zajistit.

Zmíněné výhody rastrových keší spočívají zejména v jejich bleskurychlém zobrazení, bez velkého nároku na koncové zařízení. Díky serverovému renderovacímu jádru bežícímu v asynchronním režimu (tedy někdy v noci, ne když to zrovna uživatel potřebuje) je možné typicky použít bohatou stylizaci a je možné do jedné keše složit i více hladin (keš pak nereprezentuje jednu entitu, ale celou sadu entit/hladin/tabulek, třeba Vodovod, se vší strukturou uvnitř).

I nevýhody by měly být z řečeného zřejmé: jedná se zejména o náročnost údržby keší a jejich skladování. Keše jsou rovněž k dispozici jen v předem definovaných měřítcích, přičemž náročnost na čas generování a skladovací prostor roste s každým dalším detailnějším měřítkem exponenciálně (to teď víme co znamená, že?). Uživatel se tedy nemůže přizoomovat na křižovatku či budovu do měřítka 1:20, pokud předtím server nenageneroval stovky gigabajtů dat. 

Další velké omezení je v tom, že tak jak jsou keše nadefinovány, tak jsou i zobrazeny. Pokud je jedna kešovaná hladina (kompozice) pro vodovod, tak z té kompozice nejdou uživatelsky "odepnout" přípojky, nebo nechat třeba jen hydranty. Navíc, když se hladiny začnou dělit, roste celkový problém kešování (s počtem hladin naštěstí jen lineárně), ale rovněž roste čas potřebný na zobrazení v aplikaci: při dvaceti zapnutých kešovaných hladinách se načítají a zobrazují stovky až tisíce dlaždic a to rozhodně není nic rychlého.

Nepříjemnou vizuální nevýhodou jsou rovněž "okrajové efekty" na přechodech mezi dlaždicemi. Řeší se to různě, ale vždy to je spíš bolest.

Vektory vs Keše

Po přečtení výše uvedeného je zřejmé, že ty dva uvedené principy jsou vlastně protichůdné: 

  • Vektory jsou rychlé a efektivní "dole" (ve velkých měřítcích), kde je v mapovém výřezu uchopitelné množství prvků a je třeba s nimi plynule pracovat. 
  • Rastrové dlaždicové keše jsou naopak efektivní "nahoře" (v malých měřítcích), kde je renderování určitého území časově náročné (hodně prvků najednou), ale v daných měřítcích není dlaždic tolik a kompletní přegenerování je otázkou desítek minut nebo maximálně pár hodin (a nezabírá to místo na úložišti).
Z popisu však vyplývá i to, že těch scénářů a potřeb je více a v porovnání s vlastnostmi variant zatím nelze jednoduše "vybruslit" (ale složitěji to jde - viz pokračování seriálu).

A co ty ostatní: WMS, WMTS a spol?

WMS služby a jim příbuzné (někde se nazývají "dynamické rastrové hladiny") jsou předchůdcem a současně vlastně prerekvizitou rastrových dlaždicových keší. Fungují tak, že mapová aplikace požádá server o konkrétní výřez mapy, server jej vykreslí na základě své definice (typicky stylizace, datové zdroje) a zaslaných parametrů (třeba výčet podhladin) a vrátí aplikaci obrázek mapy a ta jej zobrazí. Tento klasický scénář byl v řadě aplikací nahrazen právě rastrovými kešemi, neboť velké množství požadavků na WMS či dynamické mapové služby znamenalo velkou zátěž na aplikační i databázový server, kde se ve špičkách nedostávalo paměti a CPU. Výhodou bylo to, že služby poskytovaly vždy aktuální data, bylo možné pracovat s podhladinami, atd. Některé mapové servery (např. MapGuide OpenSource) přitom dokáží renderovat data až s obdivuhodnou rychlostí.

Hybridní model, který však považujeme spíše za škodlivý, je takový, že mapa se vykresluje po dlaždicích, ty jsou však vždy dotazovány a online renderovány na serveru. Výsledek je sice ten, že prohlížeč si může po krátkou dobu některé dlaždice pamatovat, ale mapový server je utápěn stovkami malých dotazů.

WMTS (a příbuzné jako TMS, atp) můžeme rychle zařadit do kategorie rastrových dlaždicových hladin. Zda je to "uvnitř" keš nebo jsou dlaždice renderovány online už je na způsobu řešení, jak je zmíněno výše.

Tyto zdroje jsou v twiGISu historicky podporovány, typicky se ale používají zejména na externí mapové služby, jako veřejná ortofota, katastr, atd.

Jak z toho tedy ven?

... no, to se rozepíšeme v pokračování tady na blogu. Jen si buďte jisti, že jsme na to kápli, těšte se a mějte se fajn!

Žádné komentáře:

Okomentovat