First, I agree that for many information communities that working solely
with coordinates expressed in WGS 84 is very limiting. For example, forget
doing GIS business in local government if your software only works with
WGS 84 - 2d coordinates!
That said, I have worked location/geo standards activities not only in the
OGC but also in the W3C, OMA, IETF, OASIS, ISO, ITU, ASPRS, OSGeo, GeoRSS,
and so on. I do so to try to insure consistency of the semantics,
modeling, and even the encoding for location payloads.
Based on my 15 years experience doing standards I can categorically state
that in many geo based applications and related encodings for location
that WGS 84 is the default and often only allowed CRS. Period. This is
especially true for what we in the OGC call mass market applications (and
what others call neogeo which is a misleading term). Mass market includes
location services, earth browser apps, car navigation systems, GPS centric
apps, location enabled RSS, authority to citizen alerting, and so forth.
And increasingly, sensor systems are location enabled and guess what -
they provide WGS 84 coordinates. This includes all of the UAVs that I am
aware of.
The issue for all of these applications and related standards that specify
the use of WGS 84 is that they properly document the semantics and usage
of WGS 84. The Terminology section in the geo-uri draft is quite good,
although I will be suggesting some additional words for increased semantic
clarity and reference. We went through very similar dialogues when
developing the GeoRSS information model and the GML Point Profile. In both
of these examples, the default CRS is WGS 84 2d. However, in recognition
that many applications and regions (such as Russia, India, and Australia)
require the use - often as legal mandates - that other CRSs MUST be
supported, the GeoRSS and GML Point encodings support by extension other
CRSs.
I do not see any reason that a similar approach cannot be used with the
geo-uri approach.
Sorry for the long winded response in support of Alexander's logic
regarding WGS 84.
Regards
Carl
>>>>>> "AM" == Alexander Mayrhofer <alexander.mayrhofer@nic.at> writes:
>
> IS> I still have concerns over the lack of support for the sheer
> IS> variety of CRS currently in use. My ``guess'' is that these exist
> IS> on purpose, and not because the parties involved didn't reach an
> IS> agreement. While the intent of the geo: URI scheme is to allow for
> IS> ``a protocol independent, compact and generic way to refer to a
> IS> physical geographic location'', its use for this purpose may be
> IS> hampered by the necessity to perform otherwise unnecessary (and
> IS> wasteful to the computer's resources) projection transformations.
>
> AM> As i said a couple of times (and that seems to be what people i
> AM> talk about that issue think as well):
>
> AM> - WGS-84 is currently clearly the most predominantly used CRS for
> AM> "neogeography"
>
> It isn't. Apparently, there're a lot of geoscientific data sets
> (SRTM- and ASTER-derived digital elevation models, some of the
> MODIS datasets, Landsat imagery is what comes to mind) which are
> referenced to UTM, sinusoidal or other projections. To me, it
> looks like that the only field where WGS-84 is predominant in
> geoscience is climatology.
>
> Yet, as the computing power rises, and allows for even finer
> resolutions to be used for world-scale climatic models, the
> community is forced to look... for other ways to construct the
> modelling grids, which effectively means -- coordinate systems.
>
> AM> - If you use it, the "casual user" won't be surprised, and doesn't
> AM> need transformations
>
> Just to clarify: while the stated purpose of the proposal is to
> ``provide a protocol independent, compact and generic way to
> refer to a physical geographic location'', don't you assume a
> rather specific protocol here? Namely, one with a user seeing
> an URI within his or her WWW browser window?
>
> [...]
>
> AM> - most internet users are not even aware that there's something
> AM> like CRSes.
>
> I don't think that most of the Internet users of today seen an
> RCPT command, either. Nevertheless, SMTP keeps going.
>
> [...]
>
> --
> FSF associate member #7257
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
