Subject: [Geopriv] Proposed text for 3825bis

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 9 Feb 2010 23:39:28 -0800

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 10 Feb 2010 09:12:49 -0800

Thanks.  I have incorporated this material into Appendix A.3.  A strawman
version of -08 is available here:

http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-08.txt

From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Tuesday, February 09, 2010 11:39 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: 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-----

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.  

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

        <gml:Polygon>

          <gml:exterior>

            <gml:LinearRing>

              <gml:posList>

              </gml:posList>

            </gml:LinearRing>

          </gml:exterior>

        </gml:Polygon>

      </gs:base>

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

        <gml:LinearRing>

          <gml:posList>

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

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

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

     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.

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

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: 

 

-----END-----

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Feb 2010 07:10:16 +0800

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

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.

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

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:

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.

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

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

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.

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

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:

-----END-----

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 10 Feb 2010 15:16:05 -0800

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:

> 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.
>
>
> 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.
>
> 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.
>
> the following form (where $value$ indicates a value computed from  
> the DHCP option as described below):
>
> 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  
> 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 
> ".
>
> bits beyond those indicated can be either zero or one.  For version  
> 1, the resolution fields indicate uncertainty distances.
>
> 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).
>
> 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).
>
> There are 22 whole bits in the altitude encoding (instead of 9) and  
> 30 bits in total (instead of 34).
>
> 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:
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Feb 2010 07:21:53 +0800

The error is absolute (it’s 2^-8 for altitude), it doesn’t make sense to say “up to”.

From: Richard L. Barnes [mailto:[email-masked]]
Sent: Thursday, 11 February 2010 10:16 AM
To: Thomson, Martin
Cc: Bernard Aboba; [email-masked]
Subject: Re: [Geopriv] Proposed text for 3825bis

Hi Richard,

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Richard L. Barnes
Sent: Wednesday, 10 February 2010 6:39 PM
To: Bernard Aboba
Cc: [email-masked]<mailto:[email-masked]>
Subject: [Geopriv] Proposed text for 3825bis

Hi Bernard,

--Richard

-----END-----

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 10 Feb 2010 15:37:02 -0800

Are you referring to the quantization error?
      highvalue = value | mask
versus:
      highvalue = ( value | mask ) + 1 (== lowvalue + scale)
(the all-0xFF high value vs. the next low value)

If that's the concern, then we might as well just adjust the fixed- 
point version to use the "+1" version.

I guess I'll agree that you're unlikely to get errors simply due to  
the fact that you're doing floating-point arithmetic in this case.

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Feb 2010 11:00:06 +0800

(Resend; list post size limit reached)

The question is whether you consider the trailing 1 bits in the high value to be limited to the 34 (or 30) bits that are available, or whether you let the 1 bits continue indefinitely.  The +1 favours the latter interpretation (and avoids any 4mm gaps).

Ultimately, this is rather academic.  It’s less than 4mm (in both cases).  Given the other limitations of the representation, that’s nothing.  Let’s just add the 1 to the mask and keep everything nice and simple.

   highvalue = (value | mask) + 1
   (or highvalue = lowvalue + scale)

(Single precision floating point will likely lose this detail, but doubles have space aplenty :)

--Martin

From: Richard L. Barnes [mailto:[email-masked]]
Sent: Thursday, 11 February 2010 10:37 AM
To: Thomson, Martin
Cc: Bernard Aboba; [email-masked]
Subject: Re: [Geopriv] Proposed text for 3825bis

If that's the concern, then we might as well just adjust the fixed-point version to use the "+1" version.

I guess I'll agree that you're unlikely to get errors simply due to the fact that you're doing floating-point arithmetic in this case.

--Richard

…

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Feb 2010 10:52:16 +0800

--Martin

--Richard

From: Richard L. Barnes [mailto:[email-masked]]
Sent: Thursday, 11 February 2010 10:16 AM
To: Thomson, Martin
Cc: Bernard Aboba; [email-masked]<mailto:[email-masked]>
Subject: Re: [Geopriv] Proposed text for 3825bis

Hi Richard,

Hi Bernard,

--Richard

-----END-----

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 12 Feb 2010 17:00:40 -0800

Do we have agreement on a proposed text change for this sub-issue?

From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Wednesday, February 10, 2010 3:37 PM
To: Thomson, Martin
Cc: Bernard Aboba; [email-masked]
Subject: Re: [Geopriv] Proposed text for 3825bis

     highvalue = value | mask
versus:

If that's the concern, then we might as well just adjust the fixed-point
version to use the "+1" version.

I guess I'll agree that you're unlikely to get errors simply due to the fact
that you're doing floating-point arithmetic in this case.

--Richard

The error is absolute (it's 2^-8 for altitude), it doesn't make sense to say
"up to".

 

Hi Richard,

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: "Richard L. Barnes" <[email-masked]>
Date: Fri, 12 Feb 2010 23:29:13 -0500

I think so -- just add "+1" to the binary version:

OLD: highvalue = value | mask
NEW: highvalue = (value | mask) + 1

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Feb 2010 10:48:12 -0800

I've submitted RFC 3825bis-08, which includes the new GML mapping material (in Appendix A), as well as fixes for all the open issues (which I've gone ahead and resolved as "fixed" in TRAC). 

Since quite a bit of editing was required to incorporate the new material, it's possible that some issues remain.  

Please have a look at -08, and file issues for any problems that remain:
http://www.ietf.org/html/draft-ietf-geopriv-rfc3825bis-08.txt

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 13 Feb 2010 10:49:15 -0800

Oops.  That's http://www.ietf.org/id/draft-ietf-geopriv-rfc3825bis-08.txt

From: [email-masked]
To: [email-masked]
Date: Sat, 13 Feb 2010 10:48:12 -0800
Subject: [Geopriv] RFC 3825bis-08