On Sep 8, 2006, at 9:09 PM, Winterbottom, James wrote:
>
> In all the examples used in RFC-3825 in the appendix, the way
> resolution
> is used is to express a range in the latitude, longitude and altitude.
> This expresses an area or volume, there is no other way to interpret
> this. I am past believing that you can't see this.
These illustrations are in an appendix to indicate that they are not
normative. The point of the appendix is to show what size regions
different resolutions imply, including deliberately partially hiding
location by lowering resolution. This does not change the fact that
the resolution is SPECIFIED as "number of valid bits in the fixed-point
value". As we have explained before, this represents the normal
scientific/engineering concept of significant figures.
> I am not saying having a resolution parameter is not useful, just the
> way that RFC-3825 stipulates it be interpreted.
The way RFC 3825 specifies resolution is just what is necessary to
implement the principle of significant figures when using a
fixed-length binary number rather than a variable number (limited by
the measurement precision) of decimal digits.
> As for errors please read PIDF-LO profile, it is very clear there.
No, it is not. As explained in the dialog on the GeoPriv list some
time ago, the errors are in your interpretation of the illustration in
the appendix of RFC 3825. RFC 3825 does not specify arbitrary
geographic polygons, although you seem to insist it should. Your
invention of longest matching substrings of boundaries leads to the
errors you report. Please stop attributing your erroneous
interpretation to the different purpose of RFC 3825.
John
>> From: Marc Linsner
>>
>> We are obviously talking past each other. I used the aviation and
>> marine industries as examples of users of geo coordinates for their
>> respective navigation applications. I used that analogy because both
>> those applications commonly refer to fixed locations (e.g. airport
>> runways,
>> marine buoys/markers), the same non-mobile type entities served by
>> RFC3825
>> (the commonality being 'non-mobile, not the application). I can't
>> testify
>> whether these application implementations internally represent data in
>> binary, octal, decimal, etc. But I can attest that these applications
>> DO NOT express any kind of uncertainty association in addition to the
>>
>> location representations. My experience with these applications have
>> been with variable length fields, hence a separate resolution
>> parameter
>> has not been included.
>>
>> Resolution, whether expressed in binary, octal, decimal, etc. cannot
>> represent an arbitrary area/shape. Hence, RFC3825 cannot express an
>> arbitrary area/shape as it only includes resolution.
>>
>> Would you please expand your question concerning errors? What errors?
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 9 Sep 2006 10:50:46 -0400
This archive was generated by hypermail 2.1.8 : Sat Sep 09 2006 - 11:09:34 EDT