We are currently working on a mobile app with offline geodata editing capability. The idea, of course, is: Users collect and edit data in the field and synchronise changes back into a central database when they return to their offices. The ArcGIS platform provides all the tools to easily implement that functionality. The necessary configuration is described in this tutorial. However, if you use your own app instead of Esri’s Collector app, you have to consider a few additional points. You could find out about these on help sites. But to keep you from searching too long I’ll share them in this post.
Challenges … – and a solution
We basically had two challenges to solve:
- How do we bring the edits that were made outdoors back into the DEFAULT version of the database?
- How do we get rid of all the (in this context: superfluous) versions the offline sync creates?
A look behind the scenes is helpful to understand what’s going on: For offline synchronisation in the Esri ecosystem you first need an enterprise geodatabase. The feature classes can either be versioned, or non-versioned with archiving activated. In our multi-user environment the second option was not viable, thus we had to go with versioning. You can find more information about setting up your environment here.
When a user then downloads data from a feature service, the following happens: The database creates a new version that is derived from the DEFAULT version. This new version gets a name like username_ID (for example Esri_Anonymous_i_1466000080844 if your map service is not secured). ArcGIS then creates a replica based on this version. This is a file geodatabase that is stored on the mobile device. One more important detail: In the database the replica is a child version of the originating version. This „hidden version“ is invisible with the normal ArcGIS tools. You can only see it in the SDE.VERSIONS table where it appears with a name like „SYNC_“.
After offline editing the user starts the synchronization process. However, this does not yet bring your edits back to the DEFAULT version of the database. Synchronize only reconciles the data between the replica and the originating version. Afterwards you need to use the Reconcile Versions tool to finally see your edits in the DEFAULT version and hence your map service. In order to streamline this process, for our application we created a geoprocessing service based on the Reconcile Versions tool which the mobile app calls after synchronization is complete (see also this help page).
Addendum for maintaining performance
The above process works fine. But there is, as you may know, one flaw: The database versions don’t automatically disappear but keep piling up. This can become a problem, when the version tree is big – which makes database compression inefficient. In the end (certainly in our project with several hundred versions), you can end up with an incredibly slow database. So let’s get rid of those unnecessary versions as soon as possible!
The Reconcile Versions tool has an option to delete version afterwards. Unfortunately, the tool fails consistently with the error message „Error deleting version […] Operation not allowed on a version with dependent children“. But there are no child versions visible in ArcGIS. So what gives? Of course, the problem arises from the „hidden versions“ of the replicas that keep us from deleting their parent versions. And how do we eliminate those? First of all, by unregistering the replicas using the REST interface of ArcGIS Server. But in our case it turned out that this was not enough: Somehow we have some „SYNC_“ versions that do not have a replica registered on ArcGIS server. Where these come from I am not entirely sure. Maybe they are created when a user aborts the data download from the map service? In any case, you can remove those versions using the Delete Version tool – although they are not visible in ArcGIS Desktop. You just need to find the version names using either arcpy.da.ListVersions or a query on SDE.VERSIONS.
The overall workflow in the end looks like this:
While the ArcGIS platform provides a great ecosystem, there are some murky corners where things can become convoluted – as in every GIS ecosystem, let’s face it. I hope these tips help you better understand offline editing and synchronization. If not or if you have an even trickier problem to solve, my colleagues and I are happy to take your questions, or hear your experiences.