Just so that it is clear for everybody what the issue is about, Android is not really relevant outside of resurfacing it.
Historically the understanding was that ele would use "height above the ellipsoid", there is some reasoning on the Altitude page, might have made sense originally. In 2013 the ele entry was fiddled to point to the height above geoid. This leaves us with a) conflicting definitions in the wiki (not the first time) b) a tag de-facto redefined after multiple years of use (natural=tree anybody?) Naturally the correct way to solve the issue would have been to introduce a new tag with the appropriate semantics and then let ele die out. Given that the mess has already happened it could be argued that we might as well use ele with the semantics that have been proposed for ele:regional, because that is what it "mostly"* has been used for. Simon * if would naturally be nice if that wasn't just based on speculation. Am 04.05.2020 um 02:37 schrieb Greg Troxel: > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
