pondělí 19. října 2020

twiGIS - nový servisní modul (ukázka)

 To tu ještě nebylo! Ale ne ... doba nás prostě ponouká k poťouchlostem, jako je následující video. 

Servisní modul twiGIS je nástroj pro odbavení (zatím) jedněch z nejpalčivějších a nejdůležitějších agend při správě majetku - provádění a evidence povinných a nezbytných prohlídek, kontrol, revizí. Doplněk GIS aplikace twiGIS, který ve videu prezentujeme na případu výtahů.


pondělí 12. října 2020

Režimy hladin v twiGISu - teď ty nové

Tak a je tu pokračování. K dosavadním obvyklým režimům hladin si přidáme nějaké nové možnosti a hlavně možnosti jejich kombinace.

Vektorová kompozice

Tak jako se někdy v jedné rastrové hladině sejde několik různých entit (tříd, tabulek) - a je prezentována jako tzv. kompozice, může se podobná věc přihodit i u vektorů. Vektorová kompozice se chová jako jedna hladina, která je však uvnitř reprezentovaná několika dílčími vektorovými hladinami. Se všemi vlastnostmi jednotlivých vektorových hladin, tedy snapováním, možnostmi měnit styly na straně klienta, atd. Navíc je možné libovolně zapínat a vypínat jednotlivé vnitřní hladiny.

Hodí se zejména tam, kde chceme celou skupinu dat prezentovat uživatelům pro zjednodušení jako jednu hladinu, např. "Vodovod", "Základní mapa", "Cizí sítě", a přitom stále těžit z vektorové povahy dat, nebo v některých speciálních případech. V jednom z nedávných případů kolega použil kompozice na zobrazování zařízení v podzemních kolektorech. Hladina zobrazuje vlastní symbol zařízení, popisek, který má vlastní souřadnice a uživatelé jej umisťují na fixní místo, a vynášecí čáru mezi popiskem a symbolem. Data nese symbol, popisek a čára jsou pomocné (s popiskem lze ale hýbat), všechno dohromady se to chová jako jedna hladina.

Online rastr, Externí rastr

Jedná se vlastně o to samé, co jsme zmiňovali v minulém článku: online či dynamické rastrové hladiny, renderované na straně serveru a poskytované do aplikace jako výsledný obrázek. 

twiGIS umožňuje několik způsobů, jak tyto hladiny do klientské aplikace dostat. Prvním způsobem je režim Externí rastr, kdy je rastrový zdroj kontaktován napřímo webovou aplikací, tedy prohlížečem uživatele. Druhým je tzv. twiGIS online rastr, kdy se k poskytování dat do klienta používají serverové služby twiGISu.

Proč to odlišujeme a jaký je mezi tím rozdíl? Externí rastr je dobře použitelný např. pro veřejné neautorizované služby. Klientská aplikace stahuje např. veřejnou Ortofoto přímo z CUZK a žádným způsobem nedochází k zatěžování vlastních aplikačních serverů a zpomalování komunikace, což je u takových zdrojů je naprosto zbytečné.

Interní Online rastr se naopak používá tam, kde je vhodné přístup ke zdroji "skrýt" či autorizovat pomocí uživatelských oprávnění twiGIS. Jednoduchým případem je nakupovaná externí WMS či autorizovaná WMS našeho partnera, kdy nelze poskytnout přístupové údaje do uživatelských prohlížečů. Častějším případem jsou prostě vlastní rastrové hladiny poskytované přes vnitřní rastrový engine.

V obou případech může být rastrový zdroj jakýkoliv (WMS, WMTS, MapAgent, ...) a v obou případech může správce rozhodnout, zda budou data prezentována jako dynamicky renderované malé dlaždice (tiled) nebo tak, že se při každém pohybu mapy renderuje celý mapový výřez (singletile).

Ta pravá orgie je kombinace režimů

Jak jsme zmiňovali v minulém článku či dříve v tomto článku, různé režimy se chovají lépe či hůře v různých měřítcích či datových situacích. V twiGISu jsme umožnili kombinovat výhody různých režimů i nad jednou hladinou.

Definice hladiny v twiGISu probíhá tak, že založíte hladinu, řeknete, jak se bude jmenovat (např. Vodovod) a do hladiny přiřadíte datové entity - a to klidně víc než jednu (např. Potrubí, Hydrant, Uzávěr, Přípojka). Tím máme datový základ hladiny. 

Aby bylo možné vůbec něco zobrazovat, je třeba hladině přiřadit definici stylu, která určí, jak budou jednotlivé prvky v mapě vypadat - na základě jejich vlastností, měřítka, atd. Prostě GISová klasika. Jako poslední  věc je vhodné hladině přiřadit rastrový zdroj - tedy službu či mapový engine, který poskytuje rastrová data - viz rastrové režimy výše. (To samozřejmě není nutné, když má být hladina prezentována jen jako vektor.)

Posledním krokem je právě definice režimů, tedy způsobu, jakým je hladina v různých rozsazích měřítek prezentována uživateli. Typický příklad je takový, že v horních měřítcích se hladina chová jako rastrová keš a v dolních měřítcích jako vektor (či vektorová kompozice). Tedy dlaždice jsou tam, kde je jich relativně málo, snadno se aktualizují a skladují, ale mají velký efekt na rychlost aplikace, a vektory (či třeba nekešované online dynamické rastry) jsou tam, kde je třeba pracovat s aktuálním daty, editovat, snapovat, a správa dlaždic by už naopak byla velmi náročná.

Důležitá vlastnost je ta, že správce aplikace definuje hladinu, nastaví režimy a o zbytek se postará systém - vytvoří dlaždice kde je to třeba, automaticky uživateli přepíná režimy při používání aplikace, zajišťuje korektní chování například při výběrech (identifikaci) prvků v mapě, atd. Možné kombinace jsou technicky prakticky neomezené (reálný smysl samozřejmě dávají jen některé).

twiGIS tak dokáže velmi bezstarostně a přitom velmi efektivně zajistit publikaci téměř jakýchkoliv dat. Umí i takové kousky, že se přehledová hladina napojená na několik entit se zoomováním do detailu rozpadne na vektorovou kompozici, kde je možné s každou vektorovou entitou pracovat samostatně - měnit stylizaci, vypínat, snapovat, atd.

O různých scénářích použití a přínosech si napíšeme v dalších částech seriálu.


Ukázková hladina v režimu rastrové keše na přehledce celého areálu.

Ukázková hladina v režimu online rastru při pohledu na jednotlivé budovy.

Ukázková hladina v režimu vektorové kompozice v detailu křížení sítě.

středa 7. října 2020

Jak dostat twiGIS z interního serveru do Internetu a mobilu?

twiGIS obvykle slouží jako interní firemní informační systém. Je nainstalovaný na serveru uvnitř sítě, je v doméně, díky doméně je nastaveno jednotné ověřování a SSO pomocí ActiveDirectory, atd.

Často je však potřeba tuto aplikaci používat i mimo vnitřní síť: v terénu, na mobilních zařízeních, z domova, atd. Tradiční přístupy, jak toho dosáhnout byly dosud dva:

  1. Reverzní proxy: Přes hlavní firemní proxy/bránu je vytvořen prostup z vnější sítě na aplikaci nainstalovanou uvnitř. Poměrně jednoduché a funkční řešení, které však má určitá bezpečnostní rizika (například snadné napadení/zahlcení aplikace zvenku).
  2. VPN: Zabezpečený přístup přes VPN z různých zařízení. Bezpečnější, ale pro uživatele otravnější, na mobilech někdy nemožná nebo komplikovaná metoda.
Obě varianty naši zákazníci aktivně používají. V nedávné době přibyla další možnost, která je nám velmi sympatická: Microsoft Azure AD Application Proxy. Cloudové řešení, které využívá AD identit publikovaných do cloudu (třeba kvůli Office 365) k ověřování uživatelů aplikace a zajistí bezpečné nasměrování komunikace z internetu na vnitřní aplikaci.


Informace k nastavení řešení aplikační proxy a ověřování:

Takže pokud už třeba Azure a Office365 používáte a máte vypublikované identity, je zde velmi zajímavá alternativa pro publikaci (nejen) twiGISu vašim uživatelům do Internetu nebo na spravovaná zařízení.

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!