Proposal talk:Buildings

Discussion

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)

This overlaps with Relations/Proposed/Site, the name of which I like better. Furhtermore, I proposed highway=entrance on Proposed features/House numbers. -- 3247 23:45, 2 January 2008 (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

Relation: building_part

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.

Remark 2: Another related problem might be that usually roof:apex=yes is ignored since it is part of the building=yes or building:part=yes way.

Example 2.1: An example might be the roofs of the towers of the [Bremer Dom](http://en.wikipedia.org/wiki/Bremen_Cathedral).

If it is neccessary I will provide some graphical examples. --Cracklinrain (talk) 13:01, 27 March 2013 (UTC)

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".

outline and crosshatching of building parts

I am not an expert in cartography, but since the 3D-Community more often uses the top view contour instead of using the outline on the ground, there is serious difference to the the usual OSM interpretation for building=* (see Buildings#Tagging).

My hope is that the type=building relation will solve this dualism and enable renderers to crosshatch building parts which are not on the ground, but overlay roads or other stuff. For some building types like building=roof or building=bridge the rendering should be crosshatched by default for the most renderers. Building parts which have tags like min_height=*>0 or building:min_level=*>=1 and do not cover a building part on the ground (of the same building), should be rendered crosshatched, too.--U715371 (talk) 00:36, 27 November 2014 (UTC)

Example: Media:Ehemaliges_Amerikanisches_Generalkonsulat_-_Bremen.jpg

Default building attributes as tags on building-relation?

What do you think about adding the default 3D-tags of a building to the building-relation instead of adding them to the building way. Since your outline on the ground is not the covered area of the building you may have building parts which are completely not covered by the building-way (from which for example osm2world takes default tags for all building parts).--U715371 (talk) 22:07, 15 December 2014 (UTC)

Obsolete

The availability of high-resolution arial images obsoletes this proposal. Mapping the building outlines has become standard. Applications can easily determine which nodes (entrances, POS, address nodes) belong to a building by checking if the node is inside (or on the edge) of the building erea. The only remaining use of the relation would be the "label" member, which I think is a bad approach anyway. Applications should calculate the label position themselves, based on building shapes, font size, available space etc. --Fkv (talk) 10:23, 5 January 2015 (UTC)

I agree, and had made a note in the proposal page, that the original intent of the proposal might be obsolete, however the relation is now used in 3D modelling. --Polarbear w (talk) 16:30, 5 January 2015 (UTC)