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