[...]
> Regarding the specification of Coordinate Reference Systems:
[...]
> Ted Hardie then proposed that we should not *preclude* the potential
> future use of other reference systems:
> http://www.ietf.org/mail-archive/web/vcarddav/current/msg00989.html
> Which i have finally added to the draft. However, this was never
> intended as an "let all CRSes bloom" option for the URI - as outlined
> above, this was more intended as an "emergency exit" once WGS-84
> becomes obsolete (which is not going to happen anytime soon, as far
> as i understand - note that WGS-84 is being adopted over time -
> please don't fall for thinking that "84" in "WGS-84" has the same
> meaning as "95" in "Windows 95" - there's no need to "upgrade"!)
> I think that letting thousands of CRSes bloom for the URI is
> dangerous - it will clearly limit interopability, and impact the
> original goal of having something that's simple, human readable, and
> easy to use (even for people who don't even know what a CRS is, and
> just enter the coordinates into a mapping service or their car
> navigation system).
> So, please let's stay with primarily one CRS, and use the parameter
> as an "emergency exit" mechanism only. Obviously, that also means
> that i am opposing the use of an URI/URN as the specification of the
> CRS.
My point is that the geo: URIs may actually be useful in
metadata entries. When the data these entries describe uses
non-WGS 84 CRS (which is true for most of the raster data sets
derived from satellite observations; check Landsat 7 data on
http://www.landcover.org/, for instance, or you may refer to the
vast variety of data sets available through
https://wist.echo.nasa.gov/), it seems to be inappropriate to
use WGS 84. Especially when both the sender and receiver of the
geo: URI use non-WGS 84 CRS internally (consider, e. g.,
MapServer showing Landsat 7 data.)
There, of course, exist other ways to express such information
(like GML, for instance) while preserving the CRS, which,
however, seem to me somewhat cumbersome, when compared to a URN
with one more URN embedded within it.
Also note that when transforming from a given CRS to WGS 84, the
transformation of the associated uncertainty may be non-trivial.
Having said that, I believe that the specification, if allowing
the use of non-WGS 84 CRSes, should warn about possible
interoperability problems and generally recommend /against/ such
CRSes, except for the special cases (like, e. g., passing the
locations between two agents that already use non-WGS 84 CRS
internally.)
> Regarding uncertainty
[...]
> However, i would very much like to declare the "uncertainty"
> parameter out of scope of the current document, and create a
> different document for that parameter (Martin Thomson has indicated
> he would be willing to work on this?).
FWIW, I've no objections to this.
[...]
--
FSF associate member #7257
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
