process same input data with mkgmap with different styles at the same time

Hello list, I try to make Garmin maps with different layers. http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map The idea is, that you can enable or disable some transparent maps that you won't see. For this reason I use mkgmap with different options and stylefiles multiple times on the same input data: java -ea -jar mkgmap.jar [options1] --style-file=style1 input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 input_data java -ea -jar mkgmap.jar [options3] --style-file=style3 input_data ... This works good, but is not with so good performance as it could be. The input data are gzipped osm-tiles of europe and everytime mkgmap runs it has to decompress and parse the same stuff. The cleverst solution I could imagine is to start mkgmap once and give it different options at the same time for different threads for example: java -ea -jar mkgmap.jar [options1] --style-file=style1 --outputdir=dir1 [options2] --style-file=style2 --outputdir=dir2 [options3] --style-file=style3 --outputdir=dir3 input_data The question is: How difficult is it to implement in mkgmap? I looked at the source code but didn't understand enough to implement it. In germany we would say I looked at the code like a pig at a clockwork. ;) I think a problem is that at the moment the order of commandline args doesn't matter but then it would be important which option belongs to which thread. Maybe another solution could be to build a cache - like the tilesplittercache, where mkgmap can store the parsed input_data. Another mkgmap instance could use this cache instead of the input data. Maybe this solution would be more easy to implement or am I wrong? So something like: java -ea -jar mkgmap.jar [options1] --style-file=style1 --write-cache=cachdir input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 --read-cache=cachdir java -ea -jar mkgmap.jar [options3] --style-file=style3 --read-cache=cachdir What do you think about that ideas? Btw: Can I specify an output directory for mkgmap or is it everytime the actual directory? Thanks! Christoph

Hello Christoph,
Hello list,
I try to make Garmin maps with different layers. http://wiki.openstreetmap.org/wiki/All_in_one_Garmin_Map
The idea is, that you can enable or disable some transparent maps that you won't see. For this reason I use mkgmap with different options and stylefiles multiple times on the same input data:
java -ea -jar mkgmap.jar [options1] --style-file=style1 input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 input_data java -ea -jar mkgmap.jar [options3] --style-file=style3 input_data ...
This works good, but is not with so good performance as it could be. The input data are gzipped osm-tiles of europe and everytime mkgmap runs it has to decompress and parse the same stuff.
The cleverst solution I could imagine is to start mkgmap once and give it different options at the same time for different threads for example: java -ea -jar mkgmap.jar [options1] --style-file=style1 --outputdir=dir1 [options2] --style-file=style2 --outputdir=dir2 [options3] --style-file=style3 --outputdir=dir3 input_data
The question is: How difficult is it to implement in mkgmap? I looked at the source code but didn't understand enough to implement it. In germany we would say I looked at the code like a pig at a clockwork. ;)
That's a great phrase! But to answer your question. I think it would be a lot of work to do what you are suggesting and really not the best solution. If I was trying to do what you are doing I would simply de-compress the input once (disk space is cheap) and then run separate mkgmap sessions as before. You could also pre-process the XML to filter out all of the crap tags that you are not interested in. That would speed up the processing by mkgmap.
I think a problem is that at the moment the order of commandline args doesn't matter but then it would be important which option belongs to which thread.
Maybe another solution could be to build a cache - like the tilesplittercache, where mkgmap can store the parsed input_data. Another mkgmap instance could use this cache instead of the input data. Maybe this solution would be more easy to implement or am I wrong? So something like: java -ea -jar mkgmap.jar [options1] --style-file=style1 --write-cache=cachdir input_data java -ea -jar mkgmap.jar [options2] --style-file=style2 --read-cache=cachdir java -ea -jar mkgmap.jar [options3] --style-file=style3 --read-cache=cachdir
What do you think about that ideas? Btw: Can I specify an output directory for mkgmap or is it everytime the actual directory?
Thanks! Christoph
Cheers, Mark
participants (2)
-
Christoph Wagner
-
Mark Burton