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.
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 AbobaTo: geopriv@ietf.orgSent: Wednesday, January 19, 2011 9:50 AMSubject: [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 FieldsLatitude 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