I would like to add "grounds" or "property" to this. This would indicate the extent of the property on which a building is situated, of which only a portion is occupied by a building or buildings. For example, a school building may be surrounded by school property on which playgrounds, sporting fields and parking lots may be located. Fence does not adequately describe this because the property may not be fenced or only partially fenced. Andrewpmk 23:38, 11 December 2007 (UTC)
- I agree. Relations/Proposed/Site is better proposal. We already have proposed too many grouping relations: street, collection, site, buildings. The more abstract and universal a relation will be, the better. -- Surly 08:12, 7 July 2010 (UTC)
- I think that this Building-Proposal should be merged with the Site-Proposal or be differentiated from it as in my opinion a site describes what belongs together semantically and physically and a building describes what is related physically (things in a building must not be connected in any way, they just share the same building). So I would at least change the proposal that the "contains" role can point to site-Relations instead of building-Relations as a "building" containing a "building" makes no sense for me, instead a building can also contain a site (for example a shop and an associated entrance) and vice versa. (sorry for my bad english) --Cg909 23:56, 28 September 2010 (BST)
This is a very important information for routing software for visually impaired persons. The entrance should also bring information to which floor / level it leads. --Lulu-Ann 14:20, 25 February 2009 (UTC)
Addresses & entrances
So if I tag the entrance node with the address information as recommended, should its role in the relation be address or entrance? —Mzajac 20:41, 3 February 2011 (UTC)
- Entrance! Lulu-Ann
There are issues with modelling roofes at OSM.
The Problem is: Assume you have a buidling with several builing:part and each of the building:part has its own way tagged with roof:ridge=yes. Then you cannot decide which roof:ridge belongs to which building:part since the building:part overlap or share a way.
My solution is: We introduce a new relation building_part which will be member of the relation type=building. Its members will be ways tagged roof:ridge=yes or roof:apex=yes. Analog to the relation type=building they may have the role ridge and apex.
Remark 1: Since you want to model only a half of a roof you might be forced to draw a line tagged roof:ridge=yes on the highest side of a building=yes or building:part=yes way. You are now also able to applicate my solution and add the way roof:ridge to the building_part relation.
Example 2.1: An example might be the roofs of the towers of the [Bremer Dom](http://en.wikipedia.org/wiki/Bremen_Cathedral).
- Generally, I'm not a friend of nested relations, as they are very complex and will be confusing to many mappers. In this case, I unfortunately cannot see a real alternative if you want to work with explicitly mapped ridge and edge ways or apex nodes. So I reluctantly have to concede that we might need these building part relations. Aside from usability concerns, the suggestion is clean and sensible.
- By the way, I will not be able to quickly support this in OSM2World because of architectural limitations in the software. But that should only be a secondary consideration when designing a tagging scheme. --Tordanik 20:01, 28 March 2013 (UTC)
- it would be nice to have some graphical examples here. --Kendzi (talk) 07:02, 26 June 2013 (UTC)
Rename role "contains" to <void>
I think that by default items in the type=building should mean "contains".