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

Sat Apr 9 08:30:06 BST 2011

Hi Felix,

On Sat, Apr 09, 2011 at 03:09:07AM +0200, Felix Hartmann wrote:
>not good. multiple layers show different top/bottom PC vs GPS . too 
>much trouble to care for it. Use transparent asymetric objects instead.

Note that the current way of doing things would not be going away. The 
multi-layer style could be based on the default style, just like the 
marine style currently is. (Heck, the marine style could be another 
layer in the new multi-layer style.)

As layers could be assigned to map tiles when invoking mkgmap, you could 
merge all layers to one output tile if you wanted.

My rationale for multiple layers is to allow the user to select what to 
see on the map. For example, bus, bicycle or ski routes are useless 
clutter when you are not interested in them. Typically, you would only 
want to see at most one type of routes at a time.

A more radical example would be to be able to hide all ways that are not 
allowed for the currently selected mode of transportation. I am not sure 
how that would work; I guess that the routing network would have to be 
constructed from a union of all map layers then.

Less clutter should mean faster display updates. For example, if landuse 
polygons were in a separate layer, maps would pan faster when you 
disable the landuse layer. I do not know about you, but I rarely need 
the landuse when using the street network. They can be nice for hikers 
or mountain bikers. When I take a shortcut through some forest paths, I 
could want to enable the landuse layer.

How can you achieve this without using multiple layers, or without 
updating the map on the device?

	Marko

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