October 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

question regarding MapRoad
by GerdP 25 Mar '14

25 Mar '14

Hi Steve, I'd like to change the way how MapRoad objects are handled in the sub division split process. Current implementation is like this: 1) StyledConverter creates a MapRoad instance with max. 250 points, if a road has more points, multiple instances are created, each with its own RoadDef. 2) When the sub divisions are created, a MapRoad is never split, so the final result is that each instance is written to exactly one sub division. The Garmin format seems to imply that we should rather split the MapRoad to match a given bbox of a sub division. This will produce smaller img files because the offsets to the sub division centers are smaller, and if we allow to start with MapRoad instances having > 250 points, we also have fewer NOD entries. I tried to implement this, but I can't find a nice way to store the information about the order of the segments of a road. This is needed when finally the RoadDef.addPolylineRef() method is called. I think that we either have to make sure that each part of a road is processed in the correct order, or we have to restore the order after all the filters where used. (For the different levels, a road will be split into different parts, if a road goes out and in we can have multiple segments in one sub div, not directly connected to each other) I have no idea yet how to do this. Can you help? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/question-regarding-MapRoad-tp5781633.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 10

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

Address Index problem
by Marek Greško 16 Feb '14

16 Feb '14

Hello, I am experiencing several issues using index search on my GPS unit. First is probably related to: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q2/017760.html I have missing streets in Bratislava (Slovakia) in index. But I am not sure whether is is only in Bratislava (which uses districts). I tried to compile only partial map (cut off from Slovakian map) containing only corresponding part of Bratislava and streets are there. My address setup in style file is like this: # Slovakia mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:country=SVK & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } ... which is with high probability correct. Second problem is, when I use code page 65001 when searching for streets I can filter only first character. Probably because of case sensitive search? I am unable to insert lowercase characters into my gps unit to test whether this is the real cause. When compiling with 1250 codepage, the search filter works correctly. Does the index need to be uppercased? Thank you Marek

4 15

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

[PATCH v1] finalizer style file
by WanMil 03 Nov '13

03 Nov '13

Hi, I had a look how much effort it is to add a finalizer style file that is used each time a rule with an element type definition matches. This might make it more easy to implement "general rules" (like the mkgmap:access tag which seems to be useful for complex styles). The finalize file must contain actions only. Otherwise mkgmap stops with an error message. Attached patch for the mergeroads branch realizes this. Maybe have a look on it and reply if you find it useful or superfluous. The patch also contains an additional style function type() returns node, way or relation depending on the elements type. @Steve: do you think it would be possible to add a finalize section to the bottom of each style file (especially points, lines and polygons)? I have the feeling that this is more understandable and maybe better to have different finalize styles for each element type. WanMil

3 5

[Patch v1] avoid wrong bearing results
by GerdP 01 Nov '13

01 Nov '13

Hi, a few weeks ago I suggested that we might need higher precision in the Coord class. Attached patch is a quick hack to implement this. If I got it right, this may allow to remove a lot of code that tries to correct what the rounding had done wrong. For the beginning, I've used the precise values only for bearing calculations, as I think that this is most important. high_precision_coord_v1.patch <http://gis.19327.n5.nabble.com/file/n5783533/high_precision_coord_v1.patch> Please let me know what you think about it. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v1-avoid-wrong-bearing-results-tp57835… Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 7

Still problems with remove-short-arcs
by Carlos Dávila 31 Oct '13

31 Oct '13

I still get some wrong routing at some roundabouts using remove-short-arcs=0. See attached screenshots. At http://osm.org/go/b_YMZ7sDP-- MapSource makes a detour to avoid the roundabout, due to a sharp angle that is introduced by remove-short-arcs=0. If I use rsa=3, the route goes through the roundabout, but the exit number is wrong, because the incoming road and the first street are joined at the same node of the roundabout.

3 7

Commit: r2795: Minor correction to getAngle.
by svn commit 31 Oct '13

31 Oct '13

Version mkgmap-r2795 was committed by gerd on Thu, 31 Oct 2013 Minor correction to getAngle. Always use c2 to calculate the initial bearing. (c1.bearingTo(c2) != c2.bearingTo(c1) - 180) The previous version returned wrong values when the distance between c1 and c2 or c2 and c3 was large. See http://www.movable-type.co.uk/scripts/latlong.html

1 0