Subject: [Geopriv] geo: URI: what about uncertainty?

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 13:58:23 +0700

Any particular reason not to allow for an uncertainty
	information to be specified in the URI?

	Speaking of practical significance, consider, e. g.:

--cut: http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-01.txt --
   <p>one of Vienna's popular sights is the <a href='geo:
   48.198634,16.371648;crs=wgs84'>Karlskirche</a>.

   A web brower could extract the coordinates from the HTML snippet, and
   offer the user various options (based on configuration, context), for
   example:

   o  display a small map thumbnail when the mouse pointer hovers over
      the link

   o  switch to a mapping service of the user's choice once the link is
      selected
--cut: http://www.ietf.org/id/draft-ietf-geopriv-geo-uri-01.txt --

	There, the uncertainty information embedded into the URI would
	allow for the ``small map thumbnail'' or the ``mapping service''
	resolution (or scale) to be determined automagically.  Say, the
	mapping service could select a map resolution so that the given
	uncertainty will be of a few pixels on the screen.

	Examples:

	* geo:53:83;uncertainty=1 -- Barnaul on a global-scale map;

	* geo:53.36:83.75;uncertainty=0.05 -- Barnaul on a
	  regional-scale map;

	* geo:53....:83....;uncertainty=0.0001 -- a street map around a
	  specific location in or near Barnaul.

	(Though note that it should be allowed for the uncertainties on
	different axes to be different.)

	... Finally, following the ``confidence trend'', the comment
	like the one below may come handy.

--cut: www.rfc-editor.org/rfc/rfc5491.txt --
   It is RECOMMENDED that uncertainty is expressed at a confidence of
   95% or higher.  Specifying a convention for confidence enables better
   use of uncertainty values.
--cut: www.rfc-editor.org/rfc/rfc5491.txt --

-- 
FSF associate member #7257

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 28 Jul 2009 09:45:26 +0200

> 	information to be specified in the URI?

I am definitely not the expert who had addressed that for previous
protocols, but i remember there was always a heated discussion (3825
comes to my mind).

First, there's a difference between "uncertainty" and "object dimension"
(uncertainty is how "unsure" the measurement is, while what you describe
is more "what is the approx. Size of the location to be represented).

Then, what is the "dimension" of those values? Is is a circle, or a
sphere? In "natural" space, or in the "projected" space (lat/lon circle,
which would definitely not give a circle in "real world"?) What is the
dimension (meters, inches, degrees?). 

If you want, we can set up a quick chat here in Stockholm about it - and
i would love to have someone who was involved in other "uncertainty"
discussions joining...

Alex

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 02:53:38 -0500

Hi Alex,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alexander Mayrhofer
> Sent: Tuesday, 28 July 2009 9:45 AM
> To: Ivan Shmakov; [email-masked]
> Subject: Re: [Geopriv] geo: URI: what about uncertainty?
> 
> >
 
That's a misleading argument.  The contention in 3825 was for different reasons.

> is more "what is the approx. Size of the location to be represented).

That's a fair comment.  However, as it stands, there is nothing that even helps.  Often size of uncertainty can be used to provide _some_ help.

> dimension (meters, inches, degrees?).

SI units are good.

> i would love to have someone who was involved in other "uncertainty"

I'm sitting right behind you... ;)

> Alex
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 15:27:12 +0700

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

 >> Any particular reason not to allow for an uncertainty information to
 >> be specified in the URI?

 > protocols, but i remember there was always a heated discussion (3825

	ACK.

 > First, there's a difference between "uncertainty" and "object
 > dimension" (uncertainty is how "unsure" the measurement is, while
 > what you describe is more "what is the approx. Size of the location
 > to be represented).

	To my mind, these are not as distinct as it may seem.

	For example, I could post a geo: URI to describe my own position
	for, say, today.  I'm certainly to go visit a few places during
	the day (at least home and work), so there's uncertainty
	associated with my position, and it comes not from the
	instrument's inability to perform the precise measurement, but
	also from my own ``inability'' to stay precisely in one place.

	In other words, the uncertainty always gives the interpreting
	party the area (for 2D) or volume (for 3D) where the object is
	most likely (at 95% confidence) to be found.  The respective
	extents depend, and could be estimated from: the precision of
	the instrument, the characteristic size of the object which
	location is being measured, its characteristic movement
	distance, the intended use of the information being published,
	or, I believe, most commonly, taking into account all of these.

	The above being said, I don't think that a geo: URI may need to
	allow for a detailed specification of all the sources of the
	uncertainty, or why they were assumed, or how they were
	estimated or measured.  However, the simply ``uncertainty as
	delta'' specification is, I guess, will be handy.

	One more example: in different contexts, either of the following
	may be used to refer to the city of Barnaul:

	* geo:53,83;

	* geo:53.4,83.8;

	* geo:53.36,83.75.

	While these aren't ``equal'' per the geo: scheme specification,
	the addition of the uncertainty information could allow for
	these to be related to each other.

	Also, it should be noted, that for a physicist, the following
	URIs look quite /distinct/:

	* geo:53.4,83.8;

	* geo:53.40,83.80.

	While these are ``equal'' per the specification.  Don't know if
	it's of any significance, though.  It may, however, be useful to
	note in the specification that the interpretation of the geo:
	URIs is somewhat contrary to the expectations a physicist may
	have.

 > sphere? In "natural" space, or in the "projected" space (lat/lon
 > circle, which would definitely not give a circle in "real world"?)
 > What is the dimension (meters, inches, degrees?).

	In my opinion, it should always refer to the ``projected''
	space, and use the dimensions used for that projected space.
	For EPSG 4979, for instance, it would be degrees for Y and X,
	and meters for the altitude.

 > If you want, we can set up a quick chat here in Stockholm about it

	?  Could you please be more specific?

	It'd certainly be hard for me to visit Stockholm in the
	foreseeable future.

 > - and i would love to have someone who was involved in other
 > "uncertainty" discussions joining...

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 15:41:51 +0700

>>>>> Thomson, Martin <[email-masked]> writes:

[...]

 > SI units are good.

	... Except that these would be quite hard to apply to the
	(latitude, longitude) pairs as specified by the geo: URIs.

	The location specification reading ``53 degrees latitude
	plus/minus 1000 meters, ...'' seems rather unsound to me.  I'd
	expect the deltas' dimensions to align with the corresponding
	axes' dimensions, as per the CRS used.

	FWIW, the coordinates and the respective deltas will define an
	ellipsoid in the projected space where the object is to be found
	with the specified confidence (e. g., 95%.)

	Note that the ellipsoid defined in one projected space may
	correspond to an arbitrary complex shape in some other projected
	space.  But I'd leave this complexety off the geo: scheme
	specification.

[...]

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 03:48:34 -0500

You make a good point.  Maybe it would be best to leave the complexity out and we can discuss this in a separate draft.  This would specify a new "uncertainty" URI parameter and its semantics.

I support the idea of uncertainty and would be willing to help.

On the point of metres uncertainty, that's how we do it.  For one thing, that makes it more usable by people.

> From: Ivan Shmakov [mailto:[email-masked]]
> Sent: Tuesday, 28 July 2009 10:42 AM
> To: [email-masked]
> Cc: Thomson, Martin; Alexander Mayrhofer; Ivan Shmakov

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 03:50:34 -0500

The instant you raise the point of significant figures in this forum, you are asking for a world of pain.  I'll give you a running start.

I'd actually like to see text that says that 'geo:1,2' == 'geo:1.0000,2.00000' to avoid this issue/trap entirely.

> Behalf Of Ivan Shmakov
> Sent: Tuesday, 28 July 2009 10:27 AM
> To: [email-masked]
> Cc: Ivan Shmakov

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Tue, 28 Jul 2009 11:11:39 +0200

> The instant you raise the point of significant figures in 
> this forum, you are asking for a world of pain.  I'll give 
> you a running start.
> 
> I'd actually like to see text that says that 'geo:1,2' == 
> 'geo:1.0000,2.00000' to avoid this issue/trap entirely.

Actually, i have been personally approached by an AD yesterday,
requesting that i add exactly such text to the draft. I will do that in
the next version to get that document forward.

Alex

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 16:39:57 +0700

>> The instant you raise the point of significant figures in this
 >> forum, you are asking for a world of pain.  I'll give you a running
 >> start.

 >> 'geo:1.0000,2.00000' to avoid this issue/trap entirely.

	Well, it will allow for better scanf (), printf ()
	compatibility, at the least.

 > requesting that i add exactly such text to the draft.  I will do that
 > in the next version to get that document forward.

	Could you please consider a clarification like the following as
	well?

    [...]  In particular, the number of trailing zeros MUST NOT be
    treated as an indication of the precision of the values given.

	Perhaps a generalization should then follow immediately?  Like:

    The digits forming the values MUST NOT be unconditionally assumed
    as all being significant.

---

From: Ivan Shmakov <[email-masked]>
Date: Tue, 28 Jul 2009 17:05:06 +0700

[...]

 >> ... Except that these would be quite hard to apply to the (latitude,
 >> longitude) pairs as specified by the geo: URIs.

 >> The location specification reading ``53 degrees latitude plus/minus
 >> 1000 meters, ...'' seems rather unsound to me.  I'd expect the
 >> deltas' dimensions to align with the corresponding axes' dimensions,
 >> as per the CRS used.

[...]

 > You make a good point.  Maybe it would be best to leave the
 > complexity out and we can discuss this in a separate draft.

	No objections here, but I'm completely unfamiliar with the
	``draft process.''

 > This would specify a new "uncertainty" URI parameter and its
 > semantics.

	I'd rather opt for a set of per-axis parameters.

 > On the point of metres uncertainty, that's how we do it.

	How ``we'' is defined here?

 > For one thing, that makes it more usable by people.

	I don't think so.  One point is whether we're going to have a
	single, or several (one per axis), uncertainty values.

	If the latter way is choosen, how would one apply an uncertainty
	specified in meters to a value in degrees (like a longitude)?

	The former way is no better, as one, once again, cannot easily
	reconstruct the area (or volume) within which the object is to
	be most likely positioned.  At least, one'll have to transform
	the projected space's (x', y', z') triplet to the Euclidean
	space, make a sphere in that space, using the uncertainty as the
	radius, and then transform this sphere back to the projected
	space.  I didn't much research into these ``volume
	tranformations'', but it seems overly complex to me.

	... Especially when compared to simply making an axes-aligned
	ellipsoid in the selected projected space.

	To put it simple, one's going to take a long way to simply draw
	the object's likely position area with MapServer (or GRASS),
	while with the per-axis, axis-aligned parameters it's simple and
	straightforward.

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 28 Jul 2009 06:33:26 -0500

> 	No objections here, but I'm completely unfamiliar with the

We write a different RFC.  That's all.  Generally, we try to reduce things to the smallest possible sized pieces.  Sometimes, this is a really good tool for reducing document complexity.
 
> 	I'd rather opt for a set of per-axis parameters.

RFC 3825 did that.  It only increases the complexity.  Part of the advantage of this geo: URI is its simplicity.  If you want rich expressions of regions of uncertainty, then use an http[s]: URI that resolves to a PIDF-LO (c.f. RFC 5491).  We can do per-axis uncertainty there.

> 	How ``we'' is defined here?

We is the IETF, 3GPP, Google, Apple, you name it.  Those in the location services business.

> 	specified in meters to a value in degrees (like a longitude)?

It's not that hard to apply this subjectively.  I know what 50 metres looks like.  It's the same everywhere.  1 degree longitude is 100km at the equator, but this has two problems.  Firstly, it changes; 1 degree at the poles is zero metres.  Secondly, how many people know what 0.5 degrees latitude is?

> 	ellipsoid in the selected projected space.

The definition of shapes in the documents we have are all made in normal space, not the projected, polar coordinate space.  That would remain.  What you are suggesting seems simpler, but it is FAR more complex when you also consider how users - people - deal with the data.  

> 	while with the per-axis, axis-aligned parameters it's simple and

Nah, it's easy: 
<http://held-location.sourceforge.net/held_js/pidflo.html> 

If you care for additional accuracy, then it gets a little more complex - but that's only dealing with your map projection.

--Martin

---

From: Stephen McCann <[email-masked]>
Date: Tue, 28 Jul 2009 13:48:02 +0200

Why can't these units be expressed in arc seconds. This is how the
uncertainity of celestial objects' orbits' are expressed. e.g. +/-
0.7"

2009/7/28 Ivan Shmakov <[email-masked]>:
>  >>> SI units are good.
>  >> ... Except that these would be quite hard to apply to the (latitude,
>  >> longitude) pairs as specified by the geo: URIs.
>
>  >> The location specification reading ``53 degrees latitude plus/minus
>  >> 1000 meters, ...'' seems rather unsound to me.  I'd expect the
>  >> deltas' dimensions to align with the corresponding axes' dimensions,
>  >> as per the CRS used.
>
> [...]
>
>  > You make a good point.  Maybe it would be best to leave the
>  > complexity out and we can discuss this in a separate draft.
>
>  > This would specify a new "uncertainty" URI parameter and its
>  > semantics.
>
>  > I support the idea of uncertainty and would be willing to help.
>
>  > On the point of metres uncertainty, that's how we do it.
>
>  > For one thing, that makes it more usable by people.
>

---

From: [email-masked]
Date: Tue, 28 Jul 2009 14:17:48 -0400 (EDT)

Ivan -

There has been considerable discussion on uncertainty in this group. You
may wish to read relevant emails and documents.

That said, in geodesy a simple approach (and one that is often used),
positional and local uncertainty become simple indicators of the quality
of position. Positional uncertainty is global or absolute, computed with
respect to the reference frame or datum. Local uncertainty is computed
with respect to adjacent features within the same data set or source.

There are many excellent references on uncertainty and geodetic
coordinates. Just google "geodesy uncertainty".

The point is that this group - in coordination with others such as the OGC
- has invested considerable time discussing uncertainty and how to express
such information within the context of the requirements as defined by this
community. As such, how uncertainty is viewed and expressed is different
than in the traditional GIS industry (where uncertainty is often ignored!)
which is mapping uncertainty and not uncertainty related to an observation
and measurement (as in sensors).

Happy to discuss more if you like :-)

Carl

---

From: Ivan Shmakov <[email-masked]>
Date: Wed, 29 Jul 2009 02:12:20 +0700

>>>>> creed  <[email-masked]> writes:

 > Ivan - There has been considerable discussion on uncertainty in this
 > group. You may wish to read relevant emails and documents.

 > positional and local uncertainty become simple indicators of the
 > quality of position. Positional uncertainty is global or absolute,
 > computed with respect to the reference frame or datum. Local
 > uncertainty is computed with respect to adjacent features within the
 > same data set or source.

 > coordinates. Just google "geodesy uncertainty".

	Thanks.  I'll try to grep over these references.

	Unfortunately, this mailing list seems to bypass the Gmane
	archive, which makes it a bit hard for me to fetch all the
	postings at once for a later grep(1) invocation (and there's no
	grep(1) for either HTTP or NNTP.)

 > The point is that this group - in coordination with others such as
 > the OGC - has invested considerable time discussing uncertainty and
 > how to express such information within the context of the
 > requirements as defined by this community. As such, how uncertainty
 > is viewed and expressed is different than in the traditional GIS
 > industry (where uncertainty is often ignored!)  which is mapping
 > uncertainty and not uncertainty related to an observation and
 > measurement (as in sensors).

	As I've pointed before, there may be different sources of
	uncertainty, e. g.:

	* the uncertainty associated with the measurement method used;
	  (and doesn't it become the mapping uncertainty whenever one
	  uses a map to determine the coordinates of an object?);

	* the size of the object, which location is being measured;

	* the mobility of the object; (but note that the intended
	  longevity of the geo: URI in question should be considered for
	  the mobile objects);

	* privacy considerations.

	Consider, e. g., that one may want to disclose his own location
	so that it could be related right down to the continent, country
	and the city, but not to the street, building, floor and room.
	Even if the measurement done with GPS would give uncertainty
	level closer to the latter, the publisher of the information may
	still deliberately opt for a higher uncertainty.

[...]