Don't snap to ferries

[TheMarex]

As @danpat pointed out we currently snap against all modes of transportation, even ferries.

This creates non-nonsensical results like below:

http://map.project-osrm.org/?z=6&center=57.308724,20.632324&loc=55.078367,16.391602&loc=55.961501,16.029053&hl=en&ly=&alt=&df=&srv=

We should remove all non-default mode segments from the RTree.

[TheMarex]

So we have two ways to fix this:

1. On the client side: Add a new parameter to the query that filters the found edges by mode of transportation
2. During pre-processing: For each mode of transportation add an additional flag that specifies if its "snapable".

My original approach just disallowed snapping to non-default mode of transportations and uses the second approach. This is problematic in two ways:

• (a) The semantic value of the mode of transportation value is user defined. forward_mode=2 could mean anything. It could make sense to snap to that.
• (b) This breaks a lot of tests since we test routability on streets with non-default travel mode for the profile tests. (which relies on snapping to that road in the first place)

The second approach would add a new API parameter and yet another query mode. This is less problematic after the StaticRTree refactor which moves the application complexity outside of the query code.However from a user standpoint this does not really help. They would need to know that the streets they want to snap to have mode=0 or mode=1. Instead it should just Do The Right Thing (tm).

We can try to fix (b) by changing the way we do routability tests.

@danpat I think we should go with the pre-processing technique after all. Any opinions here?

[emiltin]

the mode is user defined, but is usually known by both back and front end. that's how the front displays eg 'ferry' when applicable. so the front end (and user) would know what mode to use for eg bikeways.

[MoKob]

Related: https://github.com/Project-OSRM/osrm-backend/issues/1726

[TheMarex]

Resolved.