Updating Measure Tolerance in an existing ArcGIS Desktop ALRS

[KevinHunt]

When we first set up the NYSDOT Milepoint ALRS in Roads and Highways years ago, we explicitly set the X and Y tolerance and resolution using standards we used  elsewhere in the NYSDOT GIS environment and the M (measure) tolerance was set automatically as shown below.  Our assumption at the time was the measure tolerance had been set to the most appropriate value based on the desired X/Y tolerance.   While that is true, I do not believe this M Tolerance (0.000000621369949 miles) is compatible with our Measure Precision of 7.

Since our Milepoint ALRS has been in production, we have seen unsettling issues with tiny mismatches in length between centerline (geometric) length, route end measure and event end measures.

After comparing with the North Carolina DOT ALRS Resolution and Tolerance properties, I believe that the measure tolerance on the network should be set simply based on the measure precision as shown below.    

If Measure Precision (decimal places) = 6  then...

   Measure Tolerance should be 0.000001 miles (five zeros right of the decimal point)

If Measure Precision (decimal places) = 7 then...

  Measure Tolerance should be 0.0000001 miles (six zeros right of the decimal point)

Note that since NYSDOT uses measure precision = 7 our current M tolerance of 0.000000621369949 miles is greater than 0.0000001 miles.   Does this extra "wiggle room" in tolerance create the inconsistent end measures on routes and events that we have seen in our network?

So a few questions for he group…

For the Esri SMEs or product team:

1. I didn’t see more information on aligning the Measure Precision and Tolerance settings in the attached white paper.  Do you concur with the “if…then” statements above or is my brain playing tricks on me with a whole bunch of very small numbers?   
2. If we decide to update our ALRS to reset the measure tolerance, I understand that we need to start from scratch and reload the network and event feature classes into it.  Could you guide me to the best process/documentation to do that? 

For the rest of the RHUG community:

1. I'm curious how other well established RH ALRSs are set up for M precision and tolerance.  Would you could your LRS Network Properties for Resolution and Tolerance Properties shown below and post them here as something like the following example:  

New York (NAD83 UTM Zone 18N):  

Measure precision:  7

X/Y Tolerance:  0.001 meters

M Tolerance:   0.000000621369949 miles

Many thanks!  Kevin

[RyanKoschatzky]

Kevin,

"we have seen unsettling issues with tiny mismatches in length between centerline (geometric) length, route end measure and event end measures." What is the measures differences you're seeing? 

NAD_1983_StatePlane_North_Carolina_FIPS_3200_Feet

NAVD88_height_(ftUS)

 

[KevinHunt]

Thank you Ryan.  We've seen a number of different measure discrepancies between centerline length, route length and event measure length when looking at the end of the route or the beginning or end of a route overlap.   Since our measure calibration is set up to recalibrate based on changes in geometric length (a detail I should have included above), we expect all end measures to line up to the seventh decimal place when looking at the end of a route.  We have seen bigger discrepancies in length that we are investigating as well but this post is focused on how to prevent discrepancies in length at the 6th and 7th decimal place of measure precision 

[NathanEasley]

Hi Kevin,

Answers to your 2 questions are below.

1. I didn’t see more information on aligning the Measure Precision and Tolerance settings in the attached white paper.  Do you concur with the “if…then” statements above or is my brain playing tricks on me with a whole bunch of very small numbers?
   The M tolerance is the value that will be used to determine if two values are the same (within tolerance) or different (outside tolerance) within Roads and Highways when performing calculations.  The precision value within the LRS properties shows the decimal place where a significant (non-zero) value is present in the M tolerance.  In the example you showed, the M tolerance had 6 zeros before a significant digit was at the 7th place, so the precision is 7.  If the M tolerance had 2 zeros then a significant digit at the 3rd place, the precision would be 3.
2. If we decide to update our ALRS to reset the measure tolerance, I understand that we need to start from scratch and reload the network and event feature classes into it.  Could you guide me to the best process/documentation to do that?
   It depends how you want to model the feature classes.  You can model them all yourself in advance then create the LRS within the geodatabase and associate those feature classes as Networks, Events, and Intersections in the LRS.  I'd recommend taking a look at this topic on tolerance and resolution in the LRS, if you're planning to go that route to understand the XYZM tolerance and resolution values for all those feature classes https://pro.arcgis.com/en/pro-app/latest/help/production/roads-highways/tolerance-and-resolution-set....  The other option is let the Roads and Highways configuration tools create the feature classes when you create the LRS, Networks, Events, and Intersections.  With this approach, you would need to add your business data fields after these tools run.  With both approaches, we'd recommend using a new geodatabase to ensure things like domains aren't duplicated between the old and the new LRS.

Nathan
ArcGIS Roads and Highways team

[KevinHunt]

Thank you Nathan.   Your guidance on setting up the new geodatabase will help me get this update right the first time.  

In terms of the first question above, allow me to ask the question a different way.  If our measure precision is set to 7, do you agree that we might resolve length discrepancies that we see in the 7th place by updating the M tolerance from 

0.00000062....  to

0.0000001 ? 

The problem is that the length discrepancies creates tiny but invalid gaps and overlaps when we dynamically segment our event data to publish it.