[gdal-dev] Importing OSM: closed ways being skipped

Richard Marsden winwaed at gmail.com
Thu Sep 26 14:33:42 PDT 2019

I am trying to read an osm pbf file, but I am getting different
feature counts when I use ogr2ogr to convert the file to spatialite,
and the Python OGR/GDAL wrapper (in a QGIS plugin) to loop through the
features individually.
Points, lines, and line strings are the same. The differences are in
the multipolygons.  ogr2ogr is reporting "closed ways" (with
osm_way_id set), whilst the direct Python calls are not.
The direct Python calls report a much lower multipolygon count, and
missing specific ids that I have searched for. It reports no features
with osm_way_id set.
(my test data is the Geofabrik Texas extract - this contains a lot of
buildings encoded as closed ways)

I've also described the issue here:


Whilst searching this list, I saw references to osmconf.ini - turns
out I have about half a dozen copies installed from various
applications. They all have a "closed_ways_are_polygons" entry, which
looks like it could be the cause of the problem.
I tried copying one of these files to my plugin's directory, reloading
the plugin, and no change.

How can I programmatically check which osmconf.ini (if any) is being
used, what the closed_ways_are_polygons= setting is set to? Is it
possible to override it?

Environment: Windows 10 x64; GDAL and OGR2OGR are v2.4.1
More Python code is at the above link, but  this is how I am opening
an querying the features (error checking/etc removed for simplicity):

    from osgeo import gdal

    gdal.SetConfigOption("OGR_INTERLEAVED_READING", "YES")

    ds = gdal.OpenEx(input_pbfname, gdal.OF_VECTOR)

    nly = ds.GetLayerCount()

    nPoints = 0

    for ily in range (0,nly):
        layer = ds.GetLayerByIndex(ily)

        feat = layer.GetNextFeature()
        while feat is not None:
            if layer.GetName() == "points":
                nPoints = nPoints+1
       #     elif  layer.GetName() == "lines": <etc>

If everything appears okay with my Python install, the next step would
be to try reproducing the issue directly with C/C++ - probably on a
Linux system. If this turns out to be a bug, then I'm game to
investigate it further and fix. However at the moment, I think it is
much more likely to be a configuration issue.


Richard Marsden

More information about the gdal-dev mailing list