[mkgmap-dev] Splitter --cache parameter

Sun Aug 23 20:04:55 BST 2009

Hi Francois, thanks for the feedback. Sounds like the caching makes quite 
a difference for you which is great news. In your case I'd say that most 
of the gain is because the cache prevents having to uncompress the .bz2 files 
multiple times - that's a very time consuming process.

As for the problem you talked about with changing to different .osm files, 
it's something I'm already aware of and mentioned in my earlier mail:

"Be careful to delete the cache files if you want to rerun the splitter on 
a different .osm file, otherwise the previously cached data will be used 
from the original .osm file instead. (I'll probably add a check for this 
situation, but there's nothing in place to prevent it just yet.)"

Basically if you specify --cache and there's already some cache files in 
existence, they'll get used and any .osm files that you specify on the command 
line will be ignored. Until I address this, you could try creating different 
directories to use as a cache for each .osm file you want to process. eg:

java -Xmx2000m -jar splitter.jar --cache=switzerland switzerland.osm.bz2
java -Xmx2000m -jar splitter.jar --cache=andorra andorra.osm.bz2

Hope that helps,
Chris

f> Chris Miller a écrit :
f> 
f> Hi Chris,
f> 
>> If you want to enable the disk caching, you specify the cache
>> location as follows:
>> 
>> --cache=<directory>
>> The --cache parameter is entirely optional. if you don't specify it,
>> the
>> splitter will work in exactly the same way it did previously.
>> I hope the above explanation makes sense. Any questions, comments or
>> suggestions are welcome.
>> 
f> I'm testing it against Switzerland.
f> 
f> 1st run : With the option --cache enable, these are the results :
f> 
f> 20h 20mns 17s - On va decouper la carte switzerland.osm.bz2 en
f> plusieurs
f> morceaux (beginning)
f> 20h 23mns 35s - On a fini le decoupage de la carte
f> switzerland.osm.bz2.
f> (end)
f> (local time)
f> 2nd run : Same as 1st run, so --cache enable, but I've not removed
f> the
f> previously created node.xxx, ways.xxxx and relations.xxxx files
f> created.
f> -rw-r--r--  1 fm users     8200 2009-08-23 20:22 nodes.bin.keys
f> -rw-r--r--  1 fm users 69494780 2009-08-23 20:22 nodes.bin
f> -rw-r--r--  1 fm users     6481 2009-08-23 20:22 ways.bin.keys
f> -rw-r--r--  1 fm users 25194598 2009-08-23 20:22 ways.bin
f> -rw-r--r--  1 fm users     1312 2009-08-23 20:22 relations.bin.roles
f> -rw-r--r--  1 fm users     1693 2009-08-23 20:22 relations.bin.keys
f> -rw-r--r--  1 fm users   474197 2009-08-23 20:22 relations.bin
f> For that same run, it gives me :
f> 20h 28mns 08s - On va decouper la carte switzerland.osm.bz2 en
f> plusieurs
f> morceaux (begin)
f> 20h 29mns 05s - On a fini le decoupage de la carte
f> switzerland.osm.bz2.
f> (end)
f> Problem : it doesn't want to write new nodes.xxxx etc... files. The
f> files are the same as before. It seems that splitter sees the already
f> created files, and doesn't want to create new one by overwritting the
f> previous ones. This gave me a problem, as I run splitter first
f> against Andorra ( ;-) very tiny osm file), and then after against
f> Switzerland. Splitter used the nodes.xxx ways... and relations.xxx
f> files created for Andorra.
f> 
f> 3rd run : without the option --cache enable :
f> 20h 35mns 33s - On va decouper la carte switzerland.osm.bz2 en
f> plusieurs
f> morceaux
f> 20h 39mns 51s - On a fini le decoupage de la carte
f> switzerland.osm.bz2.
f> So it much faster.
f> 
f> Francois
f> 