"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
On Jan 26, 2011, at 11:12 AM, Andy Mabbett wrote:
> 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.
>
> On 23 January 2011 16:24, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>> How about this?
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>> On Sun, Jan 23, 2011 at 2:49 AM, Andy Mabbett <andy@pigsonthewing.org.uk>
>> wrote:
>>>
>>> On 23 January 2011 00:27, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>>>> Here is a proposed revision of Section 2.3 to address the concern.
>>>> Comments
>>>> welcome.
>>>>
>>>> 2.3. Latitude and Longitude Fields
>>>
>>> [...]
>>>
>>>> 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.
>>>
>>> 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
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
>>
>
>
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
