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

["Thomson, Martin" <[e-mail]>]

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

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.
 
>  > This would specify a new "uncertainty" URI parameter and its
>  > semantics.
> 
> 	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.

>  > On the point of metres uncertainty, that's how we do it.
> 
> 	How ``we'' is defined here?

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

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

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?

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

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.  

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

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

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