Proposal talk:Cluster (2015)

Lake Group: site or cluster?

Talk on site relation proposal page.--Jojo4u (talk) 13:00, 17 April 2016 (UTC)

Relation name

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:

1. 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.
2. 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
3. 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
4. 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.
5. 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)

I have no idea what you are talking about. Please be more specific and try to give an example. --Fkv (talk) 22:56, 28 April 2019 (UTC)

Sorry for putting the quoting level wrong, I was replying to Jeisenbe. --Dieterdreist (talk) 08:54, 29 April 2019 (UTC)

Voting plans

Are there any plan to proceed to repeated RFC and a vote? Or is it an abandoned proposal? (note that tag may be actively used and proposal may be abandoned, I did it with some of my proposals) Mateusz Konieczny (talk) 20:33, 23 July 2020 (UTC)

You could have asked the question before changing the status. Glad you finally chose the right path. No, this proposal is obviously not abandoned. There is no alternative to this relation, only the relation name is arbitrary. I use this relation quite a lot and I keep suggesting it in various discussions.

I really would like to start voting on it, but that's no more the preferred way to get a proposal approved. In my experience, proposals are usually voted down by people who didn't even read them and/or who aren't competent in the respective subject. I've seen arguments like "I oppose this proposal because these things don't exist where I live." You'll realize how obsolete voting is when you look at how the voting rules themselves were changed too without voting. E.g. first the minimum number of positive votes was 50%+1, then someone changed it randomly to 75% without even asking.

The preferred way to get a proposal approved is now to write an editor template, then wait for the usage numbers to rise, and then set the proposal status to "inuse" or "defacto". Unfortunately, I don't know how to write an editor template, so I need to wait for someone else to do it.

Another option is to silently set the status to approved or de-facto and hope that noone will notice. That's how Geozeisig and Dieterdreist usually do it.

--Fkv (talk) 21:57, 23 July 2020 (UTC)

@Fkv: I'm dismayed by https://www.openstreetmap.org/user/Fred73000 doing mass re-tagging of type=cluster worldwide. 105 changesets from https://www.openstreetmap.org/changeset/131189310 to https://www.openstreetmap.org/changeset /131207749 bringing it down from 238 to 69 instances. --- Kovposch (talk) 03:28, 13 January 2023 (UTC)

@Kovposch: That's a catastrophy. Can you please revert those changesets quickly or tell the Data working group to do it? I am currently seriously ill and thus unable to do that myself. --Fkv (talk) 05:21, 13 January 2023 (UTC)

Sorry to hear that. Get well soon. I already informed DWG in case, and will revert them if no further developments from them. --- Kovposch (talk) 07:08, 13 January 2023 (UTC)

So what did the DWG say? You see that the user is not cooperative and not willing to revert his changes himself. Someone needs to do the reverts. --Fkv (talk) 17:56, 14 January 2023 (UTC)

No reply yet. They only acted yesterday on a low-priority ticket I submitted last month. I will need to learn how to use the Perl revert script, or I have to go through 110 changesets in Revert UI in batches of 20 up next. I already reverted those in my country I'm working on.
If you feel well, we can bring this up to publicized discussion. I prefer the Discourse forum.
--- Kovposch (talk) 02:08, 15 January 2023 (UTC)

Notice given https://www.openstreetmap.org/user_blocks/6768 --- Kovposch (talk) 10:00, 15 January 2023 (UTC)

Reverted:

131245385,131243106,131242681,131242606,131242111,131241985,131241848,131207749,131207616,131207493,131207390,131207337,131207265,131207099,131206816,131206493,131203359,131203285,131203140,131203081,131199051,131198959,131198903,131198879,131198847,131198821,131198746,131198671,131198566,131198466,131198429,131198389,131198351,131198319,131198298,131198271,131198142,131196745,131196386,131196362,131196333,131196283,131196262,131196243,131196150,131196105,131196042,131196008,131195811,131195780,131195650,131195601,131195475,131195446,131195402,131195123,131195057,131194993,131194941,131194872,131194759,131194713,131194658,131194597,131194464,131194410,131194340,131194246,131194158,131194410,131194340,131194246,131194158,131194119,131194096,131194054,131193981,131193940,131193896,131193822,131193797,131193383,131193274,131193177,131192779,131192693,131192613,131192580,131192548,131192476,131192422,131192356,131192309,131192277,131192126,131192040,131191985,131191841,131191793,131191655,131189467,131189425,131189347

With unaffected changesets filtered out. I will review each of them later.
--- Kovposch (talk) 14:27, 17 January 2023 (UTC)

merge with group type

Sorry to come here so lately. This proposal is the same as the proposal group so I proposed to merge them. Cluster had the status abandoned (for almost 2 years) so I have yesterday change almost all cluster type into something else (group or other). Fred73000 (talk) 20:37, 13 January 2023 (UTC)

Have you reverted your changes already? If not, please do so quickly, or ask the DWG to do so.

My proposal is NOT abandoned, even though its status is subject to regular vandalism.

Even if my proposal were abandoned, or did not exist at all, it would be fine to use the type=cluster relation type. See Any tags you like. You have no right to change tags set by other mappers.

Even if there were good reasons for a mass edit, you would need to follow the Automated Edits code of conduct.

An RFC for my proposal has already been sent, whereas the type=group proposal is still a draft. That means that my proposal is further advanced. Apart from that, my proposal came first. I have no idea why the author of the other proposal wrote a concurrent proposal instead of supporting mine. So if you consider a mass edit, it should be to change all type=group to type=cluster, not the other way round.

type=site is fundamentally different to type=cluster. You should know that because my propsal explains it in detail.

--Fkv (talk) 21:12, 13 January 2023 (UTC)

And why the hell are you continuing to do that after our comments and your question here? From https://www.openstreetmap.org/changeset/131241848 to https://www.openstreetmap.org/changeset/131245385 8 changesets.
Aside from the difference with type=site, as I have commented, type=site need to have a top-level feature tag of site=* or ordinary ones eg power=plant. If you can't find one (usually because they are mixed), it's not a site=*, but a type=cluster. In any case, you shouldn't change them to a type=site without even doing it properly. --- Kovposch (talk) 12:56, 14 January 2023 (UTC)

According to rules of the wiki Proposal_process#Proposal_status_overview_list, the status is 'abandoned" when "the proposal has a long time of inactivity (at least 3 months) on the wiki pages (including all languages and discussion pages) and is also not added to the OSM database". Inactivity for the main page was 1 year and 10 months. Inactivity for the talk page was 2 years and 6 months. When someone changes a wiki page, we receive an email : you received an email almost 2 years ago (telling you that the new status is "abandoned") and you did not react ! And now it is my fault ? No : when I looked at this main page 2 days ago, this tag was abandoned by you for almost 2 years because of your inactivity. Don't act as if it is my problem, it is yours. Don't blame others for the consequences of your inactivity.
According to this query https://overpass-turbo.eu/s/1q99 (osm database on 1/1/2023), only 240 elements had this tag (proposed 8 years ago), at least 35% were from fkv (probably more if someone else modified the initial version). Some of these elements were not cluster, for example this one https://www.openstreetmap.org/relation/6181032/history (like creating a building with the name "house").
The same query with the date 1/1/2015 (before the creation of your proposal) shows that osmdata had 7 elements.
The same querie for group (proposed 4 years ago) shows 274 elements (on 1/1/2023).
The same queries for group and cluster on 1/1/2018 (3 years after the proposal page for cluster and 10 months BEFORE the proposal page for group) show 80 cluster and 70 group : it is propably the reason of the proposal for group.
Conclusion : for 2 years the status "abandoned" was a good status (because the proposal was abandoned by you). Even if the status "obsoleted" was also suitable. Please assume the consequences of your inactivity and change the last cluster elements in the database in a more appropriate tag. Best regards. Fred73000 (talk) 17:31, 14 January 2023 (UTC)

Blah blah blah. You are trying to divert the discussion from your illegal mass edits. Revert your edits, and then we can discuss the proposal status or whatever. --Fkv (talk) 18:00, 14 January 2023 (UTC)

Big talks with "Don't act as if it is my problem, it is yours. Don't blame others for the consequences of your inactivity." when you are the one doing the destruction with no regards to how either concept is used. --- Kovposch (talk) 02:09, 15 January 2023 (UTC)