Where is Remove Duplicate Centerline Geometry in your process?

04-02-2020 08:13 AM
Labels (3)
New Contributor II

Hello all,

We are working towards more automated maintenance of our R&H geodatabases.   This maintenance is necessary to support weekend processes that will rely on the Calculate Route Concurrencies GP tool.   

The one tool that is not available as a GP tool and therefore can not be scripted is the Remove Centerline Geometry Duplication tool.   (I'm assuming the new ArcGIS Pro Remove Overlapping Centerline tool can not be run against a 10.7.1 R&H geodatabase that is edited using Desktop)   As a result, we have only been running Remove Centerline Geometry Duplication on an as needed basis up until this point.   To support our AgileAssets integration and other downstream publishing, we need to incorporate this process in a weekly workflow.   LRS network editors complete the prerequisite centerline clean up to eliminate centerlines with a Null value for the ROADWAY_GUID:

(Remove Duplicate Centerlines error on ArcGIS 10.5.1 )

Those edits need to be reconciled and posted across all versions including Default (which requires geodatabase administrator privileges) in our environment before Remove Centerline Geometry Duplication will run successfully.  Currrently, we only post changes to Default outside of business hours so we are trying to figure out if there is a way to make all this work without relying on human intervention afterhours.

If you that have a business process in place that is working in your agency, I would be grateful if you could share it here. 

Thanks, Kevin


10 Replies
Regular Contributor


NCDOT has run that tool only a handful of times in lower arcmap versions. What I have found is that while I am running the tool to fix one set of known issues it touched other centerline records I had not known about since the tool runs statewide. That's not to say it those change where wrong but just additional issues that I was not aware of and making the cleanup a more difficult process.The last time I tried, I stopped and looked for a different workaround for the route fixes needed because those additional changes. The 10.5 tool version and the condition of some routes lead to event data being shifted and clean up work that needed be done. For us at the end of the day, there was more cons then pros to running the tool. You should be able to run the tool in a version to see what the impact will beforehand. We would run this tool at a scheduled quarterly freeze where we go to state zero in the database to get around the issues your talking about. 

One of the things Nathan has talked about for Pro is the tool can be run on a selection set and not statewide. That will one day give us more flexibility and be able to run more often.

Esri Contributor

A note about the comments regarding removing centerline geometry duplication in Roads and Highways as it relates to route concurrency (overlapping route geometry) and route dominanceAlthough my reply does not necessarily address the original GeoNet question, I do want to bring to the community’s attention the relative importance in de-duplicating centerlines in Roads and Highways for ALRS networks where route dominance is configured. For this example, I present to you four routes where the concurrency rules are set such that the greater, alphanumeric Route ID is the dominance rule.

Example 1: Routes “zRoad” and “aRoad” are concurrent. Each route has its own centerlines and those centerlines overlap in the highlighted region below (not de-duplicated):

Here is the corresponding centerline sequence table for Example 1:

Example 2: Routes “xRoad” and “bRoad” are concurrent. Each route shares the middle centerline where they overlap in the highlighted region below (de-duplicated):

Here is the corresponding centerline sequence table for Example 2. Note the yellow highlighted records represent the concurrent centerline segment:

Now, suppose we need to run the Calculate Route Concurrencies GP tool to calculate and report the concurrent route segments within the LRS Network and determine what routes are dominant for a given section of roadway. Here is what the output of the GP tool should look like for Example 2:

In this example, the GP tool traverses the centerline sequence table to determine routes in networks that share centerline sections and based on the configured network concurrency rules determines what the dominant route is along the concurrent section (re: DominantFlag). However, without de-duplicating centerlines for Example 1, the output result from the geoprocessing produces an empty recordset:

Finally, running the Remove Centerline Geometry Duplication utility on the ALRS and then re-running Calculate Route Concurrencies GP yields this result for Example 1 and Example 2:

The moral of the story here is that no matter why or when you introduced centerline geometry duplication into your ALRS, if you have overlapping/concurrent route definitions you really need to be cognizant that route dominance depends of keeping your centerline sequence table nice and tidy. Hope that helps!


roads and highways team

New Contributor II


Thank you for your experience.  We are still at 10.5.1 for a bit longer in New York and your note about RDCG impacting event data on certain route configurations is a bit unsettling.  During testing last year, we found data issues on the Agile side of the Agile/R&H interface before we started running RDCG ahead of running the interface.  Our project team just completed the AgileAssets upgrade to 7.3.6 which will allow us to begin running the interface in production after a long hiatus and this one of the reasons why we are looking at running RDCG more often.   You mentioned that you would run RDCG during your quarterly freeze period.   Does that mean you update the network in Agile with the Agile / R&H interface on a quarterly basis following the quarterly R&H freeze?


I appreciate your examples that shed light on how duplicate centerline geometry will introduce issues for the Calculate Route Concurrencies GP tool.   The community is relying more and more on the Calculate Route Concurrencies for business needs related to route dominance.  Coming back to the original question - I can not remember if there was a technical reason RDCG could not be packaged as a GP tool for Desktop?   Would be much more practical to use it routinely.

Your comment about keeping a tidy Centerline table raised another question.  We have a handful of "orphaned" Centerlines that have Roadway_GUIDs that are no longer found in the Centerline_Sequence table.  Would these features have any impact on RDCG or other undesirable effect? 

Thank you

0 Kudos
Regular Contributor


We have a had a quarterly freeze in place for over a decade. This allows our Pavement folks a chance to update the Agile system. It does not always happened. I believe they just finished the update with 1st Qtr 2020 data but aren't not going to do sync with 2nd Qtr 2020 data. If we had to run RDCG it would be after the editors freeze and before we sync with Agile.

In the method you are proposing, how you do handle locks (route or event) that an editor might have overnight on a route that they are changing data and RDCG would be changing? I could see running RDCG in a throw away version, analysis routes touched and lock those route affect in another version that you would run RDCG overnight in to prevent but there is always a chance that things don't line up perfectly. 

I wouldn't think you would have to run RDCG more then a few times a year. In our system we would install data reviewer checks and provide more training to the offending editor/s to prevent bad data being posted. It is far better to delete the version and lose work then post and have to fix the error later if it is even possible with all the different downstream impacts. 

Where it is - it is at the hands of the route editors to run that tool after doing route edits in the version workflow.  There is some aftermath to using it, you just have to absorb that aftermath or clean it up.  The best we can do is to have that run on the lockroot version and post it to default by the route editor after performing the route edits.  We would all much prefer and look forward to a geoprocessing tool.

now that there are pro environments with geoprocessing tools I've been playing with fire and cross versioning databases and tools to figure things out in pro.  Esri support has let me know the back end architectures are different and there's a good chance some things wont work or be supported doing that, but you could try to use that pro tool on a 10.7.1 database or earlier, it might work.  

0 Kudos
New Contributor II

Ryan, Kyle, 

Thank you for your responses.   We probably have not watched the results of Remove Duplicate Centerline Geometry as closely as you have and I'm concerned about the issues you raise.  You raised some additonal questions.

  1. Could you expand on the behavior that you have seen?  Particularly with events?  How did you identify these problems?
  2. Are there known conditions that cause the problems that need to be cleaned up following a run of the RDCG tool?
  3. If you are cleaning up What is the clean up process?   
  4. Is there a safe time to run RDCG  (eg. when there are no editors, no locks, and/or geodatabase is at state 0)?
  5. Are you using Data Reviewer checks to identify and revome duplicate centerlines in the edit process as an alternative to running the RDCG tool?   What checks are you using?
0 Kudos

1.  we see undesired segmentation in the primary routes process when this tool fails.  Amit describes it perfectly in his post.  In our system, we encounter his Example #2 - we can find it when we run route concurrency and inspect that table for overlaps.  For events problems, I suppose you could have trouble ensuring that events are recorded to the primary route.

2. if routes are appended to overwrite existing routes and the geometries are slightly different and not overlapping within tolerance, unexpected results can occur.  It might be more time consuming to clean that up than to take time to do extensive hands-on edits.

3.  I think it involves zooming in to XY tolerance levels and making minor edits to achieve precise geometry overlap.

4.  no time is really any safer than another time.  If you are running it for the first time then a good time is when you have some time to edit routes, troubleshoot, and somehow fix the situations.

5.  the thing we check most often is if the segment route length equals the segment shape length.  We have Data Reviewer so we can run non-monotonic checks I think?

Kevin, I will chat with a couple of my editors today and try to clarify some of these responses.

0 Kudos
New Contributor III

Hey Kevin,

Ryan is working on a reply to the Geonet post.


0 Kudos