[Tagging] RFC ele:regional

[Peter Elderson]

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 <gdt at lexort.com>:

> Martin Koppenhoefer <dieterdreist at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20200504/154e00a3/attachment.htm>