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