[Tagging] RFC ele:regional

Kevin Kenny kevin.b.kenny at gmail.com
Fri May 8 14:58:24 UTC 2020


My thoughts - trying to be brief, I started writing a much longer
message, but it got disorganized fast:

1. ele=* should always be orthometric.

2. Datum may be supplied with ele:datum=*, defaulting to
'ele:datum=unknown'. Within the regions of the Earth where a datum is
valid, all the datums in common use agree to within a couple of metres
of each other. (Obviously, you wouldn't want to try to extrapolate
NAVD88 onto a different continent!) Accuracy at that level is good
enough for virtually all land and aeronautical applications. How many
elevations in OSM have been determined with precise division of
levels, or with a four-hour integration time on a survey-grade GNSS
station?

3. A key like ele:tidal=* should be considered for nautical uses,
because water depths and bridge heights in tidal regions are measured
relative to tidal elevations.

4. Tidal datum may be supplied with ele:tidal:datum=*. The values for
this key may the local tidal measurements of MLLW, MLW, LMSL, DTL,
MTL, MHW, LWD, MHHW. Default in North America should likely be
'ele:tidal:datum=mllw' because that's how bathymetry is tabulated here
- referenced to local Mean Lower Low Water. Other locales will likely
have other conventions.

Rationale for separate keys: Orthometric and tidal elevations may be
some metres apart, and there would likely be considerable confusion if
the two were to use the same key. (Consider the case of the Bay of
Fundy, where the tidal range is 16 m. Geoid height and MLLW will be
eight metres apart - try to compare 'ele:*' values!

Bridge heights and water depths are not elevations, but elevation
differences, and need further discussion. (How best to call out water
depths on inland waterways, or bridge heights above them?) The Wiki
doesn't appear yet to have a lot about bathymetry.

5. Height-above-ellipsoid COULD be tabulated as ele:ellipsoidal=*
(with datum required), I suppose - but I agree with Greg Troxel that
ellipsoidal elevation has no place in OSM. It's an intermediate
calculation, which we wouldn't be discussing on the 'tagging' list at
all if it were not for the fact that the Android location API
unfortunately exposes it. It's very often tens of metres off from the
actual surface of the sea. It cannot be displayed as anything that an
ordinary user would recognize as an 'elevation' without further
computation; data consumers ought not to be required to resort to such
computations merely to produce a map for popular use, as opposed to a
navigational chart. Since API's like the one to 'vdatum' generally
allow conversion between two arbitrarily chosen reference frames, it's
no more work for the programmer of a data consumer that needs precise
data to convert from the supplied datim than from the ellipsoid.

Those wishing to determine whether a building site is above 19-year
highest high water should really consult a competent engineer, and not
OSM. (Disclaimer: I am an engineer. In a different specialty entirely.
Choice of building site in a tidal region is entirely outside my
professional competence, and it would be unethical and illegal for me
to consult on such a project.)

Those piloting a vessel had better have charts from a competent
authority. For commercial vessels, there are legal chart carriage
requirements that OSM will likely never satisfy.

"Leadsman!" "And a quarter five, over a clay bottom!"



More information about the Tagging mailing list