Latest Contributions by KevinHunt

Hello Amit - Thank you very much for your investigation and workarounds. 1. Yes, after seeing the March RHUG presentation from Ohio DOT, I was attracted to the approach that Ethan Pointer used to assemble the LRS network from scratch and use the process to make “clean up” updates to the attribute tables and properties of the LRS feature classes. I also wanted to change the M tolerance (and corresponding resolution) in the ArcGIS Pro geodatabase from the R&H default to 0.0000001 Mile (US Survey). My thought was that as that as long at the M tolerance is set smaller than the default tolerance, it should be compatible with the rest of the LRS. Perhaps that is not the case. I understand that this reconfigured measure resolution should not have any impact inside the Roads and Highways ALRS which is controlled by the Measure Precision setting, but we believe the default measure tolerance is causing rounding discrepancies in the 7th decimal place in our downstream data mart which is not controlled by the ALRS measure precision functionality. I am coming to the conclusion that I need to change my approach to migrating the geodatabase. We have done some work with Clive recently on our migration so we will continue to look at this. Based on your work around, it sounds like my measure tolerance should be OK if we straighten out some other things but I would like to confirm that. 2. “The LRSN_Milepoint network you configured is set to Autogenerated Route Id”. Good catch…this was not intended. Originally I was trying to use the “Create LRS Network from Existing Dataset” GP tool and had the Route ID Field Config set to “Single-Field Route ID”. An error from that tool related to an undefined M unit of measure had me resort to the “Create LRS Network” GP tool instead and that tool appears to have assigned “Autogenerated Route Id”. Good to know there is a “Modify LRS Network” tool that can change this. Your post has me realizing how I could be tripping things up by using a combination of tools to establish the new LRS Feature Dataset in Pro. I have not yet tried to run “Modify LRS” because I have been focused on getting everything from the ArcMap ALRS into the file geodatabase first. As you and Clive have suggested, I will try the migration from the ArcMap ALRS next…once I make the attribute table and property changes. I’m learning a lot along the way.

The behavior we found was quickly reproduced by Tech Support and the result of the support case is BUG-000166871. Not everyone has run into this issue with the these GP tools so I suspect there is something different about the file geodatabase that I was using that is causing the issue.

Thank you Nathan. Will do.

I'm wondering if there are any known issues with the "Create LRS Event" GP tool in ArcGIS Pro 3.2. I've been trying to use it this week and ArcGIS Pro is crashing every time I attempt to run it. The first time I tried it, I believe I was able to set all the variables and hit "Run" before it crashed. Every time I've tried it since then, ArcGIS Pro crashes while I'm setting up the tool. I thought I would check here before I put in a Tech Support case. I believe I am running ArcGIS Pro 3.2 and have not yet installed either of the patches I noticed. Thanks! Kevin

Re: RHUG working groups · ‎02-05-2024

The RHUG AgileAssets Work Group (AAWG) is made up of Roads and Highways users that integrate the organization's LRS with the AgileAssets (Trimble) enterprise asset management system. Goals of the group: Share and document best practices with the LRS Gateway and other integrations between RH and AA Collectively address issues that arise in the integration between RH and AA Influence the future direction of LRS Gateway and other integration between RH and AA to support Applications of Enterprise GIS in Transportation (AEGIST) The RHUG AAWG work group currently meets on the first Wednesday of each month and New York and North Carolina are planning meeting agendas. For more information or to be added to the meetings, please reach out to Kevin Hunt or Ryan Koschatzky. kevin.hunt@its.ny.gov; rjkoschatzky@ncdot.gov

‎11-17-2023

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.

‎11-17-2023

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

‎11-16-2023

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: 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? 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: 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

‎02-23-2023

Hi Nathan, Looks like the link to the download for 10.7.1 is empty. Would you please confirm that link for us?

Event Dissolve in ALRS? · ‎02-13-2023

Hello RHUG! We recently discovered instances of adjacent traffic station locations with the same traffic station ID in an internal RH event feature class. I told the data owner, "no worries...we'll run an event dissolve to merge the adjacent event records". Then I went looking for the Location Referencing "Dissolve Events" tool and didn't find one. The GP tool I was thinking of was the "Dissolve Route Events" tool in the Linear Referencing Tools toolbox. Is there a 'manufacturer-approved' way to dissolve adjacent events in an internal RH event feature class?

‎11-21-2021

I meant to follow up on this article sooner when the details were fresher in my head but better late than never. We completed additional testing and closer inspection on this measure precision issue on the NYSDOT Milepoint ALRS and confirmed the notes Nathan and Amit documented here. Specifically... 1. The Roads and Highways geoprocessing tools we tested, including Calculate Route Concurrency (CRC), generate results that respect the measure precision set in the LRS Network properties. (7 in our case) 2. We did eventually locate a series of very small geometry errors in the Centerline feature class, similar to what is shown in Amit's 6/2/21 post above. Once these errors were repaired in the ALRS, the small overlaps generated by the concurrency API and the Calculate Route Concurrencies (CRC) tool cleared up. This issue turned up last spring while we were working on our "Roadway Data Mart" (RDM) which is being developed to publish the LRS network, events and dynamic segmentation results from NYSDOT's transactional Roads and Highways environment. One of the things we realized contributed to some confusion and concern is that a new field in the SQL Server 2016 geodatabase created by ArcGIS with type "Double" will create a "Number" field with Precision = 38 and Scale = 8. As a result, all the measure fields in our transactional ALRS are currently defined as Number 38,8 In the Roadway Data Mart (RDM), we wanted to completely avoid even the perception of a eighth significant digit right of the decimal point so we redefined all measure fields in the RDM to be Number 38, 7. We believe this will help mitigate potential data integrity issues related to measures when we use the RDM for both new dynamic segmentation products (ie. LRS event overlay results) and downstream system integrations.

‎11-19-2021

Hi Kevin NYSDOT maintains route concurrency on the routes. Due to some special cases related to incomplete inventory data on reverse (or non-primary) direction routes, our system generates and maintains a CONC_HIERARCHY field (a database trigger and calculates a value based on other route table attributes) for every route in the ALRS. This field then becomes the primary field defining the route dominance on the network. Once all roadways in the network include inventory data, we should be able to remove the CONC_HIERARCHY field and rely on the remaining four route table fields. The attached xlsx shows the current Route Dominance settings on our network.

‎11-17-2021

Hi Ryan, I just heard from Ting Wang at AgileAssets that he tested the issue with both 10.7.1 and 10.8.1 and both behave the same. The bug has just been established this week so I assume the product team will need some time to investigate.

‎11-16-2021

This article documents a problem and work around New York and AgileAssets uncovered as we worked through the LRS Gateway testing between Roads and Highways 10.7.1 and AgileAssets 7.6.2 (both running on Windows 2019) Please note: This issue only applies if you are using the Esri File Geodatabase API running on Windows Server (as opposed to Unix) to read the file geodatabase produced by the Roads and Highways (RH) ExportNetwork service. The Export Network GP Tool output is a file geodatabase. Applications that need to be aware of LRS network changes interface with the LRS in Roads and Highways through the RH Export Network service. At NYSDOT, our interfacing application is the AgileAssets enterprise asset management (EAM) system running on Windows Server 2019. Testing by NYS ITS and AgileAssets revealed that the File Geodatabase API could not reliably read the file geodatabase produced by the RH Export Network REST service. The problem was intermittent but otherwise persistent. As a result, the LRS Gateway sync would regularly fail. An upgrade of the File Geodatabase API to the latest version (1.5.2) did not fix the issue. AgileAssets had not seen this issue before because other customers (as well as their internal environments) generally run on Linux servers. The workaround that was proposed, and we have used successfully, was to publish a model that completes the Export Network GP tool first, creating the file geodatabase output, and then exporting the file geodatabase to JSON using a second GP tool. In our case, the AgileAssets EAM consumes the JSON format, avoiding the need to read the file geodatabase using the File GDB API. Due to the work around and since may not run AgileAssets on Windows Server for much longer, we did not work with Esri Tech Support on this issue. However, I wanted to make the community aware of it.

‎11-15-2021

NYSDOT and NYS ITS are currently working with AgileAssets on the "LRS Gateway" interface which uses the Roads and Highways REST API to update the LRS network and events in the NYSDOT AgileAssets Enterprise Asset Management (EAM) System. While completing final testing, we uncovered a problem with the Export Network service that has been documented and reproduced by Esri Tech Support. When running the Roads & Highways’ ExportNetwork GP tool (needed for the interface between AgileAssets and Roads & Highways) at NYSDOT, we noticed the Concurrency output from the tool is different between a File geodatabase and the enterprise geodatabase imported from the same file geodatabase. The file geodatabase’s Concurrency output appears to be correct, whereas the enterprise geodatabase’s Concurrency output is missing records. R&H Version: 10.7.1 Here is the bug that has been established: BUG-000144531: "Running Export Network returns different results if input layer is stored in file gdb or enterprise gdb." There is an additional bug from earlier this year that Esri believes may be related: BUG-000139908: “Calculate Route Concurrent GP Tool does not produce consistent result on SQL Server” Our tentative workaround for an initial LRS Gateway "sync" is to publish and run the ExportNetwork and RelocateEvent services from file geodatabase copy of our current enterprise geodatabase.

Online Status	Offline
Date Last Visited	Saturday

My Ideas

Latest Contributions by KevinHunt

Re: Create LRS Event GP Tool crashing in Pro 3.2

Re: Create LRS Event GP Tool crashing in Pro 3.2

Re: Create LRS Event GP Tool crashing in Pro 3.2

Create LRS Event GP Tool crashing in Pro 3.2

Re: RHUG working groups

Re: Updating Measure Tolerance in an existing ArcGIS Desktop ALRS

Re: Updating Measure Tolerance in an existing ArcGIS Desktop ALRS

Updating Measure Tolerance in an existing ArcGIS Desktop ALRS

Re: Roads and Highways 10.7.1 patch 5 now available

Event Dissolve in ALRS?

Re: Measure resolution tolerance vs. measure field definition

Re: Concurrent Routes - Managed via LRS (Routes) or Events?

Re: Export Network Bug is impacting LRS Interface to AgileAssets EAM

File Geodatabase API not reading the file geodatabase from ExportNetwork GP tool/service on Window 2019

Export Network Bug is impacting LRS Interface to AgileAssets EAM

Re: Create LRS Event GP Tool crashing in Pro 3.2

Create LRS Event GP Tool crashing in Pro 3.2

Re: RHUG working groups

Updating Measure Tolerance in an existing ArcGIS D...

Event Dissolve in ALRS?

Roads and Highways User Group (RHUG)