Field infrastructure footprint analysis

2.6.Mapping Support

It is important to draw a distinction between map data, which typically represents the road network, and the relationships between road segments (i.e., which road segments are connected to which other road segments to form the road network) and road geometry data, which represents accurate dimensional information about a particular section of road or a particular feature on a road. Examples of this include the locations of stop bars for intersection lane approaches, the curvature and super-elevation of specific curved road segments, widths and heights of tunnels and other partial barriers, etc. These features lie on road segments, and therefore are associated with the road and possibly with a larger road network map, but they are more or less independent of each other. They represent data about specific locations that may also be included on the larger road network map. These two types of data are often confused with one another, a situation made worse by the fact that the SAE J2735 message set uses the term MAP for the geometric road data message. For purposes of this discussion we will use the term map when referring to road network databases and information that relates to the larger scale road network and road geometry when referring to roadway dimensional and feature data.

5. Road Geometry Data Standards

Roadway geometry data for locations related to safety messages will be location specific, and thus must be produced for each situation. The data content and accuracy must be consistent between providers if the data is being provided from multiple sources (e.g. commercial map companies). If the data is provided individually by each jurisdiction responsible for each road area, for example as part of a warning message, the data content and accuracy must be consistent across jurisdictions, regardless of how the data was generated (i.e., locally, commercially, etc.).

6. Map Message Content

The J2735 MAP message specification is limited generally to intersection approach data. It provides some support for 3D geometry (i.e., overpasses), but does not support bank angles, surface conditions, and many other road geometry or dimensional attributes that one may need to support a connected vehicle application. The standard alludes to future content, but this content is not yet developed, and it appears that the plan is to develop a variety of different message types to address specific road situations.

This will limit the opportunities for many applications requiring road geometry data, such as Curve Speed Warning, toll/lane payment zone definition, border crossing and freight management lane directions, etc. Furthermore, specifications for accuracy and integrity do not exist, so receiving such data, even in the existing MAP message gives no assurance that data received from one location will be of the same accuracy or integrity as that received at another location.

Recommendation. Consider revising existing message standards to provide an extensible format that allows efficient provision of identified road elements and the dimensional/geometric parameters associated with them. Without specifying the solution in too much detail, it may be much more efficient and flexible to convert from the current fixed structured format for each type of roadway element (e.g. intersection geometry message, road curve message, etc.) to defining a road geometry data object that has a variety of attributes that can be dynamically identified (for example, using an XML tag approach). If a suitable schema of possible road attributes is defined, then one can convey the appropriate road geometry elements and their values in a single message type, but that message type can support an unbounded array of different roadway situations and structures. It can also be easily extended as new structures are created (for example, dedicated lanes and entry points for automated vehicles).

7. Road Geometry Data Maintenance

In many cases the degree of accuracy of road geometry data required for a particular application may not be high. This is especially true for situations where the geometric feature is not defined by construction, such that the feature may change relatively quickly. For example if a specific lane is closed, then it may be desirable to alert approaching motorists that the “right lane is closed, merge left.” However to determine this requires considerable human resources to identify locations where such transient hazards may exist, and to then determine the geometric changes required.

It appears that it may be feasible to capture such information from vehicle probe data instead. This allows the simultaneous detection of road geometry changes and the quantification of those changes with minimal human staff involvement. Ideally such an approach would simply require human validation and approval of automatically generated road geometry data (particularly for road data that does not require survey grade accuracy and that may change rapidly).

Recommendation: Determine how quickly road geometry features may change, and how many changes are likely to occur (to assess the approximate cost of human detection and updates). Determine the required dimensional accuracy and required integrity for these measurements, and assess the feasibility of using probe data to automatically detect and generate such updates. Identify requirements for validation and authentication of the data and the updates.