May 2009 - mkgmap-dev - The mkgmap lists

[PATCH v3] - merge nodes to remove evil short arcs
by Mark Burton 28 May '09

28 May '09

v3 now requires the --remove-short-arcs option to enable this feature now deletes consecutive identical points ---------- v2 now reports OSM ids of merged/replaced nodes (at the cost of using more memory while the XML is being converted). only does this stuff if route option enabled. ---------- The attached patch is a first stab at a solution for this problem. Please test. It is implemented in an iterative fashion and it should terminate after a few passes. If 10 passes are executed it will give up, please report if you see it doing that. It would be nice if the diagnostics reported the OSM id of the nodes rather than their coordinates but I haven't worked out the best way of achieving that yet. Cheers, Mark

2 2

Commit: r1044: Make opposite cycleways when bicycles can use oneway streets in reverse.
by svn commit 28 May '09

28 May '09

Version 1044 was commited by markb on 2009-05-28 01:01:02 +0100 (Thu, 28 May 2009) Make opposite cycleways when bicycles can use oneway streets in reverse. Some oneway streets allow bicycle traffic in the reverse direction and this patch makes a way with the same points as the original that allows bicycle traffic (in both directions). Feature is enabled with the --make-opposite-cycleways option.

1 0

[BUG and PATCH] Use of overlay style file breaks routing, fix attached
by Thilo Hannemann 27 May '09

27 May '09

When using the overlays style file it will break the routing of the map. The reason seems to be that if routable ways are overlayed they get added several times as routable ways. The attached patch will add only the first overlay type as a routable way and the other overlay types as lines. It will also copy the list of points instead of just passing on the pointer (don't know whether that is necessary). By the way: when experimenting with overlays I can not control which line of the overlay is painted first, it seems to change randomly. Anybody has an idea why this is so? The LineAdder gets the ways always in the same order. Does they get mixed up somewhere in mkgmap or does the GPS unit do some strange stuff? Regards Thilo

1 0

[PATCH v1] Synthesise cycleways that allow reverse bicycle routing on oneway streets
by Mark Burton 27 May '09

27 May '09

Hello cyclists, Here's a little patch that will synthesise a cycleway that "lies on top" of an existing oneway street when any of the cycleway="opposite" tags are present. This will allow bicycle traffic to route in the reverse direction. I have tested this using mapsource (it worked!) but not a real GPS yet. It seems to me that if the cycleway is actually a separate track then it would be better not to use cycleway="opposite_track" but to have a separate cycleway in the OSM data. If the original way was called Foostrasse, the cycleway will be called "Foostrasse (cycleway)". The word cycleway is hard coded. If that's an issue for you, feel free to submit a new version of the patch that localises that word. Cheers, Mark

6 11

R: [mkgmap-dev] road_speed parameter
by Marco Certelli 27 May '09

27 May '09

This is what I know: Road_speed: 0 to 7 Default values: 7=128Km/h, 6=108Km/h, 5=93km/h, 4=72km/h, 3=56km/h, 2=40km/h, 1=20km/h, 0=8km/h. In Mapsource you can change speeds for levels 2 to 6. My garmin nuvi 255 does not allow any change respect the default speeds. I don't know about other devices. The speed is used for route calculation (shorter time). But for best route calculation, garmin gives also a time penalty to each turn you are required to do in a given route. Road_class: 0 to 4 cGPSmapper says it is the main driver for the route calculation (but does't explain how it is used. maybe is also used to decide if a cross is a turn for you or you are just proceeding on the main road... I don't now but I'll made some experiments Ciao. --- Mer 27/5/09, gypakk(a)gmx.eu <gypakk(a)gmx.eu> ha scritto: > Da: gypakk(a)gmx.eu <gypakk(a)gmx.eu> > Oggetto: [mkgmap-dev] road_speed parameter > A: "Development list for mkgmap" <mkgmap-dev(a)lists.mkgmap.org.uk> > Data: Mercoledì 27 maggio 2009, 14:43 > Somewhere in style files there are > road_speed parameters. > Today I know that the speeds for 5 different road classes > can be set in Mapsource. > > I assume that the road_speed values in style file represent > these 5 Garmin road classes. But how does the GPS device > know what speed is referred to by what road class? Is there > a speed table in gmapsupp.img file? > > How can I change these speed values for the GPS device? > > Since these speeds are surely used by the routing algorithm > to weight alternative routes, I would like to get influence > on that, especially for preferring cycleways and residential > streets for cyclists. > > Markus > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >

2 1

Commit: r1043: Fix Coord aliasing bug caused by using HashMap instead of IdentityHashMap.
by svn commit 27 May '09

27 May '09

Version 1043 was commited by markb on 2009-05-27 18:54:08 +0100 (Wed, 27 May 2009) Fix Coord aliasing bug caused by using HashMap instead of IdentityHashMap.

1 0

R: [mkgmap-dev] [PATCH v3] - merge nodes to remove evil short arcs
by marco_certelli＠yahoo.it 27 May '09

27 May '09

Hi, I switched on the mkgmap logging and I noticed, compiling "the most simple failing map" I attched to a mail yesterday, that when the routing is faulty (routing nodes collapsing) the TableA used by the NOD builder has 5 nodes and 5 arcs. This should means that the central node (the collapsed) has a routing Arc going to itself. This may cause the problem. In the file \parabola\imgfmt\app\net\NOD1Part.java there is the function that populates the TableA. The original function is: /** * Add a node to this part. * * The node is used to populate the tables. If an * arc points outside the bbox, we know it's not * an internal arc. It might still turn into an * external arc at a deeper level of recursion. */ public void addNode(RouteNode node) { assert bbox == null || bbox.contains(node.getCoord()) : "trying to add out-of-bounds node: " + node; bboxActual.extend(node.getCoord()); nodes.add(node); for (RouteArc arc : node.arcsIteration()) { tabA.addArc(arc); RouteNode dest = arc.getDest(); if (bbox != null && !bbox.contains(dest.getCoord())) { arc.setInternal(false); tabB.addNode(dest); } } nodesSize += node.boundSize(); } The instruction adding the arcs to the table A is tabA.addArc(arc). We should try to change the function avoiding to add an arc to Table A if the arc from a node points to itself. I propose to change the code in a way similar to the following: .... nodes.add(node); for (RouteArc arc : node.arcsIteration()) { RouteNode dest = arc.getDest(); if (dest!=node) tabA.addArc(arc); if (bbox != null && !bbox.contains(dest.getCoord())) { ..... I don't know if this works, (for example I don't if the comparison dest!=node can be done like that) but it should easy to try. Ciao.

2 1

[PATCH v2] quick distance calculation
by Mark Burton 27 May '09

27 May '09

Added distanceInDegreesSquared() to be used where relative distances are required (i.e. finding closest city). Now quickDistance() just calls distanceInDegreesSquared() and applies the sqrt and scaling. Still using quickDistance() instead of slowDistance() for all other distance calculations. ---------------- Folks, OK, so the parallelisation code has not been very successful so far but we can still speed up mkgmap. You have probably noticed that it spends a huge proportion of its time in Math.acos() which is being called from Coord.distance(). The attached patch renames distance() to slowDistance() and introduces a new quickDistance() function that is based on the code that was in the MultipolygonRelation class. I have tested quickDistance() against slowDistance() and for maps in the UK and Germany it produces distances that are very similar (within 0.5% or better). It is substantially faster and so I believe we should change to using it as long as it doesn't introduce any issues. So please try out this patch and report: a - if any breakage is observed b - performance increase/decrease Cheers, Mark

2 5

[PATCH] alpha patch for simplifying ways and reducing img size
by Johann Gail 27 May '09

27 May '09

Find attached an patch (usable on R915), which reduces the point density of ways and roads to reduce the filesize of the resulting img file. It does it by using the douglas peucker algorithm. With this algorithm it is possible to set a max error distance and the resulting line will have filtered out all points without any points outside this distance band. For an exact explanation consult wikipedia. I tried it with an error distance of 10m. Higher distances don't gain much more. The saving is in some areas with bad osm data (useless high point density) up to 25%. In general it saves only 5% in file size. Consider this patch as an alpha release, which should only show the possibilities. For the release it will need at least an option at the commandline for setting the error distance. Also I'm not sure, if the StyledConverter.java is the correct file for this patch. I've seen there is some filter infrastructure in the mkgmap project, but I've no idea how to use it.

5 14

[PATCH v2] - merge nodes to remove evil short arcs
by Mark Burton 27 May '09

27 May '09

v2 now reports OSM ids of merged/replaced nodes (at the cost of using more memory while the XML is being converted). only does this stuff if route option enabled. ---------- The attached patch is a first stab at a solution for this problem. Please test. It is implemented in an iterative fashion and it should terminate after a few passes. If 10 passes are executed it will give up, please report if you see it doing that. It would be nice if the diagnostics reported the OSM id of the nodes rather than their coordinates but I haven't worked out the best way of achieving that yet. Cheers, Mark

1 0