Modelling individual lane information.

626
5
08-12-2024 06:43 PM
Labels (2)
KatrinaOppermann
Emerging Contributor

Hello Everyone,

I'm from the Australian Capital Territory Government directorate that looks after our roads and highways. I'm currently trying to convert our existing linear referencing system (based off of deprecated technology) into ESRI Roads and Highways.

I think I understand most of the model (although if anyone can confirm if the Route_Id has to be fixed length or could be variable, I'd appreciate it!), but I'm really struggling with how to model our Lane information.

Our current system has evolved so that all condition data - cracking, skid resistance, fwd etc - is captured against a specific lane name (not a lane number). There is a LANE table, that stores all the lane information - name, width, to and from chainages etc, - and includes things like through lanes, turning lanes, bus lanes, ramps and shoulders.  It is imperative that I be able to map the condition data to the new model, so I need to have all my Lanes in the system as named things. Is the only solution to have each one of these as an individual event layer? Or is there an alternative method? 

Please find below the current set of lane types.

KatrinaOppermann_0-1723513258461.png

What would be the best method to model this so that I can attach the condition data to the lane information?

Any help would be very much appreciated.

Kind regards,
Katrina

5 Replies
RyanKoschatzky
Frequent Contributor

I know some states have the street name in the route id so the field has to be variable. You can set the routeid as text or concatenation.

 https://pro.arcgis.com/en/pro-app/latest/tool-reference/location-referencing/modify-route-id-padding...

How you are you currently modeling the geometry for the lanes? Do you have one centerline for each lane or all the lanes? You could model either way. Main difference comes down when you make changes to the alignment of the route. Do you want to do the change once or many times (once for each lane)? That is a business decision. 

You could have single centerline geometry for the route and an event for cracking that had fields for lane value and cracking value. All or some event feature classes could be set up like that. You could combine cracking, skid resistance, fwd etc in one or many feature classes. The more changes in the values, the more likely I would be to separate the different feature classes. Again, that's a business decision.

You could have a single centerline geometry for each lane and an event for cracking with just a field for cracking value. 

You could have single centerline geometry for the route and stack each lane as a separate routeid and an event for cracking with just a field for cracking value. Just case it’s possible doesn’t mean it’s the best option. I think this might be too messy but it’s a business decision.

Hope that helps some.

Ryan

AyanPalit
Esri Regular Contributor

@KatrinaOppermann   Interesting use cases and thanks for the details. ArcGIS Roads and Highways provides advanced linear referencing configurations and various modelling techniques. Some of the relevant options are cited by @RyanKoschatzky 

Q:  Does Route_Id has to be fixed length?

A: Refer to LRS Data Model   >  Network feature class Organizations use the fields ‘Route ID’ and ‘Route Name’ in ways that best fit their business requirements. From a design perspective, ‘Route ID’ is like an unique database key, often modelled as a GUID (38 character, alpha-numeric) while ‘Route Name’ is a more human readable, nameplate information.

‘Route ID’ does not have to be fixed length however, the field data type and the data should be consistent throughout the LRS model objects (networks, events, calibration point feature classes). ‘Route ID’ maybe modelled by concatenation of other fields  in the network feature class using Modify Route ID Padding.  

Q: How to model Lane information?

A: The options are well laid out by Ryan. I would lean towards modelling the highway as the network routes and the lanes as events. This option reduces the maintenance overhead, editing experience is more efficient, and will likely be more performant.  You can leverage subtypes to model the Lane table into an LRS event feature class. Refer to LRS Data Model   >  Events data model

Q: How to model Lane Condition data?

A: Certainly look at consolidating different conditions as suggested by Ryan. Lane Condition will be another LRS event layer and you can use similar modelling techniques as noted above. Alternate could be storing conditions as related table to the Lane.

Q: How to associate  Lane Condition to Lanes?

A: There may be multiple options:

  • Use dynamic segmentation to combine Lane Condition and Lane data from the two LRS event feature classes. There are multiple tools in ArcGIS Roads & Highways that allow you to dynamically segment the LRS events.
  • Use related tables, relationship class
Ayan Palit | Principal Consultant Esri
KatrinaOppermann
Emerging Contributor

Thank you RyanKoschatzky and AyanPalit, you have both given me valuable advice.

I was hopeful that the Route_id could be variable length, but all the examples in the help files were fixed width, so I was not confident. Thanks for confirming that! 

To answer your question Ryan, we have a single road centreline geometry for the network, and the lane information is modelled as tabular attribution against it, so not spatial. We will definitely be sticking with this model, as to create and maintain each lane individually does not provide us with enough advantages to outweigh the maintenance time disadvantage. 

I think I will create an event layer for each kind of condition reporting - eg, for cracking that has field values for lane name and cracking values. And then also create separate events for each of our lane name / types. While it does feel like overkill having 30 odd event layers for lanes, it will at least have all the already captured information in the new model. Then as Ayan suggests, we'll use dynamic segmentation for bringing the two together. I think I was making it harder than it should be, but I thought there might be a more simplified solution. 

AyanPalit, could you please expand on how I might use SubTypes to model the lane table into the LRS? Would this somehow allow concurrent lanes in the same event table? Would it be possible to have all our lane types in one event layer? 

Thank you so much for your help!

Kind regards,
Katrina

AyanPalit
Esri Regular Contributor

@KatrinaOppermann Basically, you may use the lane types and create a single subtyped event layer. You may have concurrent lanes in the same event layer, referencing the same highway route. The subtypes documentation has good advantages listed: 

  • Set default values on fields in each of the subtypes that will automatically apply when creating new features.
  • Apply coded or ranged domains to the fields of a subtype, enabling you to constrain input information to a valid set of values.
  • Each subtype may have different connectivity, relationship, or topology rules associated with it.
  • Increase the performance of the geodatabase by representing a variety of real-world objects as a subset of features in a given feature class instead of creating new feature classes for each object.
  • Create customized rules between features using written code.
Ayan Palit | Principal Consultant Esri
RyanKoschatzky
Frequent Contributor

I would probably go with a field for each event (cracking) called lane and use a coded domain for types but we have not tried something like that so I am not sure of the pro/cons on that direction. 

Another option/thought is to look at this post of a few other states data model to see if they have something similar. 

https://community.esri.com/t5/roads-and-highways-user-group-rhug-questions/roads-and-highways-data-m...

DC DOT had something closer to what I think your trying to model. I don't recall who took over for James Graham (with cyclomedia now) when he left that could explain it better but I found this article. 

https://www.gis.fhwa.dot.gov/newsletters/Newsletter_July2018.pdf