Route calculation error introduced in r1337:1343

Hi Mark, About a week ago, I began experiencing route calculation errors on the Edge 705. I cannot calculate a bicycle or walking route from my home (2 km east from the Korso railway stop) to the Pasila railway station or the center of Helsinki (a few km further south). Because a Nüvi user complained about broken car routing west from Helsinki, with no obvious error in the OSM data, I decided to test earlier versions of mkgmap. Dropping the option --adjust-turn-headings did not make any difference. I just rebuilt and tested the following mkgmap revisions: r1319: ok r1331: ok r1337: ok r1343: route calculation error In addition to these, I have built (broken) maps with r1344, r1362, and r1364. Should I track down the earliest buggy revision, or is the r1337:1343 range of revisions specific enough? Best regards, Marko

Hi Marko,
About a week ago, I began experiencing route calculation errors on the Edge 705. I cannot calculate a bicycle or walking route from my home (2 km east from the Korso railway stop) to the Pasila railway station or the center of Helsinki (a few km further south).
Because a Nüvi user complained about broken car routing west from Helsinki, with no obvious error in the OSM data, I decided to test earlier versions of mkgmap. Dropping the option --adjust-turn-headings did not make any difference. I just rebuilt and tested the following mkgmap revisions:
r1319: ok r1331: ok r1337: ok r1343: route calculation error
In addition to these, I have built (broken) maps with r1344, r1362, and r1364.
Should I track down the earliest buggy revision, or is the r1337:1343 range of revisions specific enough?
That's all very interesting. I'll tell you why. I have been working on another patch that removes redundant nodes from ways. When I use that patch, the maps are fine on mapsource and the etrex but with the nuvi they break the routing in a completely odd way. It just thinks that it can't get past a certain point even though there's no good reason not to. I wonder if this is the same problem that you are seeing. Could you please try reducing the value of MAX_ARC_LENGTH (in StyledConverter.java), initially right back to 25Km as that's what it's been for a long time and see if it makes any difference for you. If that doesn't help, you could try using smaller values for some of the other constants there. Cheers, Mark

Hi Mark, and thanks for your quick response.
Should I track down the earliest buggy revision, or is the r1337:1343 range of revisions specific enough?
One more observation: r1338 is fine. Between r1338 and r1343, the only changes according to svn:log are to message reporting and MAX_ARC_LENGTH.
Could you please try reducing the value of MAX_ARC_LENGTH (in StyledConverter.java), initially right back to 25Km as that's what it's been for a long time and see if it makes any difference for you. If that doesn't help, you could try using smaller values for some of the other constants there.
Guess what, this works: Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java =================================================================== --- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1365) +++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy) @@ -84,7 +84,7 @@ public class StyledConverter implements private final Map<Way, Way> originalWay = new HashMap<Way, Way>(); // limit arc lengths to what can be handled by RouteArc - private final int MAX_ARC_LENGTH = 75000; + private final int MAX_ARC_LENGTH = 25000; private final int MAX_POINTS_IN_WAY = LineSplitterFilter.MAX_POINTS_IN_LINE; Best regards, Marko

Hi Marko,
One more observation: r1338 is fine. Between r1338 and r1343, the only changes according to svn:log are to message reporting and MAX_ARC_LENGTH.
Yes, that's why I asked you to try reducing that value.
Guess what, this works:
+ private final int MAX_ARC_LENGTH = 25000;
Very good. Could you please try bisecting between 25000 and 75000 to see what approx value is the cutoff point between it working and it not working. FYI - using a value of 25000 did not make my Nuvi routing problem go away. Cheers, Mark

Hi Mark,
Could you please try bisecting between 25000 and 75000 to see what approx value is the cutoff point between it working and it not working.
MAX_ARC_LENGTH = 39062 works but 40625 does not.
FYI - using a value of 25000 did not make my Nuvi routing problem go away.
How long distance is it? My route is 22.6 or 22.7 km, and the problematic car route reported by the Nüvi user ought to be 10 km or less. Best regards, Marko

Hi Marko,
Could you please try bisecting between 25000 and 75000 to see what approx value is the cutoff point between it working and it not working.
MAX_ARC_LENGTH = 39062 works but 40625 does not.
OK, I shall set the limit to 35000 and we can see if that's reliable. This is odd because that's much shorter than the maximum arc length that can be encoded. I wonder if using longer arc lengths causes some buffer overflow in the Nuvi?
FYI - using a value of 25000 did not make my Nuvi routing problem go away.
How long distance is it? My route is 22.6 or 22.7 km, and the problematic car route reported by the Nüvi user ought to be 10 km or less.
That route was long but when I found where it could not route through, even a short route did not work. It's like a node simply doesn't exist anymore. Cheers, Mark

Hi Mark,
MAX_ARC_LENGTH = 39062 works but 40625 does not.
OK, I shall set the limit to 35000 and we can see if that's reliable.
This is odd because that's much shorter than the maximum arc length that can be encoded. I wonder if using longer arc lengths causes some buffer overflow in the Nuvi?
I tested with my Edge 705. I have not heard back from the Nuvi user yet. I asked him to test my map, which was compiled with 39062. Marko

On Wed, Nov 11, 2009 at 11:09:24AM +0200, Marko Mäkelä wrote:
Hi Mark,
Could you please try bisecting between 25000 and 75000 to see what approx value is the cutoff point between it working and it not working.
MAX_ARC_LENGTH = 39062 works but 40625 does not.
The Nüvi user replied today that the map that I generated with r1392 (MAX_ARC_LENGTH=35000) on November 16 works for him. He did not state the date of the map, so he could also be referring to r1366 patched with MAX_ARC_LENGTH=39062, from Nov 11. Marko

Hi Marko,
The Nüvi user replied today that the map that I generated with r1392 (MAX_ARC_LENGTH=35000) on November 16 works for him. He did not state the date of the map, so he could also be referring to r1366 patched with MAX_ARC_LENGTH=39062, from Nov 11.
Well, I chose 35000 because 39062 is too much of a magic number! However, it would be good to find what the real problem is here. As I reported before, I have a useful patch that removes nodes that aren't really needed but I can't use the patch because although the maps are fine for mapsource and the etrex, the nuvi barfs on them! It's bizarre. I wonder if there is some stupid bug in the nuvi that we're hitting. I have tried lots of different things (changing sizes of data tables, etc.) but nothing seems related. Grrr. Cheers, Mark
participants (2)
-
Mark Burton
-
Marko Mäkelä