Following up to myself, a few things I didn't have time to say last
night.
Once we accept that the base notion of ele= means WGS84 geoid height
(meaning the MSL sort of height), and that ellipsoidal heights basically
have no place in OSM, then:
0) The entire notion of looking at a sign on a mountain and believing
that is suspect. I certainly think it's fair to put in a sign object
with an inscription, as "there is a sign" is a fact. But on mountains
here, there is often some number in feet, and it's never clear whether
that's in NGVD29, or NAVD88. Often the number doesn't change much and
it doesn't matter. But a sign with a number without a datum has to be
taken with a huge grain of salt. (As I understand it, most countries
have a 20s-50s generation height system and an 80s/90s height system,
and many are moving to a 2020s height system.)
1) For this proposal to be considered, we need to have examples of how
different elevations are between "WGS84 altitude" and various national
height datums. In the US, the differences are at the meter or so
level. So while the ability to enter national datum heights without
losing accuracy is useful, there is complexity in use to trade off
against that. I suspect that differences from most other national
vertical datum to WGS84 are small.
2) As always, I am concerned that tagging discussions tend to focus on
what taggers want to represent and not be so concerned with how data
consumers uses the tags. Tags are after all a protocol that is
written by mappers and read by renderers, routers, etc. It's
therefore important that simpler data consumers get sensible answers,
and that mappers being less precise provide data that is not grossly
wrong.
Therefore, if we're going to represent this, I think we should say:
ele=<ELEVATION>
ele:datum=<DATUM_CODE>
where ELEVATION is some sort of "height above sea level", where the
main/primary datum is the WGS84/EGM, and if it is in some other datum
(e.g. NAVD88 in the US and I am seeing various other ones on the
list), then ele:datum denotes that datum. This means that if a mapper
just puts in an elevation, ignoring vertical datum, or if a renderer
ignores it then nothing terrible happens, just a meter or two of fuzz.
And, if the mapper is precise, and the renderer deals, then all is ok
with no loss of precision due to datum issues.
I'll also say that this alternate datum notion is irregular, in that we
expect horizontal positions to be transformed from national horizontal
datums to WGS84, and that putting in a tag to say that coordinates were
in some other datum would be, I think, considered madness. Instead, we
expect people to transform any such data to WGS84. (And we realize that
meter level shifts are not that important usually, because measurements
and source data is rarely that good.)
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
