Subject: [Geopriv] [geopriv] #31: Consolidation of material on GML Mapping into Appendix A

From: "geopriv issue tracker" <[email-masked]>
Date: Sat, 13 Feb 2010 02:33:19 -0000

#31: Consolidation of material on GML Mapping into Appendix A
---------------------------------------+------------------------------------
 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:                            
---------------------------------------+------------------------------------
 With the newly submitted material on GML Mapping, we now have material on
 GML mapping in two appendices.  It is proposed that this material be
 consolidated into a single Appendix A.

-- 
Ticket URL: <http://wiki.tools.ietf.org/wg/geopriv/trac/ticket/31>
geopriv <http://tools.ietf.org/geopriv/>

---

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

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

---

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

#31: Consolidation of material on GML Mapping into Appendix A
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  bernard_aboba@…           
     Type:  defect                     |       Status:  closed                    
 Priority:  major                      |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |      Version:  1.0                       
 Severity:  Active WG Document         |   Resolution:  fixed                     
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by bernard_aboba@…):

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

Comment:

 Fixed in -08.

-- 
Ticket URL: <http://rsync.tools.ietf.org/wg/geopriv/trac/ticket/31#comment:2>
geopriv <http://tools.ietf.org/geopriv/>