> 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.)
As you outlined below, the "professional" GIS world has multiple options
available when conveying spatial information in a variety of CRSes. The
"geo" URI specification aims at filling the gap that there's no simple,
easy to use and human readable format that's well standardized.
Simplicity is a key feature for me in the scheme. If you want
complexity, there are enough other schemes to go with.
> 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.
Correct. That's why i am in favour in *always* expressing uncertainty in
meters - which would
A) not require any transformations on the uncertainty value
B) make the uncertainty parameter independent from the crs parameter
C) make uncertainty understandable and measureable to non-GIS people too
(my mum understands +/+100 meters, but not +/-0.03 degrees)
> 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
I would leave that to the specifications which define the additional
CRSes.
Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
