Proposal:Cluster (2015)

Tag:type=cluster
Proposal status:	Proposed (under way)
Proposed by:	fkv
Tagging:	type=cluster Data item
Applies to:
Definition:	A cluster of single features
Statistics:
Rendered as:	name only
Draft started:	2015-01-05
RFC start:	2015-01-14
Vote start:	tbd
Vote end:	tbd

Abstract

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:

1. 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.
2. The term "site" could be misleading.
3. 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.
4. 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.

A type=cluster relation was first suggested by Erik Lundin on Talk:Relations/Proposed/Site.

Mapping

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.

Examples

• Schönefelder Seen

Currently mapped as a place=locality on 416032511 416032511.

2 of the 3 individual lakes (5105726 5105726 5105729 5105729 23961229 23961229) have name=Schönefelder See.

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.

• Schwedenhöhlen

Currently mapped as a relation 1330994 1330994 of type=collection.

This could be changed to type=cluster.

• Fronbachwände

Currently mapped as a myriad of natural=cliff lines, e.g. 308174689 308174689 171828311 171828311, 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 1810994 1810994.

This could be changed to type=cluster, and the building=* tag would be transferred to the individual buildings.

• Krainernadeln

See abstract. Currently mapped as a multipolygon (1229393 1229393 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 5392189 5392189 with 833 coast segments as members.

This could be changed to type=cluster, with the place=island/islet objects as members.

Rendering

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

Alternatives

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

type=cluster:

type=group:

Voting

Not yet.