>
> 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