January 2017 - mkgmap-dev - The mkgmap lists

Splitter abort with error starting from v560, with v571 command line and abort error
by Ataro 12 Jan '17

12 Jan '17

The last splitter version that i have in my archive, working on my overpass osm data file, is v.441. C:\Users\UTENTE\Documents\OSM Map\Scripts>"C:\Program Files"\Java\jre1.8.0_111\bin\java -enableassertions -Xmx8192M -jar ..\splitter-r441\splitter.jar --mapid=69010001 src\AN.osm --mixed --output=pbf --keep-complete=false --max-nodes=1200000 --polygon-file=bounds.poly Splitter version 441 compiled 2016-11-17T07:05:46+0000 boundary-tags=use-exclude-list cache= description= geonames-file= handle-element-version=remove ignore-osm-bounds=false keep-complete=false mapid=69010001 max-areas=512 max-nodes=1200000 max-threads=4 (auto) mixed=true no-trim=false num-tiles= output=pbf output-dir= overlap=auto polygon-desc-file= polygon-file=bounds.poly precomp-sea= problem-file= problem-report= resolution=13 search-limit=200000 split-file= status-freq=120 stop-after=dist wanted-admin-level=5 write-kml= Setting default overlap=2000 because keep-complete=false is in use. Parameter --boundaryTags is ignored, because parameter --keep-complete=false is used Elapsed time: 0s Memory: Current 123MB (5MB used, 118MB free) Max 7282MB Time started: Thu Jan 12 17:02:22 CET 2017 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units (0.0439453125 degrees) - areas are multiples of 0x800 map units wide and high Processing src\AN.osm in 1 file Time: Thu Jan 12 17:02:26 CET 2017 Exact map coverage read from input file(s) is (42.5299859046936,10.78831672668457) to (46.02988243103027,13.729734420776367) Exact map coverage after applying bounding box of polygon-file is (42.5299859046936,10.78831672668457) to (46.02988243103027,13.729734420776367) Rounded map coverage is (42.4951171875,10.7666015625) to (46.0546875,13.7548828125) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... splitting bounds Highest node count in a single grid element is 33.957 Highest node count in a single grid element within the bounding polygon is 33.957 Trying to find nice split for (42.4951171875,10.7666015625) to (46.0546875,13.7548828125) with 2.953.923 nodes searching for split with min-nodes 60000, learned 0 good partial solutions Best solution until now: 4 tile(s). The smallest node count is 550399 (45 %), the worst aspect ratio is near 3.48, elapsed search time: 0 s searching for split with min-nodes 605438, learned 0 good partial solutions Best solution until now: 4 tile(s). The smallest node count is 685592 (57 %), the worst aspect ratio is near 3.38, elapsed search time: 0 s searching for split with min-nodes 853992, learned 1 good partial solutions Best solution until now: 3 tile(s). The smallest node count is 857577 (71 %), the worst aspect ratio is near 2.06, elapsed search time: 0 s searching for split with min-nodes 1072705, learned 0 good partial solutions searching for split with min-nodes 965141, learned 0 good partial solutions searching for split with min-nodes 911359, learned 0 good partial solutions Best solution until now: 3 tile(s). The smallest node count is 918015 (76 %), the worst aspect ratio is near 1.95, elapsed search time: 0 s searching for split with min-nodes 982712, learned 0 good partial solutions searching for split with min-nodes 950363, learned 0 good partial solutions searching for split with min-nodes 934189, learned 0 good partial solutions searching for split with min-nodes 926102, learned 0 good partial solutions searching for split with min-nodes 922058, learned 0 good partial solutions searching for split with min-nodes 920036, learned 0 good partial solutions searching for split with min-nodes 919025, learned 0 good partial solutions searching for split with min-nodes 918016, learned 0 good partial solutions Solution is nice. Can't find a better solution with search-limit 200000: 3 tile(s). The smallest node count is 918015 (76 %), the worst aspect ratio is near 1.95 Trying to cut the areas so that they fit into the polygon ... Area 69010001 covers (43.3740234375,10.7666015625) to (46.0546875,13.7548828125) and contains 1103171 nodes (91 %) Area 69010002 covers (42.4951171875,13.095703125) to (43.3740234375,13.7548828125) and contains 918015 nodes (76 %) Area 69010003 covers (42.4951171875,10.7666015625) to (43.3740234375,13.095703125) and contains 932737 nodes (77 %) Creating the initial areas took 62 ms 3 areas: Area 69010001: 2021376,501760 to 2146304,641024 covers (0x1ed800,0x7a800) to (0x20c000,0x9c800) Area 69010002: 1980416,610304 to 2021376,641024 covers (0x1e3800,0x95000) to (0x1ed800,0x9c800) Area 69010003: 1980416,501760 to 2021376,610304 covers (0x1e3800,0x7a800) to (0x1ed800,0x95000) cached 2 combinations of areas that form rectangles. WriterGridTree [512][512] for grid area (42.45220184326172,10.723686218261719) to (46.09760284423828,13.797798156738281) requires max. 3 checks for each node (0 sub grid(s)) Grid(s) created in 31 ms Writing temp files took 0 ms Distributing data Thu Jan 12 17:02:26 CET 2017 Processing 3 areas in a single pass SparseLong2ShortMapHuge: Allocating three-tier structure to save area info (HashMap->vector->chunkvector) SparseLong2ShortMapHuge: Allocating three-tier structure to save area info (HashMap->vector->chunkvector) Starting distribution pass 1 of 1, processing 3 areas (69010001 to 69010003) Processing src\AN.osm Writing ways Thu Jan 12 17:02:30 CET 2017 Writing relations Thu Jan 12 17:02:33 CET 2017 coord Map: Number of stored ids: 2.953.923 require ca. 200.6 bytes per pair. 496272 chunks are used, the avg. number of values in one 64-chunk is 5. coord Map details: bytes/overhead 5.106.352 / 587.480.072, overhead includes 35 arrays with 16 MB way Map: Number of stored ids: 234.985 require ca. 290.56 bytes per pair. 92162 chunks are used, the avg. number of values in one 64-chunk is 2. way Map details: bytes/overhead 938.904 / 67.338.520, overhead includes 4 arrays with 16 MB JVM Memory Info: Current 1169MB (674MB used, 495MB free) Max 7282MB Full Node tests: 113.863 Quick Node tests: 3.209.154 Thread worker-0 has finished Thread worker-1 has finished Thread worker-2 has finished Distribution pass(es) took 7055 ms Time finished: Thu Jan 12 17:02:33 CET 2017 Total time taken: 11s The first not working version that i've is v. 560, and all the following versions all abort execution as the following v.571 C:\Users\UTENTE\Documents\OSM Map\Scripts>"C:\Program Files"\Java\jre1.8.0_111\bin\java -enableassertions -Xmx8192M -jar ..\splitter-r571\splitter.jar --mapid=69010001 src\AN.osm --mixed --output=pbf --keep-complete=false --max-nodes=1200000 --polygon-file=bounds.poly Splitter version 571 compiled 2017-01-12T15:17:15+0000 boundary-tags=use-exclude-list cache= description= geonames-file= handle-element-version=remove ignore-osm-bounds=false keep-complete=false mapid=69010001 max-areas=2048 max-nodes=1200000 max-threads=4 (auto) mixed=true no-trim=false num-tiles= output=pbf output-dir= overlap=auto polygon-desc-file= polygon-file=bounds.poly precomp-sea= problem-file= problem-report= resolution=13 search-limit=200000 split-file= status-freq=120 stop-after=dist wanted-admin-level=5 write-kml= Setting default overlap=2000 because keep-complete=false is in use. Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.splitter.Main.readArgs(Main.java:436) at uk.me.parabola.splitter.Main.start(Main.java:93) at uk.me.parabola.splitter.Main.main(Main.java:79) There is a problem in the last splitter versions. --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

1 0

Splitter abort with error starting from v560
by Ataro 12 Jan '17

12 Jan '17

The last splitter version that i have in my archive, working on my overpass osm data file, is v.441. C:\Users\UTENTE\Documents\OSM Map\Scripts>"C:\Program Files"\Java\jre1.8.0_111\bin\java -enableassertions -Xmx8192M -jar ..\splitter-r441\splitter.jar --mapid=69010001 src\AN.osm --mixed --output=pbf --keep-complete=false --max-nodes=1200000 --polygon-file=bounds.poly Splitter version 441 compiled 2016-11-17T07:05:46+0000 boundary-tags=use-exclude-list cache= description= geonames-file= handle-element-version=remove ignore-osm-bounds=false keep-complete=false mapid=69010001 max-areas=512 max-nodes=1200000 max-threads=4 (auto) mixed=true no-trim=false num-tiles= output=pbf output-dir= overlap=auto polygon-desc-file= polygon-file=bounds.poly precomp-sea= problem-file= problem-report= resolution=13 search-limit=200000 split-file= status-freq=120 stop-after=dist wanted-admin-level=5 write-kml= Setting default overlap=2000 because keep-complete=false is in use. Parameter --boundaryTags is ignored, because parameter --keep-complete=false is used Elapsed time: 0s Memory: Current 123MB (5MB used, 118MB free) Max 7282MB Time started: Thu Jan 12 17:02:22 CET 2017 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units (0.0439453125 degrees) - areas are multiples of 0x800 map units wide and high Processing src\AN.osm in 1 file Time: Thu Jan 12 17:02:26 CET 2017 Exact map coverage read from input file(s) is (42.5299859046936,10.78831672668457) to (46.02988243103027,13.729734420776367) Exact map coverage after applying bounding box of polygon-file is (42.5299859046936,10.78831672668457) to (46.02988243103027,13.729734420776367) Rounded map coverage is (42.4951171875,10.7666015625) to (46.0546875,13.7548828125) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... splitting bounds Highest node count in a single grid element is 33.957 Highest node count in a single grid element within the bounding polygon is 33.957 Trying to find nice split for (42.4951171875,10.7666015625) to (46.0546875,13.7548828125) with 2.953.923 nodes searching for split with min-nodes 60000, learned 0 good partial solutions Best solution until now: 4 tile(s). The smallest node count is 550399 (45 %), the worst aspect ratio is near 3.48, elapsed search time: 0 s searching for split with min-nodes 605438, learned 0 good partial solutions Best solution until now: 4 tile(s). The smallest node count is 685592 (57 %), the worst aspect ratio is near 3.38, elapsed search time: 0 s searching for split with min-nodes 853992, learned 1 good partial solutions Best solution until now: 3 tile(s). The smallest node count is 857577 (71 %), the worst aspect ratio is near 2.06, elapsed search time: 0 s searching for split with min-nodes 1072705, learned 0 good partial solutions searching for split with min-nodes 965141, learned 0 good partial solutions searching for split with min-nodes 911359, learned 0 good partial solutions Best solution until now: 3 tile(s). The smallest node count is 918015 (76 %), the worst aspect ratio is near 1.95, elapsed search time: 0 s searching for split with min-nodes 982712, learned 0 good partial solutions searching for split with min-nodes 950363, learned 0 good partial solutions searching for split with min-nodes 934189, learned 0 good partial solutions searching for split with min-nodes 926102, learned 0 good partial solutions searching for split with min-nodes 922058, learned 0 good partial solutions searching for split with min-nodes 920036, learned 0 good partial solutions searching for split with min-nodes 919025, learned 0 good partial solutions searching for split with min-nodes 918016, learned 0 good partial solutions Solution is nice. Can't find a better solution with search-limit 200000: 3 tile(s). The smallest node count is 918015 (76 %), the worst aspect ratio is near 1.95 Trying to cut the areas so that they fit into the polygon ... Area 69010001 covers (43.3740234375,10.7666015625) to (46.0546875,13.7548828125) and contains 1103171 nodes (91 %) Area 69010002 covers (42.4951171875,13.095703125) to (43.3740234375,13.7548828125) and contains 918015 nodes (76 %) Area 69010003 covers (42.4951171875,10.7666015625) to (43.3740234375,13.095703125) and contains 932737 nodes (77 %) Creating the initial areas took 62 ms 3 areas: Area 69010001: 2021376,501760 to 2146304,641024 covers (0x1ed800,0x7a800) to (0x20c000,0x9c800) Area 69010002: 1980416,610304 to 2021376,641024 covers (0x1e3800,0x95000) to (0x1ed800,0x9c800) Area 69010003: 1980416,501760 to 2021376,610304 covers (0x1e3800,0x7a800) to (0x1ed800,0x95000) cached 2 combinations of areas that form rectangles. WriterGridTree [512][512] for grid area (42.45220184326172,10.723686218261719) to (46.09760284423828,13.797798156738281) requires max. 3 checks for each node (0 sub grid(s)) Grid(s) created in 31 ms Writing temp files took 0 ms Distributing data Thu Jan 12 17:02:26 CET 2017 Processing 3 areas in a single pass SparseLong2ShortMapHuge: Allocating three-tier structure to save area info (HashMap->vector->chunkvector) SparseLong2ShortMapHuge: Allocating three-tier structure to save area info (HashMap->vector->chunkvector) Starting distribution pass 1 of 1, processing 3 areas (69010001 to 69010003) Processing src\AN.osm Writing ways Thu Jan 12 17:02:30 CET 2017 Writing relations Thu Jan 12 17:02:33 CET 2017 coord Map: Number of stored ids: 2.953.923 require ca. 200.6 bytes per pair. 496272 chunks are used, the avg. number of values in one 64-chunk is 5. coord Map details: bytes/overhead 5.106.352 / 587.480.072, overhead includes 35 arrays with 16 MB way Map: Number of stored ids: 234.985 require ca. 290.56 bytes per pair. 92162 chunks are used, the avg. number of values in one 64-chunk is 2. way Map details: bytes/overhead 938.904 / 67.338.520, overhead includes 4 arrays with 16 MB JVM Memory Info: Current 1169MB (674MB used, 495MB free) Max 7282MB Full Node tests: 113.863 Quick Node tests: 3.209.154 Thread worker-0 has finished Thread worker-1 has finished Thread worker-2 has finished Distribution pass(es) took 7055 ms Time finished: Thu Jan 12 17:02:33 CET 2017 Total time taken: 11s The first not working version that i've is v. 560, and all the following versions all abort execution as the following v.571 Splitter version 571 compiled 2017-01-12T15:17:15+0000 boundary-tags=use-exclude-list cache= description= geonames-file= handle-element-version=remove ignore-osm-bounds=false keep-complete=false mapid=69010001 max-areas=2048 max-nodes=1200000 max-threads=4 (auto) mixed=true no-trim=false num-tiles= output=pbf output-dir= overlap=auto polygon-desc-file= polygon-file=bounds.poly precomp-sea= problem-file= problem-report= resolution=13 search-limit=200000 split-file= status-freq=120 stop-after=dist wanted-admin-level=5 write-kml= Setting default overlap=2000 because keep-complete=false is in use. Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.splitter.Main.readArgs(Main.java:436) at uk.me.parabola.splitter.Main.start(Main.java:93) at uk.me.parabola.splitter.Main.main(Main.java:79) There is a problem in the last splitter versions. --- Questa e-mail è stata controllata per individuare virus con Avast antivirus. https://www.avast.com/antivirus

1 0

Commit r3751: cleanup + reformatting, no functional change
by svn commit 12 Jan '17

12 Jan '17

Version mkgmap-r3751 was committed by gerd on Thu, 12 Jan 2017 cleanup + reformatting, no functional change http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3751

1 0

Commit r3750: copyrightread3.patch by Mike Baggaley
by svn commit 12 Jan '17

12 Jan '17

Version mkgmap-r3750 was committed by gerd on Thu, 12 Jan 2017 copyrightread3.patch by Mike Baggaley - document that licence file and copyright file have to be in utf-8 - issue better error message in case they are not - allow to use variables in the file, use --help=options for details http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3750

1 0

New code for splitting polygon
by Ticker Berkin 12 Jan '17

12 Jan '17

Hi Gerd I've written some new code for splitting polygons in an efficient manner. The main interface takes a shape and line of latitude or longitude and returns 2 lists of shapes on either side of the line. There is also a function to clip to rectangle. I've put the code in util/ShapeSplitter but it could go elsewhere if you prefer. So far I've only converted build/MapArea to use it, but I think it can be used throughout eventually. For the moment I've commented out the old code in MapArea, but this can be deleted in a while. Regards Ticker

2 8

type=through_route relations and mkgmap r3743
by Gerd Petermann 12 Jan '17

12 Jan '17

Hi all, I've noticed that mkgmap still checks these relations for correctness but they have no influence on the created map. Part of the code that handled them was removed with r3649: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3649 If your map was created with r3743 or later, please check if you find a crossing with such a relation which where routing hints are wrong. In that case I would try to add code for the support, else some unused code can be removed. Gerd

5 16

Commit r3743: Reduce rounding error when saving initial heading in compacted format
by svn commit 12 Jan '17

12 Jan '17

Version mkgmap-r3743 was committed by gerd on Sun, 08 Jan 2017 Reduce rounding error when saving initial heading in compacted format http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3743

4 8

Commit r3748: AngleChecker: Reduce rounding error when calculating initial heading in compacted format (same problem as in RouteNode)
by svn commit 12 Jan '17

12 Jan '17

Version mkgmap-r3748 was committed by gerd on Thu, 12 Jan 2017 AngleChecker: Reduce rounding error when calculating initial heading in compacted format (same problem as in RouteNode) patch by Andrzej Popowski (modified) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3748

1 0

3746 mkgmap
by Steve Sgalowski 12 Jan '17

12 Jan '17

with this patch there is a problem with routing in australia / queensland not shure if isolated or not , but when I live on moggill rd Pinjarra hills , and there is Pinjarra road behind me jus 400 m through the bush , it does not ever come off , the preferrd route , to the route you are driving . Stephen

2 2

Splitter r570
by Gerd Petermann 11 Jan '17

11 Jan '17

Hi all, I've merged the junit branch and the memory_opt2 branch into trunk. There are no changes in the user interface. The unit test framework was changed to junit (as with mkgmap), but this is only important for developers of splitter. A new ant target run.func-tests performs some functional tests. I'll add more in the next days. The major improvements from the memory_opt2 branch: - a smaller memory footprint, esp. when splitting large files like europe or planet with a rather small --max-nodes value - still you'll see thesame or slightly better throughput compared to r560 Some numbers; Split planet with --max-nodes=1000000 The stats after Problem-list-generator : r560: coord Map: 3.670.470.372 stored long/int pairs require ca. 1.0 bytes per pair. 67931848 chunks are used, the avg. number of values in one 64-chunk is 54. coord Map details: bytes ~3.523 MB, including 35 array(s) with 8 MB way Map: 385.087.014 stored long/int pairs require ca. 1.15 bytes per pair. 7019031 chunks are used, the avg. number of values in one 64-chunk is 54. way Map details: bytes ~423 MB, including 4 array(s) with 8 MB Problem-list-generator pass(es) took 879042 ms r:570: coord Map: 3.670.470.372 stored long/int pairs require ca. 0.48 bytes per pair. 67931848 chunks are used, the avg. number of values in one 64-chunk is 54. coord Map details: bytes ~1.710 MB, including 35 array(s) with 8 MB way Map: 385.087.014 stored long/int pairs require ca. 0.75 bytes per pair. 7019031 chunks are used, the avg. number of values in one 64-chunk is 54. way Map details: bytes ~276 MB, including 4 array(s) with 8 MB ... Problem-list-generator pass(es) took 829059 ms

1 0