Saturday, January 22, 2011

Re: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

Here is a proposed revision of Section 2.3 to address the concern.  Comments welcome.

2.3.  Latitude and Longitude Fields

   The Latitude and Longitude values in this specification are encoded
   as 34 bit, twos complement, fixed point values with 9 integer bits
   and 25 fractional bits.  The exact meaning of these values is
   determined by the datum; the description in this section applies to
   the datums defined in this document.  This document uses the same
   definition for all datums it specifies.

   Latitude values encoded by the DHCP server MUST be constrained to the
   range from -90 to +90 degrees.  Positive latitudes are north of the
   equator and negative latitudes are south of the equator.

   Longitude values encoded by the DHCP server MUST be normalized to the
   range from -180 to +180 degrees.  Positive longitudes are east of the
   Prime Meridian (Greenwich) and negative (2s complement) longitudes
   are west of the Prime Meridian.

   Since it is required that server-provided values of Latitude and
   Longitude be constrained, location consumers encountering values
   outside the range MUST ignore the location data rather than
   attempting to normalize potentially invalid values.  Location
   consumers SHOULD log the error.

   When encoding, Latitude and Longitude values are rounded to the
   nearest 34-bit binary representation.  This imprecision is considered
   acceptable for the purposes to which this form is intended to be
   applied and is ignored when decoding.


On Fri, Jan 21, 2011 at 2:11 PM, Carl Reed <creed@opengeospatial.org> wrote:
I would agree that if a value is outside the normal ranges for lat and long, then there is an error somewhere in the workflow. As such, an error message should be reported to the application or the user. Clamping to +90 is actually creating even more erroneous data. Thanks, Bernard.
 
Carl
 
----- Original Message -----
Sent: Wednesday, January 19, 2011 9:50 AM
Subject: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

Ari Keränen's review (see below) included a comment on issues arising from clamping of
latitude/longitude values outside the range. 

Comments?
===========================================
2.3. Latitude and Longitude Fields

Latitude values encoded by the DHCP server MUST be constrained to the
range from -90 to +90 degrees. Location consumers MUST be prepared
to normalize values outside this range. Values outside the range are
normalized by clamping [...]

If the values MUST be within those boundaries, doesn't it mean that a
value that is out of the range is somewhat likely completely wrong (due
to a broken implementation) and thus it would make sense to ignore it
rather than try to normalize the value and make it appear as if it was
valid? I'm not sure if I'd like to be liberal in what I accept when it
comes to information that could literally be a matter of life and death.


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv