March 2011 - mkgmap-dev - The mkgmap lists

Commit: r1884: Include the new installer directory in the build
by svn commit 06 Mar '11

06 Mar '11

Version 1884 was commited by wanmil on 2011-03-06 10:47:14 +0000 (Sun, 06 Mar 2011) Include the new installer directory in the build I forgot to commit the build.xml in r1882

1 0

Recent crashes when searching on device
by Steve Ratcliffe 06 Mar '11

06 Mar '11

Hi There have now been a few reports of problems searching on some devices with the latest version of mkgmap. It seems that it occurs when a gmapsupp.img is created directly by mkgmap and sent to the device. In other words the index itself has nothing to do with the problem, if this is correct. This is probably good news since there are not too many changes to stuff outside of the index itself. So could people confirm that when they see crashes they are not installing via mapsource, and what GPS device they are using? ..Steve

7 24

re-trying multi layer map
by maning sambale 06 Mar '11

06 Mar '11

I am creating a multi-layer map. On my test, I'm using a single osm file and I was able to create some form of hillshading effect using elevation polygons and dithering with typ: http://farm6.static.flickr.com/5298/5488803441_a65e23d54c.jpg What I want is to split the data into three layers (coastline, hillshade and osm data - pois, lines and polys). Following the advice here: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q4/009484.html I have this args file: ========== gmapsupp code-page=1252 latin1 country-abbr=PHL country-name=PHILIPPINES generate-sea=polygons,extend-sea-sectors,close-gaps=1000,land-tag=natural=coastline family-id=111 product-id=1 family-name=Map1 draw-priority=20 transparent=no mapname=10000001 input-file=coastline.osm style-file=/home/maning/routable_garmin/git/osmphgps/styles/outdoor family-id=222 product-id=1 family-name=Map2 draw-priority=25 transparent=yes mapname=20000001 input-file=elev_level.osm style-file=/home/maning/routable_garmin/git/osmphgps/styles/outdoor family-id=333 product-id=1 family-name=Map3 draw-priority=28 transparent=yes mapname=30000001 input-file=pois_lines.osm style-file=/home/maning/routable_garmin/git/osmphgps/styles/outdoor ========== But I get this error: time java -jar mkgmap.jar --read-config=args0.list java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:571) at java.util.ArrayList.get(ArrayList.java:349) at uk.me.parabola.mkgmap.reader.osm.SeaGenerator.joinWays(SeaGenerator.java:209) at uk.me.parabola.mkgmap.reader.osm.SeaGenerator.end(SeaGenerator.java:265) at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingHooksChain.java:78) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:73) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:148) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:58) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:224) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:221) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) I also tried creating the maps separately and then run another mkgmap instance, but I don't see the coastline and hillshade: time java -jar mkgmap.jar --gmapsupp --product-id=1 --family-id=111 --draw-priority=20 10000001.img COASTLINE.TYP --family-id=222 --transparent --draw-priority=25 20000001.img ELEV.TYP --family-id=333 --transparent --draw-priority=28 30000001.img The typ files have the different FID for each layer. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

2 2

Commit: r1883: Remove coast branch
by svn commit 05 Mar '11

05 Mar '11

Version 1883 was commited by wanmil on 2011-03-05 19:41:54 +0000 (Sat, 05 Mar 2011) Remove coast branch It has been merged back to trunk in r1752

1 0

Commit: r1882: MapSource installer improvements
by svn commit 05 Mar '11

05 Mar '11

Version 1882 was commited by wanmil on 2011-03-05 19:39:34 +0000 (Sat, 05 Mar 2011) MapSource installer improvements * uses family name for directory name * map can now be uninstalled from "Add/Remove Programs" (WinXP) or "Programs and Features" (Vista/Win7) * uninstalls map if already installed (NEW: silently force uninstall if silently installing) * installer and license files are now generated from templates for easier maintenance --Nakor

1 0

Commit: r1881: Add some variants of european country names to the Locator config
by svn commit 05 Mar '11

05 Mar '11

Version 1881 was commited by wanmil on 2011-03-05 16:48:21 +0000 (Sat, 05 Mar 2011) Add some variants of european country names to the Locator config

1 0

Re: [mkgmap-dev] Problems with latest splitter versions
by Michael Prinzing 05 Mar '11

05 Mar '11

On Thu, 3 Mar 2011 21:16:26 -0600, Scott Crosby wrote: >On Wed, Mar 2, 2011 at 5:36 PM, Michael Prinzing <mipri(a)gmx.net> wrote: >> I am getting the splitter from svn, compiling and running it unter >> Windows XP SP3 using JDK 1.6.0_25. There are 2 problems if I am using a >> splitter version newer than r161 (tryed until r167 so far). >> >> >> 1.) germany.osm.pbf from geofabrik cannot be split >> -------------------------------------------------- >> > >BTW, there's no need to do two passes. Unlike prior versions, this >version of the splitter will handle as many areas as you want to throw >at it. I've done 6000 at once on my 4GB ram desktop. This is a great improvement, especially on a system with only 1,7GB of RAM like mine. >Frantisek Mantlik tracked down and fixed the problem with threads=1. Yes, it is working fine now, thanks. >> 2.) File containing contour data cannot be processed >> ---------------------------------------------------- >> >> When generating my maps, I usually add data to draw contour lines. The >> file containing that data is available from >> http://osm.arndnet.de/contourdata.osm.gz (not my site!). It is in OSM >> format 0.5. >> > >> When buildig a map, I am combining this data with the OSM data (please >> note that the contour data file contains node IDs starting at 2^31, so >> they collide with the IDs from "real" OSM data if used unchanged). But >> even when I am trying to split this file without additional OSM data, >> the same as above happens and the splitter stops at the end of the >> first and only pass: > >This won't work. The splitter is written in Java, where most standard >Java classes and collections don't support indices that are 64 bits. >This means that ID's more than 2**31 are too big and will be treated >as negative by Java and blow up this code. The current array resize >logic further limits this to node ID's less than somewhere around >1,750,000,000, but I just committed a fix to trunk that I think will >extend this range to 1--1,999,999,999. You could help me find and fix >any other issues if you could supply a small file with node ID's >around 1,950,000,000. Well, there was a typo in the description in my initial post, sorry for that. The correct version is: The original file contains IDs starting with 2^30 = 1073741824. Since the beginning of this year they are colliding with the IDs OSM is assigning to new nodes, so I decided to renumber the nodes in my file. In order to have the gap between OSM IDs and my IDs as big as possible and being able to do the change by a simple search and replace, I changed the leading '1' in every node ID with a '2', so now my IDs are starting from 2073741824. The file contains about 18,000,000 nodes, so even the highest ID is less than 2^31. I thought this should be safe, and the old splitter r161 was able to process the file. I've tryed again now with the new splitter r170 and different node IDs and found the following: If the node IDs are starting at 2073741824 (= 2^30 + 1e09) there is still an exception. It happens immediately when the splitter begins to write out the data. I've posted an example yesterday, but with the new splitter there is an other exception: Exception in thread "main" java.lang.IndexOutOfBoundsException: Index (32402221) is greater than or equal to list size (31250001) at it.unimi.dsi.fastutil.objects.ObjectArrayList.get(ObjectArrayList.java:258) at uk.me.parabola.splitter.SparseInt2ShortMapInline.put(SparseInt2ShortMapInline.java:128) at uk.me.parabola.splitter.SparseInt2ShortMultiMap$Inner.put(SparseInt2ShortMultiMap.java:81) at uk.me.parabola.splitter.SparseInt2ShortMultiMap.put(SparseInt2ShortMultiMap.java:31) at uk.me.parabola.splitter.SplitProcessor.writeNode(SplitProcessor.java:209) at uk.me.parabola.splitter.SplitProcessor.processNode(SplitProcessor.java:118) at uk.me.parabola.splitter.OSMParser.endElement(OSMParser.java:243) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:57) at uk.me.parabola.splitter.Main.processMap(Main.java:399) at uk.me.parabola.splitter.Main.writeAreas(Main.java:355) at uk.me.parabola.splitter.Main.split(Main.java:188) at uk.me.parabola.splitter.Main.start(Main.java:116) at uk.me.parabola.splitter.Main.main(Main.java:105) Next try with node IDs beginning at 1773741824. Again I get an exception but this time after the splitter has written a part of the output, not immediately as above. In this time, the splitter uses an huge amount of memory, and so the exception says: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at it.unimi.dsi.fastutil.longs.LongArrays.ensureCapacity(LongArrays.java:107) at it.unimi.dsi.fastutil.longs.LongArrayList.ensureCapacity(LongArrayList.java:202) at it.unimi.dsi.fastutil.longs.LongArrayList.size(LongArrayList.java:271) at uk.me.parabola.splitter.SparseInt2ShortMapInline.resizeTo(SparseInt2ShortMapInline.java:97) at uk.me.parabola.splitter.SparseInt2ShortMapInline.put(SparseInt2ShortMapInline.java:125) at uk.me.parabola.splitter.SparseInt2ShortMultiMap$Inner.put(SparseInt2ShortMultiMap.java:81) at uk.me.parabola.splitter.SparseInt2ShortMultiMap$Inner.put(SparseInt2ShortMultiMap.java:79) at uk.me.parabola.splitter.SparseInt2ShortMultiMap.put(SparseInt2ShortMultiMap.java:31) at uk.me.parabola.splitter.SplitProcessor.writeWay(SplitProcessor.java:231) at uk.me.parabola.splitter.SplitProcessor.processWay(SplitProcessor.java:134) at uk.me.parabola.splitter.OSMParser.endElement(OSMParser.java:253) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:57) at uk.me.parabola.splitter.Main.processMap(Main.java:399) at uk.me.parabola.splitter.Main.writeAreas(Main.java:355) at uk.me.parabola.splitter.Main.split(Main.java:188) at uk.me.parabola.splitter.Main.start(Main.java:116) at uk.me.parabola.splitter.Main.main(Main.java:105) This looks like if the fix that should extend the possible range for the IDs to 1,999,999,999 does not work yet. Unfortunately it is not sufficient in this case to have just a few nodes and ways, so I cannot provide a small piece of data to reproduce it. Of course I could send you the whole file which has about 60MB in PBF format. If I am using IDs beginning at 1573741824, everything works fine (even with the same memory settings as before). For now I can assign IDs that the splitter is able to handle, but sooner or later this will be a problem. If OSM is growing like it did in the last months, it will reach node IDs of 2e09 and above pretty soon (next year). And the new version of srtm2osm is also generating node IDs from 2e09 on upwards to avoid collisions with the OSM data. While splitter r161 could handle this, it is not possible to process this data with the new splitter versions. Michael

2 1

Commit: r1880: Fix copying location attributes that were lost in the filters
by svn commit 05 Mar '11

05 Mar '11

Version 1880 was commited by wanmil on 2011-03-05 11:04:46 +0000 (Sat, 05 Mar 2011) Fix copying location attributes that were lost in the filters The MapElements copy constructor used by several filters did not copy the location attributes like street, zip etc.

1 0

Include the following patches into trunk -- Patch4 - decrease douglas peucker error
by Felix Hartmann 04 Mar '11

04 Mar '11

This is the last patch for the series. I'm not really sure if it should be applied. I don't even find out where I got this patch from. I just assumed that someone thought about writing it, and hence it provides some benefit. I really don't know whether this patch improves or degrades the map. Actually mostly wondering on what it is worth:

2 9

Recommended version?
by NopMap 04 Mar '11

04 Mar '11

Hi! I'm packing an update of my beginners' tool set and so I am here with my ususal question: Which version of mkgamp would you recommend as reliable? The Wiki states 1625, which appears a little bit dated. However, from this list I gather that quite a lot is going on at them moment so the latest build might not be the best idea. So which version would you recommend as most reliable? bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Recommended-version-tp6087673p6087673.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 6