Editing Feature Services

[TedCronin]

So, I don't think I have asked this, yet, and perhaps it does not belong here in this thread, but how does the new editing work for layers/tables as part of the feature service.  Is this handled on the default version, or are we to create services from versions?  Sorry if I sound a bit ignorant.

[RaviNarayanan]

At beta 1, the requirement is that the dataset needs to be registered as versioned and default version can be published for editing. At beta 2, editing will be supported for both versioned and non-versioned data.

Thanks
Ravi

[TedCronin]

At beta 1, the requirement is that the dataset needs to be registered as versioned and default version can be published for editing. At beta 2, editing will be supported for both versioned and non-versioned data.

Thanks
Ravi

So, there will be no support for versions other than default (Would be nice to drive version creation in rest/api, thus edit other versions).  For beta 2, it seems like this is a bit limiting, in that we either use version editing  or non version editing, but not both, right?  We can't have a database that can handle both versioned and non versioned editing, it would have to be either or, such as we are editing Parcels via ArcMap, but the Assessor Tables as part of a CAMA/Property Tax System, could not be stored as part of the GDB and edited via feature access via rest server.

Just some thoughts.

[RaviNarayanan]

So, there will be no support for versions other than default (Would be nice to drive version creation in rest/api, thus edit other versions). 

Feature service can be used to edit default or other versions of the dataset. The choice of version should be made when authoring the map that will be published for editing.

For beta 2, it seems like this is a bit limiting, in that we either use version editing  or non version editing, but not both, right? 

Can you please explain further on what you mean here? My understanding is that you can register a dataset as versioned or not register a dataset as versioned and feature service can be used for editing dataset in both cases.

[TedCronin]

Feature service can be used to edit default or other versions of the dataset. The choice of version should be made when authoring the map that will be published for editing.

Can you please explain further on what you mean here? My understanding is that you can register a dataset as versioned or not register a dataset as versioned and feature service can be used for editing dataset in both cases.

It just would be nice to not have to generate a mxd each time for each version, so we would have 10 versions with 10 services. 

Yes, that is what i am saying.  If I have a GDB that is versioned, I would also, like to store date that can be edited via non versioned in the same database that may be setup via a relationship class with the versioned  layer(s), maybe I am missing something, but I have always had issues when blending these two ways for editing data in the same database.

[RichardWatson]

I understand that the workflow is to create a map document, which uses the correct SDE version, and then publish the map document as a service.  Users then connect to that service and use it as needed.

What if have a web service which supports creating a new version?  Let's say that I want users in the field to submit potential changes which have to be reviewed/moderated.  In this case, each user would have their own SDE version.

In this case you can either:

1) Have your web service create a new SDE version, create a map document which uses this version, publish the map document as a service, and then finally use that service.  Of course, you also have to worry about ending the service at some point.

2) Create a generic non-pooled service and have it create and utilize a new SDE version.

How does ESRI see this working with the push to have a large number of "volunteer" editors on the web?

[JessicaParteno]

  If I have a GDB that is versioned, I would also, like to store date that can be edited via non versioned in the same database that may be setup via a relationship class with the versioned  layer(s), maybe I am missing something, but I have always had issues when blending these two ways for editing data in the same database.

Hi Ted,

Having versioned and non-versioned data in the same Geodatabase is supported and it is also supported in feature services. When you have a feature service with versioned and non-versioned data, both type of layers can be queried and edited through the service. The main difference will be in the QA QC of the edits in the Geodatabase.

As far as using a relationship class to related versioned and non-versioned data, this can be done in the Geodatabase but only with Simple relationship classes because Composite relationship classes propagate the version type to both the origin and destination objects. If you want to use a relationship class between versioned and non-versioned data it is important to note that both the origin and destination in the relationship class have to be registered with the geodatabase. It is also important to note that if the destination in the relationship class is not versioned, when features are deleted in the origin the foreign key values will be set to Null in the destination. During the reconciling and posting of the versioned feature class if you decide to restore the deleted features, the foreign keys will not be set back to the original foreign key value, this will have to be done manually.

Hope this helps,

Jessie

[JessicaParteno]

What if have a web service which supports creating a new version?  Let's say that I want users in the field to submit potential changes which have to be reviewed/moderated.  In this case, each user would have their own SDE version.

Hi,

Feature services were designed to support one version per service. This workflow allows the author of the service to control which version is exposed through the feature service. If you want to publish multiple versions of the same data, a separate feature service will have to be created for each version. The ability to create new versions through the feature service is not currently supported.

The advantage to this workflow is that it prevents end users from selecting the wrong version  and it also prevents the end users from creating hundreds of versions that can be very difficult to manage. If you are using versioned data in your feature service you can use QA QC and then reconcile and post the selected edits from the version publish in the feature service to control which edits are maintained in the Geodatabase.

Hope this helps,

Jessie

[RichardWatson]

Thanks for the response Jessie.  I appreciate it and believe that I understood what you said.

That said, I am concerned with how well this approach fits the problem that I have.

Let's say that we are talking about a utility company here which is deploying crews to worksites.  When the crew gets to the worksite they want to correct information which is presented to them via the web (ArcGIS Server services).  So... what they do is to edit the features and correct them as needed.  Once the features are corrected then they are submitted and there is some review process (QA QC) which takes place.  If the changes are good then they are reconciled and posted by the reviewer and if not then the crew is informed of the problems/issues and asked to correct the same and resumit them.

The issue here is that there are a large number of crews in the field.  So... one approach is to create a single SDE version and publish it out for all crews.  If we do that then the crews will see the unapproved work of other crews.  Is that correct?

The only alternative is to publish out an SDE version for each crew.  I understand that the feature service does not support this but I suspect that I could programmatically accomplish the same.  I would simply replicate what ArcCatalog and ArcGIS Server Manager do in order to create and publish services.

Am I going off in the weeds here?  I really want the best solution for the customer which also fits well with the design of ArcGIS Server.

[RichardWatson]

Look at the "Inside the API" \ Editing topic in the ArcGIS JavaScript API under the paragraph "Citized participation, or geo-wiki".

Here is quote from that paragraph:

"In this type of application, you may have to code some security checks to ensure that users can only edit or delete their own incidents. You may also include logic to periodically clean out the database, or allow a subset of authenticated users to close or delete incidents."

What I conclude from this, and the previous discussion, is that the built-in functionality is not designed to accomodate a workflow which uses SDE versions in order to isolate the changes made by one user from another user.  Certainly ArcMap provides this but ArcGIS Server does not.

Please correct me if I am wrong because I really want to understand.  It appears to me that there no built-in provision for isolating changes made by various users.