W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2009

Re: Civic Address for V2

From: Andrei Popescu <andreip@google.com>
Date: Tue, 10 Mar 2009 08:12:34 -0700
Message-ID: <708552fb0903100812h1bca799fp1aa30ee8218de70a@mail.gmail.com>
To: Doug Turner <doug.turner@gmail.com>
Cc: Henning Schulzrinne <hgs@cs.columbia.edu>, Alec Berntson <alecb@windows.microsoft.com>, Marc Linsner <mlinsner@cisco.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
I can put mine in IDL so we have it as a reference? I'll do that later today.

Andrei

On Tue, Mar 10, 2009 at 7:51 AM, Doug Turner <doug.turner@gmail.com> wrote:
>
> Does someone have a proposal IDL of the full civic address with "human
> readable names?"  (instead of A2, "county").  I saw Andrei's reduced form
> proposal, but didn't see anything that was a complete civic address.
>
> Doug
>
> On Mar 10, 2009, at 7:20 AM, Henning Schulzrinne wrote:
>
>> Most cases won't need all the fields, but having them will allow more
>> applications and avoid the hackery and guestimes I talked about. Just as an
>> example, having a separate building name field is quite useful on campus for
>> friend-finder applications ("who is in the same building?"). In some other
>> cases, we may only have limited precision (e.g., county-level for
>> IP-address-to-location services). I admit that I find it hard to believe
>> that somebody doesn't understand "building name", "floor", "street suffix"
>> or some of the other fields proposed. The more obscure fields, such as the
>> street branch system, will only apply regionally, so developers that don't
>> care about Indonesia can ignore them, but they do make the system capable of
>> handling more than just US and European addresses.
>>
>> Henning
>>
>> On Mar 9, 2009, at 2:44 PM, Doug Turner wrote:
>>
>>> Hello Henning,
>>>
>>> I do not think we have any use cases that require comparing addresses for
>>> equality.  We clearly did not for the v1 addressing (coords).  I tend to
>>> think that civic addressing comparison is out of scope.  For example, if two
>>> UAs pass back an address for the same place, I do not think that we should
>>> make any guarantees that the data the UA pass back to the requesting site is
>>> the same.  In fact, I do not think that the addresses need to be the same
>>> between different runs of the same UA.  The reason for this is that UAs
>>> might use different back-ends for determining the actual location of the UA.
>>>  Maybe the first geolocation request uses WiFi->location, and the second
>>> request uses a user defined position, or what have you.
>>>
>>> Secondly, we are not designing this API for someone like your or me or
>>> anyone on this mailing list that can understand thirty+ fields, have no
>>> problem looking up extensive documentation, and enjoy digging through
>>> mailing list for rationale on the way things are they way they are..
>>>  Rather, the API must be designed for the web at large.  I think we should
>>> design the simple-to-use over a can-do-everything-everyone-every-wanted
>>> address for v2.
>>>
>>> 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.
>>>
>
>
Received on Tuesday, 10 March 2009 15:13:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:52 UTC