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]

Received on Monday, 10 November 2008 02:01:39 UTC