Talk:Key:height

queries on value

Page suggest using "m" for meters as an option. Will queries on values work in case ie: "height = 27 m"? If not, I'd suggest to clarify it on page. Cascafico (talk) 10:27, 23 April 2021 (UTC)

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)

clearance?

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 4.5m, can this be tagged height=4.5 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 http://latlon.org/buildings 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

So

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)

Tanks extending into the ground

Mention how to tag:

An open water tank, made of cement,

-----|      |----
     |      |
     |      |
     --------

extending from the surface into the ground three meters.

A similar one, one meter above ground, and two meters below.

     |      |
-----|      |-----
     |      |
     --------

Jidanni (talk) 20:06, 1 August 2019 (UTC)

OK:

height=0
depth=3

height=1
depth=2

Jidanni (talk) 20:10, 1 August 2019 (UTC)

I would expect the tag height to indicate the height of the feature, so it shouldn’t matter whether it is in the ground or not, the height of your tank in the example would always be “3 m”—Dieterdreist (talk) 20:49, 1 August 2019 (UTC)

Well then how shall one distinguish them? My friend fell in to one and almost drowned. You can't see them on the surface if they are covered with weeds. Jidanni (talk) 21:17, 1 August 2019 (UTC)

I don’t question it should be possible to map it and distinguish these cases, but height is not the tag for it. I suggest you ask on the tagging mailing list.—Dieterdreist (talk) 21:33, 1 August 2019 (UTC)

I'm fine for now, but I'll be happy to use whatever you guys finalize. Jidanni (talk) 22:34, 1 August 2019 (UTC)

Cell towers on roofs

Mention if we should add the building height, or just the height of the tower itself. Jidanni (talk) 14:22, 7 June 2020 (UTC)

It is already written in the first sentence: The key height=* describes the actual height of a feature. this means it is the height of the cell tower. You can add sth like support=roof if you want to emphasize with tagging that it is indeed on top of a building.—Dieterdreist (talk) 23:05, 7 June 2020 (UTC)

Good. (Yes, but "actual" with no examples of what is actual and what is not actual, will mean different things to different people. So please add an example to the page.) Jidanni (talk) 23:38, 7 June 2020 (UTC)

Maybe use:

Height of storage tank on roof:

1. 1 meter? actual tank
2. 2+1=3 meters? (It has a 2 meter support scaffold underneath it)
3. 12+2+1=15 meters? (add building)
4. 234+12+2+1=249 meters? (and above sea level)

Answer: #1. Jidanni (talk) 23:43, 7 June 2020 (UTC)

Hmmmm, but for antennas one would probably say 3 meters, as usually the support is included... And also for water pressure, one would talk about 3 meters too! Jidanni (talk) 23:49, 7 June 2020 (UTC)

(https://commons.wikimedia.org/wiki/File:Phony_water_tank_real_cell_tower.jpg is both a "water tower" and an antenna!) Jidanni (talk) 01:24, 8 June 2020 (UTC)

If the height is measured in a different unit, the unit abbreviation is appended to the value,

If the height is measured in a different unit, the unit abbreviation is appended to the value,

Then immediately there is a feet example with no units appended. Jidanni (talk) 19:48, 18 June 2021 (UTC)

Are you speaking about " height=7'4" "? It is specifying units? Mateusz Konieczny (talk) 14:45, 19 June 2021 (UTC)

Which relations?

I suggest discussing here, not in summaries.

I have edited several thousand Wiki articles. I try my best to make the documentation complete, consistent and as detailed as possible. Only a small fraction of keys and tags are used on relations. If you think this one is used on any relations please list them. Maybe we have incomplete documentation and and will need to complete it. I spent a lot of time and looked through all the relations and [height] only appears on the relation "Bridge". Please list other relations if there are any. Please provide rational arguments in the discussion.

Your arguments:

• "it’s also used with type=building" - it is incorectly used on this relation because it only collects building elements into a whole, it is not used to add building properties.
• "and likely more" - please list them Dieterdreist. Relation:bridge is the only one listed on the Wiki. Your statements are based on some premises. What are those premises?
• "if you know and accept ..." - False assumption. No, I don't know and I wrote about it earlier. maro21 21:13, 1 March 2024 (UTC)

Hunting stands in German-speaking countries

This section is, according to its title, mainly used in German-speaking contries. But in the DE: version of this page, they don't talk about it : on the DE: page, height should be a number and only a number. Second point: there is no wiki page for height:full or half or low so impossible to know what it means/when to use it. So I suggest to remove this part from the English version. Yunan973 (talk) 13:55, 21 June 2024 (UTC)

The section describes that such values of this key are used. There is nothing incorrect about it, so the section should stay. On the Wiki we describe the use of a given tag, whether it is correct or not. maro21 16:08, 26 June 2024 (UTC)