May 2014 - mkgmap-dev - The mkgmap lists

Problem with barrier=gate and access=no
by Nelson A. de Oliveira 09 May '14

09 May '14

Hi! I am creating a local map with mkgmap (r3262), with the default style and the following relevant options: --add-pois-to-areas \ --add-pois-to-lines \ --adjust-turn-headings \ --check-roundabout-flares \ --check-roundabouts \ --code-page=1252 \ --drive-on-right \ --gmapsupp \ --housenumbers \ --index \ --latin1 \ --levels=0:24,1:22,2:20,3:18,4:16,5:14 \ --location-autofill=is_in,nearest \ --make-poi-index \ --merge-lines \ --min-size-polygon=8 \ --name-tag-list=int_name,name,alt_name \ --poi-address \ --pois-to-areas-placement="entrance=main;entrance=yes;building=entrance" \ --polygon-size-limits=24:12,18:10,16:8,12:4,10:0 \ --preserve-element-order \ --process-destination \ --process-exits \ --reduce-point-density=3 \ --reduce-point-density-polygon=8 \ --remove-short-arcs \ --report-dead-ends \ --report-similar-arcs \ --route >From what I see at points (from the default style), we have: barrier=gate { add mkgmap:bicycle=yes; add mkgmap:foot=yes; addaccess no; set mkgmap:road-speed=0; } If I properly understand this, by default we will have an access=no for vehicles when it finds a barrier=gate (and it should have the same effect where we have barrier=gate + access=no). But I am seeing an user saying that on places where there are barrier=gate + acess=no (like this node http://www.openstreetmap.org/node/2702166795) his GPS Garmin nüvi 40 is still routing him through this way (while OSRM properly understands the acess restriction). How can I verify if mkgmap is properly creating a restriction on barriers that have acess=no, please? (I don't own a Garmin to test, just in case) Thank you! Best regards, Nelson

3 3

Commit: r3264: apply rc-and-logging-v2.patch : set return code 1 if map creation failed
by svn commit 09 May '14

09 May '14

Version mkgmap-r3264 was committed by gerd on Fri, 09 May 2014 apply rc-and-logging-v2.patch : set return code 1 if map creation failed It also changes the handling of so called MapFailedExceptions like "There is not enough room in a single garmin map..." or "Overflow of the NET1. The tile ..." These messages are now printed as severe messages via the logging system (showing the input file): Severe (MapFailedException): \ld_sp\63240003.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. The stdout contains two new messages: Number of MapFailedExceptions: 3 Number of ExitExceptions: 0 If any of the two shows a non-zero value, the program exits with return code 1.

1 0

Commit: r3263: Performance: create a polygon in MultipolygonRelation processing only if required and reuse it - no functional change.
by svn commit 08 May '14

08 May '14

Version mkgmap-r3263 was committed by wanmil on Thu, 08 May 2014 Performance: create a polygon in MultipolygonRelation processing only if required and reuse it - no functional change.

1 0

finalize and some ways with overlays
by Bernd Weigelt 08 May '14

08 May '14

Hi i have a problem, that the finalize section to often calls inc/access, in my case for every overlay and the routable way. IMHO it should call it only for the routable way(s) with road_speed and road_class. an example lines: highway=cycleway [0x1200a resolution 23-23 continue] highway=cycleway [0x1100a resolution 24 continue] highway=cycleway [0x0a resolution 24 road_class=0 road_speed=1] <finalize> # The finalizer section is executed for each element when a rule with an element type matches # calculate the access rules include 'inc/access' ; ------ inc/access includes for testing some ways this additional test highway=* & bicycle=official { echo ' 1 ${highway} | ${bicycle} | ${mkgmap:bicycle} ' } output for this way http://www.openstreetmap.org/way/243198140 .... 243198140: 1 cycleway | official | null 243198140: 1 cycleway | official | null 243198140: 1 cycleway | official | null .. How can i fix this? Or is there something wrong in my style? Bernd

3 3

problem with address search and --code-page
by Michał Rogala 08 May '14

08 May '14

Hi! I'm creating 2 types of maps (covering Poland): - regular map (default code-page) - localized map (code-page 1250) first map is here: http://garmin.osmapa.pl/mapy/OSMapaPL-20140120V1.29_IMG.zip second map is here: http://garmin.osmapa.pl/mapy/OSMapaPL-OGONKI-20140120V1.29_IMG.zip problem is: map with code-page 1250 works well - I can search for any address - MapSource and GPSMap device show it. map without code-page 1250 (default setting) has incomplete index - I can't search for almost any street (only a few available, no housenumber search). One example is: City: Warszawa Street: Aleje Jerozolimskie Housenumber: 91 with --code-page=1250 I can find this address, without --code-page=1250 I can't. No regional characters are involved in this street name. Do you have any idea why this happens? I use mkgmap-r2998, r2979 had the same problem. No difference if I use --lower-case or not. My mkgmap arguments: --verbose --family-name=OSMapaPL --description=OSMapaPL --series-name=OSMapaPL --coastlinefile=./coastlines_europe.osm.pbf --read-config=./config/osmapa.config --bounds=./bounds --family-id=004 --product-id=004 --mapname=66004001 --overview-mapname=66004000 --style-file=./resources/styles/ --style=mapa --check-styles config file is: verbose max-jobs country-name=Polska name-tag-list=name:pl,name generate-sea location-autofill=is_in,nearest tdbfile index add-pois-to-areas link-pois-to-ways remove-short-arcs preserve-element-order country-abbr=POL route net gmapsupp nsis check-styles process-exits process-destination housenumbers overview-mapnumber=66007001 overview-levels=6:16,7:15 best regards Michał Rogala

3 44

splitter r325: improved split algo and new option
by Gerd Petermann 08 May '14

08 May '14

Hi all, I've applied num-tiles-v1.patch and improved the split algo, see http://gis.19327.n5.nabble.com/mkgmap-ToDo-list-tp5803388p5805165.html It is now less likely that splitter creates tiles with a low number of nodes, it is more likely that all tiles have nearly the same number of nodes, and typically you will see fewer tiles. Maybe this also means that you can increase the max-nodes value. I hope this also reduces the need for complex interactions between spltter and mkgmap. Gerd

6 17

Building vs way in default style
by Stéphane MARTIN 07 May '14

07 May '14

Hi all, I don't know if it's an issue... A map compiled with the default style gives a not very nice rendering for "Barrage Vauban" in Strasbourg (identifier 40 217 747 in OSM). https://tuxdomain.darktech.org/osm-garmin/view.php?file=France/Barrage_Vaub… Building is not rendered. Just the way. And there are bits of building on the banks. Priority problem in the style ? NB : building isn't correctly tagged (building=bridge would be a better tag). Steph

5 10

[Patch v2] set program return code and improve logging
by Gerd Petermann 07 May '14

07 May '14

Hi all, attached is version 2 of the patch. Changes to v1: - change Main.main to Main.mainStart() which returns an int - let Main.main call mainStart() and use System.exit(1) in case of errors - let unit tests call Main.mainNoSystemExit() which doesn't call System.exit(). - synchronized -> volatile for access of field programRC For version 1 see http://gis.19327.n5.nabble.com/Patch-v1-set-program-return-code-and-improve… If I hear no complains I'll commit it on friday. Gerd

1 0

[Patch v1] set program return code and improve logging
by Gerd Petermann 07 May '14

07 May '14

Hi all, attached is a patch the should set program return code to 1 in case of severe errors. It also changes the handling of so called MapFailedExceptions like "There is not enough room in a single garmin map..." or "Overflow of the NET1. The tile ..." These messages are now printed as severe messages via the logging system (showing the input file): Severe (MapFailedException): \ld_sp\63240003.o5m: (thrown in BufferedImgFileWriter.ensureSize()) There is not enough room in a single garmin map for all the input data. The .osm file should be split into smaller pieces first. The stdout contains two new messages: Number of MapFailedExceptions: 3 Number of ExitExceptions: 0 If any of the two shows a non-zero value, the program exits with return code 1. @WanMil, Steve: Please review. In Main.java I use "synchronized" to make sure that concurrent updates are handled. The System.exit() method is only used if the program is not called from another java program. The code In MapFailedException.log() tries to determine the code that caused the Exception. I hope this works in all environments? Gerd

3 5

Commit: r3262: small performance improvements: use compiled tags in a few more places
by svn commit 07 May '14

07 May '14

Version mkgmap-r3262 was committed by gerd on Wed, 07 May 2014 small performance improvements: use compiled tags in a few more places

1 0