Skip to content
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

Closed
graue opened this issue Mar 4, 2022 · 4 comments
Closed

Transit paths should be preserved from GTFS #33

graue opened this issue Mar 4, 2022 · 4 comments
Labels
bug Something isn't working

Comments

@graue
Copy link
Contributor

graue commented Mar 4, 2022

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"

image

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.

@graue
Copy link
Contributor Author

graue commented Dec 3, 2022

Looks like the 511 GTFS has accurate shapes for at least some transit routes in shapes.txt, for example Muni 67:

image

(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).

@graue graue added the bug Something isn't working label Jan 10, 2023
@graue graue changed the title make bus paths follow the road Transit paths should be preserved from GTFS Jan 10, 2023
@graue
Copy link
Contributor Author

graue commented Jan 22, 2024

It's nontrivial to determine what portion of the shape to display:

Shapes do not need to intercept the location of Stops exactly, but all Stops on a trip should lie within a small distance of the shape for that trip, i.e. close to straight line segments connecting the shape points.

so you need a fuzz factor. Also, many bus routes have loops. So there's an optional shape_dist_traveled in stop_times.txt. About 70% of the 511 entries have it. In theory if correctly filled out, this makes it easy? SamTrans doesn't have it though. https://gtfs.org/schedule/reference/#shapestxt

If we did this in the router, we would have to implement the algorithm from scratch there, calling getTripGeometry on the GTFSFeed class, then subdividing the shape to only the relevant portion.

@graue
Copy link
Contributor Author

graue commented Jan 2, 2025

@arindam1993 want to do the honors of closing this?

@arindam1993
Copy link
Contributor

Fixed with a combination of bikehopper/gtfs-processor#3 and bikehopper/bikehopper-web-app#33

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants