Return-Path: 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 27C7A28B56A for ; Wed, 10 Feb 2010 15:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=-1.323, 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 jmD99GiV2PEQ for ; Wed, 10 Feb 2010 15:14:57 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C195A28C168 for ; Wed, 10 Feb 2010 15:14:56 -0800 (PST) Received: from [128.89.255.129] (helo=[128.54.56.215]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1NfLmx-0008PX-BF; Wed, 10 Feb 2010 18:16:08 -0500 Message-Id: <0C61DFC9-33CD-4773-AF58-FAF9FFA089D4@bbn.com> From: "Richard L. Barnes" To: "Thomson, Martin" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F032E566A63@SISPE7MB1.commscope.com> Content-Type: multipart/alternative; boundary=Apple-Mail-13--226242792 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 10 Feb 2010 15:16:05 -0800 References: <8B0A9FCBB9832F43971E38010638454F032E566A63@SISPE7MB1.commscope.com> X-Mailer: Apple Mail (2.936) Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Proposed text for 3825bis X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2010 23:14:59 -0000 --Apple-Mail-13--226242792 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable 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=92ll also note that the difference between setting bits and using =20= > exponents of two is quantifiable. The error in the upper value is =20 > 2^-25. > > > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On =20= > 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 =20 > rfc3825bis, here is some text that defines a mapping to GML. Hope =20 > this helps, > > --Richard > > > -----BEGIN----- > Section X. GML Mapping for Resolution > > This section describes how the location value encoded in DHCP format =20= > for geodetic location can be expressed in GML. This mapping is =20 > valid for versions 1 and 2, and for the currently-defined datum =20 > values (1, 2, and 3). Further version or datum definitions should =20 > provide similar mappings. > > The DHCP format for location described above logically describes a =20 > geodetic prism, rectangle, or point, depending on whether altitude =20 > and resolution values are provided. These shapes can be mapped to =20 > GML by first computing the bounds that are described using the =20 > coordinate and resolution fields, then encoding the result in a GML =20= > Polygon or Prism shape. > > Section X.1. GML Templates > > If altitude is provided in meters (altitude type 1) and the datum =20 > value is WGS84 (value 1), then the proper GML shape is a Prism, with =20= > the following form (where $value$ indicates a value computed from =20 > the DHCP option as described below): > > xmlns:gs=3D"http://www.opengis.net/pidflo/1.0" > xmlns:gml=3D"http://www.opengis.net/gml"> > > > > > > $lowlatitude$ $lowlongitude$ $lowaltitude$ > $lowlatitude$ $highlongitude$ $lowaltitude$ > $highlatitude$ $highlongitude$ $lowaltitude$ > $highlatitude$ $lowlongitude$ $lowaltitude$ > $lowlatitude$ $lowlongitude$ $lowaltitude$ > > > > > > > $highaltitude - lowaltitude$ > > > > The Polygon shape is used if altitude is omitted or specified in =20 > floors, or if either NAD83 datum is used (value 2 or 3). The =20 > corresponding GML Polygon has the following form: > > xmlns:gml=3D"http://www.opengis.net/gml">> > > > > $lowlatitude$ $lowlongitude$ > $lowlatitude$ $highlongitude$ > $highlatitude$ $highlongitude$ > $highlatitude$ $lowlongitude$ > $lowlatitude$ $lowlongitude$ > > > > > > The value "2D-CRS-URN" is defined by the datum value: If the datum =20 > is WGS84 (value 1), then the 2D-CRS-URN is "urn:ogc:def:crs:EPSG::=20 > 4326". If the datum is NAD83 (value 2 or 3), then the 2D-CRS-URN is =20= > "urn:ogc:def:crs:EPSG::4269". > > A Polygon shape with the WGS84 three-dimensional CRS is used if the =20= > datum is WGS84 (value 1) and the altitude is specified in meters =20 > (altitude type 1), but no altitude resolution is specified (that is, =20= > AltRes is 0). In this case, the value of the altitude field is =20 > added after each of the points above, and the srsName attribute is =20 > set to the three-dimentional WGS84 CRS, namely = "urn:ogc:def:crs:EPSG::4979=20 > ". > > A simple Point shape is used if either latitude or longitude =20 > resolution is not specified. With altitude, this uses a three-=20 > dimensional CRS; otherwise, it uses a two-dimensional CRS. > > xmlns:gml=3D"http://www.opengis.net/gml"> > $latitude$ $longitude$ $[altitude]$ > > > Section X.2. Finding Low and High Values using Resolution Fields > > The resolution fields indicate the bounds of the location region =20 > described by a DHCP location object. For version 0, the resolution =20= > fields indicate how many bits of a value contain information. Any =20 > bits beyond those indicated can be either zero or one. For version =20= > 1, the resolution fields indicate uncertainty distances. > > The two sections below describe how to compute the latitude, =20 > longitude, and altitude bounds (e.g., $lowlatitide$, $highaltitude$) =20= > in the templates above. The first section describes how these =20 > bounds are computed in the "resolution encoding" (version 0), while =20= > 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 =20 > field), if all bits beyond those bits are set to zero, this gives =20 > the lowest possible value. The highest possible value can be found =20= > setting all bits to one. > > If the encoded value of latitude and resolution are treated as 34-=20 > bit unsigned integers, the following can be used (where ">>" is a =20 > bitwise right shift, "&" is a bitwise AND, "~" is a bitwise =20 > negation, and "|" is a bitwise OR). > > mask =3D 0x3ffffffff >> resolution > lowvalue =3D value & ~mask > highvalue =3D value | mask > > Once these values are determined, the corresponding floating point =20 > numbers can be computed by dividing the values by 2^25 (since there =20= > are 25 bits of fraction in the fixed-point representation). > > Alternatively, the lowest possible value can be found by using =20 > resolution to determine the size of the range. This method has the =20= > advantage that it operates on the decoded floating point values. It =20= > is equivalent to the first mechanism, up to floating-point errors. > > scale =3D 2 ^ ( 9 - resolution ) > lowvalue =3D floor( value / scale ) * scale > highvalue =3D lowvalue + scale > > Altitude resolution uses the same process with different constants. =20= > There are 22 whole bits in the altitude encoding (instead of 9) and =20= > 30 bits in total (instead of 34). > > Section X.2.2. Uncertainty encoding > > In the uncertainty encoding, the uncertainty fields directly =20 > represent the logarithms of uncertainty distances. So the low and =20 > high bounds are computed by first computing the uncertainty =20 > distances, then adding and subtracting these from the value =20 > provided. If "uncertainty" is the unsigned integer value of the =20 > uncertainty field and "value" is the value of the coordinate field: > > distance =3D 2 ^ (8 - uncertainty) > lowvalue =3D value - distance > highvalue =3D value + distance > > Altitude resolution uses the same process with different constants: > > distance =3D 2 ^ (21 - uncertainty) > lowvalue =3D value - distance > highvalue =3D value + distance > > > > -----END----- --Apple-Mail-13--226242792 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable 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.
 s/versions 1 and 2/versions 0 and = 1/
I=92ll = also note that the difference between setting bits and using exponents = of two is quantifiable.  The error in the upper value is = 2^-25.
 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,
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=3D"