2011/4/9 Marko Mäkelä marko.mak...@iki.fi:
Maybe I was being unclear. The use case that I have in mind is the
generation of a map set that comprises several layers (families in
Garmin terminology). These layers can be enabled or disabled in the map
settings menu on the GPS receiver.
On Sun, Apr 10, 2011 at 11:26:58AM +0200, Martin Simon wrote:
I think this is a great idea! I generate a map with seperate layers for
-roads and small areas like buildings
-landuse
-a colored terrain model (to be able to switch between this and
landuse representation)
-speed limits as colored ways
Same here. My only issue with QLandkarteGT is the inability to plan
routes.
Again, the old way of doing things would not be going away. This
multi-layer stuff would remain compatible with existing styles and
scripts. To take advantage of it, you would have to edit the styles and
scripts.
2011/4/10 Felix Hartmann extremecar...@gmail.com:
Same here. My only issue with QLandkarteGT is the inability to plan
routes.
Again, the old way of doing things would not be going away. This
multi-layer stuff would remain compatible with existing styles and
scripts. To take advantage of it,
Am 10.04.2011 13:45, schrieb Felix Hartmann:
I'ld actually rather have the opposite. Get mkgmap to accept multiple
input files and merge them into the same layer. That way one could
take 2 osm files, or one 1polish map, one osm, or one .img and one .osm
(say one contourlines, one normal map)
On 10.04.2011 14:22, Martin Simon wrote:
2011/4/10 Felix Hartmannextremecar...@gmail.com:
Same here. My only issue with QLandkarteGT is the inability to plan
routes.
Again, the old way of doing things would not be going away. This
multi-layer stuff would remain compatible with existing
It is clear when zooming in on my GPSMAP 62s that Garmin can make use of
resolutions greater than 24 with regard to 'styling':
I have a map in which I go with the default 'styling' for 'Residential
Roads (0x06)' by not specifying this in my TYP file. I zoom-in to the
point where I know that
El 10/04/11 14:37, Felix Hartmann escribió:
On 10.04.2011 14:22, Martin Simon wrote:
2011/4/10 Felix Hartmannextremecar...@gmail.com:
Qlandkarte has gone a long way, but still Mapsource draws the maps
better looking, quicker and autorouting and generall track planning is
much quicker.
Moin,
since my GPS-maps rely heavily on multiple layers, there would be some benefit,
if producing of these layer could happen within a single mkgmap run, so that the
common proccesing steps would be executed only once.
Whether this can be achieved, depends on the time of the processing step. I
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
On Sun, Apr 10, 2011 at 07:42:53PM +0200, WanMil wrote:
* 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?
No, I haven't collected any
On Sun, Apr 10, 2011 at 07:42:53PM +0200, WanMil wrote:
* 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?
No, I haven't collected any
The patch (based on an idea of Marko) checks if a multipolygon and its
potential outer members has tags that are defined in the style. If not
the multipolygon processing is not performed.
This reduces processing time for small styles with a limited set of tags.
The effect is not as big as
13 matches
Mail list logo
