Taking Your Maps Offline: Publishing the Data

By Tom DeWitte, Kevin Ruggiero, Mike Hirschheimer

Part 3 of 5

Organizations large and small need to keep their mobile workers informed. Whether it is a blue-sky day or storms are brewing overhead, mobile workers need current information on the utility system they spend every day maintaining. This information informs the mobile worker about which conductors are energized, pipes are pressurized, and cables are live. Critical information that helps to keep the mobile worker safe and the utility system reliable.

Consistently and reliably transmitting new and updated information to a utilities entire mobile workforce is not easy. The paper maps deployed for the initial 150 years of the utility industry were unable to receive incremental updates. The day after the paper maps were put into the hands of the mobile worker, the information on the map was already out-of-date. The same issue applied to early mobile map viewer applications, like ArcReader. The snapshot of information stored locally on the mobile device was unable to be incrementally updated. It too became more and more outdated with every passing day after the snapshot of information was created.

These lessons learned from previous efforts to provide timely and current information to the mobile worker, tell us that a mechanism is needed to update a mobile worker’s information incrementally and consistently. In today’s mobile world, this equates to maintaining a local copy of the geospatial representation of the pipes, conductors and cables on the mobile workers phone, tablet, or laptop. The mechanism of transmitting this information to the mobile device when it is connected to a network is web services.

What Are Web Services

A web service is a method of communication between your mobile device and your data server. When a web service is created it is an always-on process, that is listening for mobile client applications to send requests.

There are many different types of web services. Within ArcGIS Enterprise there are specialized types of web services for geocoding, geoprocessing, sharing image data, and sharing vector data. ?The sharing of vector data is how feature and table records are passed between the mobile device and the centralized data repository.

ArcGIS Enterprise supports multiple types of vector data web services. These include, KML, WFS, ArcGIS Feature Services and Hosted Feature Layers. ArcGIS Feature Services and Hosted Feature Layers are the only vector data sharing web services which support the synchronization of changes between the mobile device and the centralized data repository. Put another way, to keep our mobile workers informed with data changes being made by office staff and data changes being made by other mobile workers, there must be either a Feature Service or a Hosted Feature Layer to handle the communication.

A feature service is how ArcGIS Enterprise Geodatabase managed data such as Utility Network data is shared to mobile devices for synchronization.

A hosted feature service is how ArcGIS Portal hosted feature layer data is shared to the mobile devices for synchronization.

Organizing Data with Feature Services

In the example we have been describing in this blog series, the data that needs to be made available to the mobile device for local caching is coming from four different data repositories. Two of the data repositories are Enterprise Geodatabases, one data repository is the Portal’s hosted feature layers, and the fourth is an ArcGIS Online registered vector tile basemap configured for export. Each Enterprise Geodatabase will contain multiple featureclasses and tables which need to have their records synchronized to the mobile devices.

A single feature service can be a grouping of 1 or more featureclasses and tables. When trying to determine how to organize your data into feature services, it is important to know that each individual feature service can only connect to one data repository.? This means that all featureclasses and table must be accessing the same enterprise geodatabase thru the same relational database connection.

Publishing data for offline use has some additional constraints on the organization of content in the feature service. ?

??????????????? -A featureclass or table can only be referenced once.

??????????????? -Subtype group layers are not a supported layer type???????

Publishing a Feature Service for Syncing

Creating a feature service can also be referred to as publishing the data. Publishing the data is the 2nd of the four primary steps in creating offline map areas.

The “Publish the Data” step is typically accomplished with the desktop tool, ArcGIS Pro. The “Share as Web Layer” tool is the specific tool to use to publish the feature service.

By default, a feature service does not support synchronization. To activate synchronization, check the box “Enable Sync” within the feature properties configuration panel.

Many of the featureclasses in enterprise geodatabases have their geometries configured to support the storage of elevation (Z) and distance along a line (M). Field editors of this Z-enabled and M-enabled data may not have this information available at the time of data capture. To allow field editors to collect this information without a complete geometry definition, default values and behavior need to be defined.

For the Z value check the box to turn on the “Apply default to features with Z-values”. Then set the default z-value to the desired value.

For the M value check the box to turn on the “Allow geometry updates without m-value”. This will set the M value to NULL when a new feature is created.??????

Publishing Your Utility Network

Key to keeping mobile workers safe is providing current information about their utility assets. When these assets are stored in an enterprise geodatabase and managed with the utility network capabilities, the publishing step is a matter of modifying the properties of an already published feature service.

For the office mappers to create and maintain the digital connected representation of your utility assets, requires that the data be configured as branch versioned and published as a feature service. The already published utility network feature service may not be fully configured for syncing with offline map areas. To support syncing to offline map areas requires two configurations of the feature service that will need to be set. The first is to modify the already mentioned feature service properties to enable syncing. The 2nd configuration is to define the role that branch versioning will have during the synchronization process.? There are two options for branch versioning during sync:

-None

-Create a version for each downloaded map

To know which option to set starts with an understanding of what your mobile workers will do with this utility asset data.

Version Creation = None

If the answer to this question is that mobile workers will only view and query the utility network data, then the default setting of “None” is the correct setting. With this configuration no additional versions are created or required to successfully sync.

If you set the Version Creation option to “None” and allow your mobile workers to edit the utility assets, those edits will be posted directly to the default version. Syncing to the default version will share these edits immediately to all other office and field users.

Version Creation = Version for each downloaded map

This option is recommended when your mobile workers are editing the utility network managed utility assets, and those edits need to be reviewed and quality control checked prior to sharing with the rest of the organization.

When this option is chosen, a branch version is created within the enterprise geodatabase when the mobile worker downloads the offline map area for the first time. All field edits will be synchronized to the created branch version.

A more detailed explanation is available within the Esri online documentation.

Version Creation = Create a version for each user

This option is not valid for branch versioned feature services.

With these two configurations set, the utility network feature service is ready to support offline map area synchronization.

Publishing Your Landbase

Unlike the Utility Network, a feature service may not already exist for sharing the landbase information. Office mappers may be using the ArcMap desktop application and its direct connection capability to access the landbase data stored in an enterprise geodatabase. In this example configuration the enterprise geodatabase will be using traditional versioning to track and manage changes to the landbase.

Publishing the landbase feature service to support offline map area syncing requires checking feature service configuration option, Enable Sync. ?

With sync enabled you now must decide what versioning strategy to deploy to support the mobile users. If your mobile users are not intended to create or modify the landbase features, then the correct Sync Version Creation option is: None.

If you mobile users will be creating new landbase features or modifying existing landbase features then a version needs to be created to manage the flow of landbase edits. Two version management options are available for traditional versioning: “Create a version for each downloaded map” or “Create a version for each user”.

A more detailed explanation of these sync version feature service options is available with the Esri online documentation.

Scaling your Feature Services

At the beginning of each workday there will likely be a spike in the number of mobile devices attempting to sync to the published feature services. This spike is caused by the mobile workers opening Field Maps and the offline map area enabled web map on their mobile device. This will initiate a synchronization.

The capacity of a single feature service to scale to accommodate this morning spike in concurrent devices requesting to sync is defined within the pooling portion of a feature service’s properties. The pooling parameters which directly impact capacity are: Minimum number of instances per machine” and “Maximum number of instances per machine”. These parameters are adjustable after the feature service is published.

The Minimum number of instances per machine value represents the base level of concurrent users that a single server can support.? As the number of requests for data increases the server will automatically start creating new additional instances.? This will continue until either the concurrent demand for data is met or the Maximum number of instances per machine is reached.

If the number of concurrent user requests exceeds the maximum number of instances value, additional users will be put into a queue and must wait for an instance to become available.

After the morning spike in synchronization, the number of concurrent users requesting data from the feature service will decline. ?This will cause the number of instantiated instances to decline until the minimum number of instances per machine value is reached.

Publishing Your Field Collected Data

Hosted Feature layers provide another method of publishing data for synchronization to mobile devices. The publication process is integrated into the Hosted Feature layer initial creation process. Once a Hosted Feature layer is created it is automatically published as a feature service.

Similar to an Enterprise published feature service, a hosted feature service is not sync enabled when it is initially created. Enabling sync is a task for the hosted feature layer owner, modifying the settings.

The Minimum number of instances per machine value represents the base level of concurrent users that a single server can support.? As the number of requests for data increases the server will automatically start creating new additional instances.? This will continue until either the concurrent demand for data is met or the Maximum number of instances per machine is reached.

If the number of concurrent user requests exceeds the maximum number of instances value, additional users will be put into a queue and must wait for an instance to become available.

After the morning spike in synchronization, the number of concurrent users requesting data from the feature service will decline. ?This will cause the number of instantiated instances to decline until the minimum number of instances per machine value is reached.

Publishing Your Field Collected Data

Hosted Feature layers provide another method of publishing data for synchronization to mobile devices. The publication process is integrated into the Hosted Feature layer initial creation process. Once a Hosted Feature layer is created it is automatically published as a feature service.

Similar to an Enterprise published feature service, a hosted feature service is not sync enabled when it is initially created. Enabling sync is a task for the hosted feature layer owner, modifying the settings.

Checking the box to Enable Sync is all that is required to enable syncing.

Registering the Basemap to your Org

The final data source to prepare for offline map areas is the basemap. For our example we will use an Esri curated basemap. Most of the Esri provided basemaps are not compatible with offline map area syncing. All ArcGIS Enterprise referenced default basemaps are NOT valid for offline map areas. Only a subset of the ArcGIS Online basemaps is valid for use within offline map areas. A listing of the 19 Esri vector basemaps for offline map areas (for export) can be viewed here.

Using these ArcGIS Online basemaps in ArcGIS Enterprise requires that the basemap be registered as a layer in Enterprise, and that a valid ArcGIS Online user account is embedded within the registered vector tile layer.

It is recommended that this ArcGIS Online user account is not an employee’s active account, nor should it be an account with administrative rights. This embedded user account should be a non-user account created expressly for access to the basemaps.

A Persistent Listener

Consistently and reliably transmitting new and updated information to a utilities entire mobile workforce requires web services. These published feature services have specific parameters which need to be configured to support syncing. Once a service is configured for syncing, it becomes a persistent listener, that is ready to respond to a mobile devices’ request for changes in data. This persistent listener is available on stormy days as well as sunny days to ensure that the utilities mobile workers have the current information they require to safely maintain a reliable utility system.

About this Blog Series

This is the third blog article in our series on offline map areas. In future blog articles we will continue to explain the details of how offline map areas work and the specific decisions an administrator will need to make during deployment.

The first blog provided an overview of offline map areas.

The second blog provided details on how to prepare the data for offline usage and synchronization.

The fourth blog will provide details on the creation of offline map areas, how they are stored and managed in the portal environment.

The fifth and final blog will provide details on the deployment and management of offline map areas for a large mobile workforce.

PLEASE NOTE: The postings on this site are our own and don’t necessarily represent Esri’s position, strategies, or opinions.