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

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

Hi Cullen,

It does depend on why A & B are being written to begin with, but a correct way to write two such contextual statements would be:

A) 3825 provides a way to explicitly state the number of binary digits that should be considered significant in a 34 bit fixed point representation of each of the latitude and longitude values associated with a point.

B) The pidf-lo profile specification does not include an equivalent GML encoding for a point that explicitly indicates the number of significant digits for each of the latitude and longitude values of that point.

Presumably the follow on question is whether we should add this GMLC encoding. It's not something I'm for or against; I guess the main use would be as vehicle to not lose the explicit significant digit information from a 3825 packet.

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.

The recipient gets a value which they interpret as anything from zero to 31.9999999 recurring (I call it 32 for convenience).

> I think your phrase "bounding area" confuses the issue. If we say a  
> rectangle R that is collinear with the equator bounds the polygon P,  
> we could mean a few things. One would be the smallest rectangle such  
> that P was inside R. Another meaning would be any R where P was  
> inside. I believe the correct term for the first is "minimum bounding"  
> while the second is just "bounding". The DHCP stuff can do the  
> bounding but not the minimum bounding.

Terminology is certainly problematic - and there's been no end of semantic gymnastics in the discussion. However, it's definitely true that the minimum bounding area that DHCP can communicate in the above example is zero to 32 degrees.

BTW, the example in the lci-binary draft uses a target that straddles 32 degrees (it's 31.99999850 to 32.00000274). The actual minimum bounding that can be used to enclose this target is zero to 64 degrees. The example text has a lot of machinations around determining an error value associated with the target but then doesn't follow through with conclusions about how it applies in the final 3825 encoding. The example actually implies that the final encoding should be 000100000.0000000000000000000010101  32.00000062 with Res set to 27; i.e. the last .... 0010101 part has no significance. Well, since 27 bits of resolution means that it's the first 27 bits that are significant, and as I said to John S, this results in the following interpretation for the recipient of the encoding:

000100000.0000000000000000000XXXX

That is:

000100000.00000000000000000000000 recurring

To

000100000.00000000000000000001111 recurring

or 32.00000000 to 32.0000038

So the result is a range that has the lower value inside the original range and an upper value which is outside the original range that was the subject of the example. I think this was a mistake. It certainly ends up with a smaller range than the 64 degrees that can actually be communicated and still bounds the range but at the expense of being wrong and conveying the wrong information.

Cheers,
Martin


-----Original Message-----
From: Cullen Jennings [mailto:[e-mail]] 
Sent: Monday, 25 February 2008 10:14 AM
To: Dawson, Martin
Cc: Richard Barnes; GEOPRIV
Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci


So I certainly agree with you that the significant digits end up  
expressing a rectangle, and not that any rectangle can be expressed  
with significant digits. How would you phrase (A) so that it did not  
add to confusion in this sort of way?

More inline

On Feb 23, 2008, at 11:33 PM, Dawson, Martin wrote:

> Hi Cullen,
>
> Your description of (A) reflects the kind of misunderstanding that  
> 3825 (and lci-binary) causes.
>
> You can't take a "rectangular shape where the location of the thing  
> in question is" and express it with significant digits.
>
> Yes - you can take a point expressed with a limited resolution and  
> see what rectangular area it ends up looking like - but you can't go  
> the other way. This should be fairly obvious - with only 34 possible  
> values of resolution, there are only 34 possible "regions" you can  
> describe with these resolution break points for each of lat or lon.
agreed - I did not mean to imply otherwise.

> Further, which bit becomes the least significant one is driven by  
> *where the region is* and not how precisely it could actually be  
> determined.
>
> Consider an area of uncertainty between 15.999 and 16.034 latitude.  
> In the binary form, the largest number of 3825 significant digits  
> that don't preclude at least part of this region is 4 - and the Lat  
> value is 0000xxxxx.xxxxxxxxxx... - i.e. the location is between zero  
> and 32 degrees and to cover this area of uncertainty the Lat value  
> must be sent as zero and LaRes set to 4. Needless to say, 0-32  
> degrees is a wholly inadequate representation of 15.999 to 16.034  
> degrees. Now - I had to do this because of *where* the actual region  
> was located and not because of how accurately or with what  
> confidence I could determine it.

So given we know we are in the 15.999 to 16.034 range, I totally agree  
that if the best representation we could provide of this in DHCP had a  
range of 32 degrees, that would not be acceptable. I think this topic  
here is hugely important to if we need to do something to 3825 or not  
and I would very much appreciate if you could walk me though this in  
as a detailed example. I know you have said this many times in the  
past but I have never been able to work thought the whole example.

Could you walk this example thought how it would convert into the  
smallest region that we can represent in the binary-lci form that  
still totally covers the above range then convert that back out from  
binary to normal latitudes. If we end up with a range that 32 degrees,  
I agree it is broken but I'd love to see the example worked through.  
Thank you in advance.

>
>
> The shapes that the pidf-lo profile define allow areas of  
> uncertainty with arbitrary size and location to be described and  
> exactly with the accuracy to which they could be determined -  
> something resolution on its own simply can't do.

agree

> I think the only pertinent question from the GML perspective is  
> whether we also want to add a "point with resolution" encoding -  
> which would have the same characteristics as the 3825 codec. I don't  
> have an objection to creating this new type but I also haven't found  
> out why it is useful either.

Again I think we mostly agree. I agree it would be easy to do. I'm not  
particularly for or against the idea but I would want to know why it  
was useful to have it. In general I find lots of options no one needs  
never help interoperability.

>
>
> Your précis sounded like the only difference between A & B is how  
> the DHCP RFC and GML go about representing the same thing. That is  
> incorrect - the latter is capable of representing something that the  
> former is not. 3825 and binary-lci should not state or imply that  
> the RFC can be used to encode bounding areas.

I think your phrase "bounding area" confuses the issue. If we say a  
rectangle R that is collinear with the equator bounds the polygon P,  
we could mean a few things. One would be the smallest rectangle such  
that P was inside R. Another meaning would be any R where P was  
inside. I believe the correct term for the first is "minimum bounding"  
while the second is just "bounding". The DHCP stuff can do the  
bounding but not the minimum bounding. But ignoring the terminology  
issue, we both are very clear on that DHCP can and can not do and back  
to my original question at the top, I'd be happy if you could help me  
rephrase A so that it was widely understood by people that did not  
care about uncertainty, resolution, and error yet did not cause any of  
the type of confusion you are worried about here.

>
> Cheers,
> Martin

Cullen (in my individual contributor role)

>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On  
> Behalf Of Cullen Jennings
> Sent: Sunday, 24 February 2008 4:55 PM
> To: Richard Barnes
> Cc: 'GEOPRIV'
> Subject: Re: [Geopriv] Direction for draft-ietf-geopriv-binary-lci
>
>
> Having read this whole thread, what I got out of it was
>
> A) the DHCP drafts is capable of describing a roughly rectangular
> shape where the location of the thing in questions is probably inside
> this rectangle
>
> B) The way GEOPRIV uses GML to describe a roughly rectangular shape
> where the location of something is probably inside seems to be using a
> four vertex Polygon like the polygon in section 5.2.2. of draft-ietf-
> geopriv-pdif-lo-profile-11.
>
> Am I correct in my understanding of A and B?
>
>
> Cullen <with my individual contributor hat on>
>
>
> On Feb 12, 2008, at 8:04 AM, Richard Barnes wrote:
>
>> There has been some confusion recently about the relationship between
>> draft-ietf-geopriv-binary-lci and GML.  In particular, the binary-lci
>> draft specifies how the binary point+uncertainty format can be
>> converted
>> to a decimal point+uncertainty format, notionally so that it can be
>> used
>> in GML.  However, GML lacks a notion of precision, so including a
>> point
>> derived per binary-lci as a point in GML would discard the  
>> uncertainty
>> information.
>>
>> In order to clarify this so we can move this draft forward, I'd like
>> to
>> make a suggestion and pose a question:
>>
>> 1. A section should be added to binary-lci to describe how a
>> point+uncertainty should be expressed in GML.  This could be as a
>> rectangle (prism), as an ellipsoid, or something else (I'll leave  
>> this
>> to others to describe), but there needs to be a defined conversion
>> to GML.
>>
>> 2. Does anyone intend to use binary-lci for converting to a format
>> other
>> than GML?  If so, please describe the format and the use case for it.
>> If not, then perhaps binary-lci should be re-framed as a description
>> of
>> how to convert from the DHCP format to GML.
>>
>> Cheers,
>> --Richard
>>
>> _______________________________________________
>> Geopriv mailing list
>> [e-mail]
>> http://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> 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]
>


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