January 2014 - mkgmap-dev - The mkgmap lists

type=multipolygon relations
by Gerd Petermann 19 Jan '14

19 Jan '14

Hi all, from time to time I stumble over mp like this: http://www.openstreetmap.org/relation/3318482 It contains way 135320941 three times. In other cases inner ways are duplicated, and that really causes trouble when calculating the areas. I wonder why we don't remove duplicate entries when we process the members of mp relations. Is there any possible constellation where this would cause trouble? Gerd

5 12

Access flag question
by chris66 19 Jan '14

19 Jan '14

Hi, I have a question to the section in the doc of the new style system: --- Access restrictions of roads are now defined by setting special mkgmap:* access tags (mkgmap:car, mkgmap:foot, mkgmap:bicycle, mkgmap:truck, mkgmap:bus, mkgmap:taxi, mkgmap:emergency, mkgmap:delivery). Roads are blocked for a specific vehicle type if the mkgmap:<type> is set to the value no. The new addaccess and setaccess actions help to assign all values at once. --- Are other values than "no" being recognized? What about "private" and "destination"? Greetings Chris

3 5

Commit: r2977: correct handling of roads with more than 250 points
by svn commit 19 Jan '14

19 Jan '14

Version mkgmap-r2977 was committed by gerd on Sun, 19 Jan 2014 correct handling of roads with more than 250 points For roads with multiple segments, the lastSegment bit was set too late, so that all segments were written with the lastSegment bit set to true (the default value).

1 0

Commit: r2976: Fix BitReader.sget2() in the multi word cases.
by svn commit 18 Jan '14

18 Jan '14

Version mkgmap-r2976 was committed by steve on Sat, 18 Jan 2014 Fix BitReader.sget2() in the multi word cases. The final byte determines if the result is positive or negative and the number of special words beforehand make that result bigger. This only affects reading non-mkgmap files. Added a couple of tests for them.

1 0

shape merger in high-prec-coord branch
by Gerd Petermann 18 Jan '14

18 Jan '14

Hi all, today I've finished the work on the shape merger. The algo works quite simple: 1) if two similar shapes (same type, name, min+max resolution) share one or more identical points, both are combined. In the combined shape, the longest sequence of identical points is removed. This reduces the number of points and the number of shapes. On the other hand, it makes shapes larger, so that it is more likely that many smaller landuse=forest shapes are combined and appear at lower resolution levels. 2) After merging, all points on (almost) straight lines are removed. This reduces again the img size and has a very nice side effect: Connected buildings look much better. Two screen shots show what I mean: Area in OSM: http://www.openstreetmap.org/node/21030850#map=17/53.06636/8.79033 Screenshots: http://files.mkgmap.org.uk/download/170/r2961.png http://files.mkgmap.org.uk/download/171/r2966_mergeshapes.png I see no big change in the runtime , I guess the additional cpu time that is needed for the merged is gained back because less data is written, the img size is 2-3% smaller compared to trunk. Any feedback is welcome. Gerd

5 18

Commit: r2975: Read and access the newly discovered table A record length in NOD header.
by svn commit 18 Jan '14

18 Jan '14

Version mkgmap-r2975 was committed by steve on Sat, 18 Jan 2014 Read and access the newly discovered table A record length in NOD header. Set it to an explicit five, rather than align-1 since there is no relationship to align.

1 0

Path not displayed on certain place
by Jaromír Mikeš 18 Jan '14

18 Jan '14

Hi, on one place where "path", hiking_route and ski_route should be displayed is actually displayed just hiking_route. I am using transparent polylines so covering line by eachother is not the issue and this combination of lines works perfectly on other places for me. I already tried solve ths issue on OSM garmin forum: http://forum.openstreetmap.org/viewtopic.php?id=23887 Here is problematic path on OSM: http://www.openstreetmap.org/#map=19/61.66852/23.22331 (http://www.openstreetmap.org/#map=19/61.66852/23.22331) Here is tile from my map: https://docs.google.com/file/d/0Bxq-m_IH9Cf0TXE4NldRcjQ1YWs/edit (https://docs.google.com/file/d/0Bxq-m_IH9Cf0TXE4NldRcjQ1YWs/edit) And here lines file from my style file: https://github.com/miramikes/garmin_hiking_map/blob/master/lines (https://github.com/miramikes/garmin_hiking_map/blob/master/lines) regards mira

3 3

Commit: r2974: stop with error message when style file contains
by svn commit 18 Jan '14

18 Jan '14

Version mkgmap-r2974 was committed by gerd on Sat, 18 Jan 2014 stop with error message when style file contains non-numeric value for resolution or level

1 0

Address search: city sometimes missing
by Thorsten Kukuk 17 Jan '14

17 Jan '14

Hi, I wasn't able to find specific addresses on my Garmin 62s, even if I did know that I entered them in OSM. During testing of my adjusted style for the new mkgmap version, I found out that the addresses are not missing, but that the addresses don't have a city assigned. That's why I cannot find them on my 62s, where I have to enter a city always, but with mapsource. The question is now, why? This happens with the default style of mkgmap, too, independent of the mkgmap version. For example, look here: http://www.openstreetmap.org/#map=17/49.44674/11.03418 There are two buildings from Siemens, Von-der-Tann-Strasse 30 and 31 in 90439 Nuernberg. As you could see in the attached screenshot, only the housenumber 31 has a city assigned, the number 30 has not. I added some "echotags" to the style file: mkgmap:city is set correct to Nuernberg in all cases. Any idea what's going wrong? Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

4 18

Routing
by Steve Ratcliffe 17 Jan '14

17 Jan '14

Hi I've been looking into routing and I have updated NodDisplay so that it mostly works on any file. I've not discovered much that wasn't known before, apart from a compact way of storing directions that is probably suitable for short roads. There is a destination road-class field in the node flags that we do not seem to set, so we should fix that. I am in the process of updating the nod.txt file with everything I've learned so far. There are also two new programs. 1. test.check.NodCheck reads in a NOD file and cross checks various things. So it can tell you if the angle in NOD is similar to the actual angles between two nodes. Files give lots of errors, but it doesn't mean that they are wrong, just things to look into. 2. test.svg.Main Converts the routing graph to an SVG file that can be displayed in inkscape (and perhaps other SVG viewers). The idea is to be able to visualise what is going on. Only a portion of the file is processed, since the output is very large. They are only of use if you want to look into the routing code. The output will make no sense at all if you are not familiar with it, and possibly even if you are ;) ..Steve

4 16