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:
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.
1. Back in 2017 I would have identified the issue as the events changed values. Now based on the other esri tickets I would probably say the event measures where not applied correctly to the route geometry. I was able to spot the issue on the direction event before and after a roundabout/divided sections and the values were not correct. However, I don't believe it is an event specific issue.
The easiest way to find any issue is after you run the tool, run lastedited queries for the date (not date and time) and editor that ran the tool on your data. If like us, what you find may be surprising. It may not be wrong but something was changed that we did not expect. For me that suggests an unknown problem we didn't know about. That route should be researched before posting fixes to ensure that was the best method and you can live with any downstream effects.
2. The tool in some areas created micro centerline segments because of some arc geometry we had introduced. Using that geometry later on has created issues with editors creating multipart routes. I think reloading the routes might have been a better option but no without its own challenges at that time. That condition is what was I tried to fix last year. Too many centerlines where edited and we decided to realign the routes in those area to fix the issue and have known incorrect history then to have other unknown issues. As mentioned above event data may have shifted.
3. It all depends on what was identified as being edited by the tool or what Data Reviewer returns. Not a helpful answer but too many variables to give a simple answer.
4. Because we have conflict prevention turned on, I recommend no editing and locks in the system when running the tool to prevent issues. For us the easiest way to guarantee no editing is at a quarter freeze with no one else in the system. In an enterprise environment it can be difficult to keep 30+ users in different groups/locations on the same page.
5. We use Data Reviewer, there is a table check for unique ids. Another method is to cartographic realign the offending route out of the road bed and retire the route as opposed to using a future delete routes tool not available at 10.5.1 to remove the route. You can add a new route in the correct location.