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

Hi Cullen,

I think there are only two general points to respond to.

With respect to the first point:
> 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.

Here is the text from the RFC:

           2.1.  Elements of the Location Configuration Information

             Code 123:  The code for this DHCP option.
             16:        The length of this option is 16 bytes.
             LaRes:     Latitude resolution.  6 bits indicating the
number 
                        of valid bits in the fixed-point value of
Latitude.
                        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.

             LaRes does not define Geographic Privacy policy.
             Values above decimal 34 are undefined and reserved.

             Latitude:  a 34 bit fixed point value consisting of 9 bits
of
                        integer and 25 bits of fraction.  Latitude
SHOULD be
                        normalized to within +/- 90 degrees.  Positive
                        numbers are north of the equator and negative
                        numbers are south of the equator.

                        A value of 2 in the LaRes field indicates a
                        precision of no greater than 1/6th that of the
globe
                        (in the first example of the appendix).
                        A value of 34 in the LaRes field indicates a
                        precision of about 3.11 mm in Latitude at the
                        equator.

The definition of LaRes says to me that any bits further right than this
value could have any value. I don't see anything that describes a
potential range for interpreting the bits to the left of this value and,
in particular, don't see anything saying that the value of latitude is
to be interpreted as +/- half the maximum possible value of the bits
further right than LaRes.

If this was the intent, it did a terrible job of defining it - but
presumably the intent is to let the example speak for itself - since
it's referenced from the definition.

So - if I go to the example, the value in the latitude field is given
as:

000101001.1110000011111011101010001 (I've added the decimal point
myself) or +41.87884 degrees.

The very first example of interpreting LaRes is 2:

   If: LaRes is expressed as value 2 (0x02 or 000010) ... then it would
   describe a geo-location region that is north of the equator

So - according to this - a value of 2 indicates the Northern hemisphere.
If the intent were per your interpretation, then it would indicate
something like 64 degrees either side of the equator.

The next example looks at LaRes being 3:

   If: LaRes is expressed as value 3 (0x03 or 000011) ... then it would
   describe a geo-location area that is north from the equator to 63
degrees
   north,

I don't know why it says 63 - I would have expected 64 (or 63.999
recurring) but, nevertheless, if the intent were per your interpretation
it would have said 32 degrees either side of the equator.

The next example actually starts somewhere other than the equator (i.e.
it doesn't interpret Latitude as just zero).

   If: LaRes is expressed as value 5 (0x05 or 000101) ... then it would
   describe a geo-location area that is latitude 32 north of the equator

   to latitude 48

Again, as you can see, the minimum value is 32, the actual value of the
digits to the left according to LaRes. If the intent were per your
interpretation, it would have said 32 degrees plus or minus 8 degrees.

The rest of the example is consistent and I won't labour the point. I
don't see how the interpretation can be anything other than significant
digits and not plus/minus precision.

With respect to the second point:
> The intent is to say that the location of the device is probably  
> within the roughly rectangular range specified.

Your point here appears to be that it's well understood that this is the
intent and I really have to differ. Leaving aside the question of
whether 34 possible lateral dimensions are a sufficient basis for a
useful uncertainty reporting scheme (I don't they are) and leaving aside
the question of just how the recipient is supposed to interpret LaRes
(significant digits or plus-minus precision), it has not been at all
clear or consistent that this is the intent.

For example, Marc has mentioned a number of times that the intent is
only to convey a point and the resolution to which that point is
measured. If this isn't the case - if the intent really is to
communicate a specific area - then the administrator in my example below
*should not* do what I described. He can't just use GPS to measure the
point in the centre of the building and populate Latitude and LaRes with
the value and resolution reported by the GPS unit.

If the administrator did that, and the resolution was a small number
equivalent to a couple of metres, then the recipient would have to
assume that the intent was to inform them that the target actually is
within those couple of metres (normal to the "confidence" discussion
which is a separate one and common to all schemes).

There cannot be any ambiguity - either the intent is a point with some
additional data indicating the precision to which that point was
measured or it's actually a specific area - which actually means the
location of the extents would have been independently and more precisely
measured.

My impression to date has been very much that the intent was a point
with precision. However, perhaps you're correct and the intent was
always a specific boundary of uncertainty. So, this only modifies my
view of the required steps to the following extent:

If the intent is that 3825 communicates a point (with resolution) then
the corresponding GML encoding needs to be just a point (with optional
extensions for resolution). If the intent is a rectangle, then there is
an existing GML encoding for this; there's no need to try and include
resolution in this encoding because the interpretation of the extents of
the rectangle have to be to arbitrary precision and, in fact, the only
purpose of the resolution parameters in 3825 was to indicate what the
value of these area extents actually are.

Either way 3825 needs an overhaul to clarify and make normative these
interpretations. The lci-binary draft does not clarify and, while being
too vague to make a definitive judgement, appears to contradict 3825. My
personal view: 3825 is fine for communicating a point (with resolution -
whatever the use is); it's a really poor scheme for communicating
specific areas of uncertainty.

Cheers,
Martin

-----Original Message-----
From: Cullen Jennings [mailto:fluffy@cisco.com] 
Sent: Saturday, 1 March 2008 9:01 AM
To: Dawson, Martin
Cc: GEOPRIV
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci

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:fluffy@cisco.com]
> 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:fluffy@cisco.com]
>> 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]
>

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