Key Documents

SAE DSRC Message Set, J2735

The below document is key to understanding the MAP and SPaT Messages in any detail. The minor extracts found here will not be enough. So you are strongly urged to purchase of a copy of this standard.

The official release of the standard at this time is called:
SAE J2735 Dedicated Short Range Communications (DSRC) Message Set Dictionary™
(Revised: 2016-03-30)   
Buy a complete copy, including the ASN.1 source specification here.

The MAP data structures found in that document are the child of many mothers.  The experiences of many early deployments, many pilot projects and research efforts, and practical road modeling with GIS from much of the world went into creating that body of work.  [insert a join the TC note here too]


TODO: Add NTCIP 1202 efforts here as well with suitable text,
get with Jean J /NEMA to develop text for this.

Civil Engineering Standards

The following documents are useful to gain an understanding regarding the common design guidelines a civil engineering firm or traffic engineer looks to when creating intersections and related roadway infrastructure.


NCHRP REPORT 812, Signal Timing Manual, Second Edition

From the forward: In addition to covering basic and advanced signal timing concepts, this second edition of the Signal Timing Manual addresses establishment of a signal timing program including setting multimodal operational performance measures and outcomes, determining staffing needs, and monitoring and maintaining the system.  Some of the advanced concepts addressed include the systems engineering process; adaptive signal control; preferential treatment (e.g., rail, transit, and emergency vehicles); and timing strategies for oversaturated conditions, special events, and inclement weather.  The manual will be useful to traffic engineers and signal technicians at any agency operating traffic signals.

The top level link is:

Readers should skim chapter four for a basic understanding of how signalized intersection designs work if they have not encountered such systems before.

Manual on Uniform Traffic Control Devices for Streets and Highways

The MUTCD defines the standards used by road managers nationwide to install and maintain traffic control devices on all public streets, highways, bikeways, and private roads open to public travel. It is freely available and is published by the US Federal Highway Administration (FHWA) under 23 Code of Federal Regulations (CFR), Part 655, Subpart F.

The MUTCD contains a mother-load of key information on:

  • Overall roadway geometric practices (needed to comprehend MAP & intersection layouts),
  • Key signage definitions (needed to use many of the normative ITIS codes), and
  • Common signalized intersection methodologies (and terms)

If, like this author, you are not a formally trained civil engineer working for a DOT, a few afternoons spent reading this material will make many of the topics covered by the overall DSRC message set much clearer.

The top level link is:

Signalized Intersections: Informational Guide

This is a very readable guide on Signalized Intersections is required reading or at least skimming in order the gain an understanding of the general roadway geometry issues involved in lane placement


Other Standards

The following documents are also useful if you need to understand the overall GIS data exchange process in any depth


GeoJSON is a standard intended for representing general geographical features, and therefore can be used capture and to represent lane-level details (“features”) needed for the DSRC MAP messages.  It is an open source and free standard and is supported by a great many GIS tools and vendors.

There is a a specification, kept by the the Internet Engineering Task Force (IETF), who have formed a working group, to produce and maintain the standard:  RFC7946


JSON (JavaScript Object Notation) is a popular way to serialize and send data between devices on the internet (between server and web apps) using Java and JavaScript.  GeoJSON is built on top of JSON.  

There is a a specification (ECMA-404), which is kept by Ecma International in a task group.  There are many industry associations, here is but one with some useful background materials.  The actual ECMA-404 standard is here.


KML, or Key Hole Markup Language as it was first called, is the XML based markup language used by Google earth and other GIS products.  KML is widely supported as a method of GIS data exchange.  The file format KMZ is a zipped style of KML.

KML has become an international standard.  It is naintained by the Open Geospatial Consortium, Inc. (OGC).


XML, or Extensible Markup Language, see this for everything you might need to know, now in it 5th edition (2008) and originally one of the worlds shortest successful standards (~25 pages).   As you have undoubtedly read before… Extensible Markup Languages (XML) history begins with the development of Standardized Generalized Markup Language (SGML)


Misc Notes

The JSON notation uses a human readable system of named value pairs, whereas XML uses a system of nested tags.  Both are expressed in simple text (ASCII in general) and are not binary.  Hence they are human readable to some degree.  Both allow adding arbitrary attribute data in selected places. How to best do that with the MAP and Generic Lane level detail remains unclear.  Neither was design with level of detail about roadway geometry provided by the DSRC MAP or otherwise now needed in mind.

There exist today several tools that will translate from one format to the other. This generally works for points and poly line objects.  However there is not a common method of cross attribute exchange, so there is where the labor lies.

By contrast, DSRC messages are expressed in un-aligned PER ASN encoding (a binary format not easily read without special tools) when they are sent over the air.   Before that point, it the perfectly acceptable to save and to express MAP messages using XER, the ASN.1defined XML Encoding Rules.   As outlined in this article set, the best overall point in the map creation value chain at which a MAP containing full LLH values is converted into the smaller final ASN message payload is not a settled point.  The best practice at this point appear to be to delay the final conversion (and the resulting lose of data to translate the content further) as long as practical.

Was this article helpful?

Related Articles

Leave A Comment?

You must be logged in to post a comment.