Additional CH config leads to error

[karussell]

When I using the following config:

graphhopper:
  datareader.file: ""
  graph.location: graph-cache

  graph.flag_encoders: car|turn_costs=true

  profiles:
    - name: car
      vehicle: car
      weighting: fastest
      turn_costs: true
    - name: car_no_tc
      vehicle: car
      weighting: fastest

  profiles_ch: []

  profiles_lm:
    - profile: car
    - profile: car_no_tc
      preparation_profile: car

  routing.ch.disabling_allowed: true
  routing.lm.disabling_allowed: true
  ...

then everything works. But as soon as I use profiles_ch: [car_no_tc] the error is thrown:

Cannot find LM preparation for the requested profile: 'car_no_tc'
You can try disabling LM using lm.disable=true available LM profiles: [car, small_truck, truck, scooter] -
for url http://localhost:8989/match?vehicle=car

Using profile=car_no_tc or profile=car in the URL does not help. Also strange: when I use profile=car the error message is still:

Cannot find LM preparation for the requested profile: 'car_no_tc'

[easbar]

I had a look a this. There seem to be multiple things involved.

1. When we request with vehicle=car this means the ProfileResolver is used in MapMatchingResource to find a matching profile. If there are CH preparations it tries to find a CH profile and finds profile=car, because this is the only profile for CH. If there is no CH profile it tries to find an LM preparation and finds both profile=car_no_tc and profile=car, but in this case takes profile=car_no_tc, because it favors the profile with turn costs if both are available.

2. MapMatching does not really depend on the CH preparations. It only checks for the ch/lm.disable flags and if they are both false and there are some LM preparations it tries to find landmarks for the given profile. So if CH is disabled MapMatching uses the LM preparation for the car profile and everything is fine, but if we enable CH for car_no_tc it tries to find an LM preparation for profile=car_no_tc.

3. In MapMatching we are missing the implementation of the cross-query feature so far which means we cannot find landmarks for profile=car_no_tc.

So the first thing we need to fix is implementing the cross-query feature. This should fix this issue. However, its still ugly that ProfileResolver considers CH profiles and MapMatching does not. The problem here is that we are injecting a global instance of ProfileResolver in MapMatchingResource, but we need a slightly different resolver for map-matching.

[easbar]

And there is another problem: We cannot request with profile=car_no_tc either, because MapMatchingResource always uses ProfileResolver instead of skipping it when the profile parameter is used explicitly.