March 2014 - mkgmap-dev - The mkgmap lists

error in mkgmap reg. toll roads
by Gerd Petermann 05 Mar '14

05 Mar '14

Hi all, Steve just found out that we have a bug in the NOD header which is related to the drive-on-left option: Only if this option is enabled we set one bit in the header which has a big influence on the routing: You have to switch on "avoid toll roads" in MapSource and Basecamp to be able to route on major roads Instead this bit should always be set, no matter what drive-on-xxx option is used. This bug is very old and I noticed that some people use toll roads in their style. So I wonder if anybody relies on the wrong behaviour or why nobody complained until now? Gerd

1 0

Distorted lines
by Andrzej Popowski 05 Mar '14

05 Mar '14

Hi, I observe badly looking lines. I have attached some pictures and xml objects that doesn't look good on Garmin map. My guess is that there is no proper simplifications for resolution 24bit. Points too dense are removed in a non optimal way which can lead to jagged curves. This could be the reason for bad looking tram railways (file tram1.osm in test.zip). Other reason could be removing of short lines. I think in this case some nodes are moved. It looks like instead of creating a new node in a middle of removed line, first point is used. This can lead to bigger distortion. This is probably the case of road example (file road1.osm). -- Best regards, Andrzej

10 40

removed remove-short-arcs option in r3077
by Gerd Petermann 05 Mar '14

05 Mar '14

Hi all, with r3077 I've removed the remove-short-arcs option in the high-prec-coord branch. Gerd

2 2

high-prec-branch ready for trunk?
by Gerd Petermann 04 Mar '14

04 Mar '14

Hi all, I think the branch is ready as it is. Steve and I are still working on a new algo to calculate the NOD data (routing information), but this doesn't depend on high precision and should be done in a different branch. In short, the branch produces smaller img files with nicer looking lines and shapes and slightly improved routing and requires around 10% more cpu time. If I hear no complains I'll merge on March 6. Gerd P.S. The more detailed changes in the branch compared to trunk r3072 are: 1) the program keeps the higher precision of OSM data ( precision ~ 5 cm, presuming that OSM data is precise) and tries to detect situations where the rounding to Garmin map units (precision ~ 2.4 m) causes distorted lines. The effects are "rounder" roundabouts and "straigter" straight roads. A nice side effect is that the algo drops a lot of points which makes img size smaller. 2) polygons with equal attributes are merged and the remaining points are filtered to also remove distortions. The positive effects are - smaller img size - nicer looking buildings, see previous post http://gis.19327.n5.nabble.com/shape-merger-in-high-prec-coord-branch-tp579… A negative effect of the current implementation is that two different algos are used for lines and shapes, e.g. coastlines may differ from the sea shapes. It is planned to correct that in the near future . 3) Restriction relations are no longer written in a format that prohibits pedestrians and emergency (unless the style requests that) 4) the code for the option --link-pois-to-ways was rewritten, see http://gis.19327.n5.nabble.com/Patch-v2-link-pois-to-ways-and-restrictions-… 5) a few optimizations and corrections in the NOD data reduce the size of the NOD file and seem to correct some routing problems. This is not related to high-precision. 6) Precompiled boundary and sea data is ~30% larger as it contains more points, and also calculaion time for them increased (this is related to higher precision). It is probably possible to change that also, for now that means larger downloads.

6 6

Limit in MapSplitter
by Gerd Petermann 04 Mar '14

04 Mar '14

Hi all, we have a limit in mkgmap that doesn't allow to have more than 255 POI in an area of 10x10 map units. If this limit is reached, you see the "Area too small to split at ...(reduce the density of points, length of lines, etc.)" message Technically it is no problem to solve this, e.g. we can create overlapping areas and distribute the points, but I wonder if that would be of any use? Gerd

1 0

[Patch v1] ignore duplicate POI
by Gerd Petermann 04 Mar '14

04 Mar '14

Hi all, attached patch ignores repeated POI, typically generated by the --add-poi-to-line feature in combination with a style that doesn't check the mkgmap:line2poitype=inner tag. If two or more POI with equal tags appear in sequence. This might help to avoind the problem reported by Stephen. @Stephen: I think you should also check your style. Did you change it as requested here ? http://www.mkgmap.org.uk/news/2013/12/22/more-flexibility-in-style-files-st… Gerd

1 0

additional arcs patch
by Gerd Petermann 03 Mar '14

03 Mar '14

Hi all, attached is a patch for r3065 in the high-prec-coord branch. It should improve long distance routing, as it adds additional arcs from minor roads to major roads (so called indirect links). Maybe the improvement is only seen on the device. It would be great to hear some test results (good or bad), compared to trunk r3057 and compared to r3065. A compiled binary is here: http://files.mkgmap.org.uk/download/179/mkgmap.jar Gerd

7 15

splitter exception
by thesurveyor＠wolke7.net 02 Mar '14

02 Mar '14

2 2

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