Re: What about Reverse Geocoding?

In this use case, i do not see why you need anything exposed into the  
DOM.

Lets suppose you did.  We extended the location object to have this  
data.  i don't see how a "pizza site" could make use of this  
information.  Will they have to have a data base of civic addresses?   
Is it not easier to just pass them a conical form and let them deal  
with it?

I am all for making it easier for the user to type in their location.   
However, i don't think we should be transporting this information to  
every website.... instead, i think we should encode it into something  
that is more universal.

For example, for a end user to get their location, I wrote up this  
little web app (ignore lack of polish, etc.)

http://whatismygeolocation.com/

It is is based on the google maps api.  You simply enter where you  
are, confirm where the webapp thinks you are, and you get back a lat/ 
lon.  This can be made simpler, not requiring the user to enter any  
data (or copy that lat/lon).  In any case, using this approach will  
allow you to avoid sending "civic" address over the wire, and instead  
use the base lat/lon format.

Thoughts?

Regards,
Doug

On Nov 9, 2008, at 7:01 PM, Thomson, Martin wrote:

> The use case we dealt with when we were toying with the idea of a  
> browser plugin was the automatic filling of address forms.  We even  
> had a working prototype that followed exactly this use case.
>
> For instance, knowing where you are, you can order deliveries  
> without needing to go through the tedium of telling the site where  
> to send the package/pizza/truckload of blue metal.
>
> You could also say that people are more likely to get a civic  
> address correct.  If you are relying on manual entry, then civic  
> address information is at least equivalent to automatic methods.   
> Geocoding and reverse-geocoding erase a lot of the difference  
> though, but a lot of that is subject to how robust the  
> implementation of the translation is.
>
> Cheers,
> Martin
>
>> -----Original Message-----
>> From: Doug Turner [mailto:doug.turner@gmail.com]
>> Sent: Monday, 10 November 2008 1:42 PM
>> To: Thomson, Martin
>> Cc: Greg Bolsinga; public-geolocation; Andrei Popescu; Richard Barnes
>> Subject: 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]
>>
>
> ------------------------------------------------------------------------------------------------
> 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 03:12:58 UTC