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

["Christian Hoene" <[e-mail]>]

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 [phone] 
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.  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 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.

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

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.

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

...