That’s admirable, but people normally do that before editing the data.
It’d be useful to link to what you are referring to. I suspect that you’d be correct to say that when creating something new, creating a tagged way is a better option than creating a single outer multipolygon, but that’s not were talking about here - we’re talking about a large mechanical edit with potentially many edge cases. If the risk of corrupting data was high because edge cases weren’t understood, then the mechanical edit might not make sense.
Confused as this implies you came to search in OSM because ‘things’ were missing ‘from our database’. An external to OSM database? If so, what are the hooks used to pull this missing data? Plural 'things" so you have more than the missing campsite identified.
My understanding is that no mech edit was employed, rather manual work and using the reltoolbox Reconstruct function with which ive found to never lose a bit of tagged information, is simply removing the multipolyon type and changing it to a simple polygon. Tested it today on a fake 1 member MP and adding a boundary relation to it. After reconstruct the boundary was still there and that was a part about which concern was voiced.
I’m doing that before any mechanical edit. Everything thusfar has been manual work, as I’ve explained in previous posts and the summary of my workflow. It’s not like the actual mass edits where I’ve pressed “the nuclear edit button” as DeBigC poetically put it.
Not only when creating something new, but also when editing existing data, with the exception of boundaries, which I’ve omitted from the start. (Boundary relations shouldn’t be multipolygons in the first place, but that’s a story for another time)
Naturally. I’m now doing this task manually to figure out what sort of edge cases can be expected for a larger scale edit. So far I’ve seen a few interesting cases, but those have all been easy to filter out and leave as they are.
That’s what I’ve been doing with all the edge cases I could find actually in OSM. The reltoolbox has proven to be very reliable especially with those, see for example Way: 297169214 | OpenStreetMap which used to be a member way of the two adjacent meadows.
Let me start by saying that I’m all for QA and improving/simplifying things. I understand the example I gave previously is not an issue, I just wanted to mention that this can happen (people here have been upset about less).
Assuming you will focus on simple cases to keep it manageable, what is the expected magnitude of the change? x * 10**y where x and y would be …?
Given the workflow as described, how often do you plan to go through these steps? Unless you automate this in some way, it’s likely mistakes will happen. There are just way too many steps involved.
Furthermore, maybe it’s just me, but I still have no clear picture of which MPs will be affected (I thought I had, but your query and workflow make me wonder). It would be helpful to see a definitive list of selection criteria (which is needed anyway for that query).
In my area most instances landuse areas that share nodes with adjacent areas and should be split into multi way polygons and the duplicate line removed. Often the split lines represent linear features such as hedges and fences anyway.
That totally depends on whether or not I can find a way to simplify (reconstruct) multiple polygons at once. All the QA steps happen before the changes, so also in the tasks I did earlier, the final step after the QA was just “reconstruct - next - reconstruct - next” on a loop.
What I would really like is a model builder like what ArcGIS has. Then I can just string a set of actions together and perform those on new sets of data each time. But I can’t program it myself so I have to do the steps manually. For me this task is no problem at all, it’s just a bit repetitive. I always double or triple check if I’ve done it right, so I only have to do it once. I like that sort of efficiency.
It only looks like a lot of steps because I listed each button press separately. My point was mostly to make it reproducible for others.
The larger a scale I can work at, the fewer times it has to be done. That can be a huge benefit if you consider that there are thousands of these.
I started with 1-member MPs, but somewhere along the way I discovered that it’s just as easy to include MPs with only multiple unclosed outers that have well below 2,000 nodes, so I’m including those too.
After simplifying ~98% of all 1-member multipolygons in the Netherlands to closed ways (largest changeset for reference), I am now proposing to do something similar on a global scale.
one reason to have one member multipolygons is that there is one or more other objects on the same place which is/are also represented with such multipolygons, or by the tags on the way.
Another common situation for these are tags on the way representing a linear object (e.g. barrier=fence/wall).
Sometimes I am creating these because I know they will be needed later (the ways will be split further on or tags will be added to the way).
There are very likely existing some pointless multipolygons which could just as well be represented by a closed way, but I wouldn’t generally assume this is the case.
Nothing stops folks from returning the object to a multipolygon at the time that is does need to be one (hole in geometry). I don’t really understand the argument about keeping these placeholder MP.
For the fence case, you COULD do it as a MP with a single outer way but you can also use the nodes and make an overlapping way. There’s no reason it has to be a MP. Use the simplest tool for the job as it currently needs, which is a way in this case.
not true, a few months ago you replaced all commons links in image tags by links under the wikimedia_commons key. I have been contributing hundreds of such images and only found out about your massive retagging because these images were missing in my map from one day to the other.
Yes, thank you. I’m aware. If you follow the workflow I outlined you’ll see I’m not actually touching these.
It has yet to be seen if I can scale up to a global scope or anything that comes near it.
Ways totalling less than ~1900 nodes. I’ll keep the MPs if they are close to the maximum size of a single way.
The members may have tags. These will be retained thanks to the reltoolbox plugin. You can try that out for yourself. I also thought I would have to exclude these cases (and I have done so in some manual edits that I did so I know it’s possible exclude them), but it turns out that with the reltoolbox plugin I can convert the MPs to closed ways safely without losing the ways and their tags.
In most cases the resulting closed ways will be mapped/tagged on an existing ways (only if those don’t have tags yet). I have already restored the histories of lots of ways that started as ways but were remapped as MPs at some point in their histories.
Thanks for the explanation, I have update my original post accordingly.
I my opinion, the duplication of ways (i.e. for a fence on a part of the MP) will make it difficult to get acceptance from the community. All in all, due to size and complexity, you’ll step on too many toes (keep in mind that even replacing a deprecated tag with an approved one is frowned upon).
Nothing as fancy as that
I was browsing the map in my area and noticed rendering of the discussed islet, which I recently worked on, had changed (showing the name of the islet instead of the campsite). Curious as to the reason, I checked the data in OSM and found a huge changeset in which the 1 member MP for the campsite was removed with no explanation for removing (or changing) this valid 1 member MP and then 4 other huge changesets with similar comments removing 1 member MP’s nationwide in the Netherlands and Latvia . In an attempt to find a discussion for these nationwide edits before they were performed (which there wasn’t for the Netherlands and Latvia) I looked on the forum and ended up here.
If so, what are the hooks used to pull this missing data? Plural 'things" so you have more than the missing campsite identified.
None, except for just looking at the map and checking the data
I don have the data-analysis skills to perform an automatic analysis for other missing items besides the deleted campsite.
Of course one could manually check the edits for missing items, but as stated before that is not my responisibilty here, but the responsibility of the person who conducted these undiscussed mass edits in which data got lost.
As stated above there are reasons to make a single member MP for such cases: multiple -completely- overlapping ways may be a simple tool for computers, but not necessarily for users.
In JOSM overlapping ways need more elaborate clicking schemes and subtle interpretation of rendered data to even discover that there are hidden geometries. In iD the process for accessing the hidden geometries is still unclear for me (I managed it with unglueing nodes and moving them, then the hidden geometry becomes clickable, but that is far from ideal).
There might be other ways, but still the argument "ways are easier to maintain than MP’s " seems far fetched for these cases, since the various relations that a way is a part of is shown directly in both iD and JOSM without further steps that some mappers (such as me after multiple years of mapping) are not aware of.
In the case of the islet the overlapping-identical way approach would now need 3 overlapping ways (islet, camp_site and landuse) and a fourth is someone wanted to tag the present embankment. If people really think that is progress over single-member MP’s and single member MP’s should be replaced with multiple identical ways, than that is something that can be argued in the context of say Editing_Standards_and_Conventions or One feature, one OSM element, but forcing one’s preferences on this, “purging” valid one member MP’s in undiscussed nationwide edits is not the way.
I took a closer look at the camp site in Changeset: 138859320 | OpenStreetMap and the only MP in that place I could replace with ways was, unexpectedly, the river. I left everything else unchanced in that changeset. It’s still possible to move either the polygon of the scout camp or the islet onto the outer way of the grass MP, but the benefit of that seemed so marginal that I didn’t even bother. So I think we have reached an agreement on this case.
I think there is a misunderstanding about the word “purging”. Purging, in JOSM terminology, means to remove data from the active dataset so it can’t be edited, shortcut ctrl shift P. You can try that for yourself. It’s not a mass removal or replacement.
P.s. You remind me of another QA step that I forgot to mention: for 1-member MPs, I purge the ones with multiple parent relations, so cases like the camp site will be completely omitted.
Looking at that change, I thought it might help to add what I’d normally do if editing in an area like this. One thing that I would do (and hasn’t been done here) is ensure that fences, hedges, walls etc. are mapped as separate features from landuse. They might reuse some nodes, they might not (depends on the landuse). What I do find myself doing a lot of the time is unpicking landuse from linear waterways. I’ll want to add a stream and hedges both sides, so I’ll need to unpick the landuse that previously joined in the middle, add the new features, and then complete the landuse (perhaps using the new hedge nodes) either side. Whether an area feature is drawn as a single-member multipolygon or a single way isn’t particularly relevant - most editors support that pretty well.
What I might refactor is where someone’s created landused multipolygons from a selection of other linear features - for example created agricultural landuse from surrounding hedges and waterways. That’s because (in my personal opinion that approach is OSM’s version of write-only code - something so complex that people can’t easily edit it). However those are never single-member multipolygons, so aren’t relevant here.
The reason I interpreted your usage of “purging” here as “to delete the relation from the OSM-database (even if the outer has multiple parent-MP’s)”
instead of “to exclude form the further workflow, so it remains untouched” ,
is that with the campsite -after I pointed out that all the data had vanished from OSM because of the nationwide edits you performed-, you did not restore the relation you deleted, but created a hidden duplicated second way instead. That is exactly the result of purging as in “to delete the relationship from OSM”
And in this case I found that rather annoying, since this was not a single member MP as an unindented residu of other editing, but clearly (per the the notes on the element and history) an intended recent usage of multiple MP’s - in line with wiki documentation- for an outer geometry that describes multiple features, where the prior usage of a way lead to conflicting and changing tagging.
Again, that is not my responsibility, but the responsibility of the mapper who made nationwide edits on more than 1.700 items that are shown to be error-prone.
Everybody makes mistakes when mapping, me as well.
But when somebody shows that mass edits I have made lead to unintended loss of data I would stop my other mapping activities and would focus on checking the error prone edits I have made.
The thought of shifting that burden to my fellow mappers instead of myself would seem unappropriate to me.
