You probably don't need to be playing with the --resolution parameter. It specifies the resolution of the overview map, and AFAIK that's still hard-coded in mkgmap so there's currently no need to change this setting for now. The reason specifying higher resolution values requires more memory is because the areas that the splitter generates need to be aligned to the resolution of the overview map. The lower the overview map resolution, the coarser the alignment boundaries are. The splitter generates a density map internally that is in chunks matching the alignment boundaries, so each step up in resolution results in a density map that's 4 times more detailed than (and requires 4 times the memory of) the previous value. I'll try and improve the docs. Chris FH> David wrote: FH>

...

To Felix Hartmann Resolution 24 contains the most detailed leveol of details you can use in a map. Resolution 23 is a bit less detailed, and so on. That is why resolution 13 contains far less data than resolution 16. But if you mean by "24-13" all resolutions included in the interval [24;13], it is probably a bug. FH> I don't really understand what your response has to do with the FH> original question of why memory increases largely when running the FH> splitter for say resolution=16 instead of resolution=13. Of course I FH> know that 24 is the most detailed resolution. Resolution 24 has to FH> be included in any map, all other additional resolutions are FH> optional. I don't understand why the splitter needs crazy high FH> memory requirements if splitting for 16 instead of resolution 13, as FH> a map with the lowest resolution of 13 could include resolution 16 FH> as second level, therefore I would assume that splitting with FH> resolution=13 should use more memory than splitting with FH> resolution=16. The splitter can't know what intermediary resolutions FH> will be used. FH> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev