GraphHopper.com | Forum | GitHub | Maps | Blog

GTFS routing and transfer issues


#1

We are using graphhopper for the TCAT bus system to navigate Ithaca, NY. We are seeing some odd behavior with routing. For example, a user needs to take the Route 30 and Route 14 to get to their destination.

Desired output:
They need to get off the bus once at a stop and wait for the Route 14 bus (a transfer).
While traveling on the Route 30, Route 30 finishes its service at a stop. It then begins a new iteration of Route 30 again from the same stop.(So the trip_id is different).
The traveller should get off at the first stop of this new Route 30 once it leaves its starting location.

I was thinking Graphhopper would be smart enough to detect the change in trip_id but just say ‘debark at the specific stop for the transfer’. This is not the case.

Actual output:

When the first route 30 finishes, graphhopper tells us to transfer to the 30 (which is the same bus, just a new trip id). However, the traveller isn’t really making a transfer. They stay on the bus and the same route.

We use isInSameVehicleAsPrevious to alert the user when they should stay on the bus. We believe it would be a more friendly, cohesive experience if the two legs of the Route 30 are considered to be one trip when giving directions.

Is this behavior intentional?

Best,

Austin


#2

It sounds exactly like the intended behavior. Maybe I don’t understand the issue, but the flag isInSameVehicleAsPrevious is exactly meant to describe this situation. So if you, say, build a GUI around this, you would use this flag to inform the user “stay on vehicle; trip id changes, but this is not a proper transfer”.

A changed trip id can be relevant. It depends on the situation on the ground. Maybe the bus driver stops, changes the headsign, and everything looks like a new trip is starting. Then the user wants to know this (to not be confused).

Or (as you are probably experiencing), the user can’t tell at all and the changing trip id is just a technicality. We don’t know.


#3

In any case, the solution to your issue is probably to merge a leg with the previous one whenever you encounter this flag.


#4

To give a bit more detail: This is the block feature of GTFS.

This page calls it an “in-seat transfer”.

The semantics is just “it’s somehow a new trip, but the passenger can remain seated”. Agencies can use it to model whatever they want. In particular, never-ending loop lines. But also completely different trips where the driver gets off and has a smoke in between.