March 2012 - mkgmap-dev - The mkgmap lists

newbie question: How to use mkgmap?
by Hadmut Danisch 03 Mar '12

03 Mar '12

Hi, this list is said to be suitable for *any* questions about mkgmap. I'm trying to create my own img files for a garmin eTrex (instead of downloading from the tile server). For some reason it does not work the way I expect, and even by reading all web pages I could find about usage of mkgmap, I did not find the problem: wget -O muenchen.osm "http://api.openstreetmap.org/api/0.6/map?bbox=11.54,48.14,11.543,48.145" java -jar mkgmap-r2232/mkgmap.jar muenchen.osm produces an img-file of just 9216 bytes, there must be something wrong. And java -jar mkgmap-r2232/mkgmap.jar --index --gmapsupp muenchen.osm even aborts: SEVERE (LocationHook): muenchen.osm: Disable LocationHook because boundary directory does not exist. Dir: bounds Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1 at java.util.ArrayList.elementData(ArrayList.java:338) at java.util.ArrayList.get(ArrayList.java:351) ... Is there anywhere a step-by-step-introduction? I did not find any hint about what I am doing wrong and what options are really required to generate img files. regards Hadmut

2 1

[Patch] Improve StyledConverter
by GerdP 03 Mar '12

03 Mar '12

Hi WanMil, we have at least 5 unused bytes in each Coord instance. I suggest to save one more flag and an id-value in them to speed up StyledConverter and remove one more IdentityHashMap. See attached patch. Gerd http://gis.19327.n5.nabble.com/file/n5533908/styledConv_v1.patch styledConv_v1.patch -- View this message in context: http://gis.19327.n5.nabble.com/Patch-Improve-StyledConverter-tp5533908p5533… Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

[Patch] Spurious dead main thread
by GerdP 03 Mar '12

03 Mar '12

Hi WanMil, the loop in main (performance branch) does not always end, sometimes the main thread hangs in cmplService.take(); I guess this happens when the last preparer finishes after the test of getActiveCount() and before take() is called: do { try { cmplService.take(); } catch (InterruptedException exp) { System.err.println(exp.getMessage()); } } while (((ThreadPoolExecutor) threadPool).getActiveCount() > 0); The attached patch solves this problem. Gerd http://gis.19327.n5.nabble.com/file/n5533662/spuriois_hang.patch spuriois_hang.patch -- View this message in context: http://gis.19327.n5.nabble.com/Patch-Spurious-dead-main-thread-tp5533662p55… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

[Patch] Improve MapMaker.roadsAreJoined()
by GerdP 03 Mar '12

03 Mar '12

Hi, roadsAreJoined() tests all points of one MapLine against all points of another MapLine instance. It should first check the previously calculated bounding boxes to eliminate many unsuccesfull loops. Gerd Index: src/uk/me/parabola/mkgmap/main/MapMaker.java =================================================================== --- src/uk/me/parabola/mkgmap/main/MapMaker.java (revision 2232) +++ src/uk/me/parabola/mkgmap/main/MapMaker.java (working copy) @@ -196,6 +196,8 @@ private boolean roadsAreJoined(MapLine r1, MapLine r2) { if(r1 != r2) { + if (r1.getBounds().intersects(r2.getBounds()) == false) + return false; for(Coord c1 : r1.getPoints()) { for(Coord c2 : r2.getPoints()) { if(c1 == c2 || c1.equals(c2)) -- View this message in context: http://gis.19327.n5.nabble.com/Patch-Improve-MapMaker-roadsAreJoined-tp5533… Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

Commit: r2232: 280: nsis lang patches
by svn commit 02 Mar '12

02 Mar '12

Version 2232 was commited by steve on 2012-03-02 21:41:18 +0000 (Fri, 02 Mar 2012) 280: nsis lang patches Spanish: Carlos D?\195?\161vila German: Henning Dutch: Minko

1 0

Location rules include
by Chris66 02 Mar '12

02 Mar '12

Hi, why is the include of the location-rules commented out in the default style ? #base-style=location Chris

2 1

[PATCH V1] Idea for minor speed improvement for boundary preprocessing
by GerdP 02 Mar '12

02 Mar '12

Hi WanMil, this was a very good hint :-) Time for african boundaries was 250 secs with /branch/performance/r2225, 267 secs with trunk, and with this patch it is now 152 secs - use simple quadtree in BoundarySaver.splitArea() - add try/catch in BoundaryPreparer.run() to allow e.g. usage of assert. Without that, an assertion was handled by the threading routines and caused program stop without any message. Please double check this, I am still not so experienced with try+catch and wrong placed Ciao, Gerd http://gis.19327.n5.nabble.com/file/n5512906/splitArea_v1.patch splitArea_v1.patch WanMil wrote > > Hi Gerd, > > boundary preprocessing takes quite a lot of time. That's not a big > problem because it's performed only by some people who publish their > results. > > But I think some speed improvements would not be bad anyhow?! > > While preprocessing asia and america I go an idea. The area of a > boundary is splitted into the raster. But each time the complete area is > intersected to the raster. In case an area is big and/or complex > (boundary of russia, USA, canada etc.) this takes a long time. It would > be possible first to cut the area into smaller pieces (columns or rows > of the raster) and then do the final cut to the raster. Maybe this saves > time because the column or row areas should be less complex. > > What do you think? > > WanMil > _______________________________________________ > 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/PATCH-V1-Idea-for-minor-speed-improvement-fo… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 4