Waiting till midnight to check next buses

[jidanni]

Just to get things rolling:
I'm just your average bus passenger.
The buses in my home town run from 6AM-10PM.
At 00:01 I can check how the buses will be at 6AM.
But if I check earlier, all the bus apps just say "last bus already left"
If I were in charge, even at 11PM I should be able to see the 6AM situation.
Anyway, is this somehow the fault of GTFS?

[skalexch]

@jidanni that should not be the fault of GTFS. The GTFS feed transmits the schedules, and the trip planning app/platform ingests the feed and presents the schedule. What you are describing can happen because the trip planner decided to think of the present moment only. This decision is left to the trip planner: either a) always showing you the next bus or b) showing you the current bus (or nothing) and only showing you the 6am buses if you plan a trip that starts around 6am.

[jidanni]

OK, thanks. All I know is of the ten or so apps on Google Play, no matter what towns' busses one selects, they all have the same behavior, for all towns in Taiwan.

[aaronrumph]

@jidanni I can certainly agree with @skalexch that this is the fault of the apps, not GTFS. For some information about the likely cause: GTFS's 'Time' format allows for times after midnight (e.g. 25:30:00 rather than 01:30:00) so that agencies can convey that a trip past midnight is considered part of the same service day. Because of the way transit routing is done (RAPTOR), trips are typically filtered to only those on a specified service date (presumably they use the current date) . As such, if there are no remaining trips on that day, it will not show any at all. IMO they should take the approach of, "user asks for trips today, but there are no trips left today, well then I should show the next available trips (with their dates/times)". It is worth asking the developers of whichever app you use to support this, as it is not very difficult to implement. For what it's worth, in the US, the transit app seems to do what you want it to.

[felixguendling]

Because of the way transit routing is done (RAPTOR), trips are typically filtered to only those on a specified service date (presumably they use the current date)

I'm not sure about proprietary engines but MOTIS and OTP are not limiting the search to only one day by default. This is definitely not a limitation of the RAPTOR algorithm.

[aaronrumph]

Agreed, not a limitation of RAPTOR at all, just that if you're trying to use RAPTOR to answer "when are the next departure times" some implementations use a date to filter trips (see r5/r5py) so that when you run a query you run it for a specific departure time on a specific date. The behavior of "at 23:59 shows no trips, 00:01 the next day shows trips" is explained by this. They could easily change their implementation to include trips from the next service day if they want. It is not that RAPTOR inherently forces them to choose, just that when they do implement RAPTOR, they may not want it to show a route if it's next available trip is a week from now (since you're trying to leave now), so they (could) prune based on date. Given the original commenter's experience, that is almost certainly what's happening, although as you say it is NOT a limitation of RAPTOR.

The not supporting trips past midnight on same service day is a separate issue, my apologies if I conflated the two in my original comment. (e.g. R5 not supporting routing through midnight: conveyal/r5#973 (comment))

While I do not know well enough to say for certain, my guess is that some sort of similar pruning is used by MOTIS/OTP (it seemed to me to be this way based on their API documentation). Some pruning is almost always used (from what I have seen), as otherwise, when reaching a stop in RAPTOR and iterating through all the trips that serve that route, you would have to include ALL trips from the query date until the last date in the feed. I could definitely be wrong though :)

[skinkie]

I love to finally write this. So rrrr is really superior to r5 :-D