February 2010 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] Commit: r1576: There seems to be a way to show elevation profiles
by Minko 20 Feb '10

20 Feb '10

Hi, I use the standard Garmin types for contour lines, 0x20, 0x21 and 0x22 I created the contour lines with Srtm2Osm, split srtm.osm data with the same tile area bounds as my map. Now I have two img's of the same area, one with osm data, one with contour lines. E.g. 10010001.img and 10010101.img The contour tile is transparent so I can see the contours on top of the map in Mapsource. Is it possible to merge those two layers into one tile and still keep the routing? How can I merge the two 10010001.osm with 10010101.osm or 10010001.img with 10010101.img? Will it be possible to show the elevation profile with this approach? Cheers, Minko Ronny Klier wrote: This will not work. I got the same problem in different versions of MapSource. May be there should be an explicit warning in "show-profiles" option help. > > If I make one mapset with only contour lines, I see an emtpy profile. > This works fine for me (in 6.15.11). Did you use the standard Garmin types for elevation(0x20-0x21)?

2 1

Re: [mkgmap-dev] Commit: r1576: There seems to be a way to show elevation profiles
by Minko 20 Feb '10

20 Feb '10

With some detours, I finally got the elevation profile working in my mapset ;-) I dont know if it now worked because I also installed Garmin Basecamp. First, I had all map tiles and contour img's in one mapset. They are still there, but now I created another tdb index file with mkgmap on all contour img's from the same mapset, with the options: --overview-mapname: contours_nl --show-profiles=1 --tdbfile I stored the contours_nl.tdb file and contours_nl.img overview map in the same directory, and installed it in Mapsource. The result is that I see the contours on top of the map (with routing), and I can choose to switch to the bare contour mapset without all osm data. In this mapset I can see now the elevation profile :-) On the GPS (tested a Etrex and Dakota) I can now switch the contours on and off, but routing doesn't show the elevation profile. You can download and view some images of my custom maps on my website: http://sites.google.com/site/openfietsmap

1 0

[PATCH v2] heed the through_route relation when adjusting turn headings
by Mark Burton 20 Feb '10

20 Feb '10

v2 - no longer requires the node to have role "junction" This patch also includes two other changes to the heading adjustment code: When matching arcs, as a last resort, match road class and speed. If at a node, an outgoing arc cannot be matched to an incoming arc by possiblySameRoad(), try to find a single outgoing arc that has the same road class and speed as the incoming arc and use that. and: When adjusting turn headings apply all relevant adjustments. Previously, if a heading needed adjusting because the delta from the outgoing arc was too small, it did not then consider whether the delta from the incoming arc was too small also. Now, it considers both cases and adjusts the heading as appropriate. So please test even if you are not adding any through_route relations and if you see any notable changes (good or bad) please say. -------------------- This new relation (type through_route) specifies which 2 ways are the "through route" at a junction. The relation requires 2 ways (no role required) and a node with role = junction. It should only be used at those junctions where the through route cannot be reliably inferred from the ways' names and/or refs. Here's an example from my local town: | 1 | / | / |/ A | | | | B /| / | / | 2 | The vertical road is the "through route", i.e. you can drive from one end to the other without crossing any white lines. But, from point 1 to point 2 is a B road so ways 1-A, A-B, and B-2 all have some ref, say, B1234. Without the through_route relation, mkgmap assumes (erroneously) that the through route is 1-2 because all of the ways in that route have the ref B1234. By adding 2 through_route relations (one at A and the other at B), mkgmap is informed of the real through route and will take that into account when adjusting the turn headings. The end result is that the quality of the routing directions is improved (we hope). In this example, we need to have 2 relations because the B road joins/leaves the through route at two places. So if you know of any junctions that would benefit from this relation, please add it to the map data and try this patch to see if it improves the routing instructions. Mark

4 6

Re: [mkgmap-dev] Commit: r1576: There seems to be a way to show elevation profiles
by Minko 19 Feb '10

19 Feb '10

Hi Mapsource (6.15.7) crashes when I click to see the profiles of the route: invalid map/set<T> iterator I have the elevation contour img's in one mapset with the osm map img tiles, combined them with mkgmap r1580 (with --show-profiles=1). If I make one mapset with only contour lines, I see an emtpy profile.

2 1

cannot add waypoints on an area polygon
by maning sambale 19 Feb '10

19 Feb '10

Hi, I found this in the osm diary: http://www.openstreetmap.org/user/bri%20g/diary/9588 "On another point can I talk about areas? The whole of the University of British Columbia was and still is tagged as an area - fine no problem, but loading my Garmin HCX with a map derived from an OSM file converted by MKGMAP, it will not allow me to store a way point in a predefined area." "Okay let me explain, if I store the point of exactly where I am that works, but usually I move the pointer to where the data point is, say a post box on the other side of the road, but that is in in an area, so the Garmin says no can do." I'm wondering if this a device specific issue (Garmin HCx) or mkgmap. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

3 3

Commit: r1580: In RoadDef.toString() assume id is an OSM id and return an OSM browse URL.
by svn commit 18 Feb '10

18 Feb '10

Version 1580 was commited by markb on 2010-02-18 23:17:24 +0000 (Thu, 18 Feb 2010) In RoadDef.toString() assume id is an OSM id and return an OSM browse URL.

1 0

[PATCH] Add way link to "contains zero length arc" output
by Ævar Arnfjörð Bjarmason 18 Feb '10

18 Feb '10

This helps me debug potential zero length arc issues.

2 6

Commit: r1579: When adjusting turn headings, take account of through_route relations.
by svn commit 18 Feb '10

18 Feb '10

Version 1579 was commited by markb on 2010-02-18 20:39:57 +0000 (Thu, 18 Feb 2010) When adjusting turn headings, take account of through_route relations. This relation may be defined for a junction to indicate which ways are the "through route" when that cannot be inferred from the ways' names or refs.

1 0

Commit: r1578: When matching arcs, as a last resort, match road class and speed.
by svn commit 18 Feb '10

18 Feb '10

Version 1578 was commited by markb on 2010-02-18 20:39:52 +0000 (Thu, 18 Feb 2010) When matching arcs, as a last resort, match road class and speed. If at a node, an outgoing arc cannot be matched to an incoming arc by possiblySameRoad(), try to find a single outgoing arc that has the same road class and speed as the incoming arc and use that.

1 0

Commit: r1577: When adjusting turn headings apply all relevant adjustments.
by svn commit 18 Feb '10

18 Feb '10

Version 1577 was commited by markb on 2010-02-18 20:39:48 +0000 (Thu, 18 Feb 2010) When adjusting turn headings apply all relevant adjustments. Previously, if a heading needed adjusting because the delta from the outgoing arc was too small, it did not then consider whether the delta from the incoming arc was too small also. Now, it considers both cases and adjusts the heading as appropriate.

1 0