November 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

Bad performance because of complex boundary relation
by Gerd Petermann 17 Jun '14

17 Jun '14

Hi, this might be an OSM problem... While working on a "beautifyRoundabout" algo I wondered why one tile in Southamerica needed a very long time to calculate. It turned out to be a problem in the location hook. The boundary relation 1981462 is a very complex polygon. I don't see a simple solution in mkgmap, but wouldn't it be better to create a simple way enclosing the area to map this boundary? Gerd

4 3

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

TYP-file can't be written
by Henning Scholland 18 Dec '13

18 Dec '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, just another problem: I got the message from mkgmap, that the TYP-file can't be written in CP1251 and CP1256. In the header of my txt-TYP-source I have written CP1252. Converting this to CP1250 and CP1254 is done without problems. So I don't understand, why it's a problem for CP1251 and CP1256. Any guesses? Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSkShZAAoJEPFgsWC7jOeT/iwIAJM9g29e/69wwIer17x54nC6 u5zwjnZzIEV7vRIfmTHCe6ucFCLHjG+MDtTAq5vZVtDOQUTcvmXUYbF6AAkiXpsd tHp1UXyqcbKy6mQSY0HQkRRzRWqOyJpnQxKe76S4PI6BrARCXm4Rr+UpXLlkXQKe 2F1VELgTZoQ4MR1k4CwNdvuvxeTtMbCLloPBUIoIktutyOLKI+8gonQkiniuSSM0 7cDESCwXiJlS1SGNg7I3rGoHsBpmbceqd+8DZaFnpxnez2bHrnirp0c2hIo3x27N bSLnPSSaJO5ES7mEQkMHcXOFFNHQDee6znHuJmpyCwhzRXSdyUDVSYrsGesjxJg= =v9L8 -----END PGP SIGNATURE-----

4 10

r 2839 in high-prec-coord branch
by Gerd Petermann 30 Nov '13

30 Nov '13

Hi all, it took a while to analyse many special cases, but today I've committed r2839. Compared to trunk you should see: - better routing results because bearing values are calculated using the high precision values of coordinates. - fewer optical errors caused by rounding, e.g. ugly roundabouts or havy zig-zagging lines in the img when OSM data shows an almost straight line - smaller img file size because many obsolete points are removed - slightly higher peak memory usage, else not much difference in throughput Wrong angles are corrected by either moving the displayed points a little bit or by removing them. In some cases, points are merged as in the old short-arc-removal process, but with improvements: - if a way has only two points, the algo tries to keep that way in favor to a wrong angle in the img (else routing would be changed in favor to optic) - very close exit points on a roundabout are kept if possible (to avoid wrong "leave roundabout at" messages Up to now the changes are calculated for routable ways. In a second step, non-routable ways (not shapes) sharing modified points are modified as well. This is useful for those users who create styles for biking. The code needs a bit of review, but I think the result is very good now. Next on my todo list: 1) Change the implementation of the --link-pois-to-ways feature. Current implementation is too complex. Maybe it doesn't work at all now. @WanMil: Or do you already work on it? 2) Implement the merge-shape feature. Gerd

3 4

Access handling trunk <=> mergeroads branch
by WanMil 30 Nov '13

30 Nov '13

Hi, I am comparing differences between the mergeroads branch running the compatibility mode and the trunk. Having the following way: access = destination highway = path The access bits are set as: trunk | branch no_car | 0 | 1 no_bus | 0 | 1 no_taxi | 0 | 1 no_foot | 0 | 0 no_bike | 0 | 1 no_truck | 0 | 1 no_throughrt | 1 | 1 delivery | 0 | 1 emergency | 0 | 1 0 = bit is not set 1 = bit is set For delivery and emergency I am not sure if delivery/emergency is allowed if the bit is set or unset. At the moment the trunk allows all type of vehicles to use the given way. I think that's not good. The branch allows only foot to use the way. What do you think should be the correct access bit mask for the given way? Does anyone know if delivery bit == 1 means the way can be used if one has something to deliver to a point of this way? And the same for emergency? WanMil

3 3

[splitter patch] check for mapids with less than 9 digits
by Ben Konrath 28 Nov '13

28 Nov '13

Hi guys, I ran into a problem where my map failed to generate properly with mkgmap when the mapid used with splitter had more than 9 digits. I've attached a patch for splitter to check for a mapid with more than 9 digits. Thanks, Ben

2 2