From OpenStreetMap Wiki
Jump to: navigation, search

Physical restriction instead of legal restriction

I have made a proposal for physical height restrictions instead of legal ones. As I have written on the proposal and on the mailing list, many countries have different signs for the two. --Skippern 01:38, 31 July 2009 (UTC)

Someone recently changed the definition of maxheight to be for a specifically "legal" height limit, which was not the case in the past (e.g. it was frequently recommended for use on ways passing under bridges or trees, which is a physical height limit, not legal). Therefore I would recommend reverting the definition of maxheight to a height limit in general, and if more specific information is available, specifying the kind of limit with either maxheight:legal or maxheight:physical. --Waldo000000 23:40, 1 August 2009 (UTC)

"... which can be either a physical or legal limit, or the minimum of those, or both". Alv 23:54, 1 August 2009 (UTC)
I think the user doing the edit did that in response to his opinions of my proposal. IMO it is wrong to start edit tags in the middle of a proposal process. --Skippern 01:50, 2 August 2009 (UTC)

This page + legal + physical

This page should stay as it is, as it will not alter the meaning of things already tagged, the two other tags for legal and physical maxheight are still not supported by rendering and routing, so atleast for now they should be used together with maxheight. --Skippern 16:15, 17 October 2009 (UTC)

Just for the record (this is being discussed in enough places already): I disagree with that suggestion. Instead we should
  • keep maxheight for legal restrictions
  • use maxheight:physical for physical restrictions
  • not use maxheight:legal at all. --Tordanik 01:49, 18 October 2009 (UTC)

Non-legal usages of maxheight

According to tagwatch there are about 100 usages of maxheight in Norway, they are marked by triangular warning signs and not circular restriction signs. I think the same applies for Sweden and Denmark also, another 100 or so usages. I couldn't get any information about usages in Brazil, but both legal and physical restrictions are used, I have tagged all height restrictions whether physical or legal with maxheight and maxheight:* - if anybody from other countries can add in on the usages, than it is easier to see how widespread non-legal usage of the tag really is. --Skippern 01:36, 18 October 2009 (UTC)

Norway have no triangular maxheight signs, just round. UK have triangular signs. Gnonthgol 16:42, 18 October 2009 (UTC)
UK now uses circular signs which prohibit rather than warn. And1969 (talk) 22:10, 13 May 2014 (UTC)
Tagwatch shows 157 uses in Finland, out of which I know about 10% to be unposted and roughly measured (cycleway!) limits or from square signs denoting physical limits. There could more in other cities. Alv 10:44, 18 October 2009 (UTC)

Removable barriers inflicting maxheight restriction

In Ireland (and probably in other places), there are quite a few parking lots etc., that have a barrier enforcing a height restriction. This is not because there isn't the height available, but more to prevent trucks, big vans, campers etc. from entering the area. These barriers can be opened to let bigger vehicles in, if need to be, but you'd need to contact somebody who has a key.

I'd propose to use something like maxheight:barrier=removable or the likes, to indicate it can be organised to get access with vehicles higher than the restricition posted. Not sure, if that's a good idea. Marlow 00:28, 23 February 2011 (UTC)

How about adding a tag removable=yes (or something similar) to the barrier? A tag like that could be used for all barriers, regardless of the exact limits enforced by the barrier - height limits, width limits, vehicle class limits ... --Tordanik 05:52, 23 February 2011 (UTC)
There is no barrier mapped, because there is no barrier. Well, there is a barrier that enforces the height-restriction, but everyone that doesn't exceed the height-restriction can enter freely and there is no type of barrier in the list (of the documented ones), that would fit that description. Marlow 10:14, 23 February 2011 (UTC)

There is barrier|height_restrictor

For removable height restrictors I tagged maxheight:conditional=none @ private.--Jojo4u (talk) 19:52, 14 April 2015 (UTC)

maxheight for areas and ways only?

Is it still the current consensus that maxheight should be used on areas and ways only? Taginfo says that quite a few people already use this tag on nodes. You could (for example) use it on Tag:barrier=sally_port or on ways below bridges. I'm not sure if splitting a way up just to set maxheight on a very short way is the right solution. --Frankst 11:34, 9 September 2012 (BST)

There is one case where maxheight on nodes might be appropriate: When the node has a barrier=* tag. But for ways below bridges, splitting the way is the right solution. Otherwise, some applications (one I know from personal experience is to use the maxheight of the ways below the bridge as a lower limit for bridge height in 3D rendering) just wouldn't work. --Tordanik 15:32, 9 September 2012 (BST)
Maybe that program should be improved to allow a node with maxheight=* also work for that rendering? Tagging for specific software is just like tagging for the renderer. We should tag what is appropriate and the software should adapt to the way we tag, not contrary. --Skippern 18:20, 9 September 2012 (BST)
A problem with using a node here is that the node is never under the infinitely thin bridge way if you look closely enough, but always next to it. One could try to work around this with assumptions about how wide the bridge is or other fuzzy metrics, but this might be slower, more importantly, it would certainly be less reliable. With ways, you just perform an intersection test - and because mapping this situation by splitting the way has worked just fine for the last few years, I don't see any reason to introduce an inferior alternative tagging style.
Oh, and if you believe that this has anything to do with Tagging for the renderer, you clearly don't understand what that catchphrase actually means. --Tordanik 20:03, 9 September 2012 (BST)
I am not saying that a node would be best tagging practice, I am just saying that I find your argument invalid as it resembles Tagging for the renderer. Using how some obscure or technical software use OSM as argument for tagging is NOT valid arguments in dictating best practice. If there is any good reasons for tagging maxheight as node, than the software should adapt to the tagging, not the tagging adapt to the software.
Maybe the developers of your software (you?) should look at how maxheight:marine=* is used? Maybe that is a better way of tagging bridges anyway? Besides I (and probably almost everybody) already tag how you explain that software to work, though I can see a lot of inaccuracy in it towards your software. I was once in a situation where a bridge had to be measured on 15 points in order to get a cargo under it, I am not suggestion that we are going to put all of that tagging into OSM, though your software should probably love to see it. --Skippern 20:19, 9 September 2012 (BST)
It is not "tagging for the renderer" to take the needs of applications into account when defining a style of tagging. Maybe you believe that there should be a rule invalidating such considerations, but "don't tag for the renderer" is not that rule.
The maxheight:marine style of tagging maxheights on the bridge instead of the way below could also be used for height calculations, but as far as I can tell it would be somewhat challenging for routing when applied to roads. Most importantly, though, it is almost unused according to taginfo and opposite to current practice.
As for more detailled tagging of the clearing above roads: That might be even more useful for some applications, but as you acknowledge yourself it's unlikely that it would be widely adopted. In general, I do not see how this idea is particularly relevant for the discussion whether maxheight on nodes should be an accepted tagging style for ways below bridges anyway. --Tordanik 21:18, 9 September 2012 (BST)
I admit that the use of maxheight on the road under the bridge is more in line with the practical need of the information same as maxheight:marine on the bridge. Anyway I don't see why maxheight shouldn't be tagged on single nodes either, if it can be seen as useful. For me it is usefull to know that a stretch of road have maxheight=5.2, and a bridge have maxheight:marine=42, and see no problem that an entrance to a building can have maxheight=2.2. None of these examples are Tagging for the renderer as I see it, as all three examples have good useful information. Tagging for the renderer is when you dictate, or even worse deliberatly wrongfolly dictate tagging because of a desired result in some software. --Skippern 22:46, 9 September 2012 (BST)

Estimate max. height?

What about covered roads where no maxheight sign is available? This happens a lot for entryways to backyards which go in a tunnel through the house (examples: [1], [2], [3]). Should I estimate the physical height? And/or indicate somehow that no maxheight sign is available?

maxheight:physical=3 + source:maxheight:physical=estimate. Or buy a ultrasound based distance meter (should be way under 20 euros by now), and source:maxheight:physical=ultrasound with a more accurate number :) As far as I've tested, angle based measuring from afar with a mobile and a suitable app is not close enough - errors of 0.5 meters, or even more, were too common with the heights involved in road objects. It can be better with some phones, but one must "calibrate" their app beforehand. Alv (talk) 22:37, 25 May 2013 (UTC)
@Alv: wow, this sounds extremely cool. Did you already blog about this? Love to see more details and pics.
@Oliver: in situations where no maxheight sign is available, you could use maxheight=none. According to Taginfo this is commonly used by now, although it has a some shortcomings. For a more detailed discussion please see discussion in German Forum (Google Translation to English is good enough to get the general idea). Maxheight Map also interprets maxheight=none and marks those ways/nodes in green. Mmd (talk) 09:10, 26 May 2013 (UTC)
There is even more discussion going on about which value should be used for height restrictions without signs: where different options are noted. Even though any mapping is better than none it seems to be a rather small issue so solving it in some convenient, generally acceptable way should be easy. Maybe some poll with the three or five most popular solutions would be good, followed by some voting quickly after. --HybridOL (talk) 13:52, 30 January 2015 (UTC)

Imperial Symbols

A large number of UK maximum height signs use prime (0x2032) and double prime (0x2033) with a hyphen separator instead of ASCII apostrophe and double-quote. I would prefer that maxheight corresponds precisely with what is shown at the height restriction site and that routing agents improve their parsing to handling this. --Pink Duck (talk) 10:54, 11 November 2013 (UTC)

I do not think this is a major priority. If we agreed this we would also have to accept distances in metres with a Cyrillic lowercase 'м' because that is the standard symbol in Russia, Ukraine etc. And1969 (talk) 22:22, 13 May 2014 (UTC)

Lanes and non-horizontal bridges

The underside of a bridge is often not horizontal, so that the maxheight is smaller at the inner lanes. Sometimes this is indicated on the signs. E.g (4.3 m) (4.1 m)

How do we map this? We could split the road into separate one-lane roads. But they are not really separate roads.

If we only use one maxheight, which one should be used. For routing purposes the high value would be best. For safety warning the lower value vould be most useful. Elgaard (talk) 15:28, 21 July 2016 (UTC)

It's a rare situation, but maxheight can be used with [Lanes] tagging. Example of a road with 4 lanes and 3 m height limit on inner lanes only in a right-hand traffic region:
In addition you can tag the higher limit with key maxheight, in my example maxheight=default. This is useful to support routers which are not aware of lanes tagging, and it is ok to use the additional tag because the road is passable up to the higher limit.--Slhh (talk) 21:54, 21 July 2016 (UTC)
Thank your That seems like a good solution. I have now used it on . I do not think that the situation is that rare. There are a lot of older bridges, especially in Europe that are quite rounded Elgaard (talk) 22:40, 21 July 2016 (UTC)
It gets more complicated [4]. First the maxheight are different in the other direction: 4.5, 4.2. And there is three lanes in each direction and I cannot read the leftmost maxheight on the mapillary images. Elgaard (talk) 20:50, 22 July 2016 (UTC)
The maxheight lanes tagging on this way should be without the .3 in the key: maxheight:lanes = 4.3|4. I think this is just an oversight of you since the others are correct.--Jojo4u (talk) 11:11, 23 July 2016 (UTC)
The key maxheight:lanes.3 has a typo, but the value default|4.3|4 is ok, provided that the yellow signs indicate a legal height limit. Unfortunately, I don't know the Canadian traffic rules. What does the yellow sign really mean? A legal height limit? A physical clearance? A recommended height limit (physical clearance minus safety margin)?--Slhh (talk) 13:29, 23 July 2016 (UTC)