Re: [Geopriv] A new draft on Bayesian Location Identifiers

[todd glassey <[e-mail]>]

On 10/21/2010 11:04 PM, Christian Hoene wrote:
> Great Martin,
> 
> thank you very much for your fast and detailed comments! We will
> consider and address them in an updated version. Let's meet in
> Beijing to discuss how to progress.
> 
> See you then
> 
> Christian
> 
> --------------------------------------------------------------- 
> Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS),
> University of Tübingen Sand 13, 72076 Tübingen, Germany, Phone +49
> 7071 2970532 http://www.net.uni-tuebingen.de/
> 
> -----Original Message----- From: Thomson, Martin
> [mailto:[e-mail]] Sent: Friday, October 22, 2010
> 7:13 AM To: Christian Hoene; [e-mail] Cc:
> [e-mail];
> [e-mail];
> [e-mail] Subject: RE: [Geopriv] A new draft
> on Bayesian Location Identifiers
> 
> Hi Christian,
> 
> This is certainly interesting work.
> 
> My biggest concern is that this is not necessarily the right forum
> for this sort of work.  I find that to be a little disappointing, but
> you might find that there is insufficient expertise to deal with this
> here.
> 
> ==Commentary
> 
> My primary concern regards how a recipient of this data might use it.

That is NOT something that the IETF should be concerned with. The
purpose of the IETF is to create technical interoperability standards
for technologies and NOT to control what is and is not routed on the
Internet lest it become a formal lobby and no longer retains its
immunity as a Standards Org.

> I can certainly see how being able to essentially transfer the state
> of a filter between entities might be useful where each performs
> location determination.  I struggle a little more in how I might
> imagine a typical location-based application using the data.
> 
> Providing motivation, use cases, or examples would help greatly.

The issue of how evidence of location is created is key here and the
Bayseian model is a powerful.
> 
> The state of a Kalman filter is relatively easily converted into an
> ellipsoid shape.  Sure, the process is lossy, but it becomes more
> readily understood.  The challenge for you is to motivate the
> inclusion of the covariance matrix.

Agreed.
> 
> In some respects the particle filter is (to me) the most likely to be
> useful to a generic application.  In describing a field of relative
> probabilities you are able to convey a much richer representation of
> location.

For what use models is the question though. What specifically are you
trying to accomplish and what are the constraints with a solution that
meets those needs. For instance there was a new ruling in the California
Courts about evidence being "trustworthy" and how that applies to these
types of controls is that in order that their output be court admissible
and as such useful, they will also need to be trustworthy. And that in
this instance is a legal term and not a technical one which will
probably snow half of this list and piss the other half off, but that's
the way of it in today's world.

>  This is not necessarily the product of a particle filter
> as assumed in the draft; other location determination methods are
> able to produce probability distributions that do not readily fit a
> neat distribution.
> 
> If we were to look solely at filter usage alone, I've found that
> Kalman filters are still far more commonplace.  The additional
> processing required for particle filters is prohibitive, particularly
> for mobile devices that have power consumption constraints.  The
> additional flexibility provided by the particle filter simply isn't
> necessary either, since it is easy to assume linear progress when
> time increments are quite small - as they often are.

Depending on how the filter is implemented and how much of it is in HW.
For instance a nVidia GPU based filter will rip relative to one running
on a P4 Quad Core or like device.
> 
> I'll admit to not being familiar with Gaussian sum particle filters.
> Since the state here is very similar to the Kalman filters with the
> only difference being the number of mean+covariance tuples, it might
> be sensible to try to unify the representation of these.
> 
> ==Coordinate Systems and Datums
> 
> This part of the draft seems a little out of place.  We've already
> done a lot of work restricting the coordinate systems (and coordinate
> reference systems) that are permitted in PIDF-LO.

This by the way is a tremendous mistake. The technology of location
based services is about to take another step forward with new technology
not available before and that also is something this standard needs to
take into account. That the technology underneath the operating model is
continuing to evolve.

> 
> GML already covers a lot of this area.  If you feel that you need to
> use a different coordinate reference system, then it seems likely
> that there is already support for the system that you are looking
> for.  If there isn't, we should discuss your needs, and maybe that
> might be the subject of a separate work item.
> 
> I'd recommend that you remove this section and the corresponding
> additions to the PIDF-LO entirely.
> 
> ==Representations
> 
> The representations that you use could use some more rigorous
> definition.  This requires that you define the structure and
> semantics of each of the elements that you are looking to define.
> Ultimately, an XML schema that defines elements in a specific XML
> namespace is going to be necessary.  Prior to that, we need to know
> exactly what to include, where to include it, and how to interpret
> it.
> 
> The Kalman filter example is quite good.  Attaching a covariance
> matrix to the point location is good.  However, I'd like to see a
> more explicit indication of the units of the covariance matrix (I
> assume that this is metres) and the number of dimensions.
> 
> Leaving messy namespace declarations out, something like this might
> be good:
> 
> <gp:location-info> <filter:KalmanFilterState
> srsName="urn:ogc:def:crs:EPSG::4979"> <gml:pos>-34.407242 150.882518
> 34</gml:pos> <filter:covariance dim="3"
> uom="urn:ogc:def:uom:EPSG::9001"> 1 0 0 0 4 0 0 0 16 
> </filter:covariance> </filter:KalmanState> </gp:location-info>
> 
> Notice how I use <location-info> to establish context.  (BTW, that
> matrix is almost too neat to be real :)
> 
> The particle filter results map very nicely onto an existing GML
> construct: the coverage.  Take a look at Section 19 of the latest GML
> specification for more detail of this.  In effect, we are describing
> the value of the weight function at discrete points.
> 
> Borrowing from the GML definitions and having ParticleFilterState, we
> might get something like:
> 
> <gp:location-info> <filter:ParticleFilterState> <gml:domainSet> 
> <gml:MultiPoint srsName="urn:ogc:def:crs:EPSG::4979"> 
> <gml:pointMembers> <gml:Point><gml:pos>-34.407242 150.882518
> 34</gml:pos></gml:Point> <gml:Point><gml:pos>-34.5 150
> 34</gml:pos></gml:Point> <gml:Point><gml:pos>-34.4 151
> 34</gml:pos></gml:Point> <gml:pointMembers> </gml:MultiPoint> 
> </gml:domainSet> <gml:rangeSet> <gml:ValueArray> 
> <gml:valueComponents> <filter:Weight
> uom="urn:ogc:def:uom:EPSG::9201">0.5</filter:Weight> <filter:Weight
> uom="urn:ogc:def:uom:EPSG::9201">0.25</filter:Weight> <filter:Weight
> uom="urn:ogc:def:uom:EPSG::9201">0.25</filter:Weight> 
> </gml:valueComponents> </gml:ValueArray> </gml:rangeSet> 
> </filter:KalmanState> </gp:location-info>
> 
> Coverages are very well defined in GML.  As a result there are lots
> of options.  For instance, it's probably better to use a DataBlock
> when the number of points starts to get large.
> 
> The Gaussian sum particle filter might be addressed by adding
> multiple pos+covariance pairs to a new GaussianSumParticleFilter
> element.
> 
> You'll note that I've omitted the time component on each of these.
> PIDF already provides a timestamp mechanism that we already use.
> Even where GML provides the capability to convey time, we've opted to
> use the PIDF mechanisms instead, since these help us better integrate
> data with existing frameworks.
> 
> --Martin
> 
> 
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Christian Hoene Sent:
> Friday, 15 October 2010 3:59 AM To: [e-mail] Cc:
> [e-mail];
> [e-mail];
> [e-mail] Subject: [Geopriv] A new draft on
> Bayesian Location Identifiers
> 
> Hello,
> 
> we just have finished a first version of a draft, what presents a
> transmission format for uncertain, relative and transformed location
> estimates: http://www.ietf.org/id/draft-hoene-geopriv-bli-00.txt Any
> comments and any feedback are welcomed.
> 
> With best regards,
> 
> Christian Hoene
> 
> --------------------------------------------------------------- 
> Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS),
> University of Tübingen Sand 13, 72076 Tübingen, Germany, Phone +49
> 7071 2970532 http://www.net.uni-tuebingen.de/
> 
> -----Original Message----- From: IETF I-D Submission Tool
> [mailto:[e-mail]] Sent: Thursday, October 14, 2010 10:51
> AM To: [e-mail] Cc: [e-mail];
> [e-mail];
> [e-mail] Subject: New Version Notification
> for draft-hoene-geopriv-bli-00
> 
> 
> A new version of I-D, draft-hoene-geopriv-bli-00.txt has been
> successfully submitted by Christian Hoene and posted to the IETF
> repository.
> 
> Filename:	 draft-hoene-geopriv-bli Revision:	 00 Title:		 Bayesian
> Location Identifier Creation_date:	 2010-10-14 WG ID:		 Independent
> Submission Number_of_pages: 11
> 
> ...
> 
> _______________________________________________ Geopriv mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/geopriv


-- 
//-----------------------------------------------------------------


This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message.

Thank you for your cooperation.