=site does need a feature. As =tree_group is common enough, it’s fine to be added for now. I opposite to the poor scalability of creating a =*_group for everything, but that may have other solutions eg if site= is used for this.
The =cluster I prefer, and =group , are mainly for collective identities by naming. If they form one greater thing together, =site might be better, which should have a feature specified. This is the case if it is thought as a monument.
Eg a few, or a butch of islands may use =cluster / =group , when the grouping isn’t special enough. If they are significant and recognized as related, it can be a =archipelago as =site , or =multipolygon (leads to extremely many members) now.
For heritage= , =site is used, not =cluster / =group without a feature or other attributes. (That’s for things specified to be protected. =multipolygon can still be used for an area extent.)
It may be possible for different features to mix in a =cluster / =group , eg different vegetations, geological formation (maybe =rock and =stone ?), a group of crossings (=bridge and =tunnels). =island and =islet inside an =archipelago . Then they rely on the naming, members, and semantics for humans to interpret the meaning. =site make it clear with the explicit feature type.
Recently I looked at Disambiguation between statue and sculptural group again. Don’t have more good answers now than then.
1 Like