- From: Erik Wilde <dret@berkeley.edu>
- Date: Sun, 29 Jun 2008 14:51:14 -0700
- 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 UTC