<div class="gmail_quote">Hi Nic,<br><br>Frederik makes a good point.  Using the BitSet id tracker for planet level splitting, and IdList id tracker for small bboxes should provide significant memory usage gains.  I've had a closer look at the code, and the IdList uses an integer (ie. 4 bytes) of memory per id within the bounding box meaning that it will be more efficient than BitSet for any bounding box containing less than 1/32 of the data in the planet.  BitSet by comparison uses a fixed amount of memory which is (maximum_id / 8 = total bytes).  In fact it will be slightly better than that because the planet id allocation is sparse due with ids no longer existing in the current planet file due to deletes.<br>
<br>Some example numbers.  There are actually several id trackers created per task, but the one containing node ids is the important one.  If there are 500 million nodes in the planet, a BitSet should consume approximately 60MB of memory.  An comparable IdList would consume almost 1.9GB.  However, if a bounding box contains only 10 million nodes, it will consume only 38MB compared to the BitSet still consuming a fixed 60MB of memory.<br>
<br>If you're having problems with the dividing line splitting bounding boxes in two, can you use the --bounding-polygon task instead to give you a more accurate dividing line.  It consumes identical memory to --bounding-box, but uses a more complicated implementation for deciding if a node lies within the specified area.  For simple polygons with limited numbers of points I think the performance will still be very good.<br>
<br>I didn't understand your suggestion for a better id list tracker implementation, but I think it would require a single task that has knowledge of all bounding boxes being produced instead of the current implementation where each box is processed independently with its own id tracker.  Your needs may require a dedicated plugin with a new task targeted to your requirements.<br>
<br>Brett<br><br><br>On Tue, Feb 9, 2010 at 12:00 AM, Nic Roets <span dir="ltr"><<a href="mailto:nroets@gmail.com" target="_blank">nroets@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hello Frederik,<br><br>I was looking for something like your outPipe=r1, inPipe=r1 trick. But as Brett (and you) point out, doing it in one pass will require lots and lots of RAM.<br><br>And I've tried it with a dividing line in the US. Except 51 rectangles cross that dividing line and I know 51 BitSets will require more than 4GB RAM. So two passes are also not an option.<div>

<br>
<br><div class="gmail_quote">On Mon, Feb 8, 2010 at 2:06 PM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">


<br>
<br>
PS: Is it by design that some areas are not covered by any of your rectangles?<br><font color="#888888">
<br></font></blockquote><div><br></div></div></div>All areas are covered. Only after clicking on the rectangle will it become a larger yellow rectangle and you can see it's true size.<br><br>
<br>_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org" target="_blank">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
<br></blockquote></div><br>