RE: What about Reverse Geocoding?

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]

Received on Sunday, 9 November 2008 22:21:29 UTC