While parsing OSM globally for peaks, mountain passes and similar features, I noticed quite a few ele=* values that are clearly understandable but don’t follow the documented format.
So I’m wondering whether a narrowly defined mechanical cleanup such as:
ele=<number>m → ele=<number>
would generally be considered acceptable.
If so, I’d be interested in discussing further cases one by one, with an exact rule for every transformation rather than using a general “smart” parser.
For example, possible candidates could be:
590 m → 590
590m → 590
960 meter → 960
30 metros → 30
731米 → 731
1726.0м → 1726.0 (edited)
At the same time, I would explicitly not touch cases where interpretation is ambiguous or the value has additional meaning, for example:
1.331 m - decimal or thousands separator?
2,337 - same problem
500-750 - range
~1720 or 925? - approximate/uncertain
82 m (Summit 230 m) - multiple different elevations
values in feet - separate question
unrelated text, coordinates, phone numbers, opening hours, etc. accidentally stored in ele=*
So the idea would be a small set of individually discussed, deterministic normalizations, not trying to infer what arbitrary malformed values “probably mean”.
Would this be a reasonable kind of mechanical edit? And if yes, does discussing additional patterns one by one sound like the right approach?
How many of those sort of results are you seeing? Because it’s pretty obvious, as soon as you look at the map, as to whether a spot is virtually at sea level, or way up in the mountains!
Definitely do not convert values mapped in feet into meters – this is a verifiability problem because often the values are taken from an official source published as feet with some particular rounding process, and a conversion to metric destroys any rounding hints.
Why store the conversion in OSM at all? If it was an obscure unit (e.g. the measurement unit is the ell, as used in Saxony in 1758 (not to be confused with the ell used in Cologne)), then maybe you could make the case that it’d help data consumers, but if it’s just one extra unit with a known and straightforward conversion (the modern foot), consumers will likely find it easier to multiply by 0.3048 than to hope that someone added ele1 to OSM
Is there a recommendation to not enter ele values with decimal points? Otherwise, why don’t you change it to 1726.0? This would retain the current accuracy.
If I see ele=30.26697921752931, I’m going to assess if it was originally measured in feet. The equivalent would be ~99.30111291840325 feet - again an unlikely number. I’m then going to assume it is someone using misguided precision. I’m NOT going to assume they measured a mountain to an accuracy of one side of an atom or the other.
Another interesting point: The plans of the village Weiskirchen to increase the Schimmelkopf with a lot of gravel to reach the 700 metres would be futile because that doesn’t count
There’s a verifiable difference between the tenths or hundredths place versus enough decimal places to make the IEEE cry foul. It’s the difference between a wrist altimeter and a scanning electron microscope.
Many of the fractional meter elevations and heights come from building imports where the source used a digital elevation model for the elevations and LiDAR for the heights. In San José, the elevations in meters can range from single digits to the hundreds place. The source probably needed some extra precision to assess flood risk or to convert more reliably to feet, though maybe not quite this much.
More rarely, the precision is on the signs:
Of course, this precision is easily outweighed by uncertainty about the datum or even the location used to make the measurement. But that’s a general caveat to ele=*, which is for informational purposes, at most for gently landing an aircraft on the roof of a shelter atop a peak in flight sim.
Thanks for posting the code. A couple questions from glancing at your readme:
You’ve identified 75 elevations that indicate the datum. Even if the datum appears to be redundant to the norm, maybe it would be helpful to preserve this information for future reference, in case there’s any question as to the elevation’s determination method. There have been some ideas for recording the datum. They never went anywhere, but at least you could stick it in a note:ele=* tag or something to that effect.
There’s a suggestion that ele=* is the wrong key for elevations in feet and that this information should go in ele:ft=* instead. Did you arrive at this conclusion from the ele=* documentation or something else? Previous discussions have turned up significant support for allowing unit specifications in ele=*. This is already the longstanding undocumented status quo. Although ele:ft=* is slightly more common, that key is a failed tagging idea. A nontrivial number of occurrences are significantly out of sync with ele=*. The problem has only gotten worse since the issue was first raised more than five years ago. If you want to avoid taking a position on elevations in feet, also avoid setting unrealistic expectations about ele:ft=*.
can you share also which ele value will be after your edit? For some at least it is unclear how fully automated process can reliably transform it (say ele=233;272)
thank you for pointing out the case in the datum. After some more research, it seems that not all can be converted to EGM96 goid model, which OSM uses. So, the discussion is if it would still be good enough - my take is that it probably isn’t.
Convertible (lat/lon + EPSG grid):
m ü NN / m NN / mNN, German Normalnull: 6
NHN, German Normalhöhennull: 0 here
m NGF, French IGN69: 1
m ü. A., Austrian Adriatic: 1
m ü. M. / m.ü.M, Swiss: 2
Not convertible:
LAT: 1. Needs tide model
自高潮面起算: 1. Needs tide model
Generic (msnm 54, slm, masl, m s.n.m., n.p.m., mdpl, dpl, snm, above sea level, plus 16 more spellings): 112. No source datum named, nothing to convert
Caveats: corrections are decimetre scale on integer metre values; EGM96 is coarser than the national datums. We will create digits after the dot, possibly suggesting precision.
Regarding Feet: I did not want to start messing with it as there is an ongoing discussion. I guess we should act based on the bigger picture.
ele=233;272 - This case is excluded (see the multi-value case in picode7/osm-normalize), as I don’t see how it can be fixed.
It would be interesting to discuss such cases, as I’m not 100% clear what they mean. My best guess is that we see two values for the two gnis:feature_ids of the Node: Fairmount (158842673). Digging deeper you can find a page that has an elevation of 234 meters. Other cases might be easier to debate.
It would be possible to build an LLM-Assistant that suggests linked evidence (if available), so that humans can quickly manually review it. I open to discuss this approach further
I agree. Just make sure that, if any dashboard or report mentions these foot cases, nothing in the documentation leads a mapper to think there’s anything to do to it at the moment. My concern comes from a suggestive passage in the readme. We don’t want to inadvertently exacerbate the problems of dataloss or conflicting data. We’ll probably need to update the ele=* documentation with some words of caution as well.
