RE: What about Reverse Geocoding?

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]

Received on Monday, 10 November 2008 03:02:02 UTC