Proposal:ele with units
|ele with units|
|Proposal status:||Proposed (under way)|
|Proposed by:||Minh Nguyen|
The wiki should acknowledge the fact that ele=* can be tagged in a unit other than meters. This key should formally accept an elevation expressed in any of the documented height units, as long as the unit is explicitly specified as part of the value. If no unit is specified, the value would be interpreted in meters. This is a change from the key's current definition according to the wiki, which requires the value to be implicitly in meters only. With this change, mappers would be allowed to use the predominant local unit for elevation, i.e., feet in the United States.[note 1]
A mapper who lives in the United States would intuitively expect to provide elevations in feet. This is the standard elevation unit used everywhere, including on signposts.[note 2] Meters are used only in some technical contexts, but it is even common for terrain maps to label peaks and contour lines in feet. In parts of the western U.S., unnamed peaks are commonly identified by their elevation in feet.[note 3] Some landmarks outside the U.S. have also retained signposted elevations in feet for historical reasons; perhaps this choice is notable enough to state explicitly in a tag.
Almost every key indicating a measurement accepts values in non-metric units as long as they are specified using a unit symbol. For example, height=*, maxspeed=*, maxweight=*, and maxheight=* all accept alternative units. However, Key:ele inconsistently specifies that the value must be expressed as a bare number in meters and suggests using ele:ft=* for elevations in feet and inches. Back when ele=* was first proposed as one of OSM's first measured keys in 2007, before there was a significant U.S. mapping community, there was a strong notion that tag values should be as structured as possible, which meant a normalized floating point number without any other complications. For several years, mappers and some imports manually converted maxspeed=* and maxweight=* to SI units, but at some point the consensus shifted in favor of using the local units where appropriate, and those keys have since been migrated to the local units. This makes the last remaining holdouts, ele=* and depth=*, even more surprising to mappers.
Mappers aware of the potential confusion can manually convert unlabeled feet measurements to meters, but these errors are difficult to find using standard tools.[note 4] Manual conversion can also introduce precision errors. Some editors let the user select the unit from a list of valid units, but for ele=* they can only accept a pure number, which leads to confusing behavior. A sophisticated renderer or editor could localize units on the fly to match signs and local expectations, but it could also introduce rounding error or get the significant figures wrong in the process. Some mappers have worked around this constraint by setting name=* to spot elevations in feet.
The parallel ele=* and ele:ft=* keys can introduce internal inconsistency. For example, this peak is both 948 feet (289 m) and 216 meters (709 ft) tall, and this peak is both 69 feet (21 m) and 69 meters (226 ft) tall.
Here are some examples of changes that could take place based on this proposal based on the on-the-ground principle. By itself, this proposal does not mandate any immediate changes to existing data, but local communities could decide to undertake these changes:
Lewis Pass, New Zealand:
- The U.S. National Flood Insurance Program posts high water marks indicating an elevation in decimal feet.
- Oswatomie, Kansas, posts its elevation as 10,428 inches (869.0 ft) on welcome signs.
Some of the "old" values in these examples do not match the actual tagging in OSM because elevations were imported from a source based on a different vertical datum or reference ellipsoid than what's signposted. These nuances are out of scope for this proposal.[note 5]
This proposal is motivated by mapper experience and quality assurance rather than final rendering. Depending on the use case, a renderer may normalize all elevations to either feet or meters, potentially dynamically based on a user preference. It may indicate the unit as part of the label, in a legend, or not at all, based on the user's expectations.
ele=* is a longstanding key, so many renderers have been using it, some with baked-in assumptions about the value format. For example:
|Renderer or tileset||ele=###||ele=###'||ele=### ft[note 6]||Notes|
|Mapbox Streets source||yes||yes||yes||Recognizes all the acceptable length units, even nautical miles, converting them to meters and feet in separate fields.|
|OpenMapTiles||yes||yes||yes||Converts values to feet and indicates whether to display the value in feet or meters according to local custom.|
|OpenStreetMap Carto||yes||Hidden||Hidden||height=* values in feet are recognized, even though waterfall heights are labeled in the same manner as peak heights. Temporarily leaving unlabeled any elevations in feet is suboptimal but not as disruptive as the poor routing that occurred while maxspeed=* was transitioning to miles per hour.|
|OpenTopoMap||yes||yes||yes||Displays the value verbatim.|
|Organic Maps||yes||yes||yes||Converts all values to feet.|
|OsmAnd||yes||yes||yes||Displays the value verbatim.|
|Planetiler||yes||yes||yes||Recognizes all the acceptable length units, even nautical miles, converting them to meters and feet in separate fields.|
|TopOSM||yes||yes||yes||Converts unqualified values from meters to feet.|
- Key:ele: replace the SI-centric language with standard language about units; mark ele:ft=* as deprecated
- ele (Q250): remove the qualification "in meters" from the description
- ele:ft (Q3242): set status (P6) to deprecated (Q5061) and replaced by (P17) to ele (Q250)
- Tag:natural=peak#Description: remove the qualification "in metres" from the description of ele=*
- Tag:information=guidepost#How to map: remove the qualification "in metres" from the description of ele=*
- Tag:natural=saddle#Usage: remove the qualification "in metres" from the description of ele=*
- Tag:natural=volcano#Tags to use in combination: remove the qualification "in meters" from the description of ele=*
- Tag:man_made=tower#Optional tags: remove the qualification "in meters" from the description of ele=*
- Map features#Properties: remove the qualification "in metre" from the description of ele=*
- Map features/Units#Unusual keys: remove the exception about ele=*
- OpenRailwayMap/Tagging#Stations / Stops: remove the qualification "in metres" from the description of ele=*
- US National Park Service Tagging: Points of Interest: remove the warning about meters from the description of ele=*
- Osmose/issues#Missing tags: remove the qualification "in meters" from the description of ele=*
- Overpass API/Overpass API by Example/QA Tool Overpass Queries: remove the qualification "in meters" from the description of ele=*
By itself, this proposal does not mandate any immediate changes to existing data, but local communities could decide to convert elevations to the appropriate units (after researching the provenance of any imported data). As of December 2021, some 1,400 features are tagged with ele=* in feet and/or inches using various formats, while 2,300 features are tagged ele:ft=* (which would be deprecated).
Metric elevations predominate in the United States, where elevations in feet would be most relevant: of the 5.1 million features tagged with ele=*, only 835 are tagged with explicit feet or inches, while 1,700 are tagged ele:ft=*. Some other keys like ele:note=* are also sometimes used to indicate the elevation in feet. As discussed above, it is unknown how many additional features are tagged with elevations implicitly in feet.
Of the 5.1 million features tagged with ele=* in meters, at least 4.9 million were imported, including:
- 2,877,694 from a building import in Los Angeles 
- 918,961 from the GNIS import 
- 519,793 from a building import in Portland, Oregon
- 443,445 from a building import in Connecticut
- 189,695 from a building import in San José, California
Again, these features would not necessarily change from meters to feet. These figures are provided to allay concerns about changing the meaning of something that superficially is very commonly mapped in a different manner.
- For the most part, the only new format would be ####.#' for elevations in feet, but other units like ####'##.#" for feet and inches would also be syntactically valid for some rare signs.
- The elevations of peaks, mountain passes, populated places, and railroad stations are typically signposted in many regions. In the U.S., the vast majority of peaks and populated places are already tagged with ele=*. This proposal would only affect how the elevations can be tagged, not whether they are tagged.
- For example, Peak 13,762 in the Colorado Rockies is at an elevation of 13,762 feet (4,195 m) NGVD 29.
- Some mappers have experimented with generating a digital elevation model (DEM) from ele=* tags to spot local deviations. However, this process is expensive and manual, and deviations would be more difficult to spot in rugged terrain.
- There are multiple separate proposals and ad-hoc tagging schemes for more or less specific frames of reference, including ele:wgs84=*, ele:local=*, and Proposed features/ele:regional.
- Officially discouraged but still common.
- Friedl, Steve (March 25, 2015). “Elevation in local units”. talk-us mailing list .
- “Message in #random”. OSMUS Slack. September 7, 2017 .
- “Thread in #random”. OSMUS Slack. October 31, 2021 .
- SK53 (December 27, 2018). “imperial units silently removed from ele tag”. iD.
- Thompson, Mike (September 7, 2017). “Elevation in Feet as part of Peak Names”. tagging mailing list .
- Thompson, Mike (March 7, 2019). “Spot elevations collected as natural=peak and name=Point (height in feet)”. talk-us mailing list .
- “High Water Mark: Be Flood Aware”. City of Roseville. Roseville, California. Retrieved November 29, 2021.
- Carder, Doug (May 13, 2021). “‘If inches could only be feet, we would beat Aspen, Colorado.’”. The Miami County Republic. Paola, Kansas. Retrieved November 29, 2021.
- “project.mml”. openstreetmap-carto. September 22, 2021. line 1,483. Retrieved November 29, 2021.
- meased (April 6, 2018). “Add rendering for waterway=waterfall”. openstreetmap-carto. Retrieved November 29, 2021.
- “Boxcar Rock”. OpenTopoMap. Retrieved December 2, 2021.
- “osm2meta_test.cpp”. Organic Maps. April 9, 2020. lines 23–28. Retrieved December 3, 2021.
- Nguyen, Minh (July 1, 2023). “Elevations in feet are ignored”. tordanik/OSM2World .
- Nguyen, Minh (May 17, 2022). “[BUG] Elevations in feet are misinterpreted as meters”. Planetiler. Retrieved May 18, 2022.
- “import_planet”. TopOSM. September 1, 2011. lines 89–90. Retrieved December 2, 2021.
- “test_guidepost_table.py”. waymarkedtrails-backend. December 28, 2020. line 46. Retrieved November 29, 2021.
- Talk:Key:ele#Feet and inches (September 2021)
- “Thread in #tagging”. OSMUS Slack. November 28, 2021 .
- Nguyen, Minh (December 2, 2021). “Feature proposal - RFC - ele with units”. tagging mailing list. Retrieved December 2, 2021.
- Nguyen, Minh (December 2, 2021). “Feature proposal - RFC - ele with units”. talk-us mailing list. Retrieved December 2, 2021.
- “Message in #proposals”. OSMUS Slack. December 2, 2021 .
Please comment on the discussion page.