Marko, I like the idea to use the same tile data in one mkgmap run to create multiple img files. At least it is worth to discuss it, if it makes mkgmap faster. Before starting to implement it some things have to be considered: * The advantage to create multiple img files in one mkgmap run is that parsing and preparing of the OSM data must happen once only. Do you have numbers how many percent of the time is used for these steps? Please be aware that mkgmap is optimized in such a way that it loads only the tags which are needed in the style file. * I think the layer concept will be too complicated. I would prefer to have multiple styles (as Torsten Leistikow proposed in a seperate mail). * From my point of view it won't be possible to run mkgmap with different options for the different styles (or layers in your concept). Will this remove the timing advantages? Thanks for your idea! WanMil
I got an idea today: Make the style language support layers, and allow the user to specify which layers to generate and in which output files. This would have the benefit that you could generate all output layers from a map in a single run, reducing the parsing and multipolygon processing overhead, and possibly allowing more parallel processing.
The default layer (say, layer 0) would always be generated, to keep compatibility with the current behaviour.
If we extended the default style so that it would generate overlay lines for bridges and tunnels on a non-default layer, these lines would be omitted by default. Someone with a fancy TYP file could invoke mkgmap with special options to generate these overlay lines, either in the same output tile, or in a separate output tile, so that the map user can enable or disable bridges and tunnels by selecting map sets on the device.
Another application would be generating one map family per route relation type, so that you could choose which routes you want to see on the device: ski, bicycle, bus, road network, etc. My current --style=routes lumps all types of route relations together, not very useful.
Let me illustrate this rough idea with an example. The syntax is not settled yet; I would appreciate some feedback on this. I think that I should be able to implement this, if there is no serious opposition to this idea.
Consider the default style with the following addition to the beginning of the lines file:
waterway=* [layer 1] boundary=* [layer 2]
By default, all waterways and boundaries would be omitted from the map, because they are not in the default layer. Here is an example of such a default invocation, in the mkgmap.args format:
family-id: 42 mapname: 63240001 description: City input-file: 63240001.osm.gz mapname: 63240002 description: Suburb input-file: 63240002.osm.gz
Now, let us generate separate map sets for layer 1 and 2:
family-id: 42 mapname: 63240001 description: City layer1-family-id: 1 layer1-mapname: 73240001 layer1-description: City Waters layer2-family-id: 2 layer2-mapname: 83240001 layer2-description: City Boundaries input-file: 63240001.osm.gz mapname: 63240002 description: Suburb layer1-family-id: 1 layer1-mapname: 73240002 layer1-description: Suburb Waters layer2-family-id: 2 layer2-mapname: 83240002 layer2-description: Suburb Boundaries input-file: 63240002.osm.gz
We could also merge multiple layers to a single output tile by specifying
layer3-merge: 2
or even ask mkgmap to merge everything to the default output tile:
layer1-merge: default (or 0) layer2-merge: default
What do you think? This scheme is only useable when it is acceptable to use the same map tiles for all map sets. If you need smaller or larger tiles for certain map layers, you would need to invoke mkgmap once for every set of input tiles.
Best regards,
Marko
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev