July 2009 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Problem with styles
by sonke016＠planet.nl 05 Aug '09

05 Aug '09

I now have put the style folder in the mkgmap base map, and --style=fiets doesn't seem to work. Do I have to put the style in a zip-file? Willem1 > sonke016 at planet.nl schrieb: > > I have a problem when I'm trying to use a style. If I create a style, > > for example "fiets", put it in the folder > > "mkgmap\resources\styles\fiets", and I use the command > > > > java -jar mkgmap.jar map.osm --tdbfile --style-file=styles\fiets > > then mkgmap just uses the default style. I tried almost everything: > > using --style, using quotation marks, using > > --style-file=resources\styles\fiets etc. > > I think, the path of the style must be relative to your working > directory. So when you are running in the mkgmap directory, the > parameter --style-file=resources\styles\fiets should work. > > Or you can put the fiets folder as a subfolder under your working > directory, then the parameter would be --style=fiets. > > Gruss > Torsten

6 5

Magic highway symbols on Vista CX failing
by Alexander Wittig 03 Aug '09

03 Aug '09

Hello I seem to have a problem with the default style and the highway tagging on my Garmin Vista CX with mkgmap rev. 1114. When I tag highway=secondary, name=Grand River and ref=MI 123, the result is a road with name "Road". It works as expected, however, with highway=primary. So I did some research and I think the problem is that not all of the "magic" symbols in src/uk/me/parabola/mkgmap/osmstyle/actions/HighwaySymbolFilter.java are available on the unit. Also they are named wrongly for this unit. I made an OSM test file[1] to check all symbol names given in the above source file. It contains parallel road segments with ref=MI 43 name=Grand River I-VI and highway tags of motorway,trunk,primary,secondary,tertiary,residential respectively. Then I used a slightly modified default line style[2] (which assigns one highway symbol to each of the above road types) to generate a map[3] with the --gmapsupp command switch. After uploading the result to my Vista CX, it renders like in this picture[4]. The styles are (from bottom to top): interstate,shield,round,hbox,box,oval. Some remarks: * Styles "interstate" and "shield" look exactly like hbox and box but they prepend "US" and "Hwy." to the reference (only appears when hovering the pointer over the street). This is not so useful for OSM data, since the US tagging scheme in the Wiki says those should be included in the ref tag (i.e. ref="I 94" or ref="US 127"). * Style "box" is misnamed, as it produces an oval * Style "oval" does not work, it seems to break the entire name of the road * Style "round" is misnamed, it produces a framed box I don't know how other units render these symbols, so I can't say whether the names should be changed or not. But I do think that "oval" should at least not be used in the default style for secondary roads, as it actually breaks the name display on my (not quite uncommon) unit. If you need more information or want me to run more tests, please let me know. Alexander [1] http://alex.wittig.name/sonstiges/mkgmap/test.osm [2] http://alex.wittig.name/sonstiges/mkgmap/lines [3] http://alex.wittig.name/sonstiges/mkgmap/gmapsupp.img [4] http://alex.wittig.name/sonstiges/mkgmap/P1020125.JPG

3 4

Translating command line strings into target charset
by Marko Mäkelä 01 Aug '09

01 Aug '09

My friend, who owns a Garmin GPSMap 60CSx, notified me of a character set problem in a tile name of my map. I wasn't aware of the problem, because my Edge 705 does not display map tile names. The tile Etelä-Suomi (Southern Finland) appears as EtelÃ¤-Suomi, where the currency symbol ¤ is displayed as a black diamond. Other ä characters in the gmapsupp.img are encoded as the byte code 304 in octal notation. The workaround should be simple: in mkgmap.args, write the ä as \304 instead of using UTF-8. But I would except the parameter to be translated. After all, the style files are already interpreted as UTF-8. I think that the right fix of this bug would be such that \u escape codes are expanded before utf-8 to target character set translation, and hex and octal escape codes (\xC4, \304) are expanded after the translation. That would also allow us to embed Garmin control characters where desired. Also, I would like to have some transliteration in the UTF-8 to cp1252 (latin1) translation. The Garmin displays many latin1 and cp1252 code points as a black diamond, as I posted some time ago. We could avoid that by translating those code points. I attempted to override the built-in translation (in the JRE as far as I understood) some time ago, but I must have patched the wrong place, because my changes had no effect. Any hints, Steve? Regards, Marko

2 1

"board Ferry"
by Valentijn Sessink 01 Aug '09

01 Aug '09

Hi list, As I was biking around with my brand new, (only €66) Nuvi 205, I noticed that, while the regular map says "Ga. Aan Boord. Veerboot.", the mkgmap made map just lets you drive straight into the water. Maybe there's something special about a ferry terminal point? The map shows the ferry line all right and it routes over it, so that's not the problem. Also, when simulating the journey, there's a boat sign on the Nüvi (where you normally have the arrows telling you how to turn), while the OSM map just shows an arrow telling you where the next turn is (on the other side of the water). An interesting detail is, that the Nüvi, in simulation mode, will wait for the ferry to leave, it just sits there, waiting for the virtual ferry to reach the virtual other side. This is both with the Garmin and the OSM map, and it means that the ferry *line* is interpreted as a ferry, so here the OSM map is all right. It's just the boarding itself that is lacking. Best regards, Valentijn

2 1

[PATCH] multipolygons not showing
by Christian Gawron 31 Jul '09

31 Jul '09

The attached patch (which changes just one line) fixes a problem with multipolygons sometimes not showing. Best wishes Christian Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java =================================================================== --- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (Revision 1115) +++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (Arbeitskopie) @@ -54,8 +54,7 @@ if (w != null) { List<Coord> pts = w.getPoints(); int[] insert = findCpa(outer.getPoints(), pts); - if (insert[0] > 0) - insertPoints(pts, insert[0], insert[1]); + insertPoints(pts, insert[0], insert[1]); pts.clear(); } }

1 0

success with roadtrip, gmapibuilder
by Greg Troxel 31 Jul '09

31 Jul '09

I have been trying for a while to build my own maps with mkgmap, and was getting bad maps into RoadTrip. I figured out what I was doing wrong and thought I'd share it. I had run the splitter and then mkgmap, creating a gmapsupp.img overall map file in addition to all the tiles. I ran gmapibuilder with the gmapsupp.img instead of the individual tiles, and this produces a totally broken gmapi. I spiffed up the caveats section under command line to try to warn others: http://wiki.openstreetmap.org/wiki/Gmapibuilder Here's what I'm doing now, and it seems to work except routing is broken on my vista hcx, perhaps due to some messed up ways in the mass data. #!/bin/sh INPUT=$1 if [ "$INPUT" = "" ]; then INPUT=massachusetts.osm fi cd $HOME/OSM || exit 1 if true; then rm -f 6324* 40000001.* areas.list template.args java -Xmx2000m -jar splitter.jar \ --max-nodes=500000 \ $INPUT \ > OUT.01.splitter 2>&1 ed template.args <<EOF g/^description:/d w EOF fi # --net is implied by --route java -enableassertions \ -Xmx2048m \ -jar mkgmap.jar \ --max-jobs=1 \ --gmapsupp \ --tdbfile \ --series-name="OSM_gdt_series" \ --family-name="OSM_gdt_family" \ --area-name="OSM_gdt_area" \ --overview-mapname=63240000 \ --family-id=632 \ --product-id=1 \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="MA" \ --region-name="Massachusetts" \ --description="OSM_gdt" \ --route \ --add-pois-to-areas \ --remove-short-arcs \ -c template.args \ > OUT.02.mkgmap 2>&1 # --ignore-osm-bounds \ # --mapname=63249900 \ mkdir -p GMAPI /Users/gdt/SOFTWARE/GMAPIBUILDER/gmapi-builder/gmapi-builder.py -o GMAPI -t 63240000.tdb -b 63240000.img -v 6324*.img > OUT.03.gmapi 2>&1 ls -lh gmapsupp.img

1 0

Commit: r1115: Fix infinite loop when an action changes a tag in the condition.
by svn commit 31 Jul '09

31 Jul '09

Version 1115 was commited by steve on 2009-07-31 11:44:16 +0100 (Fri, 31 Jul 2009) Fix infinite loop when an action changes a tag in the condition. You should still avoid actually doing this.

2 1

Routing across multiple tiles
by MarkS 31 Jul '09

31 Jul '09

I'm trying out maps with routing turned on. The routing seems to work fine within a single map tile, it also works fine when I route to a neighbouring tile. However, if I route across multiple tiles then it always fails. Mapsource just spends ages and then draws a straight line whilst my garmin counts to 100% and says their was a calculation error. Am I doing something wrong or is this something we are aware of?

3 8

comparing numeric values
by Torsten Leistikow 30 Jul '09

30 Jul '09

Moin, in the style rules documentation in the WIKI it is stated, that a comparison of numeric quantities is possible, e.g. "maxspeed>=30". Is this really working? I tried the following example: In my osm file I had five ways: <way id='-9902' action='modify' visible='true'> <nd ref='-9900' /> <nd ref='-9901' /> <tag k='highway' v='null_null' /> <tag k='layer' v='-1' /> <tag k='name' v='layer=-1' /> </way> <way id='-9912' action='modify' visible='true'> <nd ref='-9910' /> <nd ref='-9911' /> <tag k='highway' v='null_null' /> <tag k='layer' v='0' /> <tag k='name' v='layer=0' /> </way> <way id='-9922' action='modify' visible='true'> <nd ref='-9920' /> <nd ref='-9921' /> <tag k='highway' v='null_null' /> <tag k='name' v='layer!=*' /> </way> <way id='-9932' action='modify' visible='true'> <nd ref='-9930' /> <nd ref='-9931' /> <tag k='highway' v='null_null' /> <tag k='layer' v='1' /> <tag k='name' v='layer=1' /> </way> <way id='-9952' action='modify' visible='true'> <nd ref='-9950' /> <nd ref='-9951' /> <tag k='highway' v='null_null' /> <tag k='layer' v='+1' /> <tag k='name' v='layer=+1' /> </way> And in my style the lines-file contained the following rules: highway=null_null & layer<0 [0x01 resolution 10] highway=null_null & layer=0 [0x02 resolution 10] highway=null_null & layer>0 [0x03 resolution 10] highway=null_null & layer='-1' [0x04 resolution 10] highway=null_null & layer='0' [0x05 resolution 10] highway=null_null & layer='1' [0x06 resolution 10] highway=null_null & layer='+1' [0x07 resolution 10] highway=null_null [0x08 resolution 10] As a result I expected the following conversions 9902 -> 0x01 9912 -> 0x02 9922 -> 0x08 9932 -> 0x03 9952 -> 0x03 Against my expectations the conversions were the following: 9902 -> 0x03 9912 -> 0x05 9922 -> 0x08 9932 -> 0x03 9952 -> 0x03 What is wrong? - My understanding of the style rules? - The documentation of the style rules? - The behaviour of mkgmap? Gruss Torsten

3 6

vanishing map
by Valentijn Sessink 30 Jul '09

30 Jul '09

Hello list, After a long search, here's the (lacking of) results. Eventually, I found a single node on the map that would stop the map from blanking. However, when I made the map just be a tiny bit larger, it would vanish again - with or without the node. So the blanking is probably the result of a subtle interaction between (sub)map element count and tile position. Or something like it. Or something completely different. Best regards, Valentijn

4 5