- From: Richard Barnes <rbarnes@bbn.com>
- Date: Tue, 11 Nov 2008 13:40:31 -0500
- To: Andrei Popescu <andreip@google.com>
- CC: Doug Turner <doug.turner@gmail.com>, "Thomson, Martin" <Martin.Thomson@andrew.com>, Greg Bolsinga <bolsinga@apple.com>, public-geolocation <public-geolocation@w3.org>
I though the group had discussed "reverse geocoding", which, I admit, is
more complicated. This is just defining a format.
--Richard
Andrei Popescu wrote:
> Hi Richard,
>
> On Tue, Nov 11, 2008 at 6:31 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>> Given that it's much easier to come up with a civic address representation
>> than to come up with guidance on reverse geocoding, might we consider
>> addressing this in v1?
>>
>
> I'm afraid the group already discussed this and decided to leave it
> out for v1. As I said, we'll consider it for v2 and discuss your
> proposal at that point.
>
> Thanks,
> Andrei
>
>
>> The structure could essentially be a copy/paste from RFC 5139 (proposed text
>> below; or choose some reasonable subset of it). API calls, or integration
>> with the Position structure, would be easy to add.
>>
>> --Richard
>>
>>
>> -----BEGIN proposed interface-----
>> interface Civic {
>> readonly attribute DOMString country;
>> readonly attribute DOMString A1;
>> readonly attribute DOMString A2;
>> readonly attribute DOMString A3;
>> readonly attribute DOMString A4;
>> readonly attribute DOMString A5;
>> readonly attribute DOMString A6;
>> readonly attribute DOMString PRM;
>> readonly attribute DOMString PRD;
>> readonly attribute DOMString RD;
>> readonly attribute DOMString STS;
>> readonly attribute DOMString POD;
>> readonly attribute DOMString POM;
>> readonly attribute DOMString RDSEC;
>> readonly attribute DOMString RDBR;
>> readonly attribute DOMString RDSUBBR;
>> readonly attribute DOMString HNO;
>> readonly attribute DOMString HNS;
>> readonly attribute DOMString LMK;
>> readonly attribute DOMString LOC;
>> readonly attribute DOMString FLR;
>> readonly attribute DOMString NAM;
>> readonly attribute DOMString PC;
>> readonly attribute DOMString BLD;
>> readonly attribute DOMString UNIT;
>> readonly attribute DOMString ROOM;
>> readonly attribute DOMString SEAT;
>> readonly attribute DOMString PLC;
>> readonly attribute DOMString PCN;
>> readonly attribute DOMString POBOX;
>> readonly attribute DOMString ADDCODE;
>> }
>>
>> // For example...
>> var addr = navigator.geolocation.lastPosition.civic;
>> // Print a US address
>> var addrStr = ""
>> addrStr += addr.HNO +" "+ addr.RD +" "+ addr.STS +"\n";
>> addrStr += addr.A3+ ", "+ addr.A1 +" "+ addr.PC +"\n";
>> -----END proposed interface-----
>>
>>
>> Doug Turner wrote:
>>>
>>> On Nov 11, 2008, at 9:53 AM, Andrei Popescu wrote:
>>>
>>>> Hi Martin,
>>>>
>>>> On Mon, Nov 10, 2008 at 9:51 PM, Thomson, Martin
>>>> <Martin.Thomson@andrew.com> wrote:
>>>>> Hi Andrei,
>>>>>
>>>>> I think that you've got it, but rather than could, I'm saying "should".
>>>>> The API shouldn't assume that the two have the same source, but it doesn't
>>>>> need to be.
>>>>>
>>>>> Rather than saying that we should revisit reverse geocoding in version
>>>>> 2, you should be saying that we should revisit _civic addresses_ in version
>>>>> 2.
>>>> Ok, fair enough. I suspect we'll see more demand for this once this
>>>> spec opens up to a larger audience, so I believe it'll be one of the
>>>> top discussion items for v2.
>>>>
>>>> All the best,
>>>> Andrei
>>>
>>>
>>> +1
>>>
>>>
>
Received on Tuesday, 11 November 2008 18:41:16 UTC