calculated turn$ vs reality

[Asteliks]

This probably isn't a bug but nether the less it affects routing.

The algorithm can calculate unusably high turn$ even though in reality the place looks like this:

The questions are:

• can something be done about this?
• do you have any suggestions in terms of street mapping?

[polyscias]

I know that for turn-instructions there is a turnInstructionCatchingRange that is meant for this kind of situations, see the discussion in #332

From the Trekking profile:

assign turnInstructionCatchingRange = 40 # %turnInstructionCatchingRange% | Within this distance (in m) several turning instructions are combined into one and the turning angles are better approximated to the general direction | number

Something like that seems to me also like a good idea for the turn$

For the profile I use I have set the turncost to 30 instead of the 90 used in the default Trekking profile.

For this particular crossing it does look to me like a good idea to make the four roads cross in OSM at one point.