On Fri, Apr 08, 2011 at 11:19:17PM +0300, 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
On Sat, Apr 16, 2011 at 12:23:03AM +0300, Marko Mäkelä wrote:
I think that 2.5 minutes for these simple layers is too much. Because
the processing time per layer did not vary much, no matter how much data
was generated (13312 bytes .img of ferry routes, 986624 bytes of bus
routes), I would guess
Am 15.04.2011 23:23, schrieb Marko Mäkelä:
On Sun, Apr 10, 2011 at 09:18:00PM +0200, WanMil wrote:
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
On Sun, Apr 10, 2011 at 09:18:00PM +0200, WanMil wrote:
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
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
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
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
On 04/08/2011 03:19 PM, 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.
You can already do this using the XAPI to pull the data you want for
each layer you want to define in
On Sat, Apr 09, 2011 at 01:14:31PM -0500, Paul Johnson wrote:
On 04/08/2011 03:19 PM, 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.
You can already do this using the XAPI to pull
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
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
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
21 matches
Mail list logo
