|Status:||Proposed (under way)|
|Definition:||A cluster of single features|
|Rendered as:||name only|
Sometimes, a name or address does not belong to a single object, but to a group of objects. There is currently no way to set attributes to a group of objects. You can set attributes to each single object, but that's not the same as attributes on the group. E.g. there's a group of rock spires named "Krainernadeln". This is plural case. If you add a name=* tag to each of the spires individually, you need singular. But the singular is uncommon. Nobody will ever do a search for "Krainernadel" (singular). Even if someone talks about just one of them, he will not call it "Krainernadel", but refer to it as the upper/eastern/etc. Krainernadel.
None of the currently documented relation types matches that purpose:
- type=collection is aimed for linear features only.
- type=multipolygon means one disjunct area, not a group of individual areas. Another issue is that multipolygons cannot be used for nodes or lines.
- type=multiobject is for a single real-world object that is fragmented in OSM only.
- type=site is meant for institutions. Also, the term "site" would be misleading.
The member roles (label, perimeter, entrance) proposed for that relation type make no sense for generic clusters such as rock spires.Update 2016-04: label and entrance have been removed from proposal, perimeter got redefined. But currently defined for "man-made objects".
Make a relation of type=cluster and add the members to it (no role names needed). Tags describing the cluster in its entirety should go to the relation. Any other tags should go to the individual features.
The members may include any combination of nodes, lines, areas, and multipolygons.
- Schönefelder Seen
- Currently mapped as a place=locality on .
- 2 of the 3 individual lakes (name=Schönefelder See. ) have
- This could become a relation (type=cluster + name=Schönefelder Seen) with those 3 lakes as members, and the name "Schönerfelder See" could be removed from the individual lakes.
- Currently mapped as a relation of type=collection.
- This could be changed to type=cluster.
- Currently mapped as a myriad of natural=cliff lines, e.g. , all of which have name=Fronbachwände.
- The name could be transferred to one type=cluster relation containing the individual cliffs as members.
- Markt 50, Altenmarkt:
- Currently mapped as a building multipolygon .
- This could be changed to type=cluster, and the building=* tag would be transferred to the individual buildings.
- See abstract. Currently mapped as a multipolygon ( with no physical tag.
- This could be changed to type=cluster, with natural=cliff (or =rock or =spire) features as members.
- Canary Islands:
- Currently mapped as a multipolygon with 833 coast segments as members.
- This could be changed to type=cluster, with the place=island/islet objects as members.
- A renderer may span the name across the area (hull) made up by its members, or place the name in the center (or gravity center).
- A renderer may use the relation for generization: If there's not enough space to display all of the individual features, the renderer may display only one signature, centered and with the name taken from the relation.
- Search engines (such as the Nominatim function on openstreetmap.org) are advised to handle cluster relations similar to multipolygon relations.
The undocumented type=group is possibly used for the same purpose.