[gdal-dev] 'Polygons as multipolygons' option for OSM driver

Rahkonen Jukka Jukka.Rahkonen at mmmtike.fi
Mon Aug 13 01:50:55 PDT 2012


Even Rouault wrote: 

> > The behaviour of the driver would be that no simple polygons (polygons
> > that are described as ways) would be reported until the file has been
> > completely processed.
> >
> > The algorithm would be something like that :
> > - store ways in the temporary way DB as currently, but don't advertize
> > ways that are identified as area for now
> > - when examining relations, when a polygon described as a way has been
> > "consumed" as being the outer way of a relation, it will be removed
> > from the temporary way DB (actually, probably just tagged as being no
> > longer advertizable, in case it would be needed by another relation
> > afterwards) - at the end, report all ways that are areas that remain
> > in the temporary way DB as being advertizable
> 
> I've implemented the above in r24774. It might have an impact of
> performance (not benchmarked, and hopefully not too big) and if you turn -
> progress, it will seem to be stuck at 100% for longer as before, since there is
> now the post processing of closed ways that are not referenced by relations
> to do.

I made a quick test with command
ogr2ogr -f SQLite -dsco spatialite=yes germany.sqlite germany.osm.pbf -gt 20000 -progress --config OGR_SQLITE_SYNCHRONOUS OFF --config OSM_COMPRESS_NODES YES -lco SPATIAL_INDEX=NO

With previous version the conversion took 880 seconds vs. 985 seconds with the new one (r24776) thus it was 12 percent slower in this phase.  I consider that it is not bad at all because for most use cases the OSM polygons (closed rings presenting areas) and multipolygons (coming from OSM multipolygon relations) must be combined anyway and it would probably be much slower as a separate process.

The timings above include only the raw conversion into Spatialite. Creating spatial indexes for the tables take so much time that the whole process that gives indexed tables as end result is only 4 percent slower with the new OSM driver version.

-Jukka Rahkonen-




More information about the gdal-dev mailing list