Subject: RE: [Geopriv] LCI and Uncertainty Representation

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 4 Apr 2006 19:01:03 -0500

Are you suggesting that there are two possible interpretations for 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.

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?

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.

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.

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Monday, 3 April 2006 4:44 PM
> To: Thomson, Martin
> Cc: [email-masked]
> Subject: Re: [Geopriv] LCI and Uncertainty Representation
> 
> 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.
> >>

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

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

---

From: John Schnizlein <[email-masked]>
Date: Wed, 5 Apr 2006 11:52:29 -0400

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.

>   not be considered valid and might be purposely false, or zeroed by

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.