- mkgmap-dev - The mkgmap lists

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

18 Feb '10

v3 - bug fixes: now ignores through_route relations if the junction is outside of the tile's bounding box should no longer think that ways that have been split do not start or end at the junction. -------------------- 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

2 7

[PATCH v2] Enable elevation profile in MapSource
by Ronny Klier 18 Feb '10

18 Feb '10

v2 adds new option "show-profiles" to enable or disable this feature. Default is disabled. -------- Original-Nachricht -------- Betreff: [PATCH] Enable elevation profile in MapSource Datum: Sun, 14 Feb 2010 23:53:31 +0100 Von: Ronny Klier <ronny.klier(a)s1999.tu-chemnitz.de> Antwort an: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> An: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> Newsgruppen: gmane.comp.gis.openstreetmap.mkgmap.devel Hi, there seems to be a way to show elevation profiles for a route without having the DEM subfiles stored in the map. There is a byte in TDB file's header section which can be set to 1. If set MapSource generates the profile from the contour lines. The result is not as good as having the full information from DEM subfiles but better than nothing. Please try this patch, especially with maps without contour lines. Maybe setting this flag has to be bound to existing contour lines. Ronny

2 1

How to tag artificial cut lines in multipolygons
by Marko Mäkelä 17 Feb '10

17 Feb '10

Hi WanMil and others, Some time ago, there was discussion that the MultiPolygon code in mkgmap should tag the lines that it generates when splitting multipolygons to polygons. I think that there is a genuine need to split large multipolygons to smaller multipolygons in the OSM data too. For example, I generated multipolygons for the lake Saimaa in the past couple of weeks. I split it to maybe 10 or 20 multipolygons, some of them still huge (hundreds of ways in the relation, many of them consisting of 500 nodes). A fellow mapper who generated the natural=coastline for many Finnish waters in the first place got upset of the artificial splitting. I suggested a solution where the artificial split lines would not be given any natural=water or natural=coastline tag, but something else, say, artificial=yes. What do you think? Is there an existing tag that we could use for this? Is there now a multipolygon around the Canarian Islands? I could not find one. I am considering defining some multipolygons with some artificial cut lines on the Finnish coast, so that I would get water without --generate-sea and could work around the limitations of the Geofabrik map extracts by defining the borders of the sea multipolygons within the Geofabrik cutting boundary. Marko

2 2

[PATCH v4] Multipolygon code enabled for overlapping lines
by WanMil 17 Feb '10

17 Feb '10

Compared to v3 (posted by Carlos in thread "Wrong multipolygon warnings") some unused debug messages have been removed. The patch enables the multipolygon code to process multipolygons with overlapping lines. WanMil

2 8

Commit: r1575: Allow overlapped lines in multipolygons (WanMil)
by svn commit 17 Feb '10

17 Feb '10

Version 1575 was commited by marko on 2010-02-17 19:32:07 +0000 (Wed, 17 Feb 2010) Allow overlapped lines in multipolygons (WanMil)

1 0

Re: [mkgmap-dev] Help from the style file gurus
by Minko 17 Feb '10

17 Feb '10

Hi, I don't know if this already has been discussed, but some combinations of TYP file and overlays wont work in Mapsource. I'm trying to put oneway, bridge and tunnel symbols on the roads by using the layer style file. This works fine with tunnels and bridges, but with oneway symbols I noticed the following issue: For oneway streets I create in the TYP file a line element. Its a 3 pix bitmap with a a black arrow sign -> in the centre line. I use the line symbol 0x00 (Road) to display this line, but any line that garmin can display, works. In the line overlay style file, I combine this arrow sign with the highways: 0x0200: 0x02, 0x00 (representing highway=primary & oneway=yes or 1) 0x0300: 0x03, 0x00 (secondary roads / oneway) 0x0400: 0x04, 0x00 (tertiary / oneway) 0x0500: 0x05, 0x00 (unclassified / oneway) I noticed that: 1) Only on the LOWER class roads (0x04, 0x05 etc) the arrow display (that i put in the center of the bitmap) is displayed fine, as long as I draw the lines as BITMAP in the TYP file. It doesn't matter if they are either 1 or 2 colored bitmaps. So a yellow tertiary road, with black borderlines, and a black arrow in the centre of the road indicating the driving direction, will display fine. 2) If I draw the roads as line elements instead of bitmaps, the arrow is NOT displayed. 3) With MAJOR road types 0x02 and 0x03 however, the arrow only shows up if: - the roads are drawn as bitmap AND - the center of this bitmap (where the arrow is displayed) is transparent, otherwise it will be covered by the bitmap color of the road. With a line that is defined by two colored bitmaps, the arrow is covered and don't show on mapsource 4) As I said tunnels and bridges showed up fine, as long as the bitmap of these tunnels and bridges were wider then the bitmap of the roads. Of course this could be arrow signs or other symbols too, as long they are drawn outside of the road. I use mapsource 6.15.7, and I don't know if this behavior is a bug in mkgmap or is it a mapsource issue?

2 2

suppress place tag in road-name-pois
by maning sambale 17 Feb '10

17 Feb '10

The road-name-poi switch is very useful for street search, however, in most cases the place tag attached is wrong mostly due to wrong place tag position. Is it possible to suppress adding the place tag and show only the streetname? -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

1 0

typ file not included with generating gmapsupp
by maning sambale 17 Feb '10

17 Feb '10

My typ file is not incluced when I created a gpamsupp file from a previous mkgmap run time java -Xmx1512m -jar mkgmap.jar --read-config=args.list philippines.osm time java -Xmx1512m -jar mkgmap.jar --gmapsupp some_dir/*.img some_dir/MINIMAL.TYP -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

7 12

NPE with r1572 and --map-features
by Ævar Arnfjörð Bjarmason 16 Feb '10

16 Feb '10

After upgrading from r1441 to r1572 using --map-features broke for me: $ java -Xmx1024M -enableassertions -jar /home/avar/src/osm.nix.is/mkgmap/dist/mkgmap.jar --map-features=cycling-map-features.csv Iceland-cycle.osm java.lang.NullPointerException at java.util.ArrayList.addAll(ArrayList.java:472) at uk.me.parabola.mkgmap.osmstyle.RuleIndex.addChangables(RuleIndex.java:249) at uk.me.parabola.mkgmap.osmstyle.RuleIndex.addRuleToIndex(RuleIndex.java:103) at uk.me.parabola.mkgmap.osmstyle.RuleSet.add(RuleSet.java:97) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.addBackwardCompatibleRules(StyleImpl.java:317) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.initFromMapFeatures(StyleImpl.java:288) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.readMapFeatures(StyleImpl.java:270) at uk.me.parabola.mkgmap.osmstyle.StyleImpl.<init>(StyleImpl.java:141) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.createStyler(Osm5MapDataSource.java:120) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:80) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:148) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Exiting - if you want to carry on regardless, use the --keep-going option The files needed to reproduce it are here: http://v.nix.is/~avar/mkgmap/npe/

2 4

Commit: r1574: Repair the --map-features option which was not correctly
by svn commit 16 Feb '10

16 Feb '10

Version 1574 was commited by steve on 2010-02-16 21:48:14 +0000 (Tue, 16 Feb 2010) Repair the --map-features option which was not correctly modified for the new style features.

1 0