[mkgmap-dev] process same input data with mkgmap with different styles at the same time

Mon Mar 22 11:00:32 GMT 2010

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