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: [mailto:public-geolocation-
>>] 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] <>
>>> [2] <>
>> 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(;});
>>> 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
>>  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