Lake Group: site or cluster?
I support the idea, but I believe the name is not chosen well. Would 2 objects be called a "cluster"? Would we no want to be able to tag groups of 2 things? Therefore I have started documenting the type=group relation type in a proposal here: Proposed_features/Group_Relation, feel free to leave your comments. --Dieterdreist (talk) 10:41, 31 October 2018 (UTC)
- Yes, 2 objects would be a cluster. Theoretically, a cluster consisting of only 1 object would also be possible: Think of a cluster of which all but one objects were destroyed, or a cluster of artworks of which only the first one has been erected so far.
- I don't care too much whether the relation type is called "cluster" or "group", but I feel that "cluster" is more descriptive, while the term "group" is too ambiguous. Any set of objects can be regarded as a group, and the relation would certainly be misused for all kinds of classifications. --Fkv (talk) 11:10, 31 October 2018 (UTC)
- To me cluster means things are packed tightly together. For a looser group with lots of space in between, the term seems strange (may be my lack of understanding of the term though). Interesting your hypothesis for a one-member cluster/group, I am not sure I will buy it though: for the case that all but one have been destroyed, I would see the cluster/group as not existing any more. If the things were tagged as disused / abandoned / raised etc. they would still have to be added, so it would be either more than one member, or the group not being there any more. Similarly a cluster of artwork, were only one is physically built, would mean the cluster/group is not there yet. If you would want to model the cluster/group, you would have to add the rest as proposed:features or under construction or something like that, in order to make the cluster (and it would be clear that most of it will yet have to be built).
- Can you give an example for a "group", where the term is ambiguous and the relation should not be created? --Dieterdreist (talk) 11:41, 31 October 2018 (UTC)
- Galaxy clusters have millions of light years in between. We may disagree on the minimum number of relation members, but that's just a small detail that doesn't affect the overall purpose and usage of the relation. Nobody forces you to create one-member clusters. Feel free to use them or not use them, depending on your needs and preferences.
- No, I cannot give an example, because I am not going to analyze all 78 existing instances, and they do not really matter as they were created back when no documentation existed. What worries me is the thousands of relations that will pop up when the relation gets approved, and we can only speculate about how they will look like. My prognosis is that type=group is more likely to be misused than type=cluster, but you know, it's impossible to prove a prognosis right in advance. --Fkv (talk) 12:22, 31 October 2018 (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 have to be mapped with different objects. Sure, many things can be mapped as a node or an area, but in a relationship that defines a single named feature it would be best to keep to one type of object. 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 cluster relation is only nodes, it would be much easier for database users to handle. --Jeisenbe (talk) 13:44, 16 April 2019 (UTC)
- I'll reply to each of your points individually:
- Difficult software design: No. Recursion is a concept that every IT student learns in the first semester. The relation types may differ, but the tasks are the same. That's most obvious when we view it in OOD: When every OSM object has a setName() method, we can propagate the cluster name down to the members by simply calling each member's setName() method, no matter whether that member is a node, way, relation, or what the relation type is. Or if we want to render the name only once, we can calculate the label position by collecting the locations of the indivudual members by calling their getBBOX() method.
- Difficult to handle nodes, ways and areas in the same relation: No. Even the relation view on the OSM website can already do this. Example: www.openstreetmap.org/relation/7193249
- Can't think of any examples where a cluster or group of objects have a single name but have to be mapped with different objects: Didn't you check the examples on the proposal page? See also the example above as well as other examples in Overpass Turbo
- Multipolygon relations already exist for features that include one or more areas: Yes, but a MP is one single feature with a special areal extent, while a cluster is a group of individual features. E.g. a group of houses is not one house on a disjunct area. It's multiple houses, each of which has its own building attributes (building=* tag value, levels, roof), start_date etc. A group of lakes is not one lake, it's multiple lakes, with different ele=* attributes etc., and each of the lakes can have a name on its own. See also the above example of Palagruža islands again: One of the islands is called Vela Palagruža, another is called Mala Palagruža, etc. If you were to replace the indivudual islands with one multipolygon, you would need to drop all of these individual names. Adding a multipolygon without deleting the individual islands is not much better, because then you have more islands in the database than really exist.
- and there are also proposals for relationship types that are made up of linear ways: I do like Proposed features/Multilinestring and I have been using it myself, but you can't use this instead of type=cluster. Just as a multipolygon, a multilinestring uses its members only to define the extent. You can't use a multilinestring to group 2 cliffs with different height attributes.
- One more note on the difficulties to handle cluster relations in application software: There are many other relations and tagging schemas that are difficult to handle, such as public transport relations, lane mapping, opening hours syntax, etc. The first step is always to define a tagging standard, then you start to think about implementation. Implementation is not our job as mappers anyway. When someone finds it worth implementing, they will do it. Otherwise they don't, regardless of difficulty. What we can tell for sure is that they'll never start implementing when there is no tagging standard.
- --Fkv (talk) 19:36, 17 April 2019 (UTC)
- I understand your reasoning, Jeisenbe (simpler to query only nodes), but in practical terms it would mean people would have to downgrade objects that are already represented as areas, lines or relations, and map them as nodes instead, when they should be added to a cluster relation. This would seem quite bad. It also implies that things in a cluster relation and mapped as a node would probably not be upgraded to more detailed geometry like areas. Both are negative effects. Reducing an area or a line to a point is usually not difficult. -—Dieterdreist (talk) 22:28, 28 April 2019 (UTC)