Roads and Highways Locks

[ElsitMandal1]

Wondering if this expected behavior in ArcPro Roads & Highways Branch versioned & Conflict prevention enabled environment?
ArcPro 3.5.2 Roads & Highways Route Realign "errors out" because of event lock on another route
that happens to share one of the centerlines of the route being worked on to edit.
( The realign segment has a totally different centerline that is not shared with the route that has the event lock)

[CodyPatterson]

Hey @ElsitMandal1 

I could somewhat see this being a thing, only because the alignment may cause differences in some aspects other than the centerline, but it does seem pretty strange that it happens even without different non-shared centerlines.

Would it be possible to drop the lock manually and verify it working then? Also, did this happen to work in a previous version of Pro?

Cody

[ElsitMandal1]

After manually deleting the lock on the other route, the realignment edit on the route worked. Someone else in my work group had mentioned this issue in a previous version as well.

[AyanPalit]

@ElsitMandal1 Where concurrent routes exist, routes are locked based on common centerlines.

Reference: Conflict prevention > Conflict prevention during centerline editing

[ElsitMandal1]

The route that is being edited has many centerlines. The centerline that is involved in the edit is not shared with the other route.   The documentation link above does indicate if any of the centerline is shared with any other route, then what I encountered is expected. But what would be the reason behind this restriction for lock when the edit is on a different part of the route?

[AyanPalit]

@ElsitMandal1 I can just guess based on the description; it would help if you post a screenshot.

Note that locks are at the route level - not the centerline. That's the only way to maintain the integrity of calibration on routes. So a shared/concurrent centerline, even small segments, would lock the corresponding route(s). 

[ElsitMandal1]

The East west route is the one being edited. The event edit lock was on the North south route where the 2 routes shared a centerline. The yellow highlight is the realignment location

[AyanPalit · Accepted solution]

@ElsitMandal1 Thanks for posting the screenshot; this helps.

Suggest reviewing the LRS Locks table and correlate with the documentation.

• If there's an edit on the shared centerline, the LRS Locks table will show locks on both Routes. This is expected behavior.
• If only event on North south route is edited and has an event lock, with no locks on the route itself.  Then the East west route (with shared centerline) should not have a lock. 
• Try releasing the event lock and check if that resolves the issue. 

Reference: Conflict prevention > Conflict prevention during centerline editing

[ElsitMandal1]

In ArcPro 3.5.3, we are continuing to see the "expanded" (not observed in ArcMap roads and Highways) locks behavior in other Route edit locations also. While trying to split a centerline of the dominant route, I235 SB, that has a non-dominant route K96 WB, the split errored out because of event edit locks on US81 NB and I-135 NB because K96 WB shares an entirely different centerline as non-dominant at the other location shared by U-81 and I-135. US81 or I-135 does not ride/share centerline with I-235 SB anywhere in the county.

To summarize, what we are seeing is that, if any event edit locks are present on any dominant route/nondominant route and any associated dominant or nondominant routes, then it is not possible to acquire a lock to edit route.

[AyanPalit]

@ElsitMandal1 Recommend logging a Esri Technical Support case to review this behavior.