Latest Contributions by KamilNovák

I don't have a solution but I would also like to know if there is a solution. Thanks. ... View more

I really support this idea. ... View more

@JonahLay There are many reasons to set different sharing setting for the associated web feature layer. For example: some Portal users can only view the data in the app (WAB, ExB) vs. some users have the right to edit the data in the same app within the opendata catalog we don't want to share a map image layer that creates a separate "HTML item" ... Yes, it's exactly as you say. Our current workflow is as you describe. And our sharing settings can be very complicated - many assigned groups. And this setting is lost after overwriting. ... View more

Jen pro ilustraci reálného nasazení Koop: Aplikace polohy vozidel MHD v Mostě konzumuje feature službu, která vniká právě v Koop. Pro Koop byl v tomto případě připraven custom plugin, který v reálném čase transformuje XML data z WSDL služby poskytované SW Dopravního podniku. Rozhraní samotného Koop pak běží ZDE.   ... View more

Také rádi této možnosti využijeme k inspiraci, k načerpání nějakých těch zkušeností, best practices a tipů. Díky. ... View more

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 🙂 ... View more

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í 🙂 ... View more

Is there some solution for this issue, please?  I found this note on the ArcGIS Hub Changelog (9 November 2021): "Fixed custom footer missing on Enterprise sites (10.9.1)" Is this note relevant for resolution of this issue? Thanks. ... View more

We observe the same behaviour. Enterprise 10.9.1, WAB Developer 2.23. ... View more

Same problem on Enterprise Sites 10.9.1, too. ... View more

Yes, I noticed that when migrating my application to ArcGIS JS API 4.19. I thought that I have issue in my app, but not, the problem is reproducible in the MapViewer (4.19) with Esri layers. ... View more