logo separator

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

From Felix Hartmann extremecarver at gmail.com on Sat Apr 9 21:57: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. If 
you don't follow the whack of needing europewide maps, but just export 
the region you really need to your GPS, rather install different maps 
onto your PC.

Because multilayered maps are not properly workin on PC (dunno about 
Qlandkarte GT, I still primarily plan with Mapsource 6.16)

Multilayered maps mean that if you plan with Basecamp/Mapsource, you 
need different maps for your GPS.

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