This is a follow-up of @Thiskal’s suggestion to look for MPs that are simple polygons constructed out of several outer ways, like this building part. I apologise if I haven’t made this clear enough.
I’m not am iD user at all, as Josm is much more intuitive to me. But I took a look to see if I could find an answer to the questions below.
In answer to point (a), once I select a way, nodes that are connected to one or more other ways are grey. Unconnected nodes are white.
In answer to point (b), you can select a grey node on the way and press Ctrl+Arrow-Up to find all ways connected to the node and select one of them.
So yes, as a non-iD-expert, I managed to answer the 2 questions, but only with the help of my expert knowledge of I could do this in Josm. Its still not intuitive to me, but that goes for iD in general.
Having said this, I still prefer the single-multipolygon solution in cases like the scout group example. At the moment it is a mix with one way for the scout group without relation and a second way that is used in the grass landuse multipolygon and the islet multipolygon.
What if the water around the islet were mapped as a multipolygon. Which of these way should have the inner role in the water multipolygon? Any one of the 2? Both? Or yet an other copy of the same way?
3 Likes
That water multipolygon did in fact exist until I found an excuse to split it up.
Thanks for looking at this Gertjan !
So tags on several overlapping identical ways can be edited in iD , but it requires more advanced editing skills from the user than on several single-member MP’s, just like in JOSM.
For the avoidance of doubt : do you mean
- a): you prefer the current situation with 1 multipolygon (landuse, grass with patches of forest) and 2 additional identical ways (islet; camp_site) or
- b): you prefer the former situation with 3 single-member multipolygons and only one outer way
Cheers
1 Like
After reading your justification for your edits
I assumed for a while that user-friendliness -especially for beginners- actually was your motivation for these mass edits you already have made without prior consulting. That is why I asked how overlapping ways could easily be edited in iD, a question you refused to respond to
But after seeing your remarkable indifference here to the loss of information your edit has led to and after reading :
I realised you summarized your motivation for editing quite accurately here
If you had any local knowledge, you would have realised this splitting up of the water area is quite nonsensical, it isn’t a canal next to a river in the sense of OSM : none of those two bodies of water is naturally flowing down towards the sea.
Both are -for quite a few centuries now- part of the same isolated boezem-basin below sea level, which only reaches the sea or a river when it is being pumped up by one of four pumping-stations that -when working- connect the boezem up to free flowing water.
The eastern part has been dug out as well, not in the 1930’s like the western part, but somewhere in the 1200’s , when part of a former tidal stream was converted to a canal for carrying excess water northward.
If start-date would be a reason for splitting up water, you can have endless separations in lakes that have expanded over time due to wind-induced erosion.
Please don’t go out and to find excuses to change things, but look at how you can actually improve our common database and make it more fun to contribute here instead of making things worse.
1 Like
The above mentioned editing for satisfying personal fiddling needs does resemble the behavior that has resulted in two earlier user-blocks from the DWG with reasons as
https://www.openstreetmap.org/user_blocks/5430
once again you have committed a mechanical edit without the required discussion: Changeset: 113465893 | OpenStreetMap
You have received many comments about past activities of that kind but apparently they have not led to any change in your behaviour.
From now on you will receive a temporary account block for every un-discussed mechanical edit that attracts criticism from the community.
and
https://www.openstreetmap.org/user_blocks/5565
once again you’ve made a wide-ranging “correction” following the “documentation” in an area where you have no knowledge: Changeset: 115350228 | OpenStreetMap […]
Please don’t make these types of edits. Go out and record some great detailed POI information in an area where you actually have first-hand knowledge, or trace some data from aerial imagery if you must, but this world-wide tag fiddling doesn’t help.
[…] . I am however extending the original request to “tag fiddling by applying what you think is right according to the documentation without knowing anything about the local area or why the tags you are editing were introduced”.
The mass edits you performed last friday were actually a kind of mechanical edit, since you turned yourself into some kind of bot after your “QA-phase” :
In this “QA phase” -that you performed before consulting previous mappers ot the community here- you missed several types of items that you should have excluded.
And since you didn’t look at the individual data you were performing actions on, you did not notice that your QA-phase had failed to exclude something that had to be excluded.
And also did not look at the result of your operation after your “reconstruct”, you went on in your loop to the next item so you did not notice that data had gone missing , like the item previously discussed here.
And because you did not look at the individual data that you were mechanically editing on 1.700 relations in a day, you also did not notice that you introduced additional errors instead of solving existing errors with your edits.
Such as here where you removed the landuse MP, while the previous mapper correctly stated that the right way of action was not to remove the MP, but to add the already present water geometry as an inner to the MP
https://www.openstreetmap.org/changeset/138822498
And here yet another mapper point out other errors you have introduced with your recent edits :
https://www.openstreetmap.org/changeset/139058959
This last edit you have even made after it was shown that your edits led to unintended loss of data and you were requested multiple times here to check your own work since it was shown there was unintended data-loss
You refused this since you claimed:
With this kind of behavior you are breaking more than you are fixing.
Not only data, but more importantly the energy of your fellow mappers.
I would have thought that the clear recent indications that a fellow mapper made that your behavior was detrimental to his well-being would have given some food for thought and self-reflection / empathy
: https://community.openstreetmap.org/t/complexe-waterway-relaties/5269/24
But instead you make cynical references to the frustration your behavior leads to with other mappers, just like you are doing here.
Sad state of affairs …
I am leaving this discussion for now and focussing my energy on more positive matters.
Cheers.
4 Likes
None of these arguments hold, but since Multimodaal has left the discussion I see no reason to explain and defend myself against them again and again.
I just hope you do not follow the plan you laid out above. Doing so will cause mayhem.
So far I haven’t noticed any mayhem. I’ve seen one or two edit conflicts but those were easily resolved and did not end up in my changesets (I triple-checked that).
Have you tried to do any edits like this? What sort of mayhem have you experienced or do you foresee?
For a start, if the instructions to get an estimate of what you are about to edit in the area of my local knowledge contain such blatant errors as purging what is aimed at, I doubt your skills for this. Second, there are valid reasons for what you want to extinguish. Maybe Osmose is fine after all, it will take ages to complete, still there at least something can be marked false positive.
1 Like
Since all of it still requires manual review I’m not too picky about which data I purge before I start editing. The more important part is downloading parent relations. That has nothing to do with my editing skills. I also don’t know what you’re trying to say since I have three years of experience and thousands of changesets with JOSM.
That’s what we’ve been discussing here, and that’s the data I’m trying not to edit. Some constructive feedback like ZeLonewolf’s is helpful in that process.
Osmose is certainly a helpful tool.
I’ve skimmed this thread and have a use case for a single element multi-polygon that I don’t think I’ve seen listed here, so forgive me if I’ve missed it.
I have seen examples of small cays and islets where it is necessary for the outer way to be natural=coastline but that the entirely of the cay is e.g. natural=sand. In this case it is perfectly logical for the natural=sand to be on a single element multi-polygon. The cay could be split into two pieces of coastline arbitrarily, but it’s not really needed when the whole thing’s less than a mile long.
2 Likes
I have seen very similar cases: small, sandy islets, mapped as a natural=coastline closed way with a single-member natural=sand multipolygon. The multipolygon could in theory be made into an overlapping closed way, but since there’s a risk of accidentally replacing the natural=coastline with sand and there’s no real benefit to this change, I’m leaving them alone.
I’ve taken a look at single member MPs in my province (there are rather few) and even replaced some with polygons. These were mostly small natural=* in areas mapped mosaic-style, and leftovers from editing buildings. Not really worth the effort.
There were, however, several cases of buildings with courtyards where the inner polygon had been drawn but not added to the MP. I fixed these, but an automated edit as proposed would have hidden the problem.
Multi-member MPs are more common, but a lot more complex to assess (and I wouldn’t normally touch them).
All in all, I think this may lend itself to a maproulette challenge (with instructions to only simplify the obvious and trivial cases), but after 107 posts I don’t see overwhelming support for a (semi-)automated global change. In my humble opinion, if you go through with this you’re asking for trouble.
After 100 comments in a discussion where someone adds insult to injury everyone has the right to leave the discussion.
I meant b)
its my opinion, too
i would prefer a)
That’s most of what I edit as well. It isn’t particularly exciting for most people, especially since you won’t see the results on any map, but it achieves the benefits that Woazboat managed to explain better than I could.
I agree that a mechanical edit of all cases would miss too many edge cases.
I’m now developing a way to assess them, so you don’t have to. As I said before, the most important bit in that process is downloading all parent relations before any edits. After that it becomes more feasible.
I largely agree with you, except that this probably isn’t suitable for MapRoulette. MR has poor support for relations.
The problem of MPs is not whether it is easier or more complex to work on in a technical sense. There are workarounds and tools for the editors.
The problem is understanding the structure of a multipolygon relation. Many users find that difficult. Multiple stacked simple polygons are easier to understand for many users. This problem is smaller for single-member relations, but huge for more complex MP relations.
Therefore, MP relations should be used as little as possible and only where they are absolutely necessary and cannot be solved in any other way.
I therefore support in principle the idea of dissolving and simplifying MP relations that are not necessary. However, I reject the idea of doing this automatically. The danger is simply too great that mistakes will happen because some special case has not been considered. Despite all the previous discussion.
I also have overpass-turbo queries to find different MP constructs in order to simplify them afterwards. But I do this manually, each case individually and after checking the circumstances.
6 Likes
I fully agree with you.
Could you share these? Perhaps there’s something I can learn from and copy.