1-member multipolygons

General talk
101

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
102

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.

103

I just hope you do not follow the plan you laid out above. Doing so will cause mayhem.

104

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?

105

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
106

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.

107

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
108

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.

109

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.

110

After 100 comments in a discussion where someone adds insult to injury everyone has the right to leave the discussion.

111

I meant b)

112

its my opinion, too

i would prefer a)

113

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.

114

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
115

I fully agree with you.

Could you share these? Perhaps thereā€™s something I can learn from and copy.

116

The question is: Is there a simple type of one-member multipolygon that can always be replaced with a closed way polygon, without losing any data?
In other words, cases MPā€™s were not intended for. If that can be defined in a way that excludes other types or uses, you can safely build and use an automated replacement workflow or automated edit for it.

Technically this would involve a selection based on type, tags, members, with inclusions and exclusions. The challenge
is to get it right. If it this selection can be done, fine.

The selection should be on the safe side. That is, if cases are excluded that could also do with a simplification, that is no problem; those can be dealt with in another way. Go for the safe definition.

Safe definition

  • An MP,
  • representing one single area
  • and nothing else,
  • with only one closed way member with outer role,
  • where the outer way is not too big
  • and has no tags of its own,
  • and has no other functions or attachments.

I think the only cases to watch are the ones where a mapper expects to add an inner later, and uses one-outer MP as a signal, or as a sevice to future mappers. Since adding an exluded space to an area turning it into an MP is standard practice (and is greatly simplified by the JOSM PolygonCutOut plugin), I think there are better (more sure, more direct) ways to help ones workflow and mapping agenda.
Nevertheless, itā€™s good to let mappers/communities know well in advance what is about to happen so they can handle these cases e.g. with a note about expected changes in the future.

My preference would be to apply this edit country-by-country, preferably after consulting its community about when and how. Maybe the community would rather handle it themselves, that would be even better.

2 Likes
117

This is indeed what Iā€™ve been looking for. For example, some landuse/natural areas (forest, grass etc) look like good candidates, and buildings do not.

118

PolygonCutOut has inclusions and exclusions to determine what is an eligibe area, and it can turn MP areas into polygon areas vice versa. That might be a nice checklist.

The reltoolbox has filters and safeguards in the reconstruct function as well.

119

The natural=coastline exception mentioned above is one I use also. In general, I think you should skip all cases where the relation and member have tags with the same key and a different value, and that will mitigate those cases and possibly other valid uses.

120

In Sweden Iā€™ve found cases of tiny islets with natural=bare_rock or natural=grassland multipolygons on them. In JOSM I can easily remove the closed ones from the data I plan to edit by searching for natural=coastline closed, adding parent relations to the selection and then pressing ctrl shift P. (Example)

More difficult is preserving the coastlines of islets with multiple natural=* multipolygons on them when the coastlines are not part of a place=islet multipolygon. In those cases the natural=* multipolygon is the only parent relation of the coastline, and the relation toolbox incorrectly uses the coastline way to build a natural=grassland/bare_rock closed way, removing the coastline in the process.

As an example, imagine this islet without the place=islet multipolygon. I have found a few of such cases in recent edits.

In the cases I encountered I either added a place=islet multipolygon or remapped the coastlines, but it would be nice if the reltoolbox plugin could detect coastlines and would never overwrite them.