- mkgmap-dev - The mkgmap lists

Commit: r925: Directory sizing works for small files. Probably by co-incidence.
by svn commit 23 Feb '09

23 Feb '09

Version 925 was commited by steve on 2009-02-23 00:17:08 +0000 (Mon, 23 Feb 2009) BRANCH: small_img Directory sizing works for small files. Probably by co-incidence.

1 0

Commit: r924: Find attached a patch which maps tag landuse=farmyard to 0x4e
by svn commit 22 Feb '09

22 Feb '09

Version 924 was commited by steve on 2009-02-22 23:17:42 +0000 (Sun, 22 Feb 2009) Find attached a patch which maps tag landuse=farmyard to 0x4e (Orchard/Plantation) - Peter

1 0

Commit: r923: Find the lengths of the individual files.
by svn commit 22 Feb '09

22 Feb '09

Version 923 was commited by steve on 2009-02-22 18:46:56 +0000 (Sun, 22 Feb 2009) BRANCH: small_imgsrc/uk/me/parabola/imgfmt/app/ small_imgsrc/uk/me/parabola/imgfmt/app/map/ Find the lengths of the individual files.

1 0

Commit: r922: Add logging when bbox reading fails - Johann Gail
by svn commit 22 Feb '09

22 Feb '09

Version 922 was commited by steve on 2009-02-22 13:01:24 +0000 (Sun, 22 Feb 2009) Add logging when bbox reading fails - Johann Gail

1 0

[PATCH] print an error log if unable to read bounding box
by Johann Gail 22 Feb '09

22 Feb '09

Find attached an patch, which prints an error message, if reading of bounding box fails. It helps debugging somtimes.

1 0

Commit: r921: A branch to rewrite the .img writing code, so that it does not
by svn commit 22 Feb '09

22 Feb '09

Version 921 was commited by steve on 2009-02-22 12:18:51 +0000 (Sun, 22 Feb 2009) BRANCH: trunk/resources/styles/default/ A branch to rewrite the .img writing code, so that it does not have to reserve the maximum space for the directory. This will result in much smaller img files when the input file is not so large.

1 0

Routing (and other) woes
by Michel Marti 22 Feb '09

22 Feb '09

When routing with a mkgmap (svn rev. 907) generated routable map, my nüvi gets seriously confused about this area: http://www.openstreetmap.org/?lat=47.44357&lon=8.69386&zoom=17&layers=B000F… * Two of the motorway-links there look like residential roads on the device * way 4987473 is labeled '67' although there is no such ref or name for this way in the OSM data * The way 10864230 (highway=secondary) is labeled "Ramp" on the garmin Another area that shows similar problems: http://www.openstreetmap.org/?lat=47.479862&lon=8.704816&zoom=18&layers=B00… Again, motorway link 4248871 is unnamed in OSM, but on the Garmin, it is labeled with the name of a nearby river (Töss, id: 4255496). It also gets rendered like a residential road. As a side effect, in those two areas, the garmin omits some turn-instructions (e.g. to take the ramp to the motorway). I also noticed that when taking a different route as the one suggested by the device, it takes much longer for the garmin to recalculate the route than with the built-in map. Are these known deficiencies? Cheers, - Michel

2 3

Found an possible bug in inter-tile routing
by Johann Gail 22 Feb '09

22 Feb '09

Hello, I've just noted an interesting detail while generating an inter tile routing map. I cannot investigate further at the moment, just want to tell you my observation. There are three boundrary nodes on one street. Maybe the street crosses the boundary three times, but I dont believe, that point #0 and #1 are both on the boundary. I will have a closer look tomorrow. 2009/02/21 17:19:22 INFO (StyledConverter): Way Ludwig-Thoma-Straße's point #11 at 48,35974/11,38021 is a boundary node 2009/02/21 17:19:22 WARNUNG (MapLine): consecutive identical points Ludwig-Thoma-Straße 2009/02/21 17:19:22 WARNUNG (MapLine): consecutive identical points Ludwig-Thoma-Straße 2009/02/21 17:19:22 INFO (StyledConverter): Way Ludwig-Thoma-Straße's point #0 at 48,35793/11,38239 is a boundary node 2009/02/21 17:19:22 INFO (StyledConverter): Way Ludwig-Thoma-Straße's point #1 at 48,35793/11,38239 is a boundary node

3 2

Commit: r920: Show coordinates of correct point in diagnostic message.
by svn commit 22 Feb '09

22 Feb '09

Version 920 was commited by markb on 2009-02-22 09:20:09 +0000 (Sun, 22 Feb 2009) Show coordinates of correct point in diagnostic message.

1 0

[PATCH] Bicycle routing opposite to oneways for cycleways tagged as "opposite_*"
by Stefan Wenk 22 Feb '09

22 Feb '09

In that attachment you find an addition to enable support for bicycle routing opposite to oneways if the way is tagged as cycleway="opposite*". If a way matches these two conditions the code creates a new overlapping way, without a "oneway" tag and "highway=cycleway" instead of the original highway type. The patch is intended for the osm routing mode. The code works for me with one drawback:If I change the routing mode from "bicycle" to "car/motorcycle" and the destination is located at one of those oneways, which are also opposite cycleways, then I'm seeing a similar behavior, which was fixed in r906/r907 earlier this week: On the first glance it looks as the device routes into the oneway, but if you look at the proposed route more closely one can see that the device directs into the artificially created cycleway. Anyway, this problem is not related to the proposed patch, because the routing on the device and mapsource currently also directs a car/motorcycle into ways, which, are tagged as "highway" = "cycleway" if the destination is there. I have verified this by removing the "oneway" tag and by changing the highway type to "cycleway" in the osm input. Maybe somebody has an idea how to fix this problem. If this problem cannot be solved, then possibly a command line option could be introduced with gives the user the choice to either create maps with optimized cycleway routing or optimized car/motorcycle routing. Stefan

3 5