[OSM-dev] Shared borders of (multi) polygons represented as duplicated ways

[Stefan Baebler]

Hi!

While preparing a dataset for a community import (
https://wiki.openstreetmap.org/wiki/Slovenia_Landcover_Import_-_RABA-KGZ )
we ran into 2 kinds of related problems that originate from Shapefile's
different representation of polygons:

a) duplicated ways: when no tags are present on two overlaping ways, but
ways are members of different relations JOSM reports this as an error. This
is common mostly with nested multipolygon relations, where one relation's
outer way is the other's inner member.

b) Ways on same position: this is similar to previous, but some tags
differ, making the match not exact. JOSM reports this as warning. This is
more common, because it doesn't require that many levels of nesting, A
simple meadow in a multipolygon forest is enough.

The illustraded description is in the issue of ogr2osm (my first choice for
preparing the dataset):
https://github.com/pnorman/ogr2osm/issues/28 (not fixed yet).

Vincent promptly fixed the JOSM's OpenData plugin for importing shapefiles
and adjusted validation logic: https://josm.openstreetmap.de/ticket/10743 ,
so we might go this way (shp -> JOSM instead of ogr2osm -> JOSM or any
other editor), but it will require adjusting the data preparation scripts,
and more importantly, relying on the end users (community importers) for
using the latest (development) builds of JOSM with latest OpenData plugin
to fix the data during the import.

While editing existing OSM data I noticed that this is quite common problem
in OSM database, even if not coming in via imports (manual edits).

My questions are:
Are duplicated ways considered erronous and to be avoided at all costs or
are they tolerable?
Are any tools (osm inspector and similar) detecting these problems?
Are there any plans to fix such topological errors (if considered as such)
in existing data by bots (automated edits)?
Is ogr2osm being used for other imports with similar problems?
Is ogr2osm being actively maintained?

thanks,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20141121/65d7ecd8/attachment.html>