Felix,

After playing around a bit on my Vista HCx I did notice slightly different routing too. The maximum distance that it manages without "route calculation error" did not change however.

On the HCx, I just tried an 800Km route from where I live to Thurso and it took quite a while (stuck on 100% for a minute or two) but it did eventually calculate a sensible route.

...

Today's offering includes the table A tweak but it also increases one of the limits that determine when a route centre needs to be sub-divided. As far as I can tell, the limit was somewhat smaller than it should have been. So with this patch, fewer routing centres should be required (obviously depends on the map data). Routing in Mapsource is now different too. So far I have found one route that does not calculate with the old version, but with the new. The difference is however 2-3 more turns, so no drastical improvement. Maybe some routes also degrade?

I guess that is possible but I would hope that the overall effect is beneficial. I'm (optimistically) working on the theory that increasing the size of the route centres makes the route calculation easier/quicker. That could, of course, be complete rubbish. With the current patch, my GB map is around 172 MB compared to 180 without so the space saving is worth having if not dramatic. Cheers, Mark

Valentijn Sessink wrote:

Valentijn Sessink schreef:

...

given the turning penalties Garmin seems to have. But the Nuvi does really really strange things: it routes me through

... by bicycle (I forgot to mention that.).

forget bicycle mode. Only car / taxi and similar modes work well. Bicycle and Pedestrian are crap anyhow. They drop all road_speed down to 1, and more or less inverse the road_class. With this base for deciding which way to route, all results are obliged to be pure crap! The speed for the arrival time calculation is 18km/h or if road_speed=0 then 7-10km/h depending on unit/mapsource. The only maps that kinda work with bicycle / pedestrian mode are the dutch "onroute" maps. I think that knowing the above facts, they simply created maps with road_speed=1 for ways that are supposed to be chosen, and road_speed=0 for those that are not supposed to be chosen. If you want to have good bicycle routing, you are obliged to reprogram the maps by fooling the GPS with reprogramming the maps so that cycleways have attributes like motorways, and so on - only then routing will work well - of course suffering from the big problem of penalty time at intersections which are too long for bicylce/pedestrian mode. This could be solved by adding additional ways at intersections however.

V. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Marko, Thanks for the report.

I generated the same map with the only difference being this patch. The file was a little smaller:

-rw-r--r-- 1 marko marko 36888576 22.9. 09:01 gmapsuppa.img -rw-r--r-- 1 marko marko 36510720 23.9. 14:06 gmapsupp.img

...

So please test this patch (it replaces the previous patch) and let me know if their are any issues.

Routing seems to be unaffected. I tested the same route, both bicycle (253 km) and car (204 km).

Good.

...

You must enable assertions, otherwise if the data structures overflow you won't know until mapsource/gps barfs.

There are a few differences between the generated gmapsupp.img if I enable assertions. The files are of the same size, though. Come to think of it, the differences could be attributed to --max-jobs. But the diff of hexdump is only 64 lines, or 16 differing 16-byte blocks.

I think the differences will just be the time stamps. Enabling assertions really should not make the output change otherwise. That's a least 3 positive reports so I think this patch is probably OK to commit. Cheers, Mark