Every two years when I upgrade to the latest debian stable I start from scratch with my elevation contours pgsql/postgis database. This year I spent an entire day trying to find some new combination of work flow that would allow me to import the data successfully. My old work flow goes like this:
- unzip srtm3 data
- create osm file using phyghtmap version 1.47
import osm to pgsql db using the following command:
osm2pgsql -d contours --style [path to style file] (add -a for subsequent imports)
(with osm2pgsql v0.92) I first ran into memory issues, which forced me to use -C (cache) and -s (slim) options. The first file imported ok, but the next one took 300 some seconds at 0.4k/s. If you assume 1 osm file for each of the 550 srtm3 zip files to be converted/imported this works out to over 45 hours. Actually, it would take much longer since phyghtmap spits out sometimes 5 or so osm files for a given zip archive. So this is not feasible, and this process used to take me only 6-7 hours with older versions of osm2pgsql. So after a day of trying everything I could think of including combining the osm files prior to import using osmconvert and osmosis (this resulted in garbled data verified in qgis), I gave up and went searching for an older version of osm2pgsql. I compiled version 0.86 from source, and bam, I was back on track with my old work flow.
So finally my question is this: is the old behavior of osm2pgsql gone forever or can we resurect it just as a cli switch? It seems to me the problem is all the indexing that is being done on each import, but I do not see any switches that allow that behavior to be turned off.
