---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Active WG Document | Keywords:
---------------------------------------+------------------------------------
Comment(by bernard_aboba@…):
Proposed Resolution is as follows:
Appendix A. GML Mapping
The GML representation of a decoded DHCP option depends on what
fields are specified. The DHCP format for location logically
describes a geodetic prism, rectangle, or point, depending on whether
Altitude and uncertainty values are provided. In the absence of
uncertainty information, the value decoded from the DHCP form can be
expressed as a single point. If the point includes Altitude, it uses
a three dimensional CRS, otherwise it uses a two dimensional CRS. If
all fields are included along with uncertainty, the shape described
is a rectangular prism. Note that this is necessary given that
uncertainty for each axis is provided idependently.
If Altitude or Altitude Uncertainty is not specified, the shape is
described as a rectangle using the "gml:Polygon" shape. If Altitude
is available, a three dimensional CRS is used, otherwise a two
dimensional CRS is used.
For Datum values of 2 or 3 (NAD83), there is no available CRS URN
that covers three dimensional coordinates. By necessity, locations
described in these datums can be represented by two dimensional
shapes only; that is, either a two dimensional point or a polygon.
If the Altitude Type is 2 (floors), then this value can be
represented using a civic address object [RFC5139] that is presented
alongside the geodetic object.
This section describes how the location value encoded in DHCP format
for geodetic location can be expressed in GML. This mapping is valid
for the DHCPv6 option and both versions 0 and 1 of the DHCPv4 option,
and for the currently-defined datum values (1, 2, and 3). Further
Version or Datum definitions should provide similar mappings.
These shapes can be mapped to GML by first computing the bounds that
are described using the coordinate and uncertainty fields, then
encoding the result in a GML Polygon or Prism shape.
.in -0.3i
A.1. GML Templates
If Altitude is provided in meters (Altitude type 1) and the datum
value is WGS84 (value 1), then the proper GML shape is a Prism,
with the following form (where $value$ indicates a value computed
from the DHCP option as described below):
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"
xmlns:gs="http://www.opengis.net/pidflo/1.0"
xmlns:gml="http://www.opengis.net/gml">
<gs:base>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$lowLatitude$ $lowLongitude$ $lowAltitude$
$lowLatitude$ $highLongitude$ $lowAltitude$
$highLatitude$ $highLongitude$ $lowAltitude$
$highLatitude$ $lowLongitude$ $lowAltitude$
$lowLatitude$ $lowLongitude$ $lowAltitude$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
$highAltitude - lowAltitude$
</gs:height>
</gs:Prism>
The Polygon shape is used if Altitude is omitted or specified in
floors, or if either NAD83 datum is used (value 2 or 3). The
corresponding GML Polygon has the following form:
<gml:Polygon srsName="$2D-CRS-URN$"
xmlns:gml="http://www.opengis.net/gml">>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
$lowLatitude$ $lowLongitude$
$lowLatitude$ $highLongitude$
$highLatitude$ $highLongitude$
$highLatitude$ $lowLongitude$
$lowLatitude$ $lowLongitude$
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
The value "2D-CRS-URN" is defined by the datum value: If the datum
is WGS84 (value 1), then the 2D-CRS-URN is
"urn:ogc:def:crs:EPSG::4326". If the datum is NAD83 (value 2 or
3), then the 2D-CRS-URN is "urn:ogc:def:crs:EPSG::4269".
A Polygon shape with the WGS84 three-dimensional CRS is used if
the datum is WGS84 (value 1) and the Altitude is specified in
meters (Altitude type 1), but no Altitude uncertainty is specified
(that is, AltUnc is 0). In this case, the value of the Altitude
field is added after each of the points above, and the srsName
attribute is set to the three-dimentional WGS84 CRS, namely
"urn:ogc:def:crs:EPSG::4979".
A simple point shape is used if either Latitude uncertainty
(LatUnc) or Longitude uncertainty (LongUnc) is not specified.
With Altitude, this uses a three-dimensional CRS; otherwise, it
uses a two-dimensional CRS.
<gml:Point srsName="$CRS-URN$"
xmlns:gml="http://www.opengis.net/gml">
<gml:pos>$Latitude$ $Longitude$ $[Altitude]$</gml:pos>
</gml:Point>
A.1.1. Finding Low and High Values using Uncertainty Fields
The uncertainty fields (LatUnc, LongUnc, AltUnc) indicate the
bounds of the location region described by a DHCP location object.
For version 0, the uncertainty fields represent resolution,
indicating how many bits of a value contain information. Any bits
beyond those indicated can be either zero or one. For version 1,
the LatUnc, LongUnc and AltUnc fields indicate uncertainty
distances.
The two sections below describe how to compute the Latitude,
Longitude, and Altitude bounds (e.g., $lowlatitide$,
$highAltitude$) in the templates above. The first section
describes how these bounds are computed in the "resolution
encoding" (version 0), while the second section addresses the
"uncertainty encoding" (version 1).
A.1.1.1. Resolution Encoding
Given a number of resolution bits (i.e., the value of a resolution
field), if all bits beyond those bits are set to zero, this gives
the lowest possible value. The highest possible value can be
found setting all bits to one.
If the encoded value of Latitude/Longitude and resolution (LatUnc,
LongUnc) are treated as 34-bit unsigned integers, the following
can be used (where ">>" is a bitwise right shift, "&" is a bitwise
AND, "~" is a bitwise negation, and "|" is a bitwise OR).
mask = 0x3ffffffff >> resolution
lowvalue = value & ~mask
highvalue = value | mask
Once these values are determined, the corresponding floating point
numbers can be computed by dividing the values by 2^25 (since
there are 25 bits of fraction in the fixed-point representation).
Alternatively, the lowest possible value can be found by using
resolution to determine the size of the range. This method has
the advantage that it operates on the decoded floating point
values. It is equivalent to the first mechanism, up to floating-
point errors.
scale = 2 ^ ( 9 - resolution )
lowvalue = floor( value / scale ) * scale
highvalue = lowvalue + scale
Altitude resolution (AltUnc for v0) uses the same process with
different constants. There are 22 whole bits in the Altitude
encoding (instead of 9) and 30 bits in total (instead of 34).
A.1.1.2. Uncertainty Encoding
In the uncertainty encoding, the uncertainty fields (LongUnc,
LatUnc in v1) directly represent the logarithms of uncertainty
distances. So the low and high bounds are computed by first
computing the uncertainty distances, then adding and subtracting
these from the value provided. If "uncertainty" is the unsigned
integer value of the uncertainty field and "value" is the value of
the coordinate field:
distance = 2 ^ (8 - uncertainty)
lowvalue = value - distance
highvalue = value + distance
Altitude uncertainty (AltUnc in v1) uses the same process with
different constants:
distance = 2 ^ (21 - uncertainty)
lowvalue = value - distance
--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/31#comment:1>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
