Talk:Map features/Units

From OpenStreetMap Wiki
Jump to navigation Jump to search


"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, 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)


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: 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)


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 ? 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:

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)