W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: skeleton Geolocation API

From: Erik Wilde <dret@berkeley.edu>
Date: Sun, 29 Jun 2008 14:51:14 -0700
Message-ID: <486803D2.3010203@berkeley.edu>
To: public-geolocation@w3c.org
CC: Aaron Boodman <aa@google.com>

hello.

>> i like the general idea. this would also allow contexts in which no lat/long
>> information is given at all. for each context, there would have to be a
>> definition which parts of a position (lat/log, elevation, uri, bearing,
>> speed) can/must be present, and how they are defined. if it is done that
>> way, there would have to be at least three context identifiers for wgs84
>> coordinates, though, because elevation should at least be supported for
>> plain wg84, egm96, and barometric values.
> I think it is better for the web if we choose one way to interpret the
> API. Interop is hard to achieve when the developer has to be ready for
> many different measurement systems.

that's true as long as you can simply convert values. for elevation, i 
think wgs84<->egm96 can be done in both direction (if you also have the 
lat/long values). for barometric pressure, there's no way you can map 
that automatically, and yet it may be an interesting value that a device 
might want to make available. but claiming that it is a wgs84 or egm96 
value when it's not (because the device might have no gps) would not be 
a good idea.

i agree that simplification is a good goal to have for a web API, but in 
some cases that might still mean that certain messy details of the real 
world have to be exposed.

cheers,

dret.
Received on Sunday, 29 June 2008 21:51:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT