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

[Cullen Jennings <[e-mail]>]

Thank you for taking the time on this - I am getting closer to at  
least understanding what parts we agree and disagree on.

On Feb 26, 2008, at 8:52 PM, 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.
>
> 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.

Ok, here I don't see what in 3825 would make you think you would need  
to use 3 instead of 27. I 'm really am trying to make every effort  
here to understand your argument on this and glad to have it explained  
to me.

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

Agree. (Actually it is closer to 34^2 as it is 34 in lat and 34 in lon  
but I know what you mean)

>
>
> There is no practical use for a system that only has 34 different  
> sizes
> to communicate.

My vague recollection is that this statement is not the consensus of  
the WG when then decided to publish 3825. I seem to recall people  
agree that this corse resolution would be adequate for many  
applications. Now, I can see if the res for the 15.999 example was a  
value of 4 instead of something closer to a value of 27, then this  
would not meet the needs of many applications. However reading the RFC  
I do not get this out of it.

> There are an infinite number of areas (even just
> rectangular ones) that cannot be communicated using DHCP.

Agree

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

Hmm, Given the conversation we just had about how it represents the  
roughly rectangular rectangular region with the sides each being one  
of 34 different possible sizes, I have a very hard time understanding  
how you could come to this conclusion.

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

Let me expand this example a little - it is a good one.

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

Let's assume they also know the size of and orientation of the  
building and know that DHCP server only serves wired clients are  
inside the building. Using this they compute the min/max lat lon for  
the any point in the building then find a value of res for lat and lon  
that forms an area that fully covers the building.

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

As the 34 values go up in powers of two, it seems the admin will find  
a "range" that is less than 4 times the actual span of the building in  
lat or lon. I totally understand this does not put a precise boundary  
around the building but it does provide an area that is roughly within  
a order of magnitude of the smallest polygon that would cover the  
building.

> In any case,
> the recipient has no way of knowing what the intent was.

The intent is to say that the location of the device is probably  
within the roughly rectangular range specified.

> The only
> sensible interpretation is that it's a point with no intention of
> conveying uncertainty - or a particular area in any sense.

Again, I can't see how you reach this conclusion. If you care to  
enlighten me I am listening with an open mind.

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

Given we just had a long thread about what ranges it can represent. It  
seems we both agree that it can represent 34 different ranges in lat  
and 34 in lon. This specified a roughly rectangular region where that  
bounds where the device is probably located.

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

If I knew a device had a location where I had a 95% probability that  
the location of the device was somewhere with a lat between 49N and  
54.40N and lon between 122.756553W and 113.899555W, how would we  
represent this in GML? Actually, I see this is much the same question  
Robert asked so I will drop it here and we can pursue it on the other  
thread.

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

Cullen <with my individual contributor hat on>[

>
>
> -----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]
https://www.ietf.org/mailman/listinfo/geopriv