<div dir="ltr">2008/7/26 Karl Newman <span dir="ltr"><<a href="mailto:siliconfiend@gmail.com">siliconfiend@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr"><div><div></div><div class="Wj3C7c"><br></div></div>Well, I ran it for a while until it failed because of lack of heap space (I had -Xmx512M for the Java command but it wasn't enough for the ListIdTracker). But regardless, it already generated a 18.6 GB uncompressed OSM file (and that's only nodes), so I suspect there's something wrong with the creation of your segment_earth.osm. Make sure it's not failing silently.<br>

<br>A few optimizations you could use:<br><ol><li>Use planet.gz, not bz2 because Osmosis is much faster at gzip (it has native code).</li><li>Don't enable date parsing.</li><li>Add the parameter "idTrackerType=BitSet" to the bounding box task. It's more efficient for large bounding boxes.</li>

</ol>Karl<br></div>
</blockquote><div><br>Apologies for the slow reply, I've had a lot on.<br>
<br>
I had similar issues with out of memory errors and had to switch to the
BitSet id tracker.  I ended up with a 3.25 GB gzip compressed file for
the segment file.<br>
<br>
Another optimisation is to stop using the log progress task.  I haven't
tried running with and without logging recently but I suspect it adds a lot of overhead.  There's
probably a much smarter way of doing this but the current
implementation isn't very efficient.<br>
<br>
I'll run the second step now.<br> </div></div></div>