Subject: [Geopriv] Geo URI - recap and way forward

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 30 Jul 2009 11:16:05 +0200

(sorry, this is a bit long)

We had quite a lively dicussion on the list and in face to face meetings
over the last few days about the "geo" URI, and i'd like to get the
discussion back on track so that we can progress the document - much of
what was brought forward on the list veers off what imho we had agreed
in previous meetings and discussions.

Regarding the specification of Coordinate Reference Systems:
------------------------------------------------------------

In the session in San Francisco, there was concensus that simplicity is
one of the primary desireable properties of the format. In the
discussion, it was pointed out that it seems to be a good idea that
pushing the complexity to the sender rather than the receiver is good.
This led to the conclusion that using WGS-84 as the most widely used
reference system was a good thing, and there was consensus that
concentrating on a single reference system has less potential to confuse
authors and receivers. 

http://www.ietf.org/mail-archive/web/vcarddav/current/msg00992.html
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00966.html

It was noted that almost any reference system can easily be tranformed
into WGS-84 with freely available open source software (as Ivan has
pointed out as well), however, it is desireable to push the load of
transforming to senders rather than clients - clients might not have the
resources available.

*However*, concerns were raised that if in the future, another reference
system would become the predominant CRS, the scheme would still be stuck
with WGS-84 without an option to specify a different CRS (GLONASS and
Galileo were mentioned, however Carl Reed pointed out that the
differences are negligable:

http://www.ietf.org/mail-archive/web/geopriv/current/msg07302.html

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.

Regarding uncertainty
---------------------

This dicussion recently came up (and, the inclusion of URI parameters
actually opened that "can of worm"). Generally, i have the impression
that the general consensus is that such information would be useful.

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?).

There are various issues with this, including:

- dimensionality
- units
- relation to "crs" parameter?
- comparison of two URIs?

And i am sure there are more. Again, we should take care here to not
violate the original goal of simplicity and brevity - we have an
established mechanism for conveying more complex geometries called
PIDF-LO anyway... 

Way Forward
-----------

I have only heard back from very few people within the group, so will do
the following to the draft document: 

- Add a registry specification for the URI parameters, specifying that
registry
- Clarify text that significant digits should not misinterpreted as
uncertainty
- Extend / clarify the motivation behind a default CRS
- Add text in the style agreed with the chairs in hallway discussions
about privacy

I'd really like to Last Call that before Hiroshima if possible,
especially since i might not be able to attend there.

Comments?

Alex

---

From: Ivan Shmakov <[email-masked]>
Date: Thu, 30 Jul 2009 16:52:51 +0700

>>>>> Alexander Mayrhofer <[email-masked]> writes:

[...]

 > Regarding the specification of Coordinate Reference Systems:

[...]

 > 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

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 30 Jul 2009 12:12:47 +0200

> 	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.
 
> 	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)
 
> 	locations between two agents that already use non-WGS 84 CRS

I would leave that to the specifications which define the additional
CRSes. 

Alex