RE: What about Reverse Geocoding?

Hi Aaron,

I think that you are making a few assumptions about how this works.  I'll elaborate further below...

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Aaron Straup Cope
> Sent: Monday, 10 November 2008 4:53 PM
> To: public-geolocation@w3.org
> Subject: Re: What about Reverse Geocoding?
> 
> 
> What would an API return for a point that doesn't have a civic, or
> postal, address? Say a park, a field in the country, the waters off the
> coast or simply some part of the world where the data hasn't been
> collected?

There's almost always some information that can be provided.  The name of the park, the farm associated with the field.
There are also fields that include people friendly information that could include "off the west coast of the US from LA".

I'm not sure that I understand what you mean by "data hasn't been collected".  I suspect that you are assuming an automated process is generating this information.  I don't.  At some point, almost all civic address information is created by a person.  If it's a machine generating the information, then a person gave it to the machine somewhere.  If the machine doesn't have the information, it doesn't provide it and the navigator.getCivicAddress call fails (or the getCurrentPosition includes a civicAddress value that is null.
 
> What would an API do if the lat,lon passed lacked sufficient accuracy
> to
> resolve down to street level? What if street level for a fuzzy point
> turns out to be [insert your undesirable location here] ?

The civic address doesn't have to be derived from geodetic information.  However, if the geodetic location is used as input, then if it isn't enough to identify a house, then it shouldn't.  It can probably identify a town/suburb if its "fuzzy" out to 100m.  It can almost certainly identify a state or country.
 
> What is the expectation of precision and would that be exposed? If an
> API can only resolve a point to the nearest corner, or a few buildings
> over, should it still return something and how would it expose that
> information to the end user?

An implementation of the API might not be able to identify a house given the information that is available to it.  If it doesn't have the information, it can't provide it.  As above, there's probably something that it can provide.  Maybe, and stop me if this is crazy-talk, it can get the information from someone who knows, maybe the person that is using the device.

(This is probably a bigger problem for wireless devices than wired, but that's a separate problem.)
 
> Likewise, should an API expose a collection or best-before date so that
> I can infer an address in Tokyo is probably out of date? (And would
> data
> providers really be comfortable exposing that sort of information?)

I'm not sure that I follow.  All location information comes with a timestamp and is subject to the same expiration considerations.  That is, people move.
 
> What is the structure an API would return and how do you standardize on
> the subtleties in the meaning of "places". Apologies to those who've
> already heard this song but I will quote myself [1] long to say:
> 
> <snip>
> The simplest example is to contrast the way that Flickr and FireEagle
> handle "localities" since the two sites share an almost exact hierarchy
> of places. Flickr treats anything with neighbourhoods as a locality so
> in our model Duncans Mills, CA (pop. 84) and Mexico City (pop. 19M) are
> assumed to be the same "type" of place.
> 
> FireEagle does not. If you authorize an application to know your
> whereabouts at a "city" level there is an expectation that your actual
> location will be suitably fuzzed (assuming that you share an
> expectation
> that cities are "big") and in a town of 84 people there's not a lot of
> room to get fuzzy in.
> </snip>

That's an larger and more interesting question.  Standardization is the only hope here.  I think that they have Austria sorted out:

  <http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendations>

(aside: The word "locality" seems to be an convenience label used here to refer to different things.  The IETF decided to avoid any preconceptions with names and go with numbers: A1, A2, ...A6.  For places like the US, Canada and Australia: A1 == state, A2 == county, A3 == city, A4 == suburb, A5 == neighbourhood, and A6 is rarely used.  However, in Japan, this might be entirely different, although largely parallel.)
 
> On top of all that, we (Flickr) classify airports as localities. This
> makes sense for us since no one is "in Surrey" when they're taking
> photos of screaming kids at Heathrow but that doesn't necessarily mean
> the model it right for anyone else.

What airports are classified as might depend on which country you are in.  Certainly, many airports are considered on the same level as a suburb.
 
> It's an interesting and juicy problem for sure but I'm not really sure
> it's anything the DOM is going to solve.

Sure, but then it doesn't really have to.

> 
> Cheers,
> 
> --
> 
> [1] http://lists.w3.org/Archives/Public/public-

> geolocation/2008Jun/0059.html
> 
> Thomson, Martin wrote:
> > Hi Doug,
> >
> > Sure, you don't need anything in the DOM, and indeed, our original
> prototype didn't use the "DOM" when filling forms [1].  Of course, that
> relies on standardization from the sites, not the browser - you need to
> be able to rely on the form field named 'country' being a country
> field.  Going the other way around - standardization of the object
> exposed to the site through the scripting language - is a much easier
> prospect because that means standardizing fewer piece of code.
> >
> > The pizza site uses this information using the following process:
> They lift it from the browser and send it back home with the order.
> Then they pass it to the delivery driver.
> >
> > Not all delivery services use GPS in their delivery vehicles for one.
> More importantly, given that the destination might be on the 5th floor
> of an apartment building, unit 25, the GPS only gets the driver to the
> front door of the building.  He still needs the civic data.
> >
> > This is much nicer (and even less error prone) than a geodetic
> location because it is generated and consumed by humans who understand
> civic addresses.  You have to get out of the mindset that says that
> this data lives its entire life in a machine.  People have to deal with
> this stuff sometimes and people don't grok geodetic.
> >
> > I can see how your (or really Google's [2]) service helps people with
> the translation, but I don't see that it completely replaces civic
> addresses.
> >
> > Cheers,
> > Martin
> >
> > [1] What _is_ the right term for this?  My view is that it isn't
> really DOM because it isn't really a document that we're dealing with.
> I prefer to just say that "the object is exposed to the page" and leave
> it at that.
> >
> > [2] You could equally use the maps interface directly with an addon:
> <http://maps.google.com/ig/directory?ie=UTF8&hl=en&pid=mpl&synd=mpl&num

> =24&url=http://thomas.duebendorfer.googlepages.com/position_finder.xml&

> output=html>
> 
<snip deadweight>
------------------------------------------------------------------------------------------------
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 06:17:01 UTC