Martin Koppenhoefer <dieterdre...@gmail.com> writes: > Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel <g...@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.) _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
