Talk:Buildings

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:

• A lake dwelling
• A building mostly on piers

--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 [1] 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)

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)

Resolved: common values nowadays are listed on another (clearly linked) page Mateusz Konieczny (talk) 11:44, 6 December 2020 (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

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 - [2] --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:

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 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)

Tagging nonmoving ships, caravans, boats, containers as buildings seems accepted to me Mateusz Konieczny (talk) 11:43, 6 December 2020 (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.

you can use ref=* in this case.—Dieterdreist (talk) 07:34, 16 September 2018 (UTC)

there is short_name=* Mateusz Konieczny (talk) 11:45, 29 July 2020 (UTC)

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)

Resolved: it is now mentioned again and has its own page Mateusz Konieczny (talk) 11:41, 6 December 2020 (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)

Suggesting a new building type for buildings created for gastronomy like restaurants

There are many buildings that have been built for being a restaurant, a bar, an inn, an alpine hut, etc straight away, so they have not been designated to become gastronomy with a later use only. Shouldn't we have a building type / value building=gastronomy for it? Is it a good term, native speakers? Sometimes building=restaurant seems to be used (some little 700 uses according to taginfo), but which is too specific to my point of view. I don't know if building=commercial is used for it, too. But if shops have its own value, gastronomy should have one, too, in my opinion.

generally I think more specific is better (up to a certain point), e.g. better building=restaurant than building=commercial (which does say few because it is too generic and typically repeats the landuse). —Dieterdreist (talk) 07:44, 16 September 2018 (UTC)

Is there a meaningful use case for that tag? My impression is that data consumers tend to be interested in where restaurants are, but not so much where restaurant-style buildings are. Also, repeating the amenity isn't really much better than repeating the landuse – I feel that both have little value in practice. --Tordanik 17:00, 21 September 2018 (UTC)

Projection??

"To be extra precise you may want to ensure you're using a projection like Mercator (otherwise if you use something like WGS84, then objects will be distorted when rendered)."

I don't think so, especially at the scale of any building.

baden k.

• I removed it. If that is true - it should be reported as a JOSM issue Mateusz Konieczny (talk) 19:04, 29 October 2018 (UTC)

It used to be an issue back when Mercator wasn't the default projection in JOSM. People would often create buildings with unusual angles, and the advice was to switch to Mercator. So from experience, it makes a noticeable difference. But of course, people rarely configure JOSM to use a different projection nowadays, and people who do so tend to know what they're doing. --Tordanik 21:45, 29 October 2018 (UTC)

I attempted to improve the page and explain that it is not a problem for a typical user Mateusz Konieczny (talk) 17:55, 31 October 2018 (UTC)

Reasons why building's name is not rendered

Reasons why building's name is not rendered on OSM.ORG:

• Area too dense?
• The name= tag is not rendered for buildings in the first place?

Jidanni (talk) 15:35, 15 July 2020 (UTC)

first is possible, second is not true - what you can verify by searching for standalone named building. Maybe name is using still unsupported glyphs? Hard to say without specifying location Mateusz Konieczny (talk) 20:44, 15 July 2020 (UTC)

Resolved: without specific location nothing useful can be guessed Mateusz Konieczny (talk) 11:39, 6 December 2020 (UTC)

building outline with a protruding part

https://polska-org.pl/9393269,foto.html
What outline should the building have in this case? Should I also include this protruding part of the building and mark the path underneath with "covered=yes", or should I not take this hanging part into account? maro21 19:01, 11 July 2021 (UTC)

Most Accurate Possible Building Outline

I am copying over my post from the discussion page of the roof modeling page- I understand that these questions have been asked before (albeit years ago), yet I believe the essential questions remain somewhat unanswered. My hope is that new users will see this and perhaps have new input. I also attempted to summarize the lengthy discussions from nearly a decade ago into something more concise.

The unanswered questions appear to be as follows: Is the building outline most accurately the extent of the building roof as seen from a top-down (plan) view? Or is it the extent of the foundation of the building? Or is it the extent of the outer-most walls of the building that encompass closed areas?

I sense from the previous topics on this discussion page that the former of the question’s definitions should be employed because of a user-based reliance on aerial imagery for building outlines. That is: a building outline is the maximum possible area that a structure covers on the ground below as seen from a top-down (plan) view. This means that the components of a building (like a porch or front area) is included in the building outline as long as it fits entirely into the outline (i.e. does not overextend beyond the building outline). When I think about it this way, it makes it easier to reconcile building outlines with the predominantly used simple indoor tagging scheme.

Maybe this is all just for my sake of talking things out and should remain just on the discussion page, but I also thinks this gets to the essence of how to tag and understand building outlines both from the perspective of aerial mapping and on-the-ground mapping. IanVG (talk) 16:21, 24 July 2021 (UTC)

This is a good question. To which I don't yet know the exact answer, even though I have mapped thousands of buildings. For building=roof buildings it is definitely the roof outline. In case there are only aerial photos and no other source, it is probably also the roof outline.

Outlines are generally given after the line of building location on the ground (exactly it is about a meter above the ground) hence such elements as balconies are not included in the building outline. For Poland we have GIS data for buildings and their outlines are probably one meter above ground.

But there are many odd buildings, see my question above for example. maro21 20:35, 28 July 2021 (UTC)

I think the answer to this question needs to be included at the beginning of "How to map" section.

It is a difficult question to answer, because one one side, buildings will often be traced from top-down imagery, naturally outlining the extent of the roof, but on the other side, I have found when using OSM data I usually care about the extent of the foundation of the building (because that is what is relevant at level=0 and layer=0). --BudgieInWA (talk) 06:45, 7 May 2022 (UTC)

Sub-Divided Buildings?

In my area I have seen one, solitary, building that has multiple businesses mapped as one polygon per business. Is this proper? Should these be mapped as one polygon per building and then point features for the businesses?

There should be one building=* polygon for one building. Businesses can be mapped as nodes or shop=*/amenity=*/office=*/etc areas. Note also building:part=yes useful if for example different part of buildings have different level count etc Mateusz Konieczny (talk) 11:19, 3 October 2021 (UTC)