- mkgmap-dev - The mkgmap lists

Possible maxspeed patch
by MarkS 30 Aug '09

30 Aug '09

Here is a possible patch for maxspeed. Around here lots of roads have been tagged with their speed limit (which is 60mph). However, these are unclassified roads and you are unlikely to get above 40mph. At the moment the default behaviour of mkgmap is set overide the style file for these roads and set the road class appropriate to 60mph, which is too fast. I could turn on ignore-maxspeeds which would fix these roads but in turn that would result in the trunk roads in town getting too high a speed. The patch attempts to overcome this by offerring an extra option for ignore-maxspeed, so the options become [Default] - Use maxspeed if it exists, otherwise Road Class from the style "ignore-maxspeeds" - Use road class from the style file "ignore-maxspeeds:0" - Use road class from the style file "ignore-maxspeeds:1" - Use maxspeed from the style file "ignore-maxspeeds:2" - Use the lower of road class and maxspeed Effectively option 2 solves my problem. The other numbered options are there to reproduce existing behaviour using a number. The non-numbered option is to keep compatiblity with existing code. Note: - This is the first patch I've done so I might have gone about it completely the wrong way. If so I'm sorry and please give me some hints - It is also the first Java code I've ever edited so I might have done something wrong! All I can say is that it worked for me ! Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1145) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy) @@ -100,7 +100,7 @@ private final Rule nodeRules; private final Rule relationRules; - private boolean ignoreMaxspeeds; + private int ignoreMaxspeeds=1; class AccessMapping { private final String type; @@ -141,8 +141,17 @@ wayRules = style.getWayRules(); nodeRules = style.getNodeRules(); relationRules = style.getRelationRules(); - ignoreMaxspeeds = props.getProperty("ignore-maxspeeds") != null; + String ignoreMaxspeedsPar = props.getProperty("ignore-maxspeeds", null); + if(ignoreMaxspeedsPar != null){ + try { + ignoreMaxspeeds = Integer.parseInt(ignoreMaxspeedsPar); + } + catch (Exception e) { + ignoreMaxspeeds = 0; + } + } + LineAdder overlayAdder = style.getOverlays(lineAdder); if (overlayAdder != null) lineAdder = overlayAdder; @@ -903,17 +912,28 @@ } int speedIdx = -1; - if(!ignoreMaxspeeds) { - // maxspeed attribute overrides default for road type - String maxSpeed = way.getTag("maxspeed"); - if(maxSpeed != null) { - speedIdx = getSpeedIdx(maxSpeed); - log.info(debugWayName + " maxspeed=" + maxSpeed + ", speedIndex=" + speedIdx); - } + String maxSpeed; + switch(ignoreMaxspeeds) + { + case 0: + // Use the style file and ignore the maxspeed tag + road.setSpeed(gt.getRoadSpeed()); + break; + case 1: + // Use maxspeed tag, only use the style file if maxspeed is missing (the default if ignoreMaxspeeds is not defined) + maxSpeed = way.getTag("maxspeed"); + if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed); + road.setSpeed(speedIdx >= 0? speedIdx : gt.getRoadSpeed()); + break; + + case 2: + // Use the lower of the maxspeed tag and the style file value + maxSpeed = way.getTag("maxspeed"); + if(maxSpeed!=null) speedIdx = getSpeedIdx(maxSpeed); + road.setSpeed(speedIdx >= 0? Math.min(gt.getRoadSpeed(),speedIdx ) : gt.getRoadSpeed()); + break; } - road.setSpeed(speedIdx >= 0? speedIdx : gt.getRoadSpeed()); - boolean[] noAccess = new boolean[RoadNetwork.NO_MAX]; String highwayType = way.getTag("highway"); if(highwayType == null) {

9 15

mkgmap rules tiny break
by Felix Hartmann 30 Aug '09

30 Aug '09

Just as a note for people so you don't wonder why something does not work: Rules of the follwing type * & ( !=* | !=* ) will not work. and instead allways be enacted. So for example both of the follwing rules match even though neither route=mtb nor route=bicycle is set: tunnel=yes & ( route!=mtb | route!=bicycle ) [0x* resolution *] will show up even on mtb and bicycle routes. tunnel=yes & ( highway!=cycleway | highway!=footway ) [0x* resolution *] will show up even on cycleway and footway. This works however: tunnel=yes & ( highway!=footway ) [0x* resolution *] and rule is not enacted on footways. I'm not sure that the above was really intended to be doable, and for me it's no big point at all, just wanted to point it out so others save themselves the hassle of finding the fault.

2 4

Commit: r1158: Better highway=primary type
by svn commit 30 Aug '09

30 Aug '09

Version 1158 was commited by elrond on 2009-08-30 01:10:39 +0100 (Sun, 30 Aug 2009) Better highway=primary type A one-character diff to allow highway=primary to assume by default a different (and more appropriate) Garmin style to highway=trunk. by Dermot McNally Thanks! I can't see a difference in mapsource, so 0x02 and 0x03 seem to be quite close. We now have 0x01 motorway 0x02 trunk 0x03 primary 0x04 secondary 0x05 tertiary

4 4

Commit: r1157: Added support for extended type attributes in mp files.
by svn commit 30 Aug '09

30 Aug '09

Version 1157 was commited by markb on 2009-08-29 12:05:23 +0100 (Sat, 29 Aug 2009) Added support for extended type attributes in mp files.

3 4

[PATCH] Fixed secondary_link/tertiary_link Garmin types
by Ondrej Novy 30 Aug '09

30 Aug '09

Hi, 0x08 is low-speed ramp, 0x09 is high-speed ramp. But for secondary_link and tertiary_link was used 0x09 - same as motorways :). So i changed it to 0x08, patch attached, thanks. -- S pozdravem/Best regards Bc. Ondrej Novy Email: novy(a)ondrej.org Jabber: onovy(a)njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207

2 3

Missing lakes
by Tomas Straupis 30 Aug '09

30 Aug '09

Hello I've noticed strange problem with lakes (natural=water) in a middle of forests (landuse=forest). Some of them are displayed on Garmin (Colorado), some are not. The only difference in data I can see is that the ones displayed have source=Yahoo tag (in addition to natural=water and created_by=...). Strangely enough this is only happening when rendering forest areas as 0x50, if I change it to 0x17 (park) all lakes are visible. Affected area: http://www.openstreetmap.org/?lat=55.2085&lon=25.7473&zoom=13&layers=B000FTF (data taken from http://download.geofabrik.de/osm/europe/lithuania.osm.bz2) Has anybody noticed such behaviour? Is it Colorado or mkgmap problem? Thank you P.S. I will try later to add source=Yahoo to missing lakes and check if that makes them appear on the map. -- Tomas Straupis

6 12

draw-priority and layers
by frmas 30 Aug '09

30 Aug '09

Hi, I'm trying to build a map with different layers, but I guess something is wrong with the draw-priority parameter or the way i use it. 4 layers : - Layer 1 : Contour line. draw-priority=25 (the highest). Transparent Specific style (contour) - the style is just (actually): natural=coastline [0x15 resolution 12] I generate a gmapsupp.img file - Layer 2 : Personal data draw-priority=20 (a little less than layer 1). Transparent Specific style (perso) I generate a gmapsupp.img file - Layer 3 : Normal OSM map. draw-priority=10 (the highest). NO Transparency (of course) Specific style (perso) I generate a gmapsupp.img file - Layer 4 : Search map (with the road-name-pois parameter). draw-priority=1 (the lowest). No specific style. I generate a gmapsupp.img file So I should have : layer 1 (contour) : - - - - - - - - - - - - - - - - - - - layer 2 (personal : - - - - - - - - - - - - - - - - - - - layer 3 (normal) : ------------------------------------- layer 4 (search) : ------------------------------------- So, layers 1, 2 and 3 should be visible, not layer 4 as below a non transparent layer. Now, when I mix all those gmapsupp files (I rename all of them of course) plus the two .TYP files (PERSO and CONTOUR), I have different results depending the way I place them on the command line. 1) ex: mkgmap gmapsupp_layer1 gmapsupp_layer2 gmapsupp_layer3 gmapsupp_layer4 CONTOUR.TYP PERSO.TYP makes layer2 not visible. The map displayed seems to use a default style. 2) ex: mkgmap gmapsupp_layer4 gmapsupp_layer2 gmapsupp_layer1 gmapsupp_layer4 CONTOUR.TYP PERSO.TYP makes layer1 not visible. I don't know which style it uses, none of mine at least. 3) Now if I compile layer1 with my "perso" style and if I remove the CONTOUR.TYP file from the gmapsupp generated at the end of the process, my perso style is again not used, and I have always one of the layers, not displayed. Maybe I do something wrong here, but I do not understand from the tests I made and results I have how the draw-priority works. Francois P.S. I tried all possible orders, but I never got a good result. --

2 3

[PATCH] Give highway=primary a default styling different to highway=trunk
by Dermot McNally 29 Aug '09

29 Aug '09

A one-character diff to allow highway=primary to assume by default a different (and more appropriate) Garmin style to highway=trunk. It would be great to see this applied. Thanks, Dermot Index: resources/styles/default/lines =================================================================== --- resources/styles/default/lines (revision 1157) +++ resources/styles/default/lines (working copy) @@ -41,7 +41,7 @@ highway=motorway {add oneway = yes; add bicycle = no; add foot = no } [0x01 road_class=4 road_speed=6 resolution 12] highway=motorway_link {add oneway = yes; add bicycle = no; add foot = no } [0x09 road_class=4 road_speed=3 resolution 16] highway=pedestrian & area!=yes {add access = no; add foot = yes} [0x06 road_class=0 road_speed=0 resolution 22] -highway=primary [0x02 road_class=3 road_speed=4 resolution 19] +highway=primary [0x03 road_class=3 road_speed=4 resolution 19] highway=primary_link [0x08 road_class=3 road_speed=3 resolution 19] highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 21] highway=secondary [0x04 road_class=2 road_speed=3 resolution 20] -- -------------------------------------- Iren sind menschlich

1 0

Splitter default description with comments (patch)
by Valentijn Sessink 29 Aug '09

29 Aug '09

Hi list, As discussed before, I think it's a bit confusing that Splitter has a default "description" in it's template.args file that says "OSM Map". The attached patch fixes this: it puts "#" before the description if you didn't specify a --description. This also helps --description in mkgmap, as it will work as advertised, without hidden settings elsewhere. This is the patch for Splitter, cleaned up (there was a spurious comment in an unrelated file in the previous one). Best regards, Valentijn

2 1

Improving mkgmap's Unicode transliteration
by Ævar Arnfjörð Bjarmason 29 Aug '09

29 Aug '09

I'm going to Greece tomorrow and I noticed to my dismay that mkgmap's transliteration tables for the Greek alphabet were totally missing. So I hacked up a small Perl script which uses the Unicode::UCD and the Text::Unidecode modules to fillin the blanks: avar@aoeu:~/src/mkgmap/resources/chars/ascii$ perl re-transliterate.pl < row03.trans > row03.trans.tmp && mv row03.trans.tmp row03.trans The script and a patch to row03.trans which Works For Me are attached. But of course the tool can also be run on the rest of the files to fill in more blanks. And my script can of course be modified a bit further to spit out transliterations for files not yet in mkgmap row* files. I don't know what the row* files were originally based on but there's a lot of prior art for transliterating Unicode and there's no need to redo all this work for mkgmap. The Unicode Consortium has published transliteration tables (which Text::Unidecode is largely based on), it's much easier to use stuff like that rather than doing all the work yourselves. Anyway, off to pack for my flight.

2 2