Talk:Buildings

From OpenStreetMap Wiki
Jump to: navigation, search

Joined buildings

Resolved: The convention is to share nodes for common walls. Just one building is a good first pass drawing.

If there are 2 or more separate buildings that are like "stuck together"(the one being built right next to the other without any air separating them), should I add it as one building(?), or two with very close borders? By default I would add it as 2, but I'm interested in opinions Logictheo 00:19, 22 August 2008 (UTC)

I've managed to understand how to do this. It was a practical issue on how I could do it in josm. Logictheo 13:07, 15 September 2008 (UTC)
How did you do it? — Sam Wilson ( TalkContribs ) … 04:12, 3 October 2008 (UTC)
JOSM's new extrude tool followed by splitting the extruded object at the right two points and extending both of the resultant ways to be loops again does the trick for me. --achadwick 14:14, 12 January 2009 (UTC)
Hmm. I can extrude one side of a building like that, but I still get a message from the validator about overlapping ways. It's just 'info' level, so I suppose I can ignore it, but is there any way to deal with this that the validator actually likes? I thought the right way to do this would be to have the two buildings share one side, but I can't figure out how JOSM would do it, and the validator might choke even worse on that. grendel|khan 16:05, 26 February 2009 (UTC)
The Terracer plugin: JOSM/Plugins/Terracer may also be useful, or at least it confirms that shared walls mapped as overlapping ways (with shared nodes) is a widely used approach. When mapping joined up buildings manually, the unglue and merge tools come in very handy (often in short succession) -- Harry Wood 01:32, 3 December 2010 (UTC)

House numbering

Resolved: addr=:* tags have established themselves after this was asked.

I added the house numbering proposals. Are there any more proposals dealing with this ? Nochmaltobi 20:04, 1 November 2008 (UTC)

If there were, they don't seem to have any support. Somebody could tell us in English how the Japanese do addressing, though. Alv 07:29, 8 February 2012 (UTC)

Canopies

Resolved: Add covered=* for the feature below the canopy, and elevate the building overhang.

Some notable buildings have huge canopies that I feel need to be considered when one starts to add the surrounding pedestrian areas in detail. So far for few such I've drawn a separate area for the canopy and have used building=canopy + layer=1. Yet this proves to be suboptimal, since for example a railway station the rails and platforms get hidden... Would it be good to have a separate (rendered) tag for canopies? That would allow for a more consistent description of some mainly pedestrian areas. Outdoors - under the canopy - inside the railway station. Alv 16:27, 15 December 2008 (UTC)

City Buildings

Resolved: Try to find the actual location of the wall, not some imaginary point in the middle of the road.

How should one form buildings which abut the surrounding streets? E.g. when looking at [1], most of the mapped buildings can be touched when standing on the sidewalk between them and the actual lane. Currently they seem to be drawn to match the Yahoo! images, but this leads to IMHO ugly "white" space between the buildings and the street when zooming in. On the other hand, reusing the street's nodes for the building, also leads to [strange overlappings in mapnik] (see Piaristengasse/Piaristengymnasium). Please advise! --David Schmitt 17:01, 28 December 2008 (UTC)

Positioning the walls where they are is correct. Reusing the road nodes would mean that the buildings touch each other when in reality there's a road in between. If the road elements were eventually drawn as areas and if there was an agreed way, such highest zoom maps could use those to draw the roads at their exact width. Using JOSM you can adjust them so that the distance between the walls on opposing sides of the streets is realistic or accurate if you measured it - but visual estimation of the width of the road leads to quite good results (say, "here's two lanes of about 2.5 meters each, parking spaces of 5 meters and two sidewalks of 3 meters each") Alv 07:33, 29 December 2008 (UTC)
Yes. We used to do it the other way in Oxford for college buildings - very unmaintainable. Admittedly the whitespace and overlap can be ugly sometimes, but that's a renderer issue, and you shouldn't attempt to fix it in the data.
It's a bit less true of landuse areas because those are slightly interpretation-based anyway. I prefer to not abut them to roads and paths for maintainability. --achadwick 14:19, 12 January 2009 (UTC)
I agree with the idea that buildings should not touch the roads in OSM. We mark the center-lines of roads and not the actual area of the road so making buildings touch these center-lines is wrong. --Seav 10:47, 14 January 2009 (UTC)
Start adding sidewalks - their position will indicate the width of the road at high zoom, and make the buildings appear closer to the highways. Ojw 10:17, 2 August 2009 (UTC)

Estimated height

Resolved: Most people use height=* even for estimates - mappers seldom have access to accurate data anyway.

Why not adding a tag estimated_height=integer in order to be compliant with a mapnik feature, which allows to draw pseudo-3D representations of the buildings ?

See The mapnik feature, and This link for a rendered example

Because we already have est_width=* and should therefore call that tag est_height=*. --Tordanik 15:06, 31 May 2009 (UTC)
just call it height= -- everything in OSM is estimated and can be improved further if someone finds better information - you don't need to send renderers searching through a whole slew of different tags just to get the height. Ojw 10:19, 2 August 2009 (UTC)
IMO if you know it's a very rough guess, one could add a note=* or, say, source:height=rough estimate. Alv 07:29, 8 February 2012 (UTC)

House Numbering II

Resolved: Only the french and russian pages still have a link to the less used relation.

Mentioning two address-schemes was good, when it couldn't be determined which one will be used more frequently. Now the Karlsruhe Schema by far outnumbers Relations/Proposed/Postal Addresses, so I removed the later for clarity. Relations/Proposed/Postal Addresses seems to be abandoned anyway.

I also adjusted the de-translation, but my frensh, japanese and russian language-skills are...well...limited, so they have be done by somebody else. Nochmaltobi 15:46, 10 January 2010 (UTC)

Covered area?

Resolved

How do you tag an area with a roof but no walls? --NE2 16:38, 19 February 2010 (UTC)

Some use man_made=canopy, sometimes it's and/or amenity=shelter. Alv 17:11, 19 February 2010 (UTC)
covered=yes was recently approved for this. --goldfndr 11:04, 23 February 2010 (UTC)
covered describes the thing (often highway=pedestrian or similar) under the canopy, man_made=canopy the structure containing the roof. Alv 11:17, 23 February 2010 (UTC)
I use building=canopy for structures that cover fuel stations and I would use it with covered parking spaces (carports), loading docks and passenger platforms as well. Canopy could also describe an open tent, an awning, a gazebo or a pavilion under which people may gather or which gives pedestrians some protection from sun or rain. The word canopy is more specific in meaning than building=roof because almost any type of building will have a roof. Note: if there is a driveway under the canopy, JOSM gives a warning about crossing ways unless I also set layer=1. --T99 20:15, 30 July 2011 (BST)
Unresolved: building/building:part are the most common tags.

How do you tag a building part if it is covering another area and is accessible below?

Examples:

--Cracklinrain (talk) 00:10, 13 February 2014 (UTC)

Terrasse?

Resolved: "Terrasse" as a value is dying out. "Terrace" is used for "row of linked residential houses".

"Terrasse" is a German word. The English term is "terrace" (some English dictionaries define "terrasse" as a verb but I found no support for it to be used as a noun or an adjective). As a building tag value, would it mean a covered patio, a row of townhouses, a level paddy on a hillside, or something else? --T99 08:39, 18 February 2011 (UTC)

If you ask me, as i also see, this, from my German viewpoint, I think Dieterdreist [2] mean a level paddy on a hillside, but better ask him. It would good to also have terraced (for terraced houses or German "Reihenhaus"), as terraced houses are also commom here, even when many of them are blocks. --Fabi2 20:16, 18 February 2011 (UTC)
A "paddy" is literally a rice field. By extension, tag building=terrace could mean "terrain artificially graded to resemble rice fields". -- T99 20:47, 18 February 2011 (UTC)
I can see "terrasse" has been changed to "terrace" quietly. --T99 19:32, 7 May 2011 (BST)

There's two different uses of the word "Terrace" in English. We do use the word for "terrain artificially graded to resemble rice fields" (wikipedia:Terrace (agriculture)), which has nothing to do with buildings and more to do with landuse=farm. On this page however, building=terrace "Row of linked residential houses" is referring to another meaning of the word: wikipedia:Terraced house. Does that clear up the confusion?

As an aside... building=terrace seems a bit pointless to me. I'd use building=house. The fact that they are terraced houses, is (A) implicit within the layout of the ways anyway (B) not very interesting/significant and could be tacked on (by anyone who cares to do so) as a lesser tag e.g. building=house, house=terraced, but I guess that might depend on the granularity of different tags we're using with the building key. I mostly map with building=yes anyway :-)

-- Harry Wood 10:10, 25 May 2011 (BST)

I or me and some others have used building=terraced for the whole long-and-low building, when it's address wise under one house number, and the construction of the building implies it being one big structure as opposed to several houses that just happen to abut each other. They are virtually always one legal entity (although the next building somewhere near might be a part of the same housing cooperative, too). One additional criteria being that the apartments within such a building probably never occupy space above or below each other, and each has their own ground level entrance - in that sense the bits are individual houses. Alv 10:44, 25 May 2011 (BST)

--

Unresolved: “terrace”≠“terraceD

In German language (I am from Austria) we do use „Terrasse“ for the following things:

  • At buildings it is some in some way paved area (either on the ground e.g. in the garden directly joined to the house called „Terrasse“ (in English language “terrace”), or on a flat roof of a house called „Dach-Terrasse“ (picture) i.e. “roof-deck” or “roof terrace” in English language) on which the inhabitants of that house use to sit and enjoy—very often barbecueing food, etc.
  • And there is the „Terrassenhaus“ (picture) (“stepped building” or “terrace house” in English language). (Caution! It is by no means equal to a „Reihenhaus“ (in English language “terraced house“!!! “terrace”≠“terraceD”))
  • And than there are artificially flattened terrains on hills (not in the plain i.e. not on level land!) that are some times used for agricultural purpose like rice planting (see there, picture) (picture of some wine garden), but not only for that purpose (picture of the Erzberg mine). Normally we use the plural form „Terrassen“ for this. (For those speeking german: more about it there).

Kalten666 17:00, 17 February 2015 (UTC)

Storage tank?

Resolved: At 42k+ uses, man_made=storage_tank seems established.

This page used to recommend building=storage_tank but now it recommends man_made=storage_tank instead. However, man_made=* does not list "storage_tank" as a recommended value. This is inconsistent. Which tag should we use? --T99 19:43, 7 May 2011 (BST)

Well man_made=* doesn't list man_made=storage_tank yet I suppose because it's under discussion at Proposed features/storage tank -- Harry Wood 10:21, 25 May 2011 (BST)

Node or Area?

Resolved: Building nodes are an acceptable first pass mapping attempt, but will eventually turn to areas.

The table at building=* defines most values as applying to areas (closed ways) only. Is this just an oversight or has it been deemed undesirable to map a building as a single node?

A typical new residential house in my area has up to 16 or more corners, partially obstructed by eaves. I am mapping most such buildings as a single building=house node, with address tags when known. If someone doesn't approve of this, they are welcome to come and trace the other 15 corners. :-)

Btw, some houses happened to be under construction with bare foundations visible in my high-resolution aerial imagery sources (February 2006 USGS Ortho or, in some areas, ~2009 Bing). In these cases I generally trace the full outline.

--T99 21:15, 24 December 2011 (UTC)

Sounds very reasonable. You add a node and the address and if someone wants to turn them into areas then they can do so. However... if you feel like doing simplified areas with less corners that would also be good. It is easier to add corners to an existing area than to a node. Personally I would encourage you to do a rough outline. PeterIto 21:32, 24 December 2011 (UTC)

Common values

I looked at tagwatch and added some common values to the page. But there are values that probably shouldn't be used, like: building=industrial, building=residential, building=way and others. Please give some input about how to mention this on the page.--Sanderd17 09:57, 2 December 2010 (UTC)

The point is that the value should describe the topology, not the function of the building. The function can be described with other tags, eg.
  • landuse=residential + building=house instead of building=residential
  • amenity=school + building=house instead of building=school
building=way seems absurd. Maybe this is meant for covered ways (now we have covered=yes for this) or the connection of buildings above a separating street. --Fkv 19:25, 23 January 2011 (UTC)
Listing a tag like this doesn't make sense if we don't even know what it means. The wiki isn't a copy of taginfo - it contains tag definitions. building=way doesn't have one, so I removed it --Tordanik 14:32, 24 January 2011 (UTC)
Please do not tag the building with landuse=* or amenity=*, because you may run into conflicts respective the name. Furthermore naming the landuse with the POI information can IMHO be tagging for the renderer, if there is a name. Usually I would use name=* in context with landuse=* only, if it is the name of an area or place and not a POI. Therefor I suggest to map the for example retail-relevant ground as landuse=retail and keep the objects distinct from the building.--U715371 (talk) 23:38, 4 December 2014 (UTC)

I wonder why there are so many building=hut in tagstat, but no building=cabin? I am not an English speaker, so I have to trust the dictionaries and websites. It seems that huts are dwellings of poor people, not necessarily made of wood, while cabins are made of wood but not necessarily for living. Shall I start tagging cabins as building=cabin, or stay with building=hut? --Fkv 19:25, 23 January 2011 (UTC)

Types of residential buildings?

What would be a preferred values to tag buildings that contain many residential dwelling units? (There is no question about a building with only one such unit: it's a building=house.) I can see at least two seemingly distinct cases:

  1. Each unit occupies an entire vertical section of the building; there are no other units directly below or above the unit. Each unit has one or more levels/floors/storeys and may have some integrated parking space (a garage or a carport). At least some part of the building structure is shared between the units. In the US, this is called a "townhouse". In the UK, this is called a "row house" or a "terraced house" (the distinction seems vague). Is there a more descriptive tag value than the rather generic building=residential?
  2. Units are situated on different levels, below or above other units. Each unit usually has only one floor (though there could be some multi-level units such as penthouses). The building may also contain some commercial/retail or parking space typically on or near street level. The building may stand alone or be attached to adjacent (but structurally independent) buildings. This is known as an "apartment building" in the US and as a "block of flats" in the UK. I have seen the undocumented value building=block used but I find it ambiguous (a "block" is primarily an area of land that may contain many attached or detached buildings).

Note: I use landuse=residential for parcels that contain multiple residential buildings built or managed by a single administrative entity (for example, an "apartment complex").

Note: The word "duplex" is apparently used for any building with exactly two units, regardless of whether one is next to or on top of the other.

-- T99 21:14, 18 February 2011 (UTC)

1: building=terrace was once recommended somewhere, and at the moment it's somewhat popular (2772); nothing relevant is used more. I've seen building=residential described and used on very different buildings, from single family "house" to multi-storey apartment buildings.
2: building=apartments is widely used and afaik the most unambiguous, but can it refer to something else, too? Some use building=block, which imo refers only to the phrase "block of flats", but which maybe encompasses too many kinds of buildings?
The value I think needs clarification (from taginfo) is building=hut - somewhere it says it's akin to a small "house", just "not of stone" (and elsewhere it was proposed as "in villages"), yet dictionary definitions refer more to a primitive house - could be a summer hut in the woods... If a normal house can be a hut, then what is a primitive hut occupied only few weeks at a time? Or a summer habitable hut in the allotments? Alv 11:54, 19 February 2011 (UTC)
A neat thing to do would be a *drumroll* gallery of building types, each with applicable tags. Alv 13:27, 19 February 2011 (UTC)
As in here: Key:building/Gallery. Alv 13:17, 26 February 2011 (UTC)
I agree that a "hut" is generally a very primitive building, often built on bare ground from unprocessed wood, straw, mud, dung and other such materials that can be readily found in the environment. I suggest that the tag building=hut be reserved for such primitive buildings. I don't think that the presence of absence of stone in the walls should be a factor. (Many if not most modern houses in temperate climates are built from wood.) I'll update the definition unless there are objections.
Another term to consider as a tag value might be a "cabin". A cabin is typically smaller than a house, often built from wood and used as a permanent or (more commonly) seasonal residence. Unlike a hut, there is not necessarily anything primitive about a cabin -- some cabins come with hardwood floors, indoor plumbing, a fully equipped kitchen and laundry facilities, a big-sceen blu-ray entertainment system and a high-speed internet connection. -T99 00:52, 8 May 2011 (BST)

Name of buildings with several singular parts

Resolved: Use building:part=* instead of building=* and draw a way tagged as building=* around.

When adding more details to buildings with singular parts, each part gets the name of the building, usually causing the name to be repeatedly plastered all over the map. Should I make a single, separate overlapping path with the name alone for these scenarios?

Not if they are not physically connected. You can group them with a relation; whether the renderers support this is their choice. --NE2 16:35, 25 May 2011 (BST)
I grouped them as a multipolygon, with every building part as a outer role. Is this appropriate? --Micket 27 May 2011
Probably. --NE2 14:27, 27 May 2011 (BST)
This still renders with multiple names and icons, and i don't see any way a renderer would determine that its unnecessary from the given information. I could split up the buildings into multiple paths, and create a multipolygon for each building, then a overall multipolygon from only the outer paths. I believe this would render correctly, and it would make sense to mark it up like that. --Micket 15:24, 27 May 2011 (BST)
I just did as i explained above as a test, and it renders well; 8264615 (Visualise)
Oh. I thought you were talking about separate buildings. I'm not sure that it's appropriate to treat your case as different buildings; it's really just one building with different characteristics in some places. --NE2 20:07, 28 May 2011 (BST)
The "How to map" says to map singular parts invidually (but connected). Perhaps I have misunderstood it completely, but the multipolygon seems to work well in my test. --Micket 16:28, 29 May 2011 (BST)
Ah, I see. I would interpret that as applying mainly to downtown areas, where separate buildings touch. You should probably try to get more input (such as the tagging list). --NE2 18:27, 29 May 2011 (BST)
Even outside downtown areas there are places where this applies. Universities, libraries and such, are quite often built up of several (clearly distinct) singular parts, with different heights/levels. I will try the tagging list then. --Micket 17:23, 30 May 2011 (BST)
Your multipolygon will produce touching outer-outer errors - even if it's working for the renderer.--U715371 (talk) 23:19, 4 December 2014 (UTC)
The best current solution to your problem is to tag every building part as building:part=* and to map a way around the whole building tagged as building=*. Then name=*, addr:housenumber=* etc should be tagged together with building=*, of course.--U715371 (talk) 23:19, 4 December 2014 (UTC)

"building typology" vs "current function"

Hi All! Some time ago PeterIto changed description of tagging criterion from "building typology" to "current function"? Can it be explained why? As I know, by many people in many countries the value of the building tag was understood as building typology. E.g. building=chirch and building=warehouse are distinct types of buildings (different architecture), no matter how they are used currently. It's not quite good to change meaning of existing tags, because it makes impossible to interpret map data. Also, this change does not make sense for me at all, because function of the building should be (and is) indicated by tags like shop and amenity. My suggestion is to change that back to "building typology". -Zkir 12:29, 25 February 2012 (UTC)

I raised this very question on talk:key:building earlier in the month as there seems to be reasonably evidence that much of the current tagging actually relates to use rather than typology. Happy to go along with the consensus, but I think it needs a bit more of a discussion first - can we do that on the other page? 14:50, 25 February 2012 (UTC)
Sure. - Zkir 21:38, 26 February 2012 (UTC)

Buildings with multiple purposes

Tagging email list discusssion: "Multiple purposes for buildings" at http://lists.openstreetmap.org/pipermail/tagging/2013-January/thread.html

don't tag for the renderer

Resolved: Translated.

There is a good section in the german version: "don't tag for the renderer" describing things that should be avoided. Would be good to have it in english too. --Aschilli (talk) 17:11, 18 February 2013 (UTC)

Possibly not necessary that much, but translated nevertheless. I think some negative examples should be discussed. And there is for example the usage of POI tags on the building I would like to declare as tagging for the renderer.--U715371 (talk) 23:01, 4 December 2014 (UTC)

residential building name

Resolved: A name of a building is an addr:housename=*, if it there is no housenumber or other feature available for postal services.

Most residential buildings around here have names, such as "Example Building". Should this information be tagged as name=* or as addr:housename=*? I ask this around here because this is specially relevant for buildings. IMHO I know we shouldn't tag for the renderer, but the rendered result is much, much better if the building name is tagged as addr:housename=* instead of name=*, so the buildings can be rendered with their address numbers on top of them, which (IMHO again) is much more relevant. --Nighto (talk) 18:07, 18 March 2013 (UTC)

The addr:housename=* is just a tag which is relevant if you can use the name as part of the address without any housenumbers. So if a building has such a name it can additionally be tagged as addr:housename=*, but primarily as name=* - which should be an official name. See also Karlsruhe_Schema.--U715371 (talk) 21:57, 4 December 2014 (UTC)

ruined building?

what shape does a building need to be in to still be considered a building? I'm mapping an area that has an old burned-out building with the roof fallen in. how do i tag it? --Dru1138 (talk) 21:53, 24 March 2014 (UTC)

building=* and ruins=yes.--U715371 (talk) 22:00, 4 December 2014 (UTC)

How do you make inner and outer in iD editor?

Resolved: Doable, see link below

For buildings that have courtyards and such. I can't figure it out. Thanks. --Marion Barry (talk) 19:32, 7 July 2014 (UTC)

I figured it out - [3] --Marion Barry (talk) 18:04, 8 July 2014 (UTC)

Outline on the ground vs covered area

Unresolved: No solution yet.

There are different interpretations refering to the outline of buildings. Some assume the building way to be the outline on the ground, others assume it to be the covered area of a building. The latter is the more often used interpretation due to the sources at OSM for building objects which are mostly aerial pictures. In contrast the first interpretation states more or less the goal of how to tag building=*, if the building is mapped with more details. From my point of view this would require a different rendering of some detailed buildings.

I am wondering if it is possible to render areas of buildings, which are for example covering some highway=* objects like a square or are just not on the ground, in a different way. For example on a non-3D-map it should be possible to render only the outline on the ground (i.e. the area including pillars and walls) as the building. The areas which are only covering may be rendered hatched. From my point of view this could be possible using some tags from Simple_3D_Buildings.

This leads to some easy and some harder renderer problems. For example building=* is not always used as you should expect from the description on the wiki page. Some tags (for example bridge=*) are proposed and do not describe a building which has an outline on the ground (see Buildings#Tagging for more examples). Hence some objects cannot fit to the outline-on-the-ground rule. Those can be easily rendered different. But what about those buildings which are mostly only covering? So far as i know the professional way is to render only the building on the ground. May be it is also a good practice to render the covering areas, too. This would be functional, because it allows a better orientation in the field. To achieve this, it might be helpful to make use of building:part=*-objects tagged as building:min_level=*>0 OR min_height=*>0. Hence solved.

So far the rendering of the area on the ground in connection with the covered area. But there are still some other kind of features of buildings which might be rendered different. For example the name=*, which may apply to the covering areas, too. If so, a renderer has to do much more than just to take the building=*-area and render the name on it, because there is not necessarily an object covering the whole building area which could be used for rendering the name, the housenumber etc. Such object could be defined using a type=building-relation. But this is in fact not very beautiful, because you may add some redundand data (adding all the data to the relation) or perhaps miss data (tagged on the building=* object). On the other hand you may obtain tags (for example name=*) for the new building-area by recurse to the way using the role "outline" at the relation. Since there exists a relation type=building for the building, the renderer may ignore name=* on the object with building=*. This last step may be very expensive, i guess.

Do you have some better solutions to the problem? Maybe the proposition that you should tag the outline on the ground with building=* is not the best idea and therefor the tagging propositions should be changed. Currently and in the past some mappers unfortunately do not take care for the on-the-ground rule, which lead to some differing tag usage. What do you think? Does somebody of you guys have experiences in rendering this? Maybe something like this should be implemented for the osm.org-rendering. --U715371 (talk) 21:39, 4 December 2014 (UTC)

I don't have a solution ready, but I want to point out that there are contradicting rules. In the context of 3D mapping, there is a documented rule that all building parts must be included in the building outline, which would be impossible if only the ground footprint were represented with the building outline.
Would it be possible for 3D renderes to render building:part=* similar to building=*? Maybe this solves it for 3D.--U715371 (talk) 23:23, 11 December 2014 (UTC)
I also believe that this page did not originally intend to exclude parts of the buildings that do not touch the ground. In the first version, the words "on the ground" are included, but in the context of correcting a shift in the aerial imagery. So the current version might even be the result of a misunderstanding, although it could of course also have been a conscious decision. --Tordanik 10:02, 5 December 2014 (UTC)
The first point is true anyway. The second seems to be a still unresolved. There was a discussion at talk-de in January 2014 regarding this problem. Here some important points:
* German cartographers differentiate buildings (bauliche Anlagen) between "Gebäude" (buildings icluding rooms, protecting man, animals and things) and "Bauwerk" (balkonies, carports, roof overhangs, roof-only-buildings etc).
* What is drawn depends on the source: To draw buildings using aerial pictures results mostly in a non-footprint-outline - to copy from WMS results in contributing the footprint.
* Most (all) cartographic aspects of buildings should be included in the OSM.
* The German word "Grundriss" is used for a plan of a floor and does not mean footprint in this context.
* The current 3D-Renderer convention implies that a building outline includes everything what is covered by the building - which contradicts to the general footprint interpretation.
Unanswered: How do you map this: Ehemaliges Amerikanisches Generalkonsulat - Bremen.jpg
I would like to propose the solution to add footprint=yes to building:part=* which touch the ground and add footprint=no to building=* with building:part=* which do not touch the ground. Since the a usage of building=* as the footprint does not make any sense since there are moveable objects or pile dwellings in the OSM as buildings, I guess.--U715371 (talk) 23:51, 28 September 2015 (UTC)

Don't mix buildings with POIs

I've noticed that many mappers are tagging a POI onto the way which also represents the way for the building. But this is wrong, because usually the building name is not the name of the POI and vice versa. On the other hand a building name is not necessarily an address (addr:housename=*). The reason for this behavior is mostly tagging for the renderer. Mappers do not know how to tag a POI correctly, for example a carpenter (craft=carpenter) and only add the name to the building way and so it gets rendered.--U715371 (talk) 14:49, 8 December 2014 (UTC)

When a POI and a building map one-to-one, it's perfectly fine to map the POI on the building. Names can indeed collide, though that doesn't happen very often here, as buildings generally don't have names. Apart from colliding tags I don't see any problem in adding POI info to buildings. --Sanderd17 (talk) 18:41, 8 December 2014 (UTC)
If a POI and a building map one-to-one, you probably have a POI which is kind of indentical to the building, for example a church or a shopping mall. I agree that such case would be fine. I made the experience that building names and names of POIs are very often colliding, since you have some historical or architectural important buildings and the current user is using the building completely. On the other hand - "as buildings generally don't have names" - the name of the poi is almost never intended for the building. Though you probably evoke a name collision or cast a name of something to a building name. Which is against the usage of name=*.
We usually do not mix up distinct objects. For example railways and highways, boundaries and landuse or highways and public transport stations.
Another sort of collision: If there are more than one shops/offices/etc inside a building (this happens very, very often), you will favor a single one by tagging a POI on the building-way.
So creating a new way- or node-object for each POI, you add to the database, would be already kind of default anyway. --U715371 (talk) 21:24, 15 December 2014 (UTC)
PS: Since the address data of the POI is the same as for the building-way, you do not have to copy this information. GIS applications are able to apply the address to the Objects within the building-way-area. For example nominatim is able to do so.--U715371 (talk) 22:23, 15 December 2014 (UTC)
I propose to add building:name, see #building:name.--Jojo4u (talk) 16:11, 22 October 2015 (UTC)

Ships and boats as buildings?

In general ships or boats are moveable objects, but at osm some are recorded as building=*. Even the wiki page is documenting building=houseboat. I do not want to discuss whether they should be included at the OSM. I wonder that they are tagged as buildings. From my point of view it should be considered to deprecate such tagging and propose something like man_made=boat/ship/houseboat.

At wikipedia it is stated that houseboats are dwellings but no buildings (see Wikipedia-16px.png Building#Residential on Wikipedia).

Taginfo gives

tag # of uses
building=houseboat 11496
building=boathouse 1116
building=ship 70
building=boat␣house 12
building=boat_house 11
building=yes;houseboat 8

and a few more. For man_made there is currently almost nothing regarding ship/boat.

Unresolved Dutch thread about the problem - I do not understand Dutch, so maybe somebody can write a short summary.--U715371 (talk) 23:54, 11 December 2014 (UTC)

There were some replies to my question on the tagging list. Here is a short summary of some opinions: There are some mappers who may support an approach to tag man_made=* instead of building=*, but there are also some who prefer to interpret building=* more as a structure than something which has a foundation. building=houseboat is often mixed with floating homes, too. But those may be better tagged as building=floating_home (The difference is that floating homes are mostly build on logs while houseboats are built on boats). Nevertheless it would be useful to specify the attribute moveable in a separate tag.--U715371 (talk) 23:21, 4 January 2015 (UTC)

Aside: building=boathouse is distinct from building=houseboat. Boathouses typically are not boats. Mrwojo (talk) 14:43, 26 March 2016 (UTC)

Basement/cellar

I wonder if basements or cellars should be tagged as building=*. Those structures do not really have a footprint on the ground.

Imagine it extends the area of the/its building? Would building:part=basement/cellar be a good solution?

Maybe this is related to building=underground. --U715371 (talk) 00:49, 12 December 2014 (UTC)

Building Abbreviations

For Universities that use building abbreviations (e.g., Empire State Building to EMP), what tags should we use? I'm currently using name:abbreviation because I can't find anything that would deal with abbreviations.

building:use description was partially removed from wiki without link to Deprecation proposal

There >600K objects in database, but not single line about building:use except building=apartments page.

First, text was moved from Key:building to Buildings but later it was removed. Is there reason why this was done? Xxzme (talk) 10:49, 7 April 2015 (UTC)

I've started a doc for Key:building:use at least. This same issue was brought up 2 years ago on Talk:Key:building:use and nothing changed so I guess it slipped through the cracks. Mrwojo (talk) 00:02, 8 April 2015 (UTC)
The issue with building:use is that the use is often better expressed with an amenity or shop tag. And almost every other situation is one where the use matches the building type, in which case which I would consider the use implied (adding building:use=residential to millions of building=residential is not a good idea). Of course, it's used surprisingly often, so we probably need to document it. But we should state the aforementioned caveats very clearly. 09:55, 8 April 2015 (UTC)
I've tried to make that more explicit on Key:building:use. Mrwojo (talk) 15:15, 8 April 2015 (UTC)
Well but tags are not limited to shop and amenity family. What if church becomes residential building? I think proper way to tag it is: building=church + building:use=residential. There no tag in shop or amenity about "residential" AFAIK Xxzme (talk) 18:28, 9 April 2015 (UTC).
That's true, there is not really an alternative for building:use in that case. I think that the warehouse example on the page makes it clear that such situations can be mapped with building:use. I like the current status of the page after the recent edits by Mrwojo. --Tordanik 09:43, 10 April 2015 (UTC)
I somewhat disagree with text about how to use data afterwards. Since most objects were tagged with "building=* means typology" in mind (see talk pages). It will problematic if you deduce residential status from building typology tag. For example: mapper tagged disused building with single tag building=house, but then you deduce building:use=residential. When in fact, in the real world building was building=house + building:use=disused or building=house + disused:building:use=residential. There should be paragraph how to use building:use with Lifecycle prefix. Xxzme (talk) 13:04, 10 April 2015 (UTC)

Suggesting a bunch of new building types which came into my mind

May I suggest to document/propose a few more building types on this Wiki page?

  • prison - A building designed to hold people prisoners.
  • fire_station - Includes all buildings which belong to a fire station.
  • cinema - A cinema building
  • toilets - A building soley or primarily consisting of one or more toilets.
  • sports_hall - A building which is primarily used for sports. It may contain sports equipment, changing rooms, showers, toilets, swimming pools. Use sport=* to indicate the feasible sports in the sports hall. Sports halls may occacionally be used for local events, but this is ususally not the primary use. In Germany many, many schools also have a sports hall, so this is a quite important building type. Note: Also known as “gym” or “gymnasium” but I suggest to not use these words as values, because they can be very confusing because of their many meanings.
  • hall - A building with a large open area in it. Usually used for local events. This is intentionally kept vague so it is useful when you don't know the building's exact purpose.
  • parking - Cars and other vehicles park in the interior of this building. Useful for those multi-storey parkings.
  • factory - Factory building. Something is manufactured here, usually on a large scale and it does involve heavy-duty machines.
  • workshop - Building in which something is manufactured primarily by manual labor. See also craft=*.
  • education - A vague value for somehow educational-related buildings, includes schools, kindergarten, college, university etc. buildings. Use this if you are unsure about which exact value to choose.
  • car_wash_street - Car wash street.
  • toll_booth - Toll booth.
  • model_house - A building which is used as a “template” or “examples” for buildings of the same kind. They are not “actually” used, they are use for demonstration purposes. Usually they are open to the public. “Musterhaus” in German.

That “model_house” is very unique here. It might be useful to add the type of building + model_house:modeling = <any value of building> - specify

Example: building=model_house + model_house:type=retail: A model house which is a “model” of a shop building.


After a quick check on Taginfo I got:

  • factory: 3828
  • education: 1361
  • hall: 1080
  • prison: 543
  • parking: 230
  • fire_station: 183
  • toilets: 142
  • cinema: 120
  • sports_hall: 82
  • workshop: 65
  • toll_booth: 22
  • model_house: 1


If you have comments or don't understand something, please answer here! :-) --Wuzzy (talk) 00:51, 3 May 2015 (UTC)

I think there better place for this: Template:Building typology. Buildings is just short and overview article. Xxzme (talk) 00:56, 3 May 2015 (UTC)
Oops, that's what I have actually meant. My post somehow ended up here … --Wuzzy (talk) 12:53, 3 May 2015 (UTC)
Some of these seem to be veering very far into amenity territory (e.g. car_wash_street). I generally don't have a good feeling with duplicating amenity/shop tags as building tags, it leads to a lot of confusion. --Tordanik 10:04, 4 May 2015 (UTC)
Yeah, tag building=*, imo, should describe constructive type and features of building. For example we expect from building=church to have inner space for gospel gatherings, altar and spire. And sometimes contructive type of the building may not match the amenity, e.g. warehouse in building=hangar or amenity=school in building=house.--Keder (talk) 13:18, 18 May 2015 (UTC)

building:name

Often POI encompass a whole building (e.g. supermarket), and tagging the POI on the same way as the building is considered valid. Sometimes the building has a different name than the POI (example: arts centre). So in sync with bridge:name=* I propose to add a section about building:name. Using a colon instead of a underscore enables to use building:old_name and so on. Currently addr:housename=* is very often misused for this task (example Overpass Turbo).--Jojo4u (talk) 16:19, 22 October 2015 (UTC)

Tagging POI and building as the same object is not necessary and not even all that desirable, it's just done for convenience. As long as there are no keys (name or otherwise) that have different values for the building and the POI, that's ok. But when there are key conflicts, the POI should really be separated from the building. This also makes new keys like building:name unnecessary. --Tordanik 16:34, 22 October 2015 (UTC)
Just tag POI and building separately. Mateusz Konieczny (talk) 17:26, 25 October 2015 (UTC)