|
Marc B We would state that derived locations MUST
NOT be sent in an emergency call. I could imagine sending derived
locations within an ESInet, although I would discourage that. Brian From:
geopriv-bounces at ietf.org [mailto:geopriv-bounces at ietf.org] On Behalf Of Marc Berryman James, Existing NENA Standards state that
when geodetic is available it will be delivered. I think it is preferred that a
pointer provide the derived location and to always deliver the geodetic
location in the PIDF-LO, either LbV or LbR. Marc B -----Original Message----- Thanks Marc, that is what the draft
does. It also gives you the option of not
transporting the geodetic location, but provides a pointer to where it can be
obtained to address the size issue that the other James is talking about. Cheers James -----Original Message----- From: Sent: Tue 7/29/2008 8:56 AM To: Hannes Tschofenig Cc: Winterbottom, James;
geopriv at ietf.org; ecrit at ietf.org Subject: RE: [Geopriv] Announce:
Specifying Derived Location in a PIDF-LO As long as it clearly noted that the
location is derived from geodetic then I am fine. How to indicate?
Provide both geodetic and derived. If geodetic is provided then one can
safely assume the provided civic is derived (I would hope). Marc B -----Original Message----- From: Hannes Tschofenig
[mailto:Hannes.Tschofenig at gmx.net] Sent: Tuesday, July 29, 2008 8:14 AM To: Cc: Winterbottom, James;
geopriv at ietf.org; ecrit at ietf.org Subject: Re: [Geopriv] Announce:
Specifying Derived Location in a PIDF-LO Hi Marc, I agree with you that re-coding
isn't the ideal solution. Now, the question is: What do we do
when someone still does it? We are not the deployment police. Should we indicate the fact that
re-coding has happened? How should we indicate it? Ciao Hannes > > I see very real issues with
deriving a civic location from a geodetic > location, when wireless
geodetic locations became widely available > this "reverse
geocoding" caused many problems. Personally I see no > value but many issues that can
come about from a derived civic location. > > I will try to expand on these issues
(while not being able to draw > pictures to illustrate) from a
"Lessons Learned" aspect. > > 1.) Geodetic location comes in
and a civic location is derived from > the nearest know civic
location, but the geodetic location is centered > on a building in a large campus
or a large apartment building. The > nearest civic location is the
entrance to the large campus or > apartment complex, so you have
lost desirable information of the more > precise location in favor of
the civic location given to the campus or > apartment building. > > 2.) Same scenario as above, but
this time the nearest civic location > is NOT the same as the civic
location provided to the apartment > complex or campus. The nearest
civic location is provided and a > delayed response is caused by
providing the incorrect civic location. > > 3.) A geodetic location come in
from a boat in the lake, river, or > bay. The derived civic location
is a home on the lake, river, or bay. > Delayed response due to
incorrect location being provided. > > 4.) Vehicle on interstate
highway (limited access highway) provides > geodetic location, derived
civic location is along the highway but a > delayed response takes place
because not only is the civic location > derived incorrect but the responding
agency has to drive miles to gain > access to the limited access
highway when the correct responding > agency is near the access point
of the limited access highway. > > I could and can go on and on on
scenarios that can (and have) occurred > due to derived locations, but
let me put forth another consideration. > > The service providing the
derived location is using a spatial dataset, > but it is not being maintained
to the same level as the spatial data > being used at the PSAP, out of
date information is passed to the PSAP > - LIBALITY ISSUE. We update our
spatial data on a minute by minute > basis, with literaily hundreds
of changes taking place each day. There > are just so many little
differences that could exist between the > derived location and the actual
location provided by a trained call > taker, that is familiar with
the local geography, that this could > easily become a disaster and
gain major news coverage that could deal > the industry and the confidence
of the public a significant setback. > > Aside from these concerns I did
notice a few gramatical > inconsistancies in the draft. > > Thanks, > > Marc B > > -----Original Message----- > From: geopriv-bounces at ietf.org
[mailto:geopriv-bounces at ietf.org] On > Behalf Of Hannes Tschofenig > Sent: Tuesday, July 29, 2008
5:31 AM > To: Winterbottom, James > Cc: geopriv at ietf.org;
ecrit at ietf.org > Subject: Re: [Geopriv]
Announce: Specifying Derived Location in a PIDF-LO > > Sounds like a useful way to
indicate the derived location > > Winterbottom, James wrote: > > > > > >
http://tools.ietf.org/html/draft-winterbottom-geopriv-derived-loc-00 > > > > > > > > > > > > Specifying Derived
Location in a PIDF-LO > > > > > > > > > > > > Abstract > > > > > > This document describes
how specify that a location in a PIDF-LO has > > > been derived or converted
from a different location. The source > > > location may reside in the
same PIDF-LO or be a remote document > > > referenced by a location
URI and associated id fragement. > > > > > > > > > > > > > > > > > > Feedback appreciated. > > > > > > > > > > > > Cheers > > > > > > 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 > > > Geopriv at ietf.org > > >
https://www.ietf.org/mailman/listinfo/geopriv > > > > >
_______________________________________________ > > Geopriv mailing list > > Geopriv at ietf.org > >
https://www.ietf.org/mailman/listinfo/geopriv > ------------------------------------------------------------------------------------------------ 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] |
_______________________________________________ Ecrit mailing list Ecrit at ietf.org https://www.ietf.org/mailman/listinfo/ecrit