Re: [Geopriv] Proposed text for 3825bis

["Richard L. Barnes" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On  
> Behalf Of Richard L. Barnes
> Sent: Wednesday, 10 February 2010 6:39 PM
> To: Bernard Aboba
> Cc: [e-mail]
> 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-----