Martin Koppenhoefer <dieterdre...@gmail.com> writes: > So the question is how we can solve this. We could discourage the use of > the "naked ele" and encourage to always use a more specific subtag, e.g.
But is there significant amounts of data that have ele as ellipsoidal height, more so than the prevalence of somewhat wrong data in OSM? If not, there is nothing to be gained from tag churn. > - ele:egm96= to mean ele referring to the EGM96 geoid Again this makes life difficult for data consumers. Plus it's EGM08 now, and approximately zero people are clear on which of these flavors they or any device are using. > - ele:wgs84= to mean ele based on the WGS84 ellipsoid (or maybe This is very confusing and therefore a bad idea. Elevation in WGS84 is obviously, to those who really understand height, intended to mean heigh above geoid. Nobody with the slightest respect for existing practice would ever use the word "elevation" to mean "height above ellipsoid". And, I don't think we should encourage HAE to be stored in OSM at all. > "ele:ellipsoid" which would imply the WGS84 ellipsoid?) Also very confusing, as in the US ellipsoidal heights are often relative to the NAD83 ellipsoid. However, people that use them are clear on what they are doing and they are labeled correctly. > and whichever height reference system is used, e.g. > - ele:dhhn92 > - ele:tm75 > and more: https://taginfo.openstreetmap.org/search?q=ele%3A > > - ele:regional for "I have no idea but it was written on a sign", could > still be a way to be expressive about the reliability. For many use cases > +- 50m is better than no information. We could also keep "ele" for this > like you suggested, although it wouldn't be explicit then. This really feels like solving a non-problem. If you just put what's on the sign in ele, and don't worry about it, that's ok. If somebody else actually makes a valid, hard-core measuremnt, and fixes it, even better. But this is just like having approximate horizontal coordinates - if a hotel is 10m off from where it should be, that's stil useful and somebody can and will fix it later. You still haven't articulated that there is a real problem to be solved, or made an argument that my proposal for ele and ele:datum is unsuitable. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
