Proposal:ele with units
| ele with units | |
|---|---|
| Proposal status: | Proposed (under way) |
| Proposed by: | Minh Nguyen |
| Tagging: | ele=* |
| Statistics: |
|
| Draft started: | 2021-11-29 |
| RFC start: | |
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:
Lewis Pass, New Zealand:
ele=907 (unchanged)
.jpg)
.jpg)
- 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]
Editing
As a result of this proposal, an editor will be able to present an Elevation field that lets the user select between feet and meters, defaulting to the locally relevant unit. Selecting feet can cause ' to be appended to ele=*. Since the quantity will not be converted from one unit to another, no conversion error would result. The author of this proposal is personally willing to implement this enhancement in both iD and Go Map!! once the proposal passes.
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 |
|---|---|---|---|---|
| Mapbox Streets source | yes | yes | yes | Recognizes all the acceptable length units, even nautical miles, converting them to meters and feet in separate fields. |
| OpenLandcoverMap | yes | Ignored[9] | Ignored | Developer is aware of the use of feet in the U.S.[10] |
| 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[11] | Hidden[11] | height=* values in feet are recognized, even though waterfall heights are labeled in the same manner as peak heights.[12] 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.[13] |
| Organic Maps | yes | yes[14] | yes[14] | Converts all values to feet. |
| OSM2World | yes | Ignored[15] | Ignored | Developer says adding support for feet would be "no problem". |
| 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.[16] |
| TopOSM | yes | yes | yes | Converts unqualified values from meters to feet.[17] |
| Waymarked Trails | yes | yes[18] | yes[19] | Converts all values to meters. |
Pages affected
The following pages will undergo minor modifications:
- Key:ele: replace the SI-centric language with standard language about units; mark ele:ft=* as deprecated
- ele (Q250): qualify "in meters" with "by default" in the description
- ele:ft (Q3242): set status (P6) to deprecated (Q5061) and replaced by (P17) to ele (Q250)
- Tag:natural=peak#Description: qualify "in metres" with "by default" in the description of ele=*
- Tag:information=guidepost#How to map: qualify "in metres" with "by default" in the description of ele=*
- Tag:natural=saddle#Usage: qualify "in metres" with "by default" in the description of ele=*
- Tag:natural=volcano#Tags to use in combination: qualify "in meters" with "by default" in the description of ele=*
- Tag:man_made=obelisk#How to map: qualify "in meters" with "by default" in the description of ele=*
- Tag:man_made=tower#Optional tags: qualify "in meters" with "by default" in the description of ele=*
- Tag:railway=halt#Tags: qualify "in metres" with "by default" in the description of ele=*
- Tag:railway=station#Tags: qualify "in metres" with "by default" in the description of ele=*
- Tag:tower:type=observation#Tags which be used in combination: qualify "in metres" with "by default" in the description of ele=*
- Template:Map Features:properties: qualify "in metres" with "by default" in the description of ele=*
- Map features/Units#Unusual keys: remove the exception about ele=*
- OpenRailwayMap/Tagging#Stations / Stops: qualify "in metres" with "by default" in the description of ele=*
- US National Park Service Tagging: Points of Interest: reword the warning about meters to note the ' symbol in the description of ele=*
- Osmose/issues#Missing tags: qualify "in meters" with "by default" in the description of ele=*
- Overpass API/Overpass API by Example/QA Tool Overpass Queries: qualify "in meters" with "by default" in the description of ele=*
The following pages will remain unchanged:
- Key:prominence#Tagging Errors: ele=* already documented as being in meters by default but accepting an alternative unit
- MUTCD/California/G: four signs already documented as using feet in ele=*
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 January 2024, 2,160 features are tagged with ele=* in feet and/or inches using various formats, while 2,661 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.2 million features tagged with ele=*, 1,733 are tagged with explicit feet or inches, while 1,992 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.2 million features tagged with ele=* in meters, at least 4.9 million were imported, including:
- 2,870,232 from a building import in Los Angeles [1]
- 900,223 from the GNIS import [2]
- 501,660 from a building import in Portland, Oregon
- 438,018 from a building import in Connecticut
- 215,802 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.
Notes
- ↑ 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.[3] 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.
References
- ↑ 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.
- ↑ “peaks.sql”. OpenLandcoverMap. January 21, 2024.
- ↑ Bon, Kirill (January 27, 2024). “Announcement: OpenLandcoverMap”. OpenStreetMap Community Forum.
- ↑ 11.0 11.1 “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.
- ↑ 14.0 14.1 “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.
- ↑ “tags.py”. osgende. January 01, 2022. line 11. Retrieved January 28, 2024.
- ↑ “test_guidepost_table.py”. waymarkedtrails-backend. December 28, 2020. line 46. Retrieved November 29, 2021.
External discussions
- 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.
- Nguyen, Minh (January 27, 2024). “RFC: Documenting feet as an an optional elevation unit”. OpenStreetMap Community Forum.
- Nguyen, Minh (January 27, 2024). “Feature proposal - RFC - Documenting feet as an an optional elevation unit”. tagging mailing list.
Comments
Please comment on the discussion page.