Hi,
I only wanted to give some feedback about the speedup patches:
The time to build my maps was reduced by one
hour from 3.5 to 2.5 hours. Very impressive.
Thorsten
--
Thorsten Kukuk, Project Manager/Release Manager SLES
SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Jeff Haw
Thanks for committing Marko,
place=* nodes are commonly used, about polygon place=* I can only speak for the
situation
in the Netherlands that it is not recommended to render them (a lot of faulty
AND-import
data like place=city tags on villages or boundary=town on hamlets have been
removed or
Hi WanMil,
I tested the patch with my tiles for Saarland. I can confirm a reduction of
processing time ~ 6% compared to r2160, and also a reduction for the peek
value of heap memory usage (238M -> 210M), so that's both good!
BUT I also see a difference in one of the seven output img files (plus th
My style file are becoming more and more complex.
IMHO a (simple) preprocessor would be very helpful.
Important features (analogue C preprocessor):
- ##include (includes a text file)
- ##define (defines a preprocessor var; also as command line option)
- ##ifdef (checks if a preprocessor var is def
On Wed, Jan 04, toc-rox wrote:
> My style file are becoming more and more complex.
> IMHO a (simple) preprocessor would be very helpful.
At least on UNIX, there a preprocessor which would solve
this problems: cpp
But I don't know if there is something similar for windows.
> Questions:
> - What
Hello Steve,
was this patch ever commited? I checked out the last version from trunk and
copied the default style to my working-folder. Without the patch I get a lot of
errors starting with:
java.lang.StackOverflowError
at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:58)
at sun.ni
Hi
> was this patch ever commited? I checked out the last version from trunk and
> copied the default style to my working-folder. Without the patch I get a lot
> of errors starting with:
> java.lang.StackOverflowError
No the patch wasn't committed as it doesn't really work properly (it
stops
My first impression is "2.5 hours is a very long time" but it depends on ...
- What do you build ?
- What do you use (world bounds, world coastlines) ?
- What are your hardware resources (number of cores, ram, ...) ?
- Which OS are you using ?
- ...
A finding from yesterday: Using the world coast
On Wed, Jan 04, toc-rox wrote:
> My first impression is "2.5 hours is a very long time" but it depends on ...
>
> - What do you build ?
> - What do you use (world bounds, world coastlines) ?
> - What are your hardware resources (number of cores, ram, ...) ?
> - Which OS are you using ?
> - ...
I
My first impression is "2.5 hours is a very long time" but it depends on ...
- What do you build ?
- What do you use (world bounds, world coastlines) ?
- What are your hardware resources (number of cores, ram, ...) ?
- Which OS are you using ?
- ...
A finding from yesterday: Using the world coast
That sounds great!!
Thanks for the feedback :-)
WanMil
>
> Hi,
>
> I only wanted to give some feedback about the speedup patches:
> The time to build my maps was reduced by one
> hour from 3.5 to 2.5 hours. Very impressive.
>
>Thorsten
___
mkgmap-d
Hi Gerd,
yes of course I am interested, Send me all information you have.
Thanks
WanMil
> Hi WanMil,
>
> I tested the patch with my tiles for Saarland. I can confirm a reduction of
> processing time ~ 6% compared to r2160, and also a reduction for the peek
> value of heap memory usage (238M ->
Hi WanMil
This patch is a really great idea.
It does make a big reduction in the number of ways and nodes processed. I
don't see much difference in time on my home machine, some improvement on my
server however . I'm beginning to think that my machine is not CPU bound for
these tasks.
Anyway
While looking through the source code I observed that the
drive-on-left/right flag is set statically in the NODHEader class. That
means that a threads of one tile modifies this flag of all other tiles.
So when compiling a european map with GB included, it's a kind of
lottery if the GB areas rea
On 04/01/2012 22:46, WanMil wrote:
> While looking through the source code I observed that the
> drive-on-left/right flag is set statically in the NODHEader class. That
> means that a threads of one tile modifies this flag of all other tiles.
> So when compiling a european map with GB included, it'
Think of using the bounderies-info to find out in with land you are ...
Dirk
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> On 04/01/2012 22:46, WanMil wrote:
>> While looking through the source code I observed that the
>> drive-on-left/right flag is set statically in the NODHEader class. That
>> means that a threads of one tile modifies this flag of all other tiles.
>> So when compiling a european map with GB include
Steve,
can you do me a favour?
I have uploaded both versions to http://files.mkgmap.org.uk/detail/46
(only files that differ and not the gmapsupp.img).
Can you run the display tool and check if you can quickly find the
difference? I would have to completely install the display tool and have
to
Hi,
great job!!!
I'm saving now about 13 minutes (-17%) of mkgmap-runtime. In detail:
Germany: 19:17 (2154: 24:52) -22%
Turkey: 00:58 (2154: 01:04) -09%
Scandinavia: 08:58 (2154: 10:33) -15%
BeNeLux: 09:27 (2154: 11:00) -14%
Alps: 15:03 (2154: 18:30) -19%
GreatBritain: 06:
On 04/01/12 18:46, WanMil wrote:
> While looking through the source code I observed that the
> drive-on-left/right flag is set statically in the NODHEader class. That
> means that a threads of one tile modifies this flag of all other tiles.
> So when compiling a european map with GB included, it's
On 04/01/12 20:14, WanMil wrote:
> Steve,
>
> can you do me a favour?
> I have uploaded both versions to http://files.mkgmap.org.uk/detail/46
> (only files that differ and not the gmapsupp.img).
>
> Can you run the display tool and check if you can quickly find the
> difference? I would have to com
Hello WanMil,
while working on an improvement regarding the BoundaryPreparer I wonder what
we do with the administrative boundaries that are found in the OSM data. If
I see this right, we store the precompiled boundaries as well as those from
OSM input files. Maybe that's another place to remove u
Steve, WanMil,
the discussion about a prepro for styles inspired me to think about a
compiler/optimizer for style rules.
The point that I have in mind is this: Style files typically have many
different rules starting with e.g.
highway=* & ...
The current iplementation in RuleSet.java and RuleInde
23 matches
Mail list logo
