RE: What about Reverse Geocoding?

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>

> -----Original Message-----
> From: Doug Turner [mailto:doug.turner@gmail.com]
> Sent: Monday, 10 November 2008 2:12 PM
> To: Thomson, Martin
> Cc: Greg Bolsinga; public-geolocation; Andrei Popescu; Richard Barnes
> Subject: 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]
> 

------------------------------------------------------------------------------------------------
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 04:21:17 UTC