RFC: Documenting feet as an an optional elevation unit

General talk Tagging general discussion
, ,
1

This is a second RFC for formally condoning the use of feet in the ele=* key. This is essentially a proposal to edit the wiki to reflect the status quo in the database. It is not about retagging. Normally, edits to the wiki don’t go through the formal proposal process, but I recognize that this change would surprise some in the international community, so the proposal is intended to keep the community informed.

Since it’s been a while since the first RFC, I’m taking the opportunity to retell some of the story behind this key, but you can go to the proposal for the full rationale.

Background

Maps of the U.S. almost always label elevations in feet, not meters. In the more rugged parts of the country, elevations in feet are strongly associated with populated places and peaks (to the extent that many peaks are named after these values).

ele=* is one of the oldest keys in OSM, from back in the days when apparently we thought it was a good idea to abbreviate the word “elevation” to match the lat, lon, and ele attributes in the GPX file format. As in that standard, ele=* was approved to mean the altitude in meters only. However, this was back in 2007, when there was hardly a U.S. community to speak of. Even those who were mapping in the U.S., including myself, assumed that keys like maxspeed=*, maxweight=*, and height=* should always be expressed in metric units so that data consumers could perform the conversion back to customary units on the fly.

After years of fighting against surprisingly incorrect values, we changed our minds and began tagging customary units like mph and '…" (feet and inches) explicitly in most keys. However, we never got around to updating the documentation for the ele=* key, so it along with depth=* stand out as the only two measurement keys that require mappers to hard-code converted values. Yet, in practice, plenty of features have elevations tagged in feet.

In 2021, I wrote a proposal to reword the documentation to acknowledge other explicit units, as we did for the height=* and maxspeed=* keys. I got some good feedback in the RFC but put it on hold out of concern about compatibility with OpenMapTiles and a lingering rivalry between the international foot and the U.S. survey foot. (Yes, even when these non-international units get standardized internationally, we still find a way to do things differently…)

Since then, the situation has improved somewhat. Apparently OpenMapTiles is actually handling feet just fine. Meanwhile, the U.S. survey foot has finally been deprecated at the national level in favor of the international foot. (The survey foot continues to have official status in some states, for purposes that shouldn’t affect us.) Elevations in feet continue to be tagged, whether explicitly or implicitly. These values surprise some international users because of the lack of documentation.

Proposal

  • Document that ele=* can be expressed in feet, but only if the unit is indicated explicitly.
  • Deprecate ele:ft=* in favor of ele=*.

Anticipated impact

ele=* is almost exclusively used by renderers. This table shows that the impact to renderers would be negligible overall, even if we were to systematically retag all the peaks and other features in the U.S. from meters to feet (but that is not what I am proposing). If you know of another tile schema or stylesheet that specifically processes elevation and covers the U.S., please add it to the table, or let me know and I can investigate further.

Nothing uses ele:ft=*.

In practice, there should be no effect on mappers outside the United States. Retagging is out of scope for this proposal. Local mapping communities can still decide for themselves whether meters or feet is more appropriate for elevation, just as they can with other measured keys.

Thank you in advance for your feedback. I will be watching both this topic and the proposal’s talk page for responses.

19 Likes
2

Crossposted to the tagging mailing list.

1 Like
3

From a mapper ↔ data consumer point of view, this makes it slightly easier for mappers who now do not have to do unit conversion, and slightly harder for data consumers who must now do unit parsing.

2 Likes
4

This is an accurate statement about human-readable tags in general. However, from what I can tell so far, most relevant data consumers are already parsing ele=* as something other than a bare number. It’s convenient for most of them because of all the other keys that also accept units. It’s also a lot less error-prone for a handful of data consumers to implement the parsing and conversion code than for many mappers who don’t routinely use metric units to perform the same conversion manually each time they encounter this key.

3 Likes
5

The table shows for OpenTopoMap “displays the value verbatim”.

If I interpret the following post correctly, the ele tag is also used to calculate the dominance of mountain peaks.

6

On opentopomap the literal content of ele is displayed, regardless of units or whether there is anything that can be interpreted as a number at all.

For the calculation of the isolation, it does not matter whether you write “1000”, “1000m” or “3280.8 ft”. There just has to be any number (with a maximum of one point or comma as a decimal separator, no separation for thousands such as “1.000,4” instead of “1000.4”, please) and either no unit (is interpreted as metres) or ft or m as a unit. Apostrophes (3280.8’) are not interpreted (interpretation is done in this function)
If “ele” cannot be interpreted, the height is estimated from the DEM.

7

I’ve completed the info for waymarkedtrails. ft and ' work both fine.

From a data user POV, I very much prefer elevations entered in the originally available unit because it is surprisingly hard to convert a value of “304.8” back to its original “1000 ft” without running into rounding issues.

12 Likes
8

Even though I personally would prefer the world (and OSM) to be completely metric, this seems like a useful and reasonable proposal for mapping in the United States and associated territories. As long as the proper unit is indicated in the value, having more accurate data that is easily consumable is always welcome.

3 Likes
9

While it should improve the dataset a little bit going forward, I doubt it will make a big difference.
Someone who is putting in a feet figures into a metric field without notice, will not be aware - or would not care - to add “ft”. The only proper way would be to run the database and new ele entries against a DEM for +/-60 degree and flag those witha quotient of 3.1 to 3.5 automatically. And bouncing back a message to the authors to educate them - as politely as you chose.
What also would help is to improve the entry OSM entry page (I suppose JOSM and level0 users are technical and educated enough to understand the metric base of the dataset): for all fields with metricc ambiguity add a warning, to either enter the metric valuenor add a qualifier like ft, mph and alike. So nobody can claim ignore anymore. Currently the definition is hidden behind the “i” button, which people typicaly do not care about.

10

In iD, which I think is what you’re referring to as the “entry OSM entry page”, it currently shows “Elevation (meters)” for the entry:

id Elevation Interface
id Elevation Interface844×730 19.8 KB

Whereas for other things I’ve seen, such as the speed limit (maxspeed=), it shows the unit explicitly, and (at least in my locale) defaults to mph as I would expect. So when I was adding a few speed limits around town the other day, I just needed to put in the number that was on the sign and it defaulted to putting the " mph" as the unit in there for me.

id Speed Limit
id Speed Limit844×186 2.97 KB

I assume that if this proposal becomes popular, iD may end up doing something similar for elevations.

6 Likes
11

Out of curiosity, when do you encounter ele data with nice round numbers? The elevation of natural lakes and summits generally have no preference for round numbers in any set of units.

12

You are right, Peter, I must have been a bit blind, sorry.

One the other hand - what does this tell about people entering feet values into such a field … ?

13

To me, it says that they’re normal people who, like most normal people in the U.S., normally only think in terms of customary units. User education is important, but I’d rather save my breath for more important matters, like keeping bboxes small. :wink:

3 Likes
14

Just depends on the precision of your data. If you have a source that is accurate to inches or single digit cm, that would be what you would like to enter.

For very high and remote places, like the highest mountains and the the lowest deeps, the value is even specified to single digit meters with an uncertainty that can be several dozens of meters.

For locations very close to a known or to sea level, tenths of meters and less could make a big difference. For example in Japanese costal areas, the local elevation is marked out on streets in resolution of 10 cm, and in Venice, a few centimeters may make a difference if a place gets flooded on a regular basis or stays dry.

2 Likes
15

Can’t iD just add the unit selector to the input box, defaulting to meters?

Would you summarize the remaining opposing points of view?

16

It could, but if you then select feet, it would have to automatically convert the existing value from meters to feet and then convert your input from feet to meters. There is a potential for conversion error in both directions, depending on precision. This is one reason why editors didn’t offer a similar UI for other dimensional fields back when we used to insist on kilometers per hour in maxspeed.

The only outright opposition I’ve seen so far, during the previous RFC, was based on concern about mass retagging. Hopefully I’ve allayed this fear by clearly stating that the use of an alternative unit is an option only. The same respondent was concerned that renderers would have to parse and convert units instead of displaying values verbatim. However, as noted earlier, most renderers already parse units. Besides, any renderer aimed at an American audience would have to convert any metric values to feet anyways, if not globally then at least when viewing the U.S., where even non-English speakers use customary units for most purposes.

Otherwise, most feedback has been receptive, with reservations that go beyond the scope of this proposal. Multiple respondents have noted that the ' symbol is not as noticeable as the deprecated ft symbol. I agree that this is unfortunate, but I would prefer that we address the issue separately as part of the more general Units page. It might need not to go through a formal vote, since no unit symbol ever has, and most data consumers already understand both ' and ft interchangeably.

One respondent pointed out that non-numeric ele values are rare compared to ele:ft. I believe this to be an inaccurate assessment and am awaiting further information. They also expressed a preference for parallel ele and ele:ft keys, in order to better capture the mapper’s intent. While I think there’s some merit to this argument, it isn’t specific to elevations, and we’ve roundly ignored it when it comes to other dimensions, to the point that length measurements can be nested very deeply inside a conditional restriction tag, for example.

On the mailing list, there has been a lot of discussion about datums, but respondents have been quick to point out that the discrepancies between datums are a problem even for elevations given in meters. I am amused to see that my offhand remark about the U.S. survey foot has thoroughly nerd-sniped that group.

Hopefully that captures everything so far. I remain open to feedback for the remainder of this RFC period.

3 Likes
17

To underscore this point, I have in my collection a Strassenkarte of the western U.S., published in Bern for Swiss visitors to the States, that nevertheless displays elevations only in feet:

Grand Canyon National Park
Grand Canyon National Park1920×1440 372 KB
Zoll / Customs
Zoll / Customs1920×1440 202 KB

18

I do not see: from the moment this proposal gets approved, input is not just numerical with dimension added later on? Perhaps put dimension selector front, numerical input later?

19

Approving this proposal would enable iD to provide a quantity-and-unit field for ele like it does for some other dimensional keys. That is, it would provide the unit option but would not automatically convert between units. Without approving this proposal, the same UI would need to convert between meters and feet, because only meters can be stored in the raw tag.

2 Likes
20

I like to think Randall Munroe has been following at least one of the OSM communication channels:

2 Likes