Re: Civic Address for V2

While this is clearly a use case, clear and unambiguous presentation  
of address elements is important for other applications, such as  
comparing addresses for (partial) equality and proximity. In my  
experience, dealing with clearly defined elements, even if a few more,  
is far easier to program with than having to deal with picking apart  
blobs of data and having to implement all kinds of heuristics to deal  
with everybody's unique way of stuffing data into fields. I don't see  
why these elements are hard to understand.

Henning

On Mar 9, 2009, at 2:19 PM, Alec Berntson wrote:

> The public safety and emergency scenarios are repeatedly used as a  
> defense for complicated CivicAddress interfaces. I agree that for  
> those scenarios, having a very concise, unambiguous format is vital.
>
> I question whether a javascript browser API is actually going to be  
> used for these scenarios. Based on the use cases in the spec, we are  
> targeting primarily consumer scenarios where location, especially  
> civic address location, is being used as metadata and for making web  
> apps contextually aware.
>
> I don't see why this API needs to compete with or support standards  
> that are designed for a very different set of use cases.
>
>
> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org 
> ] On Behalf Of Marc Linsner
> Sent: Friday, March 06, 2009 7:51 AM
> To: Andrei Popescu
> Cc: public-geolocation@w3.org
> Subject: Re: Civic Address for V2
>
> Andrei,
>
> You are (almost) correct in your analysis.  ;^)
>
> Prior to being comfortable, I would ask that you investigate the civic
> location addressing enabled in Microsoft products as to it's usage for
> worldwide location applications, ie. parcel delivery, public safety,  
> etc.
> My basis for questioning is simply the variations that have been  
> proposed to
> the IETF.  If folks have issues with the extensive pidf-lo, is the  
> proposed
> simpler LO going to fit the bill?
>
> Let me give you some more background of discussions around
> location/addressing that have taken place over the years.
>
> The starting point of the GeoPriv civic addressing was rooted in the  
> US
> Master Street Address Guide (MSAG) that is under the administration  
> of the
> Public Safety Authorities across the US.  The MSAG is used as the
> authoritative db for call routing and dispatch of Public Safety  
> responders.
> Even though the reasoning for the complete delineation of the civic  
> address
> into fields such as pre/post street directionals seems excruciating,  
> those
> in charge of trimming seconds from response time provided evidence  
> of their
> necessity.  Their solution handles the 71 variations of ³Peachtree²  
> (St,
> Blvd, Pl. etc) found in the Atlanta, GA metropolitan area without  
> ambiguity.
>
> So, as the Internet handles the convergence of various applications,  
> it also
> has to handle the convergence of data required by those various
> applications.
>
> Yes, for more than 40 years, the MSAG location has been Œdifferent¹  
> from
> normal human consumable locations.   It¹s unreasonable to imagine a  
> future
> that supports multiple descriptions/objects for the same location,  
> as the
> Internet has completely distilled the model where the application  
> provider
> is held responsible for the location of the service.  Location data  
> will be
> derived in a myriad of methods - host derived, end-user derived,  
> network
> derived and various combinations of each.
>
> So, Public Safety was forging ahead with the complete acceptance  
> that their
> 'MSAG' location was different from human consumable civic  
> locations.  They
> came to the IETF and asked for an object to carry their MSAG location.
> After examining the varying methods a host will discover and use it's
> location, carrying the MSAG object plus the human consumable object  
> just
> makes no sense.  Hence, convergence.
>
> So I wonder, do you believe that you can algorithmically 2-way  
> transform
> pidf-lo objects to W3C location objects with 100% success, or are  
> you asking
> hosts to carry around two different location objects?
>
> Just something to think about,
>
> -Marc-
>
>
>
>
> On 3/6/09 8:49 AM, "Andrei Popescu" <andreip@google.com> wrote:
>
>> Hi Charles,
>>
>> On Wed, Mar 4, 2009 at 8:42 AM, Charles McCathieNevile <chaals@opera.com 
>> >
>> wrote:
>>>
>>> So this comes back to the use cases and requirements. If being  
>>> able to
>>> compare addresses and make useful inferences matters, then it is  
>>> important
>>> to split out the semantics, with the level of detail determining  
>>> how far
>>> down the semantic split should go. Otherwise, you are right that  
>>> it is not
>>> really important.
>>>
>>
>> I think you're absolutely right, this is the issue. We could go down
>> the route of splitting semantics in such a way that the address  
>> format
>> has a field dedicated to every particularity of any address on Earth
>> and satisfy all use cases from here to eternity. Or we could have a
>> slightly more pragmatic approach of drawing the line at a level of
>> detail that we deem reasonable in terms of complexity (i.e. easy to
>> understand by developers and capable of satisfying the use cases we
>> now have in the document). If we're careful to design the API in an
>> extensible manner, we can act on feedback from application developers
>> and API implementers and extend the format based on their needs. To
>> me, this latter approach is the one that we should take: start from
>> from rfc 4119 and simplify it  (i.e. coalesce some fields and give
>> them humanly understandable names) as I proposed. This yields a
>> solution that is also reasonably close to what Microsoft has in
>> products that ship pretty much everywhere, which is rather reassuring
>> to me.
>>
>> Thanks,
>> Andrei
>>
>
>
>
>
>
>

Received on Monday, 9 March 2009 18:26:11 UTC