Unrelated areas are grouped in multipolygon during shapefile import

[StefanB]

What steps will reproduce the problem?

1. Open a tagged shapefile for import
2. observe the imported data

What is the expected result?

Data structure that is easy to understand and to manually edit/maintain/improve later on by the OSM editors.

What happens instead?

Various areas with same tags are grouped into the same multipolygon relations even if the areas have nothing else in common, just being imported at the same time from the same shapefile with same tags. Geographically unrelated.

Example: two seperate forests in the same shapefile should be imported as separate objects, making it easier to manually edit/maintain/improve later on by the users. If a forest contains a clearing it should be imported as a multipolygon, but not including the other, unrelated forest, which should remain independent.

Providing two relatively simple shapefiles for example / test:
raba82dissJosm.zip:
Two unrelated meadows should be imported as two simple polygons.

raba316dissJosm.zip:
Three unrelated vinyards should be imported as seperate entities - two as simple polygons and the bigger one with holes as a multipolygon.
5 unrelated areas of heath should be imported as 5 simple polygons.
2 unrelated orchards should be imported as 2 simple polygons.

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

Revision: 7995
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: Don-vip
Last Changed Date: 2015-01-31 15:17:59 +0100 (Sat, 31 Jan 2015)
Build-Date: 2015-02-01 02:33:54
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 7995

Identification: JOSM/1.5 (7995 en) Windows 7 64-Bit
Memory Usage: 827 MB / 1799 MB (375 MB allocated, but free)
Java version: 1.8.0_25, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:C:\Program Files\Java\jre1.8.0_25\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Users\stefan\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\56\1ee8cfb8-50c8d4e3, -Djnlpx.remove=false, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.splashport=60000, -Djnlp.application.href=https://josm.openstreetmap.de/download/josm.jnlp, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAC1Eam5scC5hcHBsaWNhdGlvbi5ocmVmPWh0dHBzOi8vam9zbS5vcGVuc3RyZWV0bWFwLmRlL2Rvd25sb2FkL2pvc20uam5scAA=]
Dataset consistency test: No problems found

Plugins:
- SimplifyArea (30962)
- geotools (31000)
- jts (31002)
- kendzi3d (1.0.184)
- kendzi3d-jogl (37)
- log4j (30892)
- opendata (31015)
- todo (29154)
- utilsplugin2 (30892)

[StefanB]

example shapefile

[StefanB]

second example shapefile

[skyper]

See also #11101

[Don-vip]

The plugin is not smart enough to do what you describe. If several geometries are members of a multipolygon, then that's how it is described in the shapefile. If that's not correct, you must raise this problem to the authority providing the shapefile.

[StefanB]

We get multipolygons during shapefile manipulation with ogr2ogr, namely merging (dissolve in GIS lingo) similar polygons after cutting the country into a manageable pieces (based on European reference grid). Source has large polygons cut on a local gauss Krueger grid, which becomes useless after reprojection into wgs84/epsg4326.

If we wouldn't dissolve them we'd get artefacts from both artificial grids into osm data, sometimes resulting into very long (up to 1km) and narrow (down to few cm) triangular polygons.

[Don-vip]

Well, it's either something for your scripts or for ogr2ogr but not for this plugin.

[StefanB]

Indeed, ogr2ogr's -explodecollections parameter fixed it!