>
> 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
- What are valid URIs
- How does comparison work
- Are there any security considerations
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).
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?
Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
