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

From: "Christian Hoene" <[email-masked]>
Date: Thu, 14 Oct 2010 10:58:58 -0600

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:[email-masked]] 
Sent: Thursday, October 14, 2010 10:51 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
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

Abstract:
Location Generators cannot always provide exact measures of 
particular locations. Instead, they estimate the location of 
objects. More precisely, they use filters to aggregate noisy sensor 
data and to calculate probability density distributions of estimated 
positions. In location tracking applications, typically Kalman-type, 
Gaussian-Sum, and Particle Filters are used.

We believe that it is reasonable to use the outputs of those filters 
to describe a location estimate and its uncertainty, because they 
are the natural result of location tracking algorithms. In addition, 
the results of those filters can be feed into sensor fusion and 
decision making engines easily. 

Geometric representations such as polygons or ellipses might be 
demanded by an application. The output of filters can be converted 
to those application demanded shapes. However, these conversions 
come at the loss of precision and are not well understood 
scientifically. Thus, we think that transmitting filter results is a 
solution that is easier to implement.  

In this draft, we present a transmission format for PIDF-LO, which 
is based on the output of Kalman-type, Gaussian-Sum, and Particle 
Filters.

The IETF Secretariat.

---

From: todd glassey <[email-masked]>
Date: Fri, 15 Oct 2010 08:43:07 -0700

> Any comments and any feedback are welcomed.

Two points Christian - this is excellent work.

In my version of the OGC world, the whole schema is tied to the use
models where ranges of location values can be used to trigger coordinate
controls.  I call these ranges physical, virtual and logical.

Logical Locations are things like network addresses, physical can be any
number of location type noticing systems and virtual includes
policy-control to adapt for cloud and ephemeral-process constraints
which need this type of control practice.

Nice work again!

Todd Glassey - as the principal inventor of LOCATION BASED SERVICES in
data security and policy control models.

> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
> 
> 
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.862 / Virus Database: 271.1.1/3195 - Release Date: 10/13/10 11:34:00
> 

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

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.

---

From: "Christian Hoene" <[email-masked]>
Date: Thu, 14 Oct 2010 17:46:35 -0600

Hi,

My recently submitted draft contains a few Latex equations. For those how are not used to read them, I wrote a small script to convert the draft to a pdf file that contains text without $.*$ and the rendered equations. 

With best regards,
 Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Hoene
Sent: Thursday, October 14, 2010 10:59 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Geopriv] A new draft on Bayesian Location Identifiers

Hello,

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:[email-masked]]
Sent: Thursday, October 14, 2010 10:51 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-hoene-geopriv-bli-00 

Abstract:

The IETF Secretariat.

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 22 Oct 2010 13:12:38 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Hoene
Sent: Friday, 15 October 2010 3:59 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Geopriv] A new draft on Bayesian Location Identifiers

Hello,

With best regards,

 Christian Hoene

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, October 14, 2010 10:51 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-hoene-geopriv-bli-00 

...

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 22 Oct 2010 08:04:47 +0200

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

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Friday, October 22, 2010 7:13 AM
To: Christian Hoene; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] A new draft on Bayesian Location Identifiers

Hi Christian,

==Commentary

==Representations

  <gp:location-info>

  <gp:location-info>

--Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Hoene
Sent: Friday, 15 October 2010 3:59 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [Geopriv] A new draft on Bayesian Location Identifiers

Hello,

With best regards,

 Christian Hoene

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Thursday, October 14, 2010 10:51 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-hoene-geopriv-bli-00 

...

---

From: todd glassey <[email-masked]>
Date: Fri, 22 Oct 2010 08:38:48 -0700

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:[email-masked]] Sent: Friday, October 22, 2010
> 7:13 AM To: Christian Hoene; [email-masked] Cc:
> [email-masked];
> [email-masked];
> [email-masked] Subject: RE: [Geopriv] A new draft
> on Bayesian Location Identifiers
> 
> Hi Christian,
> 
> 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.
> 

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.
> 
> 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.
> 
> 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.
> 
> <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>
> 
> 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.
> 
> <gp:location-info> <filter:ParticleFilterState> <gml:domainSet> 
> <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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Christian Hoene Sent:
> Friday, 15 October 2010 3:59 AM To: [email-masked] Cc:
> [email-masked];
> [email-masked];
> [email-masked] 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:[email-masked]] Sent: Thursday, October 14, 2010 10:51
> AM To: [email-masked] Cc: [email-masked];
> [email-masked];
> [email-masked] 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/geopriv