Proposal:ele with units

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

Draft started: 2021-11-29
RFC start: 2024-01-27 2021-12-03

information sign

Too long? Read the FAQ!

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] However, this proposal does not require mappers anywhere to use ele=* any differently than before.

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.[3]

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.[5] 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.[6][7]

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. As of May 2024, 18% of ele:ft=* occurrences disagree with ele=* by 1 foot (0.30 m) or more, some by thousands of feet.[8] The community previously chose to eliminate parallel subkeys for other quantities, such as maxspeed:mph=*,[9] and more recently rejected a parallel subkey for identifying traffic signs in part over similar concerns.[10] No software is known to support ele:ft=* in any manner.

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:

  • Pikes Peak, Colorado: ele=4302 → ele=14115'

    Pikes Peak, Colorado:
    ele=4302 → ele=14115'

  • Mt. Washington, New Hampshire: ele=1917 → ele=6288'

    Mt. Washington, New Hampshire:
    ele=1917 → ele=6288'

  • Cheyenne, Wyoming: ele=1848 → ele=6062'

    Cheyenne, Wyoming:
    ele=1848 → ele=6062'

  • Livermore Station, California: ele=148 → ele=486'

    Livermore Station, California:
    ele=148 → ele=486'

  • Badwater Basin, California: ele=-85.5 → ele=-282'

    Badwater Basin, California:
    ele=-85.5 → ele=-282'

  • Lewis Pass, New Zealand: ele=907 (unchanged)

    Lewis Pass, New Zealand:
    ele=907 (unchanged)

  • The U.S. National Flood Insurance Program posts high water marks indicating an elevation in decimal feet.[11]
  • Oswatomie, Kansas, posts its elevation as 10,428 inches (869.0 ft) on welcome signs.[12]
  • A high water mark at Lake Tahoe, California, is signposted to the hundredths of a foot according to a local datum.[13]

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.

Editor Status
Every Door Ready
Go Map!! Ready
iD Ready
JOSM N/A[note 6]
Rapid Ready
Vespucci N/A[note 6]

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. Fortunately, most of them have already long supported the change proposed here:

Renderer or tileset ele=### ele=###' ele=### ft[note 7] 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[14] Ignored Developer is aware of the use of feet in the U.S.[15]
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[16] Hidden[16] height=* values in feet are recognized, even though waterfall heights are labeled in the same manner as peak heights.[17] 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 Ignored[18] yes[19] Converts all units to meters.
Organic Maps yes yes[20] yes[20] Converts all values to feet.
OSM2World yes Ignored[21] 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.[22]
TopOSM yes yes yes Converts unqualified values from meters to feet.[23]
Waymarked Trails yes yes[24] yes[25] Converts all values to meters.

Pages affected

The following pages will undergo minor modifications:

The following pages will remain unchanged:

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 April 2024, 2,145 features are tagged with ele=* in feet and/or inches using various formats, while 2,674 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,723 are tagged with explicit feet or inches, while 2,003 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:

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.

Worldwide, 49% of the 2,674 occurrences of ele:ft=* were introduced in a mechanical edit in January 2016, in order to clean up after an undocumented building import in California.

Frequently asked questions

What year is it?
It is 2024, even in the United States.
What is changing?
Some pages on this wiki that up to now have attempted to be prescriptive rather than descriptive of the OSM database. These pages will now acknowledge that ele=* can sometimes be expressed in feet and inches, if specified.
Is there any precedent for units in a numeric tag?
Yes, over 100 documented keys accept a unit after the numeric quantity.
We use the metric system where I live; should I vote against this proposal?
Please vote thoughtfully based on the needs of our project. This proposal recognizes that the U.S. community needs to coexist with the rest of the OSM community, so it takes great pains to avoid inconveniencing mappers abroad.
My language uses the metric system; what about my language?
Actually, speakers of your language who live in the U.S. also measure elevations in feet and inches.
What's wrong with standardizing on the meter everywhere?
OSM prioritizes mapping what's on the ground, that is, what is observable. The U.S. community welcomes mappers who come from a non-technical, non-scientific background and who do not routinely convert to metric units. Our widespread use of customary units for attributes like speed limits and building heights leads to surprise that ele=* is a singular exception. Often, mappers enter incorrectly converted or unconverted values that neither we nor data consumers can detect.

For mappers

Should I express an elevation in meters or feet?
You can use either. Use common sense and follow local conventions. If you have groundtruth in meters, do not convert it to feet and inches just because you can.
If I know the elevation in meters, will I have to write it differently than before?
No. You'll continue to tag an elevation of e.g. 300 metres (980 ft) as ele=300, just like you do now.
Why not require writing out m for meters too, for consistency?
Although some in the U.S. community have expressed support for deprecating unitless elevations, this would cause unnecessarily disruption to the project. In most regions, meters are a given and feet would be quite extraordinary. Deprecating a syntax used by so many features would be unlikely to succeed in practice.
Why can't my editor convert feet to meters on the fly?
The meter and the foot differ by enough that conversions between them are lossy, building up error over time, especially since the community expects the value to be rounded off to a minimal number of digits.
Can I change all the elevations in my U.S. city to be in feet?
Discuss it with the local community first. If you do convert the values, try to respect the original source's precision, where known.
Should I use ' notation or ft notation?
This proposal does not take a position on the specific notation that you should use for feet and inches. Please refer to Map features/Units. (That article does strongly prefer ' notation, which is why it appears throughout this proposal.)
Which is better, decimal feet or feet and inches?
Neither is better in every case. If you are copying a reading from a sign, dataset, or altimeter, follow the format it uses.
How do I distinguish between the international foot and the U.S. survey foot?
It does not matter. The U.S. survey foot is deprecated as of 2023. Although some survey foot measurements remain, the difference is too small to matter when measuring elevations on Earth.
What is the point of tagging an elevation without specifying a vertical datum?
This is a fundamental shortcoming of ele=* regardless of units. The OSM community has traditionally accepted elevation tags as a practical concession to cartography needs. A more rigorous approach is out of scope of this particular proposal, but feel free to propose something separately.
Can I tag an elevation in the U.S. in meters anyways, in solidarity with the international community?
This wiki cannot stop you, but make sure you correctly perform any conversion from feet to meters, preserving an accurate number of significant figures.

For software developers

Should I display elevations verbatim or convert them?
It depends. If you are developing an editor, validator, or other tool meant for mappers, you may want to keep the value unchanged to reduce the risk of miscommunication among mappers. However, if you are developing a renderer or other user interface for non-mappers, consider normalizing the values to a consistent unit to match the user's preferred measurement system or the conventional units for the kind of map you are rendering. For example, a topo map of the United States would typically label elevations in feet, regardless of language. You can perform this conversion at the same time that you format the number to match the user's preferred decimal separator and the numerals used by their language.
Why doesn't OSM normalize all elevations to meters so I don't have to convert?
American mappers do not expect the metric system to be used in just one small part of the editor while customary units are accepted everywhere else. There is a demonstrated history of data entry errors and overconversion, but we lack a reliable means to detect and fix these issues everywhere they occur.
Which units should I accept?
This proposal does not restrict ele=* to a specific set of units. See Map features/Units for a list of common length unit symbols that you should probably support in a variety of keys, not just ele=*. At a minimum, you should recognize both meters (### or ### m) and feet and inches (###', ###'##", or ##").
When will the database start containing elevations in feet?
The database has always contained elevations in feet and inches. To minimize confusion among users, consider adding support for the documented unit syntax. Hopefully the rate of unlabeled foot elevations will decrease over time once editors expose a unit selector to their users.

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.[4] 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. ↑ 6.0 6.1 Some editors don't normally format measurement tags on the user's behalf, so users will still need to enter the unit manually.
  7. ↑ 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. ↑ Townsend, Andy (November 2, 2015). “Maxweight in the USA”. talk-us mailing list. 
  4. ↑ “Thread in #random”. OSMUS Slack. October 31, 2021. 
  5. ↑ SK53 (December 27, 2018). “imperial units silently removed from ele tag”. iD. 
  6. ↑ Thompson, Mike (September 7, 2017). “Elevation in Feet as part of Peak Names”. tagging mailing list. 
  7. ↑ Thompson, Mike (March 7, 2019). “Spot elevations collected as natural=peak and name=Point (height in feet)”. talk-us mailing list. 
  8. ↑ “Query for elements with elevations in feet and meters that disagree by one foot or more”. QLever. University of Freiburg. April 29, 2024. Retrieved May 12, 2024. 
  9. ↑ “maxspeed:mph”. OSM Tag History. May 12, 2024. Retrieved May 12, 2024. 
  10. ↑ yopaseopor (April 14, 2024). “Traffic_signs: human readable values vs. ISO and law codes”. OpenStreetMap Community Forum. 
  11. ↑ “High Water Mark: Be Flood Aware”. City of Roseville. Roseville, California. Retrieved November 29, 2021. 
  12. ↑ 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. 
  13. ↑ Dara-Abrams, Drew (August 1, 2024). “You know they’re serious when…”. sfba.social. San Francisco. 
  14. ↑ “peaks.sql”. OpenLandcoverMap. January 21, 2024. 
  15. ↑ Bon, Kirill (January 27, 2024). “Announcement: OpenLandcoverMap”. OpenStreetMap Community Forum. 
  16. ↑ 16.0 16.1 “project.mml”. openstreetmap-carto. September 22, 2021. line 1,483. Retrieved November 29, 2021. 
  17. ↑ meased (April 6, 2018). “Add rendering for waterway=waterfall”. openstreetmap-carto. Retrieved November 29, 2021. 
  18. ↑ Nguyen, Minh (May 11, 2024). “Apostrophe notation for elevations in feet”. der-stefan/OpenTopoMap. Retrieved May 11, 2024. 
  19. ↑ “isolation.c”. OpenTopoMap. November 30, 2017. line 65. Retrieved May 11, 2024. 
  20. ↑ 20.0 20.1 “osm2meta_test.cpp”. Organic Maps. April 9, 2020. lines 23–28. Retrieved December 3, 2021. 
  21. ↑ Nguyen, Minh (July 1, 2023). “Elevations in feet are ignored”. tordanik/OSM2World. 
  22. ↑ Nguyen, Minh (May 17, 2022). “[BUG] Elevations in feet are misinterpreted as meters”. Planetiler. Retrieved May 18, 2022. 
  23. ↑ “import_planet”. TopOSM. September 1, 2011. lines 89–90. Retrieved December 2, 2021. 
  24. ↑ “tags.py”. osgende. January 01, 2022. line 11. Retrieved January 28, 2024. 
  25. ↑ “test_guidepost_table.py”. waymarkedtrails-backend. December 28, 2020. line 46. Retrieved November 29, 2021. 

External discussions

Comments

Please comment on the discussion page.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Ele_with_units&oldid=2751420"