motis
motis copied to clipboard
Shape is not correctly processed
While debugging and seeing further differences between OTP and this router one thing that popped into my eye is that not always the shapes are correctly generated:
For example:
1.
https://ro.motis-project.de/?lang=en#/trip/stpt_3005/0/1672720500/stpt_2706/1672721700/16
https://ro.motis-project.de/?lang=en#/trip/stpt_7820/0/1672721880/stpt_10340/1672723680/E2
This might be because of the OSRM profile that is used. Or it could be because of bad OSM data.
Thank you for your report! Currently, MOTIS is not using the shapes.txt
that come with GTFS datasets and can be generated with tools like https://github.com/ad-freiburg/pfaedle. I think instead of fixing the map matching in MOTIS, the best solution would be to extend the path module to be able to read the shapes.txt
from the loaded GTFS timetables, so the map matching implemented in MOTIS is would only be a fallback solution. We welcome contributions in this area :)
Since pfaedle is written in C++, it would theoretically be possible to switch the path
module to use pfaedle (to reduce code maintenance effort). However, the license of pfaedle (GPL) would not allow to statically link MOTIS into one dependency-free binary as we do it now.
honestly, I would make this configurable if possible -> so to make use of shapes but still do the matching because from personal experience those shapes are not always perfect, and they not always snap into place on actual road.
Also pfaedle does not work with PBF files and that's a big downside. Normally things should go smooth if the lua file for bus profile is covering all those cornercases.
We're using this profile to compute bus routes: https://github.com/motis-project/osrm-backend/blob/motis/profiles/bus.lua
If it's a very simple case, changing the parameters in the lua file might already fix the problem. So it could help to run MOTIS with a different bus profile. To do this, you need to delete the preprocessed files in the data/osrm
folder.