[Geopriv] 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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 8 Sep 2006 19:41:55 -0400