Issue routing to and from stations with quays spread over a wide area

[habrahamsson-skanetrafiken]

Problem: We've got stations with quays spread over a large area. Here is the overview of Malmö central station with all its quays marked in orange:

When searching to or from a station by id, OTP currently searches to and from all the quays belonging to that station. This causes some unwanted behaviours. Here are two examples:

1) Disembark early and walk to a nearby quay. We sometimes get the behaviour that it is cheaper and faster to disembark a bus ride and walk to one of the quays instead of continuing on the bus ride until the destination:

Current Behaviour: (this shows the egress using walking to a nearby quay belonging to Malmö C)

Expected Behaviour: (This shows the trip going all the way to Malmö C by the bus line)

---

2) Wierdness in direct search. The same underlying issue causes some strange behaviour for direct street searches where you search for a path to Malmö C but are directed to a quay that is far away from the actual station building that users expect.

Current Behaviour: This shows two street searches from opposite sides of Malmö C. Both searches have Malmö C as their destination. F and T means "From" and "To" in the image.

Expected Behaviour: A user would expect both searches to end at the same place in the central station building like this:

Possible solution

Our proposed solution to this issue is to enable a new behaviour where access/egress/direct search always uses the centroid coordinate when searching from a station id.

This should only affect search results where the itinerary starts/ends with an access/egress leg (also direct searches). If you search from Malmö C and there is a bus leaving from a quay belonging to Malmö C, you shouldn't have to walk from the centroid to the quay but get a result starting directly at the quay like it currently works.

[t2gran]

We can extend OTP to support an access/egress to a point at a Station. But, we should not use the centroid, since the purpose is for displaying the name in the map. If we use a point, we should extend the model with a StopPlace/Station "meeting point". If no "meeting point" exist we should fall back to todays implementation navigating to one of the quays.

[t2gran]

I went another round on this here at Entur, and we came up with a simpler solution. I think the use-cases for this feature are rare, so maybe we should aim for a simpler solution. So an alternative solution is:

• Having a list of station(StopPlace) ids in the config where you want to use the centroid as the origin or destination instead of the stops(quays). I would then implement this by doing the search with walk legs to the centroid, but remove the "extra" leg before presenting it to the user. Remember to adjust times and cost as well. Is this something you can live with? We could expand this solution later to add a coordinate in the config if needed - but I would use the centroid first.

[habrahamsson-skanetrafiken]

@t2gran Using the centroid for only a list of stations would be a fine solution for us. That way we could enable it for only the stations where we actually have this problem.

I didn't quite understand how you meant this could be implemented. My idea was to modify the access/egress-search something like this:

• Make a distinction between directAccessEgress and streetAccessEgress.
• DirectAccessEgress are 0 length to the quays that belong to the station id you are searching from/to.
• StreetAccessEgress we would get by doing a street search either from the station centroid or the quay vertices depending on configuration. I think this solution would only add minimal complexity and should be easy to maintain.

[t2gran]

When using a centroid, you will need to add time/cost to the access/egress to make Raptor pick the stops closer to the centroid over the stops futher away. We can do that be having a special AccessEgress implementation or remove the leg afterwards - it does not matter. In both cases the time and cost of the path/itinerary need to be adjusted (remove the "fake" part).