Best Practise Workflows
- Lauren McArtney (Unlicensed)
- Julian Pilois (Unlicensed)
To help navigate the various publishing options and decisions when working with WebGIS, Grant Carroll (Eagle Solution Architect and LocalMaps Lead Developer) has put together a series of best practice workflows and recommendations to get the most of your WebGIS and in turn, with LocalMaps.
Email LocalMaps Support to ask a question or request assistance.
Optimizing 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 of the features to the front end where the browser has to 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 be have 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 the majority 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.
Note: The latest version of the web map beta allows for the creation of group layers within the web map, however these are not currently supported in Web AppBuilder (August 2020)
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 have 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.
Optimizing 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, eg 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, eg MXD and APRX.
Results:
Feature Tested | ArcGIS Pro Loading Time (secs) | ArcMap Loading Time (secs) |
|---|---|---|
Print Test Grouped Feature | 4.69347 | 2.182814 |
Print Test Grouped Map | 4.134819 | 1.658347 |
Print Test Label Feature | 5.065971 | 2.497792 |
Print Test Label Map | 4.25637 | 1.773857 |
Print Test No Group Feature | 4.84537 | 2.453112 |
Print Test No Group Map | 4.467588 | 1.781842 |
Print Test Scales Feature | 4.77857 | 2.20711 |
Print Test Scales Map | 4.109604 | 1.701419 |
Averages:
ArcGIS Pro vs ArcMap
ArcGIS Pro 4.45 Seconds
ArcMap 2.03 Seconds
Feature Service Loading Speed
ArcGIS Pro Feature Service 4.84 Seconds
ArcMap Feature Service 2.33 Seconds
Map Service Loading Speed
ArcGIS Pro Map Service 4.24 Seconds
ArcMap Map Service 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 to ascertain why this is the case.
When using labelling it’s also clear that using labelling in conjunction with Map Services works better than compared to Feature Services.
Optimising Reporting
The way that reporting works in LocalMaps is by using copies of an ExportWebMap2 specification JSON. The ExportWebMap specification is a JSON object that is used to generate maps with ArcGIS Print services, regardless if these have been created via ArcGIS Pro or ArcMap.
When a map is added to a report in the administration page and then saved, the code in behind the page sends the selected web map to a print task to generate the JSON object for the map.
When a report is run, this JSON object is deserialized in the Web API, the graphic representing the selected property is added to the map, the extent that the map should be displayed at is calculated and then the scale is determined.
The scale is determined by using the details from the map template provided by the Print Templates Layout service, which provides the size of the data frame that the map is going to be inserted in to. Using this in conjunction with the extent, the appropriate scale for the map can be calculated.
When the above have been completed, the JSON object, along with the print template to use and the output type are sent to the configured print service. The print service generates the map and then passes back to the Web API a url to generate map.
When there are multiple maps in a report, these are then aggregated together in the appropriate order for the final output.
When using a conditional report, the API first decides whether a report needs to be generated by checking that the input geometry matches with the spatial relationship configured for the particular layers. As soon as the first layer returns true, the API skips checking any further layers as a true value indicates the report should be added, so no further checks are required.
This means that the more layers that are required to check the report, the longer a report may take to get a true value or a false value (the default).
It also means that the fastest way to generate a report is to run them as a standard report. If you require the addition of a title page then a conditional report can be used to add in the title page, by creating a report that contains just the title page, and then a second report containing all the maps required. This means the conditional check only needs to run twice, which will produce faster results.
Optimizing the Report Creation
The following tips will help optimize the report generation and ensure that it runs as faster as the technology will allow it to run.1. Map Services generate faster the Feature Services
Labels should be created in the Map Service or Feature Service, but complex placement functions such as maplex, will slow down the creation of the image.
Labels created in a web map will not work, this is because when creating labels in a web map, these are created using a graphics layer using a text symbol for the label. We cannot add all the possible labels in to the ExportWebMap JSON object saved to the database.
Use hard coded legends in the print templates, this will generate faster but also avoid issues with legends overrunning the page or template.
The degree of parallelism should be set to the number of logic processors on the machine that LocalMaps is installed on. The report will only work as fast as the number of concurrent requests it can make. Two processors means two concurrent requests, four processors means four concurrent requests and so on.
The maximum number of Print Service instances should be set to N+1 the number of processors above. E.g. if you have 2 logical processors on the machine, you should set the maximum number of services to 3.
Ensure that you have appropriate scales set for the services in the web map. LocalMaps can override scale dependencies set in the web map, however, it cannot override scales set in a service, this means that if the output print is at a scale that falls outside the range of a layer, then that layer may not be drawn.
The recommendation is to create web maps specifically for the reports that you want to create.
Updates to a Web Map
It is important to note, that LocalMaps does not store the web map in the database, but a generated ExportWebMap JSON. Any changes to the underlying web map will not be carried through to the report automatically. The report will need to be updated for the changes to be carried through. Simply configuring the web map in the report configuration will allow the ExportWebMap JSON to be updated.
The reason we do not store the web map in the database or generate the ExportWebMap on the fly is because requesting the web map from Portal or from ArcGIS Online is expensive, we need to authenticate to get the token, we then need to get the appropriate web map JSON< deserialize that, apply the correct layer visibility and then generate the ExportWebMap JSON. It is far faster to extract the JSON direct from the database.
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 a large number of 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, Internet Explorer 11, and Edge.”