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

[Richard Marsden]

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:

https://gis.stackexchange.com/questions/336595/gdal-ogr-losing-osm-closed-way-features-that-ogr2ogr-imports

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)

        layer.ResetReading()
        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.

Regards,

Richard Marsden