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

["Dawson, Martin" <[e-mail]>]

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:[e-mail]] 
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


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
000011111.1111111111111111111001110  31.99999850
000100000.0000000000000000001011100  32.00000274

001000000.0000000000000000000101010  64.00000124  sum
000100000.0000000000000000000010101  32.00000062  average
000000000.0000000000000000010001110  00.00000423  difference

Which gets to a 27 bits of resolution.

Thoughts?

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


On Feb 24, 2008, at 11:56 PM, Dawson, Martin wrote:

> 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
>
> -----Original Message-----
> From: Cullen Jennings [mailto:[e-mail]]
> Sent: Monday, 25 February 2008 5:15 PM
> To: Dawson, Martin
> Cc: Richard Barnes; GEOPRIV
> Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
>
>
> On Feb 24, 2008, at 5:53 PM, Dawson, Martin wrote:
> > 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.
> >
> 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
>
>
>
------------------------------------------------------------------------
------------------------
> 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]
>
>


------------------------------------------------------------------------------------------------
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
[e-mail]
http://www.ietf.org/mailman/listinfo/geopriv