Re: [Geopriv] Proposed text for 3825bis

Are you referring to the quantization error? 

     highvalue = value | mask
versus:

     highvalue = ( value | mask ) + 1 (== lowvalue + scale)

(the all-0xFF high value vs. the next low value)

If that's the concern, then we might as well just adjust the fixed-point version to use the "+1" version.

I guess I'll agree that you're unlikely to get errors simply due to the fact that you're doing floating-point arithmetic in this case.

--Richard

On Feb 10, 2010, at 3:21 PM, Thomson, Martin wrote:

The error is absolute (it's 2^-8 for altitude), it doesn't make sense to say "up to".

 

From: Richard L. Barnes [mailto:rbarnes@bbn.com] 
Sent: Thursday, 11 February 2010 10:16 AM
To: Thomson, Martin
Cc: Bernard Aboba; geopriv@ietf.org
Subject: Re: [Geopriv] Proposed text for 3825bis

 

Good point on the quantification: Suggested fix:

 

s/up to floating-point errors/up to a possible error of 2^-25/

 

 

 

On Feb 10, 2010, at 3:10 PM, Thomson, Martin wrote:

Hi Richard,

 

I notice that there is a small error in the first paragraph.

 

Section X: s/versions 1 and 2/versions 0 and 1/

 

I'll also note that the difference between setting bits and using exponents of two is quantifiable.  The error in the upper value is 2^-25.

 

 

From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Richard L. Barnes
Sent: Wednesday, 10 February 2010 6:39 PM
To: Bernard Aboba
Cc: geopriv@ietf.org
Subject: [Geopriv] Proposed text for 3825bis

 

Hi Bernard,

 

Since we haven't seen any text to address the remaining issue with rfc3825bis, here is some text that defines a mapping to GML.  Hope this helps,

 

--Richard

 

 

-----BEGIN-----

Section X. GML Mapping for Resolution

 

This section describes how the location value encoded in DHCP format for geodetic location can be expressed in GML.  This mapping is valid for versions 1 and 2, and for the currently-defined datum values (1, 2, and 3).  Further version or datum definitions should provide similar mappings.

 

The DHCP format for location described above logically describes a geodetic prism, rectangle, or point, depending on whether altitude and resolution values are provided.  These shapes can be mapped to GML by first computing the bounds that are described using the coordinate and resolution fields, then encoding the result in a GML Polygon or Prism shape.  

 

Section X.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 resolution is specified (that is, AltRes 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 or longitude resolution 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>

 

Section X.2. Finding Low and High Values using Resolution Fields

 

The resolution fields indicate the bounds of the location region described by a DHCP location object.  For version 0, the resolution fields indicate how many bits of a value contain information.  Any bits beyond those indicated can be either zero or one.  For version 1, the resolution 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 encodign" (version 1).

 

Section X.2.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 and resolution 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 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).

 

Section X.2.2. Uncertainty encoding

 

In the uncertainty encoding, the uncertainty fields 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 resolution uses the same process with different constants: 

 

    distance = 2 ^ (21 - uncertainty)

    lowvalue = value - distance

    highvalue = value + distance

 

 

 

-----END-----