Main menu

Expanding Proven Conflation Capabilities

Bringing Lidar-Derived Curve & Grade Data Onto Maryland DOT’s LRS

By Luke Winters, Senior Solutions Engineer, and Spencer Buteyn, GIS Consultant 

Conflation has long been one of 1Spatial's standout strengths. This includes our first customer in the U.S., the U.S. Census, as well as more recently conflating traffic data to DOT Linear Referencing Systems (LRS) in four states. Over time, we’ve refined a workflow that reliably handles differences in segmentation, attribution inconsistencies, and varying event models. Our solution has shown that conflating linear data sets can be done reliably with automation. 

Recently, we had the opportunity to extend this approach in a new direction through a project with the Maryland Department of Transportation (MDOT). Instead of traffic data, we were tasked with conflating lidar-derived curve and grade information onto the state’s LRS network. In this blog, we’ll talk about some of the differences with this conflation, as well as what this means going forward for various datasets.   

Why Curve and Grade Data? 

Maryland contracted the collection of lidar-derived curve and grade measurements for their highways. These measurements show information about how tight curves are, and the slope angle on highway segments. These give valuable context for engineering analysis, safety modeling, pavement decisions, and roadway design. However, without being tied to the LRS, these attributes can’t be easily joined with other enterprise datasets or compared to existing linear events.  

These data were collected from vehicle-mounted sensors and are stored as linear segments. Unlike traffic datasets, which often include route identifiers, direction, or milepost ranges, curve and grade segments do not include route names or other shared identifiers that can be used directly for LRS alignment. This means the conflation process must rely more heavily on geometry. Instead of comparing attributes across datasets or filtering features by route ID, the workflow centers on spatial tolerances, as the primary factor in determining match to the LRS. 

Adaptations and Enhancements  

While our conflation process always follows the same pattern of Standardize > Validate > Match > Apply > Re-Validate, no two conflation projects are exactly the same; there’s always some changes to the rule base that are needed, and MDOT’s curve and grade data were no different. The two main adaptations were short segmentation and dense linework.  

1. Mismatched Segmentation 

The geometric shapes of the curve and grade linework were quite similar to the shapes of the state LRS, so we had little issue finding matches using primarily buffers. However, the curve and grade linework was segmented significantly shorter than the LRS or other road data that we typically see. This made it a bit trickier to do the matching step since we needed to account for one-to-many matches between the datasets.  

2. Variability in Feature Density 

In this case when we say density, we’re talking about how many vertices are present on a line. More vertices can increase the spatial precision of linework, but excessively dense linework can cause issues with comparisons.  

This was the case with the curve and grade linework, the collection was overly dense. Since 1Integrate is an object-based system, it looks at every feature and, for some operations like buffers, every vertex. This caused the process to be inefficient despite the density providing no meaningful increase to accuracy. To solve this, we used 1Integrate’s built-in Douglas-Peuker algorithm to simplify the linework. After this preprocessing step was completed, the remainder of the processing went quite smoothly.   

Delivery 

As with many of our conflation projects, our final delivery was a set of linear events for both the curve and the grade attributes. These events are based on the geometries and measure values of the state’s LRS. All in all, this was a pretty quick turnaround for the conflation, at just under three months from contracting to delivery.  

Continuing to Expand Supported Data Types 

Curve and grade conflation is just one example of the additional data types we’ve successfully brought into alignment with state LRS frameworks. Over the past several years, we’ve broadened our capabilities to include: 

  • Traffic operations datasets 

  • Lidar-derived roadway features 

  • Crash data 

  • Pavement and condition metrics 

  • Engineering event layers 

Across each of these applications, the goal remains consistent: improve location consistency so agencies can trust their data, integrate systems cleanly, and unlock better decision-making.