AM> - WGS-84 is currently clearly the most predominantly used CRS for
AM> "neogeography"
IS> It isn't. Apparently, there're a lot of geoscientific data sets
IS> (SRTM- and ASTER-derived digital elevation models, some of the
IS> MODIS datasets, Landsat imagery is what comes to mind) which are
IS> referenced to UTM, sinusoidal or other projections. To me, it
IS> looks like that the only field where WGS-84 is predominant in
IS> geoscience is climatology.
AM> Well, the SRTM and ASTER datasets that i found and use are in
AM> WGS-84.
I stand corrected. I've checked the SRTM dataset as it was
obtained and it's in WGS-84. (Seems like we had it reprojected
to match some other dataset.) Still, there're other examples.
AM> And i think of "neogeography" as people with no GIS knowledge at
AM> all handling such data (and who most likely know coordinates only
AM> from their GPS, and the numbers above the wikipedia articles), not
AM> of those people who are well aware of the implications of using a
AM> certain CRS.
The question is: can such people use, e. g., Landsat 7 imagery?
See below for an example where it matters.
AM> Anyway, for the purpose of the document we had reached consensus in
AM> the group to go for WGS-84 as the default, and "keep the door open"
AM> for other CRSes.
The document seems to imply the contrary:
The optional "crs" URI parameter described below may be used by
future specifications to define the use of CRSes other than WGS-84.
This is primarily intended to cope with the case of another CRS
replacing WGS-84 as the predominantly used one, rather than allowing
the arbitrary use of thousands of CRSes for the URI (which would
clearly affect interopability). [...]
AM> I'd very much not like to re-open that discussion again.
[...]
AM> RCPT is a an element of a protocol command, not an identification
AM> scheme. "mailto:" is the corresponding identification scheme - and
AM> people know very well what it means and how to use it, even if it's
AM> printed on a business card - and for that, they don't need to speak
AM> SMTP.
I'm probably missing the point, but I see that aside from
identification, there's a place for a generic and
protocol-independent way to encode geolocation information of
arbitrary objects. Such information, after being encoded, could
be stored in various places -- ASCII files, LDAP directories,
DNS zones, RDBMS databases, etc. Or it can be passed between
processes over the network. Anyway, such information may be
obtained, e. g., by analyzing a georeferenced dataset.
Think, e. g., of a user clicking on a place upon a satellite
image in an image viewer. Whenever the image is properly
georeferenced to WGS-84, it would be trivial to encode the
coordinates the user has clicked on into a geo: URI and to pass
it to, say, some server for dereference.
Now, the situation is the same, and the image is once again
properly georeferenced, but not WGS-84 (e. g., a Landsat image.)
And the whole thing is ruined, as now you're asking an image
viewer (the ``author'' of the geo: URI) to become a GIS and to
convert the coordinates to WGS-84.
That being said, I won't insist that this generic geolocation
encoding I'd be glad to use is necessarily to be performed by
the means of URIs in general and the geo: URI in particular.
AM> Anyway: Let's get the document done, so that we have a stable basis
AM> for whatever things may bloom based on that :-)
I don't insist on the contrary, actually.
--
FSF associate member #7257
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
