This article describes issues with the vertical dimension of the LLH positions used in the DSRC work; particularly with respect the MAP applications.
First some basics
In the SAE DSRC system “height” means the height above the reference ellipsoid described by WGS84 expressed in units of 10 centimeter steps. It does not mean with respect the mean sea level (which NMEA-183 will often use) or to a local geoid.
As general rule, the vertical precision of any GNSS positional estimate is ~2x worse than that in the horizontal plane. So if your OBU is getting ~1meter accuracies (not unreasonable when corrections are used), your vertical accuracy is ~2 meters or worse.
In many GNSS systems, knowing the approximate vertical position can use this data as an aid in the positional estimate to reduce errors and obtain a better overall estimate.
In the DSRC work the system of LLH offsets coexists with the system of XYZ offsets, joined at a common anchor point. The system of units used for the “vertical” offset element (H or Z respectively) are the same in both systems. A precision of 10 centimeters is used in both.
The precise alignment between these two vertical systems varies in very slight ways at different places on the earth. But because of the fairly crude precision, the vertical values are identical in this system. In other words the offset height is same as the Z value (unlike the LL to XY process where a localized conversion factor must be determined).
Using the Vertical Dimension
For most map applications, the vertical element is not of great importance and can often be ignored. As long as the map anchor point provides a common value that the rest of the map can be presumed to be aligned with (perhaps to +- a meter), all is well. But this is not true in other cases with changes in elevation, often to a startling degree. In such cases, the map message provides various ways to sparsely insert vertical information in the geometric descriptions of the generic lanes. This is done using the common attribute system described elsewhere.
Technically, elevation is defined two ways for this use case, an absolute value, and an offset value. The first is defined as:
Elevation ::= INTEGER (-4096..61439) -- In units of 10 cm steps above or below the reference ellipsoid -- Providing a range of -409.5 to + 6143.9 meters -- The value -4096 shall be used when Unknown is to be sent
And it is used by the DF_VerticalOffset entry and in the DF_Position3D entry, which in turn is used by the DF_IntersectionGeometry (for intersection maps) and in the DF_RoadSegment (for other roadway map fragments). The key fragment in the ASN is:
-- Required default values about lane descriptions follow refPoint Position3D, -- The reference from which subsequent -- data points are offset until a new -- point is used.
A vital important detail is that the units for the overall DSRC vertical coordinate system are established here be in 10 centimeter steps (a decimeter). This becomes very important when vertical offsets are considered (as opposed to horizontal ones which are set to be 1 centimeter steps).
In the 2nd case using offsets, elevation is a defined (as an optional) attribute which can be present for every DF_NodeXY entry and is found in the NodeAttributeSetXY data frame. The key fragment of ASN is as follows:
dElevation Offset-B10 OPTIONAL, -- A value added to the current Elevation -- at this node from this node onwards, in 10cm steps -- elevations between nodes are a linear taper between pts -- the value of zero shall not be sent here
Note that it is encoded as an offset to the prior effective elevation value for that lane. The range of Offset-B10 is +- 51.1 meters in the vertical dimension, therefore any change in elevation greater than this value cannot be reflected in this element. The lane designer can elect to add another node point if required to reflect this.
Aside: A similar pattern is used for the DF_NodeAttributeSetLL entry used with the Lat-Long offset method is also provided. Aide: There was some very slight concern expressed by European contributors that a larger range (in fact a copy of the Elevation entry) should be added to LaneDataAttribute structure (used to send arbitrary values as attribute) for use in very hilly regions of when modeling road segments.
Best Practice for DF_Position3D
- When the DF_Position3D in the DF_IntersectionGeometry (for intersection maps) the data element DF_VerticalOffset SHALL be present and SHALL NOT use the Unknown value (-4096). The intent of this is that all intersection will always provide a full LLH anchor point.
A similar requirement should not be placed on DF_RoadSegment (for other roadway map fragments) because these use cases may be used for rapid ad hoc maps for incident events where suitable map planning may not be possible.
The current J2735 standard (and J2945/10 now being developed) does not make this point and because the VerticalOffset appears as an OPTIONAL entry in the ASN, a reader could incorrectly suppose that this value was not needed. This has been forwarded to the DSRC TC for consideration, and it is not official at this time.
Best Practice for Lane Elevation Changes
For each lane, the starting elevation is defined by the value set in the refPoint entry. Changes (offsets) from this value are encoded as part of each node point, in the NodeAttributeSetLL for that node, with decimeter precision. Typically this value is not sent.
No firm recommendation can be provided at this time regarding some magical threshold where an offset should be added. If the reader wants a number, any accumulated change of over 2.5 meters should result in an offset.
The best estimate of elevation of elevation should be calculated from each point to the next with suitable floating point precision when the map is created to avoid truncating the source data.
The source elevation for the lane centerlines data can easily be gathered in the field using the normal transit and rod method. Metric rods are useful in this regard, rather than 1/10th of inches more commonly found. In the absence of a site campaign, many public domain elevation databases can also be used to establish local heights.
On the use of Zoom
The Zoom scale element provides a way to increase the range (span) of offsets with a proportional decrease in the resolution (precision). The zoom for an intersection is defined to be 1:1 by the current standard. In any event, the use of zoom does not apply to the vertical dimension, ever.
A shortcoming in the current standard
The ASN comment for the offset entry provides the step value for the horizontal plane, but not one for the vertical direction.
Offset-B10 ::= INTEGER (-512..511) -- a range of +- 5.11 meters
And it is not obvious to the casual reader that they do not use the same units. This causes confusion, and it might be useful to add a line like that shown below when the next revision of the standard occurs.
Offset-B10 ::= INTEGER (-512..511) -- a range of +- 5.11 meters in the horizontal plane -- a range of +- 51.1 meters in the vertical direction
Better yet we should have used the correct the data element here (a set of vertical offsets). In the NodeAttributeSetLL where it currently states:
dElevation Offset-B10 OPTIONAL,
it should link to the correct Vertical value and be replaced to be:
dElevation VertOffset-B10 OPTIONAL,
which would avoid this confusion. The vertical definition reads:
VertOffset-B10 ::= INTEGER (-512..511) -- LSB units of of 10 cm -- with a range of +- 51.1 meters vertical -- value 511 to be used for 511 or greater -- value -511 to be used for -511 or greater -- value -512 to be unavailable