Publishing GIS Service > Service Types > Feature Service > Online Editing > SuperGIS Server Online Editing

SuperGIS Server Online Editing Workflow

Feature Service can be published in SuperGIS Server, which allows users to real-time edit the editable service layers in front-end applications, including adding, deleting and modifying features. To front-end users, SuperGIS Server online editing can be described in some steps. Firstly, the front-end users have to install the client end application that supports (SuperGIS Desktop or SuperPad), and then connect to server and download the Feature Service by entering account and passwords in client-end application. After that, the front-end users could real-time edit the Feature Service through the editability in client-end application. The last step, when the feature editing is finished, Feature Service update must be done so the full online editing workflow is implemented.

Workflow for online editing Feature Service:

1.	Front-end users connect to server to get the Feature Service through the client end application;

2.	Front-end users activate the online editing service;

3.	Front-end users update Feature Service.

Versioning mechanism is applied to Feature Services published by SuperGIS Server. For example, each Feature Service is given with a belonging Service Version by SuperGIS Server, and each feature of the layers contained will generate the identical Feature Version; as a result, as a Feature Service is published, its Service Version and Feature Version should be identical. After that, whenever front-end users update service, the Service Version of Feature Service will automatically add one. If some of the features are updated along with service, their Feature Version will also be set the same as the latest Service Version; while those not updated will remain. With such mechanism multi-user online editing in SuperGIS Server can be supported through identifying different Service Version and Feature Version.

Take the figure below for example. Assumed that a Feature Service with five features is published, by then both the Service Version and Feature Version should be V1.0. See step 2, feature 1 is being edited and service is updated after, as a result, the Service Version adds one, becoming V2.0, and the Feature Version of feature 1 becomes V2.0; while the rest of the unedited features have their Feature Version remained. See step 3, feature 3 is being edited and service is updated after, so the Service Version and the Feature Version of feature 3 have been changed to V3.0 accordingly. See step 4 and 5, they respectively edit feature 1 and 5; after updating, their Service Versions respectively become V4.0 and V5.0 and their Feature Versions turn into V4.0 and V5.0 accordingly.

Let's take another example, the same, assumed that a Feature Service with five features is published, by then its Service Version and Feature Version should be V1.0. See step 2, the user updates service after a feature is added, so the Service Version and Feature Version of the newly-added feature 6 become V2.0; while the rest unedited features remain V1.0. See step 3, the user updates service after another feature is added; therefore, the Service Version and Feature Version of the newly-added feature 7 become V3.0. See step 4, the user updates service after feature 1 is being deleted; in that case, only Service Version adds one, becoming V4.0. See step 5, the user updates service after feature 8 is added, by then the Service Version and Feature Version become V5.0, while the rest features which are not edited remain the same.

From the two examples above we learn that Service Version should always be higher or equal to the Feature Version of the features contained. In addition, since each feature is an independent unit, if there are multiple users editing the identical Feature Service at once, the data will not be influenced as long as the features in editing are different.