Subject: Re: [Geopriv] LCI and Uncertainty Representation

From: John Schnizlein <[email-masked]>
Date: Mon, 3 Apr 2006 02:44:04 -0400

It appears that my acceptance of the error attributed to RFC 3825 was 
hasty.  RFC 3825 does not require truncation of the location values 
based on the resolution.  As described, the size of a bounding box is 
determined correctly by the truncation operations in the Appendix.  The 
center of the bounding box in these examples is not the same as the 
full-resolution value because truncation fixes the edges of the 
bounding box to powers of two.  If one instead desired edges of the 
bounding box not fixed to powers of two, the center of the bounding box 
can be fixed at the full resolution, using the calculation in my 3/28 
email.  In my haste, I forgot that we (intentionally) did not preclude 
different interpretations of the bounding box implied by resolution, 
and that it is possible to position the box so it is centered on an 
intended location.  The point correctly made in RFC 3825 is that the 
resolution implies only that the point is somewhere in the box.

The method in Martin's 3/27 email for calculating precision from the 
edges of a bounding box is neither valid nor in RFC 3825 (even by 
implication).  A reasonable way to compute resolution would be to count 
the leading zeros in the difference between the higher and lower 
bounds.  This appears obvious enough to me that it does not call for a 
revision of RFC 3825.

John

On Mar 28, 2006, at 10:01 AM, Thomson, Martin wrote:

> That looks correct John.  So how would you propose to fix it?  3825bis?
>
> If you revise 3825, perhaps the new version should include some 
> guidance on how to do a conversion from a known uncertainty into the 
> 3825 form.
>
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Tue 3/28/2006 10:32 PM
>>
>> Yes, the truncation calculation of the resolution shown in RFC 3825 is
>> an error.  As you indicate, truncation of the value leads to large
>> errors where resolution is better than the difference of the value 
>> from
>> the nearest power of 2.
>>
>> The correct method to find the upper and lower bounds (respectively)
>> from resolution is to add and subtract
>>   (2 ^ (34 - resolution) - 1) * 2 ^ -25 from the value at the center 
>> of
>> the region.
>>
>> It is not the encoding of location with binary-precision that is 
>> wrong,
>> but the application of truncation.  This should be fixed.
>>
>> John
>>
>> On Mar 27, 2006, at 11:58 PM, Thomson, Martin wrote:
>>>
>>> The weakness of this encoding is most clearly demonstrated at whole
>>> numbers of degrees, particularly powers of two.  Take the range from
>>> 31.9999985° to 32.00000274°, which is a mere 0.5 metre range about 32
>>> degrees.  This results in the following binary values:
>>>     000011111.1111111111111111111001110 to
>>>     000100000.0000000000000000001011100
>>>     ^^^
>>> You'll note that there are only three bits that are common to both.
>>> This results in an encoding that represents a range from 0 to 64
>>> degrees, or a 3,500 kilometre distance!  If this encoding was
>>> converted to a PIDF-LO following the guidelines in RFC 3825, this
>>> information would be effectively useless.
>>

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 5 Apr 2006 18:28:46 -0500

There is no difference between saying "...you cannot make valid distinctions with more precision than specified..." and uncertainty.  You cannot claim that resolution in LCI is talking about significant digits and is therefore not uncertainty.

Since you talk about significant figures, let's use some examples of measurements:
  - 3.14159
  - 5.01331e7 +/- 3.2e3

The first implies a range from 3.141585 to 3.141595, the second a range from 5.01299e7 to 5.01363e7.  Both indicate that the measurement was imprecise, but there is a significant confidence that the actual value falls somewhere in those ranges.

You cannot assume that the actual value is in the middle of that range, but you definitely have boundaries.

What I am looking for is a definitive way to interpret the values in LCI to determine these boundaries.  How LCI is interpreted determines the way that it is constructed.

The appendix of RFC 3825 is quite clear in how it is interpreted; therefore, I believe that my method for encoding is also valid based on that interpretation.  For uncertainty that means that I want to ensure that the output range is a superset of the input range.  The method I used does that, at the sacrifice of precision.

The method you suggest is dependent on a different interpretation that might be valid by the normative text; however, the appendix is very clear in establishing how the value is interpreted.  I expect that implementations will follow the interpretation shown in the appendix.

That leads back to the original conclusion: unless the RFC is amended, LCI resolution/uncertainty is not useful.

> -----Original Message-----
> Sent: Thursday, 6 April 2006 1:52 AM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Geopriv] LCI and Uncertainty Representation
> 
> The "problem" may stem from the attempt to use LCI resolution to
> specify particular bounds rather than a single point with some
> resolution as intended.  LCI not intended to specify arbitrary
> boundaries.  Multiple points would be needed for arbitrary boundaries.
> 
> On Apr 4, 2006, at 8:01 PM, Thomson, Martin wrote:
> 
> > Are you suggesting that there are two possible interpretations for
> > resolution?
> 
> No, there are not two interpretations of resolution; there are as many
> as there are values of all the bits beyond the one specified by the
> resolution.  The purpose of resolution is to specify that you cannot
> make valid distinctions with more precision than specified by the
> resolution.
> 
> > The interpretation that I described is very clear in RFC 3825, with a
> > great number of examples to back it up; the +/- interpretation that
> > you suggested in your 3/28 email is completely new and certainly not
> > implied.
> 
> My attempt was to accommodate a bounding box that spanned an edge of
> longitude or latitude that was a power of two.  The example of most
> concern in your long email was where the location was near a
> power-of-two boundary, and a bounding box computed by truncation would
> be off to one side rather than centered on the point.  Both the
> truncation and +/- interpretations of resolution maintain the
> constraint that the point of the location is within a bounding box of
> the specified size.
> 
> > If I receive LCI, how am I supposed to determine which of these two
> > interpretations to apply?  Or should I assume the worst of both?
> 
> You should assume the worst of not just both, but all possible values
> within the size of the bounding box.
> 
> > In any case - I would contend that your new interpretation is not
> > valid based on the text of RFC 3825:
> >
> >   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.
> 
> I did not claim that my new interpretation was derived from the text of
> RFC 3825.  I was trying to aid understanding by acknowledging that the
> truncation method shown in RFC 3825 was not the only way to interpret
> resolution.
> 
> Let me try again to explain:  Location cannot be known with infinite
> precision.  The normal expression of this in scientific writing is to
> represent measurements with only as many "significant digits" as the
> measurement process justifies.  The equivalent method with binary
> numbers is the number of "significant bits", which we call resolution.
> This can be visualized as the width of the pencil marking a point on a
> map.
> 
> > Therefore, as a receiver of this information, I must assume that those
> > invalid bits could be anything as I showed.  This interpretation is
> > borne out by the appendix; it is this interpretation that manifests
> > the problem.
> 
> The method of determining resolution from the number of common leading
> bits in the bounding values is not valid or implied by RFC 3825.  If
> the point of location were between
>      000100000.0000000000000000001011100  and
>      000011111.1111111111111111111001110
> the difference would be
>      000100000.0000000000000000000001110
          ?
> and the resolution would be 30 bits, not 3 bits.

       000000000.0000000000000000010001110

I count 26.

That aside, the operation of conversion should be reversible, within the limits of the precision available.  Your suggestion isn't.

> >>>> [mf2]

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