- mkgmap-dev - The mkgmap lists

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

[PATCH] More barriers, kindergarten and shop polygon
by Ondrej Novy 30 Jul '09

30 Jul '09

Hi, attached patch add more barriers types, kindergarten and for every shop render polygon. Thanks. -- S pozdravem/Best regards Bc. Ondrej Novy Email: novy(a)ondrej.org Jabber: onovy(a)njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207

1 1

Clearing mapsource tile cache
by Mark Burton 30 Jul '09

30 Jul '09

Hi Garvan, I just deleted this folder C:\Documents and Settings\markb\Application Data\GARMIN\MapSource\TileCache and I think it did the trick (obviously, change the user name to your own) Cheers, Mark

3 2

Large multipolygons not working?
by Christian Gawron 29 Jul '09

29 Jul '09

Attached are two very simple osm files which show an "island" in a water polygon added by hand. Both are connected with a multipolygon relation. The difference between the to files is just the size of the island. The multipolygon is rendered correctly in the map resulting from test1.osm but not in the one resulting from test2.osm. This may be the result of a bug in the polygon splitting algorithm. This problem also occurs when I try to create a map of Corsica with the sea added by hand. Best wishes Christian

1 0

a routing problem
by Valentijn Sessink 29 Jul '09

29 Jul '09

Hello list, The following inter tile routing gives nice and unexpected results. areas.list: 63240001: 0x241000,0x25000 to 0x24d000,0x3b000 63240002: 0x24d000,0x25000 to 0x251000,0x34000 63240003: 0x24d000,0x34000 to 0x251000,0x3b000 63240004: 0x241000,0x3b000 to 0x24b000,0x42000 63240005: 0x241000,0x42000 to 0x24b000,0x53000 63240006: 0x24b000,0x3b000 to 0x251000,0x41000 63240007: 0x24b000,0x41000 to 0x251000,0x53000 63240008: 0x251000,0x25000 to 0x255000,0x39000 63240009: 0x251000,0x39000 to 0x255000,0x40000 63240010: 0x255000,0x25000 to 0x263000,0x40000 63240011: 0x251000,0x40000 to 0x259000,0x49000 63240012: 0x251000,0x49000 to 0x259000,0x53000 63240013: 0x259000,0x40000 to 0x263000,0x48000 63240014: 0x259000,0x48000 to 0x263000,0x53000 (You don't need all areas, but I don't know a trivial way to know which map part is which split). Then run: java -Xmx1600m -enableassertions -jar ../splitter/dist/splitter.jar --split-file=areas.list netherlands.osm java -enableassertions -Xmx1800m -jar ~/garmintest/mkgmap/dist/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --remove-short-arcs --lower-case --preserve-element-order --location-autofill=1 --gmapsupp --route --net --tdbfile -c template.args Then load the attached tdb-file in MapSource.exe. You'll notice three waypoints, A, B and C, all three on a different tile, A and B being adjacent and B and C also. Mapsource will route from A to B, from B to C and from A to B via C, but it will not route from A to C. I don't have my Garmin Nüvi at hand, so I can't test it there - if you want me to, I'll be able to do that in the evening if you want me to. Best regards, Valentijn

3 8

Commit: r1114: Allow numeric quantities to be negative.
by svn commit 29 Jul '09

29 Jul '09

Version 1114 was commited by steve on 2009-07-29 21:01:06 +0100 (Wed, 29 Jul 2009) Allow numeric quantities to be negative.

1 0

Commit: r1113: Test for comparasons in style files.
by svn commit 29 Jul '09

29 Jul '09

Version 1113 was commited by steve on 2009-07-29 20:37:25 +0100 (Wed, 29 Jul 2009) Test for comparasons in style files. Next will get it to work.

1 0

Commit: r1112: Improve (perhaps even completely fix) the behaviour at the edge of a map.
by svn commit 29 Jul '09

29 Jul '09

Version 1112 was commited by steve on 2009-07-29 19:24:44 +0100 (Wed, 29 Jul 2009) Improve (perhaps even completely fix) the behaviour at the edge of a map. The bug was that if you were close to the edge you could get strange behaviour such as disapearing map when zooming in really close and tool tips not appearing when hovering over roads. This fixes the subdivision width and height calculations to be more correct at lower zooms, especially when the full width is an odd number. I was going to do more than this, but it seems to work well as it is.

1 0

[PATCH] Building resolution
by Ondrej Novy 29 Jul '09

29 Jul '09

Hi, this patch fix showing building too early on Garmin device. building=* should have same resolution as highway=residential. Thanks -- S pozdravem/Best regards Bc. Ondrej Novy Email: novy(a)ondrej.org Jabber: onovy(a)njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207

2 5