Vào lúc 16:01 2024-01-27, Greg Troxel đã viết:
I would expect the proposal to give an example. It seems that one
would have a tag
ele=6288 ft
for Mount Washington (showing my East Coast bias).
Thanks, I added this to the existing examples [1], though the summit
sign unusually states the elevation in both units.
This proposal is using the ' symbol instead of the deprecated ft symbol,
but in practice almost every data consumer understands both symbols
equally. If someone feels strongly that ft would be less error-prone,
I'd encourage them to start a new proposal that would affect other keys
as well.
It would be good to explicitly state that in keeping with convention,
ft means international feet, perhaps with a parenthetical comment that
if someone meant US Survey Feet they would have written ftUS. Maybe
this is already documented.
As far as I know, no one has ever explicitly tagged a measurement in
survey feet (as opposed to a survey _on_ feet). As you point out, it's a
very small difference. I mainly brought it up because I didn't want to
have to simultaneously propose new unit symbols, which would require
developer intervention. Some imports have introduced very high-precision
values, but this is probably not a good practice to optimize around.
There is a much more serious problem in that few seem to understand
that elevation is only meaningful relative to a vertical datum. OSM
documents WGS84. Even fewer understand that this is a mess because
WGS84 is an ensemble containing a low-accuracy member
(WGS84(TRANSIT)), and that the only reasonable interpretation is that
data should be expressed in the most recent realization.
Further, WGS84's first height definition is ellipsoidal height, and
that simply is not elevation. Obviously elevation should be in "WGS84
Orthometric Height", which is what GPS receivers provide as elevation.
But elevations are not published in WGS Orthometric Height; they are
published in a national or regional datum which is pretty close, as
all datums at least roughly target a similar origin.
You can definitely count me among those whose eyes glaze over whenever
datums enter the conversation, as they always seem to when discussing
nationwide imports these days. I'm glad we have folks like you who get it.
Hopefully it's OK to leave these issues out of the proposal's scope; I
fear it would quickly sink the proposal because we don't have a very
good handle on the datums that have already been used all over the map.
We're only now starting to clean up incorrectly transformed GNIS
features and TIGER boundaries from, what, 14 years ago, to say nothing
of more recent imports.
Practically, people type in numbers from a sign, and this sign was
probably copied from some earlier sign, and may be in some ancient
datum, and may have been erroneous. This proposal has no bearing on
that, and that's ok.
Yes, I'm very much approaching this key from the perspective of
documenting what the world says about itself on the ground. More
mission-critical applications of this elevation data would have their
work cut out for them...
[1] https://wiki.openstreetmap.org/wiki/Special:Diff/2654695
--
[email protected]
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
