- From: Erik Wilde <dret@berkeley.edu>
- Date: Sun, 04 Jan 2009 16:26:38 -0800
- To: "Thomson, Martin" <Martin.Thomson@andrew.com>, public-geolocation@w3.org
hello martin. > The definition is clear enough without resorting to discussions of gravitational models. The term "ellipsoid" does not introduce any ambiguity; no mention is made of the geoid, which is clear enough. EGM96 (or EGM2008) can be applied ad hoc by those who require "sea level" type altitude. isn't EGM applied to make altitudes more "real"? it is my understanding that EGM is useful because it makes altitudes more accurate in terms of how the earth is really shaped, but on the other hand it is expensive because it is a large datasets and not all devices have it built-in. so what you're saying is that altitude is *not* EGM-corrected in any way, right? i think it would be worth to make that explicit, if that is what we want to do. i thought manufacturers may build in EGM support into their devices to make them more accurate, and we would then force them to expose a non-corrected value through the API. i think this kind of decision would be worth to be made explicit, rather than implicitly being made by just mentioning the GPS ellipsoid. > Obviously, this represents a (extremely minor) disconnect between the results and the actual physical environment; given the inherent limitations of the technology with respect to accuracy, I hardly think that it will have much bearing on the usability of the information. i think the disconnect is not so minor and in some places up to 100m (85m minus and 105m plus, i think), which can be pretty important, for example in mountaineering. if a device can provide better accuracy, why not allow it to expose it? i guess this gets back to the "the man with two watches", but again, these two watches are different. if the device has only GPS altitude, so be it, then the client would have to do the correction. however, if the device does have built-in support for providing better measurements, why disallow exposing them? cheers, dret.
Received on Monday, 5 January 2009 00:27:19 UTC