Subject: Re: [Geopriv] [geopriv] #3: GML Mapping

From: "geopriv issue tracker" <[email-masked]>
Date: Sat, 13 Feb 2010 01:03:15 -0000

#3: GML Mapping
--------------------------------+-------------------------------------------
 Reporter:  rbarnes@…           |        Owner:  jmpolk@…                  
     Type:  defect              |       Status:  closed                    
 Priority:  major               |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis          |      Version:  2.0                       
 Severity:  Active WG Document  |   Resolution:  fixed                     
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * version:  => 2.0
  * resolution:  => fixed

Comment:

 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-----

-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/3#comment:9>
geopriv <http://tools.ietf.org/geopriv/>