[Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

[Minh Nguyen]

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

-- 
minh at nguyen.cincinnati.oh.us