Re: [mkgmap-dev] Java tuning hint
Hi all,
I just found out that the JRE on my PC uses 60013 as default:
C:\Users\Gerd>java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version
| findstr StringTable
bool PrintStringTableStatistics= false {product}
uintx StringTableSize = 60013 {product}
Gerd
From: gpetermann_muenc...@hotmail.com
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Fri, 9 May 2014 08:18:44 +0200
Subject: Re: [mkgmap-dev] Java tuning hint
Hi Bernd,
It is difficult to say how many strings are kept in the table when
your have 4 threads in parallel, but it seems the value 13 fits quite well.
Larger values did not improve anything in my tests (I ignore changes < 2
seconds).
BTW: It's very difficult to get exact values.
If you execute mkgmap two times after not using it for a while
the 2nd run will always be faster because disk caches are already
filled with good values.
So, you first have to execute mkgmap a few times with exactly the
same parms and input files to find out how many seconds
it executes on average and how large the measurement error is.
You may already see 5 % difference here
when using multiple threads (--max-jobs), because sometimes
a worse case happens, sometimes not. This also seems to
depend on actions from JRE like just in time (JIT) compiles etc,
not talking about other background programs like system updates,
downloads, virus scanners, media players etc.
The worst case that can happen is that you find a good value for
one set of input files which is bad for many other sets of input files.
Gerd
> From: weigelt.be...@web.de
> To: mkgmap-dev@lists.mkgmap.org.uk
> Date: Thu, 8 May 2014 18:28:22 +0200
> Subject: Re: [mkgmap-dev] Java tuning hint
>
> Am Donnerstag, 8. Mai 2014, 17:33:22 schrieb Gerd Petermann:
>
> Hello Gerd
>
> I've made three tests with my bonn extract
>
> without -XX:StringTableSize
> Time started: Thu May 08 17:57:43 CEST 2014
> Time finished: Thu May 08 18:04:54 CEST 2014
> Total time taken: 430804ms
>
> with -XX:StringTableSize=13
> Time started: Thu May 08 18:07:33 CEST 2014
> Time finished: Thu May 08 18:14:20 CEST 2014
> Total time taken: 406425ms
>
> with -XX:StringTableSize=103
> time started: Thu May 08 18:16:20 CEST 2014
> Time finished: Thu May 08 18:23:06 CEST 2014
> Total time taken: 405556ms
>
> This are tests on my small laptop with 3.6 GB RAM with 64bit Linux
>
> Bernd
>
> > I tried both, and the smaller values seemed to work better for mkgmap.
> > I guess it depends on the input files what value is best, but at least
> > the default 1009 doesn't work well, so any much higher prime value should
> > help.
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Java tuning hint
Am Freitag, 9. Mai 2014, 09:04:22 schrieb Gerd Petermann:
> I just found out that the JRE on my PC uses 60013 as default:
> C:\Users\Gerd>java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal
> -version | findstr StringTable bool
> PrintStringTableStatistics= false {product} uintx
> StringTableSize = 60013 {product}
the same value here
bernd@apoll:~> java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -
version | grep StringTable
bool PrintStringTableStatistics= false
{product}
uintx StringTableSize = 60013
{product}
java version "1.7.0_51"
OpenJDK Runtime Environment (IcedTea 2.4.4) (suse-24.13.5-x86_64)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)
Bernd
--
amarok2 now playing:
artist: http://www.swr3.de
title: Marchin on / One Republic; Timbaland
album: SWR3
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
Hi Gerd I found out that the routing errors still exist when you have two routable lines on top of each other, one with and one without road speed/class parameters. If the GPS finds an address on such road, routing goes mad. In my style I use type 0x02 for all cycleroutes. I need to use 0x02 because this is one of the few type that are always rendered on top of all other lines. If it were possible to skip address search on the last routable line somehow I could make it not routable, but I'm not sure. Normally multiple routable lines are not often needed, so the removal of those warnings is still ok. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
Hi Minko, > I found out that the routing errors still exist when you have two routable > lines on top of each other, > one with and one without road speed/class parameters. If the GPS finds an > address on such road, routing goes mad. In my style I use type 0x02 for all > cycleroutes. I need to use 0x02 because this is one of the few type that are > always rendered on top of all other lines. just to make sure: your style creates two lines for one OSM way, they have different types, but both below 0x3f, and one has road speed/class , the other has not. Which one come first? > > If it were possible to skip address search on the last routable line somehow > I could make it not routable, but I'm not sure. For mkgmap, a routable line is one that has a road speed/class and a non-extended type. I am not familiar with the code regarding indexes for address search. I don't know ihow this is related to routing. > > Normally multiple routable lines are not often needed, so the removal of > those warnings is still ok. I think when it causes problems, we should try to find a better solution or print a warning. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
Hi Gerd > just to make sure: > your style creates two lines for one OSM way, they have different > types, but both below 0x3f, Well, it doesnt happen if 0x02 is replaced by 0x31. I think it only happens with "standard" routable line types (0x01-0x13, 0x16, 0x1a,0x1b) but i havent tested them all > and one has road speed/class , the other has not. > Which one come first? The ones with routing parameters come first. After this I handle the cycle routes with line 0x02 to make sure they are always rendered on top (on all GPS devices). I always needed to put on 0x02 routing parameters too because of this issue. I thought I might give it a try to remove them, but it seems the issue is still the case. > I think when it causes problems, we should try to find a better > solution or print a warning. A warning would be fine, in case multiple routable lines are detected. If that's too complicated, I would suggest to print the old warning only with --check-styles: "Non-routable way with routable type 0x.. starting at ... is used for a routable map. This can lead to routing errors if multiple routable lines on this way are used." ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
Hi Minko, I am still not sure if we are talking about the same stuff. A routable line is one that has roadspeed/class and a non-extended type. These lines are internally called roads. The algo in StyledConverter collects all lines (routable and not-routable) in different lists, and after removal of wrong angles and obsolete points, all non-routable lines are added before all roads. The order within the two different lists is maintained. So, the order is only important if you add multiple non-routable lines or multiple roads for one OSM way . Felix said he adds up to 7 lines for one OSM way, so we should find out which combinations are bad. Gerd > Date: Fri, 9 May 2014 12:09:14 +0200 > From: ligfiet...@online.nl > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding > routable/non-routable types. > > Hi Gerd > > > > just to make sure: > > your style creates two lines for one OSM way, they have different > > types, but both below 0x3f, > > Well, it doesnt happen if 0x02 is replaced by 0x31. I think it only happens > with "standard" routable line types (0x01-0x13, 0x16, 0x1a,0x1b) but i havent > tested them all > > > and one has road speed/class , the other has not. > > Which one come first? > > The ones with routing parameters come first. After this I handle the cycle > routes with line 0x02 to make sure they are always rendered on top (on all > GPS devices). I always needed to put on 0x02 routing parameters too because > of this issue. I thought I might give it a try to remove them, but it seems > the issue is still the case. > > > I think when it causes problems, we should try to find a better > > solution or print a warning. > > A warning would be fine, in case multiple routable lines are detected. > If that's too complicated, I would suggest to print the old warning only with > --check-styles: > "Non-routable way with routable type 0x.. starting at ... is used for a > routable map. > This can lead to routing errors if multiple routable lines on this way are > used." > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
Hi Gerd, Let me give an example when it goes wrong then: highway=unclassified [0x06 road_class=3 road_speed=2 resolution 23 continue with_actions] bicycleroute=yes [0x02 road_class=4 road_speed=3 resolution 22 continue] I have to use continue because this rule must continue for highway=pedestrian areas which are also handled in the polygons style. If I remove the road parameters from the second line routing breaks: bicycleroute=yes [0x02 resolution 22 continue] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Doubt about min-size-polygon
Hi! I have one doubt about min-size-polygon: if using it as --min-size-polygon=8, will it probably remove house polygons from the map? Thank you! Best regards, Nelson ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Doubt about min-size-polygon
Hi Nelson, Up to now the value is ignored for resolution 24. Gerd Nelson A. de Oliveira wrote > Hi! > > I have one doubt about min-size-polygon: if using it as > --min-size-polygon=8, will it probably remove house polygons from the > map? > > Thank you! > > Best regards, > Nelson > ___ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Doubt-about-min-size-polygon-tp5805728p5805731.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
Hi Minko, okay, got it. So maybe we have to separate the "well known" routable types 0x01 -0x13 , 0x1a, 0x1b, 0x16 from others which are also routable? Gerd ligfietser wrote > Hi Gerd, > > Let me give an example when it goes wrong then: > highway=unclassified [0x06 road_class=3 road_speed=2 resolution 23 > continue with_actions] > bicycleroute=yes [0x02 road_class=4 road_speed=3 resolution 22 continue] > > I have to use continue because this rule must continue for > highway=pedestrian areas which are also handled in the polygons style. > > If I remove the road parameters from the second line routing breaks: > bicycleroute=yes [0x02 resolution 22 continue] > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Commit-r3259-remove-most-checks-regarding-routable-non-routable-types-tp5805376p5805732.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
Hi Gerd I have noticed types between 0x30-3f are behaving inconsistent, they are not rendered at all in Mapsource/Basecamp, even with a typ file. Routing seems to work but not very reliable. After some more tests, I notice other remarkable things: I search for an address on an unclassified road (type 0x06, road_class=3 road_speed=2) This road also has a bicycle route (routable line without road class/speed): [0x02 resolution 22 continue] gpsmapedit shows road_class=5 road_speed=3 on this line 0x02 (??) and routing errors happen. It always routes to the tile border and then a straight direct line to the address that I search for. [0x05 resolution 22 continue] gpsmapedit shows road_class=1 road_speed=3, routing error [0x06 resolution 22 continue] gpsmapedit shows road_class=0 road_speed=3, routing error [0x10 resolution 22 continue] gpsmapedit shows road_class=0 road_speed=0, routing error [0x0a resolution 22 continue] gpsmapedit shows road_class=0 road_speed=1, no routing error [0x29 resolution 22 continue] gpsmapedit dont show road_class nor road_speed, no routing error Normally I set on type 0x02 road_class=4 road_speed=3, and then the routing is ok. Any idea why a default value of road_speed and class is assigned altough I don't specify it? Is there a way how to show/print the routing parameters that mkgmap sets on every line? > okay, got it. So maybe we have to separate the "well known" routable > types > 0x01 -0x13 , 0x1a, 0x1b, 0x16 from others which are also routable? > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3265: calm down findBugs
Version mkgmap-r3265 was committed by gerd on Fri, 09 May 2014 calm down findBugs ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3259: remove most checks regarding routable/non-routable types.
Hi Minko, I think you found a bug in GPSMapEdit. I've just verified that mkgmap doesn't write the type 0x02 line into NET or NOD, so I assume that GPSMapEdit shows some defaults when it finds a line with type 0x02. I can reproduce the routing errors on the device: 0x02 as road works, without road it fails or the device crashes after a few seconds. So I think it is not a good idea to use 0x02 without road-class/speed. Gerd > Date: Fri, 9 May 2014 15:47:05 +0200 > From: ligfiet...@online.nl > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] Commit: r3259: remove most checks regarding > routable/non-routable types. > > Hi Gerd > > I have noticed types between 0x30-3f are behaving inconsistent, they are not > rendered at all in Mapsource/Basecamp, even with a typ file. Routing seems to > work but not very reliable. > > After some more tests, I notice other remarkable things: > > I search for an address on an unclassified road (type 0x06, road_class=3 > road_speed=2) > This road also has a bicycle route (routable line without road class/speed): > > [0x02 resolution 22 continue] > gpsmapedit shows road_class=5 road_speed=3 on this line 0x02 (??) and routing > errors happen. > It always routes to the tile border and then a straight direct line to the > address that I search for. > > [0x05 resolution 22 continue] > gpsmapedit shows road_class=1 road_speed=3, routing error > > [0x06 resolution 22 continue] > gpsmapedit shows road_class=0 road_speed=3, routing error > > [0x10 resolution 22 continue] > gpsmapedit shows road_class=0 road_speed=0, routing error > > [0x0a resolution 22 continue] > gpsmapedit shows road_class=0 road_speed=1, no routing error > > [0x29 resolution 22 continue] > gpsmapedit dont show road_class nor road_speed, no routing error > > > Normally I set on type 0x02 road_class=4 road_speed=3, and then the routing > is ok. > > Any idea why a default value of road_speed and class is assigned altough I > don't specify it? > Is there a way how to show/print the routing parameters that mkgmap sets on > every line? > > > > okay, got it. So maybe we have to separate the "well known" routable > > types > > 0x01 -0x13 , 0x1a, 0x1b, 0x16 from others which are also routable? > > > > Gerd > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter removes multipolygon-tags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Gerd, after taking a deeper look into my tile 1211 (also with r327), there are stil mp's missing. Eg. three buildings of Bayreuth University. All three buildings are mapped as mp and also are member in a site relation of the university. After splitting all three mp (8628, 5185 and 1869778) aren't written but relation 933537 is written. I also updated my files on github, if you need them. Henning -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJTbTSfAAoJEKXggIeC16WPhPQIAISLb9pzkWfsytgu44WmC6Fn LRMRfeup8RcLGzbJbxD8trM4r1dUuhy9vCAzhLPzbEq+ojfw+GeKydPBwGOx9kSF AxpELMvhAHlCr6s3nv+iTehsWf2N6ivJA2TMRPtBJil2Zabe2OkgVnji6DnPyhUO egD1kM5PEaOx6diELEbHGPc3UCwYiJ24ANTCoV+o6GKb2tPsJnebdE8XsN17BL6X /wG8w+Srbkgiu4nCDvG0hDNA/gZkZF6i4K1CMGinoUtpVyR58BYUKbsUdVqRDOvc VmCgj3jyi7vC4bt03rgUR9ADrNZIvVojj3N+cH7YX3/eHKUX3xVY7iTauaPfnrk= =OWHv -END PGP SIGNATURE- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Doubt about min-size-polygon
On Fri, May 9, 2014 at 8:56 AM, GerdP wrote: > Up to now the value is ignored for resolution 24. Even if I force a --min-size-polygon=0, this snippet from polygons will override it? (and make buildings visible only at resolution 24) (building=* | amenity=*) & area!=no [0x13 resolution 24] ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter removes multipolygon-tags
Hi Henning, yes, sorry for the lazy testing :-( I found the cause for the error, but I am still searching for the correction... Gerd > Date: Fri, 9 May 2014 22:03:52 +0200 > From: o...@aighes.de > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] splitter removes multipolygon-tags > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi Gerd, > > after taking a deeper look into my tile 1211 (also with r327), > there are stil mp's missing. Eg. three buildings of Bayreuth > University. All three buildings are mapped as mp and also are member > in a site relation of the university. > > After splitting all three mp (8628, 5185 and 1869778) aren't written > but relation 933537 is written. > > I also updated my files on github, if you need them. > > Henning > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > > iQEcBAEBAgAGBQJTbTSfAAoJEKXggIeC16WPhPQIAISLb9pzkWfsytgu44WmC6Fn > LRMRfeup8RcLGzbJbxD8trM4r1dUuhy9vCAzhLPzbEq+ojfw+GeKydPBwGOx9kSF > AxpELMvhAHlCr6s3nv+iTehsWf2N6ivJA2TMRPtBJil2Zabe2OkgVnji6DnPyhUO > egD1kM5PEaOx6diELEbHGPc3UCwYiJ24ANTCoV+o6GKb2tPsJnebdE8XsN17BL6X > /wG8w+Srbkgiu4nCDvG0hDNA/gZkZF6i4K1CMGinoUtpVyR58BYUKbsUdVqRDOvc > VmCgj3jyi7vC4bt03rgUR9ADrNZIvVojj3N+cH7YX3/eHKUX3xVY7iTauaPfnrk= > =OWHv > -END PGP SIGNATURE- > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
