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
