Subject: [Geopriv] Some comments on draft-thomson-geopriv-uncertainty-08

From: Brian Rosen <[email-masked]>
Date: Thu, 7 Nov 2013 12:48:50 -0800

I’ve read this draft, and think it is an excellent explanation of the
issues we face in geopriv with measurements.  I highly recommend that we
adopt the draft and process it as a work group item.  I am particularly
happy with the definitions it offers for the various quantities.

I find it lacking in two areas:

1. I think the draft needs to discuss the issues of comparing measurements
with different confidence.  I think the bottom line on that is: don’t do
it, use one agreed upon confidence.

2. I think we need to stop expressing measurements as just the uncertainty
area.  While I understand why doing so is attractive, I think it is not
what real systems do.  Real systems express a measurement and explicitly
state the uncertainty of the measurement.  I think we need a way to express
that.

Brian

---

From: James Winterbottom <[email-masked]>
Date: Fri, 8 Nov 2013 08:02:48 +1100

Hi Brian,

Can you give an example of point 2 please?
I guess all the systems that I am familiar with use the area to express the uncertainty so I am keen to understand how it might be done differently.

Cheers
James

Sent from my iPad

On 08/11/2013, at 7:48 AM, Brian Rosen <[email-masked]> wrote:

> I’ve read this draft, and think it is an excellent explanation of the issues we face in geopriv with measurements.  I highly recommend that we adopt the draft and process it as a work group item.  I am particularly happy with the definitions it offers for the various quantities.
> 
> 
> 
> 1. I think the draft needs to discuss the issues of comparing measurements with different confidence.  I think the bottom line on that is: don’t do it, use one agreed upon confidence.
> 
> 2. I think we need to stop expressing measurements as just the uncertainty area.  While I understand why doing so is attractive, I think it is not what real systems do.  Real systems express a measurement and explicitly state the uncertainty of the measurement.  I think we need a way to express that.
> 
> 
> 
> Brian
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Brian Rosen <[email-masked]>
Date: Thu, 7 Nov 2013 13:49:36 -0800

Sure:

When you get a location from a GPS receiver, it typically uses the NMEA interface, which reports a lat/lon and a Dilution of Precision method of specifying uncertainty.
MLP usually reports location as point with circle, ellipse or arc uncertainty
E2 usually reports location as point with uncertainty

Brian

---

From: James Winterbottom <[email-masked]>
Date: Fri, 8 Nov 2013 09:00:24 +1100

Hi Brian,

MLP and E2 are essentially the same as what we use in Geopriv

Sent from my iPad

---

From: Brian Rosen <[email-masked]>
Date: Fri, 8 Nov 2013 09:33:26 -0800

Not claiming I know more than you, but I think E2 and MLP report position AND they report uncertainty by describing the position as a point, and the uncertainty as the radius of a circle or ellipse.  They don’t just sent a circle.  It’s point plus circular uncertainty, not just a circle.  In PIDF, you can’t tell the difference between a location reported as a circle with no uncertainty specified from a point with circular uncertainty.

The definition of the reported position is the lat/lon of the position and the radius of uncertainty.  We have no similar way to report uncertainty in PIDF.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Nov 2013 09:47:23 -0800

On 8 November 2013 09:33, Brian Rosen <[email-masked]> wrote:
> I think E2 and MLP report position AND they report uncertainty by describing
> the position as a point, and the uncertainty as the radius of a circle or
> ellipse.

That's not the case.

Wikipedia has the DTDs, which show that it's functionally identical to
what is in RFC 5491.

http://en.wikipedia.org/wiki/Mobile_Location_Protocol

---

From: Brian Rosen <[email-masked]>
Date: Fri, 8 Nov 2013 09:57:45 -0800

It’s defined differently.

If I send you a circle, am I specifying a point with uncertainty or a circular location?  There is a difference: in the former, I am telling you that I am specifying circular uncertainty.  In the latter, you don’t know.  A circle with a radius of 99 could be a location report with a circle of radius of 99 with no uncertainty, or it could be a circle with a radius of 33 and an uncertainty of radius 99.
In the former, since you have not specified uncertainty, I don’t know a lot about where the target is. 

MLP defines the radius as uncertainty.  5491 does not.

Brian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Nov 2013 10:34:42 -0800

> MLP defines the radius as uncertainty.  5491 does not.

I really don't want to argue too much about this.  The issue about
what E2, MLP or 32.032 define things to be is not that important.

What I was hoping to do was to create a way that a single PIDF-LO
document could accommodate multiple uses.  That is a relatively simple
thing to do with a small update to 5491 that allows location
generators to include multiple locations.

Of course, that has risks.  The guidance in 5491 is there for a good
reason.  But the good news is that the rules do allow for this to
happen.  You just have to put the most important information first.

---

From: James Winterbottom <[email-masked]>
Date: Sat, 9 Nov 2013 06:15:15 +1100

Sure you can.
We have an explicit radius parameter for circle, you may set this to zero.
We also allow,the definition of just a point.
I think that you will find that the constructs between MLP and GeoShape are almost directly interchangeable.

Cheers
James

Sent from my iPad

---

From: Brian Rosen <[email-masked]>
Date: Fri, 8 Nov 2013 11:39:31 -0800

Martin and I had a chat and we agreed upon a solution.  I’ll write a draft, which will be very short.
What we’re going to propose is an extension to LoST that add a flag to a geo that explicitly states that the area represented by the PIDF represents the area of uncertainty of location in one state, or that the area represents the target with unknown uncertainty in the other state.  If the flag is not present, the assumption is that the sender is clueless the location is that of the target with unknown certainty.

This makes it clear that an area representation of location either does, or does not specify uncertainty.

Brian

---

From: James Winterbottom <[email-masked]>
Date: Sat, 9 Nov 2013 06:41:00 +1100

Okay.

Sent from my iPad

---

From: Randall Gellens <[email-masked]>
Date: Fri, 8 Nov 2013 13:58:36 -0800

>  generators to include multiple locations.

Which is how it was originally.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
God gives us relatives; thank goodness we can chose our friends.

---

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Sat, 9 Nov 2013 00:24:30 +0000

Brian,

I know I'm missing context, but why would LoST care?

-Marc-

On Nov 8, 2013, at 2:41 PM, "Brian Rosen" <[email-masked]<mailto:[email-masked]>> wrote:

Brian

On Nov 8, 2013, at 11:15 AM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Sure you can.

Cheers
James

Sent from my iPad

On 09/11/2013, at 4:33 AM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Brian

On Nov 7, 2013, at 2:00 PM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

Sent from my iPad

On 08/11/2013, at 8:49 AM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Sure:

Brian

On Nov 7, 2013, at 1:02 PM, James Winterbottom <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

Cheers
James

Sent from my iPad

On 08/11/2013, at 7:48 AM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:

Brian

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Nov 2013 21:31:34 -0800

> Which is how it was originally.

Yes, but it was very difficult to consume such a document, which is
why we ended up with RFC 5491.