This is the first time I’ve learned of a niche topic before seeing the relevant xkcd! Thanks for granting us this nerd cred, @Minh_Nguyen!
2 Likes
Forgive me, I’m not particularly familiar with the proposal process, but it seems like there hasn’t been discussion about this in a few months. Where does this proposal stand? What are the next steps?
Thanks for inquiring, I’ve been sidetracked on a number of other projects, as usual, but we should get this over with. I’ve added an FAQ based on feedback I received during the two RfC periods. I’ve also implemented a unit field for ele=* in id-tagging-schema, which will propagate to most of the major editors:
Does anyone have unaddressed comments or concerns before I put it to a vote?
3 Likes
Thanks for everyone’s patience so far. I’m still trying to come to a resolution on one or two pieces of feedback that people have left on the proposal’s talk page. I won’t be able to make some of the commenters completely happy, short of killing the proposal, but I’ll do what I can within the goals of this effort.
2 Likes
Thanks for your work on this!
3 Likes
Just bumping this yet again; what’s left to do to make this happen?
Is there still enough resistance to letting Americans use their feet 
to prevent this from happening, or is this still in the works?
Sorry for the delay. There’s still one discussion on the talk page that’s unresolved, and I’m not sure if I can resolve it satisfactorily. Despite their call for compromise, there’s actually very little room for compromise, because the proposal doesn’t really change the status quo, just some words on a wiki page. It’s clearly a touchy subject for reasons that I can’t really relate to. 
2 Likes
Here’s your obligatory “It’s been yet another couple months” bump. I know one can’t make all the people happy all of the time, but are there substantive objections that this shouldn’t happen?
To be honest, I haven’t given the proposal much thought over the past couple months. Been too busy arguing about paths on the forum, I suppose.
The one lingering point of contention has been the choice to deprecate ele:ft=* in favor of the unit suffix. In my view, ele:ft=* is part of the problem, because it allows a significant number of features to have internally inconsistent elevation information. When wikipedia=* and wikidata=* disagree, we can easily figure it out manually or using automated tools, but when ele=* and ele:ft=* disagree, we often can’t trust either tag and have to start from scratch.
However, the criticism is that it’s unfair to expect global data consumers to write a special case to deal with the units common in the U.S. I sympathize with that standpoint but find that, by and large, data consumers have already done so or are ready to do so, pending this proposal. It’s ele:ft=* that would require special effort. Anyways, the impact of not supporting ele=* in feet is pretty minimal compared to labeling a wildly inaccurate elevation.
2 Likes
I could certainly understand people not wanting to deal with US units, I’m just not understanding why one would want to treat ele any different than one already needs to treat maxspeed, maxheight, and so forth, which all would require being able to deal with multiple units. Is it that there are more consumers (like renderers) that look at ele but just don’t happen to look at other fields that have units on them?
2 Likes
This is certainly the case for renderers - it makes sense to show elevations of peaks etc., but I can’t think of a renderer that shows/parses maxwidth, maxheight, maxspeed data. Some routers clearly deal with non-metric data, e.g. maxspeed in the UK is always entered as 60 mph etc. But then most routers aren’t interested in ele.
A glance at taginfo finds a few say they do. Parsing these values is a thing that happens (in fact, surely every router will parse maxspeed?).
1 Like
What makes ele=* special is that it’s such an old key. After all, if we had coined the key today, we would call it elevation=* instead of abbreviating it. (It was probably named after the lat and lon attributes in OSM XML or GPX.) By the time the conventions for maxspeed=*, maxweight=*, height=*, etc. changed to allow unit suffixes, I guess no one really wanted to touch ele=* because it was more visible than the other keys.
For some feature types, rendered maps have been labeling elevations based on ele=* and heights based on height=* long before any router figured out how to adjust a time estimate for maxspeed=* or present it to the user. A software developer would be very tempted to pass through a simple numeric field verbatim rather than doing any parsing or formatting. But I can’t explain why ele=* is treated differently than height=*, even by OSM Carto, other than this history.
For better or worse, any renderer that cares about elevations does need to care about the U.S. The vast majority of tagged elevations are in the U.S., due to the local community’s penchant for bulk imports and the prevalence of elevation signs in some parts of the country, even where they make no sense. This isn’t to say that a renderer must ultimately show feet to the user. That would be a stylistic choice, akin to OSM Carto’s choice to use the English decimal separator, regardless of the local language.
Yes, to the extent that routers understand maxspeed=*, they all recognize unit suffixes rather than assuming kilometers per hour. To the extent that navigation systems also present the speed limit to the user – which is a kind of map data rendering – most have the option to show miles per hour depending on the user’s language or the current location.
With this key, too, global data consumers humbly acquiesce to regional quirks like maxspeed=none on the Bundesautobahnen. After I special-cased those highways to show “∞” to the user, I got quite a bemused reaction from customers in that part of the world. Sadly, this Easter egg has since been replaced by a more appropriate Vienna Convention sign.