Re: Civic Address for V2

> I do not think we have any use cases that require comparing addresses 
> for equality.  We clearly did not for the v1 addressing (coords).

Neither of these statements is really true, if you think about it.

For example, there is a use case for providing information relevant to
the user's current location (e.g., PoI information).  To make that work,
you need to compare the user's current location with some description of
a region in which a piece of information is relevant.  For geodetic
coordinates, that can be a polygon, "Return everything within 500m of
the target".  In civic coordinates, you need the extra semantics so that
you can say things like, "Return everything in the same region" or
"Return everything on the same street".  That stuff doesn't work with
aggregated addressing, where regions and streets aren't specifically tagged.

The doc specifies (as it should!) that the coordinates MUST reference
the WGS84 coordinate reference system --  precisely so that locations
can be compared to one another.


> Secondly, we are not designing this API for someone like your or me or 
> anyone on this mailing list that can understand thirty+ fields... 

I appreciate the need for simplicity.  However, based on the input we
got in GEOPRIV from organizations that deal with addresses in
mission-critical applications (especially NENA, who do 9-1-1 standards),
the RFC 4119 format is about as simple as the format can be made and
still map sensibly to authoritative address sources, even just in the US.

(If you want to see a complex representation, check out xAL:
<>)

Cheers,
--Richard



> Keep in mind, that one could always create a civic address spec that 
> leverages the geolocation specification and implementations.  For 
> example, you could add a separate civicAddress to the position object in 
> a future specification.
> 
> Regards,
> Doug Turner
> 
> 
> On Mar 9, 2009, at 11:25 AM, Henning Schulzrinne wrote:
> 
>> 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 Friday, 20 March 2009 06:13:04 UTC