Talk:Map features/Units

Aliases

"Aliases" for SI units shouldn't be used. Things like "m" are not just random abbreviations, but standardized symbols, so there is is no reason to use other names ("metres", "metre", or maybe "meters", "meter" -- or the irritating "kph"). I therefore consider listing them here a bad idea: It unnecessarily encourages mappers to actually use them, causing more variation and uncertainity in tagging than necessary. --Tordanik 20:27, 13 June 2009 (UTC)

feet and ft

Could we suggest "feet" and "ft" as suffixes for decimal measures in Imperial feet? The abbreviation "ft" is probably the most standard abbreviation. --achadwick 10:19, 16 June 2011 (BST)

If it is actually popular in OSM tagging (any stats?), we could add that one imo. It would just be yet another another unit with multiplier-based conversion, so adding support for it wouldn't be hard at all. --Tordanik 13:05, 16 June 2011 (BST)

I don't think that's a good idea, as decimal measures in Imperial feet seem to be pretty uncommon. It would just encourage unnecessary conversions, like 14.9166 ft (which should be written as 14'11" instead). -- Eckhart 11:41, 12 June 2012 (BST)

When I measure the width of a street by counting the number of revolutions of bicycle tires, one foot is the best accuracy I can achieve. I will generally not measure inches. So I will use "ft" instead of apostrophes and quotes. (Moreover, most streets in my area are designed to be a whole number of feet in width, so a conversion to meters would be a change from exact to approximate measures.) T99 (talk) 00:06, 29 July 2018 (UTC)

Explicit units

I think we should encourage being explicit about the unit, even when using the 'default' unit. Looking through http://taginfo.openstreetmap.org/keys/?key=maxweight#values, it seems quite clear that not all of the values without a unit is in fact in tons (1000 kg). Perhaps a nightmare sifting through all the various weird abbreviations that might be used, but is that any worse than simply assuming the value is a certain unit? --Gorm 00:30, 27 June 2012 (BST)

I agree that explicitly tagging "default" units is a good idea as it avoids misunderstandings. For that reason, I always tag "m" explicitly, for example. --Tordanik 15:55, 27 June 2012 (BST)

Reasoning for kg

I don't really support the reasoning given for "kg": "3.5 t" is a shorter and somewhat more readable value than "3500 kg", and afaik signs usually use tonnes. I can't comment on the ambiguity (it's not ambiguous at all in countries using metric-based units only), but even where ambiguity exists, it would only disappear if no tonnes remained in the database. This, however, is pretty unlikely because many people will still stick to tagging the restriction the way it is given on the sign. --Tordanik 01:44, 15 August 2012 (BST)

Can someone please point my to the "reasoning given"? I simply can't find it. --Imagic 08:48, 16 August 2012 (BST)

Oh, sorry, that was actually on a different page (but by the same user who added kg to this list). I'm referring to the sentence "As 'tonne' can be ambigous and often needs decimals, it may be better to use kg like '3500 kg'" that was added to Key:maxaxleload. --Tordanik 14:38, 16 August 2012 (BST)

I also dont support this. Also on taginfo I can't find any significant number of tags using kg - actually zero but I stopped on page 7 of 170 where all values were used three times. I suggest removing this again (in the Units and the maxaxleload article). --Imagic 16:34, 16 August 2012 (BST)

If there is no further feedback on this, I agree this should be reverted this. --Tordanik 01:40, 22 August 2012 (BST)

Read the wikipedia articles called Ton and Tonne. Then you will understand what I mean with:

>As 'tonne' can be ambigous and often needs decimals, it may be better to use kg.

This applies to all tags where a unit weight is expected and goes hand in hand with my suggestion of encouraging explicit tagging of unit. The t/ton/tonne/mt is riddeled with ambiguity, even in 'metric' countries (i.e UK; the origin of OSM). Just to be clear: I'm perfectly fine with people just typing in what is says on the sign, if that includes the 't'!.

I do not suggest to change the default unit to kg, but rather to explicitly tag with a non-ambigous unit. For that I suggest the SI unit 'kg' when applicable. For this matter I see no need for conserving db space for the sake of clarity. --Gorm 14:24, 15 September 2012 (BST)

It has been a while, but I'd still like to comment on this nevertheless. With maxspeed being intended for legal limits, there will commonly be a sign, and I don't like the idea of encouraging mappers to do conversions of signed values - the introduction of the first explicitly tagged units, mph for maxspeed, was specifically for that reason. Instead, if the sign displays the limit in metric tonnes (with our without an explicit letter "t"), I would add the value in metric tonnes and set an explicit unit. As this - except for the explicit unit, unfortunately - also matches actual practice in the database better than your suggestion of preferring a conversion to kg, I still do not agree with your addition to the maxaxleload article. --Tordanik 00:50, 15 October 2012 (BST)

I agree with Tordanik: we should map what we see. I recommend removing the comment on kg-conversion from the maxaxleload article. --Imagic 07:48, 15 October 2012 (BST)

I've removed that recommendation from Key:maxaxleload now, but left the kg entry on the Units page in place - so if mappers decide to use explicitly tagged kg, it will be clear what it means. --Tordanik 01:10, 25 October 2012 (BST)

Time

We need a chapitre for time and explanation for the default unit: second, minute hour or day ?? --APP3L initiation (talk) 22:55, 8 March 2013 (UTC)

Is there actually a significant number of established keys using these units? The only one I can think of is Key:maxstay. --Tordanik 19:32, 9 March 2013 (UTC)

At least duration=* comes to mind. Ferries and some other routes use it, and if would be beneficial to have it tagged more often on those. Alv (talk) 20:41, 9 March 2013 (UTC)

Ah, didn't know that one. Of course it seems to use a completely different syntax than maxstay ... well, two actually. :/ --Tordanik 22:26, 9 March 2013 (UTC)

Nautical Miles Abbreviation

I added nautical miles to the distance length section--have seen it used in a few places. The most widely accepted abbreviation according to wikipedia is "M", so I listed that, but if people wanted to use something less ambiguous, like "nmi", that would also make sense. Neuhausr (talk) 16:07, 12 December 2014 (UTC)

Is there a need for this unit in OSM? Where is this used? I believe that if it's not used, it shouldn't be documented. Also, I agree that "M" is ambiguous, so I'm changing it to "nmi", as you suggested. --Jgpacker (talk) 17:18, 6 January 2015 (UTC)

waterway=milestone would be the main use case I could think of (and it is used a little--probably at these spots: http://taginfo.openstreetmap.org/tags/seamark%3Adistance_mark%3Aunits=nautical_miles). I could possibly see it used on things like ferry routes, too? Neuhausr (talk) 16:28, 27 January 2015 (UTC)

I see. If it's used, then I don't see a problem adding it here. Thanks for the info! --Jgpacker (talk) 20:46, 27 January 2015 (UTC)

Introducing new units

This is a reminder that there should be consensus about a unit symbol before adding it to this page. Otherwise, data consumers and developers of editors and validators will be caught off-guard. The introduction of a new unit can impact how several tags are interpreted; it can render new data meaningless to data consumers. So a new unit should be subject to at least as much consideration as a new tag. – Minh Nguyễn ^💬 07:49, 26 April 2019 (UTC)

Statistics

Is there a way to determine how much a unit is used in the database and where?

--Andrew Andrew (talk) 06:40, 30 April 2019 (UTC)

Taginfo https://taginfo.openstreetmap.org/ ? Warin61 (talk) 03:56, 1 May 2019 (UTC)

The Taginfo website can tell me how often, and where, a particular value of a particular key has been used. This works ok for things like maxspeed=30 mph where there are relatively few common values. But for lengths and such, it would be interesting to have an overview of unit usage across all keys and values: height=5 m, but also height=4.9 m, as well as width, maxheight, and many other tags. Overpass API might be more helpful for that latter case because it supports regular expressions. Alternatively, one could try working with Taginfo's raw API. --Tordanik 15:08, 3 May 2019 (UTC)

“st” for short ton, but what about stones?

This wiki page says st is short for  Short ton, but in Ireland & Britain, “st” is used for  Stone (unit), 14 pounds, or about 6.3 kg. I know it's unlikely for someone to think that a bridge's max weight is about 60 kg, but I worry about someone who is unaware of what a “short ton” is writing a parser, or using an off the shelf parser, and getting wrong data. Is there a better unit name we could use instead? What about uston? Rorym (talk) 07:16, 27 June 2019 (UTC)

Yeah, there's some more context in this discussion. Off-the-shelf parsers are an interesting consideration. Do we know that it's even practical to use an off-the-shelf parser regardless of st? The good news (or bad news) is that there's seemingly no software support for sh at the moment, so if we change our minds and call the unit something else, all that needs to change is some existing tagging (currently 132 ways). – Minh Nguyễn ^💬 17:06, 27 June 2019 (UTC)

Yards (yd)

I am using "yd" for yards, which is a common unit used to measure distances on golf courses and American football fields. T99 (talk) 20:44, 24 August 2019 (UTC)

@T99: gauge=* also describes yards as a valid unit, so I've added it to the table. – Minh Nguyễn ^💬 23:51, 5 September 2020 (UTC)

Why mention cwt?

A line was just added for cwt meaning "hundredweight", a rare unit of measurement only used 3 times in the whole database: http://overpass-turbo.eu/s/YUQ

Is it really helpful to mention it? With only 3 occurences, I can't imagine any database users adding special support for this rare unit. --Jeisenbe (talk) 07:20, 11 October 2020 (UTC)

It is the standard signposted unit for vehicle weights in one region of the world, albeit a very small one. Unlike some other unit symbols, "cwt" is probably unfamiliar to most software developers and prone to confusion between short and long, so inclusion somewhere on the wiki would be helpful. – Minh Nguyễn ^💬 06:01, 24 September 2021 (UTC)

Where is it used?--Andrew (talk) 07:10, 24 September 2021 (UTC)

30 cwt

@Wynndale: Sorry, I neglected to mention it: the Bailiwick of Guernsey. Not a very significant or large region, to be sure. Aside from that, the current usage of cwt in OSM is in England, probably on private property. – Minh Nguyễn ^💬 06:53, 25 September 2021 (UTC)

Level of precision

I noted that on the maxheight=* page, the current advice is to always add the inch, even if it is zero. I agree with this if the sign explicitly states zero (e.g., max 12'0"), but we should not be adding inch values if the source does not provide this (e.g., max 12'). This page is clear that meters can be provided without a centimeter value (e.g., 3 m, or just 3) but the only feet and inches example includes inches, so it's a little unclear. Might it be worth adding a generic note that the level of precision should match the sign/data source (regardless of unit) to comply with the concept of verifiability? It might help clarify for mappers and data consumers that, for example, a ft-in measurement may not always include the inches? Casey boy (talk) 09:18, 24 September 2021 (UTC)

Sounds good to me. I had always thought of omitting 0" as a matter of aesthetics or convenience, but you're right that it's also important to avoid excess precision. Some of the measured keys are displayed almost verbatim to end users of some renderers and navigation software, so extra precision can be misleading. (If one ever chooses to tag a converted value, the extra precision would avoid rounding error when converting back. However, that's an argument for tagging local units that don't require conversion in the first place, an idea that hopefully wouldn't be controversial in the context of this page.) The right amount of precision can vary by the type of measurement as well: a tree's diameter or height should probably be tagged only up to a certain precision, even if a more precise measurement is available, because the measurement changes over time. – Minh Nguyễn ^💬 07:09, 25 September 2021 (UTC)

Have added a note to the note section about precision. Casey boy (talk) 14:26, 29 September 2021 (UTC)

Volumes

Many features like man_made=storage_tank or water_tank:volume=* have a capacity or volume. The list of units doesn't mention it. Should 'Volumes' be added as well? Typical units could be

• l - liter
• m³ - cubic meters
• gal = gallons

--Mueschel (talk) 08:57, 3 December 2021 (UTC)

Interesting point. man_made=storage_tank says to use capacity=* which is an odd one considering that tag is mostly about the number of people/cars/etc. that can visit/be stored/etc. inside a venue. The documentation for water=reservoir doesn't even mention volume but I could see how that might be useful. I note the key volume=* has only been used 299 times but, in principle, I would support a proposal for volume. Default being m³, with an option to include imperial/other units when specified. Casey boy (talk) 09:46, 3 December 2021 (UTC)

Should also note, we mention flow rate which is volume/time - and the default is (of course) m³/s but with the option to include other units. I think it's perfectly reasonable therefore to update this page to explicitly include volume. Casey boy (talk) 09:50, 3 December 2021 (UTC)

@Mueschel: Yes, in principle, if we're going to standardize flow rate, we should standardize the dimensions it's based on. It probably makes sense to include imperial/customary units, but "gallon" is a fraught unit with multiple meanings. Maybe that's why they were omitted from the flow rate definition. Are there any emerging trends in the database for distinguishing between imperial gallons, U.S. (liquid) gallons, and U.S. dry gallons? – Minh Nguyễn ^💬 20:53, 3 December 2021 (UTC)