Taking Your Maps Offline: Data Preparation
By Tom DeWitte, Kevin Ruggiero, Mike Hirschheimer
Part 2 of 5
How do I get critical utility pipe, conductor, and cable data into the hands of my utility field workers? Before the advent of mobile computers that were not the size of briefcases, the only practical answer was paper. During a disaster event, the mapping department would have to print hundreds of copies of the same map pages to be handed out to utility field workers and foreign crews.
With first-generation mobile computers, a digital copy of the pipe, conductor, and cable data was loaded onto the mobile computers by office staff for use by utility field workers. This snapshot of data was static, and likely did not include updates still in backlog and unable to reflect the transactional updates to the utility’s network as utility field workers were responding to the disaster event.
Neither of these options are ideal for providing utility field workers with the up-to-date information they require to safely perform their jobs. What utilities desire is a mechanism that can automatically and frequently pass changes to the data from the office to the field and from the field to the office. This method of only passing changes is called bi-directional synchronization, though many will simply call it delta syncing.
Bi-directional synchronization keeps the entire organization viewing and using the same data, whether they are in the office, or in the field.
Syncing with ArcGIS
Deploying bi-directional synchronization with ArcGIS requires proper configuration of the data, and the server environment. It also needs a mobile computing device with ArcGIS Field Maps.
Offline map areas is the capability that provides bi-directional synchronization support to enterprise organizations with hundreds, thousands, or tens of thousands of utility field workers.
If this capability is of interest to you, you may be wondering, can I take my data offline? What modifications do I need to make to my data to prepare for bi-directional synchronization with my organization’s mobile devices?
-In this blog we will answer those questions.
Preparing the Data for Offline Map Areas
Preparing the data for offline map areas is the first step in our four-step process.
When preparing data for bi-directional synchronization with offline map areas we need to determine which formats of data are supported. Valid data sources are:
-Enterprise Geodatabases
-Hosted Feature Layers
File based spatial data formats such as shapefiles, file geodatabases, and CAD files do not support this advanced form of synchronization.
Being a feature class or table within an Enterprise Geodatabase or a hosted feature layer does not guarantee the ability to support bi-directional synchronization. There are additional requirements of the data structure.
Prepare to be Published as a Feature Service
For enterprise geodatabases, the first set of requirements is the requirement to publish the data as a feature service. This requirement is the following: feature class or table is registered with the geodatabase, each feature class or table must have a Global ID field, and all relationship classes must have Global ID as the primary key.
A detailed explanation on preparing data for use in offline feature services can be found in the ArcGIS Pro online help.
Hosted feature layers when created are already prepared for offline sync. All you must do is update the Setting properties and check the box to Enable Sync.
A detailed explanation for enabling a hosted feature layer for offline can be found in the ArcGIS Enterprise online help.
Providing the complete map view that mobile workers require to perform the tasks assigned to them requires a wide range of data. Multiple data repositories can be referenced within a single web map for offline map areas.
These different data repositories will often use different methods for tracking changes.
Tracking Changes with Enterprise Geodatabases
For the software to be able to identify the changes which have occurred since the last successful synchronization requires an ability to track changes within the enterprise geodatabase feature class or table. There are three options within the enterprise geodatabase for tracking changes to a feature class or table. These three options are called: Non-Versioned Archiving, Traditional Versioning, and Branch Versioning.
Non-Versioned Archiving
Non-Versioned Archiving is the database method for tracking a change to an individual record. This is perfect for workflows such as inspections, damage assessments, and field observation reports. These short transaction activities preserve every modification made to a record. For each iteration of change ArcGIS automatically assigns a “from date” and a “to date” which defines when that iteration of change was the current state of the record.
A more detailed explanation of non-versioned archiving can be found in the ArcGIS Pro online help.
Traditional Versioning
Traditional Versioning was Esri’s original method for tracking a group of changes as a single transaction. This group of changes includes additions, updates, and deletes to many records across many feature classes and tables. This is critical to preserving the integrity of the full utility system for common changes such as documenting the extension of the utility system to a new subdivision. This method uses a set of database tables to track the sequence in which the changes were made and submitted.
A more detailed explanation of traditional versioning can be found in the ArcGIS Pro online help.
Branch versioning
Branch versioning is Esri’s current and recommended method for tracking a group of changes as a single transaction. This updated long-transaction methodology uses a simpler database structure to track changes. Modifications and additions to records will be marked with a date and time.
A more detailed explanation of branch versioning can be found in the ArcGIS Pro online help.
You are not required to select one of these change tracking methods for your offline map areas deployment. Offline map areas have the capability to bi-directionally synchronize against multiple feature services and hosted feature layers; each using a different method of tracking changes.
Preparing Utility Network Data
The Utility Network is the feature service-based capability to manage networks of pipes, conductors, and cables. The Utility Network has many of the same data preparation requirements as offline map areas. They both require registration with the geodatabase, global IDs, and relationship classes based on the primary key field being global ID.
Utility Networks require editor tracking and branch versioning. The branch versioning tracking of date and time will be used by the offline map area bi-directional synchronization to identify what changes have been made across the records in the data that need to be transmitted to the mobile application running ArcGIS Field Maps.
For most utilities using ArcGIS, the utility mapping department is the only department allowed to edit the utility network configured data. This data repository, when published as a feature service will therefore be read-only to the utility field workers.
Preparing Landbase Data
In larger utility organizations, it is not unusual to have a separate department for landbase mapping and utility mapping. The editing of the landbase is also a long-transaction method. The changes to curb lines, building footprints, and lot lines are commonly tracked as a group of changes which need to be posted together.
In this landbase mapping department scenario, traditional versioning has been configured as the method for tracking these changes. The landbase mapping department is the only group allowed to edit the landbase data. This published feature service will be read-only to the utility field workers.
Preparing Field Collected Data
Field collected data can be any inspection or field observation report that will be documented by the utility field workers. In this configuration the field collected data is being stored as Hosted Feature Layers. Hosted Feature Layers use the Non-Versioned Archiving method of tracking changes.
Preparing the Basemap
Utilities have specific needs of their basemaps. First, the basemap must cover a very large geographic area. Second, the basemap needs to provide highly detailed display scales of the basemap.
This dual need for both a large geographic extent and highly detailed display scales does not work well with traditional image tile layers. But vector tile layers are very well suited to these requirements.
Esri provides a large set of vector tile basemaps with a beautiful range of cartography styles. But not all vector tile layer basemaps provided by Esri support exporting for offline map areas. There is a separate list of these “For Export” vector tile basemaps. The list of vector tile basemaps configured for exporting can be found here.
Putting it all Together
The ability of ArcGIS Field Maps and its offline map areas capability to pull data from multiple repositories provides the flexibility utility enterprise GIS administrators need to pull data from across the organization. In our utility scenario a single web map has been configured to use Utility Network data from a branch versioned Enterprise Geodatabase, landbase data from a traditional versioned Enterprise Geodatabase, inspection data from non-versioned archived hosted feature layers, and a vector tiles layer (for export) from Esri managed services.
The ability to pull data from multiple repositories provides the flexibility utility enterprise GIS administrators need to pull data from across the organization. This avoids complex back-office duplication or replication processes to prepare the data. With a single web map an organization can put all the pipe, conductor, cable, landbase, inspection, and basemap data a utility field worker needs to safely perform their daily tasks.
About this Blog Series
This is the second 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 third blog will provide details and options for publishing the selected data repositories.
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.