Export and synchronize vector data

ChristineBrunner

<\/HEAD>

The product family of the ArcGIS Runtime SDKs<\/A> has been offline-capable since version 10.2. Background maps and vector data can be exported from services, and in the case of vector data, also synchronized. To illustrate these functions, Esri Germany has developed a demo application that replicates the offline functionality of Collector for ArcGIS<\/A> with the ArcGIS Runtime SDK for .NET<\/A> and Java<\/A>. This demo is called Collector Light and is published on GitHub<\/A>. Additionally, a blog<\/A> has already been published about it.<\/SPAN><\/P>

In this article, using the example of the Java demo, the process of exporting and synchronizing vector data will now be examined in more detail.<\/SPAN><\/P>

<\/H2>A few preparations are necessary<\/SPAN><\/H2>The demo uses a <\/SPAN>WebMap<\/A><\/SPAN> as a data source. However, this is not strictly necessary. To export vector data, only a FeatureService is required. This can be hosted on ArcGIS Online<\/A>, in Portal for ArcGIS<\/A>, or on your own ArcGIS for Server<\/A>. It should be noted that the "Synchronize" operation is enabled in the service. On ArcGIS for Server, this can be done in the ArcGIS Server Manager under Functions -> Feature Access for the respective service.<\/SPAN><\/SPAN><\/P>

<\/P>

In ArcGIS Online and Portal for ArcGIS in the properties of the service.<\/SPAN><\/P><\/SPAN><\/P>When this function is enabled, the service offers additional REST interfaces. Using the "Create Replica" operation, data can be fetched offline. "Synchronize Replica" is for synchronizing data and with "Unregister Replica", data can be deleted. More on this later.<\/SPAN><\/P><\/P>

<\/> Now finally programming begins<\/><\/> We do not have to implement these REST interfaces directly. They are already encapsulated by the ArcGIS Runtime SDK for Java so that we have Java classes and methods available for this purpose. The usage for exporting vector data can be found in the demo in the class action.CreateOfflineProject. More precisely in the method createGeodatabaseFromService. <\/><\/> After a small preparation of the data due to using a WebMap, the exciting part begins at line 330 with creating the GenerateGeodatabaseParameters<\/>. <\/><\/> //set up the parameters
  GenerateGeodatabaseParameters params = new GenerateGeodatabaseParameters(
       ArrayUtils.toPrimitive(layerIds.toArray(new Integer[layerIds.size()])),
       extent,
       map.getSpatialReference(),
       false, 
       SyncModel.GEODATABASE,
       map.getSpatialReference());<\/> Here it shows that you can limit the data to be exported. On one hand there is the possibility to select individual layers of the service. On the other hand an extent can be specified so that the area is limited. Attachments can also be loaded but do not have to be. It is also important to provide a desired coordinate system as a parameter so that the data can later be displayed correctly on our map. Then two callback classes are needed. One is used to receive status information during runtime. The other is called when the task is finished and finally receives the result. Now comes into play the class GeodatabaseSyncTask<\/> which makes the actual call generateGeodatabase. ............................

// ------------------------------------------------------------------------
// Generate the geodatabase from the service and download
// ------------------------------------------------------------------------
GeodatabaseSyncTask gdbTask = new GeodatabaseSyncTask(featureServiceUrl, PortalConnector.getUser(true));
gdbTask.generateGeodatabase(params, pathToGdb, false, statusCallback, gdbResponseCallback);

To create this class you only need the URL to the FeatureService. If it is a secured service you must also pass credentials as in this example. Details on authorization and authentication are available in a separate blog.

Where are my data now?

In gdbResponseCallback in this example only a ProjectManager is informed that new data are available. So now comes the question: Where are my data? We find them under the path and name passed as parameter (pathToGdb) during call. The name gets appended with .geodatabase extension. The data are stored in a database structure more precisely an SQLite format and can be viewed with any common SQLite tool.

How do I get my data into my map?

But we want to view the data in our map and not in some other tool. For this purpose ArcGIS Runtime SDK for Java offers the class FeatureLayer. This can be created based on various data sources which is nice about this class. Regardless of data source handling is always the same. One of these data sources is GeodatabaseFeatureTable. We access these tables by our SQLite Initialize database using the class Geodatabse. For each individual layer, a GeodatabseFeatureTable is created.<\/SPAN><\/P><\/P>Geodatabase localGeodatabase = new Geodatabase("PathToGeodatabase");
  for (GeodatabaseFeatureTable table : localGeodatabase.getGeodatabaseTables()) {
  FeatureLayer featureLayer = new FeatureLayer(table);
  featureLayer.initializeAsync();
}<\/PRE><\/P>I want to call home again<\/SPAN><\/H2>So, now the data is offline. We can now move freely, far from digital civilization, and capture, change or delete data. But eventually the moment will come when we want to share our changes with our colleagues. Also, I might be interested in what they have been up to in my absence. So we need to contact the mothership (the FeatureService). In the demo, this happens in the class action.SyncProject. The method syncGeodatabase in the already known class GeodatabaseSyncTask helps us with this.<\/SPAN><\/P><\/P>gdbTask.syncGeodatabase(syncParams, gdb, statusCallback, syncResponseCallback);<\/PRE><\/P>We again see the two callbacks for status messages and for the result. As further parameters we need the Geodatabase (gdb) and special SyncGeodatabaseParameters. We have already created the Geodatabase in the previous step for visualizing the data. And we don't have to worry about the SyncParameters either because they are generated by the Geodatabase.<\/SPAN><\/P><\/P>final SyncGeodatabaseParameters syncParams = gdb.getSyncParameters();<\/PRE><\/P>The advantage is that we do not need to know the complex database structure to extract our changes. Because only the delta is always transferred, not the complete database. During synchronization, all changes on the service are also transferred to my local database so that I can continue working up to date. Here too only the delta is transferred. This is also visible in the following graphic which schematically shows the entire workflow.<\/SPAN><\/P><\/P><\/P>If several colleagues have made changes to a record, the last change always wins. Whereby the timestamp of synchronization counts and not the timestamp of the change. In future there should also be other options for resolving conflicts that can then be set per service. Currently this is not yet possible.<\/SPAN><\/P><\/H2>Let's end the hermit life<\/SPAN><\/H2>Eventually one hopefully returns to the office and no longer needs the local copy of the data. Then it is important not to simply delete it but first to unregister at the service. Of course we have again available for this purpose the class GeodatabaseSyncTask, this time with the method unregisterGeodatabase.<\/SPAN><\/P><\/P>gdbTask.unregisterGeodatabase(gdb, unregisterCallback);<\/SPAN><\/PRE><\/P>In the demo you can find this call in the class action.DeleteProject. But why is this call so important? The FeatureService creates a so-called Replica for each copy. It contains information about the copy such as the time of last synchronization. This data is needed to manage the synchronization mechanism. During unregister this Replica is deleted because then the service knows that the local copy is no longer needed. You can also view a service's replicas in its Service Directory.<\/SPAN><\/P><\/P><\/P><\/BODY><\/HTML>