Best Practice Workflow
Optimising Web Maps
Tile Layers vs Feature Layers
Tile Layers support fast visualization of large datasets because the data is stored in predefined tile images. These layer types are often used as reference layers in maps and cannot be edited.
If the features you want to include in your map cover a large area or are complex, using a Hosted Tile Layer or Hosted Vector tile Layer will decrease the time it takes to draw the features in your map. You could also use a Cached Imagery Layer or Map Image Layer that represents the features you need, as these layers also use predefined caches of data.
Feature Layers (as the name implies) are focused on the features and their attributes. For example, they allow you to apply different styles to the layer based on feature attributes, apply filters to the layer to display only certain features, cluster points based on common attributes, or configure pop-ups that present attribute information. If the owners enable it, you can edit the data.
Feature Layers are more flexible and interactive than Tile Layers, but this comes at a cost. As most feature layer functionality relies on accessing the feature attributes, the app must communicate frequently with the source data, which can slow drawing times. But, if the map you create is intended to allow people to collect or update data, or you want to filter or symbolize features based on specific attributes, you need to use a feature layer in your map.
Feature Services vs Map Services
A Map Service behaves in a different way to a Feature Service. When a request to draw features is sent to a Map Service, the server creates an image of the currently enabled layers and then sends this image back to the front end that requested it, the image is then displayed.
When a feature service receives a request to draw features, each feature for each layer is packaged up and sent back to the front end as a JSON object, which contains all the vertices required to create the feature, all the required attributes and the details for the symbology.
As a result of the above, if you need to show thousands of features on the map quickly, the best solution is to use a Map Service, as it will process everything on the server and send through the result. A Feature Service will have to send through all the features to the front end where the browser must draw the features on the map.
Feature Services have far more functionality that map services, but for pure display purposes a map service may be better.
One thing to note is that if you cherry pick out a layer from a Map Service, e.g. your service has 10 layers in it and you chose to just use the first layer in your map using the URL and the ID for the layer, the resulting layer in the map will behave like a Feature Service. E.g. it will send back all the features to the front end as a JSON object.
Remove unnecessary layers that clutter the map
You are not trying to recreate ArcGIS Pro in the web. Having a web map with hundreds of layers will not perform very well and will confuse many of your users who are not GIS people. Simpler is better, have a single purpose and direction for the map is best. Think of a web map as an app. It should do one thing and do it well. Not all people are savvy GIS users who know what layers are, how to use a layer control etc. The less clicks a user needs to make on a map the better, even if they do not have to change any layers. They can just click on a feature and get the details they need.
Generalize the geometry of layers that don’t need detail
If you have complex geometries with thousands of vertices, these do not translate well to the web and do take a long time to draw. Consider simplifying the geometries at smaller scales and using more complex representations at smaller scales where the detail is important.
Publish Vector Tile Services as background reference data
If you have data that doesn’t change on a regular basis, then consider publishing this as a vector tile layer. This can even be an approach for data that is updated weekly, Vector Tile Layers take far less time to cache than traditional Map Image Tiles and have the advantage that they can be styled in different ways to suit the needs of the map they are used in.
Setting visible scale ranges and filters
Are some layers necessary only at specific scale ranges? Use the scale setting within the web map to control when layers are visible and displayed.
Filters on layers can also be used to thin out dense layers of information to only show the information that is required. An example of this would be filtering on a date ended field to only show current information, and not cluttering the map with irrelevant features.
Avoid multiple nesting in layers
When creating web maps, its best to avoid having multiple layers of nesting. The web-based API’s do not handle this well and it can cause issues with the out of the box operation of widgets such as the layer list widget. The best way to avoid this is to have services that either have no grouped layers or if you really must have a group, only one level of grouping.
Publishing Services Tips
-
Remove unnecessary fields from any layers and always include the SHAPE field, as this is required to allow the objects to be queried and displayed as a dynamic layer properly.
-
Avoid multiple levels of nesting, e.g. group layers containing more group layers. These do not translate well to the web and can cause issues with the out of the box tools that exist for controlling layers in the web.
-
Ensure that any field names in a layer have aliases, this means you only need to set the aliases in the service, and not in every popup you create from the layer.
-
Create popups in ArcGIS Pro, this will mean that you only need to create the popup once and it will be available in the same format in each web map you create.
-
Consider the scale dependencies that are used - you can set these in the web map. If they are set in the service then they will apply to any application that uses the service, which can lead to confusing results, e.g. when used in reporting for LocalMaps.
-
For services that are not heavily used, consider publishing these as a shared instance,1 this will reduce the memory footprint on the service.
Optimising for Fast Printing
Testing has shown that Print Services created using ArcMap perform significantly faster than the those created using ArcGIS Pro.
The below result highlights the differences that have been found when testing.
The test methodology was to use the same extent with web maps from various configurations, e.g. grouped layers, non-grouped, map services vs feature services and send these to a Print Service created from ArcGIS Pro and ArcMap. The time to create the image was the only variable measured. Each request was made 50 times and the total time taken recorded.
Each print request used an A4 template with a map frame only in the template. The size of the map frame was the same between the two templates, e.g. MXD and APRX.
| Feature Tested | ArcGIS Pro Loading Time (secs) | ArcMap Loading Time (secs) |
|---|---|---|
| Print Test Grouped Feature | 4.693 | 2.183 |
| Print Test Grouped Map | 4.135 | 1.658 |
| Print Test Label Feature | 5.066 | 2.498 |
| Print Test Label Map | 4.256 | 1.774 |
| Print Test No Group Feature | 4.845 | 2.453 |
| Print Test No Group Map | 4.468 | 1.782 |
| Print Test Scales Feature | 4.779 | 2.207 |
| Print Test Scales Map | 4.110 | 1.701 |
ArcGIS Loading Time Comparison
| Service Type | ArcGIS Pro | ArcMap |
|---|---|---|
| Overall Average | 4.45 Seconds | 2.03 Seconds |
| Feature Service | 4.84 Seconds | 2.33 Seconds |
| Map Service | 4.24 Seconds | 1.72 Seconds |
The results show that the fast print performance is achieved when using Map Services sent to a Print Service created using ArcMap. Enquires have been raised with Esri in conjunction with why with Map Services works better than compared to Feature Services.
Data Decision Tree
The GIS content managers assessing existing services and data sources should determine how best to store and share data from the available options, based on how the data is updated and from where it is going to be served; ArcGIS Online, ArcGIS Enterprise or Both. Eagle’s Technical Advisors can help guide the users through this phase, but it would be up to the GIS staff to choose the ideal option and implement it. The collaborative approach to migrating the content and applications would allow staff to acquire new skills that would help them maintain and extend this deployment in the future. This decision tree diagram should serve as a general guide when choosing a data hosting option when redeploying content.
-
Hosted Feature Layer: “Hosted feature layers support vector feature querying, visualization, and editing. Hosted feature layers are most appropriate for visualizing data on top of your basemaps. In web apps, hosted feature layers are drawn by the browser and support interactive highlighting, queries, and pop-ups” They are ideal for storing data that will only be edited through web services or will not change but requires dynamic draw and query.
-
Federated Feature Service: It’s a traditional Feature Service that serves Enterprise Geodatabase features and tables from a GIS Server that is federated with the Enterprise Portal. This scenario would be a good fit for feature classes that are frequently edited from ArcGIS Desktop but also needs to be edited through web services. This type of item if shared in the Enterprise Collaboration would push edits to ArcGIS Online as read-only content for other applications to consume.
-
File Geodatabase Dynamic Map: It’s a traditional map service that reads data from a file geodatabase stored locally on the GIS Server. This is the fastest option for serving read-only content that needs to be drawn dynamically or query. It does not support the copy option on Enterprise Collaboration. It is most appropriate for servicing legacy applications that require OGC (WMS) or traditional Map Service capabilities like group layers.
-
Tile layers: “Hosted tile layers support fast map visualization using a collection of pre-drawn map images, or tiles. These tiles are created and stored on the server after you upload your data. Hosted tile layers are appropriate for basemaps that give your maps geographic context. You can use tile layers published from hosted feature layers to visualize many features at one time, and you can keep the tile layer in sync with changes to the feature data.” This is the best option to serve Imagery basemaps.
-
Vector Tile Layers: Are a newer optimize format for serving vector base maps. They are a replacement for the conventional Map Service Cache (Tile Layers) generated from vector data sources. They are built on ArcGIS Pro and served from either ArcGIS Enterprise or ArcGIS Online. They can also serve as a substitute for group layers in traditional Map Services where the layers in the group do not change very often. A vector tile from each group layer would provide a better display experience than group layers. In is current release it does not support querying or pop-ups. To support pop-ups and querying a combination of Vector Tile Layers and Hosted Feature Layers would be required. “Vector tile layers have the best performance on machines with newer hardware, and they can be displayed in most current versions of desktop browsers, including Chrome, Firefox, Safari, and Edge.”