MOTIS misses optimal route
dvdkon opened this issue · comments
While testing MOTIS on my Czech dataset I noticed that I couldn't get it to generate what I consider to be the optimal route (seen here on a proprietary route planner):
On my testing instance (config) the same query looks like this:
It does manage to get a similar route time by boarding the train elsewhere, but the proposed route has only one transfer, so from my understanding it should be displayed as a Pareto-optimal option. When I increase the max walking distance, MOTIS shows a route consisting of just the train, so I think the tram-train route should also be found.
Sadly, I don't have any further ideas on how to debug this.
For me, the first route does not make sense. They say the footpath takes 9 minutes but the arrival and departure time are 8 minutes apart (arrival 12:35, departure 12:43). So it should not be possible to change there. Can you find the 8 minute footpath in the transfers.txt file? As you mentioned elsewhere you are using the transfers module which is experimental. Can you please disable it and use the footpaths from the GTFS file? Then it's easier to debug as every footpath contained in a journey used for comparison with MOTIS has to be contained in this GTFS dataset.
I checked you dataset and it's missing the transfers.txt file. As the interchange is quite tight (almost not possible), it can just be that the transfers module produces a >8min footpath and then the journey would not be feasible. Maybe you can try to disable the transfers module and set link_stop_distance=400 as the stops seem to be ~400m (direct line distance) apart.
Thanks, I sadly can't disable the transfers module since my GTFS output doesn't contain hardcoded transfers (I'd have to generate them from a routing engine anyway). Is there any way to dump the generated transfers?
The other planner might be omitting some sub-minute details, and I can't account for its different routing engine, but it's definitely possible to compose a similar route with an earlier tram that gives enough headroom and is still faster than walking to the train.
Strangely disabling transfers and setting link_stop_distance=400 (or even higher) still doesn't produce that transfer, while creating some unreasonable results (tram stops along a line get transitively joined, so > 1 km gets somehow turned into a 2 min footpath).
One thing to note: I wanted to add a manual transfer to the stops for debugging, but realised I couldn't, since they're both in different GTFS feeds. Maybe this has something to do with the issue?
Yes, then link_stop_distance doesn't do anything at the moment. Maybe this variable should be used in general.
As your script is compiling MOTIS from scratch anyway, can you please change the maximum distance in this line?
https://github.com/motis-project/nigiri/blob/7f0c17b2d363a400cfad191795fb543d7b28b68f/src/loader/link_nearby_stations.cc#L12
It should be located at motis/deps/nigiri/src/loader/link_nearby_stations.cc.
Thanks for the reference, I first tried setting it to just 10 (then recompiling and deleting caches), and with an extra transfer added to the GTFS (tram to dummy stop on top of train station) MOTIS did actually find and report the expected route. I guess this suggests it's being "outcompeted" by another variant?
Setting it to 500, MOTIS finds the route too, just with a very low transfer time (since it's just measuring the direct path length).
Another observation: Setting kLinkNearbyMaxDistance to 10 and re-enabling the transfers module also breaks routes that transferred at "Praha-Veleslavín" (another train station, such routes were present in my first tests). I think I can say that transfers doesn't generate tram-train transfers for me (or maybe inter-feed transfers in general?)
and with an extra transfer added to the GTFS (tram to dummy stop on top of train station)
I guess this is the best way for now. We're working on improving the transfers module to handle all cases properly for different profiles. But until then (and if you don't want to have a high preprocessing time), giving MOTIS explicit data (like in this case) is required to make it work.
and re-enabling the
transfersmodule
The transfers module will be reworked from scratch and was experimental anyway. So I would not recommend using it at the moment.
The transfers module will be reworked from scratch and was experimental anyway. So I would not recommend using it at the moment.
That's a shame. If you'll be reworking transfer routing, I guess I'll wait until something's changed before testing this again.
If you're happy with the results it produces already now, it's of course fine if you continue to use it.