When you download and take offline a map that contains an editable feature service that uses data that is registered for traditional versioning, a new geodatabase version is created from the version used by the published data. When a client synchronizes edits with the feature service, edits are applied to the new version. As a result, you need to perform additional reconcile and post processes to get the edits into the published version and share the edits with others.
If the map contains a read-only feature service (only query and sync are enabled on the feature service), and the feature service contains versioned data, no version is created when the map is downloaded. Similarly, no version is created when data is copied during distributed collaboration workflows. When clients synchronize with the feature service in these cases, they have access to any edits made to the source data.
The following two options are provided to allow the feature service owner or ArcGIS Server administrator to choose how versions are created for a particular editable feature service. The publisher sets these options when publishing the feature service.
Note:
These options do not apply to data that is registered as branch versioned.
Create a version for each offline map
This is the default option. With this option, a version is generated from the published version each time you take offline a map containing an editable feature service. The version name includes the following:
- The name of the user who downloads the map
- The name of the feature service
- A unique identifier (ID)
These three components ensure the version name is unique. For example, if user Bob downloads a map that contains the feature service NetFS, the name of the version created could be Bob_NetFS_1404578882000. If the same user downloads the map multiple times (for example, from more than one device), different versions are used when the user synchronizes from each device. Thus one device will not have access to edits from the other device. However, newly downloaded maps will be current with the published version. If there are many downloaded maps, there will be many map versions. As downloaded maps are removed from the application used for offline edits, their versions can be reconciled, posted, and deleted.
Note:
If your feature service was published to an ArcGIS Server site that is not federated with a portal or you don't have individual user accounts in ArcGIS Server, the name of the map version will be Esri_Anonymous_<feature service name>_<ID>.
Create a version for each user
With this option, a version is generated for each user that downloads a map containing an editable feature service. For example, if 10 users download the same map, 10 versions are generated. Each version is specific to an individual user, and the version name is made up of the user name and service name (e.g., Joe_InspectionFS). If a user downloads the map multiple times (for example, from more than one device), the same version is used when the user synchronizes from each device. Thus one device has access to edits from the other device. However, newly downloaded maps will only be as up to date as the last time the user's version was reconciled. A user version remains as long as the user has a map downloaded.
Note:
If you use this option, you should either federate your ArcGIS Server site with a portal or configure user accounts in ArcGIS Server. If you do not do this, the name of the map version created will be Esri_Anonymous_<feature service name>, and every user connecting to the portal will use the same version.
Examples
The following sections take you through example workflows using the version options described in the previous two sections:
- Workflow 1: Download maps for data maintenance
- Workflow 2: Download maps for a short duration project
- Workflow 3: Download maps for an ongoing project
The following compares components of each workflow:
Workflow 1 | Workflow 2 | Workflow 3 | |
Version from which the feature service is published | |||
Offline version is created for each | Downloaded map | User | User |
Number of versions created | Many | Few | Few |
Latency between offline edits and updates to Default version | Low | High (1 week) | High (Daily) |
Maps involved in quality assurance | One map | All maps | All maps |
Frequency that offline versions are deleted | Daily | At project completion | Never |
Workflow 1: Download maps for data maintenance
This workflow involves a member of the organization using Collector for ArcGIS in the field to confirm edits provided from redline maps. In this case, the data is versioned and the worker requires the map he or she downloads to have the latest data from the Default version of the geodatabase. Once back in the office, the employee synchronizes edits made in the field, removes the map, and reconciles and posts the map's version with the Default geodatabase version. The process may be repeated several times a day. As each process completes, the employee deletes the offline map version.
To do this, a web map is available in the company's organizational account for members of the office workers group. A worker who is a member of this group can access the web map using Collector for ArcGIS running on one of the available devices in the office. Prior to leaving the office, the worker downloads the map using Collector. The worker then goes into the field and inspects the requested updates. Corrections are made in the field using Collector. When back in the office, the worker's corrections are synchronized with the feature service, and then reconciled and posted with the Default version.
The following sections describe this workflow:
Publish feature service
To create the web map, a feature service must first be published.
The publisher starts ArcMap and adds data to the map from the Default version. In this example, the data includes some new sensors from a feature class in the company's enterprise geodatabase. The feature class has been registered as versioned.
The publisher publishes a feature service named NetFS from ArcMap.
During publishing, he checks the Sync capability in the Service Editor, since the service is intended to be used in an offline map. The publisher also checks the Query, Update, Create, and Delete capabilities, because the data will be edited. The publisher also clicks Advanced Options to display Feature Service Advanced Options.
The Create a version for each option is enabled in the Advanced Options dialog box. For this example, the publisher checks Downloaded map. With this option set, a uniquely named version is created for the offline map when a field worker takes a map offline. This version is then used when the worker synchronizes.
The publisher also shares the service with the office workers group so data can be accessed by others in his organization.
Create web map
The next step after creating a feature service is to create a web map. The publisher does this by logging in to the organization (ArcGIS Enterprise or ArcGIS Online), creating a web map, adding the feature layer to the map, and sharing the map with the office workers group. The web map's offline mode property is set to enabled making it available for offline use in Collector for ArcGIS. Members of the office workers group can now download the map.
Download web map
With the web map available to them, workers can download the map to Collector for ArcGIS, and go into the field to inspect requested updates. To do this, a worker named Bob starts Collector and logs in to the organization. The newly shared web map appears.
Since the web map has offline mode enabled, it appears in Collector with a download button. Bob clicks the download button to start the download process.
Bob then chooses the extent and the base map resolution for the downloaded map.
When the download process starts, a version named Bob_NetFS_1404578882000 is created from the published version (Default) in the backend geodatabase. Since the service was set to create a version for each downloaded map, a unique version name is generated. The name is made up of the field worker's login (Bob), the feature service name (NetFS), and a unique ID. This version will be used when the downloaded map is synchronized.
The data is then downloaded to the device. Once downloaded, Collector switches the map to reference the local data. At this point, the map can be edited without having to be on the network. A sync button appears on the map in Collector to indicate that it is referencing the local data.
Synchronize edits
While in the field, Bob notices that one of the sensors is incorrectly positioned on the wrong side of the street. He makes this correction using Collector in the field.
During the day, Bob may visit other locations and make other corrections. If connectivity is available, Bob may also choose to sync the edits from the field. When Bob gets back to the office, he connects to the internal network on his device and does a final synchronization. This ensures that all corrections he made in the field are applied to the Bob_NetFS_1404578882000 version.
Now that he is back in the office and his edits are synchronized, Bob removes the local map from Collector and returns the device. The process of removing the local map marks the Bob_NetFS_1404578882000 version as no longer associated with an offline map. Bob then connects to the Bob_NetFS_1404578882000 version in ArcMap and reconciles and posts it with Default. Bob uses attribute-based conflict detection and manually resolves any conflicts.
After the edits are saved and Bob switches back to the Default version, he needs to delete the Bob_NetFS_1404578882000 version.
As Bob further reviews the redline edits in the office, he may need to make other trips to the field. Each trip to the field requires a new downloaded map and a new Bob_NetFS_<ID> version. Each new version will include the latest edits from the Default version. These versions will remain in the geodatabase until they are disassociated with a map and then reconciled and posted.
In addition to Bob, other office workers can perform similar tasks at the same time as Bob.
Once Bob's changes are reconciled and posted to the Default version, he needs to delete the Bob_NetFS_<ID> versions.
Workflow 2: Download maps for a short duration project
In this example, field workers take versioned data offline to make edits. They synchronize their edits in the morning and at the end of the day. A nightly reconcile and post process runs to keep the field workers' versions up to date with edits made by other field workers. When each field worker synchronizes the next morning, each sees the edits made by other field workers. When the project is complete, all edits from the field have been synchronized and applied to the project version. The project version is then reviewed and reconciled and posted with the Default geodatabase version. Upon project completion, an employee deletes the feature service and the field worker versions. In this workflow, the latency of the field workers data is no more than 1 week.
The following describes the steps needed to complete this workflow:
- Publish a feature service
- Create a web map
- Download the web map
- Synchronize edits
- Run nightly geodatabase processing
- Delete offline maps and perform final reconcile and post process
Publish feature service
In this example, a project manager needs to deploy workers to the field to perform sensor inspections. Sensor inspections are carried out periodically throughout the year. During inspections, field workers check for and record things like damage and accessibility of the sensors. This information is used to plan repairs and to understand which sensors can be accessed easily. The project is scheduled to occur over a time period of one week. For the data collection, each field worker has been provided a smart phone running Collector for ArcGIS.
For this project, the project manager plans to create and share a web map for sensor inspections in the company's organization account. The web map will reference a feature service running in the company's on-premises ArcGIS Server.
To create the feature service, the project manager starts ArcMap and adds the sensor feature class from the Default version of the source enterprise geodatabase. The feature class has been registered as versioned. The sensors that are flagged for inspection are colored yellow.
To organize the work, the project manager creates a version named Inspection and changes the map to reference this version.
Next, the project manager publishes an InspectionFS feature service from ArcMap.
The project manager checks the Sync capability in the Service Editor since the service will be used in an offline map. The project manager also clicks Advanced Options to display Feature Service Advanced Options.
In Feature Service Advanced Options, the project manager chooses the Create a version for each user option. With this option, the first time a field worker downloads a map, ArcGIS creates a version for that worker. This version is used when the worker synchronizes edits.
Create web map
Once the feature service has been published, the project manager creates a web map in the ArcGIS Enterprise portal and shares it with a group of which all the field workers are members.
The project manager performs these steps:
- Log in to the organization.
- Create a web map.
- Add the feature service from ArcGIS Server that he just published.
- Save the web map.
- Share the web map and the feature service with the group that includes the field workers.
- Enable the offline mode property on the web map to make it available for offline use in Collector for ArcGIS.
Download the web map
Each field worker accesses the web map by logging in to their accounts with Collector for ArcGIS.
With the web map available, each field worker starts Collector and logs in to the organization. The newly shared web map appears.
Since the web map has offline mode enabled, it appears in Collector with a download button (the cloud with an arrow). One of the field workers (Joe) clicks the download button to start the download process.
Joe chooses the extent and the base map resolution for his map.
When the download process starts, a version is created from the published version in the source geodatabase called Joe_InspectionFS. Since the feature service was set to create a version for each user, the version name is based on the field worker's login (Joe) and the name of the service from which it was created (InspectionFS). This version will be used when the downloaded map is synchronized.
Note:
Any time Joe downloads a map from the InspectionFS service, it will reference the Joe_InspectionFS version. For example, at some point, he may need to remove the local map and re-create it with a larger extent. When he downloads the map again, Joe will see all the edits he had previously synchronized from the Joe_InspectionFS version.
Once the map and data are downloaded, Collector switches the map to reference the local data. At this point, Joe can edit the map without having to be on the network. A Sync button appears on the map in Collector to indicate that it is referencing the local data.
A second field worker (Mary) performs the same steps as Joe. This results in a Mary_InspectionFS version being created in the source geodatabase.
Synchronize edits
While in the field, Joe is assigned work on the east side of the map. When Joe completes a sensor inspection, he marks the sensor feature's status appropriately. If the sensor passes inspection, it appears green. If it is damaged and requires repair, it appears red.
When he has network connectivity at the end of the day, Joe clicks the Sync button on Collector. This applies the edits to the Joe_InspectionFS version in the source geodatabase.
At the end of the day, Mary also synchronizes her sensor inspections from the west side of the map.
Run nightly geodatabase processing
In the evening, an automatic process runs to reconcile and post the field workers' edits. The process first reconciles and posts each field version with the Inspection version. The process applies a conflict policy wherein the last edit in is preserved and conflict detection is attribute based.
When all the edits from the field are applied in the Inspection version, validation scripts run on the data. These scripts look for and correct edits with invalid values or out of bounds features. For example, the status field must have a valid status value. If the value is invalid, it is set back to needs inspection, which is symbolized with yellow points. Once validation completes, the process reconciles the field worker versions with the Inspection version to make sure each has the latest changes.
When Joe and Mary synchronize the next morning, they see the each other's updates.
Note:
The nightly process could also have reconciled with the Default version to bring in edits that have been made to Default since the start of the project. Instead, the project manager has chosen to only reconcile with Default at the end of the project. This allows conflicts to be detected and manually reviewed prior to posting to Default. If this process is done before the end of the project, workers may perform additional edits to these features that will not appear as conflicts on the final reconcile process.
Also note that in this example, the automated process to reconcile and post the field workers' edits runs nightly. This means that a field worker won't see the most recent edits made by others until the next day. To decrease this latency, the process can be run more frequently. For example, if it were run hourly, a field worker could synchronize on the hour to get the latest edits made by others.
Delete downloaded maps and perform final reconcile and post process
The process described above continues through the one week time frame of the project. Once all sensors have been inspected, the project is complete. Field workers are asked at the end of the project to synchronize the last of their edits and remove the local map from Collector for ArcGIS. Once the local maps are removed from Collector, the field workers' versions are no longer associated with a downloaded map. The project manager then stops and deletes the feature service.
The project manager runs final reconcile and post processes on all the field workers' versions and deletes each of these versions. The project manager then reconciles and posts the Inspection version with Default. The project manager manually reviews and resolves conflicts during this process. When complete, the latest sensor inspection information is available to all in the Default version. The final step the project manager completes is to delete the Inspection version.
Workflow 3: Download maps for an ongoing project
This example workflow is similar to the previous workflow (Download maps for a short duration project) in that field workers synchronize edits they made while offline. They connect to the network and synchronize in the morning and at the end of the day. However, in this workflow, the project is ongoing so the feature service is published from a quality assurance version rather than directly from the Default version. That means additional review, reconcile, and post processes are required.
The following describes the steps needed to complete this workflow.
- Publish a feature service
- Create a web map
- Download the web map
- Synchronize edits
- Run nightly geodatabase processing
Publish feature service
For this project, the project manager plans to create and share a web map for sensor inspections in the company's organization account. The web map will reference a feature service running in the company's on-premises ArcGIS Server.
To create the feature service, the project manager starts ArcMap and adds the sensor feature class from the Default version of the source enterprise geodatabase. The feature class has been registered as versioned. The sensors that are flagged for inspection are colored yellow.
To organize the work, the project manager creates a version named Inspection and changes the map to reference this version.
Next, the project manager publishes an InspectionFS feature service from ArcMap.
The project manager checks the Sync capability in the Service Editor since the service is intended to be used in an offline map. The project manager also clicks Advanced Options to display Feature Service Advanced Options.
In Feature Service Advanced Options, the project manager chooses the Create a version for each user option. With this option, the first time a field worker downloads a map, a version is created for that worker. This version is then used when the worker synchronizes edits.
Create web map
Once the feature service has been published, the project manager creates a web map in the ArcGIS Enterprise portal and shares it with a group of which all the field workers are members.
The project manager performs these steps:
- Log in to the organization.
- Create a web map.
- Add the feature service from ArcGIS Server that he just published.
- Save the web map.
- Share the web map and the feature service with the group that includes the field workers.
- Enable the offline mode property on the web map to make it available for offline use in Collector for ArcGIS.
Download the web map
Each field worker accesses the web map by logging in to their accounts with Collector for ArcGIS.
With the web map available, each field worker starts Collector and logs in to the organization. The newly shared web map appears.
Since the web map has offline mode enabled, it appears in Collector with a download button (the cloud with an arrow). One of the field workers (Joe) clicks the download button to start the download process.
Joe chooses the extent and the base map resolution for his map.
When the download process starts, ArcGIS creates a version (Joe_InspectionFS) from the published version in the source geodatabase. Since the feature service was set to create a version for each user, the version name is based on the field worker's login (Joe) and the name of the service from which it was created (InspectionFS). This version will be used when the map is synchronized.
Note:
Any time Joe downloads a map from the InspectionFS service, it will reference the Joe_InspectionFS version. For example, at some point, he may need to remove the local map and re-create it with a larger extent. When he downloads the map again, Joe will see all the edits he had previously synchronized from the Joe_InspectionFS version.
Once the data and map are downloaded, Collector switches the map to reference the local data. At this point, Joe can edit the map without having to be on the network. A Sync button appears on the map in Collector to indicate that it is referencing the local data.
A second field worker (Mary) performs the same steps as Joe. This results in a Mary_InspectionFS version being created in the source geodatabase.
While Mary and Joe edit in the field, a new sensor is added to the Default geodatabase by an office worker. The new sensor is the result of a new project happening in the area. Whenever new sensors are installed, an inspection is required, thus it appears yellow.
Synchronize edits
While in the field, Joe is assigned work on the east side of the map. When Joe completes a sensor inspection, he marks the sensor feature's status appropriately. If the sensor passes inspection, it appears green. If it is damaged and requires repair, it appears red.
When he has connectivity at the end of the day, Joe clicks the Sync button on Collector. This applies the edits to the Joe_InspectionFS version in the source geodatabase.
At the end of the day, Mary also synchronizes her sensor inspections from the west side of the map.
Run nightly geodatabase processing
In the evening, an automatic process runs to reconcile and post the field workers edits. The process first reconciles and posts each field worker's version with the Inspection version. The process applies a conflict policy wherein the last edit in is preserved and conflict detection is attribute based.
When all edits from the field are applied in the Inspection version, validation scripts are run on the data in the Inspection version. These scripts look for and correct edits with invalid values or out of bounds features.
Note:
At this point in the process, the Mary_InspectionFS version has Joe's edits but the Joe_InspectionFS version does not have Mary's edits. This is because the Joe_InspectionFS version was reconciled and posted before the Mary_InspectionFS version.
The next step in the automatic process involves reconciling and posting the Inspection version with the Default version. The process uses attribute-based conflict detection and automatically resolves conflicts. The reconcile process brings the edits from Default (the new sensor) into the Inspection version, while the post process applies the edits from the Inspection version (Joe and Mary's edits) to the Default version.
Each field worker's version is reconciled a second time with the Inspection version to finish the automated process. Each field worker's version is now up to date.
Tip:
To get the latest changes to the fields workers, the reconcile process is needed but the post process is not required. Some organizations may run a separate process to post edits to the Default version since this makes the edits available to others outside the project.
The next morning when Joe and Mary synchronize, they see the updated sensors from the other field workers and the new sensor from the Default version. Since it is on the east side of the map, Joe will inspect the new sensor and synchronize the results. The next day, after the nightly processes are run, Joe's inspection information for the new sensor will be in the Default version.
This process repeats continuously on a day to day basis. The Joe_InspectionFS and Mary_InspectionFS versions remain as long as Joe and Mary continue to do sensor inspections. If at some point they stop working on the project, the versions can be removed once Joe and Mary have done a final synchronization, unregistered their local maps, and final reconcile and post processes have been performed on the Joe_InspectionFS and Mary_InspectionFS versions.