- mkgmap-dev - The mkgmap lists

Weird road speed
by Andrzej Popowski 20 Jan '14

20 Jan '14

Hi, I have observed weird road speeds when using current mkgmap r2977. See this way: http://www.openstreetmap.org/way/227105752 It has no maxspeed tag. It should be rendered as primary road, speed class 4. This is what I get, if I disable including "roadspeed" file from default style. With "roadspeed" all is different and depends on tile area. I have prepared sample data, where this road get speed class 6. Croping a bit tile area (outside the road) changes speed class to 3. See picture showing both cases, dark blue is class 6, green is class 3: http://files.mkgmap.org.uk/download/173/speed-problem.png I have prepared an example of source data: http://files.mkgmap.org.uk/download/172/speed-problem.7z It contains source data and a poly file for cropping. I have included batches, that I have used for creating maps. Actually I'm not sure, what is the behavior of mkgmap:road-speed-class tag. I couldn't find any description. For example if I define a road like [0x03 road_class=3 road_speed=4 resolution 19], does it create mkgmap:road-speed-class=4? -- Best regards, Andrzej

6 16

Commit: r2979: fix error regarding road speed and road class handling
by svn commit 20 Jan '14

20 Jan '14

Version mkgmap-r2979 was committed by gerd on Mon, 20 Jan 2014 fix error regarding road speed and road class handling that was introduced with r2915

1 0

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