the only CRS in the first draft. The extension that allows alternate
CRSes can use the EPSG numbers instead of special names.
--Richard
Carl Reed wrote:
> How about a more generic approach in which the EPSG codes are used
> instead of a specific datum name (which may not have international
> agreement if defined by this group!). The EPSG code for WGS 84 2d is
> 4326. Or you could use the normative name as defined in the EPSG
> database. There is an online registry so that any code/name could be
> resolved by the application and all of the pertinent (and normative) CRS
> metadata is made accessible.
>
> This is the approach we use in the OGC for any and all CRS references in
> any of our standards - as does ISO and more recently OASIS.
>
> And finally, WGS 84 is not purely a datum. WGS 84 comprises a standard
> coordinate frame for the Earth, a standard spheroidal reference surface
> (the datum or reference ellipsoid) for raw altitude data, and a
> gravitational equipotential surface (the geoid) that defines the nominal
> sea level.
>
> Cheers
>
> Carl
>
> ----- Original Message ----- From: "Tatham Oddie" <tatham@oddie.com.au>
> To: "'Andy Mabbett'" <andy@pigsonthewing.org.uk>; "'GEOPRIV'"
> <geopriv@ietf.org>
> Sent: Tuesday, June 02, 2009 3:15 PM
> Subject: Re: [Geopriv] The "geo" URI draft
>
>
>> Hi Andy,
>>
>> I personally think the datum information should be part of the URI
>> content
>> and not part of the scheme as proposed by "geo-wgs84:" and "geo-fooo:"
>>
>> Applications are registered at the OS and browser levels to a particular
>> scheme, which in this case would be "geo". Pushing datum information
>> to the
>> scheme means that an application will have to register for every possible
>> datum that it supports and provide no capacity for it to attempt to
>> handle
>> other datums. It would be somewhat akin to having each different HTTP
>> authentication mechanism exposed as "http-basic:", "http-ntlm:", etc.
>>
>> Further, it would require an additional IANA registration every time a
>> new
>> datum was considered (http://www.iana.org/assignments/uri-schemes.html).
>>
>> As such, I'd propose to stick to something like
>> "geo:wgs84:12.34,56.78" and
>> "geo:foo:12.34,56.78".
>>
>>
>> Thanks,
>>
>> Tatham Oddie
>> au mob: +61 414 275 989, us cell: +1 213 422 7068, skype: tathamoddie,
>> landline: +61 2 8011 3982, fax: +61 2 9475 5172
>> my business: tixi.com.au - Ticketing without the dramas
>>
>>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf
>> Of Andy Mabbett
>> Sent: Wednesday, 3 June 2009 7:00 AM
>> To: GEOPRIV
>> Subject: [Geopriv] The "geo" URI draft
>>
>> In message <4A2578CE.1050204@viagenie.ca>, Simon Perreault
>> <simon.perreault@viagenie.ca> writes
>>
>>> Making the parameter mandatory, even maybe promoting it to a hierarchy
>>> element, would probably result in better interoperability. How would
>>> people feel about this?
>>>
>>> geo:wgs84:12.34,56.78
>>> geo:foooo:12.34,56.78
>>
>> and...
>>
>> In message <4A257C16.5020800@stpeter.im>, Peter Saint-Andre
>> <stpeter@stpeter.im> writes
>>
>>> Why not "wgs84:12.34,56.78"?
>>
>>
>> Either model would be OK by me; as would:
>>
>> geo-wgs84:12.34,56.78
>> geo-foooo:12.34,56.78
>>
>> --
>> Andy Mabbett
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
