[Geopriv] RE: [Ecrit] Location information in emergency sessioninitiation, need for time and accuracy?

John,

Please!
Normal scientific measurements will say +- half the smallest unit. This
will place a point in the middle somewhere, and you yourself at the very
start of this debate came back with a proposal saying that.

The fact of the matter is that you are starting in the normative section
of the draft that the resolutions parameters place you with in an area.
If this is what is meant, then I am sorry to say that this but the
PIDF-LO draft is correct and you are plain wrong!

James Polk has stated more than once now that the shape defined in
RFC-3825 is a linear ring polygon. If this is the case then the
calculation in PIDF-LO profile also stand.

Quite frankly what is it that RFC-3825 represents. This part of previous
question you have tactfully ignored.

So I am going to ask you. Point, or area?
If Point, then a clarification draft stipulating this is required.
If an area, then please provide a detailed explanation of how would
re-describe the examples in PIDF-LO profile with references to the
sections RFC-3825 that eliminate the inherent errors.

I am tired of you saying that this is wrong, when it clearly follows
your specification, and you do not provide through the same example
where it is wrong, or provide a reasonable alternative.

BR
James

> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]
> Sent: Sunday, 10 September 2006 12:51 AM
> To: Winterbottom, James
> Cc: geopriv@ietf.org; Marc Linsner; ecrit@ietf.org
> Subject: Re: [Ecrit] Location information in emergency
sessioninitiation,
> need for time and accuracy?
>
>
> 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?

------------------------------------------------------------------------------------------------
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://www1.ietf.org/mailman/listinfo/geopriv
Received on Sat, 9 Sep 2006 17:11:07 -0500