Re: [Geopriv] Location measurement error

From: Thomson, Martin ^lt;Martin.Thomson@andrew.com>
Date: Tue Jul 15 2008 - 00:22:33 EDT

I have to pick on this statement, because I don't think that Hannes was blunt enough:

> I think we need to standardize the representation of
> error.

*We* already did:

  <http://portal.opengeospatial.org/files/?artifact_id=21630>
  <http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile>
  <http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty>

As Hannes pointed out, there is work that relies on this. Geopriv-policy is good now. The solution is simple, which mercifully avoids a dependency on that last draft. Loc-filters needs much more work because the issue is more complex.

MT

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Rosen, Brian
> Sent: Monday, 14 July 2008 11:56 PM
> To: geopriv@ietf.org
> Subject: [Geopriv] Location measurement error
>
> I'd like to start a discussion on how we deal with, in the big picture,
> the notion of measurement error in general and "confidence" and
> "uncertainty" in specific.
>
> I am aware that there are a set of views that go roughly like: "there
> really is no such thing as confidence and uncertainty, some vendors are
> pushing this idea because they can't do what 'real' GPS devices do and
> give you a 3 dimensional error in meters".
>
> Nevertheless, in one of the most commonly encountered location
> determination mechanisms (A-GPS and similar systems), confidence and
> uncertainty are reported, and are the only error indicator available.
>
> In other systems, notably commercial GPS systems, you get a different
> kind of error specification. Sometimes it's simply error in meters,
> often with a different value for Z than for x and y. Other times you
> get a more complex representation of error.
>
> It does seem to me that when we convey measured location, that it would
> be appropriate to convey the error of the measurement, and that error
> indication should have the ability to represent confidence and
> uncertainty. I think we need to standardize the representation of
> error. It does occur to me to ask if such standardization would better
> be done in OGC, and Carl may wish to comment. It's also possible for
> the geopriv crowd to come up with something and then OGC to incorporate
> it in a future version of GML.
>
> If we had a standardized representation of error, then we could also
> use
> that in protocols like HELD to request a location within a specified
> error bound, and we could also have a filter that requested location
> within such a bound. It would of course, be best to specify the XML
> for
> such a bound once.
>
> I'm specifically proposing that we allow error to be specified one of
> two ways initially: with an actual error measurement, in meters for X,
> Y
> and Z or as a shape (as in our other shape definitions) with an
> "uncertainty" metric in percentage terms. I would add it to GML if we
> could do that, or additional elements in PIDF-LO. I would then
> describe
> an XML data structure to specify a bound, again, either in meters on X,
> Y, and Z or confidence as a shape and uncertainty as a percentage. I'd
> allow the representation of both to be extended for other ways to
> represent error.
>
> Brian
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> 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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Mon, 14 Jul 2008 23:22:33 -0500

This archive was generated by hypermail 2.1.8 : Tue Jul 15 2008 - 00:22:43 EDT