Mark Wagner <mark+...@carnildo.com> writes: > What about regions where two or more reference systems are in common > use? If I copy an elevation from a USGS benchmark and put it in > "ele:regional", how does an end-user know if it's a recent benchmark > measured in NAVD 88 or an older benchmark measured in NVGD 29?
They don't, and this is why doing what you ask about is a bad idea. (I realize you are asking a mostly rhetorical question.) The right thing to do is one of 1) transform the elevation from whichever system it is in to WGS84 height above geoid. This is after all what we do with horizontal coordinates -- it is not acceptable in OSM to store coordinates in some random datum that is not WGS84, and then make up extra tags to pretend that's ok. 2) Use ele:datum=unknown as a clue that the data is not that high quality. 3) Look up the data sheet and mark it as ele:datum=NGVD29 or ele:datum=NAVD88 as it turns out. Keep in mind that this 'on the ground' verifiability notion is taken to crazy extremes, and that looking up a height in a database is just as legit as reading it off the disc. The physical discs are after all merely a distributed database. If you are encoding "this disc says X", then you are reporting a fact you see with your eyes. But once you report "the elevation of this disc is X (because it said so)", then you are making assumptions and *you have not actually verified* what you are putting into OSM. In particular you have not verified it any more than looking it up in the NGS databse, and arguably you have verified it much less. The next question is: If I just put a height that might be NGVD29 or NAVD88 into the db as ele, where it is interpreted as WGS84 heigh above geoid, what harm is done, and who suffers that harm? and I would say "close to zero, and anybody who is upset is welcome to look up the datasheets, transform precisely, and adjust the values in the osm db, just like anybody who finds nodes that are not placed correctly in horizontal coordinates is welcome to move them to better places". Not addressed at Mark, but I find the insistence that we have a real problem to be hard to understand. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
