|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.
- Site relations are meant for sites, i.e. define a specific site, usually consisting of man made objects, while type=cluster can be used for both natural and man_made objects.
- The term "site" could be misleading.
- Site relations are thought to add additional semantics through member roles (e.g. perimeter) which make typically no sense for clusters such as rock spires.
- Cluster relations are basically the sum of the individual objects, with only attributes (such as name, address or tourism=attraction) on the relation; whereas site relations are distinctive features on their own, and must have main tags like amenity=university on the relation to define the thing.
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 map symbol, 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 formerly undocumented (until 77 uses in 10/2018) type=group is possibly used for the same purpose. This is the proposal Proposed_features/Group_Relation