Hello WanMil,
thanks for the details regarding the algorithmn.
WanMil wrote
Two ideas:
1) Optimization:
It might save time if we could pass a function pointer to the quadtree.
The
function does the tagging for one element, and we don't have to manage
resultlists. I implemented that,
Hello Steve,
yes, that works fine, thanks a lot!
Together with the proposed changes regarding the new Date() parts mkgmap
now creates identical output for identical input, which helps a lot when
trying performance patches. Attached is the patch that I use for this.
Am 31.12.2011 09:06, schrieb GerdP:
Hello WanMil,
thanks for the details regarding the algorithmn.
WanMil wrote
Two ideas:
1) Optimization:
It might save time if we could pass a function pointer to the quadtree.
The
function does the tagging for one element, and we don't have to manage
Hello WanMil,
WanMil wrote
The reason is that the boundaries are not complete. Complete in two
meanings:
1. Some boundaries are missing due to incomplete OSM data
2. In some areas there might be a boundary with admin_level=7, other
areas do not have that admin_level. The LocationHook
Hello WanMil,
WanMil wrote
The reason is that the boundaries are not complete. Complete in two
meanings:
1. Some boundaries are missing due to incomplete OSM data
2. In some areas there might be a boundary with admin_level=7, other
areas do not have that admin_level. The LocationHook
Hi Gerd,
now we have the problem of how to measure the runtime performance.
I have compared unpatched and patched mkgmap. Both versions contain the
time output of the patched version. I have used one thread only with 15
european tiles (widely spread over europe) and compare the summarized
Hello WanMil,
I think you alew
--
View this message in context:
http://gis.638310.n2.nabble.com/PATCH-v1-LocationHook-speedup-tp7135704p7140401.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
Hi WanMil,
Yes , I think you always have to look at both values, esp. with java and GC.
If you optimize a function by allocating a lot of temp. objects, you might
see better runtime in this function but overall runtime may be worse because
GC gets very busy after executing the function.
Gerd
Hello WanMil,
admin_level=7 just an example. admin_levels are used differently in
countries and in regions etc.
I see
Verbandsgemeinde Waldmohr
http://www.openstreetmap.org/browse/relation/897709
which is the only boundary that has admin_level=7. The interesting thing is:
the
I've found and fixed another performance bottleneck:
The init method of the LocationHook contained a check if there is any
bounds file in the boundary directory. On my computer this check
requires ~1200ms. This is done for each tile and must be perfomed once
only.
So attached patch saves
Am 31.12.2011 14:51, schrieb Gerd Petermann:
Hello WanMil,
admin_level=7 just an example. admin_levels are used differently in
countries and in regions etc.
I see
Verbandsgemeinde Waldmohr
http://www.openstreetmap.org/browse/relation/897709
which is the only boundary
I used another way to optimize that part. On my machine, the list() method is
much faster than listFiles():
String [] boundaryFileNames = boundaryDir.list();
boolean foundBndFile = false;
for (String s: boundaryFileNames){
if
Hi WanMil,
Date: Sat, 31 Dec 2011 14:55:08 +0100
From: wmgc...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] [PATCH v1] LocationHook speedup
Am 31.12.2011 14:51, schrieb Gerd Petermann:
Hello WanMil,
admin_level=7 just an example. admin_levels are used
Am 31.12.2011 15:04, schrieb Gerd Petermann:
Hi WanMil,
Date: Sat, 31 Dec 2011 14:55:08 +0100
From: wmgc...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] [PATCH v1] LocationHook speedup
Am 31.12.2011 14:51, schrieb Gerd Petermann:
Hello WanMil,
Am 31.12.2011 14:58, schrieb Gerd Petermann:
I used another way to optimize that part. On my machine, the list()
method is much faster than listFiles():
String [] boundaryFileNames = boundaryDir.list();
boolean foundBndFile = false;
for (String s:
Hi WanMil,
sorry, you are right. I must have looked at availableLevels instead of
remainingLevels :-(
ciao,
Gerd
Date: Sat, 31 Dec 2011 15:09:03 +0100
From: wmgc...@web.de
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] [PATCH v1] LocationHook speedup
Am 31.12.2011
Great!
(Although for a nitpicker your patch is wrong. One could create a
directory containing one subdir named 123.bnd. This directory would be
detected as sufficient bounds dir by your patch. But I think we can
ignore this :-)
WanMil
I used another way to optimize that part. On my
Puuuh, but it's also a pity because that would have been an easy
improvement ;-)
Hi WanMil,
sorry, you are right. I must have looked at availableLevels instead of
remainingLevels :-(
ciao,
Gerd
Date: Sat, 31 Dec 2011 15:09:03 +0100
From: wmgc...@web.de
To:
Marko and Bartosz,
Thank you both for your advice. The mkgmap log showed a very large
number of messages, but none at all relating to coastline. But using
Bartosz's coastlines-europe file solved the problem (once I had
remembered to reference it before the data files), at the expense of a
On Sat, Dec 31, 2011 at 05:37:43PM +, Roger Calvert wrote:
Thank you both for your advice. The mkgmap log showed a very large
number of messages, but none at all relating to coastline.
There could have been some MultiPolygonRelation errors related to
coastlines. I should mention that the
20 matches
Mail list logo
