February 2013 - mkgmap-dev - The mkgmap lists

[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

Commit: r2502: Remove unused handling of mkgmap:on-boundary
by svn commit 24 Feb '13

24 Feb '13

Version 2502 was committed by wanmil on Sun, 24 Feb 2013 Remove unused handling of mkgmap:on-boundary

1 0

Commit: r2495: -- Increment highwayCount only for nodes of roads. This reduces the size
by svn commit 24 Feb '13

24 Feb '13

Version 2495 was committed by gerd on Fri, 22 Feb 2013 -- Increment highwayCount only for nodes of roads. This reduces the size of the img file -- remove dead code in ElementSaver

4 3

bollards cause routing breakage
by chris66 24 Feb '13

24 Feb '13

> Route Calculation (even to short distance destinations) often stops at > 68% or 81% with error message "not enough memory". This is caused by the bollard-handling. Details: In order to improve car routing I made footways and path non routable: highway=footway|highway=path [0x16 resolution 24] This is the route which causes Garmin Nuvi to overflow: <http://osrm.at/2sm> There is a path with a cyclebarrier : <http://www.openstreetmap.org/browse/node/693140576> For barriers I use this rule (more or less the same as in default style): barrier=block | barrier=cycle_barrier | barrier=stile | barrier=kissing_gate {add access=no; add bicycle=yes; add foot=yes} [0x660f resolution 24] The routing is working okay when NOT using --link-pois-to ways. Greetings Chris

3 4

Commit: r2501: House numbers, edge cases
by svn commit 23 Feb '13

23 Feb '13

Version 2501 was committed by steve on Sat, 23 Feb 2013 House numbers, edge cases Abandon ranges that are greater than the max which is 2^17.

1 0

Commit: r2500: House numbers, edge cases
by svn commit 23 Feb '13

23 Feb '13

Version 2500 was committed by steve on Sat, 23 Feb 2013 House numbers, edge cases Prevent initial values that are too large from causing an exception. The largest value is 2^20 ie 1,048,576.

1 0

["PATCH" v1] Housenumber search for OSM data
by WanMil 23 Feb '13

23 Feb '13

Hi all, I have implemented a first prototype to support housenumber search for OSM input data. This is already possible for polish format but not for OSM. Don't expect anything when trying the patch but I wanted you to take part on the first small steps of the housenumber integration. This is what the patch does: 1. Collect all nodes and ways/polygons tagged with addr:housenumber and addr:street 2. Collect all roads 3. For all elements collected in 1. get the closest road with equal name 4. Attach the housenumbers to the first routing segment of the road. Yes that's wrong - but at the moment I don't know how to forecast in which routing segments the road will be divided. Warning: The patch is a quick hack (~4 hours). It's undocumented. It's unperformant. It's mostly untested. ... But it's the first time one can search for housenumbers with OSM as input :-) Thanks Steve for implementing the new feature housenumber search! WanMil

3 6