multiple editors in utility network

489
10
Jump to solution
02-13-2024 04:35 PM
joecastellana
New Contributor II

Hello (again) all,

After some advice around managing multiple editors in a branch version utility network model.

Each editor will have various jobs (varying time and complexity) to complete each day. All edits are made in their branch version and each editor manages posting their edits to default (validate/reconcile/post/etc).

Is there any "best practice" advice regarding the posting process?

We currently use a massaging chat group where each user will message when they are posting and when done, but this is not 100% reliable and could result in an editor waiting 10-20min for another editor to complete their work. Also we see instances of dirty areas being assigned to editors that were not working on those features which can cause some confusion - Im thinking this is related to having several users in default simultaneously.

Has anyone seen/used a process that is a bit more robust? I have thought about a single user posting edits done by others (so that user would have access to all branch version), or allocating certain times of the day where each user can post. Any advice appreciated.

tia

1 Solution

Accepted Solutions
RobertKrisher
Esri Regular Contributor

@joecastellana When editing directly in default no posting or starting/stopping editing is required. All edits are directly and irreversibly applied to default, so use with care.

I've seen many organizations successfully use third-party messaging services or apps to coordinate work, but I think you should check out this presentation from IMGIS where Houston Water demonstrates their editing workflow and how they manage it using ArcGIS Workflow Manager. I'm always a sucker for a good dashboard but having real-time access to the status of every job in the GIS and knowing it's actually linked to the workflows we use for managing our versions is pretty sweet.

The version management link provided by @MarceloMarques does a good job of explaining all the most popular workflows, but as @ClaudzPora noted they misspoke when they said you could create a 2-tiered version system. Everything needs to be 1 version off of default. If you do want to try and enforce a single editor, you'd need to protect default and have the workflow be that only one or two people are allowed to post to default (i.e. have the version administrator role). This way all edits are required to flow through your posters.

I'd like to know a little more about your statement "Also we see instances of dirty areas being assigned to editors that were not working on those features which can cause some confusion", can you elaborate?

View solution in original post

10 Replies
MarceloMarques
Esri Regular Contributor

@joecastellana 

For example, in traditional versioning, the sde.default can be protected, and you can create a QA/QC version child of sde.default, all the other editors will create child versions of the QA/QC version and post / reconcile to the QA/QC version, then the GIS Admin will do quality control in the QA/QC version and reconcile/post the QA/QC version to the sde.default version. 

You can read more about branch versioning strategies in the link below.

Branch version only supports 2 tiers, the sde.default version and a child version of sde.default, we cannot create child version of child version in Branch Versioning.

Branch version scenarios—ArcGIS Pro | Documentation

You can also automate the entire editing workflow process and versioning management (branch and traditional) with ArcGIS Workflow Manager.

An introduction to ArcGIS Workflow Manager—ArcGIS Pro | Documentation

I hope this helps.

| Marcelo Marques | Principal Product Engineer | Esri |
| Cloud & Database Administrator | OCP - Oracle Certified Professional |
I work with Enterprise Geodatabases since 1997.
“ I do not fear computers. I fear the lack of them." Isaac Isimov
0 Kudos
joecastellana
New Contributor II

Thanks Marcelo, the version scenarios link is very helpful. It clearly states multiple simultaneous edits in default are allowed, but doesnt talk about the posting step. 

And Ive heard of workflow manager so am interested to read up on that as well. 

Cheers.

0 Kudos
MarceloMarques
Esri Regular Contributor

adding this documentation link about Branch Version Reconcile and Post.

Reconcile and post edits to a branch version—ArcGIS Pro | Documentation

| Marcelo Marques | Principal Product Engineer | Esri |
| Cloud & Database Administrator | OCP - Oracle Certified Professional |
I work with Enterprise Geodatabases since 1997.
“ I do not fear computers. I fear the lack of them." Isaac Isimov
0 Kudos
ClaudzPora
New Contributor

Hello @MarceloMarques ,

Please correct me if I am wrong, but my understanding is that Branch versioning only allows for a two tier / level for version management, meaning Default (parent) and Edit Versions (Child / Children directly under Default). 

Whereas the Traditional Versioning method allows for more than 2 tiers / levels to be setup for version management, such as the scenario you described. 

Seeing as this is a Utility Network, the Branch Versioning methodology would be relevant. 

Please could you provide clarity on this. 

Thank you. 

0 Kudos
RobertKrisher
Esri Regular Contributor

@joecastellana When editing directly in default no posting or starting/stopping editing is required. All edits are directly and irreversibly applied to default, so use with care.

I've seen many organizations successfully use third-party messaging services or apps to coordinate work, but I think you should check out this presentation from IMGIS where Houston Water demonstrates their editing workflow and how they manage it using ArcGIS Workflow Manager. I'm always a sucker for a good dashboard but having real-time access to the status of every job in the GIS and knowing it's actually linked to the workflows we use for managing our versions is pretty sweet.

The version management link provided by @MarceloMarques does a good job of explaining all the most popular workflows, but as @ClaudzPora noted they misspoke when they said you could create a 2-tiered version system. Everything needs to be 1 version off of default. If you do want to try and enforce a single editor, you'd need to protect default and have the workflow be that only one or two people are allowed to post to default (i.e. have the version administrator role). This way all edits are required to flow through your posters.

I'd like to know a little more about your statement "Also we see instances of dirty areas being assigned to editors that were not working on those features which can cause some confusion", can you elaborate?

joecastellana
New Contributor II

Hi Robert, thanks for the detailed reply. 

To explain my comment above regarding dirty areas, basically I can work in my editing version on a set of features, reconcile/post and go to default. Then when I review the dirty area table I can see my name in the creator field for edits I did not make. 
I am guessing it is due to timing where another user may be in default with some dirty areas active when I reconcile. So I am effectively bringing those dirty areas into my version and posting them back to default. Does that sound like what may be happening?
I dont have direct evidence of this but just my assumption at this point.

0 Kudos
RobertKrisher
Esri Regular Contributor

@joecastellana I recommend you ignore the editor tracking on dirty areas, and here's why: When you reconcile your version, we re-create dirty areas for all the features that were edited in this version. This is so that when the edits are posted to sde.default we can update the network topology (using validate) where the network was edited in the version. This means that the dirty area will show the name of the user who reconciled the version, which may be different than the person who made the original edit.

MarceloMarques
Esri Regular Contributor

@ClaudzPora 

Indeed, Branch Versioning only supports 2 tiers, the sde.default version and only a child version of sde.default, we cannot create child versions of child versions in Branch Versioning.

The example I provided above was for traditional versioning, where we could create child versions ad deep as we need, in that scenario we could set sde.default as protect, create a QA/QC version from the sde.default and then create all the editing versions as child of the QA/QC version. But this only works with traditional versioning.

You can use ArcGIS Workflow Manager to automate your editing workflows and versioning management for both versioning types, Branch Versioning and Traditional Versioning.

I hope this clarifies.

| Marcelo Marques | Principal Product Engineer | Esri |
| Cloud & Database Administrator | OCP - Oracle Certified Professional |
I work with Enterprise Geodatabases since 1997.
“ I do not fear computers. I fear the lack of them." Isaac Isimov
MarceloMarques
Esri Regular Contributor

@ClaudzPora

"Also we see instances of dirty areas being assigned to editors that were not working on those features which can cause some confusion".

Depending on how you are editing the data and creating the child versions of sde.default and allowing users to edit both, the child version and the sde.default at the same time, and then reconcile and post the changes, then after topology validation more dirty areas might show up even if the person has not even edited the feature in the child version or in the sde.default version. I'd say this is expected to happen. But if you adopt some of the branch versioning strategies, like not allowing edits directly in the sde.default version, then you can minimize this effect and if you introduce ArcGIS Workflow Manager to help orchestrate the editing workflows and to help manage the branch versions then you can further mitigate the effects of topology validation and dirty areas.

Please see this blog post article Dirty area management with the utility network (esri.com)

| Marcelo Marques | Principal Product Engineer | Esri |
| Cloud & Database Administrator | OCP - Oracle Certified Professional |
I work with Enterprise Geodatabases since 1997.
“ I do not fear computers. I fear the lack of them." Isaac Isimov