- mkgmap-dev - The mkgmap lists

mkgmap2586
by steve sgalowski 06 May '13

06 May '13

i have just downloaded the latest mkgmap2585 unzipped it and run it on a small map of the philippines and it still has the same errors , even with the merge-lines added into the compile code zoom level 17 has the error ? do i need to add any other codes to the compile code to fix this Stephen .

2 1

StyledConverter.addRoadAfterSplittingLoops and roundabouts
by WanMil 05 May '13

05 May '13

Hi programmers, the StyledConverter.addRoadAfterSplittingLoops seems to splits each roundabout at least into two MapRoad objects because they contain the same point twice (start and end point). I wonder if that's the desired function? The comment says: // check each point in the way to see if it is the same // point as a following point in the way (actually the // same object not just the same coordinates) But I think it's curious that Garmin would not allow that for roundabouts. WanMil

2 2

Commit: r2586: merge-lines-v2.patch: use merge-lines for all lines in all resolutions, except for roads in res 24. Enable merge-lines per default.
by svn commit 05 May '13

05 May '13

Version 2586 was committed by gerd on Sun, 05 May 2013 merge-lines-v2.patch: use merge-lines for all lines in all resolutions, except for roads in res 24. Enable merge-lines per default.

1 0

merge-lines and routing
by GerdP 04 May '13

04 May '13

Hi, the help file says merge-lines < ... > At the moment this option causes routing errors. Use only if routing is not needed in your map. Maybe I found the reason for the routing errors: If the segments of a road are merged, it might happen that the LineSplitterFilter has to split it because it has more than 250 points. The current implementation of LineSplitterFilter does this: The first part of a road is added as a road, all remaining parts are added as lines. With a simple change all parts are added as roads: Index: LineSplitterFilter.java =================================================================== --- LineSplitterFilter.java (revision 2581) +++ LineSplitterFilter.java (working copy) @@ -84,7 +84,7 @@ log.debug("saving next part"); l.setPoints(coords); next.doFilter(l); - l = new MapLine(line); + l = line.copy(); count = 0; first = false; The interesting part for me is that the following routines seem to expect exactly this, but parts of the code was never executed. See also http://gis.19327.n5.nabble.com/PATCH-v1-highwayCount-tp5748554p5748864.html I also wonder if it really makes sense to limit the check "Non-routable way with routable type ..." to resolution 24. I'll try to find out more tomorrow. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/merge-lines-and-routing-tp5758913.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 26

Commit: r2585: correct check regarging non-routable type usage: check only on resolution 24
by svn commit 04 May '13

04 May '13

Version 2585 was committed by gerd on Tue, 30 Apr 2013 correct check regarging non-routable type usage: check only on resolution 24

4 4

garmin 08 and 09 error
by steve sgalowski 03 May '13

03 May '13

how can i correct the codeing now , so that i can make my maps again as i have a non- routable way now in all of my maps with a garmin 08 , 09 error code Stephen

3 7

reducing output map size
by Jozef Riha 03 May '13

03 May '13

hello, is there a way how can i say which features are taking up the most space in resulting map? there may be some space for optimizations but i don't really know where to start. thanks! jose

4 6

question reg. display tool
by GerdP 02 May '13

02 May '13

Hi Steve, the NetCheck displays some messages like this: ERROR: node-count=6, nblocks=0 [VIA VITTORIO VENETO] 1afd I don't understand why the node-count value is compared with def.nblocks The write routine in mkgmap doesn't write the number of nodes to the place where display tool reads the def.nblocks value. Am I missing something? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/question-reg-display-tool-tp5759106.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 4

Is there a character limit concering the search index ?
by toc-rox 30 Apr '13

30 Apr '13

I have this POI (OSM-Node 1379747163 at N50 20.132 E9 37.533) with a very long name: The search (with BaseCamp) for "Kunstobjekt" leads to nothing ... but the search for "Kunstobjek" is successful. Question: Is there a character limit concering the search index ? Regards Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Is-there-a-character-limit-concering-the-sea… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 3

Commit: r2584: update doc: name-tag-list option removed
by svn commit 29 Apr '13

29 Apr '13

Version 2584 was committed by gerd on Mon, 29 Apr 2013 update doc: name-tag-list option removed

1 0