- mkgmap-dev - The mkgmap lists

Commit: r3246: fix severe error in overlays handling introduced with r3227
by svn commit 02 May '14

02 May '14

Version mkgmap-r3246 was committed by gerd on Fri, 02 May 2014 fix severe error in overlays handling introduced with r3227 Styles using a an overlays file did no longer work.

1 0

Commit: r3241: apply reverse-oneway-v3.patch
by svn commit 30 Apr '14

30 Apr '14

Version mkgmap-r3241 was committed by gerd on Wed, 30 Apr 2014 apply reverse-oneway-v3.patch This patch makes sure that multiple copies of an OSM way with different oneway=* tags are not treated the same. Without this patch the result is more or less unpredictable if you use something like this: xyz=* { add oneway=-1 } [0x1010 resolution 23 continue] xyz=* { set oneway=yes } [0x1011 resolution 23 continue] xyz=* { set oneway=-1 } [0x10 road_speed=1 resolution 23] todo: check code for restriction relations

1 0

Message digests with one message
by Paulo Carvalho 30 Apr '14

30 Apr '14

Dear list admins, Please check the message digest system since I've received lots of digests with just one message. Thanks in advance, Paulo

1 0

[patch v3] reverse oneways
by Gerd Petermann 30 Apr '14

30 Apr '14

Hi Felix, attached is a patch that may help to solve your problems with reversed oneways. It may not work without --ignore-turn-restrictions. I'd first like to make sure that I understand what you are doing. I've added a few lines to the default style to produce additional lines for ways with highway=* & incline=up If I got you right, you create one oneway for the uphill direction and another one with reverse direction for downhill, and also overlaying lines with types that are direction dependent. The result is in switch_oneway.zip. The attached reverse-oneway-v3.patch changes mkgmap to keep the order of points in each way. That means, points are reversed after style processing if tag oneway=-1 is found, and this order is then maintained in the rest of the program. Gerd P.S. I think we can drop the idea of reversing ways with "oneway=-1" before style processing. This will not help in your case, as you add the tag in the style.

3 9

performance2 branch doesn't work yet
by Gerd Petermann 30 Apr '14

30 Apr '14

Hi all, today I noticed a problem with the caching of the <finalize> rules. Working on it... Gerd

1 0

possible tuning for evaluation of tags
by Gerd Petermann 29 Apr '14

29 Apr '14

Hi Programmers, according to Java Mission Control the current code in mkgmap requires ~ 20% of the CPU time in Tags.keyPos(), and a few more percent in other HashMaps related to tag keys. A lot of this CPU time is required to compare the keys of tags (which are String instances), which also causes quite a lot of data being moved into CPU caches. There are two ways to reduce this CPU time: 1) reduce the time required in Tags.keyPos() This can be done if we use a dictionary to translate each used tag key into a unique id (a short or int). Instead of storing and comparing Strings we could then use the id, which in turn can be the index to an array with the tag key. 2) reduce the number of calls of Element.getTag() which calls Tags.keyPos() This can be done by some caching. Consider the following rules barrier=* & bicycle=* { set mkgmap:bicycle='${bicycle|subst:private=>no}' } barrier=* & foot=* { set mkgmap:foot='${foot|subst:private=>no}' } barrier=* & hgv=* { set mkgmap:truck='${hgv|subst:private=>no}' } barrier=* & motorcar=* { set mkgmap:car='${motorcar|subst:private=>no}' } The result for the evaluation of tag barrier=* is a constant as none of the action blocks changes it, but mkgmap really calls Element.getTag() again and again for each line. In March 2012 I did some experiments with this idea and found a typical saving of 20% run time with the default style, but I never finished it. I think it is worth to start this again in a new branch, but it will involve a lot of small changes to many sources, so I'd like to know if anybody else plans to code changes. Gerd

2 2

Commit: r3234: simplify code, reduce number of getTag() calls
by svn commit 28 Apr '14

28 Apr '14

Version mkgmap-r3234 was committed by gerd on Mon, 28 Apr 2014 simplify code, reduce number of getTag() calls no change in output expected

1 0

how to ignore/force road direction
by Michał Rogala 28 Apr '14

28 Apr '14

Hi! I've a problem with rendering trails on my map. Trails in TYP files are defined with transparent background and off the road axis (below it) so they don't render on top of the real road. But roads in OSM have pretty random direction (unless used with oneway=yes) and trails are rendered above real roads or below it depending of a road direction - this looks quite ugly and leaves empty gaps on road junctions. Is is any way to force consistent rendering of such trail regardless of the road direction? best regards Michal Rogala

3 3

Commit: r3233: update doc for --check-styles option
by svn commit 28 Apr '14

28 Apr '14

Version mkgmap-r3233 was committed by gerd on Mon, 28 Apr 2014 update doc for --check-styles option

1 0

mkgmap:label
by demon.box 27 Apr '14

27 Apr '14

Hi, in the lines rules I have this: <finalize> highway=* & name=* {set name_orig='${name}'} highway=* & route_type ~ '.*hiking.*' {name '${route_ref1|highway-symbol:oval} ${route_name|not-equal:route_ref1} [${name|not-equal:route_name}]' | '${route_ref1|highway-symbol:oval} ${route_name|not-equal:route_ref1}' | '${route_ref1|highway-symbol:oval}' | '${ref|highway-symbol:oval} ${route_name}' | '${route_name} [${name|not-equal:route_name}]' | '${route_name}' } name_orig=* {set mkgmap:label:3='${name_orig}'} name=* {name '${name}'} With the first line I preserve the name of the way and with the second line I set the tag name with the relation information. With the third line I would add the name_orig always like the second label but sometimes I see first and sometimes I see like second line... I don't understand why. <http://gis.19327.n5.nabble.com/file/n5804224/Immagine1.jpg> <http://gis.19327.n5.nabble.com/file/n5804224/Immagine2.jpg> How can I set the second label always a the same position? Thanks very much. --enrico -- View this message in context: http://gis.19327.n5.nabble.com/mkgmap-label-tp5804224.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 5