Legacy data that needs to be corrected in R&H but will bring about a ripple effect of event changes

Question

I have two areas in my data where there's a descending side of the road that got a totally different route id than the ascending side of the road.  Typically we have both the ascending and descending sides of the roads have the same first 5 characters, ie: 00024AOH000 & 00024DOH000 - where the 6th character defines if it's ascending or descending.

We also have the descending concurrent with the ascending for the other part of the route, but use route dominance so that events are placed on the ascending route.

The image below shows one of the two areas that I'm wondering how and if others have had similar issues and fixed.  I can't seem to figure out the best order of operation to fix this area.

NicoleHanson1 · Answer

We use from date as the route start date, does 343D have the same from date as what 24D would have? Yes

Is 343D is built correctly if it was 24D? The part of 343D

Does 343D have to exist when the fix is complete? Nope, it can disappear!

I am also going to assume 24A is dominant over 343D, is that correct? Yes 24A will be dominant.  Right now 343D is not concurrent with 24A.  OHH I think I know what to do....

Is 24D an active route anywhere else? Nope

What version are you using? 10.6.1

We have a similar rule - when we have a divide road like this, the descending is concurrent with the ascending where it's not divided.  Thanks Ryan!  I will try your fix in our UAT environment and let you know if that worked!

RyanKoschatzky · Answer

Nicole,

We have made very similar fixes but I have some additional questions that might impact the fix or at least for us it can.

We use from date as the route start date, does 343D have the same from date as what 24D would have?

Is 343D is built correctly if it was 24D?

Does 343D have to exist when the fix is complete?

I am also going to assume 24A is dominant over 343D, is that correct?

Is 24D an active route anywhere else?

What version are you using? We are still on 10.5.1 so it might would slightly different for you.

Our rules would require us to coroute 24A and 24D where possible, so 24D would start from the end of 24A to the start of 24A unless the begin/end is divided/couplet situation. Where corouted we would only apply event data on 24A and not 24D. Event data for 24D would only exist where 24D is the dominant route.

To fix assuming 24D exists nowhere else and dates are equal between 24D and 343D, I would create 24D along its correct alignment, so it would be corouted with 343D and click apply updates, the events would not move up the route stack to 24D because of a bug and stay with 343D. Then retire 343D with it's same from date and click apply updates. By having the same from/to date 343D would not exist anymore in the data which seems to be correct as the route number was in error. You can still find the location but you would not have the timeslice active to select again. The events that where on 343D should then be applied to 24D and there should not be any changes to the 24A events.

For us 343D would have a direction event of southbound and 24D would be have a direction event of westbound. We would have to edit the event record to show this change as opposed to adding a new record as the event timeslice would then still show an error. Other event data might also need to be updated if a similar event type scenario exists.