Add new 'profile' parameter to select routing profile

[easbar]

In #493 its discussed how to specify CH profiles and part of this question is how they can be selected for incoming routing requests (especially when adding custom weightings in #1776). There are multiple cases that have to be differentiated. These are the current options that can be used on each routing request and affect the profile that will be used:

• the vehicle / flag encoder
• the weighting: either one of the 'classic' ones like "fastest" or a custom one
• turn costs yes/no
• u-turn-costs
• CH,LM or no speed up?
• blocked areas

The speed-ups can only be used if a matching profile exists on the server side, but how should this profile be selected? So far we are doing it like this:

• if CH/LM are not enabled use the vehicle/weighting/turn cost parameters to select the FlagEncoder and create the corresponding Weighting
• if CH/LM are enabled use the same information to find a matching CH/LM profile and use it

In the future this will be more complicated, because the weighting will be configurable: There will be CustomWeighting in #1776, but also we might add the option to use the ShortFastestWeighting with an additional distance factor, a more advanced turn cost configuration or even blocked areas. In any case we can no longer require specifying all the properties of these weightings to select the profile on the server side (or at least its very unclear to me how this is supposed to work. How can we check if a requested and an available profile are 'equal' and would it not be very cumbersome to send the entire profile configuration with every request?). Instead, we will select these profiles by a unique name. To do this we will add a profile parameter to the routing endpoint. The question that arises is how this relates to the other parameters, because they will then be redundant and possibly conflicting. At the same time we do not want to break backwards compatibility, so for the current use-cases it should still be possible to choose the vehicle&weighting without setting the CH profile name for example.

These are the different cases:

No CustomWeighting

• if LM/CH are disabled the vehicle/weighting/etc parameters are used to create the weighting, just like we did in the past. the profile parameter cannot be used in this case (see below)

• if LM/CH are enabled and no profile is given the vehicle/weighting/turn_costs/u_turn_costs parameters are used to create a profile name following a certain naming convention, something like
  gh_car_fastest_edge_30. The profile is then selected using this profile name. This is equal to the current behavior except the profile name handling on the server side

• if LM/CH are enabled and a profile is given the vehicle/weighting/etc parameters are meaningless, because they cannot be considered in addition to the vehicle/weighting etc. defined by the corresponding profile. This is confusing, because setting any of these parameters will not make a difference. Maybe it would be best to throw an error if profile and any of these parameters is set on the request? For LM its a bit different: For example its possible to use a certain LM profile and increase the u_turn_costs, but on the other hand it makes no sense to use an LM profile which uses the "shortest" weighting with the "fastest" weighting. Should we try to allow some of these cases or deny them for simplicity?

With CustomWeighting

The CustomWeighting can be defined by specifying a CustomModel per request, but also there can be CustomModels on the server side that can be further adjusted/partly overwritten per request.

Whenever a CustomModel is sent on the request the vehicle parameter becomes meaningless, because of the base field in the CustomModel which specifies the vehicle already. Or should it be the other way around? Again, this is confusing and it would be better to throw an error if both these parameters are set on the same request? Similarly, the weighting parameter becomes meaningless as well, because with a CustomModel the weighting will always be CustomWeighting. So far the turn cost configuration only consists of the u_turn_cost parameter, but if this gets more advanced how should this be configurable via the url parameters?

Sending a request with a profile parameter and a CustomModel can be interpreted as using the CustomModel with this name on the server side and merge this with the given CustomModel of the request. But unfortunately this is not possible with CH/LM. The easiest option here seems to be denying requests with CH/LM enabled that specify a profile and contain a CustomModel. Then again for LM this is possible in some cases (but figuring out whether or not this works might require comparing the weight of all edges using the weighting used for preparation and the one specified on the request).

[karussell]

One note about the vehicle parameter that currently maps to a FlagEncoder. As I would like to get rid of the FlagEncoder contract and we already replaced it with an EncodedValue collection in pt (see PtEncodedValues) it might be good to consider this change already here. I.e. the main parameters are only weighting (if no CH/LM) and profile (if something is prepared or known on the server-side).

For LM its a bit different: For example its possible to use a certain LM profile and increase the u_turn_costs

Hmmh, yeah. We need some algorithm-dependent way to check this.

For LM it is not only about the simple cases, e.g. increasing the weight should work in general, like "avoid highway/ferry/steps/...". But I think this can be done via a CustomWeighting with the base pointing to an LM profile (see below). So, if only profile is specified we can throw an error if other customizable parameters are specified.

Again, this is confusing and it would be better to throw an error if both these parameters are set on the same request?

Yes, I would throw an error if someone tries to change the "base vehicle" of a server-side CustomModel.

So far the turn cost configuration only consists of the u_turn_cost parameter, but if this gets more advanced how should this be configurable via the url parameters?

I don't think it is important to have this also via URL parameter. Via POST request is sufficient and then we use the same configuration that is used for the CH profiles (via yaml)?

Sending a request with a profile parameter and a CustomModel

I do not see a use case for that and would avoid this (throw an error). So that you can only specify the profile parameter implicitely via the base entry in a CustomModel. (this makes especially sense when the CustomModel is renamed into CustomProfile)

[easbar]

I.e. the main parameters are only weighting (if no CH/LM) and profile (if something is prepared or known on the server-side).

Ok but as long as we do have flag encoders how are we supposed to distinguish e.g. car|fastest from foot|fastest? If you just want to get rid of the vehicle parameter do you mean to include the vehicle in the weighting name instead, i.e. weighting: foot_shortest or something ?

I'd like to come back to this issue and your other points when #493 becomes more clear.

[karussell]

weighting name instead, i.e. weighting: foot_shortest or something ?

Yes, exactly. But probably the EncodedValue-collection can still be used as "vehicle", so not that important, we should just think about that the vehicle is currently a FlagEncoder and will likely be a EncodedValuesCollection.

[easbar]

But probably the EncodedValue-collection can still be used as "vehicle", so not that important, we should just think about that the vehicle is currently a FlagEncoder and will likely be a EncodedValuesCollection.

Ok, sure. So basically some EncodedValuesCollections will need a name too ;)

[easbar]

Update:

In the meantime we have decided to always require the profile parameter (for GraphHopper#route). So any kind of vehicle/weighting combinations must be specified in advance (#1922) and each request needs to specify which of these 'profiles' shall be used for routing.

For backward-compatibility we add a converter on the web-api level (SPT/Isochrone/RouteResource) which derives the profile name from vehicle, weighting etc. I think there are two ways to do this:

1. Use some kind of naming convention, like vehicle=car&weighting=fastest&turn_costs=true -> "car_fastest_edge". This way the converter can act independently from the configured profiles and one has to adjust the profile names to make the old parameters (vehicle, weighting, turn_costs, u_turn_costs) work with the configured profiles.

2. Make the converter aware of the profile configurations and make it try to find a matching profile for the given parameters. In this case the profile names do not play a role at all.

So far we were also using some rules like

• "no vehicle given? -> use the first flag encoder"
• "no weighting given? -> use fastest"
• "no weighting given, but CH and only one CH profile? -> use the weighting from this CH profile", etc.

For some of these rules the converter will need to be aware of the existing configuration... I am also wondering if we need to keep all these rules or if we can get rid of some (rarely used) ones

Any preferences here? I think I would prefer the option that is easier to understand...
In any case we are aiming to remove the converter for GH 2/3 ?

[easbar]

Maybe one important difference is that the first approach allows 'configuring' the converter, for example we could name a profile with vehicle: truck "bike_shortest" and then requests with vehicle=bike would run with vehicle truck. Not sure if this is something we need.