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!" _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
