February 2014 - mkgmap-dev - The mkgmap lists

Mkgmap exception while reading "options" file
by paco.tyson＠free.fr 01 Mar '14

01 Mar '14

Hi all, I'm faced with this error : java -jar ../../../bin/mkgmap-r3057/mkgmap.jar --style-file=src/ --style=style-FR --check-styles Time started: Wed Feb 26 23:20:35 CET 2014 checking style: style-FR Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2 at uk.me.parabola.mkgmap.general.LevelInfo.createFromString(LevelInfo.java:74) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.readRules(StyleImpl.java:275) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.<init>(StyleImpl.java:160) at uk.me.parabola.mkgmap.main.Main.readOneStyle(Main.java:382) at uk.me.parabola.mkgmap.main.Main.checkStyles(Main.java:362) at uk.me.parabola.mkgmap.main.Main.processOption(Main.java:264) at uk.me.parabola.mkgmap.CommandArgsReader$CommandOption.processArg(CommandArgsReader.java:303) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125) at uk.me.parabola.mkgmap.main.Main.main(Main.java:117) When I invoke mkgmap as usual to compile a map, it fails after outputting this exact same exception trace 8 times. No map produced. I've narrowed the issue to the "options" file, pasted here : # # Style options. # # The name tag determines what tag is used as the name of a # feature. Usually this is just 'name' but you might want something # more specific such as name:en or another language variant. # You can specify a list here, the first one that exists will be # used # # Example: # name_tag = name:en, int_name, name # The levels specification for this style levels=0:24,1:23,2:22,3:20,4:18 overview-levels=5:17,6:15,7:14 If I comment out the 2 lines, then mkgmap runs fine (style checking and map compiling). This file was OK before I migrated from OS X Snow Leopard to Mavericks. Before : OS X 10.6.8, java6, mkgmap r2685. Now OS X 10.9.2, java7, mkgmap 3057 (same exception with r2960)

4 9

!= not working in rule
by Carlos Dávila 28 Feb '14

28 Feb '14

For some tests, I have included the line |highway!=residential & name ~ '[Ee]strada .*' { deletealltags }| in my lines style file, but mkgmap complains about "Invalid rule expression". Without ! it works fine. Shouldn't it work? -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale LibreOffice desde http://es.libreoffice.org/descarga/ LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.

2 2

Commit: r3072: Fix various problems that could occur when reading a file with no final eol
by svn commit 28 Feb '14

28 Feb '14

Version mkgmap-r3072 was committed by steve on Fri, 28 Feb 2014 Fix various problems that could occur when reading a file with no final eol or with CR line endings. Plus a few tests for the different cases.

1 0

Commit: r3071: Fix Invalid rule expression highway!=residential & a ~ b
by svn commit 28 Feb '14

28 Feb '14

Version mkgmap-r3071 was committed by steve on Fri, 28 Feb 2014 Fix Invalid rule expression highway!=residential & a ~ b To make this work we have to prepend a highway!=* term to the expression. This is done in most circumstances already but this expression happens to involve a different code path. Test added.

1 0

Wrong turn restriction warnings
by Carlos Dávila 27 Feb '14

27 Feb '14

4 13

Commit: r3069: fix reporting of errors in levels statements
by svn commit 27 Feb '14

27 Feb '14

Version mkgmap-r3069 was committed by gerd on Thu, 27 Feb 2014 fix reporting of errors in levels statements

1 0

problem with foot!=
by nwillink 26 Feb '14

26 Feb '14

Hi I discovered a 'unusual' foot tag , ie foot=permissive. http://www.openstreetmap.org/way/29411164 when trying change it to foot=yes, I my echotags always show me foot=no , ie foot=permissive {set foot=yes} It appears that foot!=yes is parsed as Boolean ,foot=no - perhaps I'm wrong. Any way around this? Nick -- View this message in context: http://gis.19327.n5.nabble.com/problem-with-foot-tp5797620.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

[patch v6] additional arcs‏
by Gerd Petermann 26 Feb '14

26 Feb '14

Hi all, here is the next version of the patch. The additional arcs are now only added with the (undocumented) option --x-add-indirect-arcs I've also changed (again) the formular that mkgmap uses to calculate the length of a road (segment). With trunk r3057 we use final static double LENGTH_FACTOR = 3.2808 / 16; private static int convertMeters(double l) { return (int) (l * LENGTH_FACTOR); } for r3065 in the branch I've rounded the value: return (int) (l * LENGTH_FACTOR + 0.5); In this new patch I use // units of 16 feet with one feet ~ 1/3 meter final static double LENGTH_FACTOR = 3.34 / 16; private static int convertMeters(double l) { return (int) (l * LENGTH_FACTOR + 0.5); } That means that the travel time calculated with this patch is a bit higher. I found the value looking at the travel time for a long "motorway-only" route. The length was 54.5 km, and this formular gets us close to 30 min travel time for an avg. speed of 109 km on motorways. Gerd

1 2

Commit: r3068: Read the high class boundary nodes.
by svn commit 26 Feb '14

26 Feb '14

Version mkgmap-r3068 was committed by steve on Wed, 26 Feb 2014 Read the high class boundary nodes. Not used within mkgmap.

1 0

RoadMerger and adjust-turn-headings
by Gerd Petermann 21 Feb '14

21 Feb '14

Hi WanMil, I think the code for --adjust-turn-headings in RouteNode.tweezeArcs() looks rather similar to that in RoadMerger, and maybe will not work as well in combination with RoadMerger as it assumes that two arcs with the same road (OSM id) are building the "main road": // the code tries to detect a pair of arcs (the "incoming" // arc and the "outgoing" arc) that are the "main road" // and the remaining arc (called the "other" arc) which is // the "side road" I got the impression that RoadMerger also calculates the required data (angles etc). It would be great if RoadMerger could store the information somewhere so that tweezeArcs could use it. Gerd

2 3