Subject: Re: [Geopriv] I-D ACTION:draft-schnizlein-geopriv-binary-lci-00.txt

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 1 Nov 2006 16:43:36 -0600

The position of this draft is unclear, it reads as informational, but
the changes it should be representing require it to be standards track.
I think the intent needs to be clarified. 

The abstract indicates that it describes the nature of the data
expressed in LCI, but it doesn't. It attempts to redefine what this data
represents, which is a fundamental shift from what is described in
RFC3825. The draft needs to state this clearly, and indicate that any
interpretation of location in RFC3825 is replaced by what is provided in
this document.

The draft doesn't adequately describe why the interpretation of the
representation in RFC3825 is inadequate. It needs to. In fact it needs
to take appendix A from the PIDF-LO profile draft and include that as a
core section. The problem needs to be clearly explained in the draft
before an alternative interpretation can be suggested. This doesn't
happen.

Their still seems to be a lack of understand on the relationship between
error, resolution, uncertainty and area. If you are expressing a
resolution, you are defining an error, an error defines an area of
uncertainty. This is fact, and has been clearly stated by the GeoPriv
resident OGC member Carl Reed. Consequently if you are expressing a
point only, there is no error, and the resolution bits are totally
irrelevant. All data is expressed to the maximum precision that can be
contained in the bits available. This lack of understanding is clearly
iterated in section 6, where it is suggested that error be encoded into
the resolution value.

A better solution would be to use the truncation technique that John S
described in an email on the 28th of March this year. This technique
would allow the error to be expressed as a +- uncertainty in the actual
value being provided. This has several key advantages. Firstly you can
express areas without the significant error creep that can occur
arbitrarily in the RFC-3825 specification. Secondly you don't have to
throw away the fact that there is error, which is what is currently
expressed in this new document.

I don't see any advantage being provided by the code fragment, and there
are errors in the struct definition, so I suggest dropping this all
together.

Finally, this document indicates that the location is to be used in a
PIDF-LO, yet there is no example showing what the resultant PIDF-LO
would look like. I think that this too would provide significant
benefit. If the resolution parameter interpretation were to be changed
as suggested above, then such an example is of paramount importance to
clearly illustrate what information is being represented and how it is
to be interpreted. 

All in all I think that this document is inadequate in its current form
to be adopted as a WG item, and its intent is unclear. When the concerns
above are addressed in the document then I would be happy to support its
progression to a WG item. 

Regards
James 
------------------------------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: John Schnizlein <[email-masked]>
Date: Fri, 3 Nov 2006 10:16:27 -0500

> I think the intent needs to be clarified.

The intent is as you read it: informational.  It clarifies 
interpretation of RFC 3825.

>  ... Consequently if you are expressing a
> contained in the bits available. ...

> value being provided. ...

While I appreciate the acknowledgment here that a point has an error of 
measurement, I never intended to advocate including a expression of the 
size of the error of measurement other than the resolution.

> are errors in the struct definition, so I suggest dropping this all

What errors do you see?  I would be glad to fix any identified error 
and test the code fragments if the WG adopts this as a valuable effort.

John

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 6 Nov 2006 19:00:25 -0600

John,

I think that this is dancing around the issue.  The interpretation of the data, as documented in RFC3825 (informative, normative, or whatever) is different to that described in this document.  That's an update, and a standards track document.

As for errors, all I can see is a scarcity of semi-colons and a few extra spaces here and there.  While all the code looks like a cut and paste from someone's code, it certainly wouldn't compile.

I think that the premise this document is helpful - it is not clear enough how to interpret the RFC 3825 encoding.

As James points out, an example of conversion to and from PIDF-LO would be nice; even if this is just because PIDF-LO would be an unambiguous form.  And while you are changing the interpretation of the binary form, you could take the opportunity to change the area given from a rectangular prism to an ellipsoid if you so desired.

I don't think that the conversion of resolution bits to resolution decimal digits helps (except perhaps, in some obtuse way, to support your existing fallacious argument about there being a difference between resolution and uncertainty).

Incidentally, the method you describe for calculating the error is a little convoluted.  I would just take the error (err) and work out the error directly based on a spherical approximation, rather than working out the two side values.  Of course, a real life implementation could be more precise and convert all the values to Cartesian coordinates, but I don't think that this would be necessary for this document.

Cheers,
Martin

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]]
> Sent: Saturday, 4 November 2006 2:16 AM
> To: Winterbottom, James
> Cc: GEOPRIV
> Subject: Re: [Geopriv] I-D ACTION:draft-schnizlein-geopriv-binary-lci-
> 00.txt
> 
>