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 Friday, 6 March 2009 15:52:06 UTC