- From: Richard Barnes <rbarnes@bbn.com>
- Date: Tue, 11 Nov 2008 16:09:48 -0500
- To: Andrei Popescu <andreip@google.com>
- CC: Doug Turner <doug.turner@gmail.com>, "Thomson, Martin" <Martin.Thomson@andrew.com>, Greg Bolsinga <bolsinga@apple.com>, public-geolocation <public-geolocation@w3.org>
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:10:35 UTC