Jak vytvořit mapu, aby....
Ahoj GiSáci,
tak já také přispěju nějakým tím svým pohledem, když jsem byl vyzván, i když asi nepřinesu nic objevného 🙂 Univerzální návod "jak správně vytvořit mapu..." podle mě není. Řekl bych, že je dnes jen více možností "jak to nakonec udělat". Tady bych souhlasil s @MatejVrtich, že vždycky záleží na konkrétních potřebách dané aplikace, povaze publikovaných dat atd.
Pro potřeby nějaké úzce zaměřené monotematické aplikace v JS4.x s jednou dvěma čtyřmi vrstvami bych klidně mapu sestavil z Feature služeb, byť by se jednalo o aplikaci bez potřeby editace. Z mého pohledu se v JS4.x s Feature službami daleko lépe pracuje, co se týká přístupu k vrstvám, funkcionality atd., což samozřejmě vyplívá ze zmiňované client side strategie, ale to by asi bylo na jinou diskuzi. Na druhou stranu Feature služby nabízejí opravdu omezenou symboliku a ani u jednoduchých, ale specifických map si s tím nemusíte vystačit. Aktuálně máme rozpracovanou např. tuto aplikaci https://mapy.mesto-most.cz/app/odpadove-nadoby/. Aplikace je jednoduchá, monotematická, v rámci API pracuje s konkrétními vrstvami - řeklo by se modelová situace pro Feature službu. Symbologie si ale vyžádala klasickou mapovou službu - na složenou atributově řízenou symboliku jednotlivých kontejnerových stání Feature služba nestačí.
Další věcí je rychlost vykreslování. V JS4.x už v tom takový rozdíl není, ale alespoň z naší zkušenosti, kreslení ze serveru a posílání obrázků je prostě i v současné době rychlejší. A 2x to platí u datových sad s velkým množstvím prvků a složitou geometrií. Nevím, do jaké míry za to může naše sekurita, tj. co všechno se kontroluje při požadavcích na server a v rámci response, ale naše zkušenosti takové jsou. Když už jsem se zmínil o perfomace Feature služeb, setkali jsme se i s tím, že některá slabší klientská zařízení (typicky starší a levnější Androidy) s tím mají docela problém (daň za kreslení na klientu). Takže i v současné době, je z mého pohledu, nad tím dobré přemýšlet.
U "velkých prohlížecích" aplikací typu Územně plánovací dokumentace apod. s velkým množstvím služeb a bez nějakých specifických funkčních potřeb bych pak asi zůstal u MapServices.
Ohledně problematiky "editační" a "zobrazovací" vrstvy/služby ve WAB vs. FieldMaps vs. ExB... si také nechám poradit nějaké Best Practises. Zatím to řešíme jednou mapou v MapViewer Classic s tím, že ve FieldMaps editační vrstvy označujeme "nazevVrstvy - EDITACE". Popup je nastaven jen nad "zobrazovací vrstvou", "editační vrstva" je průhledná, resp. symbol vrstvy je průhledný - pokud by byla průhledná celá vrstva, při editaci geometrie by nebyla vizuální zpětná vazba při posunu hran atd. K tomuto jen takový malý bezvýznamný postřeh, ono to "zdvojování" vrstev (editační a prohlížecí) může mít i své výhody. Pokud se potřebuju na editovaná data dívat vícero způsoby, tj. přepínat mezi pohledy (viz obrázek níže), kombinaci editační a prohlížecích vrstev se dle mého názoru neubráním.
Ohledně registrování databáze v Portalu: Z mého pohledu zajímavá věc, ale zatím toto nevyužíváme. Jinak se mi zdá, že technicky vzato se defacto jedná o automatickou publikaci Feature Layer a MapImageLayer pro každou databázovou tabulku. Takže to není tak, že by se na pozadí nevyužívala žádná mapová služba.
Těch témat, co si Jardo nadhodil, je tolik, že by se o tom dalo mluvit do nekonečna. A už teď koukám, že jsem asi delší než ty a na tvojí titulní otázku jsem stejně neodpověděl, tak už toho radši nechám a přenechám prostor někomu, kdo tomu rozumí 🙂
Co se týká toho tématu FieldMaps vs. nový MapViewer, tam budete určitě dál než my. My jsme teprve nedávno upgradovali z Enterprise 10.8 na 10.9.1 a v rámci 10.8 ještě nový MapViewer nebyl k dispozici. Nějaké pokusy na AOL samozřejmě byly, ale reálné potřeby, výhody, nevýhody... se ukážou vždycky až v ostrém provozu.
FieldMaps jsme provozovali i v rámci 10.8, ale bez té webové nadstavby a v kombinaci s klasickým MapViewerem. A tam to kouzlo, o kterém píšeš fungovalo. Pro FieldMaps pak editační vrstvy nezbývalo než označit, jak jsem psal, třeba "nazev_vrstvy - EDITACE". Pokud se to dá řešit i nějak elegantněji a třeba i v kontextu nového MapVieweru, tak budeme také rádi za nějaký postřeh.
Nejspíš to ale bude o tom, přesně jak píšeš, začít nad tím přemýšlet jinak. Cestou zřejmě bude speciální mapa pro FieldMaps sestavená z Feature vrstev s nakonfigurovanými popupy a speciální mapa pro webovou aplikaci, která bude nabízet na data vedle editace nějaký širší pohled v podobě doplňkových MapServer služeb. Zřejmě bude ale záležet vždy na konkrétním projektu, protože i ve FieldMaps se MapServer služby mohou někdy hodit.
Pak se samozřejmě nabízí otázka správy, údržby a aktualizace toho všeho - počet map, služeb, portálového obsahu roste a přehled se ztrácí. Jardo, ty jsi třeba psal, že popupy atd. definujete už na úrovni mapového projektu. Já bych to tak, i v kontextu právě toho narůstajícího množství obsahu, úplně neviděl. Co když potřebuješ hromadně upravit zobrazování nějakého atributu v pop-up napříč většího množství vrstev (typicky třeba formát datumových fieldů)? Co když potřebuješ hromadně přidat nějaký atribut napříč několika projekty (např. ti poskytovatel ÚAP dodá aktualizaci, kde je nějaký atribut nově vyplněný a ty ho chceš nově zobrazovat v pop-up výkresu záměrů, výkresu limitů, výkresu hodnot, ....)? Těchto updatů se dělá na úřadech poměrně dost. Jaké s tím máte zkušenosti a jak se stavíte k tomuto? Za mě je to docela komplikace - otevřít každý projekt, ale hlavně ručně naklikat veškeré změny. Hromadná editace JSON webových map, např. pomocí skvělého GISáckého softwaru Visual Studio Code, je pro mě nenahraditelná 🙂 Funkce "Najít a nahradit" napříč JSON soubory, a to i celé bloky kódu, je za mě skvělá a ArcGIS Pro ji bohužel nemá... teda vlastně má, ale nedá se použít v tomto smyslu 🙂
Ale to jsem úplně odbočil... i když vlastně.. nemohlo by právě tohle trochu usnadnit "ten stále se zesložiťující proces tvorby webové mapy pro řadu účelů" - prostě ji rozbít na více méněúčelových pomocí nějakého mocného IDEčka 🙂
K tomu bych chtěla dodat, že jsem při tvorbě nové webové mapy v Map Viewer narazila na několik problémů.
1) Obsahem mojí webové mapy je mapová vrstva, kterou jsem si sama nastavila podle potřeby v ArcGIS Pro, včetně nastavení pop-upů, a publikovala. Při načtení vrstvy do Map Viewer se mi ale v pop-upech některých (!) dílčích vrstev doplnil automaticky text ve formátu html kódu do kolonek název a popis seznamu polí. Nežádoucí text jsem proto v Map Viewer manuálně smazala a webovou mapu uložila. Text se mi už dál nezobrazoval, ale automaticky se mi vypnuly pop-upy všech ostatních vrstev. U některých vrstev se přitom nastavení pop-upů úplně změnilo, vyskakovací okno bych tak musela v Map Viewer znovu nastavit. Při přepublikování mapy se potom většinou problém znovu objeví, jen se přenese na jinou vrstvu (nebo více vrstev), která předtím fungovala dobře, aniž bych jakkoliv měnila nastavení pop-upu.
2) Po několika přepublikováních problém s pop-upy najednou zmizel. Objevil se ale jiný problém. Pro některé vrstvy jsem nastavila minimální měřítko 1 : 5000. Ve webové mapě se ale vrstvy v tomto měřítku nezobrazí, teprve až po přiblížení. Když jsem se podívala do nastavení rozsahu viditelnosti v Map Viewer, stačilo horní hranici posunout o kousíček za 1 : 5000, a vrstva už se zobrazila správně. Zároveň se mi ale úplně rozházela symbologie pro různá měřítka, a taky se vrátil problém s textem v pop-upech. Opravení jedné chyby tak znamenalo objevení jiné, zdánlivě nesouvisející chyby.
Všechny tyto chyby se však děly pouze v Map Viewer. Po otevření stejné webové mapy v Map Viewer Classic se všechno zobrazovalo tak, jak mělo.
