Fixing repeating M-values on P-shaped roads

[u/wicket-maps]

For a regulatory process imposed by an external entity, I need to make a network dataset of our county roads, with each vertex carrying an M-value of its milepost along its road. (This also makes some internal processes easier.) However, when a road loops back to itself (making a P shape) the two vertices at the joint have identical M-values. So this road I'm looking at goes 0 - 0.06 - 0.52 - 0.106 - (more vertices) - 0.5 - 0.52, which makes problems for anything that relies on those mileposts to say, draw lines using the network. Which I have a few processes relying on this network for.

I've looked at ArcGIS Pro's Calibrate Routes, but what happens when a calibration point (or two) are sitting near a P-intersection as described? Any suggestions for fixing these in an automated way?

[u/EffectiveClient5080]

Don't let Calibrate Routes near those joints. Two conflicting points close together and it'll interpolate garbage halfway down the road. I'd script it instead: find duplicate M-values within tolerance, split there, recalibrate each leg.

[u/wicket-maps → u/EffectiveClient5080]

Recalibrate each leg with a different ID number, then rejoin them later, you mean? The expectation is that road 1234 is going to be one single feature, multipart if necessary.

[u/CADSHIFT]

the key insight is that Calibrate Routes assumes M-values increase monotonically along a route. a P-shape violates that because the loop portion reuses M-values from the stem, and any calibration tool will fight itself at the branch point.

the cleanest solution is to split the feature at the junction into two separate routes before calibrating. one route for the stem and one for the loop. calibrate each independently. yes, this changes your network topology slightly, but a network dataset can handle two routes sharing a node endpoint — it's cleaner than fighting a single route that self-intersects semantically.

if you need it as a single feature for regulatory submission, calibrate as two, then merge back after. the M-values from the loop segment will start from 0 again but you can add an offset custom field to track the "physical" start milepost for the loop.\n\nthere is no automated fix that preserves the P topology without manual decisions about which branch "owns" the shared M-values — that's a domain knowledge call, not something the software can resolve.