September 2013 - mkgmap-dev - The mkgmap lists

process-exits vs process-destination
by Franco Bez 08 Oct '15

08 Oct '15

Hi all, is there a way to combine the features process-exits and process-destination in a single style ? Based on my experience process-desitnation does a marvellous job when entering a motorway ( does it also work with also trunk roads ? ), while process-extis is perfect when leaving a motorway or trunk road. For instance the roundabout here http://www.openstreetmap.org/?lat=47.89665&lon=10.64805&zoom=17 has two exits towards the B12. Routing from the "Sudetenstraße" going North (maybe towards Augsburg) I would like the Garmin device to announce "5 th Exit - B12 (München)". On the other hand routing to the South (maybe Kempten) it should announce "2nd exit - B12 (Kempten)". Using process-exits this does not work, it's only "5th Exit - B12" resp. "2nd Exit - B12". I would have to use process-destination instead to get the desired messages displayed. Coming home from the trip, routing from the B12 towards "Sudetenstraße" I would like "exit to the right - Exit Kaufbeuren". Using process-exits this works perfectly. Would I use process-destination I would get "exit to the right towards B12 Verteilerring" or even "exit to the right towards Sudetenstraße" a really useless announcement as the sign on the trunk road reads "Kaufbeuren / Neugablonz / Mauerstetten". So this is why I would like to have an option that combines the functionality of process-exits and process-destination. Do you see any way to achieve this in one single style ? Ciao, Franco

7 6

multi-word street search
by Michał Rogala 18 Dec '14

18 Dec '14

Hello! I've a problem regarding street search. In Poland (and I suppose few more countries also may have this issue) person-named streets can have two forms - long one: Miroslawa Dudka or short one: Dudka there is no standard for tagging such names in OSM. Problem is that Garmin/Mapsource search function is matching names from the beginning of the string, so if I enter "Dudka" it will find all streets named "Dudka" but not "Miroslawa Dutka". Do you have any idea how can I deal with such issue? best regards Michal Rogala

12 67

Distorted lines
by Andrzej Popowski 05 Mar '14

05 Mar '14

Hi, I observe badly looking lines. I have attached some pictures and xml objects that doesn't look good on Garmin map. My guess is that there is no proper simplifications for resolution 24bit. Points too dense are removed in a non optimal way which can lead to jagged curves. This could be the reason for bad looking tram railways (file tram1.osm in test.zip). Other reason could be removing of short lines. I think in this case some nodes are moved. It looks like instead of creating a new node in a middle of removed line, first point is used. This can lead to bigger distortion. This is probably the case of road example (file road1.osm). -- Best regards, Andrzej

10 40

Drive-on-left
by Colin Smale 15 Nov '13

15 Nov '13

Hi, In the last couple of years I have been making maps with mkgmap for both the UK and various continental countries. One problem that I have never been able to fix until now is that the "drive-on-left" flag didn't seem to have any effect on roundabouts in the UK. The "impact" is limited because roundabouts are one way anyway, but the pictographic representations of roundabouts always assume drive-on-right so you appear to be directed to drive the wrong way. I took a look at the code and saw that the drive-on-left and drive-on-right flags are only used to set a flag in NODHeader.java. However I just discovered ImgTool[1] which exposes the "TRE parameters", a sequence of four numbers which, I noticed, include a flag for "drive-on-left". This was not being set on my UK maps (despite using the drive-on-left option for mkgmap) so they all appeared to be drive-on-right. With ImgTool I was able to simply set this bit in my img file - and then the problems with the roundabout direction disappeared! I am not really a Java programmer so I don't feel confident about trying to fix this myself, but it seems there is related code in TREHeader.java including the following declarations: public static final int POI_FLAG_TRANSPARENT = 0x2; public static final int POI_FLAG_STREET_BEFORE_HOUSENUMBER = 0x4; public static final int POI_FLAG_POSTALCODE_BEFORE_CITY = 0x8; I think it just needs something like this adding: public static final int POI_FLAG_DRIVE_ON_LEFT = 0x20; plus the code to set this bit depending on the drive-on-left flag. It would be great if this could be changed in mkgmap. If I should really be logging this elsewhere please accept my apologies and point to me to the right place and I will enter the details there. Best regards (and thanks everyone for a tremendous program!) Colin [1] https://sites.google.com/site/sherco40/imgtool [1] Links: ------ [1] https://sites.google.com/site/sherco40/imgtool

7 19

location-autofill=nearest breaks compiling
by Carlos Dávila 16 Oct '13

16 Oct '13

Compiling British Isles map with location-autofill=is_in,nearest throws the following error: Exception in thread "main" java.lang.AssertionError: Invalid label offset found 105 at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReader.java:86) at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.readPoiInfo(LBLFileReader.java:351) at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.<init>(LBLFileReader.java:74) at uk.me.parabola.mkgmap.combiners.FileInfo.lblInfo(FileInfo.java:326) at uk.me.parabola.mkgmap.combiners.FileInfo.lblInfo(FileInfo.java:313) at uk.me.parabola.mkgmap.combiners.FileInfo.imgInfo(FileInfo.java:259) at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:152) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:545) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128) at uk.me.parabola.mkgmap.main.Main.main(Main.java:119) Removing the "nearest" part of location-autofill it works fine. All other maps I compile with location-autofill=is_in,nearest also compile without problems. Any idea why this particular map may be going wrong?

4 11

version 2718 and construction {name '${name} text'|'text'} not work
by Maks Vasilev 12 Oct '13

12 Oct '13

I have in point file rules: shop=kiosk {name '${name}, киоск'|'киоск'} [0x2e02 resolution 20] On old version mkgmap point set name as "Name, киоск" if poi have name=Name or name as "киоск" if poi without name tag. Now in 2718 poi have only name as "Name" or name as "киоск". It's a bug or new mkgmap used new syntax for text manipulation?

2 8

point outside map area
by Henning Scholland 07 Oct '13

07 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, I got the following error messages: SEVERE (MapArea): Point with type 0x1e04 at http://www.openstreetmap.org/?mlat=36.32080&mlon=25.79590&zoom=17 is outside of the map area centred on http://www.openstreetmap.org/?mlat=38.89999&mlon=35.39999&zoom=17 width = 894785 height = 307582 resolution = 11 SEVERE (MapArea): Point with type 0x1e04 at http://www.openstreetmap.org/?mlat=35.59570&mlon=27.02637&zoom=17 is outside of the map area centred on http://www.openstreetmap.org/?mlat=38.89999&mlon=35.39999&zoom=17 width = 894785 height = 307582 resolution = 11 SEVERE (MapArea): Point with type 0x1e04 at http://www.openstreetmap.org/?mlat=37.11182&mlon=25.79590&zoom=17 is outside of the map area centred on http://www.openstreetmap.org/?mlat=38.89999&mlon=35.39999&zoom=17 width = 894785 height = 307582 resolution = 11 SEVERE (MapArea): Point with type 0x15 at http://www.openstreetmap.org/?mlat=35.59570&mlon=33.92578&zoom=17 is outside of the map area centred on http://www.openstreetmap.org/?mlat=38.89999&mlon=35.39999&zoom=17 width = 894785 height = 307582 resolution = 11 0x1e04 is used for natural=bay or sea, 0x15 for place=country This only happens for my map of Turkey, but I can't find out, which objects cause the error. The only guess I have is, that it's caused by add-poi-to-areas, because there are no nodes in the input-data. Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJSNJ9nAAoJEPFgsWC7jOeTHSkH/2+es9JCaH9pA7U345Vclk7c /s3XpqU0rv2Qdcbrddfe6mLizgPSS20NCSSg9r/8J9RzcGyVU/9ec7Y/GTerG6We iSoBwPzTOp+StDCfQ4v0emxYFLx577ZSwMi0c2cteMWGHb/gys2tob401oZ/vXxv hD5czU4FvsQDKnd+TjzwskoR0YzFw2GqtFYP9jgSLlkISVEz1x/NMKgRUQe4TwPv 88YeQEnIEgEGylgWcTmLW67JOEYdej5PdP1kB4ixPc2vYkdMl91hHPhj9Ta7rLGK wfUWxptSglLQ13FagZRtxnKonJmRE0JLYxxqEOc7tIv7Ev1ph3Jy7PoT7pZ8teE= =MiBt -----END PGP SIGNATURE-----

4 6

First post to the mailing list - Garmin search issues
by Brett Russell 07 Oct '13

07 Oct '13

Hi I have been experimenting with mkgmap and struck and issue with the search features on my Garmins. My 62s using the spell search will find items such as lakes and huts (I am a bushwalker) but my Rino 650 can only find cities under the point of interests. I am using the same img files created as per below Windows 7 bat file. Any clues? Cheers Brett REM mkgmap command lineREM -------------------java -Xmx8192m -Xms2048m -ea -jar mkgmap.jar ^ --max-jobs ^ --gmapsupp ^ --route --drive-on-left --check-roundabouts ^ --generate-sea ^ --remove-ovm-work-files ^ --add-pois-to-areas ^ --location-autofill=nearest ^ --index ^ --style-file=styles\mapnik\ ^ --description="Ent_World 20M Contours" ^ --country-name=Australia --country-abbr=AU --region-name=Tasmania --region-abbr=TAS --draw-priority=25 Ent_World.osm.pbf ^ --family-name=contours --draw-priority=31 --transparent Ent_contours_20M\Ent_world*.osm.pbf ^ styles\mapnik\mapnik_play.typ

2 4

name include file
by WanMil 05 Oct '13

05 Oct '13

Hi all, I think the name include file should be reworked. I often get names like "Shell: Shell (Shell)" for fuel stations. The same happens to restaurants, supermarkets, etc. The tags name, operator and brand are often the same so I think they should not all be used in the POI name. Any suggestions for improvement? WanMil

4 5

Commit: r2707: Don't complete remove an unconnected road.
by svn commit 05 Oct '13

05 Oct '13

Version 2707 was committed by steve on Mon, 16 Sep 2013 Don't complete remove an unconnected road. If mkgmap:set_unconnected_type=none and the road is unconnected then the road was completely removed and was not available for any rule matching after a continue. Now it is not added to the removed list, so that it can still be used as a line.

6 15