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

["James M. Polk" <[e-mail]>]

At 10:52 PM 2/26/2008, Dawson, Martin wrote:
>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.

huh?

You use at least a res of 9 to cover all possible integers, and it 
doesn't take a rocket scientist to figure that one out. If you want 
to cover the 0.999 remaining in your example, you count into the 25 
that represents a sub integer, and you have 10 to get you to 1024, 
then add 10 to 9 and that's 19, the last time I did math -- so your 
res length of 15.999 is 19. The 6 additional binary bits are 
not-trustable, and not to be considered in this location.

How doesn't the appendix NOT walk you through this (in its example)?

BTW - if you want exactly 15.9990000 as your location number, you use 
34 bits of res as your length. This is pretty exact.


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

you're completely missing the point if you say the decimal above 16 
is 32 'therefore that's how 3825 says that's how "off" you have to 
go'. The decimal above 16 is 17 -- which can be done in decimal and 
binary. The one below 16 is 15 -- which can be done in decimal and 
binary. How hard is that to figure out?

>I've already said this.

and you were wrong then too, just like you're wrong now and every 
time you say this in the future.


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

huh?

to get to "0" degrees, which England does have, you need to set the 
length res to at least 9, because that covers all the integers from 0-180.

The rest of this I'll ignore until this basic understanding is achieved


>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

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