I recently switched to --flat-nodes on my osm2pgsql import and am pleasantly impressed with the improved update speed. Of course, I had to re-create the database and re-import the plane, to make the switch, but I was going to the new license and 64bit IDs at the same time, so all was well.

I do the entire planet, so --flat-nodes may not be the best for your bbox server, but it might be worth reading about.

Lynn (D) - KJ4ERJ

On 10/12/2012 10:27 AM, Stephan Knauss wrote:
Peter Wendorff writes:
osm2pgsql has to store nodes outside the bbox because geometries that overlap the borders etc. should be included in the result, too.
depends on the cutting algorithm used.
I could live with osm2pgsql doing a hard cut as I made my bbox large enough to have some buffer. If reference completeness is a requirement it's still possible to pass it to a softcut filter before and leave away the bbox at all.
Here is a description of two implemenations of a cutting algorithm
https://github.com/MaZderMind/osm-history-splitter

Yes, preprocessing might be faster therefore, but that might depend on your system setup and where the bottleneck of your pipeline is, as the cutting process faces the same problem here: it runs several times over the input file to find dependent nodes for ways that are partly in the extracted target area.

My problem is that a database which was always around 2GB grow to 40GB during the import process and this is killing my vserver. It simply can't cope with the I/O load. I used the asia extract as my input file as I did before but now the nodes table contains data 90 degrees away from my bounding box. My setup documentation does not mention anything that I manually cleaned up the nodes table after import. So it could have been a change in osm2pgsql as well.
Stephan

_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev



_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev

Reply via email to