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

[Cullen Jennings <[e-mail]>]

I think this thread may have been over taken by events at the last  
meeting. I have a much better understanding now that I did previously  
and thank you to everyone for that. I know Robert and Richard are  
working on figuring out how to move forward on this.

Cullen

On Mar 21, 2008, at 1:50 AM, Dawson, Martin wrote:

> Hi James,
>
> As far as I can tell your comments don't actually apply to anything I
> actually said.
>
> In any case - you could cut to the chase and answer Cullen's question.
> Given a range in latitude from 15.999 to 16.034 what should the
> corresponding value of Latitude and LaRes be - according to the rules
> defined in 3825? Write the actual encoding values - which have to
> binary... I'm assuming you'd agree.
>
> Cheers,
> Martin
>
> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]]
> Sent: Saturday, 1 March 2008 8:30 AM
> To: Dawson, Martin; Cullen Jennings
> Cc: GEOPRIV
> Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
>
> 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
>
>
> ------------------------------------------------------------------------------------------------
> 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]
https://www.ietf.org/mailman/listinfo/geopriv