Subject: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Feb 2008 11:04:14 -0500

There has been some confusion recently about the relationship between
draft-ietf-geopriv-binary-lci and GML.  In particular, the binary-lci
draft specifies how the binary point+uncertainty format can be converted
to a decimal point+uncertainty format, notionally so that it can be used
in GML.  However, GML lacks a notion of precision, so including a point
derived per binary-lci as a point in GML would discard the uncertainty
information.

In order to clarify this so we can move this draft forward, I'd like to
make a suggestion and pose a question:

1. A section should be added to binary-lci to describe how a
point+uncertainty should be expressed in GML.  This could be as a
rectangle (prism), as an ellipsoid, or something else (I'll leave this
to others to describe), but there needs to be a defined conversion to GML.

2. Does anyone intend to use binary-lci for converting to a format other
than GML?  If so, please describe the format and the use case for it.
If not, then perhaps binary-lci should be re-framed as a description of
how to convert from the DHCP format to GML.

Cheers,
--Richard

_______________________________________________
Geopriv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 14:17:51 -0600

Having rescanned the Id just to make sure, the terms "uncertainty" 
and "GML" (which is an acronym actually) aren't mentioned in this ID 
- so I'm having trouble understanding the point being made here about 
these terms in an ID that doesn't mention them...

At 10:04 AM 2/12/2008, Richard Barnes wrote:
>in GML.

Having just (re)scanned the ID just to make sure, the terms 
"uncertainty" and "GML" (which is an acronym actually) aren't 
mentioned in this ID - so I'm having trouble understanding the point 
being made here about these terms in an ID that doesn't mention 
them... can this be explained better?

>However, GML lacks a notion of precision, so including a point

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Feb 2008 22:28:09 +0200

Hi Richard,

I have posted a few comments about the chat we had after the GEOPRIV 
session at the last IETF meeting, see
http://www.tschofenig.priv.at/wp/?p=265
(Our group picture is nice.)

Here are the main issues:

a) When a host receives location information in the RFC 3825 format 
using DHCP then it might need to put it into a PIDF-LO (for example to 
convey it using SIP). The main question here is: What location shape is 
being produced as an outcome of that translation?
b) The answer to the above question is quite important but there is even 
a more important question: Is the location shape provided with RFC 3825 
something that reflects deployment? If the answer is “NO” then the above 
question is also irrelevant.

For question (a) you seem to have come to the conclusion that the 
location information provided by RFC 3825 is not always a point when 
expressed in GML. That's also my conclusion.

BUT: Please note my second bullet. Has someone looked at the real world 
deployment?

Ciao
Hannes

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 14:31:57 -0600

Hi Richard,

Now that we agree GML points don't have a "thickness", and so precision
can't be used in the way the authors intended, if we want to express an
area we require a normative change to the interpretation of 3825. I
think the dilemma you describe below is a little understated.

Martin and I have shown countless times that you can't simply use the
"precision" bits to change the "fat-point" representation into an area
without introducing errors of varying magnitudes in a deterministic way.
To avoid the error problems, or at least contain them, we require a
normative change to the interpretation of LCI.

I believe that there is an intent in 3825 to try and express an area of
coverage. So I don't believe that we can simply say that a point I okay,
because this encoding has spread into other areas, including wireless
because of the examples. We are on the hook to make sure it works
correctly and at the moment it doesn't and the precision bits provide no
value, max length are always used.

If we want to express an area, then there is an alternative draft that
shows how an area can expressed and precision bits can be useful. If
3825 is only for a point, then we should deprecate the use of the
precision bits and the WG should consider a new DHCP option for
expressing location as an area.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Richard Barnes
> Sent: Wednesday, 13 February 2008 3:04 AM
> To: 'GEOPRIV'
> Subject: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
> 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Feb 2008 22:33:11 +0200

I agree with James that this particular document was never meant to 
speak about GML.
I think only later in our discussion I learned that the crucial point 
was the translation of RFC 3825 to GML.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 14:55:56 -0600

James

"we" isn't the WG in your first sentence, "we" appears to be you and 
one or two others.  Hannes's comments weren't at the binary ID 
itself, Richard's questions were at it - which is good. So let's not 
get ahead of ourselves by acting as if everyone is on one side of this issue...

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 15:11:11 -0600

James,

At the end of the Geopriv meeting in Vancouver there was a meeting to
decide how to move forward on this topic.

Marc Linsner, Cullen Jennings, Robert Sparks, Hannes Tschofenig, Richard
Barnes and I were all there, and I believe that the invitation was more
open than that.

Marc made it clear that he expected the fractional component represented
by the loRes and LaRes bits to express the decimal precision of the
resulting GML point longitude and latitude, and this effectively
expresses the area the point covers, a point with "thickness" if you
will. GML points don't have a dimension, so you can't express a point in
this way. Hence the dilemma!

So, either we have an area, in which case serious work is required.
Or, we deprecate the meaning of the meaning and use of the loRes and
laRes fields and go with a point only.

Cheers
James

> From: James M. Polk [mailto:[email-masked]]
> Sent: Wednesday, 13 February 2008 7:56 AM
> To: Winterbottom, James; Richard Barnes; GEOPRIV
> Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
> 
> James
> 
> > > to a decimal point+uncertainty format, notionally so that it can
be
> >used
> > > In order to clarify this so we can move this draft forward, I'd
like
> >to
> > > to others to describe), but there needs to be a defined conversion
to
> >GML.
> > > If not, then perhaps binary-lci should be re-framed as a
description
> >of
>-----------------------------------------------------------------------
--
> -----------------------
>-----------------------------------------------------------------------
--
> -----------------------

---

From: Robert Sparks <[email-masked]>
Date: Tue, 12 Feb 2008 15:19:34 -0600

James Polk was at that meeting IIRC.

I think we have what we need to get past the logjam on this question  
now that we've
learned a little more about how GML can say things.

Richard's proposal looks like a reasonable way forward.

(And I don't have a non-empty answer to his question about non-GML  
customers
for binary-lci - if anyone does, please send that in soon).

RjS

On Feb 12, 2008, at 3:11 PM, Winterbottom, James wrote:

>> get ahead of ourselves by acting as if everyone is on one side of  
>> this
>> issue...
>>
>>> correctly and at the moment it doesn't and the precision bits  
>>> provide
> no

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 15:33:41 -0600

>James Polk was at that meeting IIRC.

I had to leave early, and wasn't there for the obvious fun part...

>>>--------------------------------------------------------------------- --
>>--
>>>-----------------------
>>>--------------------------------------------------------------------- --
>>--
>>>-----------------------
>>>>[mf2]
>>>>

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 12 Feb 2008 16:39:38 -0500

James,

In-line... 

> 
> Marc made it clear that he expected the fractional component 
> represented by the loRes and LaRes bits to express the 
> decimal precision of the resulting GML point longitude and 
> latitude, and this effectively expresses the area the point 
> covers, a point with "thickness" if you will. GML points 
> don't have a dimension, so you can't express a point in this 
> way. Hence the dilemma!

Can GML express the following lat/long values?

1) 38.6, -84.9
2) 25.45, -78.09
3) -18.567, 45.123
4) 31.7654, -82.9853
5) 26.32456, 35.98765
6) 45.345621, -56.987654
7) 23.1234567, -81.2345678

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 15:46:06 -0600

Again you totally either misrepresent what was being said or you
misunderstand it.

38.6, -84.9 in GML is the SAME as

38.600000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000,
-84.90000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000

It is NOT

The range of latitudes and longitudes between 38.60... to 38.69..,
-84.999.. and -84.900...

Or any other range someone wants to try and say it presents. A GML point
has no precision, it is absolute.

So if you are saying that is what you mean, then the loRes and laRes are
already irrelevant.

Cheers
James

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Wednesday, 13 February 2008 8:40 AM
> To: Winterbottom, James; 'GEOPRIV'
> Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
> 
> James,
> 
> In-line...
> 
> >

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 15:51:15 -0600

James

So here's my point, if there is no thickness, they no one can measure 
the point on the ground. Meaning wherever you are, you are billions 
of points, and shouldn't ever be represented by GML -- but that's not 
a way forward is it.

RFC3825 specifies to a location as small as 3.11mm by 2.62mm at the 
equator. Is that a point or an area. Mathematically that's an area, 
but I doubt any other mechanism we've had proposed is as precise for 
a location.

If you, James, were within the 4 walls of an office, you'd be in an 
area, not within a point with an uncertainty.  Your "uncertainty" is 
circular, but the office in this example, just as within any of 
99.999% of all buildings in the world, you'd be within a square or 
rectangle (i.e., within 4 walls).  So if you decide on a means of 
expressing your location as a point in any part of the room, with an 
uncertainty (a 360 degree distance from that point), you'd know there 
was either corners of the room that aren't covered, or portions in 
each of the 4 adjacent rooms you weren't in, yet you would be stating 
with the same certainty you were in.  Uncertainty, used in that 
context is both wrong and broken.

You see, you by definition are an area, so how can anything that 
gives point really mean a point?  GML 3.0 has a point. GML 3.1 and 
beyond has a position (because they realized their mistake) -- which 
doesn't have the same limitations as a point with zero area.

Ultimately, I'd like to get to the point (pun intended) of having 
whatever we use get us to describe our location as a linear ring, 
which uncertainty can't do, and precision can do, but isn't perfect.

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 12 Feb 2008 17:22:12 -0500

James, 

> 
> It is NOT
> 
> The range of latitudes and longitudes between 38.60... to 
> 38.69.., -84.999.. and -84.900...
> 
> Or any other range someone wants to try and say it presents. 
> A GML point has no precision, it is absolute.
> 
> So if you are saying that is what you mean, then the loRes 
> and laRes are already irrelevant.
> 

What I'm trying to say is you can't represent 38.6, -84.9 in RFC3825 without
expressing loRes and laRes.  I have no expection of using the xxRes
parameters outside of RFC3825.

-Marc-

---

From: "Carl Reed" <[email-masked]>
Date: Tue, 12 Feb 2008 15:27:18 -0700

Sure - and using the GML 3.2.1 metadata elements (aligned with ISO 19115 and 
Dublin core), you can provide measures of data quality, such as precision. 
If one looks purely at GML for expressing geometry, then you will encounter 
the issues that this group is discussing. Mathematically as defined in ISO 
10107, a point geometry has zero dimension. However, when one looks into the 
additional GML properties that can be associated with that point geometry, 
then the entire picture and functional capability changes.  Given the cases 
Marc defines below, I could ask the GML implementation community how this 
might best be done. Given that many applications of GML must deal with a 
variety of potential data quality measures, such as fuzzy tolerances, I 
suspect that there is a solution.

Regards

Carl

----- Original Message ----- 
From: "Marc Linsner" <[email-masked]>
To: "'Winterbottom, James'" <[email-masked]>; "'GEOPRIV'" 
<[email-masked]>
Sent: Tuesday, February 12, 2008 2:39 PM
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 16:35:35 -0600

And what I am saying is that 38.6 and 38.6000... are the same thing, so
the res is irrelevant.

> Sent: Wednesday, 13 February 2008 9:22 AM

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Feb 2008 17:38:25 -0500

James,

binary-lci is concerned with converting from a binary point+precision 
format to a decimal point+precision format. (In this case, I think that 
the meanings of "precision" and "uncertainty" align, since you're 
specifying that the actual location doesn't deviate by more than a 
certain amount.)

The question is -- what is that decimal format good for?  GML is the 
obvious candidate, since that's the format that PIDF-LO uses to 
represent location (and the draft *does* mention PIDF-LO).

Hence the two points:

1. The draft needs to say how to convert to GML, since if you're going 
to move location from 3825 to PIDF-LO, then you need to use GML.

2. Are there any other formats that people have a use for?  If not, then 
we should just skip the intermediate format and go straight to GML.

Hope this helps clarify,
--Richard

James M. Polk wrote:
> Having rescanned the Id just to make sure, the terms "uncertainty" and 
> "GML" (which is an acronym actually) aren't mentioned in this ID - so 
> I'm having trouble understanding the point being made here about these 
> terms in an ID that doesn't mention them...
> 
> "uncertainty" and "GML" (which is an acronym actually) aren't mentioned 
> in this ID - so I'm having trouble understanding the point being made 
> here about these terms in an ID that doesn't mention them... can this be 
> explained better?
>

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 12 Feb 2008 17:55:36 -0500

James, 

> 
> And what I am saying is that 38.6 and 38.6000... are the same 
> thing, so the res is irrelevant.
> 

I believe this is where we disagree.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 16:58:02 -0600

Yes I agree that this is where we disagree, and you can't express what
you are trying to say with a GML point as it stands today.

> Sent: Wednesday, 13 February 2008 9:56 AM

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 12 Feb 2008 18:11:55 -0500

James, 

> 
> Yes I agree that this is where we disagree, and you can't 
> express what you are trying to say with a GML point as it 
> stands today.
> 
> 

And what is it that you believe I'm trying to say?

I believe I can take the example original value of 38.6, -84.9, convert it
to binary-lci for transport, convert it back to the same decimal value I
started with (38.6, -84.9) and plug it into application du jour.

So, I believe that whatever meaning the original value had, it maintain that
same meaning at the output end.

Where's the problem?

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 17:15:41 -0600

What value are the resolutions bits providing?

> Sent: Wednesday, 13 February 2008 10:12 AM
> So, I believe that whatever meaning the original value had, it
maintain
> that

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 17:22:49 -0600

Hi James,

> but I doubt any other mechanism we've had proposed is as precise for

Precision aside, you are saying that RFC3825 specifies and area, Marc
and John have consistently said no, it represents a point, both can't be
right.

Marc went on in Vancouver to be clear that he sees 3825 as expressing a
point with thickness, something that straight GML can't do. So the
question is how do we address this problem, and there are two obvious
ways forward:

1) Point, no thickness, resolution parameters are meaningless.
2) Area, we have a problem because using resolution in this way
introduces unpredictable errors.

The status quo is not an acceptable way forward.

I for one would be prepared to concede that 3825 can adequately
represent a point when the precision bits are ignored and the full
extent of the latitude and longitude fields are used to express the
co-ordinates. But this is still a point, no thickness.  

> context is both wrong and broken.

Ummm... Why would I express my uncertainty as a point and radius in this
case? Why wouldn't I just express my uncertainty as area of the room?
If I had to express it as a circle, then I would simply extend the
radius of my circle such that it encompassed the corners. But all this
boils down to select the appropriate shape/volume/way to express the
uncertainty.

But again you have confused confidence and uncertainty. Uncertainty is
the area, confidence is how likely it is that I am in that area. If I
cut the corners off, then my confidence goes down, if I include space in
the adjacent rooms then the area I am expressing is more likely to have
me in it. I don't understand why this is such a hard concept to grasp.

> doesn't have the same limitations as a point with zero area.

Actually, I like to think of myself as a volume.. *8)
Absolutely though, you cannot be contained completely at a point, but
part of me can be located at a point.

> which uncertainty can't do, and precision can do, but isn't perfect.

This is simply not true!  You are defining a GML polygon, which is
uncertainty, though it is not a circle. The whole of the OGC geoshapes
document goes into explaining this in some detail. My argument now, as
it has always been, is that 3825 encoding as it stands cannot be used to
express a polygon without introducing potentially very large errors in a
non deterministic manner. If you want to keep the current option then
the interpretation of fields etc needs to be changed.. please see 3825
bis.

Cheers
James

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 12 Feb 2008 18:24:37 -0500

James,

> What value are the resolutions bits providing?

The ability to represent the original value.

Regardless what you say, significant digits have value.

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 12 Feb 2008 17:28:27 -0600

If your intent was to convey the decimal representation, I wonder why
you didn't consider BCD encoding.  4 bits for each character, 0xf to
represent an unused field...  That would have meant about 45 bits for
each number...the same as what is already needed, but you'd get about
1mm increments between values.

> Behalf Of Marc Linsner
> I believe I can take the example original value of 38.6, -84.9,
convert
> it
maintain

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 17:38:25 -0600

This is frustrating to say the least.

If the format to which you are converting does not, and cannot make the
distinction, then the only way you can enforce what you are saying is to
build a separate interpretation for a GML point to that which is
provided by the OGC. Are you suggesting that you understand this problem
better than they do?

Are you or are you not still trying to represent the error in the number
significant digits with in a GML point?

Cheers
James

> Sent: Wednesday, 13 February 2008 10:25 AM

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 17:51:16 -0600

in-line

At 04:38 PM 2/12/2008, Richard Barnes wrote:
>James,
>
>binary-lci is concerned with converting from a binary 
>point+precision format to a decimal point+precision format. (In this 
>case, I think that the meanings of "precision" and "uncertainty" 
>align, since you're specifying that the actual location doesn't 
>deviate by more than a certain amount.)
>

fair...

>Hence the two points:
>
>1. The draft needs to say how to convert to GML, since if you're 
>going to move location from 3825 to PIDF-LO, then you need to use GML.
>
>2. Are there any other formats that people have a use for?  If not, 
>then we should just skip the intermediate format and go straight to GML.

I agree these two points need to be solved in a Geopriv ID

>>and "GML" (which is an acronym actually) aren't mentioned in this 
>>ID - so I'm having trouble understanding the point being made here 
>>about these terms in an ID that doesn't mention them...
>>mentioned in this ID - so I'm having trouble understanding the 
>>point being made here about these terms in an ID that doesn't 
>>mention them... can this be explained better?
>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 12 Feb 2008 18:30:15 -0600

I'm somewhat disappointed with the turn that this discussion has taken.
But, I suppose I shouldn't be surprised.

So in the interest of progress, I'll make some clear, unambiguous
statements.  I'll withhold opinions in the interest of progress, for
just this one email.  Correct me where I'm start to go astray.

- A point has zero dimensions.

- The location of a Target (we know what this is) may be represented by
a point.  This is known as an acceptable approximation.  Obviously, a
Target occupies more than one point, but at some point we have to be
prepared to say that it is close enough to be considered "correct".

- A point is represented by a set of numbers, one for each dimension.

- A number can be represented in a variety of ways.  A logical value
might be represented lexically as a decimal, or in a binary form.

- Lexical representation can be disassociated from logical value.
Lexical representations may have limitations (e.g. number of bits) that
alter the logical value as seen by two protocol peers.

 - Slight disagreements in logical value can be managed, but user
perception may suffer (speaking from experience, this can cause
problems).  Documenting conventions for managing those disagreements are
helpful.  (In that sense, I agree with Marc about the intent of the Res
bits in 3825; where I disagree is in the implementation, more on that
later.)

 - Uncertainty can be described in a number of ways.  For a location,
uncertainty is described by an area or volume.

 - A single number for each dimension does not include enough
information to describe an area or volume.

 - RFC 3825 defines a particular lexical form for the numbers that make
up a point.  My impression from Marc is that the resolution bits are
intended to help preserve another lexical form, namely the decimal
digits entered by a user.  My impression from James is that the bits are
used to describe an area, but there seems to be some disagreement about
whether that area is an area of uncertainty or not, there seems to be
another way to interpret an area.  The actual RFC says area too, but not
which sort.

That last point is the crux.  It's why there is a new document in the
first place.  In order to answer the questions that Richard has
identified, we first need to answer one question:

        What is it that the RFC 3825 lexical form represents?  Point or
area/volume?

Once you answer that question, Richard's first question [1] is easy.

Cheers,
Martin

p.s. I'd also like to understand the other use of an area too.

[1] The draft needs to say how to convert to GML, since if you're going
to move location from 3825 to PIDF-LO, then you need to use GML.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 18:55:13 -0600

>and John have consistently said no, it represents a point, both can't be

a point is theoretical, as even the top of a pin head has an area. An 
atom has an area, if you could measure it

3825 can't get below a point with an area of 3.11mm x 2.62mm (at the 
equator), and that's an area -- but this isn't the point of this 
discussion, is it?

Aside from the 2s-complement function, removing the loRes and laRes 
values remove the ability of knowing or conveying how much of a 
number is measurable.  It's similar to a subnet mask in IP 
addressing.  The mask indications the demarc of which of the 32 bit 
field is considered to be the network address, and which is left for 
endpoint addressing.  IP routing and forwarding is done based on the 
network address as determined by the subnet mask.  It is a length 
field - yet you want to take it away?

>point with thickness,

I call a point with thickness "an area", so he and I are having a 
terminology issue

>something that straight GML can't do.

According to Carl Reed (today), GML 3.2.1 can do this

>So the

no

>introduces unpredictable errors.

uncertainty has errors too, and you're proposing doing something 
different, yet has errors too.

>The status quo is not an acceptable way forward.

Are you the candidate for change?

(you sound like a politician in the US with that line)

>represent a point when the precision bits are ignored

I for one will not accept this as a way forward

>and the full
>co-ordinates.

This makes be think (again) you don't understand 3825.  The 
resolution bits are set to mean just how many bits in the 34 bit lat 
or long fields can be measurable - or a considered trusted as that 
which was measured.  The rest of the resolution bits are set to 0s, 
which indicate "even if there are 1s in these bits, don't consider 
them to be useful.

One possibility, whose use is debatable, is that a domain 
administrator can reduce the length field bits to indicate less 
precision of the lat or long values.  This was the (written) point 
made of the appendix examples -- though admittedly, few seemed to get 
that point.

>But this is still a point, no thickness.

so, how useful would a lat or long be if you don't have 10-50 digits 
to the right of the decimal point of any "point without any thicknet" then?

What's the distance between 34 degrees and 35 degrees?

How many targets are going to be precisely at the ones digit of a degree?

how many at the tenths digit of a degree?

how many at the hundredths digit of a degree?

How many at the thousandths digit of a degree?

How much farther do I have to go to make this point (with no thickness useful)?

Where's the guidance to implementors on how precise or accurate a 
target needs to be specified?

>radius of my circle such that it encompassed the corners.

well then, since a room most likely has right angles, and you want to 
cover each corner of it with a circle, just how much of each of the 4 
adjacent rooms are you going to cover when you describe or indicate your room?

You've constantly made the point that precision of rooms using a 
linear ring gets less precise at the walls of the room. I call that a 
grey area.  What you're describing here is an outright misinformation 
that your room is actually within 4 adjacent rooms, each with partial 
circles.  Isn't this error in accuracy greater than the imprecision 
of expressing the 4 walls of a room where precision decreases only 
right next to the wall?

I mean, the way I see it, in the middle of a wall, accuracy 
overstates room A as being feet to tens of feet into the next room 
*in 4 directions*...

You cannot convince me that's a better alternative

>But all this boils down to select the appropriate shape/volume/way 
>to express the
>uncertainty.

I disagree.

Give me the most precise points of each corner of a room, and a 
linear ring gives the best representation of the room.  GML even 
covers how a linear ring can have one or more segments represented 
not in a straight line, but as arcs or curves.  This paints a pretty 
good overview of a room, especially in 2D

>But again you have confused confidence and uncertainty.

gee whiz -- I don't like either

>Uncertainty is

and if that point is the size of the room your in, you can be in that 
room - which is a point... which can be represented a lot of the time 
with 3825, and definitely by a linear ring

>uncertainty, though it is not a circle.

Accuracy is a circle, and if a point has zero thickness, then I agree 
with this finite example in which any line of a polygon (in a linear 
ring) can introduce errors.

Science is "best guess", and you want exacts and theories

3825 gives a good version of a best guess, and it comes close.

It's for wired Ethernet environments, which don't need to scale to 
WiMAX scales (i.e., 10s of miles

>The whole of the OGC geoshapes
>non deterministic manner.

no it doesn't

>If you want to keep the current option then
>the interpretation of fields etc needs to be changed..
>please see 3825bis.

that sounds like a threat, btw...

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 19:00:56 -0600

>significant digits with in a GML point?

I think I understand what you are asking, but may not.

The way I read this question, the answer is no -- 3825 is indicating 
the number of bits (in the lat/long/alt fields)  to be considered 
valid, not what should be considered in error.  Option 123 doesn't 
articulate or indicate anything about what should be considered "the 
error" bits or anything like that

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 19:36:13 -0600

>But, I suppose I shouldn't be surprised.

too bad you don't come to IETFs any more, where we can really make 
progress talking about this...

>prepared to say that it is close enough to be considered "correct".

I merge the above two BTW - because an "acceptable approximation" 
hasn't be accepted in anywhere in Geopriv (please point me to the RFC 
if I'm wrong here, and I will scream that I was wrong to the 
world  ;-)   and apologize

>uncertainty is described by an area or volume.

I disagree here.

I believe you are using an antonym of the definition here -- which 
can confuse things quickly.

A synonym of "uncertainty" is "improbability", so an antonym is 
"probability" -- which is interestingly enough, very similar in usage 
to "confidence" (values).

Since probability is the likelihood of something to happen ("how 
confident are you that you can hit that point, James?") -- 
uncertainty must be the inverse of this meaning, which means the area 
covering everywhere else that you don't want to hit or be or are.

Accuracy and Probability, which often get mixed here, are the 
percentage of a chance that a point is within an area or volume.

Statistically, Standard Deviations (SD) are usually used in these 
examples, such as 66-67% is 2/3rds probability or (un)certainty or 
likelihood of something happening or not. That's 1 SD.

2 SDs is 95% probability

3 SDs is 99% probability

>used to describe an area,

because I merge your top two points, I can understand how this is 
misunderstood.

If my 3825 point is 38'N by 86'E, is that a point, or an area? I say 
that depends on the laRes and loRes *from* the perspective of how 
definite the resolution is.  If the loRes and laRes are both set to 9 
bits, then this is not a point. If the Res bits are set to 34, then 
this is a point.  I consider the Res bits to be a component of the 
lat/long/alt fields, and everyone here seems to want to separate 
these bits out as their own independent fields. I don't believe they 
are.  (Dr. John probably will want to smack me for having this belief)

>but there seems to be some disagreement about
>whether that area is an area of uncertainty or not,

here you are using "uncertainty" inappropriately, since uncertainty 
means the inverse of an area

>  there seems to be

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 20:04:47 -0600

Hi James,

If I understand what you are saying, you are saying that the resolution
bits do no make any attempt to encode, quantify, justify, or express
errors in any shape or form?

Cheers
James

> Sent: Wednesday, 13 February 2008 12:01 PM
> To: Winterbottom, James; Marc Linsner; GEOPRIV

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 12 Feb 2008 20:35:04 -0600

Hi James,

I've responded below.

> Sent: Wednesday, 13 February 2008 12:36 PM
> To: Thomson, Martin; Winterbottom, James; Marc Linsner; GEOPRIV

I'll be there in July - the problem is that the company isn't really
willing to pay for two people to travel.  It's not cheap coming all the
way from Australia.  James has pulled the short straw more often than I
recently.  We'll both be there when the IETF comes back to Australia.

If the issue isn't resolved by then, I'll be happy to chat.

> if I'm wrong here, and I will scream that I was wrong to the

I was just being pragmatic.  Points are much easier to manage than
areas.  We model the Target as a point because that's easier than
assuming a finite shape of some strange geometry.  Using a point for the
location of the Target has drawbacks, but it's simplicity is a merit.  I
was putting forward the suggestion that for some cases, a point is
acceptable once those drawbacks have been considered.  
 
> likelihood of something happening or not. That's 1 SD.

Actually, I'm using the definition of uncertainty that is common in
measurement circles.  There are really decent primers out there that go
through this.  The synonym "improbability" isn't quite correct -
uncertainty is a quantifiable value that quantifies the magnitude of a
probable error.  The associated value for probability is called
"confidence" (again from those same sources).  Confidence gives you the
probability that the measurand (i.e. the actual, true, or correct
location of the target) is within the bounds that have been described.

I suspect that when you say "accuracy and probability" you really mean
to say "uncertainty and confidence".  As a term, "accuracy" is out of
favour, since it is used ambiguously.  It's use has been restricted to
qualitative contexts only.

Note also that standard deviations only apply as you say if the
probability distribution function (PDF) is Gaussian.

All of this is in my uncertainty draft.  I highly recommend that you
read it.
	http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty-00

There is an excellent guide from NIST that was very helpful for me:
	http://physics.nist.gov/Pubs/guidelines/contents.html
I reference this from my draft.  The appendix (D1) describes
terminology.
 
> are.  (Dr. John probably will want to smack me for having this belief)

I'll leave this for the time being, pending resolution of the prior
points.  You are asking the right question though.  My interpretation of
RFC 3825 is pretty much how you describe it there, even if you use
different terminology.  Let's resolve the terminology issue and maybe we
will all be able to disagree in the same language ;)

The other problem is that your answer differs from Marc's (I think).
Once again, if we start talking the same language, this can be resolved.
Unless of course someone decides that they don't want it resolved.
(I'll confess that I've found these discussions quite entertaining, but
I'm not doing for entirely recreational purposes.)

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 21:06:22 -0600

>errors in any shape or form?

it's a length field of valid bits, it's not for errors, no

the resolution fields indicate how much (left to right) of the lat 
and long and alt fields (all which are separate) are to be considered 
either (as a length field of the binary):

#1 - to be trusted as valid
or
#2 - the maximum that allowed to be revealed from within that domain

in the 34 bit lat and long fields, the first 9 (from the left) are 
converted to an integer to the left of the decimal point, the next 25 
bits are converted to be on the right side of the decimal point.  We 
specified 2s-complement to get the +/- signs (i.e., directions) from 
prime meridian (which is less agreed upon for altitude, as you'll 
notice in 3825)

Dr John reeeeally doesn't like #2, but it is a usage -- but it 
directly addressed a requirement at the time (2002-2004) for the 
ability to obscure, without lying (!), where a target was. The WG 
agreed one good way was to give a larger area as an answer.  This 
didn't really translate well into the later to be published RFC 4119.

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 21:28:55 -0600

The reason I asked is that is inconsistent with the "clarification"
document, that is the source of these discussions. I quote from the
NORMATIVE section of the document:

"Where a geographic location comes with an explicit error specification,

this error can be translated into the resolution of the LCI.  If the  
error measure is in distance (e.g. meters) rather than degrees, the  
conversion of longitude to degrees depends on the distance from the  
equator.  Dividing the error distance by the distance for one degree 
(computed with the method described at [6]) yields the error in 
(presumably fractional) degrees."

So I think what you are saying is that the result of decoding 3825 LCI
is in fact 4 points that form a ring enclosing area, and this is not
what Marc is saying, he is saying it is a fat point.

I think the enclosed area is what you want, but I don't see how you get
there using the explanation in 3825, without the errors that Martin and
I have described. I don't see the fat point as a reasonable
interpretation at all for reasons of compatibility that I have already
described.

Cheers
James

> Sent: Wednesday, 13 February 2008 2:06 PM
--
--

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 21:56:00 -0600

Martin

in-line below

At 08:35 PM 2/12/2008, Thomson, Martin wrote:
>willing to pay for two people to travel.

bummer, but I understand

>It's not cheap coming all the way from Australia.

you live a long ways away...

>James has pulled the short straw more often than I

your company needs to host it, as I'd love to come back. Adelaide was awesome!!

>acceptable once those drawbacks have been considered.

I wish we could get out all these points and come to an agreement...

>through this.

well... my thesis is on probability so I do know a thing or two about it

>The synonym "improbability" isn't quite correct -
>probable error.

it's the inverse of probability or confidence where

         probability (or confidence) + uncertainty = 100%

>The associated value for probability is called
>"confidence" (again from those same sources).

I said this above already, so I'm glad you agree with what I said  ;-)

>Confidence gives you the

I define this above also, so we're seeing eye to eye more and more

>to say "uncertainty and confidence".

not quite. Please re-read what I said above

>As a term, "accuracy" is out of favour, since it is used ambiguously.

I've never liked "accuracy" (but I know what it is) because people 
mix the definition with precision and resolution too often.

>It's use has been restricted to qualitative contexts only.
>

I mentioned standard deviations as more tutorial above because a lot 
of folks don't know why 67% (or 2/3rds) and 95% and 99% as used so 
often... standard deviations is why (being one, two and three 
standard deviations ,respectively)

>The other problem is that your answer differs from Marc's (I think).

yeah, I know it does. He and Dr John talk about a point as just that, 
a dimensionless point (similar to the intersection of two lines, 
which obviously have no 3rd dimension -- therefore no mass or volume 
(or even area).

> > means the inverse of an area

Let me give you an example of how I define (and have a problem with) 
"uncertainty".

You and I go to a bar and there's a dart-board.  I ask if you've ever 
played darts before, and you say you have, but are not an expert.

We go over to the dart-board and I arbitrarily ask you how certain 
you are that you'll hit the dart board, and not the wall? In other 
words, I ask what are your changes of hitting the dart-board?

If you were to answer this with a number, you'd give me either odds 
or a percentage of certainty (NOTE: here this is not a percentage of 
UNcertainty!!)

Whatever value you give me, you're not giving me what your chances 
are that you'll hit the wall (or floor), you are giving me the 
chances you'll hit a (happens to be) round area approximately 10 feet 
away from you. See, you're focusing on the dart-board, aiming at the 
dart-board - and not everything *but* the dart-board.  Using your 
terminology, you're focusing on how certain you are that you'll make 
the shot and *not* how uncertain you are that you'll actually miss 
the shot.  In other words, your focus is on the certainty of it, yet 
above you corrected me to say this is the uncertainty value -- and 
clearly this is not what you are doing (i.e., focusing on).

Furthermore, your stated chances can be converted into a probability, 
or odds, of success.  The INVERSE of that are the odds of your lack 
of success. This is the UNcertainty, and it doesn't have an area 
assigned to it, it has a "everything BUT the dart-board area assigned 
to it". This makes it an inverse.

Now, that said, if
         probability + uncertainty = 100%
then
         probability  = 100%/uncertainty
and
         uncertainty = 100%/probability

In order for one variable to gain, the other has to lose.

Your terminology has
         certainty + uncertainty = 100%

I can live with this
         certainty = probability
and
         uncertainty  = improbability

though I don't like this second pairing

but I have to think about
         certainty = confidence
to use
         confidence + uncertainty = 100%

and follow it with the ease you use the terms -- mostly because I 
strongly tend towards the positive term first (probability and 
confidence and certainty) whereas almost 100% of the discussions 
using these two terms focus on the negative (failure) term of 
uncertainty (and improbability if this was ever used - but I don't 
remember it being used in any discussion).

James

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 12 Feb 2008 22:05:42 -0600

Remember, I'm not an author of draft-ietf-geopriv-binary-lci, so I 
cannot be convicted, nor should the ID be for my opinions...

;-)

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 12 Feb 2008 22:09:20 -0600

Lol.. *8)

Won't bite!

> Sent: Wednesday, 13 February 2008 3:06 PM
> > > > > >Are you or are you not still trying to represent the error in
the
> > > >number
> > > > > articulate or indicate anything about what should be
considered
> >"the
--
--

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 12 Feb 2008 22:53:36 -0600

Hi James,

>          probability (or confidence) + uncertainty = 100%

And now I understand where your confusion comes from.  You have a
definition of uncertainty that has a strong basis (your thesis, which I
assume wasn't a doctorate thesis, or you'd be Dr. James).  I have a
different definition with a similarly strong basis (experience with
location services).  The problem is that they are very different
definitions.

(Honestly, this is the first time that I've seen the term "uncertainty"
used in that way.  Seeing you explain it the way you did explains a
whole lot.  I'm more used to talking about the probability of an event
occurring and the probability of an event *not* occurring.)

Really, I'd strongly recommend reading some of the documents that I've
linked.  The term "uncertainty" has a very definite meaning in the
context of measurement in general and location services in particular.
Think about the poor guys who measure the weight of an electron [1] and
you are heading in the right direction.  You can get good information on
this sort of thing from measurement laboratories all over, NIST in the
US, the NPL measurement labs in the UK, the BIPM (the folks who do SI
units) in France, and so on.  The terminology isn't exclusive to this
sort of measurement, it's widely used in the scientific and engineering
field, but the labs have produced some excellent material, like the NIST
guide I referenced earlier.

The darts example isn't very good, because there is a very definite
result - when you measure a result, the dart hits on one side of the
wire or not.  As a poor player, and a sober one (two conditions that
agree perfectly) I might only have a 10% chance of hitting 20 points,
but the result when I throw the dart is definite; it's either 20, or not
20.  The result is absolutely accurate.  (If it hits the wire squarely,
it probably bounces off and hits someone in the foot, which counts as
"not 20", not that that has ever happened...)

A better example would be to look at measuring the length of a piece of
string.  There is an actual value, but it's hard to know exactly what it
is.  Give the same piece of string to 10 people and tell them to measure
it as accurately as they can and you will get 10 different results.  If
you were interested in getting the most accurate value, you'd toss
outliers and pick the average of the remaining results.  But that value
is not the true value any more than any one of the measurement results
were.  Uncertainty and confidence are terms that are used for this
scenario.

Cheers,
Martin

[1]
http://physics.nist.gov/cgi-bin/cuu/Value?me|search_for=electron+mass

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Feb 2008 07:44:01 -0600

What the billy-oh is a "point with thickness"?!

Is it some strange creature which is neither a point nor an area? Why
did we need this term? What shape is this "thickness"?

For my edification Marc, is the point 38.6, 84.9 a piece of thickness
covering 38.60 recurring to 38.69 recurring and 84.90 recurring to 84.99
recurring?

That is, I've been told that only the first decimal digit is significant
- quite explicitly - by the protocol - it's 38.6xxxx.. 84.9xxxx.. 

Is that a rectangle with those extents or is it an ellipse with those
extents? What am I supposed to do with the resolution information?

I'm assuming that the protocol went to the trouble of telling me that
only the first decimal digit is significant for a reason - otherwise I'd
just interpret the values to be what James W wrote below (to notionally
infinite precision).

Here's what I think:
The bin-dec draft which is the subject of this thread actually just says
turn the value into a point. The resolution values get thrown away and
two decimal values remain which don't have any explicit precision
guidance. Sure, they only have so many digits - but outside of a 3825
context, this doesn't imply anything and, anyway, it's not clear what it
means inside a 3825 context either.

If the intent had been to convey an area (i.e. a rectangle or ellipse or
whatever shape is supposed to be inferred) then the conversion would
have been into a corresponding set of parameters. If it was a rectangle,
then it would have been four ideal points or one point and two lengths.
If it was an ellipse, it would have been one point and the major and
minor axis lengths (orientation in both cases is forced to North-South
by the paucity of information).

Since the draft just says the result converts to two decimal values, I
am forced to assume that the intent is just to convey a point. As James
W says, this could have been done in 3825 just by using zeroes and not
bothering with resolution parameters.

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Winterbottom, James
Sent: Wednesday, 13 February 2008 8:46 AM
To: Marc Linsner; GEOPRIV
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

It is NOT

Cheers
James

> Can GML express the following lat/long values?

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Marc Berryman" <[email-masked]>
Date: Wed, 13 Feb 2008 08:32:54 -0600

If 38.6, -84.9 in GML is the same as 38.60000, -84.90000, then we have a
big issue.

38.6, -84.9 would put me within a few miles of a precise location, 
38.60000, -84.90000 would put me within about an inch of a precise
location.

If I interoperated 38.6, -84.9 to be the same as 38.60000, -84.90000,
then clearly we need another indicator to say the precision is within .1
degree and not .00001 degree.

Marc B

-----Original Message-----
Sent: Tuesday, February 12, 2008 3:46 PM

It is NOT

Cheers
James

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Feb 2008 10:01:42 -0500

Martin,

I don't believe it's the task of the IETF to explain how to utilize
significant digits within the application of geo location.  This is a
often-used well-understood concept within that discipline.

Are you still satisfied with your proposal from 1 year ago?  

Snipped from an email you wrote on 2/7/07:

snip------------------------------------------------------------------------
------

Hi Marc,

At this stage, I'm quite happy to put all of this aside as the result of
miscommunication.

I think you summarized it excellently when you said:

"So can we agree that to the extent uncertainty can be conveyed via
significant digits, 3825 does such?"

If there was a summary for 3825 that went:

"The resolution parameters communicated by 3825 indicates the number of
significant digits that the corresponding location parameters are to be
interpreted as having. To the extent that uncertainty or area can be
conveyed via significant digits, 3825 permits this."

You may feel that this is the same as the sentence that you quote below -
however, I genuinely interpreted it as saying that significant digits did
not convey an area, and subsequent discussion didn't obviate the impression
that that was the intent. Something quite explicit as above would make the
conversion document much clearer - at least for me. In fact, I don't think
you really needed to explain how to encode and recode a quantity provided
with explicit significant digits. As you say below, it's well understood
art. A two line clarification as above would have completely done the trick
for 3825 for me.

Cheers,

Martin

snip------------------------------------------------------------------------
-----------

-Marc-

> From: Dawson, Martin [mailto:[email-masked]] 
> Sent: Wednesday, February 13, 2008 8:44 AM
> Is it some strange creature which is neither a point nor an 
> area? Why did we need this term? What shape is this "thickness"?
> 
> For my edification Marc, is the point 38.6, 84.9 a piece of 
> thickness covering 38.60 recurring to 38.69 recurring and 
> 84.90 recurring to 84.99 recurring?
> 
> Is that a rectangle with those extents or is it an ellipse 
> with those extents? What am I supposed to do with the 
> resolution information?
> 
> I'm assuming that the protocol went to the trouble of telling 
> me that only the first decimal digit is significant for a 
> reason - otherwise I'd just interpret the values to be what 
> James W wrote below (to notionally infinite precision).
> 
> Here's what I think:
> The bin-dec draft which is the subject of this thread 
> actually just says turn the value into a point. The 
> resolution values get thrown away and two decimal values 
> remain which don't have any explicit precision guidance. 
> Sure, they only have so many digits - but outside of a 3825 
> context, this doesn't imply anything and, anyway, it's not 
> clear what it means inside a 3825 context either.
> 
> If the intent had been to convey an area (i.e. a rectangle or 
> ellipse or whatever shape is supposed to be inferred) then 
> the conversion would have been into a corresponding set of 
> parameters. If it was a rectangle, then it would have been 
> four ideal points or one point and two lengths.
> If it was an ellipse, it would have been one point and the 
> major and minor axis lengths (orientation in both cases is 
> forced to North-South by the paucity of information).
> 
> Since the draft just says the result converts to two decimal 
> values, I am forced to assume that the intent is just to 
> convey a point. As James W says, this could have been done in 
> 3825 just by using zeroes and not bothering with resolution 
> parameters.
> 
> Cheers,
> Martin
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Winterbottom, James
> Again you totally either misrepresent what was being said or 
> you misunderstand it.
> 
> > > represented by the loRes and LaRes bits to express the decimal 
> > > precision of the resulting GML point longitude and latitude, and 
> > > this effectively expresses the area the point covers, a 
> point with 
> > > "thickness" if you will. GML points don't have a 
> dimension, so you 
> > > can't express a point in this way. Hence the dilemma!
> >

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 13 Feb 2008 14:23:49 -0600

At 10:53 PM 2/12/2008, Thomson, Martin wrote:
>outliers and pick the average of the remaining results.

the mean, actually

>But that value is not the true value any more than any one of the 
>measurement results
>were.

This is where Standard Deviations come in, in measuring the mean, 
measuring the first, second and third Standard Deviations and 
producing a bell curve probability.

If you string measurements from the 8 middle people's results (having 
tossed away the outliers), your bell curve should show results you 
can give, and how far off each other each measurement was.

All this is predicated on the belief that 8 samples are good enough 
to make a prediction.

The problem I have with location measurements of endpoints - is there 
is only one of them at a time, and that's not the best sample size.

>Uncertainty and confidence are terms that are used for this scenario.

If you agree that "confidence = probability", then I call this the 
probability that something is or isn't going to happen.  The biggest 
difference that I see from out thread is that it doesn't appear that 
anyone but me is considering Standard Deviations as an indicator of 
likelihood a target is within an area (say a room) or not. If I were 
to really get into uncertainty, I'd peg the "uncertainty" value into 
the bell curve as a function of how many Standard Deviations is acceptable.

If the area is 100m wide, and you're looking at whether a target is 
in or out of an area, and the first Standard Deviation is 30cm, then 
I'd say however you're measuring where the target is, you've done an 
outstanding job of defining that area to give an uncertainty value of 
a very low number.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 13 Feb 2008 16:32:58 -0600

Well I would be if there was some explicit acknowledgement that the goal
is to convey uncertainty at all. I find terms like "a point with
thickness" evasive with respect to this question.

Yes - significant digits is a well understood concept. If I explicitly
know that 38.6 is significant to one decimal point then I can express
the value as 38.65 +/-0.05 - that's the well understood concept.

What certainly isn't clear is what the intent of the authors is with
respect to the interpretation of the LAT/LON set with precision. The
intent seems to be that it conveys an uncertainy (e.g. per Polk) while
the commentary excuses its limitation on the basis of it being a point
(per Linsner).

If the intent is that it conveys uncertainty:

1. What shape of uncertainty should be inferred for, say, 38.65 +/- 0.05
degrees and 84.95 +/- 0.05 degrees? Rectangle? Ellipse?

2. What if I want to represent an area of uncertainty between, say, the
lines of latitude 38.996 and 39.008? I'm quite likely to want to do this
and I can't do it using precision.

The latter of the two is the most critical issue with trying to use
significant digits to convey a geographic area of uncertainty. It's also
what leaves some of us wondering why the resolution scheme is used at
all.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Thursday, 14 February 2008 2:02 AM
To: Dawson, Martin; 'GEOPRIV'
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Martin,

snip--------------------------------------------------------------------
----
------

Hi Marc,

You may feel that this is the same as the sentence that you quote below
-
however, I genuinely interpreted it as saying that significant digits
did
not convey an area, and subsequent discussion didn't obviate the
impression
that that was the intent. Something quite explicit as above would make
the
conversion document much clearer - at least for me. In fact, I don't
think
you really needed to explain how to encode and recode a quantity
provided
with explicit significant digits. As you say below, it's well understood
art. A two line clarification as above would have completely done the
trick
for 3825 for me.

Cheers,

Martin

snip--------------------------------------------------------------------
----
-----------

-Marc-

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 13 Feb 2008 16:51:02 -0600

I fear that we might be losing focus on the goal, but while this is constructive, it's worthwhile continuing.

> Sent: Thursday, 14 February 2008 7:24 AM
<snip>
> the mean, actually

Touché
 
> can give, and how far off each other each measurement was.

I've said this before, but bell curves aren't universally applicable.  Different measurements result in different forms of PDF.  The Gaussian distribution only applies where there are a significant number of small, cumulative errors.

> is only one of them at a time, and that's not the best sample size.

If you read some of the material on the topic, the method for measurement can be analysed.  There are documented methods for analysis and combination of errors.  Do some reading on the Monte-Carlo method, which is the current best practice from what I can gather.  The result of these processes is a mean value and an uncertainty, which might correspond to half-width at half-maximum, one standard deviation, or, as is most common for location, a particular confidence value (or probability).

Location estimates, leaving wire-tracing aside for the time being, often use least-squares agreement to determine a result.  The outcome of this process is an estimate (x, y, z) plus a set of residuals.  These residuals can be used to produce information on the standard deviation on each dimension.  This is usually from a single observation that uses multiple measurement results to determine a final value (think about measuring the range to a GPS satellite - you need multiple satellites to determine a position).  There are other heuristics that can be added to refine the process, like taking data from other similar observations and applying that knowledge to the result.

In short, location is often measured just once, but that does not necessarily imply that information about probability distribution is not available.

> likelihood a target is within an area (say a room) or not. 

You are so close to what I've been saying; except that, as I say above, standard deviations aren't the only (or even best) indicator of the size of uncertainty.  If we assume a Gaussian distribution, then you can use them.  I many scenarios, you can only assume a Gaussian distribution if there are more important considerations than being right.

>If I were

I think that I've lost you.  When you talk about a 100m wide area, are you talking about determining whether a Target is within an area (such as might happen with LoST)?  Because, in that case, the uncertainty in location is 30cm, and the exact shape (Circle ~39% or Sphere ~19%) will determine the confidence of that measurement.  Perhaps a more concrete example would help.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Feb 2008 18:15:17 -0500

I get this feeling you guys are bashing each other for sport; that you
really do understand the other guy's point of view, you know that what they
are saying has merit, and yet you can't agree to come up with a compromise.
I know my thinking has evolved some over time.

The DHCP crowd is using normal engineering language and normal statistical
analysis to discuss what we usually call "precision" whatever term you would
like (I'm going to use "precision" here, but you can turn that into any term
you want).  They refuse to discuss the notion that they only get one sample,
it isn't possible to calculate a meaningful standard deviation, the error
distribution isn't Gaussian and that there is so much experience in location
measurement that they have to resort to other, reasonably sound mechanisms
to express precision.

The mobile phone measuring crowd is using normal location measurement
language, and statistics created specifically for this environment to
discuss precision.  Since they can't actually give you the normal
engineering expression of precision (significant digits and standard
deviation or computable equivalents), they give you what they all decided
what they could give you, which is something they defined, precisely, and
call "confidence" and "uncertainty".  

I gather the GML folks made a mistake, and they seem to be correcting the
mistake.  Significant digits do indeed matter.  If I say I am located at
73,21 with an uncertainty of 1 cm and a confidence of 95%, then they really
truly must say 73.0000, 21.0000 and not imply it if that is what they
actually measure.  Note that I have not done the calculations, and I don't
know how many significant digits I need to express 1 cm precision in an
engineering sense.

However, the mobile phone measuring crowd has a valid way to express
precision, and they all have agreed to use it.  For the DHCP crowd to say
"sorry, we only accept significant digits and standard deviation as the
expression of precision" is unrealistic.  The folks that measure location
have agreed how to express precision, and it's not significant digits and
standard deviation.

You cannot actually measure location using any known technique and get a
Gaussian distribution of error.  The real world doesn't work that way.  I
believe that it's not even close to Gaussian for real world measurements:
while the error DOES tend to be worse at the extremes of the area, it's not
Gaussian.  That is why they came up with confidence and uncertainty: they do
a heck of a lot of measurements and compute what they can say, rather than
approximate with a Gaussian distribution.  Similarly, you can decide to
express uncertainty with circles or arc bands, etc, but the error
distribution is NOT uniform in that area, it is worse at the edges than in
the middle and you know it, but you all agreed to ignore it, and we're going
to have to go along with that.

You can't measure a point.  We all agree, a point is too small.  We aren't
going to define new absurdities like "thick points".  We approximate, we
express location of an object as location of a point with some specified
confidence and uncertainty.

My conclusion is that 3825 is wrong.  The mistake arose from a lack of
appreciation for the difficulty in determining precision, and not
understanding that the practitioners have defined a mechanism to express
precision which is not significant digits and standard deviation.  We made a
mistake.  It was a reasonable mistake to make, but it was a mistake.  We
need to express geo precision using confidence and uncertainty.  That is the
way the experts agreed to do it.  We don't have superior expertise in that
area.  The experts understand the issues and decided.  We should play along.

I think we should return confidence and uncertainty.  We should leave the
rez stuff in, because significant digits matter.  

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of James M. Polk
> Sent: Wednesday, February 13, 2008 3:24 PM

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Feb 2008 19:22:12 -0500

Martin,

The goal of 3825 is to pass the value of lat/long/alt from a DHCP server to
a host and maintain the significance of the original value.  Period. 

More inline......

> 
> Well I would be if there was some explicit acknowledgement 
> that the goal is to convey uncertainty at all. I find terms 
> like "a point with thickness" evasive with respect to this question.
> 
> Yes - significant digits is a well understood concept. If I 
> explicitly know that 38.6 is significant to one decimal point 
> then I can express the value as 38.65 +/-0.05 - that's the 
> well understood concept.

OK, so you seem to recognize that significant digits are a well known
concept.  Why is it hard to accept that significant digits must be supported
in 3825?

> 
> What certainly isn't clear is what the intent of the authors 
> is with respect to the interpretation of the LAT/LON set with 
> precision. The intent seems to be that it conveys an 
> uncertainy (e.g. per Polk) while the commentary excuses its 
> limitation on the basis of it being a point (per Linsner).

Stated above.

> 1. What shape of uncertainty should be inferred for, say, 
> 38.65 +/- 0.05 degrees and 84.95 +/- 0.05 degrees? Rectangle? Ellipse?

I don't think the IETF is the place to find your answer.  Why don't you try
a community that deals with geo-location applications?

> 
> 2. What if I want to represent an area of uncertainty 
> between, say, the lines of latitude 38.996 and 39.008? I'm 
> quite likely to want to do this and I can't do it using precision.

You are asking to possibly use a different mechanism (aka 'other than
significant digits') to convey uncertainty information, a mechanism that
3825 does not support.  I suggest you don't use 3825 if this is your
requirement (hint: it won't work!).

> 
> The latter of the two is the most critical issue with trying 
> to use significant digits to convey a geographic area of 
> uncertainty. It's also what leaves some of us wondering why 
> the resolution scheme is used at all.

Again, ask the people who use significant digits to convey uncertainty.  I
don't believe you'll find these people in the IETF.

I'm not going to continually argue with you about the merits of using
significant digits to convey uncertainty associated with geo location.  It's
in wide use, I'll even go out on a limb and claim it the most used
mechanism.  The point is that such an argument has no value in this venue.

RFC3825 supports conveying significant digits.  Hence, RFC3825 supports
conveying uncertainty via significant digits.

-Marc-

> I don't believe it's the task of the IETF to explain how to 
> utilize significant digits within the application of geo 
> location.  This is a often-used well-understood concept 
> within that discipline.
> 
> At this stage, I'm quite happy to put all of this aside as 
> the result of miscommunication.
> 
>  
> 
> "So can we agree that to the extent uncertainty can be 
> conveyed via significant digits, 3825 does such?"
> 
>  
> 
> "The resolution parameters communicated by 3825 indicates the 
> number of significant digits that the corresponding location 
> parameters are to be interpreted as having. To the extent 
> that uncertainty or area can be conveyed via significant 
> digits, 3825 permits this."
> 
>  
> 
> however, I genuinely interpreted it as saying that 
> significant digits did not convey an area, and subsequent 
> discussion didn't obviate the impression that that was the 
> intent. Something quite explicit as above would make the 
> conversion document much clearer - at least for me. In fact, 
> I don't think you really needed to explain how to encode and 
> recode a quantity provided with explicit significant digits. 
> As you say below, it's well understood art. A two line 
> clarification as above would have completely done the trick 
> for 3825 for me.
> 
>  
> 
> Cheers,
> 
> Martin
> 
> area? Why 
> thickness 
> > covering 38.60 recurring to 38.69 recurring and 84.90 recurring to 
> > 84.99 recurring?
> > 
> with those 
> > only the first decimal digit is significant for a reason - 
> otherwise 
> > I'd just interpret the values to be what James W wrote below (to 
> > notionally infinite precision).
> > 
> > Here's what I think:
> > The bin-dec draft which is the subject of this thread actually just 
> > says turn the value into a point. The resolution values get thrown 
> > away and two decimal values remain which don't have any explicit 
> > precision guidance.
> context, 
> > this doesn't imply anything and, anyway, it's not clear 
> what it means 
> > inside a 3825 context either.
> > 
> > If the intent had been to convey an area (i.e. a rectangle 
> or ellipse 
> > or whatever shape is supposed to be inferred) then the conversion 
> > would have been into a corresponding set of parameters. If it was a 
> > rectangle, then it would have been four ideal points or one 
> point and 
> > two lengths.
> major and 
> > am forced to assume that the intent is just to convey a point. As 
> > James W says, this could have been done in
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.
> > This message is for the designated recipient only and may contain 
> > privileged, proprietary, or otherwise private information.
> immediately 
> > and delete the original.  Any unauthorized use of this email is 
> > prohibited.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 13 Feb 2008 21:12:24 -0600

Well Brian, you almost lost me with those opening paragraphs.  In fact,
I disagree with the bulk of your arguments.  But I agree with the bulk
of your conclusion, except for the bit where you leave resolution in
DHCP.

I've put a few replies inline below.

Cheers,
Martin

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Thursday, 14 February 2008 10:15 AM
> To: 'James M. Polk'; Thomson, Martin; Winterbottom, James; 'Marc
> Linsner'; 'GEOPRIV'

On the contrary, I think that until recently James P and I have been
talking cross-purposes.  Our definitions of "uncertainty" were very much
at odds.  We have been making real progress in the past couple of days.
So go easy on the brakes.

> like (I'm going to use "precision" here, but you can turn that into
any
> term

Yes, most people superficially understand the meaning of significant
figures.  But, to describe this as "normal engineering language" is to
malign the many engineers who know better than to use them as a way to
convey information.  Engineers are more pragmatic than the physicists,
who certainly should never be using significant figures.

(To anticipate the response to this, 3825 can use significant figures as
much as it likes, but there are only two options:
 - The "significant bits" fields are important and carry information.
 - The "significant bits" fields have no real use; they might be used
for deciding how many digits to print.
I don't even think that there's consensus on this point, let alone what
they mean if it is the first option.  This is where your labelling falls
over, because I think that James P and Marc (who I infer are members of
the DHCP crowd) disagree.
)

> call "confidence" and "uncertainty".

Before you accuse anyone of making stuff up, try reading the ISO
standard that defines these terms.  Or you could try one of the many
references I have linked.  All of which a neither location-, nor mobile
phone- specific.
 
> know how many significant digits I need to express 1 cm precision in
an

Oh, I doubt very much that the GML folks made a mistake.  GML is
primarily a mathematical document, and from that perspective it is
sound.  They certainly made no mistake when defining a point.  What they
are doing now is addressing some of the real world constraints - the
same things we are discussing - like measurement uncertainty - by adding
fields to carry things like uncertainty and confidence.  No doubt
they'll do a very thorough job of addressing that problem too.

> Gaussian distribution of error.  The real world doesn't work that way.

Not entirely true.  If you had said that "you cannot always measure...",
I'd agree.  GPS positions go very close to a Gaussian, and can be
modelled reasonably well by a Gaussian.  Where a method is sufficiently
refined, all that remains is a Gaussian as chaos kicks in.  A lot of the
methods we have aren't that refined.

From here you are pretty much right on.

> I
> while the error DOES tend to be worse at the extremes of the area,
it's
> not
> distribution is NOT uniform in that area, it is worse at the edges
than
> in
> I think we should return confidence and uncertainty.

Cut this last sentence out, and we'd be good:
>  We should leave
<snip>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 Feb 2008 09:49:59 -0500

> don't believe you'll find these people in the IETF.

To go back to my second original question -- where do you find these 
people?  How do they interact with 3825/binary-lci?

--Richard

---

From: John Schnizlein <[email-masked]>
Date: Thu, 14 Feb 2008 10:30:51 -0500

Clarification embedded in context:

On Feb 13, 2008, at 5:32 PM, Dawson, Martin wrote:

> Well I would be if there was some explicit acknowledgement that the
> goal is to convey uncertainty at all. I find terms like "a point with

We really thought that the concept of the precision (resolution) of a  
value was well understood.  The special interpretation of  
"uncertainty" as something else has made it difficult to express the  
relationship between resolution and "uncertainty".  Possibly because  
I am "old school", I read "uncertainty" in communication engineering  
terms as defined by Claude Shannon.

> the value as 38.65 +/-0.05 - that's the well understood concept.

Good.  We can all now ignore meaningless statements about infinite  
precision.

> the commentary excuses its limitation on the basis of it being a point

I think the difficulty here is that the correspondence between an  
area of uncertainty and the resolution of the value of location was  
complicated by an unnecessary demand to encode an arbitrary area.  I  
would hope that it is clear to everybody that a lower-resolution  
value of location implies a larger area in which the target might be.

> If the intent is that it conveys uncertainty:

It is difficult to subscribe to a statement like this without a very  
precise understanding of "uncertainty", which we think has more  
semantic ambiguity than resolution.  Consider the consumer  
understanding of the resolution of an HDTV.

> degrees and 84.95 +/- 0.05 degrees? Rectangle? Ellipse?

Since the shape of the boundary depends on the joint probability  
distribution of error, which is much more detailed than necessary for  
the intended point location, there is little point in worrying about it.

Please recall that it will be difficult enough to calculate within  
which region (emergency response or pizza-shop territory) a point  
location is.  The complexity of comparing shaped and distributed  
points within these regions is not likely worth the effort.

> and I can't do it using precision.

You CAN calculate resolution for RFC 3825 using the method described  
in binary-lci in the middle of page 5, starting with "If all that is  
available is the bounding points of a region".

The middle between 38.996 and 39.008 is 39.008 - the value of  
location.   The difference from this center to the bounds indicates  
an error of 0.006, which is about 8 bits of fractional part.  Adding  
the 9 bits of resolution for the integer part of the field produces a  
resolution of 17 bits.

> what leaves some of us wondering why the resolution scheme is used at

Resolution as the number of significant binary digits (bits) is  
precisely related to the error in representation.  Because practical  
uses of location information will have errors smaller (requiring  
fewer bits of representation in the protocol) than arbitrary values,  
it makes sense to encode not the full precision of the error, but the  
logarithm (base 2) of the error.  The resolution in bits is the  
complement of the error in bits, and has the direct interpretation of  
the number of bits of the location value that are meaningful.

John

> number of
> did not convey an area, and subsequent discussion didn't obviate the
> impression that that was the intent. Something quite explicit as above
> would make the conversion document much clearer - at least for me.
> In fact, I don't think you really needed to explain how to encode
> and recode a quantity provided with explicit significant digits.
> As you say below, it's well understood art. A two line clarification
> as above would have completely done the trick for 3825 for me.
>
> Cheers,
>
> Martin
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Feb 2008 17:36:38 -0600

From past discussions, I believe Marc draws on his nautical experience.
Charts have a finite precision and locations are given to a finite
precision with the interpretation that that they are points.

I don't actually think this is the same thing that we are talking about
but it might highlight where the fundamental difference in perspective
lies.

If Air-Sea rescue publish a search area for rescue craft, they will
provide a polygon of points or a point and radius enclosing what, in
practice, is the area of uncertainty bounding the target. They do not
provide a single lat/lon with precision diminished sufficiently to
encompass that search area. The latter approach would quickly highlight
the difficulty of using significant digits to convey uncertainty (as
opposed to the precision of individual lat/lon values).

For more information on this entertaining subject check out

http://www.av8n.com/physics/uncertainty.htm

which includes such choice quotes as:

 - People who care about their data don't use significant digits.
 - Significant figures are a convenient way of getting the wrong answer.
 - You can either do the right thing, or do something with significant
figures.

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Friday, 15 February 2008 1:50 AM
To: Marc Linsner
Cc: Dawson, Martin; 'GEOPRIV'
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

--Richard

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 14 Feb 2008 17:51:54 -0600

I'm glad you brought up that example in the draft John - you can help
with completing it.

Here's the text

If all that is available is the bounding points of a region, the  

difference between the extremes and the center in both latitude and  

longitude estimates the error in degrees, which can be converted to  

resolution as above.  Find the maximum and minimum of both, calculate  

the value of the latitude/longitude as the average, and half the 

difference as the error.  

For the example bounds ranging about 0.5 meters in distances across  

about 32 degrees, the binary and decimal values are as follows:  

             binary                    decimal  

000011111.1111111111111111111001110  31.99999850  

000100000.0000000000000000001011100  32.00000274  

001000000.0000000000000000000101010  64.00000124  sum  

000100000.0000000000000000000010101  32.00000062  average  

000000000.0000000000000000010001110  00.00000423  difference  

With 26 bits above the difference, which is twice the error, this  

example yields 27 bits of resolution (remembering to add 9 bits for left

of the binary point).  

The example needs completing. Could you please provide the final result
- i.e. what, exactly, are the 34 bits of latitude value set to and what
value is assigned to LaRes?

Cheers,

Martin

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Friday, 15 February 2008 2:31 AM
To: Dawson, Martin
Cc: Marc Linsner; GEOPRIV
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

precision.

> 1. What shape of uncertainty should be inferred for, say, 38.65 +/-  

> 0.05

> 2. What if I want to represent an area of uncertainty between, say,  

> lines of latitude 38.996 and 39.008? I'm quite likely to want to do  

resolution of 17 bits.

> significant digits to convey a geographic area of uncertainty. It's  

> also

John

> snip------------------------------------------------------------------

> At this stage, I'm quite happy to put all of this aside as the  

> result of

> significant digits that the corresponding location parameters are  

> to be

> You may feel that this is the same as the sentence that you quote  

> below

> snip------------------------------------------------------------------

---

From: Andrew Newton <[email-masked]>
Date: Fri, 15 Feb 2008 08:36:14 -0500

> area.  The experts understand the issues and decided.  We should  

I think Brian has a point here.  If the IETF is defining thick points,  
even implicitly as in 3825, then it should probably defer to an  
organization with the bona fides to do this subject justice.  GEOPRIV  
uses the OGC's GML standard quite heavily, and has in the past handed  
off work to them.  Hannes has suggested the definition of a DHCP  
option that is more compatible with GML.  That is a good idea, if for  
no other reason than the rest of the GEOPRIV standards use GML.

-andy

---

From: John Schnizlein <[email-masked]>
Date: Fri, 15 Feb 2008 09:37:07 -0500

The example is complete.  Here are the answers to your questions,  
extracted from the text:

Q1: what, exactly, are the 34 bits of latitude value set to
A1: calculate the value of the latitude/longitude as the average
     000100000.0000000000000000000010101  32.00000062  average

Q2: what value is assigned to LaRes?
A2: this example yields 27 bits of resolution

John

On Feb 14, 2008, at 6:51 PM, Dawson, Martin wrote:
> I'm glad you brought up that example in the draft John – you can  
> help with completing it.
>
> Here’s the text
>
> The example needs completing. Could you please provide the final  
> result – i.e. what, exactly, are the 34 bits of latitude value set  
> to and what value is assigned to LaRes?
>
>
>
> Cheers,
>
> Martin
>
>
>
> explicitly

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Feb 2008 09:42:01 -0500

Martin, 

> Charts have a finite precision and locations are given to a 
> finite precision with the interpretation that that they are points.
> 
> I don't actually think this is the same thing that we are 
> talking about but it might highlight where the fundamental 
> difference in perspective lies.
> 
> If Air-Sea rescue publish a search area for rescue craft, 
> they will provide a polygon of points or a point and radius 
> enclosing what, in practice, is the area of uncertainty 
> bounding the target. They do not provide a single lat/lon 
> with precision diminished sufficiently to encompass that 
> search area. The latter approach would quickly highlight the 
> difficulty of using significant digits to convey uncertainty 
> (as opposed to the precision of individual lat/lon values).

This example is orthogonal to the discussion.  It is confusing the issue by
associating 'uncertainty' from a different context.

What would be helpful is to provide evidence of how uncertainty associated
with self-measuring location mechanisms is expressed/communicated.  This is
the area of applicability for RFC3825.  We'll address the shortcomings of
GML after this is agreed upon.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Feb 2008 14:31:40 -0500

Andy, 

> 
> I think Brian has a point here.  If the IETF is defining 
> thick points, even implicitly as in 3825, then it should 
> probably defer to an organization with the bona fides to do 
> this subject justice.  

The IETF isn't defining anything.  The issue is a bunch of IETF participants
attempting to characterize/justify/evaluate (as engineers love to do) what
is already in use in the geo location discipline.  The term 'thick point' is
a characterization of how one might describe the effect of significant
digits in the application of geo location.  I haven't experienced this term
in the actual geo location discipline.

What I have witnessed in the geo location space is the mechanism of self
measuring location, ala gps, yielding results that either: (a) Do not convey
uncertainty surrounding the accuracy of the measurement, OR, (b) they convey
uncertainty via significant digits expressed.  This is simply a conclusion
drawn from the fact there is not any other usable data information, that may
be construed as 'uncertainty', in the output of this mechanism.  RFC3825
supports this mechanism.

We also have participants from a competing technology space to self
measuring, which is network measuring, within the discipline of geo
location, that utilize a mechanism where they convey uncertainty associated
with a measurement via additional data field(s).  This network measuring
mechanism is clearly, but not totally, in use in the cellular space.  The
utilization of this network measurement mechanism, to date, has been outside
the applicability of RFC3825.  I make this claim as RFC3825 clearly states
not for wireless hosts.  There has not been any evidence to suggest that
locating a wired host via network measurement is in use, feasible, or
planned.

The long tirades of discussion continually are drawn into the merits of
these competing technologies (self vs. network measuring) and their
corresponding lack of/use of measurement uncertainty.  This is adjacent to
the task at hand for GeoPriv and is the discussion I've attempted to
declare, 'Not for the IETF!'.  For unknown reasons, some still believe it's
a worthy venue to discuss such.

GEOPRIV uses the OGC's GML standard 
> quite heavily, and has in the past handed off work to them.  
> Hannes has suggested the definition of a DHCP option that is 
> more compatible with GML.  That is a good idea, if for no 
> other reason than the rest of the GEOPRIV standards use GML.

There have been recent claims that GML does not support my above hypothesis
of the self measuring space.  We need to figure out: (1) if this claim is
valid (2) whether this is a correctable oversight on OGC's part or (3)
RFC4119 needs updated to support GML version 3.2.1.

Carl Reed has offered to investigate this for us.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 15 Feb 2008 15:04:44 -0600

Marc,

I don't quite not where to start since your response is so utterly
incorrect, and full of misrepresentations.

You seem to imply that 3825 is about "self-measuring" device, there is
no mention of this in 3825 at all. In fact 3825 says:

"This document specifies a Dynamic Host Configuration Protocol [1]
   Option for the coordinate-based geographic location of the client, to
   be provided by the server."

To me this is clearly a network determined location, or is the DHCP
server in the end-device?

Just to cut your response before you start, I have wandered around quite
large areas of Dallas in the past with a differential GPS unit that
quite clearly provided me with a location as a circle, point with
radius, and not a "thick point".

Our position of representing uncertainty comes from NIST. But as you
point out, NIST is a cellular telephone technology provider that is
interested only in network determined locations.

I asked John S, a very simple question in an email yesterday, that he
has declined to respond to, I think that the answer to that question
would solve a great deal of trouble. Just in case it got lost in the
noise, I shall provide a link to it here:

http://www.ietf.org/mail-archive/web/geopriv/current/msg05189.html

Have a nice weekend

James

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 15 Feb 2008 15:05:37 -0600

If we are defining "Thick Points" then a new LoST profile is also
required.

> From: Andrew Newton [mailto:[email-masked]]
> Sent: Saturday, 16 February 2008 12:36 AM
> To: Brian Rosen
> Cc: Thomson, Martin; Winterbottom, James; GEOPRIV WG

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 15 Feb 2008 17:38:21 -0500

James,

In-line...

> 
> I don't quite not where to start since your response is so 
> utterly incorrect, and full of misrepresentations.

Do you agree that self-measured location determination either doesn't
support 'uncertainty' or supports it via the use of significant digits?

Do you agree that network-measured location determination provides
'uncertainty' as additional data points to the position data?

> 
> You seem to imply that 3825 is about "self-measuring" device, 
> there is no mention of this in 3825 at all. In fact 3825 says:

There must be something lost in the translation process between northern and
southern hemisphere :^).  I never stated that 3825 is any kind of device.  I
stated that 3825 supports the data output from common self-measuring
location determination mechanisms.  These mechanisms are most akin to
building the wire-map database that dhcp would utilize in support of the LCP
function.

> To me this is clearly a network determined location, or is 
> the DHCP server in the end-device?

I am not going to answer this ridiculous question.  And I do believe you
understand the difference between the location measuring piece of location
determination vs. wiremap data and the act of passing this data to the end
host.

> 
> Just to cut your response before you start, I have wandered 
> around quite large areas of Dallas in the past with a 
> differential GPS unit that quite clearly provided me with a 
> location as a circle, point with radius, and not a "thick point".

OK, good, you've now got experience.

Would you agree this application utilized a self-measured location
determination mechanism?

Was the circle, point with radius coming from the actual GPS or due to the
resolution of the map data?

If it was coming from the actual GPS function, what standard NMEA sentence
was used to pass the 'uncertainty' data to the map function?

Was the uncertainty conveyed from the gps to the map function as additional
data to the position data?

Or was the uncertainty value conveyed from the gps to the map function
derived from 'significant digits'?

> 
> Our position of representing uncertainty comes from NIST. But 
> as you point out, NIST is a cellular telephone technology 
> provider that is interested only in network determined locations.
> 
> I asked John S, a very simple question in an email yesterday, 
> that he has declined to respond to, I think that the answer 
> to that question would solve a great deal of trouble. Just in 
> case it got lost in the noise, I shall provide a link to it here:
> 

I noticed your question and view it again as an attempt to take this
conversation down the road of comparing the merits of self-measured location
determination mechanisms to network-measured location determination
mechanisms.  Again, I going to ask that these types of debates take place in
a the proper venue, not the IETF.

-Marc-

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 15 Feb 2008 22:38:11 -0600

This results in a binary value with 27 significant digits of:

000100000.0000000000000000000   i.e. 32.00000

And, to the extent that significant digits can represent a
range/uncertainty - it covers the extents:

000100000.00000000000000000000000 recurring

To

000100000.00000000000000000001111 recurring

or 32.00000000 to 32.0000038

So the result is a range that has the lower value inside the original
range and an upper value which is outside the original range that was
the subject of the example.

In what sense is this an example of significant digits being
successfully used to represent "the bounding points of a region"?

Cheers,
Martin

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Saturday, 16 February 2008 1:37 AM
To: Dawson, Martin
Cc: GEOPRIV; Marc Linsner
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

John

On Feb 14, 2008, at 6:51 PM, Dawson, Martin wrote:
> I'm glad you brought up that example in the draft John - you can  
> help with completing it.
>
> Here's the text
>
> result - i.e. what, exactly, are the 34 bits of latitude value set

---

From: "Winterbottom, James" <[email-masked]>
Date: Sun, 17 Feb 2008 23:21:47 -0600

Marc inline.

> 'uncertainty' as additional data points to the position data?

[AJW] No I don't. A point with uncertainty radius is a circle or as may
calculate it, and ellipsoid. This is what I got from the GPS that I
used. Not a dodgey 3825 "thick point".

> There must be something lost in the translation process between
northern
> and
> southern hemisphere :^).  I never stated that 3825 is any kind of
device.
> building the wire-map database that dhcp would utilize in support of
the
> LCP

[AJW] This is not stated in 3825, it is a post supposition that you are
introducing now. It is irrelevant to the argument, and as I stated
above, I don't believe that that is how GPS reports location.

> determination vs. wiremap data and the act of passing this data to the
end

[AJW] Fair enough, though you have stated on occasion that 3825 is not
dependent on DHCP relay, where the opening text suggests that it is a
predicate for the mechanism to work.

> resolution of the map data?

[AJW] From the GPS. It was expressed as an ellipsoid point +- X metres.

I didn't say anything about a mapping function, not sure where this left
field argument came from. I didn't require a mapping application for the
activity I was performing.

> mechanisms.  Again, I going to ask that these types of debates take
place
> a the proper venue, not the IETF.

[AJW] Then you have completely misunderstood why the question was asked.
John implied that a way to convey a circular uncertainty through DHCP
was not required, because the existing option could convey a rectangular
uncertainty. I was merely asking him to confirm that I had interpreted
his statement correctly, and I am waiting for an answer.

Cheers
James

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 17 Feb 2008 23:44:20 -0600

> > Was the circle, point with radius coming from the actual GPS or due
> to
> the

I think that I know what Marc is asking.  I'll paraphrase:

"If a user was asked to pick a point on a map, what uncertainty would
you assign?"

The answer is that you omit uncertainty.  You don't provide "resolution"
either.  The user picked a point, not an area (of any shape).  Note that
this doesn't imply that there is no uncertainty, just that it wasn't
provided.

RFC 3825 doesn't provide an option to just provide a point.  It's got
this weird, mandatory "resolution" thing.
------------------------------------------------------------------------------------------------
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]

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Feb 2008 02:37:39 -0600

At 11:21 PM 2/17/2008, Winterbottom, James wrote:
> > northern and southern hemisphere :^).  I never stated that 3825 
> is any kind of
> > device.
> > I stated that 3825 supports the data output from common self-measuring
> > building the wire-map database that dhcp would utilize in support of the
> > LCP function.
> >
>
>introducing now.

James W - which part of Marc's answer are you saying is a "post 
supposition that you are introducing now. "

(i.e., 3825 has always been about good wiremaps - and that was circa 
2003 in Geopriv)

>It is irrelevant to the argument, and as I stated

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 18 Feb 2008 05:32:50 -0600

James, this bit

"I stated that 3825 supports the data output from common self-measuring
location determination mechanisms."

Please point me where this is stated or implied in 3825.

Cheers
James

> Sent: Monday, 18 February 2008 7:38 PM
> To: Winterbottom, James; Marc Linsner
> Cc: GEOPRIV WG

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 18 Feb 2008 08:02:48 -0500

James, 

> 
> "I stated that 3825 supports the data output from common 
> self-measuring location determination mechanisms."
> 

I don't believe it's stated in the draft.  But it is fact that 3825 supports
conveyance of values and preserves significant digits.  I'm struggling with
why this is hard to understand.

Analogy: The smtp protocol specification doesn't state that I can spell my
name with a c vs. a k either, but it works.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Feb 2008 11:33:30 -0500

> [AJW] From the GPS. It was expressed as an ellipsoid point +- X metres.
Just for my general font of knowledge, it's an ellipsoid because there is
different uncertainty in the X and Y directions, right?  Roughly an issue
due to the shape of the earth and the satellite orbits.

And, for most GPS systems, the error distribution is pretty close to
Gaussian (I've been looking into it lately), right?

Normally, uncertainty as you define it has flat distribution (equal
probability anywhere in the uncertainty region).  GPS is one of the
measurement mechanisms that have Gaussian error distribution (more likely
close to the focii than at the edges of the uncertainty region, bell shaped
curve).

So, in particular, with GPS, as opposed to any other way to measure, you
could express error with significant digits on x and y separately, get an
ellipsoid uncertainty region, and expect close to Gaussian distribution of
error in there, and imply an confidence roughly equal to some number of
standard deviations right?

Doesn't necessarily make it the right way to do it; I'm not changing my
opinion that we should express error/precision of geo with confidence and
uncertainty.  I'm just looking to increase my overall knowledge of what
actually is happening.

If error was most often Gaussian distributed, then we really would be better
off describing uncertainty that way, with exceptions for cases where you
can't do that, right?  Knowing error distribution would be very helpful
would it not?

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 18 Feb 2008 15:30:19 -0600

"Ellipsoid point" is a term that is used in some circles to refer to a
point on the WGS84 ellipsoid (the earth is modelled as an ellipsoid).
That is all.

The elliptical region of uncertainty doesn't always align with the
north-south/east-west axes.  The rotation parameter is necessary to get
an ellipsoid shape equivalent to the one produced by the GPS
calculation.

Gaussian distribution is OK, unless you are relying on measurements that
have inherent limitations.  Many of the methods that use network
parameters have quantisation errors that are the single largest
contribution to error.  That is why I provided a PDF indicator in my
uncertainty draft: normal, rectangular and unknown.

> Behalf Of Brian Rosen
> Sent: Tuesday, 19 February 2008 3:34 AM
> To: Winterbottom, James; 'Marc Linsner'
> Cc: 'GEOPRIV WG'
> ellipsoid uncertainty region, and expect close to Gaussian
distribution

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 18 Feb 2008 16:47:30 -0500

Martin, 

> 
> "Ellipsoid point" is a term that is used in some circles to 
> refer to a point on the WGS84 ellipsoid (the earth is 
> modelled as an ellipsoid).
> That is all.
> 
> The elliptical region of uncertainty doesn't always align 
> with the north-south/east-west axes.  The rotation parameter 
> is necessary to get an ellipsoid shape equivalent to the one 
> produced by the GPS calculation.

As I've tried to make clear out several times, there is no way to extract
this information from a GPS.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Feb 2008 17:20:16 -0500

I did say I thought DHCP ought to be able to specify uncertainty and
confidence.  I said that because the experts in location measurement I
consulted said that confidence and uncertainty was the correct way to
specify error/precision of a geo measurement.

Marc however does make a good point.  If the tool we really expect to use to
get the locations DHCP reports doesn't supply the uncertainty and
confidence, then why would we insist providing it?

As a practical matter, if DHCP is used, wouldn't you expect that a GPS
device is far and away the most likely measurement mechanism that would be
used to determine what DHCP returns?  I'm visualizing a technician wandering
around plugging in a GPS device into every Ethernet jack he finds.  If the
GPS worked in the building he was in (yes, I know, currently a big if) then
you could see a really simple way to provide accurate location on a campus.
Very attractive, simple, and, it would seem to me, far more likely to be
used than anything else.

If GPS devices don't return confidence and uncertainty, and GPS is the tool
most often used to generate the data, what would you want to see reported if
the protocol is changed to provide it?  

Brian

> Of Marc Linsner
> Sent: Monday, February 18, 2008 4:48 PM
> To: 'Thomson, Martin'
> Cc: 'GEOPRIV WG'

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 18 Feb 2008 17:13:35 -0600

Marc quoted the NMEA spec. It's defined by the National Marine
Electronics Association and definitely had sailors like Marc in mind.
This protocol does not reflect the capability of GPS devices.

NMEA conveys latitude and longitude in degrees and minutes (the latter
to four decimal places - and no use of significant digit identifiers by
the way). Hopefully most nautical types don't actually think the
location from the GPS unit is really accurate to four decimal points of
minutes. Hopefully most actually infer their own uncertainty based on
experience and knowledge of the context. And when they do - I doubt
their mental model is in terms of significant digits.

This is what Ted Hardy would call a best-fit versus best-basis issue.
The marine guys know what they wanted NMEA to do and they understand
what the right assumptions are. It's best-fit for them. It's not
appropriate or satisfactory (best-basis) for a long term and general
definition for a location protocol.

Below I show the specification for a (very common!) GPS device - by
which I mean chipset - that we work with. I just show what it provides
for a location fix. You'll see that it includes a point, major and minor
axes of uncertainty, major axis orientation, and confidence. NMEA aside,
other common protocols do convey this information from GPS devices -
e.g. RRLP and RRC - and there's nothing to prevent handheld products
from doing the same (and they do!).

BTW - If I were the sysadmin in your example, I'd use a Google Maps
mashup that let me draw an ellipse around the building and generate an
appropriately coded uncertainty area. I'd use that as the geolocation
for each office/cube and I'd encode the civic address component to
provide the additional granularity of office/cube location. I'd have to
have a good reason to provide really low granularity geo-location for
every seat - and I doubt that many people would have a good reason to go
to that trouble at this stage. Of course - if they wanted to, they
could. They'd need something better than significant digits to represent
each area of uncertainty (to the size of an office/cube?) to do so.

Cheers,
Martin

GPS device API - location component of device response:

a Latitude Sign 0 = North 1 = South

tttt Latitude in scaled degrees 0 .. 2^31 - 1 (0 .. 89.979 degrees)
The least significant bit represents about 41.9 nanodegrees

nnnn Longitude in scaled degrees -2^31 .. 2^31 - 1 (-180 .. 179.959
degrees)
The least significant bit represents about 83.8 nanodegrees

d Altitude Direction 0 = Height 1 = Depth

eeee Altitude in 2^-8 meters 0 .. 12799999 (0 .. 49999.996 meters)

F Semi-Major Uncertainty Value 0 .. 127
Semi-major uncertainty, r1, expressed in meters is given by:
r1 = 10 * ((1.1)^F - 1)

G Semi-Minor Uncertainty Value 0 .. 127
Semi-minor uncertainty, r2, expressed in meters is given by:
r2 = 10 * ((1.1)^G - 1)

o Orientation of Major Axis in scaled degrees 0 .. 89
Orientation of major axis, a, expressed in degrees is given by:
a = o * 2

K Altitude Uncertainty Value 0 .. 127
Altitude uncertainty, r3, expressed in meters is given by:
r3 = 45 * ((1.025)^K - 1)

c Confidence in percent 0 .. 100

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Rosen
Sent: Tuesday, 19 February 2008 9:20 AM
To: 'Marc Linsner'; Thomson, Martin
Cc: 'GEOPRIV WG'
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Marc however does make a good point.  If the tool we really expect to
use to
get the locations DHCP reports doesn't supply the uncertainty and
confidence, then why would we insist providing it?

As a practical matter, if DHCP is used, wouldn't you expect that a GPS
device is far and away the most likely measurement mechanism that would
be
used to determine what DHCP returns?  I'm visualizing a technician
wandering
around plugging in a GPS device into every Ethernet jack he finds.  If
the
GPS worked in the building he was in (yes, I know, currently a big if)
then
you could see a really simple way to provide accurate location on a
campus.
Very attractive, simple, and, it would seem to me, far more likely to be
used than anything else.

If GPS devices don't return confidence and uncertainty, and GPS is the
tool
most often used to generate the data, what would you want to see
reported if
the protocol is changed to provide it?  

Brian

Behalf

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 18 Feb 2008 18:19:22 -0500

Martin,

NMEA is in use by all aviation, marine, and consumer gps'.

-Marc- 

> Sent: Monday, February 18, 2008 6:14 PM
> To: Brian Rosen; Marc Linsner; Thomson, Martin
> Cc: GEOPRIV WG
> Marc quoted the NMEA spec. It's defined by the National 
> Marine Electronics Association and definitely had sailors 
> like Marc in mind.
> NMEA conveys latitude and longitude in degrees and minutes 
> (the latter to four decimal places - and no use of 
> significant digit identifiers by the way). Hopefully most 
> nautical types don't actually think the location from the GPS 
> unit is really accurate to four decimal points of minutes. 
> Hopefully most actually infer their own uncertainty based on 
> experience and knowledge of the context. And when they do - I 
> doubt their mental model is in terms of significant digits.
> 
> The marine guys know what they wanted NMEA to do and they 
> understand what the right assumptions are. It's best-fit for 
> them. It's not appropriate or satisfactory (best-basis) for a 
> long term and general definition for a location protocol.
> 
> Below I show the specification for a (very common!) GPS 
> device - by which I mean chipset - that we work with. I just 
> show what it provides for a location fix. You'll see that it 
> includes a point, major and minor axes of uncertainty, major 
> axis orientation, and confidence. NMEA aside, other common 
> protocols do convey this information from GPS devices - e.g. 
> RRLP and RRC - and there's nothing to prevent handheld 
> products from doing the same (and they do!).
> 
> BTW - If I were the sysadmin in your example, I'd use a 
> Google Maps mashup that let me draw an ellipse around the 
> building and generate an appropriately coded uncertainty 
> area. I'd use that as the geolocation for each office/cube 
> and I'd encode the civic address component to provide the 
> additional granularity of office/cube location. I'd have to 
> have a good reason to provide really low granularity 
> geo-location for every seat - and I doubt that many people 
> would have a good reason to go to that trouble at this stage. 
> Of course - if they wanted to, they could. They'd need 
> something better than significant digits to represent each 
> area of uncertainty (to the size of an office/cube?) to do so.
> 
> Cheers,
> Martin
> 
> tttt Latitude in scaled degrees 0 .. 2^31 - 1 (0 .. 89.979 
> degrees) The least significant bit represents about 41.9 nanodegrees
> 
> [mailto:[email-masked]] On Behalf Of Brian Rosen
> I did say I thought DHCP ought to be able to specify 
> uncertainty and confidence.  I said that because the experts 
> in location measurement I consulted said that confidence and 
> uncertainty was the correct way to specify error/precision of 
> a geo measurement.
> 
> Marc however does make a good point.  If the tool we really 
> expect to use to get the locations DHCP reports doesn't 
> supply the uncertainty and confidence, then why would we 
> insist providing it?
> 
> As a practical matter, if DHCP is used, wouldn't you expect 
> that a GPS device is far and away the most likely measurement 
> mechanism that would be used to determine what DHCP returns?  
> I'm visualizing a technician wandering around plugging in a 
> GPS device into every Ethernet jack he finds.  If the GPS 
> worked in the building he was in (yes, I know, currently a 
> big if) then you could see a really simple way to provide 
> accurate location on a campus.
> Very attractive, simple, and, it would seem to me, far more 
> likely to be used than anything else.
> 
> If GPS devices don't return confidence and uncertainty, and 
> GPS is the tool most often used to generate the data, what 
> would you want to see reported if the protocol is changed to 
> provide it?  
> 
> Brian
> 
> > > "Ellipsoid point" is a term that is used in some circles 
> to refer to 
> > > a point on the WGS84 ellipsoid (the earth is modelled as an 
> > > ellipsoid).
> > > That is all.
> > >
> with the 
> > > north-south/east-west axes.  The rotation parameter is 
> necessary to 
> > > get an ellipsoid shape equivalent to the one produced by the GPS 
> > > calculation.
> >

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 18 Feb 2008 17:43:38 -0600

I knew you were going to say that :)

Nevertheless, NMEA are a marine forum and, in any case, same comments
apply.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 19 February 2008 10:19 AM
To: Dawson, Martin
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Martin,

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 18 Feb 2008 18:49:57 -0500

Martin, 

> products from doing the same (and they do!).

Please identify non A-GPS devices that support these protocols.

I really am curious.

-Marc-

---

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 18 Feb 2008 17:53:08 -0600

Perhaps John and Marc would be so kind as to each answer this question
posed to the WG at least twice now as it if fairly fundamental as to how
the WG should perceive then RFC3825 encoding.

Regards
James

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 18 Feb 2008 17:59:23 -0600

I'm not sure why the question is relevant. The strange turn of events
that you introduced into this thread was that 3825 was based on the
assumption that only GPS would be used to determine the location
configured into the DHCP server (or words to that effect).

You said that there's no point in having "uncertainty" because GPS
devices can't do uncertainty. You quoted the NMEA protocol as evidence
of this. I pointed out that GPS devices are capable of it and, indeed,
other protocols than NMEA support the conveyance of this information.

In any case, both RRLP are used to convey location results for other
technologies as well - UTDOA, OTDOA, RTT,... This is irrelevant to the
discussion; I'm just answering your question.

A question from me. If NMEA was such a significant touchstone in
defining 3825, why did you put significant digits into it - can NMEA
tell the user how many digits are significant?

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 19 February 2008 10:50 AM
To: Dawson, Martin
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Martin, 

I really am curious.

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Mon, 18 Feb 2008 19:18:40 -0500

As always in discussions within this community, they evolve.  In an attempt
to draw a parallel to the wiremap that DHCP is expected to utilize, I
thought comparing it to self-measured location determination mechanisms
would help some connect the dots.  But, as always, it gets continually
twisted into a bucket of 'oblivion?'.  

NMEA has nothing to do with 3825, and yes NMEA expresses significant digits.
FYI, significant digits in variable expressions are indicated by the number
of digits shown.  But, in fixed length expressions, as in 3825, one must
expose which digits are significant (hence the resolution bits).

BTW, I asked for non A-GPS devices (yes, the kind that perform self-measured
location determination), and you answered with a set of A-GPS protocols.
Again, more oblivion.

-Marc-

> 
> I'm not sure why the question is relevant. The strange turn 
> of events that you introduced into this thread was that 3825 
> was based on the assumption that only GPS would be used to 
> determine the location configured into the DHCP server (or 
> words to that effect).
> 
> You said that there's no point in having "uncertainty" 
> because GPS devices can't do uncertainty. You quoted the NMEA 
> protocol as evidence of this. I pointed out that GPS devices 
> are capable of it and, indeed, other protocols than NMEA 
> support the conveyance of this information.
> 
> In any case, both RRLP are used to convey location results 
> for other technologies as well - UTDOA, OTDOA, RTT,... This 
> is irrelevant to the discussion; I'm just answering your question.
> 
> A question from me. If NMEA was such a significant touchstone 
> in defining 3825, why did you put significant digits into it 
> - can NMEA tell the user how many digits are significant?
> 
> Cheers,
> Martin
> 
> > for a location fix. You'll see that it includes a point, major and 
> > minor axes of uncertainty, major axis orientation, and confidence. 
> > NMEA aside, other common protocols do convey this 
> information from GPS 
> > devices - e.g.

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 18 Feb 2008 19:16:36 -0600

OK... let's summarize where we are at from my perspective then:

1. 3825 can only represent location uncertainty to the extent that
significant digits can do that. There are mixed messages from the
authors as to whether the *intent* was to support communication of
uncertainty or not (James is waiting for a response from John S on that
topic).

2. The subject draft provides some C code that shows how to interpret
the resolution parameters from an LCI encoded block. I'm not sure that
the code really added anything over the normative 3825 text but it
definitely makes it clear that the "non significant digits" are thrown
away.

3. The subject draft then provides an example of coding a bounding
region in LCI encoding. As I pointed out to John S, it fails to
represent this bounding region (still waiting for a response on that
question as well). The prior, C-Code, example makes it clear that the
"non significant digits" are to be ignored. This is also as would be
expected by the normative text. The result is a bounding region which is
both a different size and in a different location to the one that the
example attempts to encode and only manages to overlap the source
region. This illustrates the problem with using significant digits.

4. It's not clear to me what use the recipient of significant digits in
the LCI encoding will make of them in practice. But I don't want to go
down a best-fit route. They can't rely on them as being indicative of
uncertainty.

5. In an associated thread, Hannes and co are trying to propose that
explicit support for uncertainty (e.g. at least a circle as a starting
point) be added to DHCP. John S appears to be arguing that it's
unnecessary because resolution already provides what you need. As above,
some of us think that resolution is quite inadequate for this purpose.

6. So - where are we?
a. The subject draft doesn't actually clarify the normative statements
in 3825 with respect to providing uncertainty - and, indeed, seems to
provide a counter-example.
b. There hasn't been a satisfactory conclusion as to whether 3825 should
be enhanced so it can provide a useful means of conveying explicit
uncertainty.

BTW - UTDOA, OTDOA, and RTT are not AGPS protocols - they are
positioning technologies (which aren't GPS). In any case, I still don't
know what you were getting at. There a non-GPS self-locating device that
uses NMEA - is that it? I'm still unclear why it's pertinent. Again, my
point is that GPS devices can and do provide genuine uncertainty - and
you can just read it off the display; no need to be constrained by NMEA.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Tuesday, 19 February 2008 11:19 AM
To: Dawson, Martin
Cc: 'GEOPRIV WG'
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

As always in discussions within this community, they evolve.  In an
attempt

NMEA has nothing to do with 3825, and yes NMEA expresses significant
digits.
FYI, significant digits in variable expressions are indicated by the
number
of digits shown.  But, in fixed length expressions, as in 3825, one must
expose which digits are significant (hence the resolution bits).

BTW, I asked for non A-GPS devices (yes, the kind that perform
self-measured
location determination), and you answered with a set of A-GPS protocols.
Again, more oblivion.

-Marc-

---

From: "Carl Reed" <[email-masked]>
Date: Wed, 20 Feb 2008 14:03:38 -0700

Brian -

With regard to GML, GML follows the ISO standards for geometry, spatial 
referencing by coordinates, and so forth.

Precision/accuracy are considered to be metadata elements as opposed to 
having to be a special property of a geometry that states number of 
significant digits and so forth. GML 3.2.1 specifies that spatial metadata 
should be encoded using 19139:2007 - Geographic information -- Metadata --  
XML schema implementation.

Also, a couple of notes from two of the GML editors:

GML is XML, i.e. it is a text encoding, so what you see is what you get. 
There is no explicit support for precision. (My note:  GML payloads are 
generated by applications. Accuracy and precision are driven by the 
applications and not GML per-se)

Regards

Carl

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'James M. Polk'" <[email-masked]>; "'Thomson, Martin'" 
<[email-masked]>; "'Winterbottom, James'" 
<[email-masked]>; "'Marc Linsner'" <[email-masked]>; 
"'GEOPRIV'" <[email-masked]>
Sent: Wednesday, February 13, 2008 4:15 PM
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 22 Feb 2008 08:31:32 -0500

This seems like squirming to me.

I accept (yet again), that precision/accuracy are separate metadata.

You can't just wave your hands with significant digits.

If you say 23,65 with an uncertainty of 1/2cm and a confidence of 95%, every
engineer and mathematician should start laughing.  If you say 23.000000,
65.00000 they will allow that it's possible, but be pretty suspicious.  If
you say 23.0133467, 65.0000000 with an uncertainty of 1/2cm and a confidence
of 95%, they will be happy (and perhaps a little suspicious).  Your point,
which I understand, is that you can say 23.0122765, 65.000000 with a
precision of 1KM and an uncertainty of 50%.  My point is that 23.0122765,
65.0000 with uncertainty of 1KM is different from 23,65 with uncertainty of
1KM.  That difference may or may not matter to an application.  

XML is text, and therefore you can easily encode 23, 23.00000000 and
23.012275, and you don't need any mechanism to state significant digits;
what you see is what you get.  Yes, but you do need to show it for me to see
it.

The specific problem is that if the data was 23, 23.0, 23.00, 23.0000,
23.00000 or 23.0000000, there is a difference in those values that may
indeed matter to the application, even if it has separate confidence and
uncertainty values.  If I can't encode the difference in the mechanism that
gets data to the GML document creator, I have a problem.  John and Marc have
pointed that out, and they are correct.

Brian

> From: Carl Reed [mailto:[email-masked]]
> Sent: Wednesday, February 20, 2008 4:04 PM
> To: Brian Rosen; 'James M. Polk'; 'Thomson, Martin'; 'Winterbottom,
> James'; 'Marc Linsner'; 'GEOPRIV'
> > Gaussian.  That is why they came up with confidence and uncertainty:
> they
> > do
> > precision which is not significant digits and standard deviation.  We
> made
> > a

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 22 Feb 2008 08:52:16 -0500

Carl,

I'm curious about OGC's thoughts on GML carrying point-of-interest (POI)
data from mapping applications.  As far as I can tell, none of the mapping
applications utilize metadata elements to express precision/accuracy of the
POI.  Is it a goal of GML to be used in this space?

Or, are we to assume the what-you-see-is-what-you-get is meant to preserve
any implied precision of the variable length text encoding?

Thanks,

-Marc-

> To: Brian Rosen; 'James M. Polk'; 'Thomson, Martin'; 
> 'Winterbottom, James'; 'Marc Linsner'; 'GEOPRIV'
> With regard to GML, GML follows the ISO standards for 
> geometry, spatial referencing by coordinates, and so forth.
> 
> Precision/accuracy are considered to be metadata elements as 
> opposed to having to be a special property of a geometry that 
> states number of significant digits and so forth. GML 3.2.1 
> specifies that spatial metadata should be encoded using 
> 19139:2007 - Geographic information -- Metadata -- XML schema 
> implementation.
> 
> There is no explicit support for precision. (My note:  GML 
> payloads are generated by applications. Accuracy and 
> precision are driven by the applications and not GML per-se)
> 
> Regards
> 
> Carl
> 
> 
> <[email-masked]>; "'Marc Linsner'" 
> <[email-masked]>; "'GEOPRIV'" <[email-masked]>
> >really do understand the other guy's point of view, you know 
> that what  
> >they  are saying has merit, and yet you can't agree to come 
> up with a  
> >compromise.
> > The DHCP crowd is using normal engineering language and normal 
> > statistical analysis to discuss what we usually call "precision" 
> > whatever term you would like (I'm going to use "precision" 
> here, but 
> > you can turn that into any term you want).  They refuse to 
> discuss the 
> > notion that they only get one sample, it isn't possible to 
> calculate a 
> > meaningful standard deviation, the error distribution isn't 
> Gaussian 
> > and that there is so much experience in location 
> measurement that they 
> > have to resort to other, reasonably sound mechanisms to express 
> > precision.
> >
> > deviation or computable equivalents), they give you what they all 
> > decided what they could give you, which is something they defined, 
> > precisely, and call "confidence" and "uncertainty".
> >
> > I gather the GML folks made a mistake, and they seem to be 
> correcting 
> > the mistake.  Significant digits do indeed matter.  If I say I am 
> > located at
> > 73,21 with an uncertainty of 1 cm and a confidence of 95%, 
> then they 
> > really truly must say 73.0000, 21.0000 and not imply it if that is 
> > what they actually measure.  Note that I have not done the 
> > calculations, and I don't know how many significant digits 
> I need to 
> > express 1 cm precision in an engineering sense.
> >
> > precision, and they all have agreed to use it.  For the 
> DHCP crowd to 
> > say "sorry, we only accept significant digits and standard 
> deviation 
> > as the expression of precision" is unrealistic.  The folks that 
> > measure location have agreed how to express precision, and it's not 
> > significant digits and standard deviation.
> >
> > You cannot actually measure location using any known 
> technique and get 
> > a Gaussian distribution of error.  The real world doesn't work that 
> > way.  I believe that it's not even close to Gaussian for 
> real world measurements:
> > it's not Gaussian.  That is why they came up with confidence and 
> > uncertainty: they do a heck of a lot of measurements and 
> compute what 
> > they can say, rather than approximate with a Gaussian 
> distribution.  
> > Similarly, you can decide to express uncertainty with 
> circles or arc 
> > bands, etc, but the error distribution is NOT uniform in 
> that area, it 
> > is worse at the edges than in the middle and you know it, 
> but you all 
> > agreed to ignore it, and we're going to have to go along with that.
> >
> > You can't measure a point.  We all agree, a point is too small.  We 
> > aren't going to define new absurdities like "thick points".  We 
> > approximate, we express location of an object as location 
> of a point 
> > with some specified confidence and uncertainty.
> >
> > understanding that the practitioners have defined a mechanism to 
> > express precision which is not significant digits and standard 
> > deviation.  We made a mistake.  It was a reasonable mistake 
> to make, 
> > but it was a mistake.  We need to express geo precision using 
> > confidence and uncertainty.  That is the way the experts 
> agreed to do 
> > it.  We don't have superior expertise in that area.  The experts 
> > understand the issues and decided.  We should play along.
> >
> > I think we should return confidence and uncertainty.  We 
> should leave 
> > the rez stuff in, because significant digits matter.
> >
> > Brian
> >
> >
> [mailto:[email-masked]] On 
> >> Behalf Of James M. Polk
> >> >A better example would be to look at measuring the length 
> of a piece 
> >> >of string.  There is an actual value, but it's hard to 
> know exactly 
> >> >what it is.  Give the same piece of string to 10 people and tell 
> >> >them to measure it as accurately as they can and you will get 10 
> >> >different results.  If you were interested in getting the most 
> >> >accurate value, you'd toss outliers and pick the average 
> of the remaining results.
> >>
> >> the mean, actually
> >>
> >> >measurement results were.
> >>

---

From: "Marc Berryman" <[email-masked]>
Date: Fri, 22 Feb 2008 07:58:28 -0600

Thanks Brian for re-stating what I have been saying, and trying to
explain! 

Let hope someday it will be understood by all that there is a
significant difference between 23.0, 23.00, 23.0000, 23.00000 and
23.0000000. 

GML allows for this, so why not just place the proper number of
significant digits into the text string????

Marc B

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Rosen
Sent: Friday, February 22, 2008 7:32 AM
To: 'Carl Reed'; 'James M. Polk'; 'Thomson, Martin'; 'Winterbottom,
James'; 'Marc Linsner'; 'GEOPRIV'
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

If you say 23,65 with an uncertainty of 1/2cm and a confidence of 95%,
every
engineer and mathematician should start laughing.  If you say 23.000000,
65.00000 they will allow that it's possible, but be pretty suspicious.
If
you say 23.0133467, 65.0000000 with an uncertainty of 1/2cm and a
confidence
of 95%, they will be happy (and perhaps a little suspicious).  Your
point,
which I understand, is that you can say 23.0122765, 65.000000 with a
precision of 1KM and an uncertainty of 50%.  My point is that
23.0122765,
65.0000 with uncertainty of 1KM is different from 23,65 with uncertainty
of
1KM.  That difference may or may not matter to an application.  

XML is text, and therefore you can easily encode 23, 23.00000000 and
23.012275, and you don't need any mechanism to state significant digits;
what you see is what you get.  Yes, but you do need to show it for me to
see
it.

The specific problem is that if the data was 23, 23.0, 23.00, 23.0000,
23.00000 or 23.0000000, there is a difference in those values that may
indeed matter to the application, even if it has separate confidence and
uncertainty values.  If I can't encode the difference in the mechanism
that
gets data to the GML document creator, I have a problem.  John and Marc
have
pointed that out, and they are correct.

Brian

> <[email-masked]>; "'Marc Linsner'"
<[email-masked]>;
> > really do understand the other guy's point of view, you know that
what
> statistical
> > analysis to discuss what we usually call "precision" whatever term
you
> > would
any
> decided
> > what they could give you, which is something they defined,
precisely,
correcting
> > precision, and they all have agreed to use it.  For the DHCP crowd
to
> say
> > have agreed how to express precision, and it's not significant
digits
it's
> > a heck of a lot of measurements and compute what they can say,
rather
than
> in
> > the middle and you know it, but you all agreed to ignore it, and
we're
> > going
> aren't
express
> > need to express geo precision using confidence and uncertainty.
That is
> > the
> > way the experts agreed to do it.  We don't have superior expertise
in
> that
> > area.  The experts understand the issues and decided.  We should
play
> > along.
> >
> > I think we should return confidence and uncertainty.  We should
leave
> >> >A better example would be to look at measuring the length of a
piece
> of
> >> >string.  There is an actual value, but it's hard to know exactly
what
> >> >it as accurately as they can and you will get 10 different
results.
> If

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 22 Feb 2008 10:44:19 -0600

>significant difference between 23.0, 23.00, 23.0000, 23.00000 and

Marc - I think perhaps, that some applications cannot tell the 
difference, and perhaps bothering with it makes things harder for 
those applications.

Just a thought

---

From: "Carl Reed" <[email-masked]>
Date: Fri, 22 Feb 2008 09:52:22 -0700

Not trying to squirm :-)

This is an interesting issue and one that the GIS community tends to ignore 
as they typically carry confidence info and accuracy/precision info as 
metadata - although in the not too distant past they carried no metadata at 
all!

Let me phrase the issue correctly and bring it before the OGC members. No 
reason that we cannot develop a GML Change Request or develop an OGC GML 
Best Practice for this topic.

Given this approach, I was wondering if someone on this list could provide a 
succinct one paragraph description of the requirement. I could give a try by 
reading past emails but I fear that I would butcher the resulting text.

Thanks and regards

Carl

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Carl Reed'" <[email-masked]>; "'James M. Polk'" 
<[email-masked]>; "'Thomson, Martin'" <[email-masked]>; 
"'Winterbottom, James'" <[email-masked]>; "'Marc Linsner'" 
<[email-masked]>; "'GEOPRIV'" <[email-masked]>
Sent: Friday, February 22, 2008 6:31 AM
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

>> > need to express geo precision using confidence and uncertainty.  That 
>> > is
>> > the

---

From: Andrew Newton <[email-masked]>
Date: Fri, 22 Feb 2008 13:48:51 -0500

> what you see is what you get.  Yes, but you do need to show it for  

I'm probably not following this thread as closely as I could, so I'm  
not catching all the arguments.

GML is defined using XML Schema, and XML Schema has the  
"fractionDigits" facet for decimal data types.  See http://www.w3.org/TR/xmlschema-2/#rf-fractionDigits 
.  If I read that correctly, it is possible that 23.0 and 23.0000 are  
the same thing.  I'm not sure this is relevant, given that it would  
seem GML or the GEOPRIV use of GML would have to define this facet.

Additionally, unless told to explicitly preserve precision, most  
libraries will not do so.  They will convert the number to their  
internal representation and any implied precision will be lost.  If  
the goal is to preserve precision as this data is consumed and  
regurgitated in the network, the best thing to do is to be explicit.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 22 Feb 2008 14:39:39 -0600

Let us agree to disagree then Marc B.

There is no difference at all between these things, if you are trying to suggest that there is an error or an uncertainty then express it correctly as such (an area), and don't use significant digits to "suggest" it. As has been stated and shown more than once, stipulating uncertainty with significant digits merely provides the tools the get the answers wrong.

Cheers
James

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]]
Sent: Fri 2/22/2008 7:58 AM
To: Brian Rosen; Carl Reed; James M. Polk; Thomson, Martin; Winterbottom, James; Marc Linsner; GEOPRIV
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Marc B

-----Original Message-----

Brian

<[email-masked]>;
what
you
any
precisely,
correcting
to
digits
it's
rather
than
we're
express
That is
in
play
leave
piece
what
results.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 22 Feb 2008 17:01:24 -0500

First of all, for those of you reading at home, the base of this discussion
is NOT what is put in GML (in for example, a PIDF) but what is put in a DHCP
response which some other entity, such as a phone, will use to create a
PIDF, and thus a GML document from.  Andy's mention of losing precision in
libraries is thus quite germane.

I think James W is wrong.

I think his reasoning is something like (assuming circular uncertainty
regions):

If I have the point 23,46.0234 with (circular) uncertainty of +/-.005, then
the actual location somewhere within a circle of centered at
23.000000000000,46.0234 with a radius of .005.  Whether you say 23, 23.0,
23.000 or 23.000000000 the area of uncertainty is exactly the same and the
possible places the actual location can be is exactly the same.  Therefore,
significant digits don't matter -- it is the uncertainty value that tells
you what the size of the uncertainty region is.

However, if you say 23, 46.0234, then the x coordinate of the center point
of the circle is somewhere between 22.50000 and 23.49999 and the radius of
the circle is .005.  If you say 23.0000, 46.0234, then the x coordinate of
the center point of the circle is somewhere between 22.00005 and 23.000049
and the radius is still .005.  The possible places where the actual location
could be in those two cases are different, because the center could be in a
different place, and the radius is the same.  I could have a point that was
inside the uncertainty region in one case, but outside it in the other. 

Brian

> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Friday, February 22, 2008 3:40 PM
> To: Marc Berryman; Brian Rosen; Carl Reed; James M. Polk; Thomson, Martin;
> Marc Linsner; GEOPRIV
> There is no difference at all between these things, if you are trying to
> suggest that there is an error or an uncertainty then express it correctly
> as such (an area), and don't use significant digits to "suggest" it. As
> has been stated and shown more than once, stipulating uncertainty with
> significant digits merely provides the tools the get the answers wrong.
> 
> Cheers
> James
> 
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 22 Feb 2008 16:42:30 -0600

No, because you are using significant digits again to express the uncertainty.

Your premise in the first part of the last paragraph is wrong. The centre of the circle for the X co-ordinate is not between 22.5 and 23.49.... it is exactly at 23, which is 23.0000000000000...  So the answer is exactly the same.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Fri 2/22/2008 4:01 PM
To: Winterbottom, James; 'Marc Berryman'; 'Carl Reed'; 'James M. Polk'; Thomson, Martin; 'Marc Linsner'; 'GEOPRIV'
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 22 Feb 2008 19:36:59 -0600

Hi Brian,

What is your scenario actually an example of?

Presumably it's not using a 3825 encoded location - because you can't have that key piece of information that the uncertainty radius is .005 degrees (was it, or is it metres? - maybe I missed it, but I didn't see you state the units that this uncertainty circle is in).

So - if you know the actual uncertainty radius, what *use* are the significant digits in the lat/lon values? If you try to infer any kind of uncertainty from those significant digits, then you get one of:

* A region of uncertainty that overlaps but neither covers all the actual uncertainty area nor lies completely within it (see last response on the interpretation of the region example in the draft) which confuses the recipient as to how they should interpret the information.

* A region of uncertainty which is completely inside the actual (.005) area of uncertainty and therefore  doesn't add any new information

* A region of uncertainty which completely swallows the actual (.005) area of uncertainty and leaves the recipient of the information wondering what they are meant to infer from the significant digits. Which is the normative piece of information - the resolution or the uncertainty radius?

I have *no objection* to interpreting 3825 as only being able to communicate significant digits. I don't know what practical purpose they serve. I would like the explanations to highlight that, in fact, they are quite inadequate for encoding regions bounding uncertainty. It would be good to have a practical example of how they are actuallyuseful. Similarly, GML can define how to encode a point that conveys the number of significant digits that the sender wants to convey.... for whatever purpose they might want to do that. Let's be clear - they have no practical use for communicating uncertainty areas.

BTW - given Marc's observation that NMEA supports arbitrary numbers of digits in the lat/lon values, I checked out one of our Novatel receivers. As I metioned, we don't use NMEA because it doesn't provide the more sophisticated measurementsthat GPS devices actually make. I noted, however, that while the receiver does use a specific number of digits in the NMEA output, it always uses the same number of them. That is, regardless of the actual uncertainty the receiver calculates, the Novatel always presents the same number of digits on the NMEA output. It's only one receiver - but it is a data point (no pun intended) in this discussion.

Cheers,
Martin

-----Original Message-----
From: [email-masked] on behalf of Brian Rosen
Sent: Sat 2/23/2008 9:01 AM
To: Winterbottom, James; 'Marc Berryman'; 'Carl Reed'; 'James M. Polk'; Thomson, Martin; 'Marc Linsner'; 'GEOPRIV'
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Brian

---

From: "Marc Linsner" <[email-masked]>
Date: Sat, 23 Feb 2008 17:40:46 -0500

Martin, 

> 
> I have *no objection* to interpreting 3825 as only being able 
> to communicate significant digits. I don't know what 
> practical purpose they serve. I would like the explanations 
> to highlight that, in fact, they are quite inadequate for 
> encoding regions bounding uncertainty. It would be good to 
> have a practical example of how they are actuallyuseful.
> Similarly, GML can define how to encode a point that conveys 
> the number of significant digits that the sender wants to 
> convey.... for whatever purpose they might want to do that. 
> Let's be clear - they have no practical use for communicating 
> uncertainty areas.

So, in your opinion, when is it necessary to communicate uncertainty?
(Quick fix?)  It seems the only application area that includes uncertainty
data is within the cellular industry.  I've found no evidence of it outside
of that industry.  Aviation, Marine, and non-cellular Consumer devices do
not communicate uncertainty data, at least none in a 'standard' protocol.
The cellular consumer devices that provide uncertainty data, as you point
out, do so on the A-GPS side of the device, towards the network and do not
present it to the local OS, locally NMEA is used.  (Yes, Garmin devices send
uncertainty radius information in a vendor-proprietary NMEA statement.)

Also, I've found no point-of-interest data (POI) that includes uncertainty,
this includes the data loaded into aviation units that perform instrument
approach/landing procedures.  So, aviation gps units talk NMEA and
autopilots land airplanes without the use of uncertainty data. (even to the
point of breaking runways as every plane lands in the same spot)

> 
> BTW - given Marc's observation that NMEA supports arbitrary 
> numbers of digits in the lat/lon values, I checked out one of 
> our Novatel receivers. As I metioned, we don't use NMEA 
> because it doesn't provide the more sophisticated 
> measurementsthat GPS devices actually make. I noted, however, 
> that while the receiver does use a specific number of digits 
> in the NMEA output, it always uses the same number of them.

I've witnessed the output on different machines and I believe it's dictated
by the designer to fit the target application, i.e., aviation may include
more digits than consumer street mapping.

-Marc-
 
> That is, regardless of the actual uncertainty the receiver 
> calculates, the Novatel always presents the same number of 
> digits on the NMEA output. It's only one receiver - but it is 
> a data point (no pun intended) in this discussion.
> 
> Cheers,
> Martin
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Sat, 23 Feb 2008 21:39:53 -0600

Hi Marc,

My personal goal on this thread isn't to defend the usefulness of
"uncertainty" - though I have done my best below to provide you a
flavour of my perspective. My primary goal is to fix 3825 (and the
binary-lci draft if that's the way to go) so there is no confusion about
the ability to use 3825 for representing uncertainty. It can't be
effectively used for this and currently both the normative text in 3825
and the binary-lci draft perpetuate the misconception (and associated
user confusion) that it can be.

I'll try to answer your questions:

> data is within the cellular industry.

Uncertainty is *useful* for such things as:

* Call routing - whether it's for emergency calls, roadside assistance
calls, pizza franchise "one number" calls. Indeed, it doesn't need to be
"calls" per se - it could be for appropriately routing any form of
communication including voice, IM, email... where evaluating the
likelihood the actual location being on one side of a routing boundary
or not needs to be resolved.

* Dispatch management - whether it's for police, ambulance, fire, sea
rescue, mountain rescue, roadside assistance, dementia patient
"recovery", rail rolling stock recovery,... where the nominal area to
search needs to be communicated.

* Local information services - tailoring amount and detail of
information based on the indicated area of uncertainty associated with
the users' reported location, screen real estate, and human factors
generally.

* Collision avoidance systems - based on projected overlap of
uncertainty areas.

It's quite inappropriate to characterize any of these sorts of things as
somehow "cellular specific" or only pertinent to "quick fix". An example
of a cellular specific application would be to use the uncertainty
information to implement predictive handoff between network cells - and
identifying the optimal cell to hand off to. Otherwise, these
applications are specific to *the emergency service sector* or the
*roadside assistance sector* or the *web location content sector* etc.
The nature of the access network is moot.

Uncertainty arises from the systems that provide the geodetic location
information that are used in these application domains. It is not only
cellular systems that will have uncertainty. Further, it is not
desirable to require an application to *know* what sort of system the
location information derived from and make *per use* decisions about how
it should interpret the location information. Hence, a location
acquisition mechanism that can provide uncertainty information is more
general and useful than one that can't.

Locations delivered over DHCP can very definitely be subject to
uncertainty - it might be the uncertainty associated with the extents of
a building or an entire campus. That's up to the administrator but 3825
doesn't provide an administrator an effective way to communicate this
information to the DHCP clients. 

I don't strongly object to DHCP lacking this capability - there are
alternatives that can provide location information with uncertainty and
they can be used instead of DHCP. I want it to be made clear in the 3825
specification (whether it's via this lci-binary draft or another
mechanism) that 3825 can't be used to effectively communicate
uncertainty and indeed that the normative text in 3825 that says it can
is actually in error. Currently the opposite is being done - continuing
to suggest that uncertainty boundaries can be effectively communicated
with 3825.

For example, the second example in the binary-lci draft strongly implies
that it shows the bounding area used in the example being successfully
represented with resolution. What it actually shows is that it isn't -
and so it would be more appropriate to highlight it as a counter-example
and say it demonstrates why resolution is generally not useful for
representing bounding areas.

With respect to your observation that POI data isn't documented with
uncertainty, my only comment is that this is an example (I don't know
how true or representative) of an application presentation that doesn't
use uncertainty. I don't claim that uncertainty is expressed everywhere
in every walk of life. I'm saying that when it comes to location
measurement systems and network systems that communicate location to
devices for use with unknown and arbitrary applications, that a system
which can communicate uncertainty is more generally useful than one that
can't.

> I've witnessed the output on different machines and I believe it's
> dictated by the designer to fit the target application, i.e., aviation
> may include more digits than consumer street mapping.

This comment isn't pertinent to my observation. Regardless of whether
the Novatel receiver is being used for aviation or street mapping, I
noted that it uses the same number of digits in the NMEA output no
matter what the actual uncertainty was in the GPS calculated result. So
to infer *actual precision* from the number of digits this receiver put
in the NMEA output would be a mistake. The *actual* precision may be
more or less - depending on the quality of the fix - so it's evident
that the receiver is not attempting to provide any explicit resolution
information based on the number of digits in the output. I believe you
were suggesting that DHCP administrators would use the number of digits
in a GPS device NMEA output to configure resolution into the DHCP
location record. Indeed, this use case may have inspired the inclusion
of resolution in the codec in the first place. I find the use case
somewhat presumptuous (i.e. surely administrators will use all sorts of
mechanisms to source the location information) and, apparently, it's
based on an invalid premise anyway.

Finally - do you have an example of precision/resolution being useful to
a DHCP client. I know you've taken the position that this isn't your
problem - it's up to whoever uses it. However, surely you had something
in mind when you included it in the spec? As above - I don't really care
if you can't find any good examples; I really just want 3825 fixed such
that it's not incorrect.

Cheers,
Martin

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Sunday, 24 February 2008 9:41 AM
To: Dawson, Martin; 'Brian Rosen'; Winterbottom, James; 'Marc Berryman';
'Carl Reed'; 'James M. Polk'; Thomson, Martin; 'GEOPRIV'
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Martin, 

So, in your opinion, when is it necessary to communicate uncertainty?
(Quick fix?)  It seems the only application area that includes
uncertainty
data is within the cellular industry.  I've found no evidence of it
outside
of that industry.  Aviation, Marine, and non-cellular Consumer devices
do
not communicate uncertainty data, at least none in a 'standard'
protocol.
The cellular consumer devices that provide uncertainty data, as you
point
out, do so on the A-GPS side of the device, towards the network and do
not
present it to the local OS, locally NMEA is used.  (Yes, Garmin devices
send
uncertainty radius information in a vendor-proprietary NMEA statement.)

Also, I've found no point-of-interest data (POI) that includes
uncertainty,
this includes the data loaded into aviation units that perform
instrument
approach/landing procedures.  So, aviation gps units talk NMEA and
autopilots land airplanes without the use of uncertainty data. (even to
the
point of breaking runways as every plane lands in the same spot)

> in the NMEA output, it always uses the same number of them.

I've witnessed the output on different machines and I believe it's
dictated
by the designer to fit the target application, i.e., aviation may
include
more digits than consumer street mapping.

-Marc-

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 23 Feb 2008 21:55:12 -0800

Having read this whole thread, what I got out of it was

A) the DHCP drafts is capable of describing a roughly rectangular  
shape where the location of the thing in questions is probably inside  
this rectangle

B) The way GEOPRIV uses GML to describe a roughly rectangular shape  
where the location of something is probably inside seems to be using a  
four vertex Polygon like the polygon in section 5.2.2. of draft-ietf- 
geopriv-pdif-lo-profile-11.

Am I correct in my understanding of A and B?

Cullen <with my individual contributor hat on>

On Feb 12, 2008, at 8:04 AM, Richard Barnes wrote:

> to GML.

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 24 Feb 2008 01:33:18 -0600

Hi Cullen,

Your description of (A) reflects the kind of misunderstanding that 3825 (and lci-binary) causes.

You can't take a "rectangular shape where the location of the thing in question is" and express it with significant digits.

Yes - you can take a point expressed with a limited resolution and see what rectangular area it ends up looking like - but you can't go the other way. This should be fairly obvious - with only 34 possible values of resolution, there are only 34 possible "regions" you can describe with these resolution break points for each of lat or lon. Further, which bit becomes the least significant one is driven by *where the region is* and not how precisely it could actually be determined.

Consider an area of uncertainty between 15.999 and 16.034 latitude. In the binary form, the largest number of 3825 significant digits that don't preclude at least part of this region is 4 - and the Lat value is 0000xxxxx.xxxxxxxxxx... - i.e. the location is between zero and 32 degrees and to cover this area of uncertainty the Lat value must be sent as zero and LaRes set to 4. Needless to say, 0-32 degrees is a wholly inadequate representation of 15.999 to 16.034 degrees. Now - I had to do this because of *where* the actual region was located and not because of how accurately or with what confidence I could determine it.

The shapes that the pidf-lo profile define allow areas of uncertainty with arbitrary size and location to be described and exactly with the accuracy to which they could be determined - something resolution on its own simply can't do. I think the only pertinent question from the GML perspective is whether we also want to add a "point with resolution" encoding - which would have the same characteristics as the 3825 codec. I don't have an objection to creating this new type but I also haven't found out why it is useful either.

Your précis sounded like the only difference between A & B is how the DHCP RFC and GML go about representing the same thing. That is incorrect - the latter is capable of representing something that the former is not. 3825 and binary-lci should not state or imply that the RFC can be used to encode bounding areas.

Cheers,
Martin

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 24 Feb 2008 15:13:52 -0800

So I certainly agree with you that the significant digits end up  
expressing a rectangle, and not that any rectangle can be expressed  
with significant digits. How would you phrase (A) so that it did not  
add to confusion in this sort of way?

More inline

On Feb 23, 2008, at 11:33 PM, Dawson, Martin wrote:

> You can't take a "rectangular shape where the location of the thing  
> in question is" and express it with significant digits.
>
> Yes - you can take a point expressed with a limited resolution and  
> see what rectangular area it ends up looking like - but you can't go  
> the other way. This should be fairly obvious - with only 34 possible  
> values of resolution, there are only 34 possible "regions" you can  
> describe with these resolution break points for each of lat or lon.
agreed - I did not mean to imply otherwise.

> Further, which bit becomes the least significant one is driven by  
> *where the region is* and not how precisely it could actually be  
> determined.
>
> Consider an area of uncertainty between 15.999 and 16.034 latitude.  
> In the binary form, the largest number of 3825 significant digits  
> that don't preclude at least part of this region is 4 - and the Lat  
> value is 0000xxxxx.xxxxxxxxxx... - i.e. the location is between zero  
> and 32 degrees and to cover this area of uncertainty the Lat value  
> must be sent as zero and LaRes set to 4. Needless to say, 0-32  
> degrees is a wholly inadequate representation of 15.999 to 16.034  
> degrees. Now - I had to do this because of *where* the actual region  
> was located and not because of how accurately or with what  
> confidence I could determine it.

So given we know we are in the 15.999 to 16.034 range, I totally agree  
that if the best representation we could provide of this in DHCP had a  
range of 32 degrees, that would not be acceptable. I think this topic  
here is hugely important to if we need to do something to 3825 or not  
and I would very much appreciate if you could walk me though this in  
as a detailed example. I know you have said this many times in the  
past but I have never been able to work thought the whole example.

Could you walk this example thought how it would convert into the  
smallest region that we can represent in the binary-lci form that  
still totally covers the above range then convert that back out from  
binary to normal latitudes. If we end up with a range that 32 degrees,  
I agree it is broken but I'd love to see the example worked through.  
Thank you in advance.

>
>
> The shapes that the pidf-lo profile define allow areas of  
> uncertainty with arbitrary size and location to be described and  
> exactly with the accuracy to which they could be determined -  
> something resolution on its own simply can't do.

agree

> I think the only pertinent question from the GML perspective is  
> whether we also want to add a "point with resolution" encoding -  
> which would have the same characteristics as the 3825 codec. I don't  
> have an objection to creating this new type but I also haven't found  
> out why it is useful either.

Again I think we mostly agree. I agree it would be easy to do. I'm not  
particularly for or against the idea but I would want to know why it  
was useful to have it. In general I find lots of options no one needs  
never help interoperability.

>
>
> Your précis sounded like the only difference between A & B is how  
> the DHCP RFC and GML go about representing the same thing. That is  
> incorrect - the latter is capable of representing something that the  
> former is not. 3825 and binary-lci should not state or imply that  
> the RFC can be used to encode bounding areas.

I think your phrase "bounding area" confuses the issue. If we say a  
rectangle R that is collinear with the equator bounds the polygon P,  
we could mean a few things. One would be the smallest rectangle such  
that P was inside R. Another meaning would be any R where P was  
inside. I believe the correct term for the first is "minimum bounding"  
while the second is just "bounding". The DHCP stuff can do the  
bounding but not the minimum bounding. But ignoring the terminology  
issue, we both are very clear on that DHCP can and can not do and back  
to my original question at the top, I'd be happy if you could help me  
rephrase A so that it was widely understood by people that did not  
care about uncertainty, resolution, and error yet did not cause any of  
the type of confusion you are worried about here.

> Martin

Cullen (in my individual contributor role)

> Behalf Of Cullen Jennings

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 24 Feb 2008 19:53:30 -0600

Hi Cullen,

It does depend on why A & B are being written to begin with, but a correct way to write two such contextual statements would be:

A) 3825 provides a way to explicitly state the number of binary digits that should be considered significant in a 34 bit fixed point representation of each of the latitude and longitude values associated with a point.

B) The pidf-lo profile specification does not include an equivalent GML encoding for a point that explicitly indicates the number of significant digits for each of the latitude and longitude values of that point.

Presumably the follow on question is whether we should add this GMLC encoding. It's not something I'm for or against; I guess the main use would be as vehicle to not lose the explicit significant digit information from a 3825 packet.

I'm not sure that there's anything more to be said as far as working through the example.

The range is 15.999 to 16.034

3825 allows me to encode it as a 34 bit fixed decimal number, with 9 bits before the decimal point. The only binary range that completely encloses the target range is 0-32 degrees. The *next smallest* range is 0-16 and that leaves out the upper 0.034 degrees of the region(which is actually the largest part of it). So - the 3825 encoding that includes the whole region is:

0000xxxxx.xxxxxxxxxxxxxxxxxxxxxxxxx with Res set to 4

Of course, you have to put some numbers in the other 21 non-siginficant bits when you populate the fields in the option but, by definition, they are not significant; they can be anything.

The recipient gets a value which they interpret as anything from zero to 31.9999999 recurring (I call it 32 for convenience).

> bounding but not the minimum bounding.

Terminology is certainly problematic - and there's been no end of semantic gymnastics in the discussion. However, it's definitely true that the minimum bounding area that DHCP can communicate in the above example is zero to 32 degrees.

BTW, the example in the lci-binary draft uses a target that straddles 32 degrees (it's 31.99999850 to 32.00000274). The actual minimum bounding that can be used to enclose this target is zero to 64 degrees. The example text has a lot of machinations around determining an error value associated with the target but then doesn't follow through with conclusions about how it applies in the final 3825 encoding. The example actually implies that the final encoding should be 000100000.0000000000000000000010101  32.00000062 with Res set to 27; i.e. the last .... 0010101 part has no significance. Well, since 27 bits of resolution means that it's the first 27 bits that are significant, and as I said to John S, this results in the following interpretation for the recipient of the encoding:

000100000.0000000000000000000XXXX

That is:

To

So the result is a range that has the lower value inside the original range and an upper value which is outside the original range that was the subject of the example. I think this was a mistake. It certainly ends up with a smaller range than the 64 degrees that can actually be communicated and still bounds the range but at the expense of being wrong and conveying the wrong information.

Cheers,
Martin

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Monday, 25 February 2008 10:14 AM
To: Dawson, Martin
Cc: Richard Barnes; GEOPRIV
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

More inline

agree

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 24 Feb 2008 22:14:47 -0800

On Feb 24, 2008, at 5:53 PM, Dawson, Martin wrote:
> 3825 allows me to encode it as a 34 bit fixed decimal number, with 9  
> bits before the decimal point. The only binary range that completely  
> encloses the target range is 0-32 degrees. The *next smallest* range  
> is 0-16 and that leaves out the upper 0.034 degrees of the  
> region(which is actually the largest part of it). So - the 3825  
> encoding that includes the whole region is:
>
> Of course, you have to put some numbers in the other 21 non- 
> siginficant bits when you populate the fields in the option but, by  
> definition, they are not significant; they can be anything.
>
Let me see if I follow your argument here.... Lets just change the  
example slightly to 19.09 and 20.01 and work in base 10 instead of  
base 2. You are saying that if I wanted to represent the measurement  
20+/-0.01 with significant digits in base 10, I would need to write  
100 because only 0 to 100 fully covered the range 19.09 to 20.01 ? I  
was sort of expecting I could write 20.0

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 25 Feb 2008 01:56:40 -0600

Hi Cullen,

Here's the text from 3825 for LaRes:

" .This value is the number of high-order Latitude bits that should be
   considered valid.  Any bits entered to the right of this limit should
   not be considered valid and might be purposely false, or zeroed by
   the sender.

   The examples in the appendix illustrate that a smaller value in the
   resolution field increases the area within which the device is
   located."

In the example you suggest, you don't have any mechanism to communicate
the 0.01 part using DHCP. You've only got significant digits. Using the
decimal version of 3825, and assuming you wanted to send 20.0, you'd
send something like:

020.000000 with Res set to 4. which is 020.000000 to 020.099999 (let's
say 20.01).

So, yes, you'd be stuck with something between 0 and 100 (99.999...) if
you wanted to enclose your region.

Now, you may have been wanting to apply a typical interpretation of
precision - except that it's usually a half the significance of the
remaining digits.

i.e. 20.0 is 20.00 +/- 0.05 which is 19.05 to 20.05

I don't believe the 3825 text points to that interpretation. But,
nevertheless, this also doesn't give me any power to represent specific
areas because the size of the area isn't coupled to the precision with
which a point is measured. It's certainly not a satisfactory
representation of your 19.09 to 20.01 (I'm prepared to stand corrected
but I think that .a 08 difference in latitude accounts for about 9km) -
or the infinite number of other possible regions that could be anywhere
within that range.

If 3825 *intends* to convey the interpretation that the precision is
plus or minus the maximum value of the remaining "insignificant" digits
then it needs to say so. It doesn't - and, in fact, the example in 3825
is consistent with the "the other digits can be anything"
interpretation.

Regardless, and this is the important thing, there should be no talk of
3825 being useful for conveying "areas" or "regions". Significant digits
(or precision) alone do not have the necessary expressive power to do
this. Since it's not possible for the sender to communicate a specific
region using DHCP, it's really really important that receivers don't
attempt to interpret the received value that way - it's just a point
with significant digit numerators or precision (and it's unclear what
use those are to the receiver). I would actually prefer 3825 to make
this clarification explicitly - currently it leaves readers with the
opposite impression - as does binary-lci.

Cheers,
Martin

---

From: "Marc Berryman" <[email-masked]>
Date: Mon, 25 Feb 2008 06:45:47 -0600

Since James is being disagreeable :>) let me try to go at this from a
different angle. Actually I think the problem is a mathematicians view
verses a geographers view verses a programmers view 

The mathematician says 23.0, 23.00, 23.000, and 23.0000 are all the
same. 

The geographer says they are all different. I will illustrate this fact
from a geographer's point of view. 

A programmer says, it depends on the application. I'll hold off on the
programmers view until the end. I think it will drive home the point I
am trying to illustrate. 

23.0, 23.00, 23.000, 23.0000 How many digits to get the precision we
need? 

At the equator 1 degree of longitude and 1 degree of latitude both equal
equals 60 nautical miles. 

A nautical mile is exactly 1,852 meters, or 6,076.11549 feet in length.
1 nautical mile is about 1.15077 statute miles, which makes 1 degree
equal to 69 statute miles (at the equator). 

1 degree equals 69 statute miles 
1 degree equals 69 * 5280 = 364,320 feet 
0.1 degree equals 6.9 * 5280 = 36,432 feet 
0.01 degree equals 		3,643.2 feet 
0.001 degree equals 	364.32 feet 
0.0001 degree equals 	36.432 feet 
0.00001 degree equals 	3.6432 feet 
Accuracy is +/- 1 of the last significant digit so we can build the
following table 

Decimal degree accuracy 
1 +/- 	364,320 feet 
0.1 		36,420 feet 
0.01 	3,642 feet 
0.001 	364.2 feet 
0.0001 	36.42 feet 
0.00001 	3.6432 feet 

So now one should be able to determine that from a geographical space
that 23.0, 23.00, 23.000, and 23.0000 are all quite different, due to
the implied accuracy of the number of significant digits to the left of
the decimal place. 

Now from a programmers perspective, dealing only with Latitude for this
example. Lets say I have a spatial database of all the structures within
an area, with addresses for each structure.
If I wish to find all the addressed structures within a given area I
would query the data for Latitude 23.0 and get back a few thousand
For Latitude 23.00 would return several hundred
For Latitude 23.000 would return several dozen
For Latitude 23.0000 would return a few
For Latitude 23.00000 would return one

So from a geographers and a programmer's view 23.0, 23.00, 23.000, and
23.0000 are all different, because we are counting the numbers to the
right of the decimal point as significant digits.

Marc B

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 4:43 PM
To: Brian Rosen; Marc Berryman; Carl Reed; James M. Polk; Thomson,
Martin; Marc Linsner; GEOPRIV
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

No, because you are using significant digits again to express the
uncertainty.

Your premise in the first part of the last paragraph is wrong. The
centre of the circle for the X co-ordinate is not between 22.5 and
23.49.... it is exactly at 23, which is 23.0000000000000...  So the
answer is exactly the same.

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Fri 2/22/2008 4:01 PM
To: Winterbottom, James; 'Marc Berryman'; 'Carl Reed'; 'James M. Polk';
Thomson, Martin; 'Marc Linsner'; 'GEOPRIV'
Subject: RE: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
 
First of all, for those of you reading at home, the base of this
discussion
is NOT what is put in GML (in for example, a PIDF) but what is put in a
DHCP
response which some other entity, such as a phone, will use to create a
PIDF, and thus a GML document from.  Andy's mention of losing precision
in
libraries is thus quite germane.

If I have the point 23,46.0234 with (circular) uncertainty of +/-.005,
then
the actual location somewhere within a circle of centered at
23.000000000000,46.0234 with a radius of .005.  Whether you say 23,
23.0,
23.000 or 23.000000000 the area of uncertainty is exactly the same and
the
possible places the actual location can be is exactly the same.
Therefore,
significant digits don't matter -- it is the uncertainty value that
tells
you what the size of the uncertainty region is.

However, if you say 23, 46.0234, then the x coordinate of the center
point
of the circle is somewhere between 22.50000 and 23.49999 and the radius
of
the circle is .005.  If you say 23.0000, 46.0234, then the x coordinate
of
the center point of the circle is somewhere between 22.00005 and
23.000049
and the radius is still .005.  The possible places where the actual
location
could be in those two cases are different, because the center could be
in a
different place, and the radius is the same.  I could have a point that
was
inside the uncertainty region in one case, but outside it in the other. 

Brian

> To: Brian Rosen; Carl Reed; James M. Polk; Thomson, Martin;
Winterbottom,
> James; Marc Linsner; GEOPRIV
> > > you want).  They refuse to discuss the notion that they only get
one
> > > sample,
> > > it isn't possible to calculate a meaningful standard deviation,
the
> > error
> > > distribution isn't Gaussian and that there is so much experience
in
> > > location
> > > 73,21 with an uncertainty of 1 cm and a confidence of 95%, then
they
> > > really
> > > actually measure.  Note that I have not done the calculations, and
I
> > don't
> > > know how many significant digits I need to express 1 cm precision
in
> > > "sorry, we only accept significant digits and standard deviation
as
> > > approximate with a Gaussian distribution.  Similarly, you can
decide
> > > My conclusion is that 3825 is wrong.  The mistake arose from a
lack
> > > mistake.  It was a reasonable mistake to make, but it was a
mistake.
> We
> > >> outstanding job of defining that area to give an uncertainty
value
> ----------------------
> ----------------------

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 25 Feb 2008 07:37:36 -0600

Hi Marc,

Using your handy chart, how would you represent, using just precision, a
line extending, say, 653.8 feet either side of, say, +1.5876 degrees
latitude?

Cheers,
Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marc Berryman
Sent: Monday, 25 February 2008 11:46 PM
To: Winterbottom, James; Brian Rosen; Carl Reed; James M. Polk; Thomson,
Martin; Marc Linsner; GEOPRIV
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

Decimal degree accuracy 
1 +/- 	364,320 feet 
0.1 		36,420 feet 
0.01 	3,642 feet 
0.001 	364.2 feet 
0.0001 	36.42 feet 
0.00001 	3.6432 feet 

Marc B

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]]
Sent: Fri 2/22/2008 4:01 PM
To: Winterbottom, James; 'Marc Berryman'; 'Carl Reed'; 'James M. Polk';

Brian

Winterbottom,
one
the
in
they
I
in
as
decide
lack
mistake.
value

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 25 Feb 2008 12:52:28 -0500

Please cite the reference for this claim.  It does not appear in any
document I've seen.

I am not using significant digits to express uncertainty.  I am using normal
engineering notation to express a value in a coordinate system.  You can
very reasonably write 2.36545 +/-.02 if you want to.  What you cannot
reasonably do is write 23 +/- .000001.  Expressing uncertainty of a two
dimensional coordinate system using a circle is reasonable, and, once again,
I'm not objecting to the notion that we should express uncertainty expressly
and not imply it with significant digits.  However, 23 and 23.0 are not the
same thing.  You cannot infer that 23 +/- .001 is 23.000 +/- .001. If you
get 23 +/- .001 you have missing data.  If it is 23.000, you must say that.

You may possibly be able to get me to say that if we express uncertainty
separately, that we could compute the number of significant digits in a
binary representation of the coordinate system by impressing some model on
the data and use the uncertainty to infer the number of significant digits
needed to express the coordinate.  This means in theory you could add an
uncertainty value to the DHCP value, impress a WGS-84 model of the earth on
the data with the specified uncertainty, calculate the number of bit of
precision needed to get that to be correctly reflected in the coordinate,
and IMPLY that the value in the binary representation represents that number
of digits.

I can say that, but I'm not in favor of doing that.  I think we must retain
the ability to express significant bits in the binary representation
explicitly.  If some LIS reports 23,52 with an uncertainty of a cm, I would
be looking for a problem, whereas I know how well meaning devices deliver
23.02766, 52.47786 with an uncertainty of 500 meters.  

Brian

> Sent: Friday, February 22, 2008 5:43 PM
> To: Brian Rosen; Marc Berryman; Carl Reed; James M. Polk; Thomson, Martin;
> Marc Linsner; GEOPRIV
> Your premise in the first part of the last paragraph is wrong. The centre
> of the circle for the X co-ordinate is not between 22.5 and 23.49.... it
> is exactly at 23, which is 23.0000000000000...  So the answer is exactly
> the same.
> 
> 
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 25 Feb 2008 15:49:41 -0600

Brian,

The lexical representation of a number does not imply anything about the
value.  Both you and Marc have this same confusion.

I expect that many implementations will take a calculated or stored
value (which is probably represented as an IEEE 754 floating point
number internally) and apply standard methods for acquiring a binary
representation.  If the number happens to be very close to a whole
number, that's what you will get.  Therefore, 23 +/- 0.000001, while
highly unlikely, is a possible result.  Implying that an implementation
has an obligation to adjust significant figures, where it has already
provided a superior alternative means of expressing uncertainty, is not
sensible.

Furthermore, 23 +/- 0.000001 is exactly the same as 23.000000 +/-
0.000001, whatever perceived credibility the second has over the first.
Try the following comparison some time:
  if (23 == 23.000000) printf("OMG.\n");

I can appreciate that certain communities have conventions that assign
an implicit meaning to significant figures.  Protocols need to be
explicit.  Hence the discussion.

Cheers,
Martin

> Sent: Tuesday, 26 February 2008 4:52 AM
> and not imply it with significant digits.  However, 23 and 23.0 are
not
> binary representation of the coordinate system by impressing some
model
> on
> centre
> > of the circle for the X co-ordinate is not between 22.5 and
23.49....
> > is NOT what is put in GML (in for example, a PIDF) but what is put
in
> a
> > DHCP
> > response which some other entity, such as a phone, will use to
create
> > could be in those two cases are different, because the center could
> be in
> > a
> opposed
> > > > significant digits and so forth. GML 3.2.1 specifies that
spatial
> > > metadata
> > > > GML is XML, i.e. it is a text encoding, so what you see is what
> you
> > > get.
> payloads
> > > are
> > > > >I get this feeling you guys are bashing each other for sport;
> that
> > > you
> > > > > are saying has merit, and yet you can't agree to come up with
a
> > > > > you want).  They refuse to discuss the notion that they only
> get one
> > > > > sample,
> > > > > distribution isn't Gaussian and that there is so much
> experience in
> > > > > location
> > > > > measurement that they have to resort to other, reasonably
sound
> > > > mechanisms
> > > > > language, and statistics created specifically for this
> environment
> > > to
then
> they
> > > > > really
> > > > > truly must say 73.0000, 21.0000 and not imply it if that is
> what
> > > they
> > > > > actually measure.  Note that I have not done the calculations,
> and I
> > > > don't
> > > > > know how many significant digits I need to express 1 cm
> precision in
> > > an
> > > > > engineering sense.
> > > > >
> > > > > "sorry, we only accept significant digits and standard
> deviation as
> > > the
> > > > > expression of precision" is unrealistic.  The folks that
> measure
> > > > location
> > > > > You cannot actually measure location using any known technique
> and
> > > get a
> > > > > Gaussian distribution of error.  The real world doesn't work
> that
> > > way.
> > > > I
> > > > > You can't measure a point.  We all agree, a point is too
small.
> > > > > precision which is not significant digits and standard
> deviation.
> > > We
> > > > made
> > > > > a
should
> > > > >> >is.  Give the same piece of string to 10 people and tell
them
> > > > measure
> > > > >> >you were interested in getting the most accurate value,
you'd
> toss
> > > > >> >But that value is not the true value any more than any one
of
> > > > >> tossed away the outliers), your bell curve should show
results
> > > > >> The problem I have with location measurements of endpoints -
> is
> > > there
> > > > >> If you agree that "confidence = probability", then I call
this
> > > > >> difference that I see from out thread is that it doesn't
> appear
> > > that
> > > > >> likelihood a target is within an area (say a room) or not. If
> I
> > > were
> > > > >> to really get into uncertainty, I'd peg the "uncertainty"
> value
> > > into
> > > > >> the bell curve as a function of how many Standard Deviations
> is
> > > > >> acceptable.
> > > > >>
> > > > >> in or out of an area, and the first Standard Deviation is
> 30cm,
> > > then
> > > > >> I'd say however you're measuring where the target is, you've
> done
> > > an
-------------------------------------------------------------------
> -----
-------------------------------------------------------------------
> -----
---------------------------------------------------------------------
> -----
---------------------------------------------------------------------
> -----

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 26 Feb 2008 08:30:50 -0800

Ok, so in your example of a range is 15.999 to 16.034 what is the  
largest 9+25 bit fixed point number in binary that is less than or  
equal to  15.999 and the binary number that greater than or equal to  
16.034?  what  value of res would see as being used? The question I  
want to get to here is if your statement is correct that the smallest  
range we are going to end up with a 32 degree range. Alternatively we  
could work with the example (which I have not personally checked but  
just copied out of binary lci)

              binary                    decimal

Which gets to a 27 bits of resolution.

Thoughts?

Cullen <in my roll of a individual contributor trying to understand>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 26 Feb 2008 22:52:22 -0600

Hi Cullen,

Technically there is no 9+25 fixed point number in binary that is both
less than or equal to 15.999 and greater than or equal to 16.034. But
I'm just being pedantic.

In the spirit of your question, however, the way 3825 is written you'd
use a resolution of 4 to cover this range - that's if you accept that
the purpose of 3825 is to allow ranges to be communicated in the first
place. So that's zero to 32 degrees. I've already said this.

In the example given in binary-lci, if you coded as 3825 describes,
you'd actually set the resolution to 3. That is zero to 64 degrees.

As the example in binary-lci is written, it uses precision (that is, I
don't consider that it does follow the 3825 specification - and it's not
consistent with the example that is in 3825). In order to get the
resolution value in the binary-lci example (i.e. 27), 3825 would have to
have said that the location is the value of the significant digits plus
or minus half the maximum value of the remaining insignificant digits.
It does not say that.

It doesn't really matter though. You can take the literal interpretation
of 3825 (the range is the value of the significant digits with the non
significant digits being anything from all zeroes to all ones) or you
take the modified interpretation implied in the binary-lci example (the
intended value is plus or minus half the value of the non-significant
digits if they are all set to one).

Either way you get a system of representing areas that only has 34
possible values for the size of the area.

There is no practical use for a system that only has 34 different sizes
to communicate. There are an infinite number of areas (even just
rectangular ones) that cannot be communicated using DHCP. Since users of
DHCP cannot communicate the area that they want to, the recipient of the
DHCP encoding should not interpret what they receive as intending to be
an area. They can only interpret it as a point; what they do with the
resolution is up to them - I don't know how it's useful.

Using a concrete example - if the DHCP administrator gets a GPS fix of
particular resolution which is the center of the inside of the building,
they can put that value - presumably with the resolution value set
accordingly - into the DHCP server. That means every device in that
building gets this same point; a quite valid implementation. Now -
should the recipients interpret what they receive as an area of
uncertainty or as a point? In this case, it's certainly not the area of
uncertainty because that would be the whole building. They can't know
what the administrator intended and resolution doesn't have the
expressive power to make it clear. Given there's only 34 values to
choose from it's very unlikely the administrator could find a "range"
that practically represents the boundaries of the building. In any case,
the recipient has no way of knowing what the intent was. The only
sensible interpretation is that it's a point with no intention of
conveying uncertainty - or a particular area in any sense. The area
bounded by the insignificant digits (whether you use strict 3825 or the
modified binary-lci interpretation) conveys nothing in particular to the
recipient.

Now, if we are talking about taking a DHCP communicated location and
encoding it using the pidf-lo-profile specification, we absolutely
should not use the rectangular representation. This, very specifically,
conveys an area of uncertainty. The DHCP location should only be encoded
as a GML point. If somebody wants to define a GML point encoding that
also has "resolution" then they can - I don't know how it would be
useful.

Summary:
1 3825 should be fixed so that it doesn't indicate an intent to
communicate 
  areas
2 A location received from DHCP should not be encoded as a GML area.
3 A location received from DHCP should only be encoded as a GML point.
4 Maybe somebody wants to add a GML point with resolution encoding that
  could be used as well. Don't look at me.

Cheers,
Martin

-----Original Message-----
From: Cullen Jennings [mailto:[email-masked]] 
Sent: Wednesday, 27 February 2008 3:31 AM
To: Dawson, Martin
Cc: Richard Barnes; GEOPRIV
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

              binary                    decimal

Thoughts?

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 29 Feb 2008 14:00:31 -0800

Thank you for taking the time on this - I am getting closer to at  
least understanding what parts we agree and disagree on.

> or minus half the maximum value of the remaining insignificant digits.

Ok, here I don't see what in 3825 would make you think you would need  
to use 3 instead of 27. I 'm really am trying to make every effort  
here to understand your argument on this and glad to have it explained  
to me.

> possible values for the size of the area.

Agree. (Actually it is closer to 34^2 as it is 34 in lat and 34 in lon  
but I know what you mean)

> to communicate.

My vague recollection is that this statement is not the consensus of  
the WG when then decided to publish 3825. I seem to recall people  
agree that this corse resolution would be adequate for many  
applications. Now, I can see if the res for the 15.999 example was a  
value of 4 instead of something closer to a value of 27, then this  
would not meet the needs of many applications. However reading the RFC  
I do not get this out of it.

> There are an infinite number of areas (even just
> rectangular ones) that cannot be communicated using DHCP.

Agree

> Since users of
> an area.

Hmm, Given the conversation we just had about how it represents the  
roughly rectangular rectangular region with the sides each being one  
of 34 different possible sizes, I have a very hard time understanding  
how you could come to this conclusion.

> They can only interpret it as a point; what they do with the

Let me expand this example a little - it is a good one.

> accordingly - into the DHCP server.

Let's assume they also know the size of and orientation of the  
building and know that DHCP server only serves wired clients are  
inside the building. Using this they compute the min/max lat lon for  
the any point in the building then find a value of res for lat and lon  
that forms an area that fully covers the building.

> That means every device in that
> that practically represents the boundaries of the building.

As the 34 values go up in powers of two, it seems the admin will find  
a "range" that is less than 4 times the actual span of the building in  
lat or lon. I totally understand this does not put a precise boundary  
around the building but it does provide an area that is roughly within  
a order of magnitude of the smallest polygon that would cover the  
building.

> In any case,
> the recipient has no way of knowing what the intent was.

The intent is to say that the location of the device is probably  
within the roughly rectangular range specified.

> The only
> conveying uncertainty - or a particular area in any sense.

Again, I can't see how you reach this conclusion. If you care to  
enlighten me I am listening with an open mind.

> The area

Given we just had a long thread about what ranges it can represent. It  
seems we both agree that it can represent 34 different ranges in lat  
and 34 in lon. This specified a roughly rectangular region where that  
bounds where the device is probably located.

> also has "resolution" then they can - I don't know how it would be

If I knew a device had a location where I had a 95% probability that  
the location of the device was somewhere with a lat between 49N and  
54.40N and lon between 122.756553W and 113.899555W, how would we  
represent this in GML? Actually, I see this is much the same question  
Robert asked so I will drop it here and we can pursue it on the other  
thread.

>  could be used as well. Don't look at me.

Cullen <with my individual contributor hat on>[

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