Subject: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC 3825bis)

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Jan 2011 08:50:15 -0800

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.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 19 Jan 2011 11:57:45 -0500

It seems like things are likely to be wrong in either case, assuming you're not at a pole.  So I don't see any difference between one flavor of wrong and the other, at that level.  At least clamping is less likely to cause problems at higher layers.

--Richard

On Jan 19, 2011, at 11:50 AM, Bernard Aboba wrote:

> Ari Keränen's review (see below) included a comment on issues arising from clamping of
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 19 Jan 2011 10:18:20 -0800

In reality, wouldn't the decision be made at higher layers anyway?  The DHCP
client typically would not be the place to execute the clamping (or discard)
logic, the LCI Option would be passed up to other components (e.g. location
provider or application) where the decision would be made.  Given this,
advocating that the DHCP client make a discard decision which relies on
detailed knowledge of the option format doesn't make sense to me.

It seems more likely that a decision on discard would be made by the
application which has available the full range of information relating to
location determination (e.g. local policies, whether other more accurate
location values are available, whether manual override has occurred, etc.).

On Wed, Jan 19, 2011 at 8:57 AM, Richard L. Barnes <[email-masked]> wrote:

> It seems like things are likely to be wrong in either case, assuming you're
> not at a pole.  So I don't see any difference between one flavor of wrong
> and the other, at that level.  At least clamping is less likely to cause
> problems at higher layers.
>
> --Richard
>
>

---

From: "Carl Reed" <[email-masked]>
Date: Fri, 21 Jan 2011 15:11:52 -0700

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 ----- 
  From: Bernard Aboba 
  To: [email-masked] 
  Sent: Wednesday, January 19, 2011 9:50 AM
  Subject: [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on RFC3825bis)

  Comments?

------------------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 22 Jan 2011 16:27:54 -0800

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

   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 <[email-masked]> 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
>
>
> *From:* Bernard Aboba <[email-masked]>
> *To:* [email-masked]
> *Sent:* Wednesday, January 19, 2011 9:50 AM
> *Subject:* [Geopriv] Proposed resolution of Ticket #44 (Jari's DISCUSS on
> RFC3825bis)
>
> ------------------------------
>

---

From: Andy Mabbett <[email-masked]>
Date: Sun, 23 Jan 2011 10:49:44 +0000

> 2.3.  Latitude and Longitude Fields

[...]

>    are west of the Prime Meridian.

geoURI (rfc5870) allows for a 'crs' (coordinate reference system)
parameter so that, in future, coordinates on bodies such as The Moon
or Mars can be expressed. Some such CRSs allow a longitude value range
of 0-360, with no negative values, and of course these do not make
reference to Greenwich.

WGS84 is assumed as default, where no CRS is specified.

It would be sensible to build in such future proofing - and
consistency & compatibility - here, using the relevant sections of
GeoURI (3.4.1, 3.4.2) as a model.

See:

<http://tools.ietf.org/html/rfc5870#section-3.4.1>

<http://tools.ietf.org/html/rfc5870#section-3.4.2>

also <http://en.wikipedia.org/wiki/Geo_URI>.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 23 Jan 2011 08:24:42 -0800

How about this?

   Positive latitudes are north of the equator and negative latitudes
   are south of the equator.  Positive longitudes are east of the Prime
   Meridian (Greenwich) and negative (2s complement) longitudes are west
   of the Prime Meridian.

   Within the coordinate reference systems defined in this document
   (Datum values 1-3), longitude values outside the range of -180 to 180
   decimal degrees or latitude values outside the range of -90 to 90
   degrees MUST be considered invalid.  Server implementations SHOULD
   prevent the entry of invalid values within the selected coordinate
   reference system.  Location consumers MUST ignore invalid location
   coordinates and SHOULD log invalid location errors.

---

From: Andy Mabbett <[email-masked]>
Date: Wed, 26 Jan 2011 16:12:27 +0000

Thank you, but I do think the the GeoURL approach:

     1) Any recognised CRS may be used
     2) For each a set of rules must be provided
     3) The default CRS is WGS84
     4) Here are the rules for WGS84...
     5) No other CRS is recognised, yet.

using wording based on that in the cited section of the GeoURL
specifcation would be better, more compatible (not least with GeoURL),
and more future proof; for the reasons given previously.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 26 Jan 2011 11:28:10 -0500

Note this phrase:
"The exact meaning of these values determined by the datum; the description in this section applies to the datums defined in this document.  "

So the approach you're proposing is already there.  (1) You can use any datum value you want, but (2) you have to define it.  (4) This document defines the rules for the datums in the document (including WGS84). 

(3) and (5) are noops.  There is no default CRS, because it is always specified -- the datum bits always have a value.  There are other datums besides WGS84 (see the IANA registry).

--Richard