- mkgmap-dev - The mkgmap lists

intermittent waterways
by Minko 15 Mar '16

15 Mar '16

Hi On the osm forum a request was made to render intermittent waterways, see http://forum.openstreetmap.org/viewtopic.php?id=53986 We can add this code before the waterway lines in the default style (default/inc/water_lines): (waterway=river | waterway=canal) & intermittent=yes [0x26 resolution 20] (waterway=stream | waterway=drain) & intermittent=yes [0x10A02 resolution 22]

2 2

Oneway 1 or -1 BUG?
by nwillink 14 Mar '16

14 Mar '16

I have a suspicion that mkgmap quite understandably (!) parses oneway=-1 as oneway=yes and oneway=1 as reverse (ie arrows reversed) . However, for some unknown reason , osm defines oneway=-1 as meaning 'reverse arrows' and uses oneway=1 to mean 'oneway=yes'. In other words, mkgmap , when parsing lines,creates the opposite effect to what is implied in osm. This matters when you create a separate line types for each condition. Not a problem , just a small observation. -- View this message in context: http://gis.19327.n5.nabble.com/Oneway-1-or-1-BUG-tp5869847.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

mkgmap creates bad mapset, when input files aren't sorted
by popej 13 Mar '16

13 Mar '16

Hi, I'm trying to bypass some weird filtering by my email provider, so please forgive me if this report comes duplicated. Following command produce good mapset for Mapsource: > mkgmap --code-page=1252 --route --index --bounds=bounds 29624847.osm.pbf 29624849.osm.pbf 29624850.osm.pbf This command creates bad mapset: > mkgmap --code-page=1252 --route --index --bounds=bounds 29624849.osm.pbf 29624847.osm.pbf 29624850.osm.pbf The only difference is changed order of input pbf files. Bad mapset crashes Mapsource, when trying to send map to GPS. Mapsource gives information about error in MDR_TRIM_ADDR.CXX, which suggest mapset index. I have compared output files for both compilation. Index *_mdr.img is very different. Additionally first and second img are different, while third is the same (except compilation time). I think that output img should be the same, regardless of compilation sequence. -- Best regards, Andrzej

1 0

mkgmap (StyledConverter) Tile contains both drive-on-left an drive-on right
by Thomas Morgenstern 13 Mar '16

13 Mar '16

Hi, i am converting africa from http:\\download-geofabrik.de. mkgmap r-3671 ( and any older versions too ) give me a warrning : 'Schwerwiegend (StyledConverter): file xyz.osm.pbf :Attention: Tile contains both drive-on left (104037) and drive-on right roads (6443) '. in my STYLEFILE i have the option --drive-on=detect,right. The img-file is successfull created and routing works in Mapsource. But is the routing correct ? Tiles contains many different countries. What con i do to prevent the warning ? Thomas

2 1

Mapset name in BaseCamp and GPS is not showing --description --family-name --series-name --area-name options
by greg crago 11 Mar '16

11 Mar '16

BaseCamp and my Garmin Montana displays "US-Pittsburgh" as the mapset name, which is the LAST entry in my template.args Here is my mkgmap command: java -ea -Xmx1024M -jar \MKGMAP\mkgmap-r3665\mkgmap-r3665\mkgmap.jar --gmapsupp --description="Ohio 2016.2.10" --latin1 --index --x-split-name-index --bounds=\MKGMAP\OH\bounds --location-autofill=is_in,nearest --housenumbers --overview-mapname=Ohio-ov --overview-mapnumber=12380000 --remove-ovm-work-files --style-file=\MKGMAP\openmapchest-style\openmapchest --check-styles --family-id=665 --family-name="Ohio" --product-id=3 --series-name="Ohio 2016.2.10" --area-name="My maps" --min-size-polygon --route --drive-on=detect,right --check-roundabouts --check-roundabout-flares --remove-short-arcs --add-pois-to-areas --pois-to-areas-placement="entrance=main;entrance=yes;building=entrance" --generate-sea=extend-sea-sectors,multipolygon,floodblocker,close-gaps=6000 --make-poi-index --make-opposite-cycleways --process-destination --process-exits --tdbfile --poi-address --verbose -c template.args master_thin.txt Here is my template.args mapname: 12380000 description: US-Cincinnati input-file: 12380000.osm.pbf mapname: 12380001 description: US-Columbus input-file: 12380001.osm.pbf mapname: 12380002 description: US-Dayton input-file: 12380002.osm.pbf mapname: 12380003 description: US-Toledo input-file: 12380003.osm.pbf mapname: 12380004 description: US-Detroit input-file: 12380004.osm.pbf mapname: 12380005 description: US-Mansfield input-file: 12380005.osm.pbf mapname: 12380006 description: US-Pittsburgh input-file: 12380006.osm.pbf Which OPTION sets the mapset name in BaseCamp and GPS units? Greg

2 4

Problem with Exit info while on a BRIDGE
by greg crago 11 Mar '16

11 Mar '16

While traveling East on I-94 (in Michigan), my DESCRIPTION TEXT on my GPS ( the Nuvi layout) said "Bridge" when it should have stated "Exit 139" Example: https://www.openstreetmap.org/node/184647257 here is my exit and destination commands from my lines file: dest_hint=* { delete dest_hint } (highway=motorway_link | highway=trunk_link | highway=primary_link | highway=secondary_link | highway=tertiary_link) & mkgmap:dest_hint=true # { set dest_hint = '${destination:ref|subst: =>} ${destination|subst:;=> |subst:/=> }' | { set dest_hint = '${destination:ref|subst: =>|subst: South=> S|subst: North=> N|subst: East=> E|subst: West=> W} ${destination:street|subst: Road=> Rd|subst: Street=> St|subst: Avenue=> Ave|subst: Mile=> Mi|subst: Boulevard=> Blvd|subst: Parkway=> Pkwy|subst: Highway=> Hwy} - ${destination|subst:;=>,|subst:/=>,}' | '${destination:street|subst: Road=> Rd|subst: Street=> St|subst: Avenue=> Ave|subst: Mile=> Mi|subst: Boulevard=> Blvd|subst: Parkway=> Pkwy|subst: Highway=> Hwy} - ${destination|subst:;=>,|subst:/=>,}' '${ref|subst: =>|subst: South=> S|subst: North=> N|subst: East=> E|subst: West=> W} - ${destination|subst:;=>,|subst:/=>,}' | '${exit_hint_ref|subst: South=> S|subst: North=> N|subst: East=> E|subst: West=> W} ${exit_hint_name|subst: Road=> Rd|subst: Street=> St|subst: Avenue=> Ave|subst: Mile=> Mi|subst: Boulevard=> Blvd|subst: Parkway=> Pkwy|subst: Highway=> Hwy}' | '${exit_to|subst: Road=> Rd|subst: Street=> St|subst: Avenue=> Ave|subst: Mile=> Mi|subst: Boulevard=> Blvd|subst: Parkway=> Pkwy|subst: Highway=> Hwy}' | '${destination|subst:;=>,|subst:/=>,}'; } # build exit hint exit_hint=* { delete exit_hint } (highway=motorway_link | highway=trunk_link | highway=primary_link | highway=secondary_link | highway=tertiary_link) & mkgmap:exit_hint=true { set exit_hint = 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name|subst: Road=> Rd|subst: Street=> St|subst: Avenue=> Ave|subst: Mile=> Mi|subst: Boulevard=> Blvd|subst: Parkway=> Pkwy|subst: Highway=> Hwy}' | 'Exit ${ref|subst: South=> S|subst: North=> N|subst: East=> E|subst: West=> W}' | 'Exit ${mkgmap:exit_hint_ref|subst: South=> S|subst: North=> N|subst: East=> E|subst: West=> W} ${mkgmap:exit_hint_exit_to|subst: Road=> Rd|subst: Street=> St|subst: Avenue=> Ave|subst: Mile=> Mi|subst: Boulevard=> Blvd|subst: Parkway=> Pkwy|subst: Highway=> Hwy}' | 'Exit ${mkgmap:exit_hint_exit_to|subst: Road=> Rd|subst: Street=> St|subst: Avenue=> Ave|subst: Mile=> Mi|subst: Boulevard=> Blvd|subst: Parkway=> Pkwy|subst: Highway=> Hwy}' | 'Exit ${mkgmap:exit_hint_name|subst: Road=> Rd|subst: Street=> St|subst: Avenue=> Ave|subst: Mile=> Mi|subst: Boulevard=> Blvd|subst: Parkway=> Pkwy|subst: Highway=> Hwy}' | 'Exit ${mkgmap:exit_hint_ref|subst: South=> S|subst: North=> N|subst: East=> E|subst: West=> W}'; } # use destination hint and/or exit hint to build name (highway=motorway_link | highway=trunk_link | highway=primary_link | highway=secondary_link | highway=tertiary_link) & (mkgmap:exit_hint=true | mkgmap:dest_hint=true) { name '${exit_hint} ${dest_hint}' | '${dest_hint}' | '${exit_hint}'} This only seems to happen when highway=motorway_junction is sitting on a BRIDGE. Greg

2 10

Question about using different ROAD CLASS's and ROAD SPEED's for one linetype.
by greg crago 11 Mar '16

11 Mar '16

I noticed that I have one linetype (0x0c) for roundabouts and it had many different ROAD CLASS and ROAD SPEED # Roundabouts junction=roundabout & (highway=trunk | highway=trunk_link) [0x2a resolution 18 continue] junction=roundabout & (highway=trunk | highway=trunk_link) [0x0c road_class=3 road_speed=2 resolution 18] junction=roundabout & (highway=primary | highway=primary_link) [0x2d resolution 18 continue] junction=roundabout & (highway=primary | highway=primary_link) [0x0c road_class=3 road_speed=1 resolution 18] junction=roundabout & (highway=secondary | highway=secondary_link) [0x2e resolution 20 continue] junction=roundabout & (highway=secondary | highway=secondary_link) [0x0c road_class=2 road_speed=1 resolution 20] junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x2f resolution 20 continue] junction=roundabout & (highway=tertiary | highway=tertiary_link) [0x0c road_class=1 road_speed=1 resolution 20] junction=roundabout & (highway=unclassified | highway=residential | highway=minor | highway=living_street) [0x25 resolution 22 continue] junction=roundabout & (highway=unclassified | highway=residential | highway=minor | highway=living_street) [0x0c road_class=1 road_speed=1 resolution 22] I also have 2 other linetypes for HIGH SPEED RAMPS (0x09) and LOW SPEED RAMPS (0x08): highway=motorway_link [0x09 road_class=4 road_speed=7 resolution 15] highway=trunk_link [0x09 road_class=4 road_speed=5 resolution 18] highway=primary_link [0x08 road_class=3 road_speed=1 resolution 18] highway=secondary_link [0x08 road_class=2 road_speed=1 resolution 19] MY QUESTION: Can I combine all of these different ROAD_CLASS and ROAD_SPEED together using 0x0c and free up 2 routable linetypes? Yes, all the map elements would like the same. Greg

5 18

[Patch v1] splitter: improve splitting with polygon file
by Gerd Petermann 10 Mar '16

10 Mar '16

Hi all, as Andrzej pointed out (1) splitter r428 and older have a problem with the --polygon-file option, the tiles written by splitter can contain too much data outside of the polygon which later crashes mkgmap. The attached patch should fix this without causing much changes in other use cases. In general the resulting tiles should fit better into the given polygon now, but of course I can't test all special cases. Please try the binary from here with your data when you use polygon(s) with either the --polygon-file or the --polygon-desc-file option: http://files.mkgmap.org.uk/download/293/splitter.jar @Andrzej: Please try with the default resolution 13. When you use 14 instead of 13 you have 4 times more grid elements and therefore more values to store and many more cases to test, with 16 it is 4*4*4 = 64 times more. I saw good results with 13, res. 16 nearly kills my 8 GB machine. I think you only need a higher resolution when the data contains extremely dense area, means a single grid element contains much more than the desired max-nodes nodes. ciao, Gerd (1) http://gis.19327.n5.nabble.com/problem-with-splitter-and-bounding-polygon-t…

3 3

Commit r3671: Fix style parse bug for the form ((a=1 & b=2) | a=2) & c!=1
by svn commit 09 Mar '16

09 Mar '16

Version mkgmap-r3671 was committed by steve on Wed, 09 Mar 2016 Fix style parse bug for the form ((a=1 & b=2) | a=2) & c!=1 Also fix spelling of distribute! http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3671

1 0

style compiler bug
by Mike Baggaley 09 Mar '16

09 Mar '16

Hi Gerd/Steve, I seem to have come across an anomaly in the style compiler (or I am doing something silly). The following line does not compile: ((highway=* & motorroad=yes) | highway=motorway | highway=motorway_link) & foot!=yes & foot!=designated & foot!=permissive { add mkgmap:foot=no } But this variant compiles: (highway=motorway | highway=motorway_link | (highway=* & motorroad=yes)) & foot!=yes & foot!=designated & foot!=permissive { add mkgmap:foot=no } And so does this one: ((highway=* & motorroad=yes) | highway=motorway | highway=motorway_link) & (foot=yes | foot=designated | foot=permissive) This is the error message: Error in style: Error: (inc/access:6): Invalid rule expression: ((($highway=*&($motorroad='yes'))|(($highway='motorway')|($highway='motorway _link')))&($foot!=yes&($foot!=designated&$foot!=permissive))) Changing the != operators to = allows it to compile, so most likely a mishandling of the ! operator. Any ideas what is wrong? Mike

2 2