<div dir="ltr">On Wed, Jul 30, 2008 at 1:24 PM, Brett Henderson <span dir="ltr"><<a href="mailto:brett@bretth.com">brett@bretth.com</a>></span> wrote:<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">2008/7/26 Karl Newman <span dir="ltr"><<a href="mailto:siliconfiend@gmail.com" target="_blank">siliconfiend@gmail.com</a>></span><br><div class="gmail_quote"><div class="Ih2E3d"><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><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><div><br><div class="Ih2E3d">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></div>
</blockquote></div>I've completed the New York extraction from the segment file and created a 71.3MB gzip compressed file, that will be approaching 1GB uncompressed.  I ran this second invocation with idTrackerType=IdList due to the much smaller number of nodes in the result.<br>
<br>It all seems to be working okay at my end.  All I can think of is that the osmosis process failed unexpectedly due to an out of memory error.  The files being created were too small.<br><br></div>