[Geopriv] Proposed text for 3825bis

"Richard L. Barnes" <rbarnes@bbn.com> Wed, 10 February 2010 07:38 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24B1A28C100 for <geopriv@core3.amsl.com>; Tue, 9 Feb 2010 23:38:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.891
X-Spam-Level:
X-Spam-Status: No, score=-0.891 tagged_above=-999 required=5 tests=[AWL=-1.587, BAYES_00=-2.599, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X5O37+yqrFj for <geopriv@core3.amsl.com>; Tue, 9 Feb 2010 23:38:22 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4669528C105 for <geopriv@ietf.org>; Tue, 9 Feb 2010 23:38:22 -0800 (PST)
Received: from [128.89.255.44] (helo=[10.71.0.143]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <rbarnes@bbn.com>) id 1Nf7AY-0004TL-Ah; Wed, 10 Feb 2010 02:39:30 -0500
Message-Id: <E6DB07FF-AF22-41BB-A533-74B61D99CECA@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-1--282440105"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 09 Feb 2010 23:39:28 -0800
X-Mailer: Apple Mail (2.936)
Cc: geopriv@ietf.org
Subject: [Geopriv] Proposed text for 3825bis
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2010 07:38:24 -0000

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