[OSM-dev] New OGR driver to read OpenStreetMap .osm / .pbf files
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