April 2016 - mkgmap-dev - The mkgmap lists

"mirror" problem with GPS
by demon.box 01 Apr '16

01 Apr '16

Hi, excuse me, do you think there is a reason why this line (0x10505) it's ok in MapSource and BaseCamp: <http://gis.19327.n5.nabble.com/file/n5871069/mapsource.jpg> but on my GPS Garmin Oregon 600 it's appear exactly mirrored?? <http://gis.19327.n5.nabble.com/file/n5871069/IMG_5051_%281024_x_768%29.jpg> I tried with others element type definition but it doesn't work. I noticed the same problem with the OMM map by Felix (ExtremeCarver). Any ideas? Thanks. --enrico -- View this message in context: http://gis.19327.n5.nabble.com/mirror-problem-with-GPS-tp5871069.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 1

patch for "part" filter
by Andrzej Popowski 01 Apr '16

01 Apr '16

Hi, I have tried to use substitution filter "part" and have found, that it worked differently, than I expected. Some operation results in adding trailing separator while others don't. Some filters return null, others return "", which breaks evaluating formulas with "|". I have attached a patch, that should change behavior of following filters: "A1;A2;A3" "part:;<3" -> old "A3;", patched "A3" "A1;A2" "part:;<3" -> old null, patched "A1;A2" "A1" "part:;>-2" -> old null, patched "A1" "A1;A2;A3" "part:;>3" -> old "", patched null "A1;A2" "part:;<-2" -> old "", patched null I have attached example data and style for testing the filter. I'm not sure, what would be preferred result for following filters: "A1" "part:;<3" -> result null or "A1"? "A1" "part:;>-3" -> result null or "A1"? Both, current version and patched, return null. I think result "A1" could be useful. -- Best regards, Andrzej

2 2

Commit r3675: dest_hint_v1.patch : change --process-destination option
by svn commit 01 Apr '16

01 Apr '16

Version mkgmap-r3675 was committed by gerd on Fri, 01 Apr 2016 dest_hint_v1.patch : change --process-destination option The process_destination option was a bit problematic because it could have added the tag destination=* to an existing OSM element. The attached patch changes the method like this: 1) the tag destination is not changed by mkgmap 2) Instead the special tag mkgmap:dest_hint is now set to the destination string that was found in one of the tags listed in this code snippet: tags.add("destination"); tags.add("destination:lanes"); tags.add("destination:lanes:forward"); tags.add("destination:lanes:backward"); tags.add("destination:forward"); tags.add("destination:backward"); tags.add("destination:street"); (BTW: This is also the order of evaluation in mkgmap searches since r3673, of cause forward/backward are checked depending on the direction of the way) For style authors this means that they have to 1) change all rules with mkgmap:dest_hint=true to mkgmap:dest_hint=* 2) change the rule that produces the hint to something like this: mkgmap:dest_hint=* { set dest_hint = '${destination:ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' | '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }' | '${mkgmap:dest_hint|subst:;=> |subst:/=> }'; } Basically all places where "destination" was used were changed to mkgmap:dest_hint. This could cause trouble, so I've added a check that complains when the style contains an expression mkgmap:dest_hint=true. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3675

2 1