[OSM-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

Frederik Ramm frederik at remote.org
Wed Jul 11 09:58:18 BST 2012


On 07/11/2012 09:24 AM, Even Rouault wrote:
> The main reason is I didn't make an extensive search of what other libs
> existed before, so yes perhaps, a bit of reinvented wheel syndrom...

Apart from unnecessary duplication of work - which is basically a 
problem just for the authors and not the users - I see one issue with 
everyone making their own code do interpret OSM data and that is the 
handling of broken data.

OSM has *lots* of broken data, especially broken (multi)polygons where:

* polygon rings have gaps
* inner/outer polygon rings are mis-classified (inner rings declared as 
outer and vice versa)
* rings touch each other (inner rings touching is indeed a frequent 
thing in OSM and not considered an error)
* rings intersect

Despite these errors, the PostGIS based rendering on openstreetmap.org 
often manages to draw the buggy polygons (not by fixing them but by 
ignoring that they're broken and somehow getting away with it...), so 
people come to expect that they are present in an export, and will 
complain about missing forests or lakes if they aren't.

Different OSM processing tools have different ways of dealing with these 
problems (because you're not the only one with a "not invented here" 
syndrome), but in the end it is the users who suffer because they don't 
understand why a certain polygon shows up when they load data in QGIS 
but doesn't when they load it in OGR, or looks different when processed 
with an Osmium-based tool than when they load in into ArcGIS and so on.

If we can't get everyone to use the same code base, then it would at 
least be great to reach some kind of agreement here, or maybe at least 
produce a test suite that everyone runs their code against.


PS: For starters here's a very simple test case that should result in 
three polygons - a forest polygon with a hole, and a lake and a meadow 
polygon located in that hole: 

Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"

More information about the dev mailing list