[OSRM-talk] Fixing routing with tags

[Florian Lohoff]

Hola

On Wed, Dec 13, 2023 at 09:49:33AM +0000, Richard Fairhurst wrote:
> Florian Lohoff wrote:
> > The route uses "Im Kracht" where it should stay on K22 and L775:
> > [...]
> > The route uses "Westerweg" but it should stay on K27, L876, L803:
> > [...]
> > So my idea would be to create a tag like **relative_route_cost=**
> 
> First, you seem to be assuming that "fast car routing" is the only
> sort of routing. It really isn't. If you're riding a bike then going
> via quieter roads like Westerweg or Im Kracht is greatly preferable:
> 
> https://cycle.travel/map?from=&to=&fromLL=52.234035,8.513781&toLL=52.238110,8.483742
> https://cycle.travel/map?from=&to=&fromLL=52.280323,8.696529&toLL=52.289005,8.709464

Of course - but i dont want to put the masses of car through traffic
there. Its a per profile/modality issue. 

bicycle routing a lot more dependend on distance whereas car routing is
more depending on speed/time.

So i want to get a handle on cornercases where car/motor_vehicle routes
look good mathematically, but are bullshit traffic wise, which cant be
solved with pure physical tagging.

> Second, this is trivially fixable. As Nils says, you just change the
> routing weight of minor roads and/or add a greater turn penalty when
> turning off a major road onto a minor road.

That causes errors "on the other end of the spectrum". There are good
reasons to use minor roads if the saving is on orders of magnitude. 
OTOH you dont want to FORCE people on the higher class network to just
go around the corner.

Routing is about _relative_ weight. And whenever you turn on that knob you
shift routes at both ends of the spectrum.

> FWIW, I'm not convinced that it's possible to do good quality car
> routing on OSM data without external datasets, principally traffic.
> (The situation with cycling and walking is slightly different.) The
> engines featured on osm.org are essentially tech demos for testing
> connectivity and demonstrating a use of OSM data, but they won't give
> you the best real-world results.

I am doing RouteQA for 10 years now and routing quality in OSM can be
improved A LOT by fixing the sparse tagging.

People started tagging the higher class road network extensively.
Maxspeeds, lanes, lane_markings, smoothness etc. but forgot about 
the side roads. Now we have a speed limit somewhere and suddenly
the side road looks good _mathematically_ but just because the tagging
is sparse. So fixing up the sparse tagging about physical aspects is
the first thing i do whenever i find static routing issues.
Most of the time thats enough to fix very obscure corner cuttings.

But sometimes you are left with edge cases which are simply unsolvable
just by physical tags. And this is where i want to have a knob to
forcefully make the road less attractive for a certain modality.

This morning i hacked a solution together and applied it to
the corner cuttings i mentioned here and i solved them all.

I extended the osrm car profile to use a tag:

	route_weight_factor:motor_vehicle=-0.5

and applying that to the weight calculated by physical tags on the road:

https://github.com/flohoff/osrm-backend/commit/c199019fefc8b0d31e45a6599c0a7f1343af2cfe

I clamp the factor down to +-0.8 to not let people make roads completely
unusable with this tag.

Flo
-- 
Florian Lohoff                                                     f at zz.de
  Any sufficiently advanced technology is indistinguishable from magic.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20231213/ff75c291/attachment.sig>