Talk:Key:building

See Also: Proposal of this Feature

Discussion to date moved to 'talk:buildings'

See also: talk:buildings

I have moved the discussions about building tagging from this page to the new Buildings article in talk:buildings. I have done this because it seems appropriate to have the earlier discussions about tagging in the place that is likely to attract further discussion to avoid duplication or contradiction. PeterIto 06:49, 17 December 2011 (UTC)

Scope

The buildings key currently seemss to be trying to perform a range of contradictory roles. It is mainly about building use: ie retail, hotel, garage, but then has entries for building status: ie 'collapsed', and also the construction material: ie 'panel house'. In addition there is the suggestion that one uses building=yes and building:type=* for the function. As such it isn't possibly to define a ruined hotel which is constructed using a 'panel-house' technique.

Can I suggest that:

1. Confirm that this tag should be used for the purpose of the building,
2. Agree on a recommend way of tagging the construction method, ie panel house etc, and also possibly if it has a flat or pitched roof etc.
3. Encourage the use of more standard life-cycle tagging for ruined buildings.
4. Create a number of 'catch-all' type for situation where something is known about the use, but not everything. For example 'Education', for any sort of educational establishment, particularly one for which a more specific tag is not available, and 'place_of_worship' for any form of religious building.
5. Clarify that we should be tagging the 'main purpose' of the building, so a shop with a flat above would be tagged as a shop. Possibly we need 'mixed' for where there it is too complex for any of the agreed tagging.

Any thoughts?

-- PeterIto 11:55, 8 February 2012 (UTC)

From what I've read on the mailing lists and this wiki and on the IRC channel, the rough consensus has been that building is best used for "typology", i.e. physical nature of the building - a "house" might be used as an office, but it looks like a house (even if they come in very different but similar shapes), an old church looks like a church even if it now only has a nightclub inside. As you noticed, this has been been to date more of a "tag anything", so I took the top 15 values and removed entrance and yes to see what the majority is:

value	count (2012-02-08)	percentage of these	typology/use?
house	469074	26%	typology
hut	340728	19%	typology
residential	296618	17%	use
garage	155603	9%	typology
apartments	111597	6%	typology
roof	109595	6%	typology
garages	72767	4%	typology
industrial	65307	4%	use
farm_auxiliary	25488	1%
service	19405	1%
detached	18032	1%	typology
church	15417	1%	typology
school	14362	1%	typology
manufacture	13528	1%	use
terrace	11322	1%	typology
collapsed	10708	1%	state
hangar	10666	1%	typology
cabin	10153	1%	typology
retail	8928	1%	use/typology
Totals		of these	of all except yes
typology		75%	70%
use		24%	22%
could-be-either/unknown		4%	10%

Remaining values total to 138416 atm (and =yes is at over 49 million). I do agree that dealing with some little used variants (as you listed) is a challenge, especially how to instruct the next mapper who comes across a building=panel_house to move that to, say, building:structure=large_panel_system if they choose to change the building value. (fwiw, now that I read about it on wp, just about all blocks of flats built here since the 1960's, and even today, are these, even if they might look just like masonry buildings). The questions that remain unasked for classifying buildings are probably the ones that give us the majority of unorthodox values: is a university building with mostly paid researchers' rooms a building=office? Alv 12:55, 8 February 2012 (UTC)

Thanks for such a fast and comprehensive response. Based on my analysis which is more angled at building 'use' that 'typology' a number of places seem to be using the 'use' system. I also believe that the terms garage, garages, apartments and house (the most common on your list) are just as likely to be being used for use rather than typology. Personally I would be reluctant to tag a solicitors office as 'house' even if it occupied a building that was originally built as a rather grand house, particularly if I was to then need to tag the solicitors next door based in a 1960s office as 'office'. I think other people would also get that wrong a lot of the time. Anyway... here are the values I have seen is use around the place grouped a rough sort of way:

• Civic: amenity, city_hall, courthouse, church, civic, gymnasium, hall, museum, place_of_worship, prison, pub, public_building, railway_station, service, shelter, station, toilets, tourism, train_station, veterinary
• Commercial: Commercial (except with shop=*), industrial, office, warehouse, unit
• Education: College, kindergarten, school, university
• Health: hospital, pharmacy, nursing_home, healthcare
• Residential: Apartments, dormitory, detached, flats, house, residential, semi, terrace
• Retail: Mall, shop, retail, store, supermarket,

This conversation seems to have stalled and I note that the subject has also been raised on talk:Buildings. Another though... if we are using this key for typology then how should one interpret some of the most common values? Even in the UK the term 'house' might mean a mansion, a large Victorian villa, or a small cottage and when one goes global and considers the most impoverished and richest places in the world then it seems very unsatisfactory. If however one uses the word 'house' to mean a construction in which a group of people live sharing facilities then that is immediately understandable. Similarly with garages, which can be constructed in many different ways using many different materials, some of which are indistinguishable from a shed. One can however normally establish if it is designed for the storage of a vehicle from the approach. The same sort of comments could be made about 'church', 'school' and 'office'. PeterIto 21:14, 25 February 2012 (UTC)

"how should one interpret some of the most common values? Even in the UK the term 'house' might mean a ..." In my opinion building=house can be interpreted only as a synonym of building=yes. But this problem is unsolvable.

- Zkir 22:13, 26 February 2012 (UTC)

Hi again :) In my opinion typology is better. Here are the reasoning (same as at [Talk:Buildings], just for convenience here). 1. As I know, by many people in many countries the value of the building tag was understood as building typology. For example, in Russia 'church' is a very distinct kind of architecture. However, many churches are still either abandoned or used as museums or warehouses etc. Same situation with garages, building=garages commonly assumes something like this [1], but not necessary cars are kept there, and so on. 2. It's not quite good to change meaning of existing tags, because it makes impossible to interpret map data. 3. Current function of the building should be (and is) indicated by tags like shop and amenity. No need to duplicate it in the building tag.

My suggestion is to change the definition back to "building typology", or, may be, to "intended (or original) function", adding note that there are some exceptions (which is true). - Zkir 22:13, 26 February 2012 (UTC)

+1 for the typology. A railway_station still looks like a railway_station even if it is now used as house. A church, even in a modern shape, is a kind of building, even if it is used today as a library (building=church + amenity=library). --FrViPofm 22:57, 26 February 2012 (UTC)

Use/typology and lifecycle

The main key building=* should contain the type (typology), I agree that life-cycle and construction technology should be tagged separately (together with current use). --LM 1 00:45, 27 February 2012 (UTC)

Would it be a reasonable compromise to say that where a building is current being used for the same purpose for which it was built it can simply be tagged with the current use? For example, a building that was built as a hotel, and is also currently an operational hotel should just be tagged as building=hotel. By way of contrast, a big residential house that has since been converted to a hotel (as so many have been in central London) should be tagged as 'building=house;building:use=hotel'. However... I think it will sometimes be a tall order to expect people to dig into the former uses where the building has been extensively altered, and we may have to tolerate it just being tagged with its current use for starters, ie building=hotel until someone spots the former use and corrects it. By way of example, it was only after passing this former railway station[2] over 50 times that I finally noticed that it looked like a minor rural station on a long abandoned railway line. Checking on OSM later I confirmed that it was on the route. As such I might have initially tagged it 'building=house', and then converted it to building=train_station;building:use=house' at a later date.

For the avoidance of doubt, we would recommend the same tags for building and building:use? I see that there is a suggestion that one should just use 'tags like shop and amenity' to describe the use, however I would suggest that there should only be one amenity=school or amenity=hospital attached to the landuse, not to each individual building.

-- PeterIto 20:14, 29 February 2012 (UTC)

I agree that some building types imply a specific use (and this use can be assumed unless explicitly marked). Your example with hotel and railway station seems fine to me, but I am not sure about same tags for building type and building use. building:use of a house (or apartments complex) would be residential. If the building is extensively altered, it is possible that is is not what it was anymore, so building=* could also change during time. --LM 1 09:44, 5 March 2012 (UTC)

Good, and I agree that the (implied) use for a house should be 'residential' not 'house'! It is also my preference to tag for current appearance of the building rather than the original use when it has extensively altered. For the avoidance of doubt, are you happy with the changes I have made to the building template over the past few days. Personally I am pretty happy with it now, but have had limited feedback (positive or negative) from others. PeterIto 10:06, 5 March 2012 (UTC)

<-----

I did not specifically look what was already there and what you changed, but generally, there is nothing really wrong, just a few details and missing types:

• Currently the infobox states only areas as valid elements, I believe that relation (multipolygon only) is equally valid (needed for building with holes or when reusing the outline for something else).
• building=commercial being the generic one (as is residential for accommodation), maybe there should be building=office for administrative buildings (not factories). If I understand it correctly building=industrial is intended for the factory building, right?
• building church should be accompanied by building=mosque;temple for other religions than Christian.
• I am not sure if building=civic provides enough detail: some buildings like library, theatre or swimming pool are very specific, maybe they

would deserve a separate value.

• Besides train stations there are bus stations, airports, and possibly more buildings where you buy some ticket and board some transportation. Either each should have its own value or one general for all - Is this the building=transportation?.
• University is a type of school and the building would be same/similar (classrooms, teacher's offices...) - or are university buildings so different from other schools?
• bunker it is ok here, but probably on military=bunker should be specified that it is for active bunkers, while building=bunker even for the museum type.
• Does the farmer not live in a house (that might be built next to other farm buildings)? How does b=farm differ from b=house?
• A few buildings that I have around and would not be sure how to map:
  • gazebo/pavilion;
  • exhibition building (not sure if this is used in English; place where exhibitions take place);
  • gas station (the part that is not roof) - retail?
  • multi-purpose buildings combining offices, apartments and retail.
  • there are historic buildings, that are likely to last longer than most of contemporary buildings: pyramids, castles (de:Burg), Châteaux (de:Schloss)/palace,
  • arenas (from Colosseum to Bird's nest,
  • all kinds of towers

I know that all the types I just mentioned are not so numerous, but they are usually more important than residential buildings...

--LM 1 00:03, 7 March 2012 (UTC)

Thanks for coming back on this. Very reassuring to be discussing this properly. In response to the above.

• I have added 'relation' to the type options. I would however observe that even landuse=* doesn't show relation as legal type!
• Regarding commercial, I am not clear that there is benefit from having both office and commercial given that commercial is only really for offices ((industrial and retail have their own tag value). We might however want to think about different typologies of commercial building (as we do with residential in terrace,apartments etc)
• Let's not duplicate other tags. For example: I have converted building=hangar into a redirect to aeroway=hangar. I wonder if bunker belongs here as well as in military?
• I have removed farm. I had been wanting to do that for some time, but didn't want to have too many discussions going simultaneously so left it for starters!
• Mixed is probably a necessary addition, although I think that might be work a bit of discussion first about how it should be used. See next comment.
• You then start a useful discussion about possible additional entries for significant additional typologies. I would very much support that as long as we don't duplicate entries in other tags (such as man_made, historic etc). I am going to copy your list above to a new section at the bottom of the talk page with a heading of 'possible addition values' where we can discuss them one by one!

-- PeterIto 04:21, 7 March 2012 (UTC)

• It is the same case, in both it is not any relation, but only multipolygon. Maybe multipolygon relations are (should be) treated as areas?
• You can generally distinguish apartment buildings and any other residential from any commercial, but can you always tell offices apart form industrial, sometimes there are even mixed, for this I would use commercial (don't know/mixed). And maybe commercial should be avoided altogether, since it is more use than type.
• As I see it, aeroway=hangar and military=bunker should only be used if there are planes or soldiers inside. Disused bunkers that cannot be used for defence are not military anymore, same for hangars. But the building clearly remains a bunker.

--LM 1 09:09, 7 March 2012 (UTC)

Has the whole business of typology vs use been formally resolved? If so, the verbage on main page should be updated to reflect this resolution. At this moment, main page contains ...

Apartments = A building arranged into individual dwellings

Church = A building that was built as a church

With current verbage it is not clear how to tag a building built as a church and converted to apartments. Narrative for "church" is in past tense whereas other values are written in present tense. Therefore both tags apply when a church is converted to apartments or some other purpose. -- Fbax 22:24, 12 November 2012 (UTC)

Current tag values

I have done an analysis of values currently in building around the world. There are pockets around the world where there is reasonably high usage of the tag and many other areas where nearly all buildings are 'yes'. Clearly the tagging is a bit of a mess at present, but I hope this will help us pull something useful going forward. Personally I think we are actually going to end up with some tagging which gives a clue to both typology and to use and over tag values that imply only typology. I have split the current values up into very broad categories and will comment on each in turn. PeterIto 18:15, 27 February 2012 (UTC)

Residential accommodation (see education for halls of residence etc)

• building="apartment || apartments || Barracks || bungalow || convent || council_flats || detached || detached_house || dormitory || dwelling_house || flats || house || houses || housing || palace || prison || residential || residential flats || residential home || residential,warden controlled flats || row_house || semi || semidetached || semi-detached || semidetached_house || serviced apartments || sheltered housing || terrace || terraced_house || tower_block || hall_of_residence || student_residence || student_residences"

In general, the most useful (excluding specialist places like convents, palaces prisons for now!) seem to be "apartments, bungalow, detached_house, semi-detached_house (for one or a pair of connected houses), terrace (for a single unit in a row) and residential (for a unspecified arrangement of connected dwellings). I would suggest that the fact that it is sheltered housing should be covered by secondary tagging and also the fact that it is run by the council. Regarding student accommodation, dormitory (see building=dormitory seems to be likely to create problems for us as it has different meanings in the UK and USA and the currently uses the USA one (and OSM usually is based on British Engilish). Can we recommend 'hall_of_residence' as for preference? PeterIto 18:15, 27 February 2012 (UTC)

Retail

• building="mall || residential/shops || retail || Retail || retail/commercial || retail shop || retail shops || retail,shops || retail shops,etc || shop || shops || shopping_centre || shopping_mall || store || shops & offices || supermarket" or building="commercial" + shop="*"

It does seem to be useful to distinguish a row of shops on the high-street with accommodation above from an out-of-town warehouse or a shopping centre. The wiki page recommends 'retail' for all shops except 'supermarket', but then indicates that supermarket can be used for a shopping Mall? Do we want to distinguish building types at all here, ie a distinction beteen hight-street and the 'warehouse' style? PeterIto 18:15, 27 February 2012 (UTC)

Education

• building="college || day nursery || faculty || kindergarten || Nursery || primary school || school || Sixth Form Centre || university || University"

Should we use 'school' for all levels of education and then use Proposed features/ISCED. PeterIto 18:15, 27 February 2012 (UTC)

Medical

• building="dentist || doctors || healthcare || Health and Community Centre || hospital || nursing home || nursing_home || Nursing Home || pharmacy || Pharmacy"

Any comments? PeterIto 18:15, 27 February 2012 (UTC)

Farming

• building="agricultural || barn || farm || farm_auxiliary || glasshouse || greenhouse || tiny_barn"

Comments? I don't think tiny_barn is useful, possibly hut or shed? Should a farm-house be tagged as 'house'? PeterIto 18:15, 27 February 2012 (UTC)

A bunch of smaller building types

• building="beach_hut || cabin || car_wash || carpark || garage || Garage || garages || garden_building || hangar || hut || multi_storey || multi_storey_car_park || multiple || parking || private garages || scout_hut || shed"

Comments? PeterIto 18:15, 27 February 2012 (UTC)

Offices and commercial (ie, people sitting at desks)

• building="administrative || embassy || government || commercial || Commercial || Commercial Offices || office || offices"

We have a office=* and I believe we should use virtually all of these office with an appropriate associated tag. PeterIto 18:15, 27 February 2012 (UTC)

Industrial (people making stuff and moving stuff around)

• building="depot || Dairy || Depot || factory || Factory || Foundry || gasometer || industrial || Industrial || light_industry_units || manufacture || Mill || sorting_office || storage_tank || tank || tyre services || unit || warehouse || Warehouse || warehouses || works || Works"

Thoughts? Would it be useful to shrink this down to 'industrial' (except for gasometer and storage_tank) which should be 'man_made' and not be buildings at all? Should we create a industrial=* tag to indicate what sort of industry happens there? PeterIto 18:15, 27 February 2012 (UTC)

Transportation

• building="airport_terminal || bus_depot || bus depot || railway || railway_station || station || train_station"

Should we standardise on 'airport_terminal, train_station' and 'bus_depot'. Haven't found any 'transportation' examples yet - is this useful? PeterIto 18:15, 27 February 2012 (UTC)

All sorts of civil amenities

• building="arena || ambulance_station || ambulance station || amenity || arts_centre || bank || bar || cathedral || castle || cinema || club || Clubhouse and Grandstand || community || conference_centre || convention_centre || church || church_rooms || Church Parish Hall || city_hall || civic || courthouse || exhibition_center || fire_station || gallery || guest_house || gym || gymnasium || heritage || historic || hotel || laundry || leisure || leisure centre || Leisure Centre || leisure_centre || library || market || masonic_centre || museum || Neighbourhood Centre || parliament || Parish Church || public || public_building || place_of_worship || parliament || police_station || pub || restaurant || religious || service || shelter || sport || sports_centre || stand || surgery || Surgery || swimming_pool || telephone_exchange || theatre || toilets || tourism || townhall || Town Hall || vet || vets || veterinary"

Gallery as in 'art gallery' btw. Clear there could be some rationalisation here, but how much? PeterIto 18:15, 27 February 2012 (UTC)

Purely typology

• building="arch || block || bridge|| canopy || hall || linking corridor || multiple || roof || ship || tower"

This provide no information about usage. Is that good? PeterIto 18:15, 27 February 2012 (UTC)

I disagree. building=bridge says a lot about the buildings usage ^^--Shmias 15:46, 27 March 2012 (BST)

Life cycle

• building="abandoned || demolished || derelict || construction || vacant"

These ones describe the status of the building, but not what it was or will be. PeterIto 18:15, 27 February 2012 (UTC)

Adjustments

I have made a number of adjustments to this article. In particular I have:

• tightened up some of the descriptions.
• organised the table into sections for 'accommodation', ' commercial/industrial', 'civic/amenity' and 'other'.
• Added farm_auxiliary, hospital, semi-detached and warehouse. (which are popular values). In the case of warehouse it that was already mentioned, but didn't have it's own entry. I have removed panel_house (which was only used 89 times).
• Recommended that people use man_made=storage_tank (or silo) rather than building=storage_tank
• recommended that people use 'industrial' rather than 'manufacture'.
• indicated that a building which is part of a school that has a specific purpose should be tagged with its more specific purpose.
• encouraged people to use 'building=retail;shop=supermarket' rather than 'building=supermarket' (which bizarrely referenced shopping malls in the description)
• defined a hut as 'a small auxiliary building, possibly made or wood, metal or sometimes brick or concrete'. Is that right?
• clarified that 'terrace' and 'semi-detached' should be used to identify each individual dwelling within a row. Not sure it that is right, but we do need to distinguish between a row and an individual unit somehow.

Questions:

• Is a hangar a place for the storage of aircraft or another name for warehouse as the earlier description implied? I have defined it as a storage place for aircraft.
• Is the 'transportation' type useful? or should be encourage more specific tagging for bus stations etc? Also.. is it sufficient to tag an airport terminal as aeroway=terminal or should one also tag it as a building? Similarly for many other values.
• Should we remove the supermarket entry?
• What is a service building? Is it a useful entry.
• How should people tag retail shops that have residential accommodation above them (see 'retail' and 'apartments').
• domitory is confusing re British/American English. Can we use 'halls of residence' instead?
• Do we need a new industrial=* tag to indicate what process happens in a building or facility?
• What is meant by the term 'commercial'? Is it just another name for an office, or does it also cover industrial and manufacturing and even retail?
• Should we have a catch-all 'civic' or 'amenity' value to avoid people add huge numbers of custom tags?

Any comments?

--PeterIto 07:43, 29 February 2012 (UTC)

At this time three things come to mind:

• There was a start at a gallery of building types for tagging guidance at Key:building/Gallery and IIRC it was linked to from somewhere more prominent.

• Thanks. I would however suggest that we rely on suitable photos in the table on this page and then have an individual page for value if more information is required. PeterIto 17:39, 1 March 2012 (UTC)

• Around here people have generally tagged terraced buildings as one building=* way, with the entrances then with extra (letter) ref's for doors. Generally, the whole building is considered to have the same addr:housenumber, as opposed to each dwelling having a distinct house number. And in fact it's often several row houses on the same plot that share the same housenumber, since they are part of the same housing co-op. Also the exact division can be real hard to survey, when they're built as one building. But I can totally see how it's different for the individual one home buildings built wall-to-wall. But maybe we were ahead of times when we used building=terraced for the whole building ways? :) It's the same with duplex's, although we've encountered a duplex with the tenants garages between the homes, where it would definitively make sense to use a different tag stating "part of a duplex but this way depicts one home". One could look at the 1400 uses of 'semi-detached' and 200 uses of 'duplex' to try to see if they are to date entered as adjoining dwellings or whole buildings. I could have a go at it after about two weeks, but hope somebody beats me to it. Alv 09:23, 1 March 2012 (UTC)

• In the UK each house in a terrace has a different number, and it is normally possible to see the boundaries between each house based on the position of boundaries between gardens. PeterIto 17:39, 1 March 2012 (UTC)

• Also.. here is a new ITO Map layer which allows one to more easily see how people are using the different tags. In general 'terrace' seems to be used for the whole row, apartments as one might expect with other values used for individual houses. Overall however, the great majority of buildings are still tagged as building=yes. PeterIto 22:36, 4 March 2012 (UTC)

• The case at Germany, Bremen is similar to the UK. I understand building=terrace as a single unit within a row of terraced buildings. Otherwise it is necessary to rename building=* to buildings=*. The building tag is sometimes spoiled by 3D-Tagging, which is solved by building:part=*. On the other hand it is sometimes hard to find the spot where buildings are separated by each other. I think that the goal should be to have a single way for every single building - where possible.--Cracklinrain (talk) 20:19, 30 October 2013 (UTC)

• The value service seems to have quite a lot of uses, given it doesn't have any definition/guidance - are some of them the same as building=utility, as depicted on the gallery I linked to above? Alv 09:23, 1 March 2012 (UTC)

• Can I suggest that we define suitable more specific values and then deprecate service and convert them to garage/warehouse/shed/hut or whatever as required. PeterIto 17:39, 1 March 2012 (UTC)

• My impression on further investigation is that service is used for civic buildings rather than the sheds etc as I first assumed - ie, it is a service to the community, rather than a service to a dwelling. As you can see below, I have added 'civil' to the table to cover this public service, and removed service given that its definition wasn't clear and it wasn't a very good term anyway. PeterIto 22:36, 4 March 2012 (UTC)

Some comments in line above. Also.. I get the general impression that building tagging is reasonably in its infancy which is just fine, but let's spend a bit of time adding some of the 'missing' values to the table and answering more of the above questions. In particular, if terrace is used for the whole row of houses, then I think we will need a new entry for 'terraced_house' or something to use when tagging each dwelling unit separately; similarly for each half of a semi-detached where which should have a distinct value from the one describing the pair together. Not sure that 'terraced' is value though, given how similar it is to 'terrace'. Could lead to a lot of confusion. PeterIto 17:39, 1 March 2012 (UTC)

English planning law uses this classification system for building use: Town and Country Planning (Use Classes) Order 1987. I realise that we are tagging building typology rather than use as such, however good tags will probably say something useful about both typology and use. PeterIto 05:59, 4 March 2012 (UTC)

I have now made further adjustments to the building table implementing many of the above proposals. In particular, I have clarified the use of house, terrace and residential and created an entry for 'civic' to cover a range of civic functions (libraries, community centres etc). I have removed entries for collapsed, manufacture, public, service, supermarket and storage_tank and. PeterIto 15:52, 4 March 2012 (UTC)

I have adjusted the definition of building=commercial to fit more clearly with current usage of landuse=commercial and proposed that it is used with the office=* tag. Note however that landuse=commercial is not well defined but in usage seems to be reasonably well aligned to wikipedia:Commercial district. I have now removed 'building=office' (which I had introduced recently). PeterIto 06:30, 5 March 2012 (UTC)

Duplicating landuse values

This seems to be duplicating the landuse values, leading to a bunch of redundancy when a building and its surrounding lot are both mapped. --NE2 03:07, 2 March 2012 (UTC)

The values may be same, but I don't think it is redundant because they the building and landuse/amenity ways are tagging different areas? For example... the tag 'building=school' is be used on the ways identifying the school building(s) themselves, and the 'amenity=school' is used for the school grounds that contains the buildings + parking fields etc; similarly for hotels, hospitals and train stations. Or have I missed your point? PeterIto 06:42, 2 March 2012 (UTC)

Your example is redundant - a building in an amenity=school landuse is by default a school. If there's a non-school building on school property, you can tag that as an exception, just like a small park in a residential neighborhood. --NE2 15:15, 2 March 2012 (UTC)

I see what you mean, however I suspect that many people will choose to tag a school building within a landuse of 'school' as building=school rather than building=yes if only for tidiness. I doesn't result on an additional tag after all. PeterIto 18:39, 2 March 2012 (UTC)

The other problem is that the tags need to be coordinated. If landuse=x means something different from building=x (due to changes in tags or whatever) we have a problem. I can't think of any reason we'd want different values of the two tags. So one possibility would be to keep the building=* tag for type of building only, and use landuse=* on the building for the use of the building. (This would of course be easier if all the landuses were in fact in landuse=*...) --NE2 23:26, 2 March 2012 (UTC)

I agree that some landuse tags are in a muddle, however I suggest that we focus on getting a clearer set of agreed values for building first and then worry about any landuse issues. I do however note that seem to have reasonably conformance on tag values, building=school, amenity=school; building=hospital, amenity=hospital etc. PeterIto 17:57, 4 March 2012 (UTC)

Maybe I'm not being clear? When we talk about building use, that's the same general idea as land use. So the same set of values should be able to describe both. --NE2 22:59, 4 March 2012 (UTC)

OK, I see and I do agree that we should align them where appropriate. We do now have building values of 'residential, retail, commercial, industrial' which follow the landuse tags closely. However, it doesn't follow that every building in an industrial area will be 'industrial' etc as there may be offices and warehouses and possibly also the odd house. We should also be aware that there is an intention to provide information about typology of the building within this tag, as such we should consider adding entries for 'multi-story-car-park, fill-station canopy etc which provide more information about structure; I would like to now explore adding a good number of these to this list. Also... some landuse values are not suitable for building values, such as 'orchard' or 'railway' for which 'shed', 'warehouse' and 'industrial' are probably better. PeterIto 08:58, 5 March 2012 (UTC)

Apartments, house, residential and terrace

I have been investigating how residential properties are actually used using this new map layer on ITO Map. Given that we should be aiming for simplicity, can I suggest that we update the key:buildings table as follows. I am starting with the most specific, and progressing to the most general. For each of these we should create a wiki page where the details and special cases can be discussed. I am working on the basis that any down-stream software that wishes to determine if a house is 'detached', 'semi-detached' or 'terraced' will be expected to determine that from the connections between the various 'houses' and that we do not need to provide more detailed tags to distinguish these.

1. House: A single dwelling unit with an independent external access inhabited by a small group of people sharing facilities; for example a family home, or a house shared by a small group of people; a single house will normally have a single shared kitchen. It may be attached to other other dwelling units (for example as part of a pair of semi-detached houses or as one in a row of terraced houses).
2. Terrace: A building which consists of a number of distinct dwelling houses arranged in a row, each with their own entrance. A terrace can also be mapped individually using 'house' which each dwelling in the row sharing two or more nodes with each of its neighbours (A pair of semi-detached can normally be defined as two separate houses with a share pair of nodes rather than as a terrace).
3. Apartments: A building arranged into individual dwellings, often on separate floors. It might be useful to have a way of indicating both how many units there are, and the valid addresses within the building. In addition information about any retail or commercial space integrated into the structure.
4. Residential: The most general term, covering any of the above. Where detailed information is available one of the above will nearly always be more appropriate.
5. Hall or residence: Accommodation provided for university or college students or similar.

Any comments?

-- PeterIto 11:58, 3 March 2012 (UTC)

I have now adjusted the table as per the above proposals. See 'Adjustments' section above for more details. PeterIto 16:05, 4 March 2012 (UTC)

I understand the current description of building=terrace in the list as you are allowed to tag the single house with its own way and then again be able to overlap this way with a building-way which overlaps the way of the single terraced house. Am I right? If so, I would like to edit the description.--Cracklinrain (talk) 20:27, 30 October 2013 (UTC)

Cabins, huts and sheds

Continuing a review of these building value tags, I have been trying to make sense of how the values of 'cabin', 'hut' and 'shed' are being used in OSM. 'hut' is the only value in the buildings tag table, however cabin and shed are also reasonably well used in practice. It seems that all of these are being used in different places for the same function (mainly in Germany/Italy). I have created a new ITO Map view Cabins, huts and sheds to see how they are being used. Here are the main areas where the terms are used:

• A large area of Northern Italy uses 'hut' for small buildings associated with residential properties:[3]
• Lintz uses the term 'cabin' for what appears to be the same purpose: [4]
• To the East of Lintz the term 'shed' is used instead: [5], as it is in Dortmund.[6]
• Head to the Ollheim area, also in German and one finds that both 'shed' and 'hut' are used - but in this area 'shed' is used for larger structures than huts and these 'sheds' are probably not what a British English speaker would consider to be a shed.[7]

Personally, I would suggest that we add cabin and shed to the buildings table and define them as they are described in Wikipedia, which is:

• Cabin: "A small, roughly built house usually with a wood exterior and typically found in rural areas".
• Hut: "a small and crude shelter".
• Shed: "A simple, single-storey structure in a back garden or on an allotment that is used for storage, hobbies, or as a workshop".

Any thoughts? Needless to say, we would need to do some cleanup of the existing use of the terms in the above places. -- PeterIto 23:03, 4 March 2012 (UTC)

I have now added cabin and shed and adjusted the description for hut as per the above suggestion. PeterIto 07:00, 6 March 2012 (UTC)

Possibly additional values

The following suggestions for additional entries has been made above and copied here for more detailed individual discussion: PeterIto 04:37, 7 March 2012 (UTC)

Arenas

For example Colosseum and Bird's nest.

I agree, but possibly we need a number of values for different typologies. Not sure what you mean by the examples. Do you mean the Colosseum in Rome or elsewhere? PeterIto 04:37, 7 March 2012 (UTC)

I mean Colosseum in Rome, any other amphitheatre elsewhere and by Bird's nest the one in China. Maybe the antique ones deserve a different tag than the modern ones, but they are quite the same type. --LM 1 10:35, 7 March 2012 (UTC)

Exhibition building

Not sure if this is used in English; place where exhibitions take place.

There are probably a range of these and possibly conference_centre would be better. I do however agree that something would be useful. PeterIto 04:37, 7 March 2012 (UTC)

What I mean is not conference, even if that might also be a specific building type. I meant this or this. It is usually only on exhibition grounds. Some are simple warehouses, some are more interesting. --LM 1 10:35, 7 March 2012 (UTC)

Fuel-stations

The part that is not roof - retail?

I would suggest that a fuel-station canopy should be tagged with 'fuel-canopy' or something which provides more information about use and typology than 'roof' does not. The shop bit should probably be defined using retail with a shop tag given that these places are normally also more general types of shop. PeterIto 04:37, 7 March 2012 (UTC)

I have converted this section to British English and tweeked my response for clarity. PeterIto 12:37, 7 March 2012 (UTC)

Gazebo/pavilion

Could be useful and might replace 'roof' which doesn't convey any information about the use of the building. Lets ensure that the value conveys something about the particular use of the structure, ie implied availability to the public or not. PeterIto 04:37, 7 March 2012 (UTC)

Besides gas stations I have not seen anything that would be a roof only, even these pavilions have some (low) walls around. Leaving that aside, I see no problem in the tag describing only typology and not use. --LM 1 10:35, 7 March 2012 (UTC)

In principle does it make sense to look for names that provide information about both typology and use and use typology only in those situations where we fail?

I would prefer to have these two mapped separately (what is left if all the people leave), but majority of building types imply what they are used for (which I do not mind). This is mostly because I find it easier to work with it (map and use) if only one fact is mapped within one tag... --LM 1 13:34, 8 March 2012 (UTC)

Historic buildings

Ones that are likely to last longer than most of contemporary buildings: pyramids, castles (de:Burg), Châteaux (de:Schloss)/palace.

Are some of these not already covered in historic=*? PeterIto 04:37, 7 March 2012 (UTC)

They seem to be. In fact a castle is more a complex of building than a single one, but I am not confident enough in castle typology and even less in English names for it, so I cannot add anything more. --LM 1 10:35, 7 March 2012 (UTC)

I am going to leave that for others to suggest values as it isn't something that particularly concerns me. In principle however I think we should have values for them and that they should ideally tie into historical uses/designs. Possibly 'keep' or defensive wall' etc. Need to avoid duplication of other tags though. PeterIto 12:37, 7 March 2012 (UTC)

Mixed offices, apartments and retail

For sure, although it might be useful to distinguish a set of apartments with some retail on the ground floor from a highstreet shop with a big shop and a single small apartment above.

Sure, I do not have any sensible scheme at hand, but will think about it. --LM 1 10:35, 7 March 2012 (UTC)

I would propose multi-use. Some buildings (the one I live in, for instance) have a broader mix of usage types than simply retail on the ground floor and apartments above. My building has a mix of commercial, organizations, commercial offices, and residential units sprinkled throughout it. I have seen similar buildings in the USA and India (can't speak for the rest of the world).

Maybe use semicolon-separated values, like building=apartments;office;retail? But I think that is more appropriate for building:use=*. Buildings specifically built for mixed use can be tagged with a specific building tag, and then their current use can be tagged with building:use, such as building:use=apartments;office;retail. building=mixed_use is already used 1377 times, building=mixed-use 17 times. Hanif Al Husaini (talk) 14:28, 10 April 2020 (UTC)

Towers

Do you mean communications towers or sky-scrapers or communications towers (which are covered by man_made=tower already? PeterIto 04:37, 7 March 2012 (UTC)

Sky-scrapers would mostly fall into mixed or offices. I mean towers like the Clock tower (Big Ben), Žižkov TV tower or Rheinturm they can be used for communication, but have other uses (restaurants, viewpoints...). I am not sere it they are covered by man_made=tower, all mapped as (multiple) building=yes, some have man_made tower added. Mappers clearly see these structures as buildings more than towers so we should have building=tower. (Leaving man_made=tower for ones that do not qualify as a building. I would not be sure about Eiffel tower (currently both building=yes and man_made=tower). --LM 1 10:35, 7 March 2012 (UTC)

Probably best to avoid reuse of the term 'tower', however a useful distinction is that if people work or live in the structure then it is almost certainly a building, if not then it is probably a structure? Are we talking more about 'turret', ie a vertical structure coming out of the roof or from the walls? We are however possibly getting into Google Sketchup land, and incidentially I see no licensing reason why people can't describe buildings in 3D using sketchup and link them into OSM. We might need to create our own warehouse to avoid fall foul of their 'anti-scraping' policies, but if we need 3D then that is a great tool. PeterIto 12:37, 7 March 2012 (UTC)

I have been thinking about SketchUp already. Some of the models were even contributed by volunteers, who might agree to give them to OSM too. But that is way more detailed than distinctive mapping of very high buildings (towers).

In all the towers (except for BigBen) I mentioned, there are restaurants on the top, so it would fall within your definition of a buildig, Eiffel tower is probably not a building, but "only" a structure. My distinction of tower(building) v. tower(structure) would probably be the existence of enclosed space that can accommodate people (wider than yours, they neither have to work nor live there, they have to be able to be inside of it). Most of lighthouses would fall within this definition (unless they have a separate category): building example; structure only example.

I would not insist on the word tower, but I do not know about any other one that describes this kind of buildings and it is used in this meaning already --LM 1 13:20, 8 March 2012 (UTC)

Some 'towers' are parts of buildings for example clock towers. Warin61 (talk) 01:39, 3 June 2023 (UTC)

onRelation?

As far as I can tell, the building key is not used for relations other than multipolygons (which are areas), so suggest to remove the onRelation=yes. Or can anyone offer examples for other established relations with building tags? --Tordanik 14:14, 7 March 2012 (UTC)

You are of course correct with that. It can be used on a relation, but only the multipolygon relation which seems to be treated in a different way (as an honorary way?). I will remove the onRelation=yes. See above for our discussion about its use with relations. PeterIto 14:27, 7 March 2012 (UTC)

So there is a general consensus that "onRelation" means "only it is used on relation other than a Multipolygon"? And if the tag is used on multipolygon relation then it is just "onArea"? If yes, then I will need to revert some changes I have done lately. Chrabros (talk) 12:55, 6 February 2014 (UTC)

Hey guys, you suggest that multipolygon relations are not relations. Nice job to create confusion and mess in this wiki. For me, since the beginning, onArea means a closed way, nothing else. If you are unsure with OSM elements, re-read basic pages like this one : Elements#Area_.28closed_way_.29. You will discover that multipolygons are everywhere in the wiki considered as ... relations first. --Pieren (talk) 14:48, 6 February 2014 (UTC)

The section you linked to doesn't exist. But perhaps you should read Area ("An area (or filled polygon) can be defined as an enclosed filled area defined as a closed way with appropriate associated tags or using a relation:multipolygon ..."). If that doesn't convince you, then consider:

• When you query the Overpass API for areas, the result includes multipolygons.
• The planned "area" datatype will probably replace both areas modelled as ways and areas modelled as relations. At which point an onRelation due to multipolygons would definitely stop to make sense.
• And ultimately: Is there any area tag that can only be used on closed ways, but not on multipolygon relations? I don't think so. So what information does adding onRelation to every single feature with onArea add?

I think that, yes, multipolygons are areas, and it makes sense that onRelation means "on relation that isn't multipolygon", just as onWay means "on way that isn't a closed way with an area tag". Even though for some reason, you only seem to be surprised by the former. --Tordanik 16:28, 7 February 2014 (UTC)

You make a very good points here Tordanik. IMO the whole debate is just about one thing: Pieren advocates the original status quo which was valid for a long time here. And it is that onRelation=yes means multipolygon relation, because it is relation. And Tordanik is kind-of proposing a new better way how to do so. I believe that there is no telling who is right, because both ways are reasonable way of thinking about it. I think that the best way would be if someone would write a wiki page about it, maybe even make it a proposal, and we will see how the other will react. I would be happy with any results, provided that there would be any standard after all.

I was not aware until now that Overpass API has an extension for querying areas. I was using only queries for data primitives and therefore distinguishing between query for a way and query for a relation was crucial. And I believe that this is quite common. So the information that you have to search for relation as well was valuable.

If there will be a new type "Area", then we will probably have to change this everywhere. But at the moment it is not established, so this is not a really good argument.

I do not think that there is a equivalency between "area" and "multipolygon relation". I think that you can create a multipolygon relation which is not an area, that it would be interpreted just as a collection of ways. I think that if you have a really long way then you have no other choice than to put in in a multipolygon relation. Or am I wrong? There is a note on wiki that in the past the multipolygon relation was used to map country borders and those are ways, not areas.

But finally I am still unable to find an answer for the question: "If we exclude multipolygon relation used as areas from onRelation, then what are the tags which belong to this category?"-- Chrabros (talk) 07:18, 11 February 2014 (UTC)

Multipolygons always represent areas. You cannot use it to represent a really long unclosed way, and I believe the multipolygon definition makes this clear in the beginning already. The use of multipolygons for country borders makes sense when mappers look at it in a different way: Mapping the country (note that borders get name=NameOfTheCountry tags). The alternative way of thinking - mapping the border itself - gave rise to the boundary relation type.

As for tags that are intended for use on non-multipolygon relations, here are a few examples:

• boundary=*, admin_level=*, name=* for boundary relations
• route=*, operator=*, ref=* for all sorts of route relations
• colour=*, network=*, wheelchair=* for public transport route relations
• symbol=*, ascent=*, descent=*, roundtrip=* for hiking route relations
• waterway=*, destination=*, wikipedia=* for waterway relations
• enforcement=*, maxheight=*, maxweight=*, maxspeed=* for enforcement relations

And so on. There's really not a shortage of them.

Your idea of a proposal is certainly a possibility if this cannot be resolved otherwise. But it's a lot of effort for clarifying a small detail, and I had just naively hoped that each side presenting arguments would be enough to reach a consensus. --Tordanik 17:47, 11 February 2014 (UTC)

Well, I was not talking about long unclosed ways. Thanks for disproving argument which I have never raised. Bit of fallacy, huh?

So, you see multipolygon relation for country borders (which was used in the past, I know, no need to point it out) as an area of a country. And I see it as a way. Who is right? I do not know.

Thanks for listing up the tags suitable for onRelation. But it seems to me, that there are really no tags suitable to be labeled onRelation, with the exception of the really general ones like ref, source and name. It seems to be that there is a set of tags suitable for ONE relation, but not good for OTHER relation with different type.

So, as we really cannot reach an agreement, then (if you will keep promoting the idea that multipolygon should not count for onRelation) I think that it would be better to remove the onRelation from the templates for good. As it is just source of confusion. (And yes, you are right, that IF anyone would know that we include multipolygon in onArea, then onRelation provides no additional info here. But that is not widely known I am affraid, mostly because there is no info about it on wiki.) Chrabros (talk) 16:37, 12 February 2014 (UTC)

I'm replying to Tordanik's points below:

* "The section you linked to doesn't exist.". Come on, read the page, It's not so big. Here is the section Elements#Relation where the multipolygon is in relations and the icon is on the way section. This was the original version of the area symbol . Now, you try to change it.

* "When you query the Overpass API for areas" overpass API is an external tool with its own definition of areas. It has not to dictate how the wiki wording (could be the opposite).

* "The planned "area" datatype will probably replace both areas modelled as ways and areas modelled as relations.". We don't know how and when the planned "area" will be defined. Hugh areas might simply continue with the multipolygons relations.

* "Is there any area tag that can only be used on closed ways, but not on multipolygon relations?". The "area" icon, you mean: . Answer is not. But this is because the icon distinguishes linear features (unclosed or closed ways but linear , like "highway=residential") to surface features (closed ways like "highway=residential" + "area=yes" )

* "onRelation means "on relation that isn't multipolygon" ". Multipolygons are obviously done by relations. Saying what you say is just creating confusion to newcomers and is not acceptable. --Pieren (talk) 10:02, 11 February 2014 (UTC)

Pointing out the broken link was an attempt to point out that the Elements page changed a lot over time. The last version in which the "Area (closed way)" heading which you cited has existed is from 2011. For two years, the multipolygon was in fact mentioned in the area section. until last year someone completely changed the page again. But I don't consider that support for either your or my position - the page is just too unstable to reliably prove anything. For some reason, you also choose to ignore the Area page completely.

When you point out that neither the Overpass API nor as-of-now unimplemented plans for the future are normative, you are, of course right. I merely meant them as indications that the concept of "areas" encompassing both way-areas and relation-areas does indeed exist among members of the OSM community.

Your last two bullet points, however, do not actually confront my arguments - you just repeat your position as a fact. Specifically:

• I pointed out that, because your definition would require all tags with onArea to also get onRelation, this style of using the Key/Value templates does not give any additional information to the viewer at all. You did not explain why you consider that a good idea.
• I asked why excluding way-areas from onWay is ok, but excluding relation-areas from onRelation is not. Again, you did not reply to that.

I'm not sure what to make of that, it definitely does not help not help leading this topic to a conclusion. --Tordanik 17:47, 11 February 2014 (UTC)

This icon system is ugly and confusing. Basically, all tags could be part of a relation and not only multipolygons - see e.g. multilinestring. For me, these icons are only interresting if we say that the feature is just a node or if it's a line, a surface (area) or not (a loop). We don't need a relation icon in this case. --Pieren (talk) 17:41, 12 February 2014 (UTC)

Church, chapel, cathedral

What's the difference between a church, chapel, and cathedral? One can have a chapel without having a church, and vice versa. These should be described in the Building Typology template. --Stevevance (talk) 02:19, 20 February 2013 (UTC)

Well as I understand it the church (the organization) knows it better so they name the building accordingly. IMO chapel inside the church is not mapped. We map just chapels as standalone building. Chapel is usualy smaller then church, but the most important difference is that anyone can build a chapel (as a part of its castle or manor), but church is built by the church (organization). Cathedral is then a fancy church built as a seat of bishop (though they are some churches built in cathedral style, which never had bishops). So in general, I would say, tag it as it is called by church, they know why they call it that way. :-) Chrabros (talk) 13:03, 6 February 2014 (UTC)

onNode?

I have changed the tag description to onNode=yes and it was reverted. Nevertheless there are more than 700 000 buidlings tagged as nodes and sometimes it is pefrectly good way (i.e. large terrace house tagged with building=terrace and the individual houses tagged with just nodes building=house) when there is no way of telling where is the exact division between them. So are we going to pretend that the building can be used only onArea? Chrabros (talk) 13:03, 6 February 2014 (UTC)

Even here [8] is clearly said that use of building= on a node is acceptable. I understand that it it desirable to map the building as area, when it is possible. But sometimes it is not possbile (when I meet a building in dense forest and I am not able to trace its outline properly) or not really useful (like mapping a really small building, i.e. military bunker (pillbox), where his dimensions 2mx3m are less than expected GPS accuracy). Then a node is a obvious choice. So I would like to return onNode=yes. Chrabros (talk) 06:10, 7 February 2014 (UTC)

The practical usefulness of building nodes is very limited, and as for your examples: Mapping a building within a building, as Chrabros suggests, is not valid tagging. For the military bunker there is military=bunker.

Nevertheless, buildings on nodes can admittedly make sense in certain cases, so after some consideration the onNode=yes should not have been reverted. (It would had helped if the changeset comment had contained any reason for the change, though.) I still believe that onRelation=yes, which was added in the same edit, doesn't make sense. The only relation type useful for buildings is multipolygon, and that's covered by onArea=yes. --Tordanik 10:07, 7 February 2014 (UTC)

OK, thanks.
Regarding onRelation please read the comment by Pieren above, or my talk page. I think that his arguments are better. If onRelation=yes would be used only on relations other than multipolygon, it would be really confusing and I do not know many tags which could be used onRelation then.
Tagging building inside buildings is probably not a good idea, but it was kind of suggested with building=terrace and I do not know a better way how to do it, if the actual borders of indiviual dwellings are not known, but you want to tag it with addresses. Chrabros (talk) 13:33, 7 February 2014 (UTC)

You can tag addresses on a node without also tagging that node as building. So you could still place the address nodes inside the building outline. If you know where the entrances are, it's also very common to map them as entrance=* and add the addresses there. As for the relation topic, let's continue that at onRelation?. --Tordanik 17:02, 7 February 2014 (UTC)

I want onNode=yes back. Why? Because in rural areas it can be very useful to know that there is a building, even if you do not know the size or corners of it.
I believe that the 7-800 000 building nodes currently tagged in OSM are useful on the map - I would like them to be rendered on [openstreetmap.org] as well.
I am also afraid that people tracing multiple small buildings now sometimes are inventing corners in order to create an area and satisfy the onArea demand! That is hard to detect and hard to correct... I would thus much prefer to allow onNode tagging of buildings. --anderfo 20:48, 29 October 2014 (UTC)

I also agree that onNode=yes is sensible here. It is often necessary in HOT aerial mapping when we have low-resolution imagery to work from. Also, for humanitarian purposes there are serious uses for node-only buildings, for estimating the population or the population distribution in a place. I will change it now. --Danstowell (talk) 18:28, 16 February 2015 (UTC)

For reference please see this discussion on the tagging list, February 2015, with various opinions expressed --Danstowell (talk) 18:36, 16 February 2015 (UTC)

Proposal for building=ruins

There are many ruins of abondoned buildings in the Alps. This could be former houses, sheds, stables. IMHO the tagging "building=yes" + "ruins=yes" is not adequate, because there is no description of the former building. The tag historic=* is not suitable, because the historic relevance is very low. A good and easy tagging would be building=ruins. It is already in use, but not mentioned in the wiki. I also recommend not to use "ruin" to get a explicit tagging scheme. --Rudolf (talk) 20:32, 21 March 2014 (UTC)

Not a good idea imo because ruins are not a building, but all building=* tags should be buildings. --Tordanik 18:57, 22 March 2014 (UTC)

The feature buildings is used to describe many different sorts of buildings, including houses, factories and ruined buildings. My proposal matches this definition. The combination "building=yes" + "ruins=yes" is described in ruins=*. Do you prefer this tagging or do you have another suggestion? --Rudolf (talk) 21:20, 22 March 2014 (UTC)

I think that ruined:building=* would be ideal. This would be similar to the recommendation on Key:disused. But I have to admit I never noticed that bit of text on Buildings. --Tordanik 22:26, 22 March 2014 (UTC)

IMO the correct tagging seems to be dependant on the state of building. Is it more ruins or more building? If you can still see the walls then it is building=house, ruins=yes. It if it really ruins and you maybe see just base then it is ruins=building. Chrabros (talk) 04:50, 23 March 2014 (UTC)

What is linked at https://wiki.openstreetmap.org/wiki/File:Ruins_valgrande_5725.jpg is not a building anymore, I would retag any similar ruins still tagged as buildings Mateusz Konieczny (talk) 14:23, 9 March 2018 (UTC)

Porches

What do you do if a building has a porch which is covered but not enclosed? Include the whole thing as the area for the building? --Marion Barry (talk) 19:16, 7 July 2014 (UTC)

I include the whole area. Of course you can split it as well and tag the porch as building=roof. Chrabros (talk) 06:53, 8 July 2014 (UTC)

How to tag a Würstelstand

In Vienna, Austria you find food booths called Würstelstände all over the city. Sould I tag these buildings as huts (building=hut) or would it make more sense to define a specific tag like building=food_booth? --Stefan Nagy (talk) 17:54, 24 October 2014 (UTC)

It seems people tag things like this with amenity=fast_food + cuisine=sausage, but you should ask your local community to be sure. --Jgpacker (talk) 18:08, 24 October 2014 (UTC)

Building Use or Building Design

I find the description of this key a little vague, and this is specially reflected through the different value pages. As my original understanding and which also is my opinion, the building=* key should reflect the design or construction of the building. In most cases the use of the building would be the same, for example building=apartment would be a residential block with lots of apartment units. However not all such buildings are of residential use, there are cases where such buildings are converted into an office block (landuse=commercial + office=different values + building=apartment). Mostly this is the case in larger cities where central downtown areas gradually converts from residential to commercial/retail. The building design and construction doesn't suddenly change, and would continue to appear as an apartment building from the outside until the building either is demolished and reconstructed, or have undergone a major reconstruction. - I wish that somebody can look at rewriting the key page and several of the value pages on order for this to be clearer. BTW use is already tagged in most cases through other tags, such as landuse=*, amenity=*, office=*, craft=*, shop=*, etc. --Skippern (talk) 14:07, 5 February 2015 (UTC)

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

I have suggested some new building types, see here: https://wiki.openstreetmap.org/wiki/Talk:Buildings#Suggesting_a_bunch_of_new_building_types_which_came_into_my_mind --Wuzzy (talk) 20:15, 3 May 2015 (UTC)

building=office

Would it be useful to add building=office to Deprecated_features? The tag was documented here in 2010, removed in favour of building=commercial in 2012 and re-added striked-through in 2015. I consider building=office a "false friend" since this is the first which comes to mind if I want to map an office building.

On the other hand with a usage of 50000 it may be best to keep it as a synonym.--Jojo4u (talk) 13:56, 18 July 2015 (UTC)

It is no longer considered as deprecated Mateusz Konieczny (talk) 11:39, 29 July 2020 (UTC)

House vs Detached?

Whats the difference between the two? building=house I get it's a family home. Is building=detached just a precision to say that it's a standalone building with no other house connected to it?

From how the wiki reads to me. Although, it's not exactly how the terms are used around here, but does follow the standard dictionary definition.

• House - A single unit that may share walls with other houses. Think four homes in a row where side walls are shared. Example: ,,, ┃ ▮ ┆ ▮ ┆ ▮ ┆ ▮ ┃ ,,,
• Semi-detached - Same as house, but only one wall shared. Example: ,,, ┃ ▮ ┆ ▮ ┃ ,,, ┃ ▮ ┆ ▮ ┃ ,,,
• Detached - No shared walls. Example: ,,, ┃ ▮ ┃ ,,, ┃ ▮ ┃ ,,, ┃ ▮ ┃ ,,, ┃ ▮ ┃ ,,,

Fearsyth (talk) 22:13, 26 January 2020 (UTC)

Addendum: What you are describing is building=terrace (the entire block), or building=house + house=terraced (individual sections). building=house is a unspecified single-household structure, specifying building=residential, which further clarifies a building=yes. building=house is usually a building=detached (what I mentioned and house=detached are used less often). I suppose. --- Kovposch (talk) 12:50, 29 May 2022 (UTC)

building=stands vs building=grandstand

I noticed that there is a new building=stands entry on the Wiki building page, but do we really need this? There is an already quite well established, but undocumented tag, of building=grandstand. This latter tag is at least four years old, and likely quite a bit longer, and has 2380 uses according to TagInfo (https://taginfo.openstreetmap.org/tags/building=grandstand). Even though undocumented - just like the building=stands which doesn't have its own Wiki page yet - I would personally be in favour of keeping the old tag, and document it, rather than introducing this new one, which currently only has 244 uses (https://taginfo.openstreetmap.org/search?q=building%3Dstands).--Mboeringa (talk) 16:43, 17 October 2017 (UTC)

Fully agree. All done, as discussed on the tagging mailing list. --Polarbear w (talk) 18:56, 27 October 2017 (UTC)

Suggested values

building=gymnasium

Even if the value is actually not very used, the reality is common and the architectural specificity make this value handful. FrViPofm (talk) 12:08, 9 March 2018 (UTC)

building=sports_hall is used 245x, and documented here: Proposed_features/Sports_hall. There is also 1200x "building=sport" which is a mistake since 'sport' is not a building type. 'sports_hall' is clear and unambiguous, while 'gymnasium' is a false friend in some languages, e.g. in German it is a school form. --Polarbear w (talk) 14:48, 9 March 2018 (UTC)

I also thought about it as a school type (in Poland it was school level between elementary school and high school) Mateusz Konieczny (talk) 10:38, 10 March 2018 (UTC)

Sheds for rubbish bins?

Another user added this to the map features page, and it's been used 233 times

building=garbage_shed - A garbage shed is a building used to store waste bins. May be locked. Usually meant only for the use of specified property.

However, I understand that garbage or trash (US English) should be rubbish (British English). Also the value could suggest a shed filled with garbage directly, rather than for storing waste bins.

So perhaps building=rubbish_bin_shed could work, or just use the common tag building=shed with shed=rubbish_bins? --Jeisenbe (talk) 04:53, 7 July 2019 (UTC)

Is there already a tag for outdoor rubbish bin sites? In my opinion, it would intuitively seem better to use that same tag, but combine it with building=shed. This mirrors how we usually separate the building tag (for the physical structure) from the amenity/shop/... tag that describes the functionality provided by the feature. --Tordanik 15:53, 9 July 2019 (UTC)

Definition of "building=" as actually used in Openstreetmap?

The page currently lacks a definition for the term "building."

My impression is that an area feature tagged building=* in Openstreetmap is always covered by a roof of some kind. The presence of walls is optional. So I would not tag an open lattice mast, used to hold cellular phone transmitters, as a building, because it does not have a roof. But a parking structure is a building because the top level serves as a roof for the lower level(s), and the covering over a petrol station is a building=roof.

This suggests that building=* should not be used for abandoned buildings if the roof has collapsed.

Does this description seem to fit with how the key is used in other parts of the world? --Jeisenbe (talk) 23:37, 16 September 2019 (UTC)

Making useful definitions that matches usage is tricky. Note that building tag is not used for bridges (that can be considered as special case of roof) and is actually used for buildings that are ruined. For extreme case see Forum Romanum and Ostia Antica. Other edge cases involve (nearly) parmanently moored boats (commonly tagged as building=*, IMHO correctly) and structures like obelisks, monument foundations, building foundations (abandoned constructions) - often mapped as building IMHO incorrectly. There are also silos and tanks for storage of liquids Mateusz Konieczny (talk) 10:35, 17 September 2019 (UTC)

I don't think bridges have ever been considered "roofs" or buildings in English at least. Permanently moored houseboats are fine: they have a roof and walls of a sort and are semi-permanent. I'm surprised that some obelisks are mapped as buildings, that seems to be a stretch for a solid, vertical piece of carved rock, but there are only a few hundred of these in the database so it's a minor issue. Silos and tanks have a "roof" and walls, of a sort, so I can see why they qualify. --Jeisenbe (talk) 11:48, 17 September 2019 (UTC)

What about building=plot

I have seen some people use `building=plot` in their mapping and it seems there is no issue with using such tags in OSM. But there is no entry and information about what this tag meant for. If this is standard tag, please provide information about it and its use cases. If not, please suggest what to do with it in mapping.

Ahangarha (talk) 12:37, 21 June 2020 (UTC)

I don't think this is a tag that should be used. A building plot is not a building, and therefore should not use the building=* key. It's also a pretty rare tag, globally speaking (see the map of occurences on Taginfo), so it may be related to some import or organized mapping. If possible, talk to the people using it and try to find out what they are trying to achieve. --Tordanik 18:21, 21 June 2020 (UTC)

But OSM accepts this tag. It doesn't show validation error also. If it is not supposed to be used, it should be removed from the list and also mentioned in the wiki page that it shouldn't be used. It should suggest people to use what tags if they want to refer to the building land. Ahangarha (talk) 19:34, 21 June 2020 (UTC)

"But OSM accepts this tag." there is not really such a concept.

"It doesn't show validation error also." No validator is perfect. This is especially not expected for new/unusual values.

"It should be removed from the list" What list?

"and also mentioned in the wiki page that it shouldn't be used" Why should a wrong tag be mentioned in this key page?

"It should suggest people to use what tags if they want to refer to the building land." Yes, there is already place=plot.

-- Kovposch (talk) 21:00, 21 June 2020 (UTC)

See this screenshot: https://i.imgur.com/VbH9MPH.png in which by typing `pl` it gives me auto completion for plot.

Do you suggest I replace all the `building=plot` into `place=plot`? Please have a look at https://www.openstreetmap.org/way/796451671 and tell me what is the best practice here. Should I redraw all of them for actual buildings with proper tag of `building=yes` or keep them like this by modifying tag into `place=plot` and then draw building inside the plot? What is the best practice? Specially because there are many buildings which are hard to draw as building but easy to map as plot. Ahangarha (talk) 09:28, 22 June 2020 (UTC)

Update: I have realized using `place=plot` demands adding name tag which is not possible for plot of a house! and based on what yesterday is written here: https://wiki.openstreetmap.org/wiki/Tag:place%3Dplot#Possible_synonyms using `building=plot` is common in middle east and in particular, Afghanistan and it is suggested to not change it unless there is a good reason. Clearly there is a ambiguity here! Ahangarha (talk) 10:34, 22 June 2020 (UTC)

"in which by typing `pl` it gives me auto completion for plot" - iD editor autocomplete is done in a quite dumb way, it is not distinguishing between values that make sense and make no sense at all. It is proposing all used values. If for some reason "pldhduhdhdudyhdu" would be used many times then it would propose also this in autocomplete

"Do you suggest I replace all the `building=plot` into `place=plot`? Please have a look at https://www.openstreetmap.org/way/796451671 and tell me what is the best practice here" - do you have say a photo of such area? Aerial image is not really clear.

Is it a single building or a group of buildings? Is it constructed as a place to live there (residential building?) Or for some different purpose? Mateusz Konieczny (talk) 11:43, 22 June 2020 (UTC)

I have no image except Maxar imagery which I guess is the latest for Afghanistan. But I am living close to this area. So I know what is there. What is mapped, is the land or plot not building itself. As you see, imagery is not that good and in addition to that, there is no harmony in the way buildings are made. In cases, sse of mud on the roof makes it so difficult to map buildings. So it would be a good idea to map the plot but it seems there is no proper tagging for such cases. useing `place=plot` wouldn't work as it requires to be accompanied with `name=*` which is not possible in such cases. I really don't know what to do. I cannot map buildings in rural areas as well as their structure is more complex that what you see in city. (look at this for instance: https://www.openstreetmap.org/node/5404691582) Ahangarha (talk) 08:08, 23 June 2020 (UTC)

"What is mapped, is the land or plot not building itself" - then building=* is certainly wrong. Maybe map landuse=residential for areas with residential buildings? Mateusz Konieczny (talk) 10:28, 23 June 2020 (UTC)

The landuse=residential shouldn't be used for an area consist of several building? Is it find to use if for individual buildings? I feel it would be wrong.Ahangarha (talk) 18:56, 23 June 2020 (UTC)

Yes, landuse=residential is for entire residential neighbourhood/city block/residential area in town, not for a single plot or building. For single building we use building=*. I mentioned it because in case of low quality aerials individual buildings may be not mappable, while it may be possible to map landuse=residential (what often is also much quicker, even in case of good aerial allowing to map buildings and provides plenty of information) 22:08, 23 June 2020 (UTC)

It's possible to use landuse=residential for individual "areas" if they are significant on their own. It's also about level of detail and iteration, since land-use can change within a block. They are often used to map housing/development projects, so it could depend on the scale of planning in the region. -- Kovposch (talk) 02:23, 24 June 2020 (UTC)

"useing `place=plot` wouldn't work as it requires to be accompanied with `name=*` which is not possible in such cases" You can definitely change them if you know that's the correct thing, then put a fixme=*.

Corridor between buildings?

How do you tag a corridor that connects two (or more) other buildings (sorry no picture yet)? I'm referring specifically to a corridor which is technically a separate building, separated by fire doors from the usually larger buildings at each end, and provides an indoor-like environment, protected from the elements, often with air-conditioning and/or heating, and security from unauthorized access from outside. -- T99 (talk) 09:24, 25 June 2020 (UTC)

I would map it as a separate building with highway=corridor inside or with highway=footway if acting as a public footway) Mateusz Konieczny (talk) 11:29, 29 July 2020 (UTC) (@T99:)

I would map the outline of the enclosed corridor as building:part=yes and include a highway=corridor running down the centre. The corridor would be part of the building outline (i.e. the 2 buildings plus corridor should be part of one ginormous building=* outline area; though you can break it up similar to Mateusz Konieczny's suggestion; you can then break it down with building:part=yes areas). --Dónal (talk) 11:35, 29 July 2020 (UTC)

Official opening date of a building

Many landmark buildings have official opening dates where someone high profile officially opens the building. This is usually preceded by a soft opening date or construction completion date. Should these be captured? start_date=* already exists for the construction completion date but don't see anything for official opening date. --Dónal (talk) 11:27, 29 July 2020 (UTC)

I would consider both as historic data out of scope of OSM and recommend collecting it in say wikidata project Mateusz Konieczny (talk) 11:28, 29 July 2020 (UTC)

Would be acceptable when there's a plaque or something recording it, in which both can be mapped. -- Kovposch (talk) 12:30, 29 July 2020 (UTC)

"start_date=* already exists for the construction completion date" There's your problem. This is used for that, not what you think it is for. This is often discussed. How do you define "a soft opening date or construction completion date"? They are already two different matters. What if the official opening ceremony occurs after tenants move in, or even after the thing opens for public? -- Kovposch (talk) 12:30, 29 July 2020 (UTC)

Buildings for animals other than cows, horses and pigs

We have cowshed, stable and sty for buildings that house cows, horses and pigs, but we don't have anything to describe housing for other farm animals such as chicken, goats, sheep, etc. (can't imagine how many different animals are kept as farm animals in different parts of the world). Would it be a good idea to create a tag "animal_housing" (unfortunately English doesn't a have a general word equivalent to de:Stall) that could be used to describe a building for housing animals, where it can then be specified which animals are kept there (it may be unknown as well)? This would also nicely cover buildings that keep zoo animals.--Rhhsmits (talk) 13:38, 17 September 2020 (UTC)

Good question, as asked in Talk:Tag:building=sty#Domestic_and_Industrial.3F. Supposedly building=farm_auxiliary may do for now? I don't like the combination of animal_keeping:type=* with animal_keeping=*in Proposed_features/landuse=animal_keeping ("animal husbandry" will also be more specific to agriculture than "animal keeping"). I don't understand why animal=* has so many variety use as in animal=school and animal=horse_walker either, when most are animal=yes followed by animal=chicken. It or a "livestock" key would be a good counterpart to crop=*. ---- Kovposch (talk) 05:17, 18 September 2020 (UTC)

We have been discussing factory farms on Slack. One suggestion was to add building=cafo, where cafo stands for Concentrated Animal Feeding Operation. Factory farms are becoming a environmental issue that would be helped if we could differentiate them in OSM. Glassman (talk) 20:00, 11 December 2022 (UTC)

Foundations

What's the best way to map foundations - where no walls have been set up yet, usually somewhat abandoned? For now I'm aiming for building=foundation, with a hope to see them rendered with a very light shading in future. --Richlv (talk) 23:38, 8 January 2021 (UTC)

What value would it add which prevents you from using building=construction? Ahangarha (talk) 09:22, 9 January 2021 (UTC)

I would use abandoned:building=construction as it is not really building Mateusz Konieczny (talk) 11:00, 9 January 2021 (UTC)

Great suggestions, thank you. building=construction might suit well indeed. One problem with abandoned:building=construction might be that it would be missing in most data consumers, and that would both make collecting such data less useful, and decrease the motivation to map such instances. --Richlv (talk) 14:30, 11 January 2021 (UTC)

I, in turn, would use it deliberately to ensure that catch-all rendering of buildings will not render something that is not (for now) a building Mateusz Konieczny (talk) 14:44, 11 January 2021 (UTC)

Mapping ships and other vehicles as buildings?

Another user wanted to add building=ship to this list, however, it seems that most vehicles are not mapped as buildings even when they are (semi-)permanently in one place. --Jeisenbe (talk) 08:33, 25 February 2021 (UTC)

Obviously, not all of them. Only ones that are functionally a building, see building=mobile_home and building=houseboat. building=ship and building=boat is something that I would consider correct in many cases. Note that for example historic=aircraft is extremely unlikely to qualify Mateusz Konieczny (talk) 09:49, 25 February 2021 (UTC)

building=demountable

Image of pre-fabricated buildings in Massy, Essonne, France.

The building=container page mentions that building=demountable should be used for pre-fabricated buildings that are in long-term use. Unfortunately, these seem to be common for schools and in some cases, hospitals, in the UK and Ireland where more space is needed but capital funding has not been provided to extend existing / build more permanent structures.

Usage seems to be very low (< 200) so wondering if more discussion is needed.

In addition, it would be good to identify what supplemental tags should be used for these buildings. i.e. building:levels=*, building:material=* may be relevant.

--Dónal (talk) 09:18, 22 April 2021 (UTC)

marquee vs tent

@X a x: ([9]) - is there some good reason to mention building=marquee rather than building=tent? Mateusz Konieczny (talk) 04:39, 24 June 2021 (UTC)

The reason would be, that I started thinking to edit the German version only, until realizing the not-so-intuitive templating mechanism used to support i18n of tag/value/descr tables. And the German wiki does not mention building=tent, only building=marquee.-- ✗ Λ χ ⌘ 08:07, 24 June 2021 (UTC)

@X a x: Then maybe German version should be edited to stop recommending marquee? Is there any good reason to mention building=marquee rather than building=tent? Mateusz Konieczny (talk) 09:03, 19 July 2021 (UTC)

Element column in template

Resolved

The "Element" column in the table with tags seems a bit redundant, as it's the same for every building=* tag and it duplicates info that is already present in the KeyDescription template. Would anyone object to the removal of this column? --501ghost (talk) 13:37, 1 April 2022 (UTC)

I agree, it is difficult to read such a table on small screens. — Grass-snake (talk) 17:41, 1 April 2022 (UTC)

+1 to removal, especially as it is wrong (areas are highly preferable but mapping as nodes is OK) Mateusz Konieczny (talk) 21:23, 1 April 2022 (UTC)

You will separate the bottom Key:building#Additional_attributes section that needs it? --- Kovposch (talk) 09:52, 2 April 2022 (UTC)

Thanks for the feedback. I checked if I could easily implement Kovposch's suggestion, and thankfully that went well, so I just went ahead and uploaded the changes. Looks much better IMO. --501ghost (talk) 10:32, 2 April 2022 (UTC)

Granny Flat

I suggest building=granny_flat for Granny Flats / accessory dwelling unit (ADU) for a typically smaller residential dwelling located on the same lot/parcel as a larger primary home. --Aharvey (talk) 05:06, 29 October 2022 (UTC)

North wing, south wing

Mention how to map a building that (everybody uses) the names North Wing and South Wing, for the two parts.

Also the case if when there is actually some empty land between the two wings, that don't touch. Jidanni (talk) 14:41, 5 September 2023 (UTC)

@Jidanni: I'd tag those as any other building sub-division: by using two different building:part=*, each with it's own name=* (or loc_name=*, depending) and other tags as needed. There are many of such differences that can be tagged; but perhaps we could mention two or three most popular ones in that part of the wiki page as examples... --mnalis (talk) 14:56, 15 June 2024 (UTC)

It doesn't work if the wings have building:part=* of their own above. Having a single building:part=* for each is only the simplest case.
—— Kovposch (talk) 08:27, 16 June 2024 (UTC)

Yes, that was assuming relatively simple case. If it already has multiple building parts that should be grouped, that likely calls for use of relations (more complex cases probably already use some relations anyway, either in form of multipolygons and/or Relation:building). But as you note below, this specific example above might be even simpler case (if those are indeed two separate building=* instead, then one would just tag them as such and give each building different name) --mnalis (talk) 01:17, 17 June 2024 (UTC)

Can you describe the 2 cases in more detail?

1. Are they structurally integrated? Built at the same time?
2. What is "some empty land" ? Is that actually having 2 different building=* ?

—— Kovposch (talk) 08:30, 16 June 2024 (UTC)