Proposal talk:Ele with units

(Please use the "Add topic" button to append a section to the bottom of this page to maintain chronological order. Thank you.)

Cities/villages

Is it really a good idea worth promoting to tag city/village with ele=*? Mateusz Konieczny (talk) 08:15, 29 November 2021 (UTC)

Most of them already are. The GNIS import that brought in the place=* nodes for the United States included elevation data. (Many of them, especially in the western US, are also tagged on the ground. The Cheyenne sign is hardly unique in including an elevation.) --Carnildo (talk) 09:38, 29 November 2021 (UTC)

Yeah, it's a standard part of city limit signs in some states, alongside the population, which demonstrates that it carries some importance to a populated place's identity. I couldn't tell you if the elevation is measured at each welcome sign, at city hall, or at the geographic centroid of the city, which makes the precision down to feet (or inches) somewhat less practical. For sure, you won't see me using an altimeter to determine and tag a city's elevation. I just included a city limit sign in the proposal to show that elevations in feet are often posted with the unit implied. – Minh Nguyễn ^💬 10:04, 29 November 2021 (UTC)

I find it very useful to see the elevation of a place on a map, both on "flat" maps and maps with contours/shading. Map needs data. This makes orientation elevation-wise so much easier. I would expect the elevation to refere to the point where to center of the place and thus the place=* tag is located. If it was the city limits sign, it would have to be tagged along with the traffic_sign=* itself, not a place=* the sign is referring to. Anyway, no showstopper for the proposal here. --Trapicki (talk) 16:41, 3 December 2021 (UTC)

It isn't based on the location of the sign – otherwise two city limit signs across the street from one another would agree. But now I'm curious about how the elevation of a large, hilly city would be determined. – Minh Nguyễn ^💬 02:45, 4 December 2021 (UTC)

I was always told that the elevation on city signs was the elevation of city hall. I have nothing to base that on other than things I learned as a kid from parents/teachers, so ymmv (your meters may vary). --B-jazz (talk) 04:39, 1 April 2022 (UTC)

@Trapicki: Belatedly following up on this: elevation signs are defined only in state-specific regulations, so the exact determination method may vary from state to state. In California, the signposted elevation is based on the spot elevation at “the courthouse, post office, railroad station, or benchmark in the central district of the city”. [1] – Minh Nguyễn ^💬 04:44, 30 January 2024 (UTC)

Depth

Unsurprisingly, depth=* is also documented to be in meters in the same manner as ele=*. Unlike ele=*, depth=* is only a de facto key, so I've started a discussion about whether that key's definition can simply be edited, or whether it should be incorporated into this proposal. – Minh Nguyễn ^💬 02:15, 3 December 2021 (UTC)

IMHO you should extend the proposal to depth=*. Leave out the discussion of the datum, that is totaly independent of the unit discussion. For me you could reduce it to: Proposal: Do away with the Units exceptions for ele=* and depth=* - Rationale: Conistency, precision (no conversion errors) and we now better than in 2007; 100% compatible to existing tagging; because it was a approved proposal before, let's do a Proposal/Vote now. —Preceding unsigned comment added by Trapicki (talk • contribs) 17:55, 3 December 2021‎ (UTC)

Perspective

From the point of the person, to add the information, this looks very much appreciable. Not so, from the point of the person to make use of the information. Many programming languages have a sort of "string2number" function, that convert a text value to a numerical one. They do so by stripping anything not a number. Not sure, who cares about ele values, but from a conservative point of view, it might be reasonable, if the unit was prefixed to the number, so programmers could spot errors early. OTOH, this is openstreetmap, and convenient data entry has preference, as the examples mentioned underline. The consumers will have to grow smarter. Maybe that is reasonable, maybe the just echo the text value, who knows? --Hungerburg (talk) 00:57, 4 December 2021 (UTC)

@Hungerburg: I agree, it's a definitely a tradeoff. I was uncertain whether it was a good tradeoff until I surveyed some popular renderers and found that most already do something reasonable with the standard unit syntax for ele=*. (I think Mapbox even recognizes nautical miles!) That crystallized my view about consistency being more important. You're right about the risk being misinterpretation: that's exactly what OpenMapTiles does, but it's simply a buggy regular expression that also truncates decimal values instead of rounding them. I feel reasonably confident that units are OK, but nonetheless I'd appreciate any additional research about existing renderers, to give us some peace of mind. And like you said, it is a matter of getting renderers to be a bit smarter. – Minh Nguyễn ^💬 03:16, 4 December 2021 (UTC)

Consumers are not a problem here. It already works for all other units, why not for ele=*? A dumb ``str2num`` without any checks of the string is never a good idea. As User:Hungerburg wrote, convenient data entry has preference; I would extend that to convenient and error-avoiding data entry has preference. Let's make it easy for mappers, let's be forgiving and richt in the for format (space between number and unit, leading/trailing space, decimal fractions of duodecimal units), and teach the parsers how to handle that. Let's create checks and checkers that highlight problems and find corner cases. It's not that difficult to create a test set of examples and check your parser/unit converter with that. I've written such things, it's rather a programming exercise than a huge task. —Preceding unsigned comment added by Trapicki (talk • contribs) 17:56, 4 December 2021‎ (UTC)

Format - Decimal fractions of feet

The footnote on the format hides a delicate detail: feet and inches are duodecimal (12 Inch = 1 Foot), while the metric system is decimal. When using decimal numbers with imperial length units, we can use both decimal and duodecimal divisions for feet: 17.456' or 17'4.56'', different values. Converting from one to the other often (not always) leads to rounding errors. Computers are much better in converting units, and pre-converting leads to rounding errors and values that are hard to check with the original source. Unfortunately Map_features/Units does not give details on that (let' improve that!), but there is an approved method for coordinates: DMS/Degree-Minute-Second 51°34'56", DDM/Degree-Decimal-Minute 51°34.56', DD/Decimal-Degree51.3456'. For lenth units, that would translate to "Decimal Feet" 17.456' and "Feet-Inch" 17'4.56". I think it's also important to encourage usage of the notation of the original source to preserve accuracy and allow easy comparison with the original source. Editors can help with input and validation (17.89' is sensible, 17'89" not so much, 17ft8in -> 17'89"), data consumers do their conversion code once and let the computer do the hard work. --Trapicki (talk) 18:20, 4 December 2021 (UTC)

Are you willing to parse 17′8″ ? (This is the most right, as I understand Unicode.) Or any other similar looking string, that some user copy/paste from some wordprocessor or pdf? Perhaps, a proposal for how to enter ft/in was in order, decimal or duodecimal never the less ;) I propose 17ft8in as the only valid choice, blanks thrown in for readability allowed. Single and double quotation marks are notorious for trapping escaping errors in program code. --Hungerburg (talk) 23:55, 4 December 2021 (UTC)

@Trapicki and Hungerburg: With U.S. customary units, the conventional use of decimals, fractions, and positional notation depends on the situation. Elevations on elevation signs are given in whole feet (or some multiple thereof), elevations on high water mark signs are given in decimal feet to the hundredths place, and height restriction signs are given in feet and inches. (The MUTCD specifies 8′–5″ on some signs but 8FT 5IN on others.) Meanwhile, distance signs give small mileages to the ¼, ½, or ¾, and rarely to the ⅓ or ⅔ [2], and some weight restriction signs are technically expressed down to ⅙ of a ton. [3]

Anyways, this proposal intentionally doesn't require a specific set of units or formats, instead delegating that authority to Map features/Units. If you think additional flexibility is needed in the general formatting rules, or that the preferred unit symbols should change, let's discuss it there outside of this proposal.

 – Minh Nguyễn ^💬 00:48, 5 December 2021 (UTC)

Unit name

I think that for most people outside of U.S. the ' symbol for foot is completely unknown. I would prefer the unit to be expressed more clearly, for example ft:
ele=1454ft
--Jcr83 (talk) 14:22, 11 December 2021 (UTC)

@Jcr83: I agree that ' is more obscure in metricated countries, and I also find it to be difficult to discern in some fonts. However, the ' symbol is already established as part of Map features/Units. ft is allowed and in use but is "highly discouraged". I think it's more important to align this key with all the other keys. Therefore, this proposal doesn't specifically require ' for feet, but it does use it in the examples, just as on pages like Key:height and Key:maxheight. It seems like the goal of Map features/Units is to unify each unit behind a single symbol, but you could start a conversation on Talk:Map features/Units or the tagging mailing list to see if there's any appetite for changing the standard. – Minh Nguyễn ^💬 07:21, 12 December 2021 (UTC)

@Jcr83:, @Minh Nguyen: According to the definition of the International System of Units, the SI unit of the physical quantity length is the meter, so if there is no description, ele should be using the meter. What I wish was that it was explicitly stated when you were using units like feet (That was what proposed). We chose to allow ft because, for example, in the US, non-metric units are indeed used on the ground. (Then in order to respect the original data and avoid errors caused by rough unit conversion, we should let the computer automatically convert, so ele:ft was abolished)。So if the original data is in the form 12'5", there seems to be no problem keeping it?
However, I am curious whether there is a single 12' in daily life in the US? Because ' alone without being used in combination with " seems to be directly considered 12 ft? (So ​​can we propose that this be done only when the original data is given in the form <feet>'<inch>", otherwise it is more recommended to use ft as unit) --快乐的老鼠宝宝 (talk) 12:13, 4 February 2024 (UTC)

@快乐的老鼠宝宝: ele=* will continue to be in meters by default unless otherwise specified. The general convention for length-related keys is that the default unit (i.e., m) can be specified explicitly but is discouraged.

21′–0″

The form "12 ft., 5 in." or "12 ft 5 in" is more common in writing, but the form "12′5″ " or "12′–5″ " is more common on signs. For round values, both "12 ft" and "12′–0″ " are common on signs (the latter pronounced as "12-foot-oh"), while "12′ " is relatively rare due to the potential for confusion. Since inches tend to be more prevalent in human-scale height measurements but rare on elevation signs, most elevation signs omit the unit symbol ("Elevation 4,515"), but many display either "ft." or "feet" if there's room. I'd hesitate to require an additional 0", because it would imply an extra degree of precision. Regardless, both ' and ft are already permitted in all the other length keys. If we want to prefer ft, I think we should discuss that separately, since it would affect every length key, not just ele=*.

 – Minh Nguyễn ^💬 23:17, 4 February 2024 (UTC)

@快乐的老鼠宝宝:, @Minh Nguyen: It's worth noting that 12′ is indeed customary for Americans to express "twelve feet" in shorthand writing, and only creates confusion among less-technical people who perhaps don't own a tape measure or don't work with distance measurements (or don't need to pay attention to bridge height signs because they never drive anything taller than a sedan... or all three, for an office worker who commutes via train and doesn't possess much curiosity about the world around them, in which case they probably also don't care a lot about the elevation of geographical things.) The only cases where 12′5″ means anything other than twelve feet five inches is perhaps in niche non-driving-related fields like math, music, and geography where it can mean minutes and seconds (of time or circular degrees) or derivations: https://en.wikipedia.org/wiki/Prime_(symbol) fortunately Americans rarely encounter situations where they have to talk about a 12′5″ high building at 45′67″ latitude that's a 1′15″ drive away... and if they do, the type of unit is implied in the discussion (and they'll typically quickly choose to use more distinctive unit symbols.) So no there is only one context where 12′ makes sense in a measurement of distance, even if it's foreign to non-Americans. (It's worth noting that Americans do have significant confusion about whether "12m" means "12 miles" or "12 meters" -- SI and ANSI be damned, less-standardized writings sometimes try to save space by taking out the space and "i" in "12 mi" and only context makes it clear. There's plenty of kitchen appliances that express minutes as "12m" as well... all part of the context-based chaos of daily life.) Rarely in teaching woodworking or DIY to beginners I might have to tell them what the markings mean, but everyone has to learn things for the first time in order to know them! Nobody is born using the UTC times we add to these comments, but that doesn't mean it's not useful and prolific and better than the alternatives. --Zyphlar (talk) 19:34, 10 February 2024 (UTC)

@Zyphlar: "m" was formerly the most common symbol for the mile in English-speaking countries, including the U.S. To this day, it remains the official symbol for both the meter and the mile on UK road signs. Despite our preference for British English in this project, we've adopted the American symbol mi to maintain a modicum of sanity. – Minh Nguyễn ^💬 10:48, 11 February 2024 (UTC)

Ground truth

I would prefer, the last countries U.S.A., Burma, and Liberia would start to use metric units ;-) but as the gold standard of OSM is ground truth, we should accept, what ever is visible on signs etc. In this case, it is not a question of what to use for "ele=*" but:
Why should we have differences in between different tags? We should have ONE wiki page about all (by the OSM-tools to be) accepted units The different tag wiki pages may just reference to that page. -karlos- (talk) 19:00, 12 December 2021 (UTC)

@-karlos-: You summarized this proposal quite nicely, thanks! :^) – Minh Nguyễn ^💬 22:07, 12 December 2021 (UTC)

You're talking about the inscription on an elevation sign. You can simply tag that as a sign with inscription=Elevation 1000 feet + ele=304.8. I wouldn't call this the best reason to change the status quo. --501ghost (talk) 16:42, 14 December 2021 (UTC)

Elevations aren't necessarily the main thing inscribed on a sign, and the elevation on the sign is not necessarily the elevation of the sign (example). Mappers may be interested in tagging not only the sign but also the effect of the sign. But anyways, this proposal doesn't mandate a particular source or method for elevations; it merely allows an accurate, less error-prone transcription of whatever that source may be. – Minh Nguyễn ^💬 07:16, 17 December 2021 (UTC)

What do we standardise?

In my opinion OSM would benefit from standardising the use of metric units the same way we have standardised the use of British English (as interpreted by Germans). This way, OSM-derived maps can simply display a number without the extra need of doing unit conversions. Metric units are common enough to make this an acceptable practice, as is the status quo. As stated in the rationale, "...tag values should be as structured as possible, which meant a normalized floating point number without any other complications" is something I still prefer over supporting and having to convert different units.

Furthermore, would this proposal lead to mass retagging to imperial in countries where this is used? That would seem like totally redundant work to me, as data users can simply convert the present data in metric units to imperial units if they desire this. --501ghost (talk) 17:01, 14 December 2021 (UTC)

If we standardize on metric units, then we need to deal with rounding. For example, maxheight=3.5 could reasonably have been anything from "Clearance: 11 feet 3 inches" to "Clearance: 11 feet 8 inches" originally. Speed limits would have similar rounding questions.

Further, this wouldn't save development effort. The vast majority of data consumers already support units other than meters. This proposal isn't adding a major new feature, it's removing a restriction that OSM Carto is nearly alone in paying attention to. --Carnildo (talk) 19:45, 14 December 2021 (UTC)

I meant for elevation data specifically, for which rounding data don't matter that much, because people aren't going to use OSM data to design the elevation of an aqueduct. --501ghost (talk) 00:56, 15 December 2021 (UTC)

@501ghost: I think the proposal as written already responds to all your points, but hopefully I can clarify. It does not change anything about how elevations are tagged in most countries: they will continue to be bare numbers, interpreted as meters. You may be surprised to learn that elevations are always given in feet in the U.S.; maps never display elevations in meters. Even so, the proposal does not concern itself with mass-retagging anything, because that would require researching the original source of the data. Instead, I'm choosing to focus on the steady stream of new ele=* values being added over time, some of which is inaccurate because of the unusual format of ele=*. The proposed change makes it easier for editors to support a lossless UI for entering the correct value. When the data is correct but in meters, OSM-based maps of the U.S. have to convert back to feet to meet user expectations, but the conversion back and forth is lossy. Imagine if we said that min_age=* has to be stored rounded to the tens place, but data consumers are expected to display the original number. Data consumers can already handle the "[quantity] [unit]" format because plenty of other tags follow it. – Minh Nguyễn ^💬 07:47, 17 December 2021 (UTC)

OpenMapTiles

Since ele=* is such a basic key, I consider it important to ensure that data consumers won't be needlessly disrupted by this documentation change. Fortunately, all the software I've found seems to handle units in ele=* just fine. I had been concerned about OpenMapTiles, because the code seemingly takes a value in feet, ignores the unit, misinterprets the value as meters, and converts back to feet. [4][5] But upon testing in a MapTiler-hosted OpenMapTiles layer, I discovered that it handles units correctly in every example I spot-checked, such as this sledding hill ('), this trash heap (meters), this airstrip ('), and this airstrip (ft). I can't explain it based on reading the code, but if it works, it works. 🤷‍♂️ – Minh Nguyễn ^💬 18:44, 1 July 2023 (UTC)

Some corrections and additional information

The information on OpenTopoMap provided is incomplete - OpenTopoMap fully supports only unitless (implicit meters) values as well as 'm' and 'ft' - see https://github.com/der-stefan/OpenTopoMap/blob/master/mapnik/tools/isolation.c. Generally speaking most applications that numerically interpret ele values will only support number only formats because anything else is very rare on ele in general.

Some more detailed numbers from taginfo: Currently 'ft' is used <2000 times in some form, the single quote/apostrophe symbol (Apostrophe, U+0027 - and not Prime, U+2032 btw.) <400 times and the explicit 'm' around 2000 times - compared to ele:ft with 2663 uses.

Side comment generally on tagging on OSM and not specifically on this proposal regarding:

The parallel ele=* and ele:ft=* keys can introduce internal inconsistency.

This is an universal property of the free form tagging system of OSM in general where different tags can semantically contradict each other. Compared to most such cases contradictions in ele/ele:ft are easy to determine and process. And requiring the mapper to omit one of the values does not eliminate the problem, it just hides it. Historically it has been broad consensus in OSM that allowing mappers to record knowledge with redundancies (and hence the possibility for contradictions) is generally not a bad thing - exactly because it reveals inconsistencies in the knowledge of mappers rather than hiding them.

--Imagico (talk) 12:15, 28 January 2024 (UTC)

@Imagico: Thank you for your insights. If I’m not mistaken, feet or inches are specified in ele=* and ele:ft=* in comparable numbers. [6] ele:ft=* is more common but not in such an absolute number as to cause much concern about disrupting mappers. Your point about parallel tags revealing intent is well-taken; this is how we currently justify parallel operator=* and operator:wikidata=* tags, for instance. Nevertheless, ele=* suffers from inconsistency with similar keys like height=* that causes mappers to inadvertently set ele=* to feet without saying so, an error that can be difficult to detect. Perhaps if we had gone a different route with the other measured keys, we wouldn’t be in this situation. My hope is that formalizing units within ele=* will allow editors to provide a unit option that mitigates this error, and I’m willing to implement what’s needed in iD. Editors cannot do so today without introducing some conversion error. – Minh Nguyễn ^💬 18:12, 28 January 2024 (UTC)

I guess my main point about the numbers is that in practical use ele=* is a very clean and consistently used tag with practically almost exclusively pure numbers representing meters. Any other uses so far are fringe uses and none of them clearly pre-defines how the tag can be further developed.

That means you have the responsibility here to carefully consider what are viable ways to do that. History has taught us (like in case of name=* - but we see the same in other cases) that trying to use a tag to store structured data (like different names in one case, number + unit in the other) in a way that doubles as a labeling string will never work. Labeling conventions and styles are simply so diverse globally that this will always lead to mappers essentially sabotaging any attempts at developing consensus on how to store structured data in a well defined way. And we have positive counter-examples like opening hours and access restriction where the approach to deliberately not aiming to serve data users with a ready-made labeling string or aggregate classification has led to a well defined and mapping centered syntax to be supported by broad consensus. --Imagico (talk) 10:34, 30 January 2024 (UTC)

@Imagico: I'm not sure if I understand the historical point you're making. My goal is also to promote well-defined, structured tagging while acknowledging the reality that mapper ergonomics matter a lot for this project. The absolute numbers are somewhat misleading, as the vast majority of ele=* tags have come from imports, especially in the region that would be affected by this proposal. I'm not so concerned about imports, because the largest ones have already happened, and most importable elevation sources are in meters, even in the U.S., so it doesn't make sense to convert them to feet in the database. Rather, we should be optimizing for the mappers who will be manually inputting elevations going forward, most likely based on observations in feet.

To be clear, I am not attempting to facilitate labeling ele=* verbatim. This is a poor practice that typically results in OSM-based maps showing counterintuitive elevations in the U.S. I cannot stress enough that elevations here are only specified in meters for geodesy and recordkeeping, not wayfinding or any of the other reasons we'd tag ele=* in OSM. Certainly not for map labeling. [7] Ignoring units for a moment, a -####.# format doesn't lend itself to verbatim labeling globally for other reasons besides: not every region uses the same decimal separator, and not every language uses European numerals. Most regions also use digit grouping characters, which are not allowed in the raw tag.

Nevertheless, a software developer would find it very tempting to use a raw ele=* tag in this manner, so I agree that we should be careful about breaking that expectation – not because it's a correct expectation, just out of sheer pragmatism. For this reason, I went through the trouble of determining how existing data consumers would be affected. (Most tagging proposals never bother taking this step, for better or worse.) The good news is that the impact should be relatively minimal, because most data consumers are already doing the right thing.

 – Minh Nguyễn ^💬 18:29, 30 January 2024 (UTC)

By the way, this proposal does not seek to deprecate the bare numeric values: the value is assumed to be in meters by default, just like in height=* et al. – Minh Nguyễn ^💬 20:24, 30 January 2024 (UTC)

Horrible idea

I do not see why we should kowtow to the United States' continuing refusal to use the metric system. OpenStreetMap is an international project and should be using international conventions for measurements. -- DENelson83 (talk) 20:29, 5 February 2024 (UTC)

@DENelson83: Cut us some slack, we only fully adopted the international foot just last year! ;^) As a practical matter, I believe one's distaste for the customary unit system has little bearing on this proposal. After all, we already allow customary units everywhere else; what's so unique about elevations, other than the fact that even foreigners measure it in feet while they're here? Rest assured, under this proposal, mappers everywhere continue to have the option to record elevations in meters, and generally foot elevations will be limited to the U.S. Meanwhile, data consumers are free to convert to the desired unit, regardless of the unit in the tag. This proposal is really about avoiding data entry errors caused by the documentation's current insistence on meters, further compounded by data consumers' inability to anticipate those errors. – Minh Nguyễn ^💬 05:24, 6 February 2024 (UTC)

Update Editors to convert feet to meters

Another solution might be to update the editors to automatically convert feet to meters. The user just enters the elevation then specifies the unit, feet for example, then it's converted to meters. That might eliminate errors when a person forgets to use ele=100ft. Glassman (talk) 18:11, 6 February 2024 (UTC)

@Glassman: Some editor developers have considered this, but the problem is that converting to meters to feet or vice versa results in conversion error that compounds each time someone edits the feature. This doesn't count the unavoidable conversion error that results if a renderer then needs to convert from meters back to feet based on local convention or user preference. – Minh Nguyễn ^💬 18:04, 7 February 2024 (UTC)

Per our discussion in Slack, I’ve revised the proposal to mention my standing offer to implement a value-and-unit field in iD that only annotates the unit but does not convert. The field would be dependent on passage of this proposal. – Minh Nguyễn ^💬 03:44, 8 February 2024 (UTC)