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>


>> 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.


Received on Sunday, 29 June 2008 21:51:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:49 UTC