Version mkgmap-r3258 was committed by gerd on Tue, 06 May 2014
merge the performance2 branch
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
This issue can simply be solved by using a TYP file.
You can grab the default style typ file that we use in Lambertus generic OSM
maps:
https://code.google.com/p/mkgmap-style-sheets/source/browse/#svn%2Ftrunk%2Ftyp%2Fosm%20generic%253Fstate%253Dclosed
The strange thing is that Garmin doesn't
On 06/05/14 10:24, Gerd Petermann wrote:
@WanMil, Steve: Please review.
In Main.java I use synchronized to make sure that concurrent updates
are handled.
The synchronized is not required, since int accesses are atomic and it
appears that all changes to it are made via the same thread anyway.
Hi all,
I've applied num-tiles-v1.patch and improved the split algo, see
http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5805165.html
It is now less likely that splitter creates tiles with a low number of
nodes, it is more likely that all tiles have nearly the same number of nodes,
BTW: The message is still present in version 3258. ;)
--
View this message in context:
http://gis.19327.n5.nabble.com/check-styles-tp5805213p5805352.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
___
mkgmap-dev mailing list
Hi Steve,
thanks for the quick feedback.
@WanMil, Steve: Please review.
In Main.java I use synchronized to make sure that concurrent updates
are handled.
The synchronized is not required, since int accesses are atomic and it
appears that all changes to it are made via the same thread
Hi,
Thanks all.
I'll watch it.
Le 06/05/2014 05:16, Minko a écrit :
This issue can simply be solved by using a TYP file.
You can grab the default style typ file that we use in Lambertus generic OSM
maps:
Version mkgmap-r3259 was committed by gerd on Tue, 06 May 2014
remove most checks regarding routable/non-routable types.
all types = 0x01 and = 0x3f are considered to be routable.
It seems that a routable type used for a non-routable line
is no longer causing problems, so there is no need to
Hi Uli,
thanks for the reminder. It is done with r3259.
Gerd
Date: Tue, 6 May 2014 04:57:40 -0700
From: ulib...@gmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] --check-styles
BTW: The message is still present in version 3258. ;)
--
View this message in
Hi programmers,
Eclipse complains about a lot places in the source code., e.g.
Resource leak: 'fmt' is never closedSyntaxException.java
/mkgmap/src/uk/me/parabola/mkgmap/scanline 45Java Problem
The code looks like this:
public String getMessage() {
Formatter fmt =
Seems to be much better now. I don't think I can increase the max-nodes
value though, but for most maps the new algo creates less tiles for the
same max-nodes value (e.g. Austria from 43 down to 35 for me, with the
smallest tile now around 5MB instead of 2.8, and the biggest 12MB
instead of
Hi Felix,
fine :-)
And yes, I meant max-nodes may have to be decreased, not increased. Sorry
for the typo.
Reg. speed: That's unexpected. It should not take much time to find the
better split,
(a few seconds) and typically safe some time to have fewer tiles.
I'll check that tomorrow.
Gerd
Latest NT Topo TYP files use both 0x13 and 0x109 for buildings.
Interestingly, only 109 seems to be visible.
So, I wonder why 0x13 has been included perhaps for some compatibility
reason.
--
View this message in context:
Hi @ all,
some users of my map reported to me, that there are several polygons
missing. After taking a look into the splitted o5m-files I can confirm,
that they can't be rendered because the objects doesn't contain the
necessary tags.
First I thought, it could be cause because of multiple
Hi Henning,
please check the log produced by splitter. Does it show the OSM id (I think
you mean 70274) ?
Gerd
Henning Scholland wrote
Hi @ all,
some users of my map reported to me, that there are several polygons
missing. After taking a look into the splitted o5m-files I can confirm,
Hi
Eclipse complains about a lot places in the source code., e.g.
Resource leak: 'fmt' is never closedSyntaxException.java
/mkgmap/src/uk/me/parabola/mkgmap/scanline 45Java Problem
The code looks like this:
public String getMessage() {
Formatter fmt = new
Hi Steve,
yes, I agree. I've also tried a test code and found no reason for the
message from Eclipse. It just complains about all closable instances
which are not explicitely closed. I think most of them can be ignored.
It's just that I wonder why mkgmap requires more and more memory
the longer
Hi,
Le 06/05/2014 14:08, nwillink a écrit :
Latest NT Topo TYP files use both 0x13 and 0x109 for buildings.
Interestingly, only 109 seems to be visible.
So, I wonder why 0x13 has been included perhaps for some compatibility
reason.
That is the solution.
0x10900 works fine on etrex30.
Thank
I'm glad that works!
On 06/05/2014 20:42, Stéphane MARTIN [via GIS] wrote:
Hi,
Le 06/05/2014 14:08, nwillink a écrit :
Latest NT Topo TYP files use both 0x13 and 0x109 for buildings.
Interestingly, only 109 seems to be visible.
So, I wonder why 0x13 has been included perhaps for some
On 06/05/14 10:24, Gerd Petermann wrote:
@WanMil, Steve: Please review.
In Main.java I use synchronized to make sure that concurrent updates
are handled.
The synchronized is not required, since int accesses are atomic and it
appears that all changes to it are made via the same thread anyway.
Hi Felix,
reg. speed: I can't reproduce that. I compared a split of Germany,
both versions (r321 and r325) are more or less running the same time.
(I've executed both programs two times to make sure that disk caches
are not causing big differences)
Or did you mean the combination of splitter +
21 matches
Mail list logo
