-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transit paths should be preserved from GTFS #33
Comments
Looks like the 511 GTFS has accurate shapes for at least some transit routes in shapes.txt, for example Muni 67: (I should have used the 29 as the example again, but I'm sure it's fine too) But the LineString returned by GraphHopper just includes the stops. How do we get GraphHopper to pass through the full geometry? Also, for some providers, this geometry might be wrong; how should we handle that? I looked at a BART Yellow-S shape and it appeared to follow the curves correctly but it only included the portion of the line from Concord to Antioch for some reason (unless I made some mistake mapping it). |
It's nontrivial to determine what portion of the shape to display:
so you need a fuzz factor. Also, many bus routes have loops. So there's an optional If we did this in the router, we would have to implement the algorithm from scratch there, calling |
@arindam1993 want to do the honors of closing this? |
Fixed with a combination of bikehopper/gtfs-processor#3 and bikehopper/bikehopper-web-app#33 |
The GTFS data has detailed geometry for the routes that transit lines follow, but our router currently throws all of that away and gives geometry that just has 1 point per stop, which makes routes that curve look really bad.
Example: route from "Cole Valley" to "Philosopher's Hill and Labyrinth"
We should fix this either by changing the router to pass through the full geometry or possibly doing some client side querying of some service that exposes GTFS shapes.
The text was updated successfully, but these errors were encountered: