Linear Referencing System Developer Guide

Owned by
Former user (Deleted)
25 Feb, 2022
4 min read

This doc explains how to perform a variety of queries on DDOT's Roads and Highways system.  Some are standard "out-of-the-box" queries that use ESRI's provided REST Web services.  Others make use of DDOT's own custom-built Web service tools.

Before you start

It's highly recommended that you first gain a basic understanding of linear referencing.  It would also be beneficial to understand some of the unique (but awesome) datasets which DDOT has made available through it's customized Web services.

Example Location

Querying Location on the DDOT LRS Network

For most developers, the required "first step" for any Linear Referencing System (LRS) analysis is to find the nearest centerline route.  This process takes a XY coordinate pair and returns a JSON object containing a list of nearest LRS locations found.

Input Parameters

  1. The x and y coordinate for the location
  2. The inSR and outSR for the input and output points.
    1. The standard locally projected coordinate system is Maryland State Plane, Meters.  You would enter a code of 26985 for input/output SR.
    2. The standard unprojected coordinate system is EPSG/WGS84.  You would enter a code of 4326 for input/output SR.
  3. routeType This will usually be ‘Street’
  4. And a Search Radius (in meters, max=50m).

Example Query


For more information

Check out the full documentation for this method:  https://rh.dcgis.dc.gov/dcgis/rest/services/DDOT/LRSSupport/MapServer/exts/DDOTLRSTools/pointOnRoute

Querying Cross-section LRS Data

DDOT’s new LRS Web services give you very detailed information about the configuration of lanes within DC.  Below is a graphic representation of how the data are represented with Streetmix, and how that compares to the LRS data (below):

Centerline directionality

The direction of the centerline geometry is important:  lane number ordering and directionality are both referenced according to the ascending geometry direction.  In general, the direction of the DDOT centerline geometry flows away from the quadrant boundaries.  For centerlines in Northwest DC, streets ascend to the north or to the west.  Below is a graphic representation that we have found helpful.  There are exceptions, but generally the arrows determine the geometric direction of the centerline.

Side (traffic flow direction)

Side represents the direction of a travel lane in reference to the ascending direction of the  DDOT centerline geometry.  For example, 16th Street NW ascends to the north because it is located in the NW quadrant; all data are oriented in a north-facing direction.  Lanes are numbered from left to right in this same direction.  The divider (usually a median or double-yellow stripe) divides the left side lanes from the right side lanes.  Below is a north-facing photo example that illustrates this.  Lanes 1,2 and 3 are to the left of the double-yellow stripe; lanes 4 and 5 are right side lanes.

Lane Events.PNG

Lane Type

Lane type describes both the use restrictions as well as the turning movements allowed.  

Lane Width

The width of the lane in feet.  

Notes on the Cross-section Data

Lane Tapering:  One of the primary weaknesses of modeling the data in this fashion is that we cannot represent the gradual transition from one lane configuration to another (for example when a road width widens, causing the lanes to expand from 4 lanes to 5 lanes).  To keep things consistent, we have chosen to only represent fully-formed lanes only (not their tapers/transitions).  Future iterations of the model may accommodate tapering.  

Below is an example illustrating when the lane change is represented in the LRS data.  The green line indicates we have 4 lanes present, but the beginning of a lane count change.  The yellow taper graphic highlights the taper; the red line indicates when the lane 5 comes into existence in the LRS data.

taperinglanes.PNG

Input Parameters

  1. The X and Y coordinate
  2. The inSR and outSR are the spatial references. 
    1. The standard locally projected coordinate system is Maryland State Plane, Meters.  You would enter a code of 26985 for input/output SR.
    2. The standard unprojected coordinate system is EPSG/WGS84.  You would enter a code of 4326 for input/output SR.
  3. routeType. For lanes data, this will usually be ‘Street’
  4. includeSectionEvents.  Passing 'True' will include roadway cross-section information at this location.  (this might increase the time for a return)
  5. nearestMatchOnly.  Passing 'True' will provide only a single record returned
  6. And a Search Radius (in meters, max=50m).

Example Query

The results provide much of the same information provided by getPointOnRoute but include an additional array of data within the object called 'roadwayAttributes'.  This contains all of the cross-section data for the selected point.

Querying Nearest Intersecting LRS Routes

In DDOTLRSTools, there are actually two types of methods for finding the closest intersecting route.

  • nearestRouteIntersection - This method first takes an input X and Y coordinate and finds a getPointOnRoute location (see above).   Then, taking that found location, determine the closest intersecting routes.
  • getIntersectionByRoute - This method assumes that a network location is already known and the user is required to pass in a RouteID along with the XY location of the point.  The tool performs a getPointOnRoute, finding the closest location along the provided RouteID.  Using this location along the route, it finds and returns the closest intersecting route (for the intersectingRouteType).

If you already know the Route/RouteID, it is highly recommended to use the getIntersectionByRoute method

Input Parameters

  1. x/y:  The originally x and y values from the first call.  (eventually, we would like to also give users the ability to pass the measure value we get from the first query above).

  2. routeID:  The Route ID from the first call.  In this example, it’s:  11001802

  3. inSR/outSR:  The wkid of your preferred spatial reference.  Use the one from the first call.  In this example, it’s:  4326

  4. intersectingRouteType:  Intersecting route type (usually, you’ll want an intersecting Street but you can query for other types as well.  E.g - Alley, Ramp, Driveway etc)

Example Query



Further Reference

For more information about what's possible with the Roads and Highways REST API, please visit ESRI's documentation site: