Hello Scott,<br><br>How do you keep track of what bboxs each entity belongs to ?<br><br>I'm not really asking a question, I'm just saying that I found a way to reduce the memory requirement for that considerably. Instead of a bit per bbox per entry, I store only 16 bits or 32 bits per entry. Here is the source. <br>
<a href="http://trac.openstreetmap.org/browser/applications/rendering/gosmore/bboxSplit.cpp?rev=24484">http://trac.openstreetmap.org/browser/applications/rendering/gosmore/bboxSplit.cpp?rev=24484</a><br><br>Ask if you have any questions.<br>
<br><div class="gmail_quote">On Wed, Dec 1, 2010 at 2:59 PM, Scott Crosby <span dir="ltr"><<a href="mailto:scrosby@cs.rice.edu">scrosby@cs.rice.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I've been working on making various improvements to the mkgmap<br>
splitter. It was originally intended to split a map into smaller<br>
pieces which could then be converted into Garmin format and artifacts<br>
of that original purpose continue to exist. (Eg, its coordinate system<br>
for representing the areas.)<br>
<br>
However, I've committed several improvements to crosby_integration<br>
branch in mkgmap SVN that massively increase its scalability and may<br>
make it more useful to a general audience:<br>
<br>
On a 8gb core i7 machine, the new version can:<br>
   Split the whole planet into 1200 tiles in about an hour (from pbf<br>
to osm.gz format) in a single pass.<br>
   Split the whole planet into 20000 tiles in about 4 hours over 3 passes.<br>
<br>
There are some limitations, both in the implementation, and design.<br>
<br>
    Due to inherent serialization of the internal tracking tables, it<br>
only uses a few CPU cores.<br>
<br>
    The code uses bounding boxes, not bounding polygons. In the<br>
original purpose of generating mkgmap tiles, tiles are square there<br>
are no polygon tests. Polygon support is straightforward to add, but a<br>
fileformat must be defined to specify bounding polygons instead of<br>
bounding boxes.<br>
<br>
    At thousands of tiles being output concurrently in a pass, memory<br>
consumption in output buffering can be significant.<br>
<br>
    The process assumes that the file is sorted with nodes first, then<br>
ways, then relations. Efficiency degrades if they are not further<br>
sorted based on ID.<br>
<br>
    Ways are not 'completed', A way is included if any node of it is<br>
within the bounding box. Other nodes in the way are not included<br>
unless they too lie inside the bounding box. (So, typically, the<br>
bounding box is expanded to include an overlap region.)<br>
<br>
    All metadata is dropped.<br>
<br>
The code hasn't been generalized to overcome these limitations, but<br>
might be useful to those creating lots of excerpts or breaking maps up<br>
by continent, nation, state, or county. As I don't expect to have much<br>
time to work on the code, I mention it now.<br>
<br>
Scott<br>
<br>
_______________________________________________<br>
dev mailing list<br>
<a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/dev" target="_blank">http://lists.openstreetmap.org/listinfo/dev</a><br>
</blockquote></div><br>