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

Marc,

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.

I am not saying having a resolution parameter is not useful, just the
way that RFC-3825 stipulates it be interpreted.

As for errors please read PIDF-LO profile, it is very clear there.

Cheers
James

> -----Original Message-----
> From: Marc Linsner [mailto:mlinsner@cisco.com]
> Sent: Saturday, 9 September 2006 9:42 AM
> To: Winterbottom, James
> Cc: ecrit@ietf.org; geopriv@ietf.org
> Subject: RE: [Ecrit] Location information in emergency
> sessioninitiation,need for time and accuracy?
>
> James,
>
> 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?
>
> -Marc-
>
>
>
>
>
> > -----Original Message-----
> > From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
> > Sent: Friday, September 08, 2006 6:53 PM
> > To: Marc Linsner
> > Cc: ecrit@ietf.org; geopriv@ietf.org
> > Subject: RE: [Ecrit] Location information in emergency
> > sessioninitiation,need for time and accuracy?
> >
> > It is interesting that you point this out and I am certainly
> > no expert in aviation and marine location systems. I will
> > however point out that from what I have seen that searches at
> > sea and for downed aircraft often span many thousands of
> > square kilometres, I scarcely think that this would be
> > acceptable in a domestic wired or wireless phone emergency
situation.
> >
> > I would also point out that if you have used the same
> > encoding as is used in those industries it behoves you to
> > have put them in the references section of the RFC, and to
> > have indicated that the encoding scheme came from the there
> > in the text somewhere, I certainly couldn't find any.
> >
> > Now back to my initial series of questions:
> >
> > Point or Polygon, single answer please.
> > How do you intend to address the concern regarding errors.
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > > Sent: Saturday, 9 September 2006 8:29 AM
> > > To: Winterbottom, James
> > > Cc: ecrit@ietf.org; geopriv@ietf.org
> > > Subject: RE: [Ecrit] Location information in emergency
> > > sessioninitiation,need for time and accuracy?
> > >
> > >
> > > >
> > > > Marc,
> > > >
> > > > Perhaps the statement should have been, is not suitable for any
> > > > application that require a deterministic degree of accuracy,
> > > > something to that effect.
> > > > I am quite sure that in some circumstances that the
> > encoding scheme
> > > > is fine, but I wouldn't want to be my life on it in an
emergency,
> > > > would you?
> > >
> > > I suggest emergency responders would have no problem
> > finding locations
> > > described by RFC3825, it's the same data expressions used
> > by aviation
> > and
> > > marine everyday. So, unless you travel exclusively by rail,
you've
> > > probably already placed you life in the hands of such data
> > > representation, I
> > know I
> > > have.
> > >
> > > -Marc-
> >
> > --------------------------------------------------------------
> > ----------------------------------
> > 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://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 8 Sep 2006 20:09:41 -0500