March 2017 - mkgmap-dev - The mkgmap lists

Commit r3842: Improve ResidentialHook / BoundaryQuadTree: suppress misleading warnings about overlapping admin_level=11 boundaries
by svn commit 09 Apr '18

09 Apr '18

Version mkgmap-r3842 was committed by gerd on Sat, 11 Mar 2017 Improve ResidentialHook / BoundaryQuadTree: suppress misleading warnings about overlapping admin_level=11 boundaries http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3842

8 15

POI indexing, problem with label 0x2800
by Andrzej Popowski 02 May '17

02 May '17

Hi, POI types 0x28xx are usually treated as labels, there is no icon for these POIs, only label text. CGPSMapper doc describe these POI as "Region name". I'd like to use these POI for house numbers. Problem is, that mkgmap indexes labels! It results in big increment of img files and index file. I doubt these objects are searchable, probably all this indexing is only a waste of space. I have found code in MdrUtils.java, which adds labels to index. I think this can be removed. And maybe you can add POIs in range 0x64xx - 0x66xx, they probably are searchable. There is an increase in LBL subfile, I haven't found code responsible for this. There seems to be a section LBL5 called "POI index", maybe labels goes there too? -- Best regards, Andrzej

5 15

max-nodes in splitter
by Jakob Mühldorfer 01 Apr '17

01 Apr '17

Hi, I tried to read all the docs and forums about max-nodes, but I still have questions left: * Does the splitter print an error when max-nodes is too large, or is it unpredictable and will it only fail on the GPS device * Do tiles with more nodes mean higher or lower draw performance on devices, or not matter at all Thank you for your help Jakob

5 19

AssertionError with custom style and --housenumbers
by Carlos Dávila 01 Apr '17

01 Apr '17

I'm getting the error below compiling a single tile with the following command: java -Xmx2500m -ea -jar mkgmap.jar --output-dir=./tmp --bounds=bounds.zip --precomp-sea=sea.zip --max-jobs --route --latin1 --code-page=1252 --index --housenumbers --style=truck 55139114.o5m java.lang.AssertionError at uk.me.parabola.imgfmt.app.net.RoadIndex.write(RoadIndex.java:45) at uk.me.parabola.imgfmt.app.net.RoadDef.writeLevelDivs(RoadDef.java:361) at uk.me.parabola.imgfmt.app.net.RoadDef.writeNet1(RoadDef.java:230) at uk.me.parabola.imgfmt.app.net.NETFile.write(NETFile.java:66) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:263) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:107) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:263) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:259) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Removing --housenumbers tile compiles fine. What is causing the error is the absence of the following rule in lines file: # Mop up any unrecognised highway types highway=* & area!=yes [0x07 road_class=0 road_speed=0 resolution 23] Input data: http://alternativaslibres.org/files/tmp/55139114.o5m

3 6

[Patch v3] reduce peak memory usage for global index
by Gerd Petermann 01 Apr '17

01 Apr '17

Hi all, the attached patch is a further optimization. Peak memory for --x-split-name-index is now ~ 57% of r3873, without it ~47 % compared to r3873. The run time is a bit better and the unit tests are passed again. I've removed the debug reports for now, so that this patch is ready for commit. A binary is here: http://files.mkgmap.org.uk/download/343/mkgmap.jar Worth to mention: The --x-split-name-index option requires a lot more memory in my test sample with only 51 tiles I see 250 MB instead of 101MB (437 instead of 214 with r3873), so the relative increase for the option is even higher with the patch. A lot of the memory is required to store so called sort keys. Those are created from the street name(s). A possible alternative would be to calculate the keys only only when required. This would increase run time for sorting but should keep memory much lower. I'll experiment with this later. Gerd

1 1

[Patch v1] reduce peak memory usage for global index
by Gerd Petermann 01 Apr '17

01 Apr '17

Hi all, attached is a patch which seems to help without changing the output of mkgmap. Compared to r3873 I see ~ 33% less memory usage when used with --x-split-name-index and ~50% less without it. Runtimes were similar. Actual numbers depend on the style and the used options. A binary based on 3873 is here: http://files.mkgmap.org.uk/download/341/mkgmap.jar It consists of different changes, each of them maybe used independently: 1) always release memory for mdr19, not only if it was filled for the device. 2) check if sort key has zero length, if yes, don't allocate new buffer 3) don't use MultiSortKey for mdr7 if --x-split-name-index is not used 4) count occurences of the generated key strings, cache sort keys for those keys which occur more than 3 times. 5) create smaller copy of byte array if number of allocated bytes was too high @Steve: Please review, I think 1-4 are okay, 5) may cause problems if my understanding of Sort.fillkey() is wrong. I was also surprised to see that we require such long sort keys, even with --latin1. I see many 0 bytes in the created keys, maybe that can be optimized further? Gerd

2 2

[Partch v2] reduce peak memory usage for global index
by Gerd Petermann 30 Mar '17

30 Mar '17

Hi all, attached is an improved version which also implements the new option --x-mdr7-excl. It also has some debug messages which will print Strings which appear very often, something like this: Street index (Mdr7) 'Service' : 11.09% Street index (Mdr7) 'Straße' : 7.09% Street index (Mdr7) 'CyW' : 1.66% Street index (Mdr7) 'Pth' : 3.81% Street index (Mdr7) 'Weg' : 1.13% Street index (Mdr7) 'Foot' : 9.17% Street index (Mdr7) 'Steps' : 1.58% (sample from Arndts "Speichenkarte" style which adds osm tags to the street name. The idea is to use Option --x-mdr7-excl="Service,Straße,Foot,Pth" to exclude some strings from the global index. This will esp. reduce heap memory usage , but it will also reduce the size of the index. The search will still find roads like "Abc Straße" when you search for abc, but it will not display all the streets containing Straße when you just type Straße. It should also still display "Straße des 17. Juni" if you type "Straße des" or just "Juni" in case you use --x-split-name-index. The binary is here: http://files.mkgmap.org.uk/download/342/mkgmap.jar Gerd

3 5

undocumented contour line feature
by Gerd Petermann 30 Mar '17

30 Mar '17

Hi all, mkgmap contains sources to generate contour lines from SRTM data, but it seems to be very incomplete. The last significant changes in the source was in 2010, and I never heard that anybody uses options like --x-contours since I started to contribute to mkgmap. See also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q3/002581.html I'd like to either remove the code completely or mayve make it work if you think that it would be better to have the code in mkgmap instead of a separate package like phyghtmap. Does anybody remember why it is not documented? Gerd

8 24

Commit r3873: reduce peak memory a bit: release memory for OverviewBuilder before creating indexes
by svn commit 30 Mar '17

30 Mar '17

Version mkgmap-r3873 was committed by gerd on Thu, 30 Mar 2017 reduce peak memory a bit: release memory for OverviewBuilder before creating indexes The only needed information after writing the overview map is the bounding box. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3873

1 0

Re: [mkgmap-dev] splitter-related problem: invocation of split
by philip dellafera 29 Mar '17

29 Mar '17

Hi Gerd, Hi all [Problem solved] Thanks for the tip:: starting split IN the splitter-directory hierarchy did the trick. The programme works well now (as I had suspected it would). Perhaps one should clearly indicate this fact on the internet pages (did I overread it or isn't it there?? anyhow, I'm not pointing fingers, as it might be toward myself). Can't one solve the problem in the long run via (global) variables?? Anyhow, huge thanks for the help Happy Map-Splitter Philip -- Dr. Philip Dellafera Weinbergblick 9 79395 Neuenburg am Rhein Tel.: +49 (0)7635 827 4687 email: pd8554mb01(a)t-online.de

1 0