- 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