Proposal talk:Group Relation
Feature tags on group relation for rendering?
Resolved Wouldn't it be necessary for renderers to tag the group relation with the tags that the individual elements share (e.g. natural=water + water=lake) in order that they can display the name of the group with the same style as its elements? (By the way, thanks for writing this proposal! I was just about to do the same.) --SelfishSeahorse (talk) 20:35, 28 October 2018 (UTC)
- I would not think so, rather the opposite: as the group of (e.g.) lakes is a different thing than one lake, it should not get the same tags as an individual lake. We could invent a tag for "a group of lakes", but it is not necessary, it is a feature of the group relation that you do not have to specify the nature of the thing, as it is inherently specified through its members (i.e. optionally you might add more tags to the group, e.g. wikidata or wikipedia tags). This also implies that the tags from the relation are not inherited on the children (members), they should keep their tags and have their properties taged on them, not collectively on the relation. One big field of application for this relation are named groups, the relations allows for tagging a common name for groups of things (which do have this name). --Dieterdreist (talk) 09:33, 31 October 2018 (UTC)
- You are right, that was a bad idea of mine. :-) --SelfishSeahorse (talk) 09:44, 31 October 2018 (UTC)
Tags
Thanks for this proposal. This seems to be a straightforward method to apply a name to groups of lakes, as you mentioned. However, under the Tagging heading you say, "Tags for the group go on the group relation, but no tags are mandatory (at least one additional tag is required, this is usually name or ref). Do not repeat the tags from the members, the group is automatically defined through the tags of its members." However, if one uses a group relation to collect objects like islands, rocks, or similar, there are several tags that must be on the individual objects and not on the relation. Tags such as place=island, natural=coastline, along with name and/or ref, properly belong on the object. Unless I'm not correctly understanding the intent of the proposal. AlaskaDave (talk) 07:12, 1 December 2018 (UTC)
- Maybe I should have been clearer, the members can have all the tags they want, what I wanted to say is that the relation for a group of lakes should not get a tag that says it is a lake. It does not need to get any tag that says what it is, because what it is is defined through the members of the group (their tags). But it should have some identifier, usually a name but could also be a ref, that is for the group (not for the individual members), because there would be no point in creating a relation for a group of some things that are spatially near, but don’t have a name or other identifier as a group. —Dieterdreist (talk) 14:24, 1 December 2018 (UTC)
Existing Proposal with same name
The existing proposal Relations/Proposed/Group_Relation has the same name in a different path. It is not using type=group, but type=multiobject. It is also a grouping, but with a total different tag handling approch, where members inherit tags from the relation. Therefore, the usecases of the new proposal here can't be supported. Tags which are valid for the group, but not valid for individual members, must not be directly inherited to members. The usecase of type=multiobject seems to be reduction of redundant tagging.
I think we should define type=group to support the usecases of both proposals and even combined ones. To do this, we need two tag sets, an inherited one and a non-inherited one. To separate the tag sets, we can use a 'group:' key prefix for the non-inherited ones. With the current state of editors, I would not recommend to really remove the inherited tags from the members, but to use inspectors to detect mismatches of inheritance and member tagging. When editors have learnt to display inherited tags directly on the members, the redundant tags of the members can be dropped.--Slhh (talk) 02:01, 30 December 2018 (UTC)
- The multiobject is a different kind of relation, I cannot see a point in using it, if the only advantage is reducing tag redundancy. Quite the opposite: using tags is the preferred way of stating that something has the same properties as something else, relations would be more expensive and more complicated, so they should not be used here (as a general rule relations should only be used when they are required because the statement cannot be made otherwise), also: relations are not categories.—Dieterdreist (talk) 00:19, 10 January 2019 (UTC)
No nested relations
In order that group relations don't get too complex, i'd advise you that (apart form nodes and ways) only un-nested relations are allowed to be members (or maybe even multipolygons only). Regards --SelfishSeahorse (talk) 08:50, 14 March 2019 (UTC)
Multiple object types: nodes, ways, areas and relations
I believe it will be very difficult to design software to handle a relation that can include other relation types. It will also be difficult to handle nodes, ways and areas in the same relation. I can't think of any examples where a cluster or group of objects have a single name but must to be mapped with different objects. Multipolygon relations already exist for features that include one or more areas, and there are also proposals for relationship types that are made up of linear ways. So if there is a need for a relationship type, it would be one that is made up of nodes. If the group relation type is changed to only include, it would be much easier for database users to handle, and could fulfill a need in some cases. For example, a place=archipelago is usually mapped as a multipolygon relation, with the coastline of each island as a member. But if the islands are mapped as nodes, they could be mapped as this relation type instead (at least temporarily, until a multipolygon relation could be created). --Jeisenbe (talk) 13:46, 16 April 2019 (UTC)
All database objects need a feature tag
Currently the proposal suggests that no tag is required, other than type=group and name=*, with the assumption that database users will be able to determine the feature type from the tags on the relation members. However, it is not so simple to move tags from the members to the relation. In particular, what is to be done if the tags of the members are not the same? Relations without a main feature tag will not be handled by Taginfo or other standard tools, making them difficult to find. I would recommend changing this to say that all group relations need a top-level tag. In some cases, such as place=archipelago, there is an existing tag that is meant to be used for features with multiple parts. In other cases, a new tag will probably be needed, eg natural=lake_group for a group of lakes. I think this relation should work like "type=multipolygon" and require it's own tags. --Jeisenbe (talk) 13:46, 16 April 2019 (UTC)
I understand the desire to have a flexible approach, and that from an editor's point of view (and data inconsistency/redundancy) it simplifies matters to draw the information from the members. However, as Jeisenbe points out it could be horribly complicated to implement for renderers, particularly with cascading relations, and no real hint as to how to do this has been given. I also understand not wanting to apply the singular tag to something which is multiple. Might it be worth making the absence of a feature tag optional, and introducing a key prefix "group". For example, group:natural=cliff, group:natural=water. This way, a hint can be given to the renderer as to how to treat a group relation, without making strong claims about its content (if desired, a data consumer could still choose to evaluate the member tags). If there is no one kind of feature, the editor could choose the one they think best describes the group, saving the renderer a headache. It could be made clear this may only be a near fit and not a precise description. This might make it easier for existing tools to support this relation (which I think is desperately needed!). TrekClimbing (talk) 08:43, 19 August 2022 (UTC)
Relations are not categories
I would like to point out that relations are not categories. To quote: "So, again - please don't do things like "Footways in East Anglia"." I see no place for type=group relations in OSM. --501ghost (talk) 22:08, 4 August 2021 (UTC)