[Tagging] RFC ele:regional

[Greg Troxel]

Martin Koppenhoefer <dieterdreist at gmail.com> writes:

> Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel <gdt at lexort.com>:
>
>> The notion of "local" has the same problem, and it is also a poor choice
>> of words in that in surveying, "local", refers to coordinate systems
>> established for particular projects or surveys that have no lasting
>> significance.
>
> the "definition" for "ele:local" (in German language on the English talk
> page of the tag) seems to be about this: a local datum based on a local
> reference (i.e. not the same as ele:regional). I am not in any way involved
> in ele:local, just wanted to point it out.

That does sound like what I mean by local.   I would say that heights in
such local systems should not be entered into OSM, and I would find
their use in anything tourist-facing to be very strange.

>> Basically, either you know what datum an elevation is in, in which case
>> you can 1) transform it to WGS84 height above geoid or 2) label it
>> correctly, or you don't know, in which case you should simply *admit
>> that you do not know*.

> ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.   In
contrast "ele:datum=unknown" is a crisp statement that you don't know
the datum, no more and no less.

As for guessing about regional, data consumers can guess too, but
encoding a guess in a vague way seems really unhelpful.

>> I would also ask: if this is reasonable for height, why isn't it also
>> reasonable for horizontal coordinates?
>
> because we typically have much more horizontal positional information with
> which we can compare. Errors in horizontal position are more evident
> because the relation to the surrounding (alignment, reference, angles,
> axis, proportions, etc.) won't fit. Up to a certain degree (e.g. when other
> information around is missing, and when accurate positional information is
> missing) we also do have and tolerate very approximate horizontal spatial
> information.

I'm talking about things like NAD83 vs WGS84, which is basically a 1m
difference around me.   We either transform or accept the fuzz, but it
would be crazy to label points as being in NAD83.  That's really my point.

> Greg, you wrote we should convert locally signed regional datum elevation
> information to the WGS84:geoid reference. In other context, we do not do
> unit conversions, for example we do not convert speed limits in mph to kph,
> nor do we convert weight information or maxheight information.

This isn't really about units.  Datum is about point of reference, and
the "don't convert" argument applies equally well to horizontal datums.

As I said before, if you want to put something like

information=board
inscription="Mount Washington // Elevation 6288 Feet"

that's totally fine.

> I could imagine doing a "reasonable" conversion (precision the same as
> expected from the original value) if there would be support from the
> tools (e.g.  mobile editors, iD or Josm), but otherwise I would not
> expect the vast majority of mappers doing this conversion at all in
> case of a value read off a sign, and even if they did I would expect
> this conversion step to be error prone (e.g. the mapper won't know
> which is the original datum).

I agree that casual mappers doing conversions is likely too much.

However, I don't see the harm in just entering a signed elevation in
ele= and not worrying about it, or also adding ele:datum=unknown to
represent that the data is not known to have been handled accurately.

My primary objection is not about having a tag to say the datum is
unknown.  What I really don't like is:

  the notion that it is a desired state to have elevations in other than
  the standard OSM datum, and that all data consumers should have to deal
  with this

  any notion that HAE is reasonable in OSM

  marking something as "regional" as if that is clear, when the reality
  is "unknown".  (If I come across a sign in the US with elevation, even
  I, as an elevation nerd, have no idea if it's NGVD29 or NAVD88, or if
  it's just plain bogus, with the number being copied from someone else
  who didn't really know either.)