logo separator

[mkgmap-dev] mkgmap splitter --resolution broken?

From Chris Miller chris.miller at kbcfp.com on Tue Oct 27 17:19:22 GMT 2009

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 at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev






More information about the mkgmap-dev mailing list