Locking Geospatial Data?

606
3
Jump to solution
07-26-2019 02:45 PM
TristanHiggins
New Contributor

Is there a way to lock down geometry of individual feature classes? We have a process being established that requires certain features to have their positions approved before they can be appended to the record, so features are collected by field staff, sent in for approval, and then the geospatial data is appended during the approval process. Once it's in the official feature class, we want to be able to lock down those positions and the metadata so they can't be modified by anyone except the approvers.

Normally I'd say we could just set permissions as a whole, but we don't want to bottleneck the entire process by having the group that does the geospatial approval have to make changes to non-positional data.

A workflow looks like this:

1. Field worker goes and collects new features, following guidelines set by mapping group. At the same time, existing features may have attribute updates that aren't related to their positions.

2. Field data is sent in for approval with the mapping group. Mapping staff reviews GPS metadata, and either approves, rejects, or marks data for modification (such as reducing positional accuracy estimates within the attributes), and appends the record to the publishable feature class.

3. Other staff modifies, analyzes, or appends any other data within the features aside from geospatial data, and do not have the ability to relocate features, perform coordinate transformations, or modify metadata associated with the field positional data collection.

Hopefully this isn't as complicated as I fear; really we just want a way to mark positions as authoritative and prevent unauthorized or unintentional modification. Any thoughts?

0 Kudos
1 Solution

Accepted Solutions
LanceCole
MVP Regular Contributor

Tristan, 

There are several options available to prevent geometry modifications depending upon your workflow.  All of the solutions do require staging of your data to some degree.  For example, you could use AGOL to collect your raw field data then would need to pull that data into your enterprise environment for review and initial ending.  That data may need to be split into separate feature classes or tables for internal use or be republished to AGOL for external use.

1) The simplest solution is if you have an internal Portal hosted on a ArcGIS Server.  Feature services on ArcGIS servers have an option to “Allow Geometry Updates” which prevents geometry edits, if unchecked, but still allows other attribute edits.  Additional info is available at Editor permissions for feature services—Documentation | ArcGIS Enterprise .  You can still create new features but cannot move existing.  This would require a workflow where you would edit or approve your data in one process before migrating the data to this service as you cannot make changes.  There is a known bug with this option that is still under review by ESRI, BUG-000119726S 

Enterprise Portal

2) A similar option is available in AGOL for feature services.  In the feature service settings there are options as to what type of editing is allowed.  One of the options is to “Only update feature attributes”.  Unfortunately this prevents any editing of the feature geometry including adding new features.

AGOL Options

3) Another option, which we are currently using, is to split your feature geometry and attribute data.  We create a feature class that contains the geometry and any attributes that we do not want users to modify.  We also create a table in the database that is connected to the feature using a relationship class.  The permissions for these two items can be set independently through your enterprise geodatabase permissions.  Our GIS editors can have full rights to both items, whereas, GIS users can be prevented from editing the feature class but allowed to edit the table.

The down side to this is you cannot edit the table values from the feature class attribute table directly.  The table values will not even be displayed in the feature class attribute table.  To edit values you must use the attribute window and drill down to the related table record where they can be edited.  Note, you can have the table values displayed in the attribute table by also creating a join in ArcGIS linking the feature class to the underlying table.  However, these values will be read-only.  In Pro you can also use the view related data feature.

I am traveling this morning so I borrowed a few screen shots from other posts.  

View solution in original post

3 Replies
LanceCole
MVP Regular Contributor

Tristan, 

What platform are you using for the final data AGOL, Desktop, Pro, etc.?

What database are you using for final data storage fGDB, Enterprise, Data Store, etc.?

It is easy to lock down fields as read only but a little more difficult for geometry.  I have a couple of suggestions depending on the questions above.

0 Kudos
TristanHiggins
New Contributor

Lance Cole‌,

It will be on Pro and using Enterprise for data storage; at the moment it's in AGOL but we'll eventually migrate to only using AGOL for use by outside consultants or public viewing.

0 Kudos
LanceCole
MVP Regular Contributor

Tristan, 

There are several options available to prevent geometry modifications depending upon your workflow.  All of the solutions do require staging of your data to some degree.  For example, you could use AGOL to collect your raw field data then would need to pull that data into your enterprise environment for review and initial ending.  That data may need to be split into separate feature classes or tables for internal use or be republished to AGOL for external use.

1) The simplest solution is if you have an internal Portal hosted on a ArcGIS Server.  Feature services on ArcGIS servers have an option to “Allow Geometry Updates” which prevents geometry edits, if unchecked, but still allows other attribute edits.  Additional info is available at Editor permissions for feature services—Documentation | ArcGIS Enterprise .  You can still create new features but cannot move existing.  This would require a workflow where you would edit or approve your data in one process before migrating the data to this service as you cannot make changes.  There is a known bug with this option that is still under review by ESRI, BUG-000119726S 

Enterprise Portal

2) A similar option is available in AGOL for feature services.  In the feature service settings there are options as to what type of editing is allowed.  One of the options is to “Only update feature attributes”.  Unfortunately this prevents any editing of the feature geometry including adding new features.

AGOL Options

3) Another option, which we are currently using, is to split your feature geometry and attribute data.  We create a feature class that contains the geometry and any attributes that we do not want users to modify.  We also create a table in the database that is connected to the feature using a relationship class.  The permissions for these two items can be set independently through your enterprise geodatabase permissions.  Our GIS editors can have full rights to both items, whereas, GIS users can be prevented from editing the feature class but allowed to edit the table.

The down side to this is you cannot edit the table values from the feature class attribute table directly.  The table values will not even be displayed in the feature class attribute table.  To edit values you must use the attribute window and drill down to the related table record where they can be edited.  Note, you can have the table values displayed in the attribute table by also creating a join in ArcGIS linking the feature class to the underlying table.  However, these values will be read-only.  In Pro you can also use the view related data feature.

I am traveling this morning so I borrowed a few screen shots from other posts.