Editing Sandbox

[KurtRadamaker]

I'd like to create a environment were my end users can edit polygons in an arcpro sandbox and when the polygon shape and attributes look correct update PROD data.

I'm trying to avoid the users editing directly in prod, versioning has come up, but that seems more of a solution around multiple edits to the same data.

It seems like there are many ways to skin this cat, so I'm looking for advice on the most effective method.

[RolandDuhaime]

Hi Kurt,

We created a versioned database on ArcGIS Server, that connects to an ArcGIS Portal (Enterprise config).  We then ask our editors to zoom to their area and then use the "Download Map" option in Pro to take their edits offline, and, after editing, they can then "Sync" their edits to a version that is tied to their username.  When the editors tell me that the edits are complete, I can "Reconcile" and "Post" them to the "Edit" version of the geodatabase... when all data have been edited by all users, I can then post to default.  There is a level of trust that editors won't edit content outside their jurisdiction.  That is how we do it... and I am sure there are other ways... but this was going to take the least amount of admin.  I hope this helps you.

Best Wishes,

Roland

[DavidPike]

As in updates to a single feature class or continuous new feature classes being created and moving from test to prod? Feature classes/shapefiles or enterpise gdb feature classes? More info on your data model and intended uses would help.

You could just have prod edits with a field stating 'approved' or similar.  when features are checked, you update it to 'yes'.  Put a definition query on a any services running off that feature, so only approved features will be promoted.  Bit simplistic but it would work.

[KurtRadamaker]

Enterprise gdb, No new feature classes, just adds and edits to 5 existing FCs, only one of the FCs has frequent edits the other 4 only occasional edits

[KurtRadamaker]

What is happening now is polygons are given a system generated polygon ID and tied to pricing, so an edit can have a snowballing effect on prices. My techs are telling me that sometimes, the geometry in ESRI gets screwed up, so instead of editing the polygon geometry they have to delete a polygon and recreate it. This is where the problem starts, a new polygon that is actually an old polygon. I was hoping they could create the new polygon in a sandbox, then give it the old polygon ID and replace the old polygon in prod. When we create a new polygon in prod it generates a new polygon ID and pricing info in other systems, so creating a new polygon and changing the ID and deleting the original polygon is creating orphan pricing records tied to a deleted polygon.

[DavidPike]

I think the versioned workflow Roland described would be best.  It will be confusing at first, but as with most things it will become second nature.  As a side-note, if you're using ObjectID as a record ID field - I wouldn't.