Add documentation about ShortFastestWeighting

[boldtrn]

Currently the API docs miss information about the short_fastest.time_factor and the short_fastest.distance_factor and how to use it.

[karussell]

I'm not sure if we should document them as these parameters are really low level and for LM we should not allow a decrease.

[boldtrn]

Yes, but how would anyone be able to use the ShortFastestWeighting if we don't document it properly? Not everyone can/wants to look into the code. I think it's a nice feature and maybe some more people would like to use it, but don't understand it?

[karussell]

Yes, but how would anyone be able to use the ShortFastestWeighting if we don't document it properly?

you can switch from fastest to short_fastest and trust us that we defined proper defaults :)

[boldtrn]

you can switch from fastest to short_fastest and trust us that we defined proper defaults :)

But isn't the big "feature" of the ShortFastestWeighting that a user can provide their own values?

[karussell]

I think the users usually want either "fastest" or "shortest" but with "shortest" they don't mean actual the "shortest" route, but a fast route that further considers distance. At this time I would not want to offer these additional parameters to the public. We should really consider investing into issue 1112 of GH core to use a much more powerful JSON request where tuning things like this will feel natural and logic.