[Tagging] RFC ele:regional

[Greg Troxel]

Mark Wagner <mark+osm at 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.