[gdal-dev] Importing OSM: closed ways being skipped
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
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
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.
More information about the gdal-dev