From OpenStreetMap Wiki
Jump to: navigation, search

default unit

All similar keys (width=*, maxheight=*, maxwidth=*, maxlength=*, ...) use metres as default unit (if no unit is part of the value). For consistency, I'd add this to the definition of the height key, too. Any objections? --Tordanik 12:54, 6 April 2009 (UTC)


Can this key be used to mark physical clearance, for example in a tunel? I feel maxheight=* is more for legal limitations instead of physical limitations. --Skippern 06:02, 20 July 2009 (UTC)

No. Your feel is right, use maxheight=* for clearance. --Sergionaranja 07:33, 24 July 2009 (UTC)
Actually, maxheight is for legal limitations (which are usally more restrictive than physical limitations). This is apparent from it being illustrated with a traffic sign, listed on the access restriction page and so on.
I'm not sure whether height=* is commonly used for tunnel clearance, but as I cannot think of anything else that would be described as tunnel's "height", it probably can be used for that information. Alternatively, it would be easy to create an own key and avoid any risk of confusion. --Tordanik 11:49, 25 July 2009 (UTC)
I have seen tunnels with 3 lanes noted with left lane maxheight=3.5, central lane 5m clearnance, right lane access=no + motorcar=dedicated. One could probably tag right lane with a height of 3.5 too. Mark that the sign in central lane was an information sign, and not a restriction sign. --Skippern 00:48, 26 July 2009 (UTC)


The left sign is Max allowed height 3m or maxheight=3, the right sign is Physical height/clearance 3.2m, can this be tagged height=3.2 or must another tag be invented for this? --Skippern 03:57, 27 July 2009 (UTC)

i think this last explanation is correct. i would not invent another tag. --Sergionaranja 09:35, 27 July 2009 (UTC)
I would invent another tag if this is supposed to be used not only on tunnels, but also for roads below bridges etc. For these cases, using "height" isn't appropriate and in extreme cases doesn't even work (multiple bridges crossing each other). --Tordanik 11:45, 27 July 2009 (UTC)
Ok, I am making a proposal for a clearance tag. --Skippern 00:20, 28 July 2009 (UTC)

Merge dimensions pages

We should merge Key:width and Key:length into this page or a new "dimensions" page for maintainability and to keep them all describing the same unit notations. Replace the merged-in pages with redirects. We might even want to pull in Map Features/Units too somehow. --achadwick 10:28, 16 June 2011 (BST)

I disagree. They use the same value syntax, but that's also true for maxheight/maxlength/maxwidth, and is not a reason to merge them. Just add a Map Features/Units link on each page and make sure that the examples match the syntax described there. There isn't a lot to maintain - tagging conventions haven't really changed much for these tags, and I don't expect they will. I therefore prefer to stick to the concept of individual Key:* pages for consistency within the wiki. These pages are also a good place to put the key description pages for automated parsing. --Tordanik 13:02, 16 June 2011 (BST)

height on buildings with building:part elements

The page specifies that the maximum height should be specified on the main building element, and lower heights should be specified on thw building:part elements. This is problematic for application that visualize the height information. It is a difficult task to figure out if a building has building:part elements associated with it. A lot of buildings do not have parts, so the sensible thing is to draw an extrusion of the main building element. If building:part elements are present they will be completely covered by this extrusion. It would be more sensible to omit the height key entirely on the main building element and only tag the parts. --Dschwen (talk) 00:37, 13 February 2013 (UTC)

If software can draw height only on buildings, it can take rought information from building=yes and draw this building estimately, if software is more clever, it should not draw height of buildings, which consist from building:part 's, and draw height of each building:part separately. So height on building=yes is rough information about whole building and height of building:part 's is more precise information. Dinamik (talk) 09:40, 13 February 2013 (UTC)
Too bad, this will pretty much destroy my efforts to render 3D buildings. Unless I can come up with a scheme to detect if a building=yes element has building:part=yes elements associated with it. As far as i can see there is no straight forward way to fid that out. You'd have to perform a geometric query to see if polygons (ways) with building:part=yes are contained within a way tagged with building=yes. This is an expensive operation. In my opinion this curent way of tagging is flawed. A tag on the main building element that indicates if parts are present, would be very helpful. Or a separate tag for approximate_height or max_height providing the estimate, while height provides the actual height of the min building part. --Dschwen (talk) 15:52, 13 February 2013 (UTC)
Practice says, that situation is not so bad. 1) Work of shows, that not very complicated and really working method to determine multiplicity of building:part 's into building=yes can exist. As I understand, developer of latlon uses the next scheme: if there is a line, which has role outer both in multipolygon building and multipolygon building:part, we don't render height of this building. Unfortunately, as I see, latlon uses relatively old dump - so we can't test this service on fresh data. The scheme is not ideal in all situations, but it looks working normal in the most of appropriate buildings. 2) A tag on the main building element, that indicates if there are appropriated building:part, has already existed - it is building:parts. Dinamik (talk) 19:09, 13 February 2013 (UTC)
Well, practice is very deceiving. I probably shouldn't even say this, and I will regret it the second I press Save page, because - worst case scenario - some "helpful" user will go on an editing spree and f^&% up all the beautiful buildings that render just fine currently. But, the practice is that this policy of tagging maximum height on the main building element is simply not followed, thank god! I wish it would just stay that way. The relation criteria are rather useless in practice, as many buildings don't have their parts attached through relations. And the relations are useless if all you have to go on is a mapnik rendering database (if you cannot afford to keep two humongous database replicas on your server). It seems to me that this is a case of it's been always like this rather than a case of making the data format application friendly. On top of that I've been told on IRC that adding 3D data to OSM is a nonsense idea in any case and that "maps are supposed to be 2d". So currently I do not have much hope for the situation to improve. I rather expect it to worsen considerably if the current status quo is changed to conform to this policy. --Dschwen (talk) 21:29, 13 February 2013 (UTC)

measurement units are inconsistant

The page suggests to use a space between the measment value and the unit, but it is not really needed (see how CSS removes that unnecessary space). The space is droped when using the notation with single and double quotes. But this notation causes unnecessary parsing difficulties:

  • there's no space so the unit is not directly separable
  • the two parts must be parsed separately.
  • using quotes (and notably double quotes for inches) is very bad for XML. The double quote is not even needed for inches when we already have feet, except that the subdivisions are not decimal


We should allow "4m" as the preferred form (instead of "4 m"), and deprecate the unnecessary space; this would also allow to be consistant with CSS measurements
The basence of unit would defulat to meters (the SI unit, used implicitly everyhere n the world except US, and in aeronautics which uses nautic miles and knots for speeds of aircrafts and ships).
The syntax shoudl then be more consistant and obey to the pattern <number><unit> without any space, possibly repeated to add multiple units
For <unit>, feet may remain a single quote (') for for inches it should be using letters (in) ; using double quotes causes difficulties in XML as it will be presented as """ in OSM XML files
For <number> it must remain an <integer> optionally followed by a fractional part (an ASCII dot "." and a mandatory unsigned integer possibly null); leading zeroes in the integer part, and trailing zeroes in the fractional part should be eliminated (a lenient parser may still accept these unnecesary zeroes, a null fractional part should not need any dot, except if followed by digits specifying an expected precision, so "1" and "1.0" are valid: but "1." is not valid and ".1" is not valid as the dot if present should always be between digits)
the notation <1'23> is also invalid (it specifies the unit for the first part bit not for the second one)
notations using quotes should be deprecated as they are contextual (we also use them for degrees/minutes/seconds, which may be accepted but only for data input in editors, not for storages where we use decimal degrees)
the list of units should be restricted to only those that are customarily used; exotic units specific to one country should be avoided (so heights and elevation/altittude should probably only use meters; but height may still use feet/inches for trafic limits, such as maxheight to pass bewlo a bridge or through a tunnel, simply because this is the unit used on trafic signals; in most cases the unit is infered from the country, but in some countries both units may be used and explicited, e.g. in Canada in a narrow area near the US border)
for altitudes however (above mean sea level according to an elevation model which is specific to a country , there's no use of feet.

My opinion is that it should be to editors and renderers to convert the units and the database should only store SI units; but we know that speeds are almost never in meter/second but in mph (in US only) or km/h everywhere else; this is only tolerated for speed limits signaling for trafic calming. However we know that it may cause problems near terrestrial US borders (near Canada or Mexico) when the border has many irregularities., and to avoid problems both limits are displayed with some tolerance (about 5 to 7 km/h, or 5 mph) depending on the type of vehicle used. In those areas both limits are displayed and OSM should be able to store both, separated by a semicolon and with an explciit unit, such as "maxspeed=60mph;90km/h" (the order is not significant, drivers may use one or the other)

Even if editors accept single and double quotes for feet/inches, they should convert these unit sumbols into "ft" and "in" when storing in OSM database, they will accept spaces on input, but will drop them on storage; they will acept commas for decimal separatots but should replace them biy dot on storage. Stored number can still be converted back to use other symbols according to the locale used by the final viewer (it will be a basic job for the renderer software).

Verdy_p (talk) 19:38, 4 April 2014 (UTC).

Varying height

Objects that are inclined, or are present on an inclined surface vary in height. For example, the retaining walls/bridge abutments often slope to the ground or to a lower height; and there is a definitive height of the retaining wall on both ends; the retaining wall doesn't necessarily have to start/end at the ground (height=0). To supplement incline=%/°/up/down, I think it should be possible to specify height on either end of the slope. It could possibly be tagged height:front= and height:back=; I really don't think "front" and "back" are the best ways to specify a specific end of the object, though, but off the top of my head I cannot come up with better terminology.

--YamaOfParadise 20:04, 22 February 2015 (UTC)

If you want to specify different heigts for both ends of a way, you may use :start and :end, which is already in use together with kerb=*. If you want to specify the height for different parts of an object (e.g. the front of a building) I don't think there is another solution than split up the object and put appropriate height-tags on each part. --Imagic (talk) 12:23, 23 February 2015 (UTC)

Bridge steepness

Can height of a Key:bridge way be used to indicate the maximum elevation difference between the floor at the beginning of a bridge and the floor at its top? The aim would be to estimate steepness, especially for bicycle routing. Nemo (talk) 20:40, 7 December 2015 (UTC)