181 feature merge consecutive walks at connection start or end at the service level

[clukas1]

Hi,

To solve the issue of having potential consecutive walks when routing from a geo coordinate (e.g. walk to source stop (from service), followed by initial transfer between stops from the raptor router), I've added more QueryConfiguration options for the raptor module. Allowing to prevent transfers from source stops and transfers to target stops). I think this is the most elegant way of ensuring that any max walking time query configuration values are not violated.

In the process I was thinking about adding more optional configurations to the RAPTOR module. None of those are necessary, but might be nice to haves.

• Currently only public transit legs count towards rounds. Resulting in behavior that you might get two connections with one leg as a result (-> a slower walk from A-B (round 0) and a faster direct public transit connection from A-B (round 1). Although this response isn't bad. I've seen that the KIT implementation, has a configuration parameter to specify whether transfers should be applied in a separate round, which could maybe be an interesting extension.
• Also our algorithm currently doesn't allow chaining transfers to reach a destination. Probably also not the ultimate goal of a routing request but theoretically could be implemented to allow routing very edge case requests.

Last idea only service related (not raptor):

• In the QueryConfig we currently specify max walking time as a possible parameter. When routing from GeoCoordinates we look for stops within the proximity of 500 m (this value is configurable on the service level). However I think it would be better if we calculate or query stops using a search radius based on the query max allowed walking distance. (capping it with a reasonable max value when no max walking duration is specified).

[munterfi]

Thanks @clukas1, nice work!

Looks good to me.

I have adjusted some smaller style issues and as always have a request for documentation or maybe introducing an enum to clarify the documentation this way.

[munterfi]

Document and define what a source or target transfer is at the RAPTOR level in a simple sentence. Maybe also highlight why this configuration is important and what kind of issues are prevented by it.

My attempt:

Allow reaching a source or target stop via a transfer instead of a public transit leg.
Note: At the service level, this is only relevant for route requests to or from a stop, not to a geocoordinate.

Question: Would it make sense to introduce an enum for these cases instead of using two booleans?

/**
 * Policy for allowing transfers to reach a source or target stop
 */
public enum SourceTargetTransferPolicy {
    
    /** Transfers are not allowed for either source or target stops. */
    DENY,
    
    /** Allows transfers only for reaching the source stop. */
    ALLOW_SOURCE,
    
    /** Allows transfers only for reaching the target stop. */
    ALLOW_TARGET,
    
    /** Allows transfers for both source and target stops. */
    ALLOW;
}