>> 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
>> 2. Brevity
> In my opinion, the URI is a good idea, because it removes the need
> for a registry. *However*, just because the CRS is defined in the
> urn space does not necessarily mean that the corresponding definition
> is good enough for the geo URI, because as you see from the draft,
> there's more needed to have the URI semantics defined, even if the
> CRS is clear:
> - What is the meaning of the "x","y","z" coordinate component
Is this really necessary?
> - What are valid URIs
While a CRS definition will, I guess, include the limits for the
coordinates, or at least allow for them to be determined in an
unambigous way, I doubt that these limits could easily be
written in ABNF for any existing CRS. (May EPSG 3576 [1] serve
as an example?)
[1] http://nsidc.org/data/atlas/epsg_3576.html
> - How does comparison work
Wouldn't the simple string comparison work (with the trailing
zeros being dropped)?
(But note, that the trailing zeros are used in science to
provide the uncertainty information; i. e., 1.23 may not be the
same as 1.2300 in, say, the field of physics -- while 1.23 may
be considered ``equal'' to 1.234, the 1.2300 may not.)
> - Are there any security considerations
Any example where this may be appropriate?
> So there definitely needs to be documentation for how each CRS to be
> used in the geo URI is to be mapped (note that there are many many
> CRSes that don't use the longitude/latitude scheme, for a start -
> also many CRSes have completely different definitions of the third
> dimension).
Wouldn't the party supporting a particular CRS ``know'' what the
interpretation is? Wouldn't the geo: URI with a CRS not known
to a particular party be unusable to that party anyway?
> So, just adding the CRS to the URI parameter is not good enough for a
> full definition - which means that we need a document for new CRSes
> anyway.
> Which, in turn, removes the advantage of not needing a registry...
> BUT - i think it is definitely a good idea to align the "identifier
> string" that ogc uses and what is the token in the "crs" URI
> parameter (i think we are fine with "wgs84").
> BTW, i have tried to locate that URN registry - could you provide me
> with a pointer?
I'm afraid I wasn't able to find it, either. Looks like [2]
``delegates'' the naming below urn:ogc:def:crs:EPSG: to EPSG
[3]. As per [2], urn:ogc:def:crs:EPSG is the only possible
immediate subordinate to urn:ogc:def:crs.
You may wish to check how the `epsg' file shipped with the
PROJ.4 [4] package is generated.
[2] http://www.opengeospatial.org/ogcUrnPolicy
[3] http://www.epsg.org/
[4] http://trac.osgeo.org/proj/
--
FSF associate member #7257
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
