logo separator

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

From Felix Hartmann extremecarver at gmail.com on Sat Apr 9 02:09:07 BST 2011

not good. multiple layers show different top/bottom PC vs GPS . too much 
trouble to care for it. Use transparent asymetric objects instead.

On 08.04.2011 22:19, Marko Mäkelä wrote:
> 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




More information about the mkgmap-dev mailing list