- mkgmap-dev - The mkgmap lists

frig-roundabouts doesn't work
by GerdP 28 Sep '13

28 Sep '13

Hi, The option is described in the wiki, and I find a peace of source in the HighwayHook that evaluates it, but it doesn't work. What is missing? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/frig-roundabouts-doesn-t-work-tp5748545.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 3

Commit: r2714: Make java 1.7 mandatory and refuse to run on earlier versions.
by svn commit 27 Sep '13

27 Sep '13

Version 2714 was committed by steve on Thu, 19 Sep 2013 Make java 1.7 mandatory and refuse to run on earlier versions.

5 10

merge-roads branch verry bugged...
by Felix Hartmann 26 Sep '13

26 Sep '13

I needed to revert to version 2715. ...2716 is the version which really breaks on my styles. There are for sure quite a lot serious bugs in 2716 and later... I'm sorry that I cannot relly help on tracking down the bugs - I'm currently in China, and haven't got much time, nor anything that we would consider usable internet in Europe (cannot reach my own SVN for example and lots of other things blocked - VPNs working unrealiably for productive tasks, and speed is max 256Kbit up, 2-3Mbit down) -- on the up to date - merge-roads rev 2722 many of my maps fail to compile - the usual is like countless errors due to identical road id (and rev 2721 really made this much worse. With 2717 I only get like 20 for Switzerland instead of uncountable), then (not for all countries) java.lang.assertionError: SEVERE (StyledConverter): c:\openmtbmap\maps\63710216.osm.pbf: Road with identical id: 238840783 ..... uncountable amount of, then: java.lang.AssertionError at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.match(HousenumberGenerator.java:322) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:195) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:389) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:244) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) java.lang.AssertionError at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.match(HousenumberGenerator.java:322) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:195) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:389) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:244) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) java.lang.AssertionError at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.match(HousenumberGenerator.java:322) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:195) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:389) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:244) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:127) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:243) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:239) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)

4 4

Style processor skips rule with tags added in style
by WanMil 25 Sep '13

25 Sep '13

Hi, I observed an unexpected behaviour of the style processor while checking the new access rules in the merge_roads branch. Assume the following way: highway=path And the lines file: highway=path {add test=yes} test=* [0x8] highway=path [0x9] I would expect that a line with garmin type 0x8 is created. But the 2nd rule is not considered and therefore a line with garmin type 0x9 is created. @Steve: Can you have a look at it? Attached you find the described test case. The merge_roads branch makes extended usage of such a pattern (see the inc/access file). Thanks! WanMil

2 2

special cases with short arcs
by GerdP 25 Sep '13

25 Sep '13

Hi, I am trying to find a better algo for the handling of short arcs. (Garmins routing algo refuses to route over short arcs) The typical case of a short arc is a crossing like here: http://www.openstreetmap.org/browse/node/1449682318 We don't lose much information if we merge the node with node 1303933872, so merging is a good idea here. On the other hand I stumbled across a few cases were I am not sure what to do. I many cases I'd prefer to move one of the two nodes so that the arc gets longer. See e.g. http://www.openstreetmap.org/browse/way/47138169 The first two points of the way build a short arc (2.8 m), while the next arc to point 267185122 is > 33m. The merging of these two nodes will produce a map which implies that you can turn right directly at the end of the bridge http://www.openstreetmap.org/browse/way/47138168 I think it would be better to move the node 627157116 a little bit closer to the next point 267185122. A similar case: The bridge at http://www.openstreetmap.org/browse/way/131860005 has a length of ~ 4.99 m. With the default value 5m, this is considered to be a short arc and short-arc-removal will remove the bridge by merging the two end points. On the other hand, a (service) road with just two points, one point connected to a road, the other not connected to a road should be removed if it is a short arc instead of eventually moving the point connected to the road (as this produces the zig zag lines as posted by popej (road.png): http://gis.19327.n5.nabble.com/Distorted-lines-tp5775761.html (this one is easy to detect and I can create a simple patch) I don't know yet how to implement all this, so I'd like to make sure that I am not investing much time into a wrong solution. Comments? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/special-cases-with-short-arcs-tp5778708.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 10

some minor problems
by Andrzej Popowski 23 Sep '13

23 Sep '13

Hi, here list of some minor problems, that I have noticed while using mkgmap: 1. For mp format multiple data0= lines are interpreted wrongly. For polylines each data0 should create separate line. Mkgmap connect them which is wrong. I observe the same effect with OSM data, when I remove middle part of the way with osmosis. But this could be osm format problem. There is something wrong with polygons in mp format too, I haven't investigated it. I think first data0 in polygon is outer shape and subsequent data0 should be treated as holes (inner polygons). 2. There are some problems with style defined in "levels" instead of "resolution". Maximum level number seems to be fixed at 4, regardless off options --levels and --overview-levels. 3. There should be maximum limit of subdivision in TRE subfile, probably it is 0xFFFF. I'm not sure if mkgamp checks this value for overflow. I can create an img which is correct for mkgmap but not visible in Mapsource (ok, I'm toying with MAX_DIVISION_SIZE in MapSplitter.java, but this seems quite innocent). -- Best regards, Andrzej

1 0

Transliteration with --code-page
by Steve Ratcliffe 21 Sep '13

21 Sep '13

Hi [ I'm making this a separate thread as it was previously in the 'mdr20 value changed' thread which is a mostly unrelated bug. ] Currently ascii and latin1 are special in that any character that can not be represented in those character sets is transliterated to ascii/latin1. When using any other code page then any character that cannot be represented is replaced with a question mark. I've created a patch that is currently in the 'transliteration' branch which makes it possible to use any code page and still get transliteration to ascii for any other character that is not in the code-page. I'll merge it in a couple of days if no one finds any problems. ..Steve

1 0

setMdr20 exception
by Michał Rogala 21 Sep '13

21 Sep '13

Hi! After upgrading to the release 2679 i get such exception during map compilation: Exception in thread "main" java.lang.AssertionError: mdr20 value changed f=293 t =295 count=357 at uk.me.parabola.imgfmt.app.mdr.Mdr5Record.setMdr20(Mdr5Record.java:129 ) at uk.me.parabola.imgfmt.app.mdr.Mdr20.buildFromStreets(Mdr20.java:116) at uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:312) at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:252) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinishForDevice(MdrBuild er.java:382) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuil der.java:161) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:560) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja va:128) at uk.me.parabola.mkgmap.main.Main.main(Main.java:119) I suppose that root of the problem lays in --lower-case --code-page=1250 switches, because without them everything works fine. Thank you in advance for any help :).

2 7

switch to java 1.7
by GerdP 19 Sep '13

19 Sep '13

Hi, I did not see any complains regarding the switch to 1.7. Up to now I still compile and test with 1.6, is it ok to do the switch now? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/switch-to-java-1-7-tp5778082.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 2

Commit: r2704: Fix for 'mdr20 value changed' message.
by svn commit 17 Sep '13

17 Sep '13

Version 2704 was committed by steve on Sun, 15 Sep 2013 Fix for 'mdr20 value changed' message. Space was being treated as a non-character so any names that differed only by a space would be treated the same during sorting although not during separation into different streets while building the index. This would be very unlikely to cause problem in normal circumstances, but when you have another country with names that cannot be represented in 1250 then all the names turn into sequences of question marks. In that case is likely eventually that you will get something like '??? ??' and '?? ???' followed by '??? ??' again, which sort the same but are seen as different separating the streets while building the index. The second '??? ??' causes a problem because it has already been dealt with.

3 4