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

Received on Saturday, 8 November 2008 21:24:33 UTC