How Lane Geometry is represented

This article provides and overview of how any lane geometry (or any object in the map system) is represented and how to use the data to create the polygon that contains the lane’s shape.

All Hail the Polygon…

Lanes are not rectangles or rectangular, although they often appear to be. Real world lanes and intersections are rarely laid out with nice neat square alignments. or on NS-EW boundaries.

All lanes are represented as closed polygons with are effectively transmitted in the MAP message.  The way they are sent in the DSRC MAP message is motivated by a need to conserve message size and bandwidth.  This format is NOT the way they are intended to be used in the end application. Nor is the way they are intended to be captured and edited in the MAP creation process].  There is an expectation that the MAP message(s) will be extracted and “flattened” for further use by the end consumer to meet the need of various applications.

Different applications want different things from a MAP message. The MAP developer need to consider these issues (add link to this topic). As an example, early DSRC adaptive signal controllers want to know where vehicle are with respect to a stop line.  But in order to do that, streams of error ridden BSM messages must be map matched to lane polygons to determine what lane a vehicle is in (and then compute the motion estimate to the stop line).  In contrast a pedestrian cross walk application may not care about any of these issues but simply want to know the path only a few of the lane object, and when the user is allowed to next walk.  A vehicle operating in the same intersection may be interested only in eco-drive issues and hence only care when the next movement that pertains to his lane will occur.  Flattening a general purpose map for each of these applications is much different.

A simple two point Lane

We begin with the simple case of a two point lane.  Many lanes that are short and do not required additional data can be modded in this way.

Aside:  Many early intersection efforts used maps that were made up only the ingress lanes, with those lanes represented by two points.   The current rich attribute systems did not exist in 2009 and a few years thereafter when early MAP deployment testing in Arizona, Michigan, and elsewhere was done.

Mathematically speaking, every lane needs at least three data items:

  • The width of the lane (in units of 1 centimeter)
  • The 1st Node Point (in X,Y units of 1 centimeter), presumed to be the stop line
  • The 2nd Node Point (in X,Y units of 1 centimeter), presumed to be further from the stop line

How this data is encoded and send in the message is further consider in this article (add link) but can be ignored for the present.  Issues such as anchor points and offset delta are considered there.

Given these these three points, we need to construct a polygon.

The start and end point form a straight line, representing the center-line of the roadway.  The width value is used to project a tangential line from each end point.

The distance between the StartPt and the EndPt (in cm) represent the length of the lane.  The width of the lane is given by the J2735 standard as “across the lane” so in this (contrived) case, the projection is one half the width to each corner.

Here we show the node to node distance as along the X axis and the width distance as the Y axis. But we stress again that few road are build this way and that all of the examples given here work with any rotation required.

The resulting four points are the corners of the lane polygon and can be drawn as shown above.  [Aside: We use a thicker  grey bar to denote the stop line in these figures.]

Removing the various projection lines produces the final polygon for the lane.

 

Or lanes, to reinforce that these polygons can be constructed at any rotation.

                  

 

Lane Width Varies

Nearly every every lane object has at least one width value.  The striping lane is the only exception to this rule.  The lane object may not contain a width attribute within it; in which case it inherits the current one from the parent data structure.  This allow intersections with common geometric design rules to save message space by stating the nominal width once.  A lane object may contain several width value as needed to represent its geometric shape.   The use of lane width is discussed further both here (<- provide link) and here.

So how does this affect a simple two point lane…

The lane width value is true at the node to which is is applied.  Therefore in our 2 node, there is starting width and there may be an ending width. The width on the lane along its progression form one node to another varies in a linear manner between the two node points.

So three things can occur; a lane can get thinner (moving to the node with a smaller width), remain the same (no new width provided), or grow wider (moving to a node with a larger width).

Aside: It is technically possible to create a lane object with the same width restated in multiple places with no effect on the resulting polygon but with the adverse effect on the message to bloat its size.  The current DSRC J2735 std does not provide a normative rule to prevent this.  Some enterprising party in the testing side of thinking should build a tool with rules to detect such things.

The use of lane width is discussed further both here (<- provide link) and here.

Adding a new point and fillet projections

Whenever a lane contains more that 2 nodes, there is a likelihood that the angle between the point will change.  This is how curves are represented in the MAP today, a series of short straight line segments.  The projection of the polygon at these node points involves computing the width at the intermediary node based on the current width and on the angle formed by the preceding and following nodes.

Here (<– add link) is an article where we consider the details of the fillet process further.

Adding a new point with no fillet projections

Node points can also be added to an otherwise straight segment of roadway whenever an attribute is needed.  A length of lane with a “do not block” attribute is a good example of this use case.

TODO add image here, take a google and a drawing and use the slider method.

 

Was this article helpful?

Related Articles

Leave A Comment?

You must be logged in to post a comment.