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

Resolved: The answer is yes, this is normal and unremarkable. – Minh Nguyễn ^💬 23:45, 8 May 2024 (UTC)

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

Resolved: Data consumers are generally in good shape already. – Minh Nguyễn ^💬 23:48, 8 May 2024 (UTC)

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)

Turns out even OpenMapTiles has no problem here. – Minh Nguyễn ^💬 23:48, 8 May 2024 (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

Resolved: Out of scope; worth clarifying in Map features/Units separately. – Minh Nguyễn ^💬 23:49, 8 May 2024 (UTC)

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

Resolved: Out of scope; follow up on Map features/Units separately. – Minh Nguyễn ^💬 23:50, 8 May 2024 (UTC)

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

Resolved: Map features/Units exists; we should use it more. – Minh Nguyễn ^💬 23:51, 8 May 2024 (UTC)

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?

Resolved: We shouldn't encourage data consumers to present raw POSIX numbers to users unlocalized. (Also, German speakers should take note that m is the symbol for miles in British English.) – Minh Nguyễn ^💬 23:57, 8 May 2024 (UTC)

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)

Unresolved: The "Rendering" table now lists OpenTopoMap as being fully ready for this proposal. And an FAQ clarifies that some data consumers should not expect to render the number verbatim. – Minh Nguyễn ^💬 23:59, 8 May 2024 (UTC)

Please do not claim the points i raised to be resolved when they evidently are not. The only ways to resolve these are either changing the proposal or convincing me the facts i state are wrong or my logic is flawed. Neither of this happened. See also https://en.wikipedia.org/wiki/Consensus_decision-making. If you want to dismiss what i wrote that is ok. But please do so openly and do not cover it under the false claim of things being 'resolved'.

The basic facts of tag use remain more or less as before - as does the way OpenTopoMap handles ele values. For reference: currently used methods to specify elevations in feet are:

• ele:ft=* is used 2674 times
• ele=* values with 'ft' are used around 2000 times
• ele=* values with an apostrophe, U+0027 (what this proposal suggests) are used around 400 times
• ele=* values with 'feet' are used around 60 times

--Imagico (talk) 07:24, 9 May 2024 (UTC)

@Imagico: Ah, I misunderstood your initial feedback amid the discussion about pure numbers. I certainly did not intend to brush you under the rug! My apologies for being dense, and thank you for being persistent. I've changed the table to state that OpenTopoMap hides the elevation in the event of an apostrophe, even though it does apparently respect the ft symbol. Is that consistent with your understanding of the situation? Unfortunately, I'm no longer able to confirm the source code's apparent behavior, because OpenTopoMap tiles no longer load for me at all. Hopefully that's just a temporary issue.

As I pointed out above, I tried to avoid favoring one unit symbol over another. This is a broader question that should be addressed in the context of Map features/Units, a well-established page that determines the format of a great many keys. For better or worse, that page prefers the apostrophe, which is why it appears throughout this proposal, but the proposal explicitly does not favor one over another. Among all the length-related keys, the ' or " appears 232,642 times, whereas ft or in appears only 5,820 times. [8] You're right that the situation is flipped with ele=*, but if ft is a better option, then we should pursue its adoption beyond just ele=* – as part of a separate discussion.

As for ele:ft=*, there are currently 13 elements for which ele=* and ele:ft=* disagree by more than 5%, some of which have gone unnoticed for as long as six years. [9] One might point to the existence of this query as evidence that parallel keys help us spot inconsistencies, but I would contend that, under my proposal, these inconsistencies would be much less likely to arise in the first place.

 – Minh Nguyễn ^💬 21:43, 11 May 2024 (UTC)

For completeness, I opened an issue about adding apostrophe support to OpenTopoMap, in case the developers aren't aware of this notation. [10] However, the project doesn't seem to be very active, so I'm not expecting anything much to come out of it. – Minh Nguyễn ^💬 00:00, 12 May 2024 (UTC)

Regarding OpenTopoMap - i have not evaluated their full tag interpretation logic, i just became suspicious about the claim that what this proposal suggests is fully supported given this is - so far - a rather exotic method of specifying elevations in feet (less than ten percent compared to the other methods). Hence i looked until i was able to falsify the claim. Of course OpenTopoMap is just one of many examples. And my secondary point here is of course to illustrate that you present primarily those facts that seem to be in support of your goal and leave out a lot of those which are not helpful for that.

Regarding the renewed claim that the proposal explicitly does not favor one (method of specifying feet values in ele=*) over another - all evidence is to the contrary, quoting from the proposal:

ele:ft=* should be deprecated in favor of ele=*'

Anyway - what i was primarily interested in was setting the record strait on the facts of the case w.r.t. de facto tag use and de facto tag interpretation practice by data users regarding ele=* and regarding the value and the acceptance of information redundancies in tagging in the OSM community (and btw: 13 of 2674 values differing by more than 5% is amazingly low - i can hardly imagine any other case of redundant information tagging in OSM with a similar level of consistency. 13 in 2674 could well be about the real world percentage of signed elevation values differing from the de facto elevation by more than 5 percent).

I also tried to point out that tagging consistency of ele=* with plain numbers representing meters is extraordinarily good and that this creates a high hurdle regarding attempts to change the practice of use of the tag if the aim is for such changes to be of benefit for OpenStreetMap. What you make of this is up to you. But it should be clear to everyone that if the net result of this proposal should be that everyone has a much harder time extracting meaningful information from the ele=* tag than today it will be the US community that is going to be blamed for that. In other words: In your FAQ you write:

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 people abroad.

Maybe you should mirror that with something like:

We use feet for specifying elevations where I live; should I vote for this proposal?

Please vote thoughtfully based on the needs of our project. What this proposal suggests would require all users of elevation values from OSM and all mappers to deal with the cultural particularity of specifying elevations with non-metric values. In the vast majority of other cases of cultural differences in specifying certain information (like different address systems, species=* and species:en=*) different tags are used to deal with these differences so data users can decide on their own if or not to interpret certain cultural particularities or not. A solution along these lines exists for elevations as well (ele:ft=*). This proposal wants to deprecate that solution.

--Imagico (talk) 12:59, 12 May 2024 (UTC)

@Imagico: Please do not put words in my mouth: this proposal does not favor one unit symbol over another inside tag values. It does favor ele=* over ele:ft=* (which enjoys zero adoption in software). We disagree about the wisdom of maintaining parallel elevation keys and probably will have to leave that to the voters to decide. I'm being charitable in my description of those 13 cases – one differs by 226%. This is after the global community has just conducted a wide-ranging effort to find and fix peaks with incorrect elevations, which also resulted in some conversions from feet to meters. [11][12] This effort was necessary and appreciated. However, it missed some discrepancies and more keep rolling in, even from someone who has spoken out against this proposal elsewhere on this page.

Yes, indeed, this proposal would inform data consumers of a cultural peculiarity in the United States that they may wish to account for. I can only apologize so much for the pace of metrication in my country, but my apologies won't stem the confusion. Most data consumers have been dealing with this issue for years in other keys. The only thing unusual about ele=* is that renderers label elevations on the map instead of treating it as metadata, and a few use the value verbatim. In my opinion, this is not enough reason to exempt ele=* from the general unit syntax.

I'm asking people to vote out of a spirit of magnanimity because this is a compromise. I expect that some U.S. mappers will vote against the proposal because it doesn't go far enough. For years, people on the talk-us list and Slack have been clamoring to deprecate implicit metric elevations. But in my opinion, we don't need to pretend that the meter and foot are on even footing; the foot option is nothing more than an accommodation for mappers. I agree that this accommodation comes at the expense of some data consumers. On the bright side, to the extent that more data consumers implement unit conversion, they're more likely to accommodate other regional needs at the same time, such as converting . to , per DIN 5008.

Of course, a data consumer is always free to ignore complications that they don't consider important for their users. If a developer wants to ignore those complicated ele=* tags or display them verbatim, that's up to them. The compatibility table is intended to show that there is already substantial support for units in ele=*. This point is not undermined by the presence of renderers like osm-carto or OpenTopoMap. I avoided coloring any cell in red because the point is not to shame anyone – every data consumer has its own valid priorities and constraints. If you know of any other noteworthy data consumers, please feel free to list them here or in the table itself.

 – Minh Nguyễn ^💬 02:02, 13 May 2024 (UTC)

I reject the claim that i put words in your mouth. I quoted from your comments and from the proposal and i don't think the selective quoting substantially distorted the meaning. If or not this favors `ele=*'` over `ele=* ft` and other notations everyone can determine on their own.

But let me also point out that i appreciate the difficult situation you are in here. You have taken on the thankless task of bringing a pre-fabricated decision made apparently by a gated community on slack through the proposal process. And you seem to have no negotiation leeway in doing that whatsoever. So without sacrificing that mission you cannot really engage in an open ended discussion on the merits of this proposal and openly explore possible alternatives - which is the main purpose of the proposal process otherwise.

Personally for me it is not important if this proposal is substantially modified based on the feedback received or if it is formally approved or not. As i always like to point out: The proposal process is an offer of the OSM-Community for people to critically evaluate their tagging ideas with feedback from a broader circle of people. Such feedback has been provided and it is up to you and other people behind this proposal what you make of it.

--Imagico (talk) 09:43, 13 May 2024 (UTC)

Horrible idea

Resolved: Emphasized that kowtowing is out of scope for this proposal. – Minh Nguyễn ^💬 00:02, 9 May 2024 (UTC)

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

Resolved: A unit selection option is now implemented for most major editors. This is no plan to require editors to convert units silently. – Minh Nguyễn ^💬 00:04, 9 May 2024 (UTC)

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)

@Glassman: This small pull request implements a unit option that defaults to the local standard unit for elevations. It would cover iD, Rapid, Go Map!!, and Every Door. (JOSM and Vespucci use a different preset model that normally requires the user to input units manually.) – Minh Nguyễn ^💬 23:21, 8 May 2024 (UTC)