On OSM we have a tagging scheme for monumental trees, being natural=tree + denotation=natural_monument.
Sometimes trees are not monumental on their own, but only as a group. An example are these 207 trees in Poland: OpenStreetMap
In this case, how to map them?
In Italy for example there are two trees that are a “monumental couple”, so I tagged them this way: link
Using a type=site relation + denotation=natural_monument. The single trees have denotation=urban because they are not monumental on their own. Do you think is a good idea or have better ideas?
Using a type=site relation + denotation=natural_monument. The single trees have denotation=urban because they are not monumental on their own. Do you think is a good idea or have better ideas?
I think it is fine, although now you lack a feature tag for the site relation. You could also use a type=group relation which doesn’t suffer from this problem but is not used a lot currently
I was thinking to add natural=tree_group in the type=site relation, but I don’t know if that could be redundant.
At the same time people sometimes adds natural=tree nodes to natural=tree_row ways to add details such as height, circumference ecc. so I’m not sure.
OT
I “necroposted” some old topics trying to crowd the “tree” tag in the forum. I didn’t know that they would have pop-up in the recent topics list. Sorry for that.
=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.
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
for islands you should add archipelago if there is a name, regardless of the representation as a node, or relation of type site, multipolygon or group. If there isn’t a name, you should not use group or cluster (unless there is a different attribute that applies to the thing together and not to the individual parts). If “the grouping isn’t special enough” i.e. there are some islands close to each other but they don’t have an identity together, then you shouldn’t use either of group or cluster. This is already in the data and a relation would not add anything besides overhead.
I intentionally didn’t say “unnamed”. Mainly it’s about the definition and applicability of archipelago, then whether there should be =archipelago inside =archipelago as a result.
Random example for the small end: Wasp Islands - Wikipedia in the San Juan Islands - Wikipedia is currently an =island point at the middle of the =islet around, maybe because of GNIS). It is already not recommended in Tag:place=island - OpenStreetMap Wiki , but the suggested =archipelago would overlap with San Juan Islands itself.
On the large end in Japan, Chichijima island is in the Chichijima Rettou “island row”, of the Ogasawara Guntou “island group”, of the Ogasawara Shotou “islands”, of the Nanpo Shotou “islands” (together with Izu “islands”). The level of =archipelago needs to be decided, before the collective below and above can be organized into =cluster / =group of =island / =islet and =archipelago consistently.
If it’s only a pair of large and small =island / =lslet , it may be clear this should not be an =archipelago . When there are more, it’s ambivalent.
For this topic, the clearest distinction seems to be if it can be considered as an appropriate feature (that’s not some random =*_group ) , it should use =mulltipolygon , or =site. If not, =cluster / =group . Maybe monumental trees can be some sort of historic= too?
A further complication I forgot to consider here is =tree_group seems to be used for both an unique feature of an identifiable group of trees, and as a implied land-cover instead of =wood (perhaps some don’t want to use =wood for a few trees) DE:Proposed features/natural=tree group - OpenStreetMap Wiki
The problem with this is land-cover is divisible, while the unique feature is not. At the large end, this is solved by separating boundary=forest and nautral=wood for woodland. Here, they are mixed. In concept, I personally see both a few trees and a patch of trees as landcover=trees .
The land-cover meaning of =tree_group is thus unsuitable for =site . It only makes sense on areas. Of course, the land-cover area may still be a representative perimeter of the =site with the individual =tree points.
IMHO these are just errors and should likely be tagged as archipelagos but definitely not as “island”.
I don’t see how this would be a problem, can you explain?
I would use a multipolygon if all parts are mapped as polygons (because this is the best understood widest used representation), if it has to be mapped as site (because some islands or islets are only nodes) the tagging (and applicability) for site and group would be the same (i.e. the generic site would work just as well as the group because there is an established tag for the grouped feature which should be added) (no idea about cluster but likely the same). IMHO, “group” relations only should be used when the group is considered an “appropriate feature” as a group.