Re: What about Reverse Geocoding?

Do you really mean that every website that does geolocation will have to 
provide geodetic location?  As I've tried to point out, there are many 
situations where it makes more sense to provide civic, *especially* in 
contrast to just a lat/long pair.

IMO, having two options doesn't really count as "fragmentation".  How 
hard is it two write
if (geodeticExists())
	geo_foo();
else if (civicExists())
	civic_foo();

--Richard





Doug Turner wrote:
> 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:56:18 UTC