Re: [Geopriv] [Ecrit] Announce: Specifying Derived Location in a PIDF-LO

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Tue Jul 29 2008 - 13:29:24 EDT

Moreover, it doesn't just *identify* what location the derived location
was derived from, it enables the recipient to get the source location
(or at least request it, with LbyR). This seems to me like a major step
toward providing better location even when people do geo-code.

For this function, I think a little bit of length is unavoidable I don't
think there's a way to do the above (provide source location) without
either including the source or a reference to it. And, of course, the
use of this extension is optional; maybe you just can't use it in a
low-bandwidth environment.

--Richard

Thomson, Martin wrote:
> Read the draft folks.
>
> This is _exactly_ what the draft does: it defines how to indicate that a location is derived. It also specifies how to identify the location that it was derived from.
>
> Cheers,
> Martin
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Roger Marshall
>> Sent: Tuesday, 29 July 2008 3:05 PM
>> To: Marc Berryman; Hannes Tschofenig
>> Cc: geopriv@ietf.org; ecrit@ietf.org
>> Subject: Re: [Geopriv] Announce: Specifying Derived Location in a PIDF-
>> LO
>>
>> Hannes is right to point out that it is better to be clear than to
>> assume.
>>
>> PIDF-LO has already has had capability of providing multiple locations
>> -
>> even more than 2. If there is a label 'derived', for one of them,
>> there
>> needs to be a identifier that points back to the original. This is
>> better than guessing.
>>
>> -roger marshall.
>>
>>> -----Original Message-----
>>> From: geopriv-bounces@ietf.org
>>> [mailto:geopriv-bounces@ietf.org] On Behalf Of Marc Berryman
>>> Sent: Tuesday, July 29, 2008 6:57 AM
>>> To: Hannes Tschofenig
>>> Cc: geopriv@ietf.org; ecrit@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@gmx.net]
>>> Sent: Tuesday, July 29, 2008 8:14 AM
>>> To: Marc Berryman
>>> Cc: Winterbottom, James; geopriv@ietf.org; ecrit@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
>>>
>>> Marc Berryman wrote:
>>>> 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@ietf.org [mailto:geopriv-bounces@ietf.org] On
>>>> Behalf Of Hannes Tschofenig
>>>> Sent: Tuesday, July 29, 2008 5:31 AM
>>>> To: Winterbottom, James
>>>> Cc: geopriv@ietf.org; ecrit@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@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>> _______________________________________________
>>>>
>>>> Geopriv mailing list
>>>>
>>>> Geopriv@ietf.org
>>>>
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>
>>>
>>>
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>
>> CONFIDENTIALITY NOTICE: The information contained in this message may
>> be privileged and/or confidential. If you are not the intended
>> recipient, or responsible for delivering this message to the intended
>> recipient, any review, forwarding, dissemination, distribution or
>> copying of this communication or any attachment(s) is strictly
>> prohibited. If you have received this message in error, please notify
>> the sender immediately, and delete it and all attachments from your
>> computer and network.
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@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@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Tue, 29 Jul 2008 18:29:24 +0100

This archive was generated by hypermail 2.1.8 : Tue Jul 29 2008 - 13:30:13 EDT