<div dir="ltr"><div>Hi!</div><div><br></div><div>While preparing a dataset for a community import (<a href="https://wiki.openstreetmap.org/wiki/Slovenia_Landcover_Import_-_RABA-KGZ">https://wiki.openstreetmap.org/wiki/Slovenia_Landcover_Import_-_RABA-KGZ</a> ) we ran into 2 kinds of related problems that originate from Shapefile's different representation of polygons:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>The illustraded description is in the issue of ogr2osm (my first choice for preparing the dataset):</div><a href="https://github.com/pnorman/ogr2osm/issues/28">https://github.com/pnorman/ogr2osm/issues/28</a> (not fixed yet).<br><div><br></div><div><span style="color:rgb(0,0,0);font-family:sans-serif;font-size:13px;line-height:19.2000007629395px">Vincent promptly fixed the JOSM's OpenData plugin for importing shapefiles and adjusted validation logic: </span><font color="#000000" face="sans-serif"><span style="line-height:19.2000007629395px"><a href="https://josm.openstreetmap.de/ticket/10743">https://josm.openstreetmap.de/ticket/10743</a> , 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.</span></font></div><div><font color="#000000" face="sans-serif"><span style="line-height:19.2000007629395px"><br></span></font></div><div>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).<br></div><div><br></div><div>My questions are:</div><div>Are duplicated ways considered erronous and to be avoided at all costs or are they tolerable?</div><div>Are any tools (osm inspector and similar) detecting these problems?</div><div>Are there any plans to fix such topological errors (if considered as such) in existing data by bots (automated edits)?</div><div>Is ogr2osm being used for other imports with similar problems? </div><div>Is ogr2osm being actively maintained?</div><div><br></div><div>thanks,</div><div>Stefan</div><div><br></div></div>