Shared borders represented as duplicated ways.
stefanb opened this issue · 5 comments
When converting .shp to .osm it happens that the result has some shared borders that are represented as duplicated wasy
JOSM validator reports;
- warning: Ways with same position (much too many), when duplicated ways only differ in tags, eg a multipolygon inner border (no tag, just a member of multipolygon relation) overlaps with the same simple polygon (with a simple tag) (example: a meadow within a forest multipolygon) yellow in the picture below:
fixable by reusing the simple tagged way also as a member of multipolygon relation - error: Duplicated ways (regular occurance) when both overlapping ways have the same tags, or no tags if they are both members of different relations. (example: outer/exclave meadow within a forest multipolygon or multi-level-multipolygons) red in the picture below:
fixable by reusing same way (the only one) in both relations - warning: Self-intersecting way (some) when it is drawn as such in .shp, probably unrelated
fixable by reordering nodes within way?
I was using my translation rules:
https://github.com/stefanb/ogr2osm-translations/blob/master/raba-kgz.py
but that is probably irrelevant.
The same problems appears when opening a shapefile directly in JOSM (no ogr2osm involved) due to shapefile structure. Reported an issue 10743
False alarm.
The bug was in JOSM's duplicated ways validation algorithm, fixed in JOSM's issue 10743.
The bug was in JOSM's opendata plugin (used for importing .shp files) and duplicated ways validation algorithm, both fixed in JOSM's issue 10743.
However the JOSM fixes only cover the .shp file import and validation. The problem of duplicated ways remains when one tries to import the .osm file generated by ogr2osm into JOSM. The problem is in generated .osm file, so it should be fixed at the source (ogr2osm), not at the JOSM.
Sample shapefile is 36diss.zip (attached to JOSM's issue 10743).
Discussion on the dev@ mailing list: https://lists.openstreetmap.org/pipermail/dev/2014-November/028157.html (for the record).
@stefanb You can follow the analysis and development of this request in roelderickx#7