Hi Felix,
The idea behind it was that one could priotize or depriotize roads close to Point X.
okay, understood.
However it is seriously flawed in so far, that mkgmap:road-min-speed / max-speed doesn't work.
I see no code that handles strings like mkgmap:road-min-speed or mkgmap:road-max-speed. I guess you mean mkgmap:road-speed-min ?
If you tag road-min-speed=1, the road previously was road-speed=0 and the command is road-speed=-1, it will actually increase the speed to the min-speed. However the intention is only that road-speed>0 are not decreased to 0 if that command is given. It should never increase...
I don't fully agree. The default value for mkgmap:road-speed-min is 0, and my understanding of the current code in r2643 is that the final road speed value will never by negative as long as you don't set mkgmap:road-speed-max or mkgmap:road-speed-max to a negative value (which is not quite logical,but probably ok) So if one sets a mkgmap:road-speed-min value of 1, what else could that mean ?
Else the problem is, that the distance it works, is very short anyhow, now that roads are split up into very short distances everywhere.
what is very short? I plan to change the code so that it doesn't produce short arcs (using the --remove-short-arcs value ). Do you think the value should be higher?
To improve routing, a much better approach would be to check the finished routing graph for heavy road-class changes on intersections. Garmin doesn't like to route from a road-class=4 onto a 0-1. Only 2 or 3 are liked. The max difference should be 2. However that will be difficult to achieve. Also high angles on intersections could have an automatic road-speed decrease by 1 or 2 (depending on the current state) - or even more smoothing out - that is still something going crazy. A turn of 160° is like minimum 1 minute time penalty...
Well, it should be easy to implement warnings, but I don't see how mkgmap could change the values. Gerd