Re: [Geopriv] Location measurement error

["Thomson, Martin" <Martin.Thomson at andrew.com>]

The problem with location quality (draft plug: draft-thomson-geopriv-location-quality) is that the criteria therein are not designed for consumption by an LS.  The information is intended to be consumed by an LG.  The distinction is important.

Based on this reasoning, the situation is complicated.  Filters as they stand apply well to filtering of information (i.e. don't let me know unless...), location quality issues are related to the generation of location information.  Adding location quality parameters to a filter only result in the filter being invalidated when the LS is not also an LG.  

Dealing with the issue separately is the best approach and I am against adding more complexity to loc-filters.  Quality parameters are enough different to warrant having another document.


I can remember getting some (positive) OGC feedback on draft-thomson-geopriv-uncertainty, but I'm open to receiving more. 


Cheers,
M

> -----Original Message-----
> From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On
> Behalf Of Brian Rosen
> Sent: Tuesday, 15 July 2008 4:04 AM
> To: 'Hannes Tschofenig'; 'Carl Reed'
> Cc: geopriv at ietf.org; Rosen, Brian
> Subject: Re: [Geopriv] Location measurement error
> 
> Although I am happy to have OGC do the actual work, I think we need to
> drive
> the effort towards a (relatively) swift conclusion.
> 
> Towards that end, perhaps we could develop requirements and liaison
> them to
> OGC?
> 
> Loc-filters does not touch this issue yet.  My hope is that there is a
> result from whatever comes of this discussion which makes an "obvious"
> addition to loc-filters to request a notification when a location with
> a
> specified error ("quality") was available.  I certainly want to copy
> something else.
> 
> Brian
> 
> > -----Original Message-----
> > From: geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On
> Behalf
> > Of Hannes Tschofenig
> > Sent: Monday, July 14, 2008 1:26 PM
> > To: Carl Reed
> > Cc: geopriv at ietf.org; Rosen, Brian
> > Subject: Re: [Geopriv] Location measurement error
> >
> > I would feel much better if we push these type of things to the OGC
> (as
> > much as we can).
> >
> > We have so many other things todo in our group. Additionally,
> starting
> > work on these topics within the IETF smells like a recipe for
> disaster.
> > Finally, we don't have the experts on this subject in the group in
> order
> > to produce a high-quality document.
> >
> > I agree with Brian that we should have something in our documents.
> The
> > easiest way for us to get such a work done is to reference something
> > that was already discussed and finished in OGC.
> >
> > There is only a slight problem with that approach: there are a few
> > pieces that reach into our work as well. For example, with the
> following
> > documents there are aspect where uncertainty might reach into our
> > protocol work:
> > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-17.txt
> > http://tools.ietf.org/wg/geopriv/draft-ietf-geopriv-loc-filters/
> >
> > I strongly hope that the former document is fine now. I haven't
> checked
> > the loc-filters since it was re-submitted today.
> >
> > I would also suggest Martin and Jams to forward their uncertainty
> > document to the OGC for review:
> > http://tools.ietf.org/id/draft-thomson-geopriv-uncertainty-01.txt
> > Maybe Carl has an idea on how to tackle that document.
> >
> > Ciao
> > Hannes
> >
> >
> > Carl Reed wrote:
> > > Brian -
> > >
> > > There is some relevant work done (and being done) in the OGC
> related
> > > to this topic. Let me check on the current status and provide some
> > > feedback.  Also, the OGC is totally open to accepting
> > > requirements/change requests from the community and using these
> > > requirements to help drive enhancements to the OGC standards
> baseline.
> > >
> > > FYI, there is an open call for change requests for GML. This open
> call
> > > closes in September. Any individual and/or organization can submit
> > > such change requests.
> > >
> > > So, if the IETF community has any requirements that need to be
> > > considered for the next version of GML, please visit
> > > http://www.opengeospatial.org/pressroom/pressreleases/879
> > >
> > > Thanks and regards
> > >
> > > Carl
> > >
> > > ----- Original Message ----- From: "Rosen, Brian"
> > > <Brian.Rosen at neustar.biz>
> > > To: <geopriv at ietf.org>
> > > Sent: Monday, July 14, 2008 7:56 AM
> > > 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 at ietf.org
> > >> https://www.ietf.org/mailman/listinfo/geopriv
> > >
> > > _______________________________________________
> > > Geopriv mailing list
> > > Geopriv at ietf.org
> > > https://www.ietf.org/mailman/listinfo/geopriv
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv at ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv