>> I wonder, why the `crs=' parameter's value is opted to hold a ``CRS
>> label'', and not an URI below, say, `urn:ogc:def:crs:'?
[...]
>> FWIW, I'd suggest either requiring `crs=' to hold an URI, or to have
>> a separate `crsURI=' parameter for that purpose.
> Ivan, Re-using the URIs is a pretty good idea. However, there are a
> couple of advantages to the current approach:
> 1. Abstraction: You can use "wgs84" to represent both the 2D and 3D
> CRSes, depending on whether altitude is present
... at the expense of having to maintain a separate registry of
such labels, and a mapping of these labels to URIs.
> 2. Brevity
Well, the above may justify a set of labels for the CRSes used
the most.
Wouldn't it then make sense to allow for a separate parameter to
hold an URI for the rarer CRSes?
Once again, with the current proposal, the set of available
coordinate systems is yet to be extended:
--cut: http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-01.txt --
4.4.1. Coordinate Reference System Identification
The semantics of the 'coordinates' component depends on the CRS of
the URI. The CRS itself is identified by the optional 'crs'
parameter the default. A URI instance uses the default WGS-84 CRS if
the 'crs' parameter is either missing, or contains the value of
'wgs84'. Other 'crs' values are not currently defined, but may be
specified by future documents.
--cut: http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-01.txt --
With such a parameter, a sheer number of already defined CRS
becomes available for the use in the geo: URIs.
--
FSF associate member #7257
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
