Proposal:Multipart

The 3D Development team are currently working on unifying 3D related tags.
For first results see Simple 3D Buildings.

This relation is intended to join multiple parts of a single object into a single entity, joining them logically and avoiding tag duplication.

Rationale

There's currently no way to map a building which consists of multiple parts with different heights (although there could be many other uses for this tag).

• It can't be mapped with as two buildings, as this will duplicate on map and in address search
• It can't be mapped with multipolygon, as multipolygon doesn't allow touching outer parts and it doesn't define way to process tags on subparts

Thus we need a new relation to group building parts into a single entity and avoid duplication. This relation is not limited with buildings.

Tags

Key	Value	Explanation
type	multipart	Tells applications that members of this relation are actually a single entity and should be processed as such.

Members

Way or Node	Role	Recurrence?	Explanation
	any	One or more	A member.

Usage

Usage of this relation is pretty similar to one of a multipolygon with multiple outer members, however

• This relation has no restrictions on member's geometry - members may or touch and intersect (which may or may not mean physical intersection, as these may be on different levels physically).
• This relation allows tags on members which specify details for specific parts (overriding tags on relation).
• This relation allows any object as a member. May be used for streets, waterways, forests, landuses any many more objects.

Rendering

There are several fallback ways to render this relation, and using any of them will get a 'decent' result.

1. Render as a single polygon with tags from relation
2. Render as multiple polygons, each with tags from relation (this is what mapnik does for multipolygon)

Correct render should take both relation and its members into account, e.g. render multiple polygons, but only a single label with address or name (this is what osmarender does for multipolygon). By default tags on members override tags on relation (but this is open for discussion).

Mapnik rendering of a multipolygon	Osmarender rendering of a multipolygon

As it may be seen, support for this relation may be added to both major renders by rendering relation=multipart in exact same way as multipolygon, with possibility for improvement for mapnik.

Example

Possible rendering

A school building with 3 parts of different heights shown above:

<relation id="1">
  <tag k="type" v="multipart" />
  <tag k="building" v="yes" />
  <tag k="name" v="School №1095" />
  <tag k="addr:street" v="Street name" />
  <tag k="addr:housenumber" v="32" />
  <member type="way" id="1" role="" />
  <member type="way" id="2" role="" />
  <member type="way" id="3" role="" />
</relation>
<!-- Square part -->
<way id=1>
  <nd ...>
  <tag k="building:levels" v="3" />
</way>
<!-- Thin part -->
<way id=2>
  <nd ...>
  <tag k="building:levels" v="1" />
</way>
<!-- Long part -->
<way id=3>
  <nd ...>
  <tag k="building:levels" v="4" />
</way>

Discussion

The open questions are:

• To what objects is this applicable apart from buildings?
• Are there cases where rule overriding will be ambiguous (e.g. if relation and a part both have addr:housenumber, does a point in member belong to two addresses, or only one (which one)?

Finale

It turned out that this proposal almost perfectly duplicates Relations/Proposed/Collected_Ways_Simple, so I vote for the latter to be used (for buildings as well).