Signposted vs. actual
Now that the Maxheight Map highlights so many ways under bridges, where we don't know the physical clearance, that I bought a ultrasound distance meter. Seems to work reasonably. However, I checked the guidelines on use of road signs, once again, and I concluded that there's still one untagged distinction left. The number on signs like
is supposed to be "actual clearance rounded down to 0.1 m, minus 0.1 m". It's mostly to account for day-to-day differences in truck tyres, but also for snow on the ground and on top of the truck. And to some extent because the road can curve upward next to the height limited spot, and the midpoint of a longer vehicle can then be temporarily higher than the vehicle height suggests.
Objects with maxheigh:physical=* have been last touched by 118 users, so it's hard to say which values are measured, and which are rounded down signposted values. Both values would have use cases, especially where the height does not exceed the 4.2 or 4.4 meters after which the transport becomes subject to "special transport" restrictions and rules. Alv (talk) 14:00, 23 March 2013 (UTC)
It seems that the keys maxheight:legal=* and maxheight:physical=* only make a difference for verifiability and/or checking sources. It seems most (if not all) people also add maxheight=* to the same way, therefore making the subtags redundant. Shouldn't we simply add maxheight:type=physical/legal instead? --Jgpacker (talk) 21:15, 26 October 2014 (UTC)
- No, it should be possible to add both to the same way, as the values are often not identical (the legal maxheight is usually chosen conservatively for safety reasons). --Tordanik 09:58, 27 October 2014 (UTC)
- There are ways working around that as well, though might require more syntax analysis of data-consumers, one way is something like maxheight=3.4;3.3 + maxheight:type=legal;physical. This complicates if one tags different maxheights based on lanes, but destination=* among other tags have resolved that to some degree. I am open to suggestions that might improve data quality and data reliability, but until a good replacement are suggested I stick to the current tags, even if data might appear redundant. --Skippern (talk) 11:05, 27 October 2014 (UTC)