Open derhuerst opened 3 years ago
This has been on the TODO list for some time now, as it was one of the first questions after the presentation of pfaedle at the 2018 SIGSPATIAL. At the moment, there are performance issues that speak against it. However, we have done extensive development to improve the map-matching performance during the last 12 months. This has not yet been merged into master, largely because it has not yet been tested sufficiently and also came with an update of many configuration parameters, and I don't want to break backwards-compatibility of config files. As soon as the translation of legacy config parameters into the new parameters is done, we will merge the improvements into master, at which point we might add this option.
I often work with GTFS feeds that have rough shapes for almost all trips, but map-matching them to roads would make them more precise.
I don't want to use the
-D
/--drop-shapes
option because, if I understand the mechanism correctly, recalculating the entire shape comes down to guessing the most straightforward path between to stops, essentially routing. If the bus doesn't take the most straightforward/fastest/obvious route though, but e.g. follows a meandering path within a local area, the map-matching will end up with a different shape than what the bus actually follows.Therefore, would it be an option to use the existing shape points as "guiding points" when doing map-matching? I haven't looked at how pfaedle works technically, but I imagine these guiding points could serve the cost function in a routing algorithm like A*.