Thanks for explaining why my android phone says I am at +38m (+/- 3) in my backyard when in fact it is at Dutch sea level -4.4m.
Best, Peter Elderson Op ma 4 mei 2020 om 02:39 schreef Greg Troxel <g...@lexort.com>: > Martin Koppenhoefer <dieterdre...@gmail.com> writes: > > > I’m asking for comments on > https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional > > Two big comments: > > First, the current wiki documentation about ele and Altitude should be > really straigthened out, so that we have a basis for what we are > comparing to. > > Second, the notion of a single regional vertical datum doesn't really > work. In the US, that could be the old NGVD29, or the current NAVD88. > Plus, we are about to get NATRF2022. However, all of these are within > a meter or so, and in terms of vertical data in OSM, that's not really > a big problem. So if there is going to be precision, then we should > follow GIS and have an explicit datum. I would say an EPSG code is > sensible -- see the proj package for canonical values. > > > > As for ele/Altitude, there is great confusion out there about "WGS84" > and two separate concepts: > > height above the ellipsoid. Often written HAE. The ellipsoid is a > mathematical surface that is NOT a surface of equal gravity. While > geodesists and geodetic surveyors use it, and while it's part of the > calculations within GPS, I am not aware of a single vertical datum in > use in any country that is relative to the ellipisoid. Note that > water does not flow "downhill" when "down" means to a lower value of > HAE. Water is hugely important in elevation and mapping. > > height above geoid, or height above a reference equal-gravity surface, > or height above sea level. (Yes, I realize that "sea level" is a huge > can of worms.) This is more or less what every height system uses or > intends to use. > > > In WGS84, one gets from the base computation lat/lon and a height above > the ellipsoid. This is purely a geometric answer and is totally > disconnected from grravity. Then, GPS receivers use a gravity model to > compute the offset from the ellipsoid and the reference gravity surface > (which is more or less the "sea level surface"), and they them use that > to get a "height above sea level". Receivers that display to humans > display this sea level height. NMEA has that same sea level height. > > (Android stands alone in that the API returns height above ellipsoid. > That's not wrong, but it is unusual. IMHO how Android defines an > interface is irrelevant to OSM's definitions.) > > > When people say "WGS84 altitude", they mean the height above the WGS84 > equal-gravity surface as computed from the ellipsoidal height and the > gravity model. This is sort of 0m at sea level. Note that the > ellipsoid can be 100m different from this equal-gravity surface, and is > often significantly different. It's ~30m in Boston and I hear it's 50m > in Switzerland. Nobody who says "WGS84 altitude" really means "WGS84 > ellipsoidal height". If they did, they would say "WGS84 ellipsoidal > height". > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
