- mkgmap-dev - The mkgmap lists

lines default style file reordering?
by Carlos Dávila 15 Jan '17

15 Jan '17

Is there any reason to have "process-exits/process-destination rules" block in lines file inserted in the middle of "Set highway names to include a reference" block? It seems a bit confusing. If there's no reason for the above, attached patch fixes it and also an small typo

2 1

Copyright & License file reader improvements
by Mike Baggaley 15 Jan '17

15 Jan '17

Hi Gerd, please find attached a small patch that improves the loading of copyright and license data when the --copyright-file and --license-file options are used. It will attempt to load the data using ANSI, UTF-8, UTF-16 and the default code page. If it fails, more information is provided as to the reason why. Please try and if happy commit. Thanks, Mike

8 22

Re: [mkgmap-dev] How to label maps generated by mkgmap -r3742
by Gerd Petermann 15 Jan '17

15 Jan '17

Hi Greg, options.txt groups options by meaning. The order of options is important in that way that you can do something like this: java -jar mkgmap.jar --style=s1 1234*.osm.pbf --description=2nd_style --style=s2 1235*.osm.pbf For the files 1234*.osm.pbf the style s1 is used and option description is "not visible", for the files 1235*.osm.pbf the style s2 is used and description is "2nd_style". This concept is broken when it comes to options like "index","gmapsupp", "tdbfile", and others which are always processed after the *.pbf files so that they always "see" the last setting of an option. I hope that makes it clearer? The file template.args is just a generated file which uses these rules, you can create your own file as well. I'll think about a hint reg. template.args. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von greg crago <gregcrago(a)gmail.com> Gesendet: Dienstag, 10. Januar 2017 17:11:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] How to label maps generated by mkgmap -r3742 I want to make sure I understand how the ORDER of the OPTIONS are to used. I was using the "options.txt" file to determine the order of the options. Is that correct? Why exactly did you recommend putting the --description AFTER the -c template.args option? Can you add a note to "options.txt" and using SPLTTER (template.args) OVERWRITES --mapname, --description, and --input-file? I have --area-name and I cannot see it anywhere in BaseCamp or my GPS. I used --x-mapeset-name=blabla and I cannot see it anywhere in BaseCamp or my GPS. Greg On Mon, Jan 9, 2017 at 10:49 PM, Gerd Petermann <gpetermann_muenchen(a)hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: The java code shows that the options area-name and mapset-name are evaluated. The latter one doesn't appear in the help file, so it is an undocumented option and you can only use it with --x-mapeset-name=blabla GMapTool shows the value, but I did not try where it appears on the device or what effect it has. Gerd greg crago wrote > Thank you. > > java ... mkgmap.jar ... -c template.args master_thin.txt --description=XYZ > --gmapsupp > > Worked on BaseCamp and on Garmin GPS. > > The only thing that would be nice would be a FAMILY description on the > GPS. > Right now, Garmin City Navigator Shows a MAPNAME and in a smaller font > another name (family name?) -- View this message in context: http://gis.19327.n8.nabble.com/How-to-label-maps-generated-by-mkgmap-r3742-… Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

5 11

Distinction between smooth paved/rough paved/unpaved streets
by Alexandre de Menezes 15 Jan '17

15 Jan '17

Hi, Here in my city there are basically 3 types of paving on streets: * Smooth paving (concrete or asphalth) * "Rough" paving (sett or paving stones) * Unpaved I have been tagging a lot of streets hoping to improve routing, but it seems to have no effect. In fact, I found the following rule: highway=residential [0x06 road_class=0 road_speed=2 resolution 22] It seems to ignore the paving type. Would be possible to assign different "road_speed" according to paving type? Thanks in advance, Alexandre

7 18

Commit r3753: Use correct new line character(s) in log messages
by svn commit 14 Jan '17

14 Jan '17

Version mkgmap-r3753 was committed by gerd on Sat, 14 Jan 2017 Use correct new line character(s) in log messages http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3753

1 0

Want to make one map from individual maps with different details
by greg crago 13 Jan '17

13 Jan '17

I noticed that Garmin City Navigator uses different thickness of linetype as you zoom out. I can create 2 different TYP files (filename.txt) to be used with my mkgmap command and still use the same style files, but I do not know how to combine these different maps and how to specify at what zoom levels each map is to be visible. Example: Zoom level 0-2 (detailed map with wide roads 'detailed.img') Zoom level 3-5 (overview map with thinner lines and some features removed 'overview.img) How exactly to I combine these 2 maps into one 'combo' map. I know the file size will double Do I use GmapTool? Greg

4 3

Multipolygon-relation with junction=roundabout
by Gerd Petermann 13 Jan '17

13 Jan '17

Hi all, while testing roundabouts4.patch I found this place: https://www.openstreetmap.org/relation/1518208 I think the relation is completely wrong, but it also causes some missleading warning messages because the mp-code creates some additional ways. I think the problem is that we have this "mop up rule" in lines: junction=roundabout [0x0c road_class=0 road_speed=1 resolution 22] I think it should be changed to junction=roundabout & highway=* [0x0c road_class=0 road_speed=1 resolution 22] What do you think about it? Gerd

2 1

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