Re: What about Reverse Geocoding?

Hi RIchard,

I think you missed my point.  On the web, you want a required  
universal data type for gelocation as basis.  Fragmentation will arise  
if you don't have this.

Doug


On Nov 11, 2008, at 3:17 PM, Richard Barnes wrote:

> 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:41:38 UTC