- mkgmap-dev - The mkgmap lists

Commit: r2508: minor performance improvement: remove superflous hashmap originalWay
by svn commit 27 Feb '13

27 Feb '13

Version 2508 was committed by gerd on Wed, 27 Feb 2013 minor performance improvement: remove superflous hashmap originalWay used to match restrictions. There is no need for a hashmap, we just have to compare the ids of the ways.

1 0

Commit: r2507: let mp-cut produce predictable results
by svn commit 27 Feb '13

27 Feb '13

Version 2507 was committed by gerd on Wed, 27 Feb 2013 let mp-cut produce predictable results - mpr_consistency_v1.patch by WanMil - use LinkedHashMap

1 0

Random changes in img file sizes since r2477
by GerdP 26 Feb '13

26 Feb '13

Hi, I think something is wrong. I get different output img file sizes for the same input files and parms and program. With each run, some files are a bit larger or smaller than before. My options: --max-jobs --preserve-element-order -c template.args This doesn't happen with r2476 and older versions, first rel with the problem is r2477 which brought the new mp-cut algo. @WanMil: Is it possible to change that? Ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Random-changes-in-img-file-sizes-since-r2477… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 6

length () in relations file
by Felix Hartmann 26 Feb '13

26 Feb '13

What about the length function for relations? I know this once was supported in the functions branch (or at least previous patches before the branch existed). Does such a function make sense: route=bicycle & ( distance>300 | length() > 300000 ) { apply .... } ?? Currently this puts out an (usable) error that length is not supported in relations file. Is this not implementable to to superrelations and their like? -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

7 13

Commit: r2506: remove a few warnings, no functional change
by svn commit 26 Feb '13

26 Feb '13

Version 2506 was committed by gerd on Tue, 26 Feb 2013 remove a few warnings, no functional change

1 0

patch code simplification
by GerdP 26 Feb '13

26 Feb '13

Hi, in StyledConverter we use a HashMap originalWay to store changed ways. I did not find a reason for that. The attached patch simplifies the source a little bit by replacing the search in the HashMap with a simple compare of the way id. simplifyStyledConverter.patch <http://gis.19327.n5.nabble.com/file/n5749299/simplifyStyledConverter.patch> Gerd -- View this message in context: http://gis.19327.n5.nabble.com/patch-code-simplification-tp5749299.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 1

[i18n] Feature proposal for non-latin codepages
by Steffen Breitbach 26 Feb '13

26 Feb '13

Hi everyone! I'm struggling with i18n on my Oregon 450. To make a long story short: altough the map itself is OK (Japanese map with codepage 932), the device will not display any characters at all (not even latin ones). I have tried virtually everything and come to the conclusion (for now) that the solution is not in the device or its software (at least not for now). Then I had a look at the OSM raw data (OSM/XML) and found out, that labels are not in japanese only. Most nodes that have names have a tag set like this (don't know if my mail client will handle the Kanji characters properly): <node id="236578577" lat="35.7206495" lon="139.7787494" user="JaTrainWikipedia" uid="1008753" visible="true" version="10" changeset="13836660" timestamp="2012-11-11T18:09:02Z"> <tag k="name" v="鶯谷 (Uguisudani)"/> <tag k="name:en" v="Uguisudani"/> <tag k="name:ja" v="鶯谷"/> <tag k="name:ja_rm" v="Uguisudani"/> <tag k="name:ru" v="Угуисудани"/> <tag k="railway" v="station"/> <tag k="wikipedia" v="ja:鶯谷駅"/> </node> There are two tags that are particulary interesting: "name:ja_rm", the romanized version of the Japanese characters and "name:en", the english version of the name (wich might be in most, but not in all cases, the same thing). I suppose the binary format also contains this information?! If there was an option like "--tag-names=ja_rm" or something like that that would allow me to compile a map containing only latin characters, I could have 2 maps: one for Mapsource/BaseCamp with proper Japanese labels and one containing the romanizations only for my device. I would love to contribute the code necessary, but I'm less than bad at java coding :-( What do you think of this feature proposal? Regards Steffen

2 2

Commit: r2503: correction: o5m reader did called onAddNode() for each tag.
by svn commit 25 Feb '13

25 Feb '13

Version 2503 was committed by gerd on Mon, 25 Feb 2013 correction: o5m reader did called onAddNode() for each tag. This caused multiple identical entries in the exits list.

3 2

Commit: r2504: adapt expected test value to change in highwayCount handling
by svn commit 25 Feb '13

25 Feb '13

Version 2504 was committed by gerd on Mon, 25 Feb 2013 adapt expected test value to change in highwayCount handling

1 0

Problem using housenumber option
by Jack Ughetta 24 Feb '13

24 Feb '13

Hi, I'm trying to generate a map of Italy using house numbers option (--x- housenumbers) with latest mkgmap (r2494). I see this output traces: java.lang.IllegalArgumentException at uk.me.parabola.imgfmt.app.BitWriter.putn(BitWriter.java:89) at uk.me.parabola.imgfmt.app.net.NumberPreparer.writeInitialValue (Number Preparer.java:174) at uk.me.parabola.imgfmt.app.net.NumberPreparer.fetchBitStream (NumberPre parer.java:69) at uk.me.parabola.imgfmt.app.net.RoadDef.writeNet1(RoadDef.java:203) at uk.me.parabola.imgfmt.app.net.NETFile.write(NETFile.java:66) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:220) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:97) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:61) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:201) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:198) 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) Exiting - if you want to carry on regardless, use the --keep-going option and the gmapsupp.img is not created at all. Trying to debug a little bit, i found that the problem seems to be related to this OSM element: <relation id="2198742" user="Pab09" uid="178610" visible="true" version="2" changeset="13345939" timestamp="2012-10-03T11:17:51Z"> <member type="way" ref="31563508" role="outer"/> <member type="way" ref="165015469" role="outer"/> <tag k="addr:housename" v="Hidron"/> <tag k="addr:housenumber" v="055892500"/> <tag k="addr:postcode" v="50013"/> <tag k="addr:street" v="Via di Gramignano"/> <tag k="leisure" v="sports_centre"/> <tag k="name" v="Hydron"/> <tag k="sport" v="swimming"/> <tag k="type" v="multipolygon"/> </relation> As you can see, addr:housenumber is not a valid house number (in fact it seems to me a telephon number !). However, there is, possibly, a missing check on what is supposed to be a valid housenumber (probably a sort of sanity check is needed: not all numbers could be used as house numbers, at least in relation to garmin img format limitations). I'm not sure, but I think the same problem is present with other OSM element, at least, in Italy. Thank you to all of you for your attention and for your excellent work ! ggalli

5 14