|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.
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.
|type||multipart||Tells applications that members of this relation are actually a single entity and should be processed as such.|
|Way or Node||Role||Recurrence?||Explanation|
|any||One or more||A member.|
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.
There are several fallback ways to render this relation, and using any of them will get a 'decent' result.
- Render as a single polygon with tags from relation
- 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.
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>
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)?
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).