Best Practices für die Darstellung – Webkarten-Viewer (neu und klassisch)

Henry

Hallo zusammen,

Unsere Organisation nutzt den klassischen Webkarten-Viewer sehr intensiv, und ich arbeite daran, einige Tools auch auf den neuen Karten-Viewer umzustellen.

Wir haben viele Vektordaten, die wir uns ansehen müssen, und interne Benutzer möchten häufig, dass von Anfang an möglichst viele Daten verfügbar sind. Einige gehostete Feature-Layer mit unterschiedlichen Einsatzzwecken habe ich in eigene Webkarten und Apps aufgeteilt. Trotzdem brauchen wir eine Art „Sammel-Webkarte“ als schnelle Referenz für eingehende Daten – oft mit dynamischen Eigenschaften zur Anzeige von Pop-ups (für öffentliche Grundstücke, Hydrographie, Straßen sowie interne Datenerfassungsebenen). Außerdem arbeiten wir in einem abgelegenen Gebiet und haben leider keine besonders gute Internetverbindung.

Ich habe den Anzeigebereich und die Ausdehnung aller Layer umfangreich konfiguriert, um möglichst viel Leistung herauszuholen, aber ein paar Fragen sind noch offen:

• Gibt es einen spürbaren Unterschied oder bewährte Vorgehensweisen beim Hinzufügen öffentlicher Webservices als Referenz-Layer? Also sollte ich sie zuerst als Element unter „Eigene Inhalte“ hinzufügen oder direkt über die Registerkarte „ArcGIS Online“ in die Webkarte einfügen?
• Mir ist klar, dass ich idealerweise Kartenbild-Layer für eine schnellere Darstellung verwenden würde. Unsere Benutzer möchten jedoch auch Referenzinformationen über Pop-ups abrufen können. Lässt sich das mit Vektor-Kachel-Layern lösen? Zumindest für unsere internen GIS-Daten?
• Gibt es weitere Tipps oder Hinweise zur Optimierung von Webkarten-Viewern?

Wie gesagt, vielleicht etwas pingelig – aber ich versuche, die bestmögliche Leistung herauszuholen! Danke!

jcarlson

To your first point, I prefer to add them as true Items in the Content page. Doing so allows you to define your own default symbology, filters, etc, where simply pulling the service into an individual map will bring in the service's own defaults every time. This may or may not be an issue for you, but here's an example:

We prepare an annual highway map for the county. We like to include about an inch or so of surrounding county features for additional reference and usefulness for areas along the border. However, maintaining and updating layers for this purpose would be wildly inefficient. We've got enough to do updating the roads and municipalities inside the county. By tapping into public web services like the Living Atlas, we can easily get those reference features. Since we only need adjacent counties, though, we can save the visualization settings to filter out everything but those counties, and set the symbology to our own "adjacent county reference" style. For every future map that requires those layers, we can ensure a consistent visual style.

To the second point: vector tile layers do not do pop-ups. But they can provide a great performance boost for layers with lots of features or labels. We have found that many of our common reference layers are actually already in the OpenStreetMap vector basemap. By applying our own custom style to that basemap, we can isolate and highlight certain layers. If a slightly longer turnaround time is amenable to you, you can then simply apply edits and updates to OSM, and then you don't have to worry about updating the tiles yourself.

Starting in 2.8, it's also possible to publish a hosted vector layer that is linked to vector tiles, and these allow you to refresh your vector tile cache easily as well. But then, it still doesn't address popups.

Other tips? Maybe err on the side of being restrictive with layer visibility scales. On our parcel viewer, most users are looking at individual parcels at large scales. By limiting the visibility scale, users can zoom out and pan across the county without the viewer bogging down when you pan over a densely-developed neighborhood.