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

Routing result #9

Closed
polettif opened this issue Feb 20, 2019 · 4 comments
Closed

Routing result #9

polettif opened this issue Feb 20, 2019 · 4 comments

Comments

@polettif
Copy link
Collaborator

Thank you for fixing routing with character ids in #2! I now have a question about the routing result. I've run the following code with a test feed. (I did use this feed for other calibrations of sorts and I can't see anything wrong with it but there might still be an error somewhere).

gtfs <- gtfsrouter::extract_gtfs("routing.zip")
route <- gtfsrouter::gtfs_route(gtfs, "One", "Four", 7*3600)
print(route)
#>    route  stop departure_time arrival_time
#> 1 Line B   One       07:10:00     07:10:00
#> 2 Line B Three       07:29:00     07:28:00
#> 3 Line B  Four       07:37:00     07:37:00
#> 4 Line A   One       07:00:00     07:00:00
#> 5 Line A   Two       07:05:00     07:04:00
#> 6 Line A Three       07:12:00     07:11:00
#> 7 Line A  Four       07:40:00     07:40:00

Created on 2019-02-20 by the reprex package (v0.2.1)

Is this the route to take or are these multiple possible routes since One appears twice? What I'd expect is the following route:

#>    route  stop   departure_time arrival_time
#> 1 Line D  One    07:17:00       -
#> 2 Line D  Three  -              07:23:00
#> 3 Line B  Three  07:29:00       -
#> 3 Line B  Four   -              07:37:00

which is optimised for earliest arrival, then minimal travel time. Though there might be other optimisation criteria like number of transfers.

@mpadge
Copy link
Member

mpadge commented Feb 21, 2019

Cool demo - thanks! It's definitely a bug, now I've just got to figure out a way of fixing it that doesn't break main functionality...

@mpadge mpadge closed this as completed in e684c74 Feb 21, 2019
@mpadge
Copy link
Member

mpadge commented Feb 21, 2019

That fixes the main problem, and produces this:

devtools::load_all (".", export_all = TRUE)
#> Loading gtfsrouter
gtfs <- gtfsrouter::extract_gtfs ("routing.zip")
gtfsrouter::gtfs_route(gtfs, "One", "Four", 7*3600)
#>    route  stop departure_time arrival_time
#> 1 Line A   One       07:00:00     07:00:00
#> 2 Line A   Two       07:05:00     07:04:00
#> 3 Line A Three       07:12:00     07:11:00
#> 4 Line A  Four       07:40:00     07:40:00

Created on 2019-02-22 by the reprex package (v0.2.1)

I'll now re-open to consider how to optimise routing based on your fantastic demo data

@mpadge mpadge reopened this Feb 21, 2019
@mpadge
Copy link
Member

mpadge commented Feb 23, 2019

current status:

devtools::load_all (".", export_all = TRUE)
#> Loading gtfsrouter
gtfs <- gtfsrouter::extract_gtfs("routing.zip")
gtfsrouter::gtfs_route(gtfs, "One", "Four", 7*3600 + 10 * 60)
#>    route  stop departure_time arrival_time
#> 1 Line B   One       07:10:00     07:10:00
#> 2 Line B  Five       07:15:00     07:15:00
#> 3 Line B   Six       07:21:00     07:20:00
#> 4 Line B Three       07:29:00     07:28:00
#> 5 Line B  Four       07:37:00     07:37:00
gtfsrouter::gtfs_route(gtfs, "One", "Four", 7*3600 + 10 * 60 + 1)
#> Error in gtfsrouter::gtfs_route(gtfs, "One", "Four", 7 * 3600 + 10 * 60 + : No route found between the nominated stations

Created on 2019-02-23 by the reprex package (v0.2.1)

That error should obviously not happen - FIX!


EDIT: Nope, it's okay, I just ran it on a Sunday, but specifying day gives this:

devtools::load_all ("/data/mega/code/repos/atfutures/gtfs-router", export_all = TRUE)
#> Loading gtfsrouter
gtfs <- gtfsrouter::extract_gtfs("/data/mega/code/repos/atfutures/gtfs-router/routing.zip")
gtfsrouter::gtfs_route(gtfs, "One", "Four", 7*3600 + 10 * 60)
#>    route  stop departure_time arrival_time
#> 1 Line B   One       07:10:00     07:10:00
#> 2 Line B  Five       07:15:00     07:15:00
#> 3 Line B   Six       07:21:00     07:20:00
#> 4 Line B Three       07:29:00     07:28:00
#> 5 Line B  Four       07:37:00     07:37:00
gtfsrouter::gtfs_route(gtfs, "One", "Four", 7*3600 + 10 * 60 + 1, day = 3)
#>    route  stop departure_time arrival_time
#> 1 Line D   One       07:12:00     07:12:00
#> 2 Line D Three       07:18:00     07:18:00
#> 3 Line B Three       07:29:00     07:28:00
#> 4 Line B  Four       07:37:00     07:37:00

Created on 2019-02-23 by the reprex package (v0.2.1)

@mpadge
Copy link
Member

mpadge commented Feb 25, 2019

@polettif That commit and the previous two implement this:

devtools::load_all (".", export_all = FALSE)
#> Loading gtfsrouter
gtfs <- extract_gtfs("routing.zip")
gtfs_route(gtfs, "One", "Four", start_time = 7*3600, routing_type = "first_depart")
#> Day not specified; extracting timetable for Monday
#>     route  stop departure_time arrival_time
#> 1 routeA1   One       07:00:00     07:00:00
#> 2 routeA1   Two       07:05:00     07:04:00
#> 3 routeA1 Three       07:12:00     07:11:00
#> 4 routeA1  Four       07:40:00     07:40:00
gtfs_route(gtfs, "One", "Four", start_time = 7*3600, routing_type = "x")
#> Day not specified; extracting timetable for Monday
#>     route  stop departure_time arrival_time
#> 1 routeD2   One       07:17:00     07:17:00
#> 2 routeD2 Three       07:23:00     07:23:00
#> 3  routeB Three       07:29:00     07:28:00
#> 4  routeB  Four       07:37:00     07:37:00

Created on 2019-02-25 by the reprex package (v0.2.1)

Setting earliest_departure to anything other than "first_depart" will route for the earliest arrival time instead, which in your case differs - see ?gtfs_route:

#' @param routing_type If `"first_depart"` (default), calculates the route
#' departing with the first available service from the nominated start station.
#' Any other value will calculate the route that arrives at the nominated
#' station on the earliest available service, which may not necessarily be the
#' first-departing service.

I've set that parameter as a character string at present, to allow for additional possibilities to be analysed as the package develops.

EDIT: Your comment above about number of transfers will be addressed in #1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants