Warn about supermassive avoidable multipolygons (landuse=farmland for start)

[mkoniecz]

What steps will reproduce the problem?

1. Download ​https://www.openstreetmap.org/relation/10953749 (multipolygon landuse=farmland constructed from 933 ways, around 68 000 nodes in total).
2. Run validator

What is the expected result?

Validator complains about this supermassive multipolygon that has no reason to exist.

What happens instead?

Nothing.

Please provide any additional information below. Attach a screenshot if possible.

Warning should not be emitted for named landuses, where supermassive multipolygons would be justifiable.

I already notified ​https://wiki.openstreetmap.org/wiki/Unite_Maps_Initiative/UN_Mappers about issues with their mapping (see ​https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny/deimport_landuse_in_central_Africa,_mostly_East_Congo ) and I got reply via email.

They claim that it is not import, but manual tracing from imagery.

Warning from JOSM would help in such case to provide early feedback that they are making a mistake.

BTW, is there any sane way to split that monster into smaller parts? My typical methods "remove some ways multipolygon, add it to another new one" or "delete multipolygon, construct new areas from its ways" would be horrific here.

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2021-01-21 23:33:21 +0100 (Thu, 21 Jan 2021)
Revision:17474
Build-Date:2021-01-22 02:30:49
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17474 en) Linux Ubuntu 20.04.2 LTS
Memory Usage: 660 MB / 3974 MB (405 MB allocated, but free)
Java version: 11.0.9.1+1-Ubuntu-0ubuntu1.20.04, Ubuntu, OpenJDK 64-Bit Server VM
Look and Feel: javax.swing.plaf.metal.MetalLookAndFeel
Screen: :0.0 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 1920×1080
Best cursor sizes: 16×16→16×16, 32×32→32×32
Desktop environment: LXQt
Java package: openjdk-11-jre:amd64-11.0.9.1+1-0ubuntu1~20.04
Java ATK Wrapper package: libatk-wrapper-java:all-0.37.1-1
Environment variable LANG: en_US.UTF-8
libcommons-logging-java: libcommons-logging-java:all-1.2-2
fonts-noto: fonts-noto:-
Dataset consistency test: No problems found

Plugins:
+ buildings_tools (35669)
+ reverter (35688)
+ todo (30306)

Validator rules:
+ https://josm.openstreetmap.de/josmfile?page=Rules/OSMLint&zip=1
+ ${HOME}/Documents/install_moje/OSM software/manual editing and discussions/josm/resources/data/validator/deprecated.mapcss

[pangoSE]

Support. This is a huge problem. I work on a small 32-bit laptop Thinkpad X61s and I would probably not be able to edit this relation.
I would very much favor smaller relations with a maximum of 500-1000 nodes. The smaller the better in general. This smells like an inexperienced mapper and should be discouraged if not outright impossible to upload using JOSM.

[mkoniecz]

Note that in cases of reservoir or lake of complicated shape that is named as one entity such object may be necessary, so blanket block would be too much.

[pangoSE]

This further begs for an efficient tool to split large multipolygons. They are beasts and harm the whole project as I see it. I can't find the old issue when we discussed how to effectively split large MPs with inners. Anyone who can link to it?

[pangoSE]

Replying to mkoniecz:

Note that in cases of reservoir or lake of complicated shape that is named as one entity such object may be necessary, so blanket block would be too much.

I disagree. That could be split in multiple subpolygons that share sides and have a parent multipolygon with the name on it.
Its easy to do for an experienced mapper with JOSM and reltoolbox. I suspect the problem in this case is lack of OSM training and experience for the the uploader.
My hypothesis: They just dump it in, look on the map on OSM.org and celebrate. That's not for the best of the community and long-term maintenance will most probably suffer if this is not split up. (I have not looked reviewed the quality of the data in this case, I leave that to others)

[pangoSE]

This is related to user testing see ​https://www.linkedin.com/posts/akaushik_buildforusers-ugcPost-6759528618369646592-aoPZ. These people use OSM in a way that was not intended. The ability to create enormous MPs must be blocket in JOSM IMO, it's the most effective way to avoid damage to the project.
This will of course make it even harder to improve OSM because noone can then upload these anymore. The only way forward as I see is to do an inventory on the large MP's we have. Work on them in order from largest -> smallest in a coordinated effort and then turn of the possiblity of adding new ones.

Before we can start we need good tooling to make the work effective. Bot is not an option I guess.

I have not seen a single large MP with a lot of members that could not be split up.

[pangoSE]

Replying to pangoSE:

This further begs for an efficient tool to split large multipolygons. They are beasts and harm the whole project as I see it. I can't find the old issue when we discussed how to effectively split large MPs with inners. Anyone who can link to it?

Its here https://josm.openstreetmap.de/ticket/18295 and closed. I have not tried yet so verify that we actually got a decent way of splitting beasts.

[mkoniecz]

That could be split in multiple subpolygons that share sides and have a parent multipolygon with the name on it.

There is not such a thing as a "parent multipolygon" or multipolygon containing multipolygons.

Introducing that is out of scope of JOSM validator that works with current tagging standards.

[GerdP]

Reg. support to split: I have done some multipolygon (MP) splitting and I never found a case where I was able to simply reuse existing ways. My typical workflow for a very simple case where there is only one outer way:

1. correct positions of highways and waterways (or add missing) inside the MP
2. use the parallel ways mode to draw split lines (the distance depends on existence of ditches or tree rows, so there is no simple way to do that as well.
3. Connect the split ways with the existing Use Alt+X to split or Shift+Ctrl+G to replace geometries
4. Decide what to do with the remaining areas between the split lines (remove or split further to add landuse=grass

Reg. warning: What would be the benefit? A mapper who creates such a monster is probably happy with it, a huge MP is easier to produce than many small areas.

[mkoniecz]

Reg. warning: What would be the benefit?

Someone editing with JOSM would get explicit warning and feedback that their edit is not OK before upload, and would have chance to fix it immediately.

Rather than getting irritated messages months later.

A mapper who creates such a monster is probably happy with it

The goal is to make them unhappy about it or at least aware that other are going to be unhappy about something like that.