nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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)

Vind meer berichten getagd met

Accepted answers

Ayan Palit

@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

All comments

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

Ayan Palit

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

Reference: Conflict prevention > Conflict prevention during centerline editing

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.

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?

Ayan Palit

@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

EastWestRouteBeingEdited.jpg

Ayan Palit

@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

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.