[mkgmap-dev] Idea: map layers (multiple output tiles per input tile)

Sun Apr 10 18:42:53 BST 2011

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