Re: What about Reverse Geocoding?

Right, i think draft 1 needs to have the conical format for location  
(lat, lon, err).  I worry about civic addresses universal value, cost  
to implement, and, of course, adoption.

Do you have a use case for a civic addresses?  Something that couldn't  
be solved with lats and longs?

Doug

On Nov 9, 2008, at 6:26 PM, Thomson, Martin wrote:

> This isn't necessarily about reverse geocoding.  You should be  
> careful in making that assumption.  Civic address information can be  
> acquired by other means.
>
> Besides, if it's out of scope, then what is this doing in the  
> current draft?
>
> " The Geolocation API should allow an application to request address  
> information as part of the location data. "
>
> Cheers,
> Martin
>
>> -----Original Message-----
>> From: Doug Turner [mailto:doug.turner@gmail.com]
>> Sent: Monday, 10 November 2008 1:01 PM
>> To: Thomson, Martin
>> Cc: Greg Bolsinga; public-geolocation; Andrei Popescu; Richard Barnes
>> Subject: Re: What about Reverse Geocoding?
>>
>> I thought reverse geocoding was out of the scope for the first
>> revision of the specification.  What am I missing?
>>
>> Doug Turner
>>
>>
>> On Nov 9, 2008, at 2:20 PM, Thomson, Martin wrote:
>>
>>> I don't think that either comment was suggesting that the object
>>> needed to be in XML (or DHCP LCI) format.  Only that the fields be
>>> considered for the API...  That is, something like (as you
>> suggested):
>>>
>>> interface CivicAddress {
>>>   readonly attribute string country;
>>>   readonly attribute string A1;
>>>   readonly attribute string A2;
>>> ...
>>>   readonly attribute string PLC;
>>>   readonly attribute double PCN;
>>>   readonly attribute double POBOX;
>>>   readonly attribute double ADDCODE;
>>>   readonly attribute DOMTimeStamp timestamp;
>>> };
>>>
>>> The elements chosen by gears works moderately well for the US.
>>> Unfortunately, it doesn't travel particularly well.  Hence the
>>> suggestion that the API adopt a more comprehensive set of fields.
>>>
>>> Ta,
>>> Martin
>>>
>>>
>>>> -----Original Message-----
>>>> From: public-geolocation-request@w3.org [mailto:public-geolocation-
>>>> request@w3.org] On Behalf Of Greg Bolsinga
>>>> Sent: Sunday, 9 November 2008 8:24 AM
>>>> To: public-geolocation
>>>> Cc: Andrei Popescu; Thomson, Martin; Richard Barnes
>>>> Subject: Re: What about Reverse Geocoding?
>>>>
>>>>
>>>> On Nov 6, 2008, at 1:17 PM, Richard Barnes wrote:
>>>>
>>>>> Wouldn't the simple thing to do be to just provide in the API a  
>>>>> way
>>>>> to deliver location as a civic address?  See [1] and [2] for the
>>>>> some ideas on how you might structure such an object.
>>>>>
>>>>> That way, a location provider that knows natively about a civic
>>>>> address can provide it, and a location provider that only knows
>>>>> geodetic location can geocode.  This would leave the whole  
>>>>> question
>>>>> whether and how to geocode out of the API, leaving it up to the
>>>>> location provider.
>>>>>
>>>>> --Richard
>>>>>
>>>>> [1] <http://tools.ietf.org/html/rfc4119>
>>>>> [2] <http://tools.ietf.org/html/rfc5139>
>>>>
>>>> On Nov 6, 2008, at 3:27 PM, Thomson, Martin wrote:
>>>>
>>>>> Civic addresses are pretty damned awkward for a computer system,
>> but
>>>>> they are still useful to people.  For manual entry, a civic  
>>>>> address
>>>>> is far more reliable than lat/long.  Based on the current rate of
>>>>> progress of technology, manual entry is still going to be a
>>>>> significant proportion of users.  Civic addresses include
>>>>> information that simply cannot be encoded in a geodetic position,
>>>>> such as data relating to the human environment: buildings, roads,
>>>>> signs, and landmarks.
>>>>>
>>>>> So here's a possibility:
>>>>>
>>>>> navigator.geolocation.getCivicAddress(function(address)
>>>>> { alert(address.country);});
>>>>>
>>>>> Selection of fields for civic addresses is a complex challenge.  A
>>>>> free-form line based format is possible, but it doesn't offer much
>>>>> to the recipient.  Free-form data is inconsistent.  The  
>>>>> alternative
>>>>> is to try to structure the data.  Even the most carefully
>>>>> constructed format has its drawbacks and compromises need to be
>>>>> made.  The format in RFC 4776/5139 (yes, I have a horse in this
>>>>> race) takes the structured approach and has been widely adopted
>>>>> already.  This is the format that is most likely to be available  
>>>>> in
>>>>> standard form from an ISP.
>>>>
>>>> If we pass 'a blob' back to the developer, they are going to have  
>>>> to
>>>> parse it. Sure it's flexible, but it's not very practical. In
>>>> addition, parsing more downloaded data is not so practical on
>>>> resource
>>>> constrained UAs. Developers may not parse it in the the most
>>>> efficient
>>>> manner. The first one to implement the parser will be the one that
>>>> every other developer copy and pastes into their web page. ;)
>>>>
>>>> This is why I like an API solution. I think the object in
>>>> http://code.google.com/apis/gears/api_geolocation.html#address
>>>> is also very flexible, but it's an API. The big benefit in my mind
>>>> is that the developer won't have to do any parsing.
>>>>
>>>> Would it be 'illegal' if a UA added these optional fields
>>>> ("requestAddress" to the PositionOptions and "address" in Position)
>>>> if
>>>> they should not make it into the specification? It would be a shame
>>>> if
>>>> they didn't make it in, but I can see certain UAs wanting to  
>>>> provide
>>>> this information to their developers.
>>>>
>>>> Thanks,
>>>> -- Greg
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>> ---------------------------
>>> This message is for the designated recipient only and may
>>> contain privileged, proprietary, or otherwise private information.
>>> If you have received it in error, please notify the sender
>>> immediately and delete the original.  Any unauthorized use of
>>> this email is prohibited.
>>> ---------------------------------------------------------------------
>> ---------------------------
>>> [mf2]
>>
>
> ------------------------------------------------------------------------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> ------------------------------------------------------------------------------------------------
> [mf2]

Received on Monday, 10 November 2008 02:42:58 UTC