 |
 |
 |
 |
|
 |
 |
SAE J2735-Draft-Rev29 [issued: 12-11-08]
-
249 -
This is an SAE Motor Vehicle Council draft document of the DSRC committee, subject to change.
combination of 3D position, direction and an MUTCD code. In addition to a message ID, the header
contains a start time, duration time, and priority. This allows the advisory style of message to be similar to
Dynamic Message Sign (DMS) content or to ATIS event message content (and therefore dynamic),
whereas currently a road sign is typically painted (and therefore static).
Data Frame Valid Regions
Up to 8 valid regions may be used to geographically define where each message is useful to the driver.
Multiple regions are used to describe precise segments of roadway where the message applies, such as east
and west bound lanes approaching an intersection or interchange.
Data Frame Content
All advisory content consists of multiple ITIS code/text fields and an[CH20] optional URL to images or
additional information.
The format of road sign content depends on the MUTCD code for the sign. Existing formats for road sign
content include – speed limit, work zone warning, and exit services. Additional content formats will be
defined in further editions of this standard. These future formats will couple similar types of road signs
into broad categories. Each broad category of road signs will share a common content format. The general
format follows the established rules for using ITIS text and phrases, but with minor presumptions or
restrictions for DSRC needs.
A provision also exists for a generic road sign category. The list of valid MUTCD codes
(DE_MutcdTagList) includes a “generic” value. All generic road sign content also allows a text field and
an optional URL[CH21]
9
pointing to additional information. In general free text is avoided in the DRSC
message set work, but here limited means are provided to allow[RS22] some free text (often needed for local
street and place names).
8
DCK: Small terminology issue to resolve here. The term “message”: is being used to describe both the
“inner” message and the “outer” (up to sets of 8) message. Need to address this, and ID vs Time issues.
9
Bring up the concept of a base URL/URI to be found in another periodically sent “background”
message here. Will need yet another short annex to further develop this concept. Does the committee want
to support NTCIP “MULTI” strings from CMS/VMS signs here as well?