Re: What about Reverse Geocoding?

Doug,

We should remember the distinction between "mandatory to implement" and 
"mandatory to use"; what we're talking about here is the former.  All 
the API does is define a data structure, which is how a web page gets 
data *if* the browser provides it.  Adding a field to the API entails no 
cost for implementers that don't want to use it -- either on the 
location provider end or the consumer end.  Providers don't have to fill 
the field if they don't want to, and web pages don't have to look at it. 
    A location provider that wants to do reverse geocoding *can*, but it 
certainly wouldn't have to.

By way analogy: Just because there are lat/long fields doesn't mean a UA 
has to have GPS.  In the same way, just because there are civic fields 
doesn't mean a UA has to do reverse geocoding.  In fact, neither case 
makes any requirement of the UA except to create an object that's either 
null or has a particular structure.

On the other hand, if you enable location provider to provide civic 
location, you enable a whole other class of location based applications 
(ones that prefer civic addresses, e.g., postage rate calculators, to 
pick a random example), and location providers (ones that can only 
return civic addresses, like the IETF network I described earlier).

--Richard


Doug Turner wrote:
> Richard,
> 
> We also have to worry about adoption.  We want interop between all UAs 
> and the web.  There is a significant cost to reverse geolcoation and/or 
> Civic addresses.  For example, the base implementation of a UA and a GPS 
> device has no understand of how to translate the location data from 
> lat/lon to anything greater.  My concern is that if we push ahead and 
> provide a civic address as a non-optional part of the Position element, 
> you will effectively cut off the base UAs from participation in the 
> geolocation enabled web.
> 
> For this reason, we pushed any non-lat-lon-location data until v.2
> 
> Doug
> 
> On Nov 11, 2008, at 1:09 PM, Richard Barnes wrote:
> 
>> Andrei,
>>
>> Discussion of how you populate a civic address field is completely 
>> separate from the format of the field itself.  Just because we've got 
>> a lat/long in the current version doesn't mean we have to say how a 
>> location provider uses GPS, right?  The point of this API is just to 
>> provide access to whatever location is there, not to specify how to 
>> get it.  How the location gets there (into the browser) is up to the 
>> location provider.
>>
>> If you're curious though, by and large civic location has to be 
>> manually configured or reverse-geocoded.  The IETF networks at the 
>> last few IETF meetings have been location-enabled, and we've provided 
>> civic addresses (down to an individual room) corresponding to the 
>> 802.11 AP that a client is connected to.  This is a good example of a 
>> case where civic is a lot easier to use that geodetic -- it would have 
>> been a huge pain to set up any sort of geodetic positions for APs.
>>
>> As far as the syntax I was suggesting, I was imagining a compound 
>> position object, for example:
>> interface Position {
>>     readonly attribute Geodetic geodetic;
>>     readonly attribute Civic civic;
>>     readonly attribuet UsageRules rules
>> }
>> (This is what a Position looks like in the current HELD location 
>> provider.)  A client would then get civic information like I showed 
>> before, geodetic information with something like 
>> "loc.geodetic.latitude", rules with something like 
>> "loc.rules.retransmissionAllowed".
>>
>> Cheers,
>> --Richard
>>
>>
>> Andrei Popescu wrote:
>>> On Tue, Nov 11, 2008 at 6:40 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>>>> I though the group had discussed "reverse geocoding", which, I 
>>>> admit, is
>>>> more complicated.  This is just defining a format.
>>> I'm not sure why we'd define a new interface (i.e. 'Civic') if there
>>> is no way to produce objects that implement it. Or if we do specify a
>>> way to produce such objects (e.g. your example suggests adding a
>>> 'civic' attribute to the Position interface) then I don't see how we'd
>>> be able to completely separate the discussion from reverse geocoding.
>>> I think the two should be discussed at the same time.
>>> Andrei
> 
>

Received on Tuesday, 11 November 2008 23:17:52 UTC