- mkgmap-dev - The mkgmap lists

Doubt about min-size-polygon
by Nelson A. de Oliveira 10 May '14

10 May '14

Hi! I have one doubt about min-size-polygon: if using it as --min-size-polygon=8, will it probably remove house polygons from the map? Thank you! Best regards, Nelson

2 2

Commit: r3265: calm down findBugs
by svn commit 09 May '14

09 May '14

Version mkgmap-r3265 was committed by gerd on Fri, 09 May 2014 calm down findBugs

1 0

r3264 sets return code
by Gerd Petermann 09 May '14

09 May '14

Hi all, with r3264 and higher you can check the return code of mkgmap to verify that all tiles were compiled. It will now return with a non-zero rc if one of the typical problems like "There is not enough room in a single garmin map ..." occurs. See also: http://gis.19327.n5.nabble.com/Mkgmap-always-returns-exit-code-0-even-when-… You may now also check the stdout for the lines Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Gerd

1 0

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