Proposed features/ele with units

From OpenStreetMap Wiki
Jump to navigation Jump to search
ele with units
Status: Proposed (under way)
Proposed by: Minh Nguyen
Tagging: ele=*
Statistics:

Drafted on: 2021-11-29
RFC start: 2021-12-03

Proposal

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]

ele:ft=* should be deprecated in favor of ele=*', since there only needs to be one key for elevations expressed in feet.

Rationale

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.[1] In parts of the western U.S., unnamed peaks are commonly identified by their elevation in feet.[2][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.[4] 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.[5][6]

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.

Examples

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:

  • The U.S. National Flood Insurance Program posts high water marks indicating an elevation in decimal feet.[7]
  • Oswatomie, Kansas, posts its elevation as 10,428 inches (869.0 ft) on welcome signs.[8]

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]

Rendering

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
openstreetmap-carto yes Hidden[9] Hidden[9] height=* values in feet are recognized, even though waterfall heights are labeled in the same manner as peak heights.[10] 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.
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 partial no no Discards the unit and interprets any number at the beginning of the value as meters, truncating any decimal digits before converting to feet.[11]
OpenTopoMap yes yes yes Displays the value verbatim.[12]
Organic Maps yes yes[13] yes[13] Converts all values to feet.
OsmAnd yes yes yes Displays the value verbatim.
Planetiler partial no no Per OpenMapTiles, discards the unit and interprets any number at the beginning of the value as meters, then converts to feet.[14]
TopOSM yes yes yes Converts unqualified values from meters to feet.[15]
Waymarked Trails yes
?
yes[16]

Pages affected

Features affected

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:

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.

Notes

  1. 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.
  2. 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.
  3. For example, Peak 13,762 in the Colorado Rockies is at an elevation of 13,762 feet (4,195 m) NGVD 29.
  4. Some mappers have experimented with generating a digital elevation model (DEM) from ele=* tags to spot local deviations.[3] However, this process is expensive and manual, and deviations would be more difficult to spot in rugged terrain.
  5. 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.
  6. Officially discouraged but still common.

References

  1. Friedl, Steve (March 25, 2015). “Elevation in local units”. talk-us mailing list. 
  2. “Message in #random”. OSMUS Slack. September 7, 2017. 
  3. “Thread in #random”. OSMUS Slack. October 31, 2021. 
  4. SK53 (December 27, 2018). “imperial units silently removed from ele tag”. iD. 
  5. Thompson, Mike (September 7, 2017). “Elevation in Feet as part of Peak Names”. tagging mailing list. 
  6. Thompson, Mike (March 7, 2019). “Spot elevations collected as natural=peak and name=Point (height in feet)”. talk-us mailing list. 
  7. “High Water Mark: Be Flood Aware”. City of Roseville. Roseville, California. Retrieved November 29, 2021. 
  8. 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. 
  9. 9.0 9.1 “project.mml”. openstreetmap-carto. September 22, 2021. line 1,483. Retrieved November 29, 2021. 
  10. meased (April 6, 2018). “Add rendering for waterway=waterfall”. openstreetmap-carto. Retrieved November 29, 2021. 
  11. “aerodrome_label.sql”. openmaptiles. September 11, 2021. lines 55–56. Retrieved December 2, 2021. 
  12. “Boxcar Rock”. OpenTopoMap. Retrieved December 2, 2021. 
  13. 13.0 13.1 “osm2meta_test.cpp”. Organic Maps. April 9, 2020. lines 23–28. Retrieved December 3, 2021. 
  14. Nguyen, Minh (May 17, 2022). “[BUG Elevations in feet are misinterpreted as meters”]. Planetiler. Retrieved May 17, 2022. 
  15. “import_planet”. TopOSM. September 1, 2011. lines 89–90. Retrieved December 2, 2021. 
  16. “test_guidepost_table.py”. waymarkedtrails-backend. December 28, 2020. line 46. Retrieved November 29, 2021. 

External discussions

Comments

Please comment on the discussion page.