- From: Doug Turner <doug.turner@gmail.com>
- Date: Tue, 11 Nov 2008 13:18:51 -0800
- To: Richard Barnes <rbarnes@bbn.com>
- Cc: Andrei Popescu <andreip@google.com>, "Thomson, Martin" <Martin.Thomson@andrew.com>, Greg Bolsinga <bolsinga@apple.com>, public-geolocation <public-geolocation@w3.org>
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 21:19:31 UTC