search

ad-freiburg / pfaedle

Precise map-matching for public transit feeds. Generates high-quality GTFS shapes from OSM data.
GNU General Public License v3.0
206 stars 29 forks source link

Some routes are incorrectly calculated #58

Closed Ge-Rag closed 2 days ago

Ge-Rag commented 6 days ago

Pfaedle is a wonderful tool to generate shapes.txt. Since most of the shapes.txt delivered with feeds are useless I am re-creating them with pfaedle.

Now I have come across a problem with routing, where pfaedle generates a deviation instead of connecting two stations directly.

After processing the Canada feed the trip 1751-505 results in this route: grafik

Here the connection from Sayabec to Mont-Joli is interrupted. This results in the fact that in the train simulation, the vehicle goes to Sayabec and then returns to Pacific Junction to then reach Mont-Joli on the route that appears to have no valid stations.

The GTFS Feed from Canada is here: https://s3.gtfs.pro/files/uran/improved-gtfs-viarail.zip

I am using a continental OSM file for North America found at: https://download.geofabrik.de/north-america-latest.osm.pbf

The same happens with trips from Los Angeles to Chicago sample trip id: 97370 grafik

The feed is from here: https://content.amtrak.com/content/gtfs/GTFS.zip

Now I definitely don't know if this is a pfaedle problem or if the OSM file is faulty. Pfaedle has not issued any warnings or errors.

In any case if it is an OSM file problem then I'd rather have pfaedle draw a straight line to the next station than calculation such a lengthy deviation.

BTW I removed all shape info from these feeds before running pfaedle.

Thank you.

Georg Ragaz

https://trainspotter.ragaz.net

patrickbr commented 3 days ago

This type of problem usually hints at a problem in the underlying OSM data (some gap which is often invisible on the rendered maps). I will investigate this.

pfaedle actually does draw straight lines between two stations if no route below a threshold cost can be found. However, in your cases, the resulting connections are still below this fallback threshold (if this threshold is too low, valid hops will be discarded).

patrickbr commented 2 days ago

I have now reproduced this, and it was a problem with the internal bounding box used for cropping the OSM data. The default padding around the box computed from the GTFS stops (2,5 km) was not enough to capture a small part of the rail tracks around Mont-Joli. I have now increased this padding to 20 km, and have also made it configurable via -b [ --box-padding ]. Can you please try again with the latest master?

Ge-Rag commented 1 day ago

Thank you very much!

Now it is working with default settings and the gaps in both routes are closed, plus some others have no longer straight line connections.

grafik