I figured out that this is possible: Changeset: 138848063 | OpenStreetMap
It requires more than a few steps in JOSM, mainly to prevent breaking adjacent relations.
All I still need to be able to do this at a larger scale (not one by one) is the option to reconstruct all selected polygons in @Zverik’s relation toolbox plugin for JOSM. I just created a ticket for that here.
I stumbled upon these changesets and this discussion because I noticed that data had gone missing from our database because of exactly these undiscussed mechanical edits
(as in: not discussed before the edit).
Could you please revert the changesets you have made in the Netherlands and first reach a consensus upon
(a) which conversions from relations to ways are necessary and
(b) how to reach a decent level of quality assurance.
Like @wolfbert mentioned single member MP’s can be justified and you have to understand the reasons why they may have been used before deleting them. See also :
Simplification is nice of course, but when it leads to missing data or conflicting new tagging, the disadvantages very soon outweigh the advantages.
Thanks for restoring the data you deleted.
There is nothing missing, just simplified. If you rely on relation IDs as stable identifiers, you’ve come to the wrong open source project.
What do you consider “necessary”?
Do you want me to explain my workflow?
In response to Chesterton’s fence I present to you the KISS principle.
If you really believe that, then I am wondering if you know what you are doing with these mass-edits.
For example: can you tell me where the tourism=camp_ site “Zeeverkennerscentrum Kagerplassen” has gone after your mass-edit ?
https://www.openstreetmap.org/relation/16090610/history
If you rely on relation IDs as stable identifiers, you’ve come to the wrong open source project.
If find both the tone and the content of that assumption uncalled for.
Why do you assume that I looked only at the relation id?
After your mass-edit Nominatim can’t find this camp site, Overpass can’t find it and when downloading the area to JOSM it is still missing.
What do you consider “necessary”?
A mapper deleting items in mass edits should be asking both himself and his fellow mappers that before deleting items.
Personally I find none of these deletions / conversions necessary, some single member MP’s are there for good reasons, and while other MP’s might be eligible for simplification, I find the gains of such data fiddling very marginal when you consider that we could spend our energy instead on adding missing hiking / cycling routes, access information or … instead.
I for one would rather be outside mapping than spending my time and energy on a discussion such as this, especially when the tone of the person inflicting damage to data is not especially curious or friendly.
Ah yes, the camp site. That’s an unfortunate case. I tried to purge it but somehow it must have been deleted anyway. I have since improved my QA, so that shouldn’t happen anymore. I’ve just put it back: Changeset: 138854420 | OpenStreetMap
This is a good example of why overlapping ways (how I just mapped it) may be more practical than putting one-member relations on top of ways. If you look at the history of the old relation, you will see that I was definitely not the first to accidentally delete it.
Let me know if you have more examples. I’m always happy to receive feedback, even though we may not like each other’s tone in this case.
The gains of this project may be very marginal to you personally, but to beginners who hardly know what a relation is and often won’t know how to handle one, this might make a big difference. It also removes superfluous ways and relations from the database, which makes OSM more efficient to use.
I think this is a great idea honestly. MP’s are definitely some of the more break prone features of OSM, especially for beginners. Clearing them up should simplify things somewhat (This goes doubly for multi outer ones, thats why I suggested them earlier).
I keep hearing about being good reasons for 1 member MP’s, but no specifics (I address the one by wolfbert below), nor can I think of one. Could you give some good examples?
To me this feels like a rather hypothetical scenario. The only way I can see this affecting someone is if someone uploads an MP with 1 member with the intention of adding more members in later changesets but before that happens this mechanical edit occurs. And if that does occur its something that can be solved by merely pressing ctrl + b in JOSM.
Hi, for instance the one mentioned on One feature, one OSM element - OpenStreetMap Wiki :
Examples of bad situations
- A closed way tagged with two feature tags, one of which is usually a linear feature such as barrier=hedge and another which represents an area such as amenity=school. In this case it is ambiguous if the barrier is meant to represent an area or a line, and for all properties it is unclear to which feature they belong. In such a case you may consider making a separate relations
for the barrier=hedge and for the amenity=school, make the closed way
a member of both relations and transfer the tags from the way
In the case of the camp_site that went missing in these mass-edits, the geometry of the outer is both:
The replacement today with a second linear element for the camp_site along the same nodes as the islet (instead of the deleted 1 member MP-relation) does not necessarily make things easier for beginners :
Both in iD and JOSM only one of the linear features can be selected by [JOSM: regular - see posts below] clicking it, the camp_site stays hidden, while all the relations that the geometry is a member of are visible and clickable for editing:
https://www.openstreetmap.org/edit#map=18/52.18762/4.52325
In JOSM you can make the second linear feature for the camp_site visible with a filter if you know the difference in tagging between the two items, but I would not call that improving user friendlyness over the previous situation with relations
JOSM:
You are right. That’s why I’m now looking at a complete exclusion of cases with multiple objects in one place from future edits, and I have already done so in edits after the one that contained the camp site.
You can easily select different overlapping features in JOSM via alt + click or by using the popup menu when middle clicking
Reading about it being difficult or impossible selecting a particular object when several lines or multiple relations are attached to a way. For sure in JOSM it’s peanuts.
This I use extensively to merge broken outline which ID is good at during cutting a closed way. A single cut results most always in 3 ways instead of 2 and have not been able to predict where that autonomous 2nd break is going to happen, the logic has so far escaped me.
/OT
Thx @SekeRob and @Woazboat for pointing out these JOSM-options, good to know.
However this still illustrates that a second linear feature hidden under a first linear feature with exactly the same nodes isn’t necessarily more user / beginner friendly than single member MP’s that are shown directly in the menu in both iD and JOSM
Also wondering : is there a visual clue in JOSM that tells you that there is more than one linear feature under a identical geometry, so you know in which cases it is useful to try alt-click or wheel-click ?
thx
In ID it’s colour and size of the nodes, in JOSM it is the size of the node cubes. The larger yellow cubes on the left indicates at least 2 lines.
No such change was made, what changed was Osmose:
Avoid duplicate warning for 1-member multipolygon (#1352)
So until nov 2021 the “1-member relation” was including “multipolygon - This multipolygon is a simple polygon”, Class id 11704:
So that explains the late 2021 drop.
Finding this out I also at a look at the code and see these relations are excluded:
if tags.get("site") == "geodesic":
return
if tags.get("type") in ("defaults", "route", "route_master", "associatedStreet"):
# 1 member allowed
return
It is not my responsibility (or the responsibility of fellow mappers here) to find all the missing data as a result of your mass-edits.
Twice you mentioned here (even after it was disputed) that no data was deleted and the very first example accidentally stumbled upon proved that to be wrong.
No checks have as of yet been shown that give reason to believe that no other data (apart from this camp_site) is missing because of these mass-edits
Can you show that no data has been lost, that all the data in the relations you deleted is now stored in a new element in our database ?
The feedback was I think best phrased in the link to Chesterton’s fence Wikipedia entry posted earlier , where it’s implications were also translated to open source projects :
If you’re considering nominating something for deletion, or changing a policy, because it doesn’t appear to have any use or purpose, research its history first.
You may find out why it was created, and perhaps understand that it still serves a purpose.
If you believe the issue it addressed is no longer valid, frame your argument for deletion in a way that acknowledges that.
In the message you sent to my inbox sent on 15:48 you wrote that you somehow saw posting that link as very rude / an insult.
I found that surprising, and that was not my intention.
When I was first sent that link, I regarded it as a gift, not an insult.
In this case the reason for posting that link was that nor in the changeset-comment of the mass-edits you already performed, nor in your posts here the possible reasons for wanting to use a one member MP were examined.
In this particular case the feedback could be specified to :
then:
explain at what type of 1 member MP’s you are looking to convert to ways, why they may have been formed and what their advantages / disadvantages are compared to ways
are and what QA-process is proposed to prevent and detect accidental removal of data
start performing mass edits only after finding consensus on the scope and QA
Cheers.
That camp site deletion was a result of a manual foul up which could have been part of any changeset, as demonstrated by the previous person who deleted it. There’s also no mass edit involved; these edits took me hours to make and I did check each example. The actual mass edits are being discussed here, but have not yet been conducted as I don’t have the tools to do it.
As I’ve written previously I am actually restoring a lot of data here that used to be closed ways. I have no intention to delete anything.
If it was a change to Osmose, wouldn’t the reported number drop to half what it was before and then increase gradually from that number?
Some time ago I created such a single member multipolygon. From splitting a large forest MP into smaller ones. I left it a MP, thinking, it will end up MP again in time to come.
Recently, it was converted to an ordinary area, the changelog of the user https://www.openstreetmap.org/user/Med_Pat/history reads like it might prove an inspiration for you endeavor? At least it clearly shows how much effort went into that effort.
It looks like that user fixed these cases one by one. By now I’ve created a better workflow for it that also keeps all other data intact, I’m only missing a “select/edit multiple/all” in the reltoolbox.
A quick look (OSMCha) suggests that yesterday in 5 large changesets you deleted (and to an extent transferred) more than 1700 items in two entire countries (alongside other edits that day).
Whether those edits are mechanical or not, with such numbers and scope a prior discussion is in place before making such mass edits.
Especially when the strategy seems to be to use exotic “solutions” like to nationwide replace one member MPs for multiple features on the same nodes that are consistent with suggested usage in the wiki with multiple linear geometries on exactly the same nodes, which has its own disadvantages.
That camp site deletion was a result of a manual foul up which could have been part of any changeset, as demonstrated by the previous person who deleted it.
What accidental removal do you refer to?
This edit in 2021 (v8) was not a deletion of the tag but an intended transfer from a way to a relation (see changeset comment)
The deletion of the tag from the relation in v9 was no accidental removal either, but a replacement of tourism=campsite with leisure=pitch, that has nothing to do with this being a relation instead of a way
Giving each feature it’s own element (instead of multiple features on one element), such as a separate MP’s for landuse, campsite and islet in v10 prevents conflicting and changing tagging, such as the name between v8 and v9.
I have no intention to delete anything.
That is good to hear, but still I would like to hear how you can show that no other data was lost in these huge changesets you made yesterday.
The odds that I just stumbled upon this one case (was not looking for it) while this would have in fact been the only deleted item in your mass edits from yesterday seem fairly small.
And this is not a burden that you can lay on your fellow mappers while you go along making other edits.
Also I would like to ask you to restore the 1 member MP’s that you have yesterday nationwide removed and have replaced with multiple overlapping identical linear elements.
If you want to deprecate such use for MP’s and replace them whit overlapping linear features, than a proposal would be in place.
“transferred” is a nice word for this. There is already a consensus that simplifying 1-member polygons and small polygons with only unclosed outer ways is beneficial. You can have a long and boring debate about that without me.
As for the scope, I am discussing this now before I do anything on a large scale. The edits I’ve done so far were all within the limits of what I could do without having to consult the holy handbook of “all mechanical edits are bad”.
I must have misinterpreted that. I thought it was an accidental deletion. My bad. 
Since you asked for it, here’s a summary of my workflow so far:
ctrl alt D (download parents)I discovered that the reltoolbox takes other relations and tags on ways into account and doesn’t delete them, which is very helpful.
I invite you to find more cases. I’ve been very thorough to prevent issues like that, but this one slipped through the nets when I was purging data. It was also before I discovered the reltoolbox and 5 iterations before what I’m currently doing.
We don’t have a system for such proposals in place and besides Wiki documentation proposals we work with consensus rather than majority votes. What I’m trying to do here is building a consensus.