Subject: [Geopriv] [geopriv] #14: uncertainty specification

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 29 Jul 2009 13:45:27 -0000

#14: uncertainty specification
----------------------------------------+-----------------------------------
 Reporter:  [email-masked]  |       Owner:     
     Type:  enhancement                 |      Status:  new
 Priority:  minor                       |   Milestone:     
Component:  geo-uri                     |     Version:     
 Severity:  Active WG Document          |    Keywords:     
----------------------------------------+-----------------------------------
 The draft currently does not allow for specification of varying
 "uncertainty". The "parameter" scheme would definitely allow the addition
 of such an "uncertainty" value at a later point, though.

 Q) shall the draft specify such uncertainty, or shall it leave that to an
 external specification?

 (Note: the author strongly suggests that this should be left over to
 another draft, as it is always much easier to address problems in smaller
 chunks - and we should keep the base specification as simple as possible)

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/14>
geopriv <http://tools.ietf.org/geopriv/>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2009 15:56:20 +0200

>  Q) shall the draft specify such uncertainty, or shall it leave that to an

The draft should specify an uncertainty radius in meters, either as a 
basic element or as a parameter.

---

From: Ivan Shmakov <[email-masked]>
Date: Thu, 30 Jul 2009 01:01:50 +0700

>>>>> Richard Barnes <[email-masked]> writes:

 >> Q) shall the draft specify such uncertainty, or shall it leave that
 >> to an external specification?

 > basic element or as a parameter.

	And once again, I wonder, how uncertainty in meters is supposed
	to be mapped to uncertainty in degrees?

	Please consider the following examples.

* Assignment #1: drawing uncertainty on a world map

	Given the world map drawn in (longitude, latitude) coordinate
	system with WGS 84 as the datum (you may use the world.dat file
	shipped with Gnuplot for a crude ``continents only'' world map),
	draw the shape corresponding to a spherical circle of the given
	radius, with the given point as its center.

	You will get more credits if you use a Mercator-projection map
	instead.

	* point: 83.75N 53.36E, radius: 500000 m.

* Use case #1: omit insignificant digits

	How do you transform a geo: URI specifying both location (using
	`wgs84' as the coordinate system) and uncertainty (in meters) so
	that the insignificant digits will be omitted?

	* geo:53.36,83.75;crs=wgs84;uncertaintyradius=50000

* Use case #2: spatial relationship

	The application is given a number of geo: URIs specifying both
	location (`wgs84') and uncertainty (meters; varies.)  Is there a
	simple way to find how the locations given are related?  Do
	these URI specify completely distinct locations, or can some of
	them, taking the uncertainty into account, indeed code the same
	location?

	As an example, could you please point the URIs out of the
	following list that can be suspected of being related to the
	same object, just expressed with different precision?

	* geo:53.36,83.75;crs=wgs84;uncertaintyradius=30000
	  geo:53.3,83.7;crs=wgs84;uncertaintyradius=10000
	  geo:52.53,85.17;crs=wgs84;uncertaintyradius=20000

* Use case #3: mapping geo: URIs to mapping services

	The current version of the draft reads:

--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  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 --

	The URL to switch to Google Maps could be constructed as
	follows:

http://maps.google.com/maps?ll=LATITUDE,LONGITUDE&spn=LAT-SPAN,LON-SPAN

	where LATITUDE and LONGITUDE are the coordinates, and LAT-SPAN,
	LON-SPAN give the extent of the map (``spans''; in degrees) to
	be displayed.

	The uncertainty specified within the geo: URI could be related
	to the scale (i. e., LAT-SPAN, LON-SPAN) of the map.  How do you
	calculate the spans given some uncertainty expressed in meters?

* Use case #4: travelling to Kemerovo

	Before travelling to Kemerovo you have taken a look at its
	Wikipedia page [1] and learned its geo: URI:

geo:55.36083,86.08889;crs=wgs84;uncertaintyradius=5000

[1] http://en.wikipedia.org/wiki/Kemerovo

	Travelling to Kemerovo by car, you've glanced at your GPS and
	read:

geo:55.38400,86.09200;crs=wgs84;uncertaintyradius=42

	Do you expect to see the city around, or not yet?

* Use case #1 re-visited: absolute uncertainty

--cut: http://www.av8n.com/physics/uncertainty.htm --
  1.2  How Should Uncertainty Be Expressed?

    If you want to express the uncertainty, express it separately and
    explicitly.  For example, absolute uncertainty can be properly
    expressed as 1.234(55) or equivalently 1.234+-0.055.  Relative
    uncertainty can be expressed as 2900+-13%.
--cut: http://www.av8n.com/physics/uncertainty.htm --

	Given the following geo: URI, how could the absolute uncertainty
	of the coordinates be calculated?

geo:53.36,83.75;crs=wgs84;uncertaintyradius=50000

* And finally, ...

	... given how trivial the cases above become when the
	uncertainty is expressed using the same units as used for the
	coordinates, why should the obstacles be invented?

-- 
FSF associate member #7257

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 29 Jul 2009 18:06:30 -0500

At 08:56 AM 7/29/2009, Richard Barnes wrote:
>The draft should specify an uncertainty radius in meters, either as 
>a basic element or as a parameter.

Richard - is the above said with your chair hat on, or as a member of the WG?

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 30 Jul 2009 06:59:00 +0200

Sorry, all of the comments I've been making on these issues are with the 
individual contributor hat on.
--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 04:10:26 -0500

I would like to see this included, but suggest that the uncertainty is best left as a parameter.  It fits better there.  I don't know what you mean by "basic element", but if it's part of the core list of numbers, then that would risk the data from being mistaken for coordinate data (e.g. the 4th dimension).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Wednesday, 29 July 2009 3:56 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Geopriv] [geopriv] #14: uncertainty specification
> 

------------------------------------------------------------------------------------------------
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: "Alexander Mayrhofer" <[email-masked]>
Date: Thu, 30 Jul 2009 11:18:53 +0200

Richard, Martin,

Are you willing to provide text for the "uncertainty" parameter?

;-)

Alex

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomson, Martin
> Sent: Thursday, July 30, 2009 11:10 AM
> To: Richard Barnes; [email-masked]
> Cc: [email-masked]
> I would like to see this included, but suggest that the 
> uncertainty is best left as a parameter.  It fits better 
> there.  I don't know what you mean by "basic element", but if 
> it's part of the core list of numbers, then that would risk 
> the data from being mistaken for coordinate data (e.g. the 
> 4th dimension).
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 05:13:40 -0500

<!-- ABNF additions -->

<figure><artwork><![CDATA[
  p             = crsp / uncertaintyp / parameter
  uncertaintyp  = ";uncertainty=" pnum
  num           = [ "-" ] pnum
  pnum          = 1*DIGIT [ "." 1*DIGIT ]
]]></artwork></figure>

<!-- BTW, this is needed for extensibility: crsp = "wgs84" / 1*( alphanum / "-" )  -->

<!-- New section above 4.4.3 -->

<section title="Location Uncertainty"> 
<t>The 'uncertainty' parameter indicates the amount of uncertainty in the location as a value in meters.  Where a geo URI is used to identify the location of a particular subject, uncertainty indicates the uncertainty with which the location of the subject is known.
</t>

<t>The 'uncertainty' parameter is optional and it can appear only once.  If no uncertainty is specified, this indicates that uncertainty is unknown or unspecified.  If the intent is to indicate a specific point in space, uncertainty MAY be set to zero.  Zero uncertainty and absent uncertainty are never the same thing.
</t>
</section>

<!-- BTW, you need to s/EPSG:6.6:/EPSG::/g  - the "6.6" is not used in PIDF-LO [RFC5491] -->

<!-- Comment on Section 7
  There is a great deal of duplication here - the mappings are effectively duplicated throughout.  The from geo to GML are exactly the same as the from GML to geo sections with the order inverted.  I don't think this adds value. -->

<!-- Second comment on Section 7 
It's worth noting in general that GML uses the 'double' type from XML schema and that these examples assume that numbers in the form 3.59233e2 in GML are properly converted to decimal when placed in the 'geo' URI.
-->

<!-- Section 7 -->

<section title="2D GML 'Point'">
<t>A 2D GML <xref target="RFC5491">'Point'</xref> is constructed from a 'geo' URI that has two coordinates and an uncertainty parameter that is absent or zero.  A GML point is always converted to a 'geo' URI that has no uncertainty parameter.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
   geo:%lat%,%lon%
]]></artwork></figure>
<figure><preamble>GML document:</preamble>
<artwork><![CDATA[
  <Point srsName="urn:ogc:def:crs:EPSG::4326"
         xmlns="http://www.opengis.net/gml">
    <pos>%lat% %lon%</pos>
  </Point>
]]></artwork></figure>

<t>Note that a 'geo' URI with an uncertainty value of zero is converted to a GML 'Point', but a GML 'Point' cannot be translated to a 'geo' URI with zero uncertainty.
</t>

</section>

<section title="3D GML 'Point'">
<t>A 3D GML <xref target="RFC5491">'Point'</xref> is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is absent or zero.  A GML point is always converted to a 'geo' URI that has no uncertainty parameter.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
   geo:%lat%,%lon%,%alt%
]]></artwork></figure>
<figure><preamble>GML document:</preamble>
<artwork><![CDATA[
  <Point srsName="urn:ogc:def:crs:EPSG::4979"
         xmlns="http://www.opengis.net/gml">
    <pos>%lat% %lon% %alt%</pos>
  </Point>
]]></artwork></figure>

</section>
<section title="GML 'Circle'">
<t>A GML <xref target="RFC5491">'Circle'</xref> is constructed from a 'geo' URI that has two coordinates and an uncertainty parameter that is present and non-zero.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
   geo:%lat%,%lon%;uncertainty=%unc%
]]></artwork></figure>
<figure><preamble>GML document:</preamble>
<artwork><![CDATA[
   <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
              xmlns:gml="http://www.opengis.net/gml"
              xmlns:gs="http://www.opengis.net/pidflo/1.0">
     <gml:pos>%lat% %lon%</gml:pos>
     <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
       %unc%
     </gs:radius>
   </gs:Circle>
]]></artwork></figure>

</section>

<section title="GML 'Sphere'">
<t>A GML <xref target="RFC5491">'sphere'</xref> is constructed from a 'geo' URI that has three coordinates and an uncertainty parameter that is present and non-zero.
</t>
<figure><preamble>'geo' URI:</preamble>
<artwork><![CDATA[
   geo:%lat%,%lon%,%alt%;uncertainty=%unc%
]]></artwork></figure>
<figure><preamble>GML document:</preamble>
<artwork><![CDATA[
   <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
              xmlns:gml="http://www.opengis.net/gml"
              xmlns:gs="http://www.opengis.net/pidflo/1.0">
     <gml:pos>%lat% %lon% %alt%</gml:pos>
     <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
       %unc%
     </gs:radius>
   </gs:Sphere>
]]></artwork></figure>

</section>

<-- I think that's it. I'm in two mins on the need for including anything special in comparison.  On the one hand, I don't like the idea that each parameter gets special treatment.  And special treatment is not possible for any extensions made to the format, making this a form of favouritism.  On the other hand, numerical comparison makes sense for this parameter... -->

--Martin

> From: Alexander Mayrhofer [mailto:[email-masked]]
> Sent: Thursday, 30 July 2009 11:19 AM
> To: Thomson, Martin; Richard Barnes; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] [geopriv] #14: uncertainty specification
> 
> 
> Richard, Martin,
>

---

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

Martin, 

Thanks for that work - i will incorporate it soon into a new revision.
Some comments inline

>   pnum          = 1*DIGIT [ "." 1*DIGIT ]

What about shortening the "uncertainty" parameter name for brevity, for
example to "u"?
 
> <!-- BTW, this is needed for extensibility: crsp = "wgs84" / 

Well. This circles around the issue of "allowing" vs "not precluding". I
deliberately left that out of the current specification, and would have
expected documents adding new CRSes to update the "crsp" component of
the ABNF - and would remove the need for a "crs" parameter value
registry at this point (with being just one CRS defined).

This is a question how "open" we want to be at this point. 
 
> <t>The 'uncertainty' parameter indicates the amount of 
> uncertainty in the location as a value in meters.  Where a 
> geo URI is used to identify the location of a particular 
> subject, uncertainty indicates the uncertainty with which the 
> location of the subject is known.
> </t>
> 
> <t>The 'uncertainty' parameter is optional and it can appear 
> only once.  If no uncertainty is specified, this indicates 
> that uncertainty is unknown or unspecified.  If the intent is 
> to indicate a specific point in space, uncertainty MAY be set 
> to zero.  Zero uncertainty and absent uncertainty are never 
> the same thing.
> </t>
> </section>

Can we refer to some previous work on how "uncertainty" is defined? 

> not used in PIDF-LO [RFC5491] -->

Ack.

>   There is a great deal of duplication here - the mappings 
> are effectively duplicated throughout.  The from geo to GML 
> are exactly the same as the from GML to geo sections with the 
> order inverted.  I don't think this adds value. -->

Ack. Will change.
 
> It's worth noting in general that GML uses the 'double' type 
> from XML schema and that these examples assume that numbers 
> in the form 3.59233e2 in GML are properly converted to 
> decimal when placed in the 'geo' URI.
> -->

Ack.
 
> <t>A 2D GML <xref target="RFC5491">'Point'</xref> is 
> constructed from a 'geo' URI that has two coordinates and an 
> uncertainty parameter that is absent or zero.  A GML point is 
> always converted to a 'geo' URI that has no uncertainty parameter.
> </t>
> <t>Note that a 'geo' URI with an uncertainty value of zero is 
> converted to a GML 'Point', but a GML 'Point' cannot be 
> translated to a 'geo' URI with zero uncertainty.
> </t>

You saying that the uncertainty parameter must be left out, because GML
does not specify it?
 
> <t>A 3D GML <xref target="RFC5491">'Point'</xref> is 
> constructed from a 'geo' URI that has three coordinates and 
> an uncertainty parameter that is absent or zero.  A GML point 
> is always converted to a 'geo' URI that has no uncertainty parameter.
> </t>
> <t>A GML <xref target="RFC5491">'Circle'</xref> is 
> constructed from a 'geo' URI that has two coordinates and an 
> uncertainty parameter that is present and non-zero.
> </t>
> <t>A GML <xref target="RFC5491">'sphere'</xref> is 
> constructed from a 'geo' URI that has three coordinates and 
> an uncertainty parameter that is present and non-zero.
> </t>
> <-- I think that's it. I'm in two mins on the need for 
> including anything special in comparison.  On the one hand, I 
> don't like the idea that each parameter gets special 
> treatment.  And special treatment is not possible for any 
> extensions made to the format, making this a form of 
> favouritism.  On the other hand, numerical comparison makes 
> sense for this parameter... -->

Yes, it's a hard issue. But given that we cannot foresee what future
parameters will be created, i don't think we can create generic language
on parameter comparison (unless we reduce it to textual comparison on
_all_ parameters).

Thanks again for the great (and amazingly quick!) work.

Alex

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 30 Jul 2009 05:32:41 -0500

> What about shortening the "uncertainty" parameter name for brevity, for

Fine with me.

> This is a question how "open" we want to be at this point.

From what I've seen, the ABNF is left open, but the text is more restrictive.  That means that implementations of the base spec don't choke on extensions if they strictly follow the BNF.  You've already done that for parameters, so it's just a matter of consistently applying the principle.
 
> Can we refer to some previous work on how "uncertainty" is defined?

I have an informational doc, but we never seem to get around to discussing adopting it.

http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty

In fact, I've never actually presented it.  I'd like to, one of these days.

--Martin

---

From: Stephen McCann <[email-masked]>
Date: Thu, 30 Jul 2009 18:00:18 +0100

Apologies, but can someone clarify, if Richard's question about
expressing uncertainty in degrees has been answered. With the
beautiful amount of detail in recent answers; I may have missed it.

Kind regards

Stephen

2009/7/29 Ivan Shmakov <[email-masked]>:
>  >> Q) shall the draft specify such uncertainty, or shall it leave that
>  >> to an external specification?
>
>  > The draft should specify an uncertainty radius in meters, either as a
>  > basic element or as a parameter.
>

---

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

> >   pnum          = 1*DIGIT [ "." 1*DIGIT ]

Short question: What would be the semantics of a negative "uncertainty"
value?

Alex

---

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

> Short question: What would be the semantics of a negative 

Please disregard that question, Martin. Plenary brain drain :-/

Alex

---

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

> beautiful amount of detail in recent answers; I may have missed it.

Hi Stephen,

It was Ivan posing the question. My most recent response to this was
(Ivan's text quoted at top):

--- snip ---

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

--- snip ---

I think that uncertainty should be speicified in meters, independent
from the CRS, and the members of the WG that i have spoken to seem to
agree.

Alex

---

From: [email-masked]
Date: Fri, 31 Jul 2009 12:00:55 +0200

> from the CRS, and the members of the WG that i have spoken to seem to

I agree too.

With uncertainty expressed in degrees one has to understand whether that 
means:

1.  (lat+/-u', lon+/-u')

    i.e. the region bounded by (lat-u -> lat+u, lon-u -> lon+u).  The 
shape of
    and area of this region depends on where you are on the globe, and you 
also
    get large problems with wrap-around at the poles.

  or

2.  (lat, lon) +/- u'

    i.e. anywhere within the 3d-chord specified with center (lat, lon) 
subtending
    u degrees.  This is a circular region that has almost the same shape 
and area
    everywhere (WGS84 ellipsoid notwithstanding).

It's slightly tricky - personally if someone said " (51'N, 1'W) +/- 1' " 
I'd probably assume definition 1 above, and take that to mean "50 - 52 N, 
2 - 0 W".

However IMHO definition 2 is more intuitive.  It's also much more 
consistent with specifying the uncertainty in meters.

Ray