Re: [Geopriv] Location measurement error

"Thomson, Martin" <Martin.Thomson@andrew.com> Tue, 15 July 2008 04:22 UTC

Return-Path: <geopriv-bounces@ietf.org>
X-Original-To: geopriv-archive@megatron.ietf.org
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 330E63A67D4; Mon, 14 Jul 2008 21:22:11 -0700 (PDT)
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B4BF3A67D1 for <geopriv@core3.amsl.com>; Mon, 14 Jul 2008 21:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euQlaMJGuXap for <geopriv@core3.amsl.com>; Mon, 14 Jul 2008 21:22:09 -0700 (PDT)
Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id E442F3A67D4 for <geopriv@ietf.org>; Mon, 14 Jul 2008 21:22:08 -0700 (PDT)
X-SEF-Processed: 5_0_0_910__2008_07_14_23_37_45
X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1
Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 14 Jul 2008 23:37:45 -0500
Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Jul 2008 23:22:34 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 14 Jul 2008 23:22:33 -0500
Message-ID: <E51D5B15BFDEFD448F90BDD17D41CFF1048D9D7B@AHQEX1.andrew.com>
In-Reply-To: <C80ADC57CB3BB64B94A9954A816306C5309BA2@STNTEXCH11.cis.neustar.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Geopriv] Location measurement error
Thread-Index: AcjluVxgd6c6UYTtTjG2JKe6twV/VgAd/8sw
References: <C80ADC57CB3BB64B94A9954A816306C5309BA2@STNTEXCH11.cis.neustar.com>
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Rosen, Brian" <Brian.Rosen@neustar.biz>, geopriv@ietf.org
X-OriginalArrivalTime: 15 Jul 2008 04:22:34.0703 (UTC) FILETIME=[67F6A5F0:01C8E632]
Subject: Re: [Geopriv] Location measurement error
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

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