April 2014 - mkgmap-dev - The mkgmap lists

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

refactoring
by Gerd Petermann 27 Apr '14

27 Apr '14

Hi all, please test / review the changes in the branch. Users: You should find no differences in map output between trunk r3215 and branch r3214, but maybe the log is different. Programmers: please have a closer look at the source. The intended changes : 1) Create new class AccessTagsAndBits which contains code to map tags which are relevant for routing to bit masks. I prefer to have to bit 1 for "access allowed" to avoid double negations like in "if (!noAccess[i]) ..." I hope that is okay for you as well. All routines which read data are now using the same bit constants regarding CAR,FOOT,BICYCLE,TRUCK, etc. to fill a bit mask field. The write routines convert the internal representatio to that used in the img format. @WanMil: Special case: Code in StyledConverter near roadLog.isInfoEnabled() formats the content of the TabAAcesss field in RoadDef which contains the img format. I think this is okay because the intention of the log is to show exactly the content of this field. 2) Create class ConvertedWay which combines an OSM Way instance with a reference to a GType instance. Instead of copying and modifying fields (roadClass, roadSpeed) in GType instances this is now done in ConvertedWay. Many tags which are relevant for routing are evaluated once when the ConvertedWay instance is created. The results are kept in bit masks, this allows a quick compare. Also, RoadMerger uses this class instead of creating new Road instances. @WanMil: The new code produces a different log on debug level because some comparisons are done in different order. I've changed the code to compare the bit mask fields instead of the tags, but the code still lists (most of) the compared tags to be able to produce debug info. Let me know if that is okay for you. Another solution could be to implement the debugging in ConvertedWay e.g. something like public String compareAccess(ConvertedWay other) could return a String like "mkgmap:truck is different 'no' <> 'null' " 3) With r3214 I've renamed a few methods. Please check if you find better names: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3214

2 3

Commit: r3232: oops, forgot to commit one file
by svn commit 27 Apr '14

27 Apr '14

Version mkgmap-r3232 was committed by gerd on Sun, 27 Apr 2014 oops, forgot to commit one file

1 0