Routes blended with many options with the OD has many route alternatives

[loanho23]

Hi Developers,

I ran the gtfsrouter and had the table below with the 3 route options between this OD:

• Route 1: get in 141, transferring to 765n, then to B1 and, T9
• Route 2: get in 144, transferring B1 then T9
• Route 3: get in 170x, tranferring to B1 then T9 (this option appears to have an issue that is the time getting off 170x at Wynyard Station, York St, Stand M 7:56, while the time to get in at the first of T9 at Wynyard Station, Platform 3 is 7:52)

I interpreted these 3 routes based on my knowledge of Sydney, but I believe you have better idea how to classify and select appropriate routes from the source code.

I have 2 questions:

1. How can I separate these 3 route options? in your function scripts, is there any way to add route classification?
2. How can I eliminate inappropriate route like the Route 3 from the beginning, so the gtfsrouter doesn't create that route?

Thank you very much.

gtfsrouter::gtfs_route (gtfswithtransfersprep, include_ids = FALSE, from = as.character("Sydney Rd At Austin St"), to = as.character("Central Station"), start_time = 7 3600 + 6014, day = "tu")

	route_name	trip_name	stop_name	arrival_time	departure_time
5	141	Belrose	Sydney Rd At Austin St	7:17:02	7:17:02
6	141	Belrose	Sydney Rd After Hill St	7:17:57	7:17:57
8	141	Belrose	Sydney Rd Before Condamine St	7:19:00	7:19:00
13	141	Belrose	Sydney Rd At Woodland St	7:20:41	7:20:41
17	141	Belrose	Sydney Rd At West St	7:22:39	7:22:39
18	141	Belrose	Sydney Rd At Wanganella St	7:23:57	7:23:57
1	144	Chatswood	Sydney Rd At Austin St	7:15:00	7:15:00
2	144	Chatswood	Sydney Rd After Hill St	7:16:00	7:16:00
4	144	Chatswood	Sydney Rd Before Condamine St	7:17:00	7:17:00
10	144	Chatswood	Sydney Rd At Woodland St	7:19:00	7:19:00
12	144	Chatswood	Sydney Rd At West St	7:20:00	7:20:00
15	144	Chatswood	Sydney Rd At Wanganella St	7:21:00	7:21:00
20	144	Chatswood	Sydney Rd At Coral St	7:24:00	7:24:00
23	144	Chatswood	Manly Rd At Heaton Av	7:26:00	7:26:00
26	144	Chatswood	Manly Rd At Avona Cres	7:27:00	7:27:00
27	144	Chatswood	Spit East Reserve, Spit Rd	7:29:00	7:29:00
29	144	Chatswood	Spit Rd Opp Medusa St	7:33:00	7:33:00
31	144	Chatswood	Spit Rd Opp Bickell Rd	7:35:00	7:35:00
34	144	Chatswood	Spit Junction B-Line, Spit Rd	7:38:00	7:38:00
3	170X	Sydney	Sydney Rd At Austin St	7:17:00	7:17:00
7	170X	Sydney	Sydney Rd After Hill St	7:18:00	7:18:00
9	170X	Sydney	Sydney Rd Before Condamine St	7:19:00	7:19:00
11	170X	Sydney	Sydney Rd At Woodland St	7:20:00	7:20:00
14	170X	Sydney	Sydney Rd At West St	7:21:00	7:21:00
16	170X	Sydney	Sydney Rd At Wanganella St	7:22:00	7:22:00
19	170X	Sydney	Sydney Rd At Coral St	7:24:00	7:24:00
22	170X	Sydney	Manly Rd At Heaton Av	7:26:00	7:26:00
25	170X	Sydney	Manly Rd At Avona Cres	7:27:00	7:27:00
41	170X	Sydney	Wynyard Station, York St, Stand M	7:56:00	7:56:00
21	765n	Milsons Point	Manly Rd At Heaton Av	7:25:00	7:25:00
24	765n	Milsons Point	Manly Rd At Avona Cres	7:26:00	7:26:00
28	765n	Milsons Point	Spit East Reserve, Spit Rd	7:29:00	7:29:00
30	765n	Milsons Point	Spit Rd Opp Medusa St	7:33:00	7:33:00
32	765n	Milsons Point	Spit Rd Opp Bickell Rd	7:35:00	7:35:00
36	765n	Milsons Point	Spit Junction B-Line, Spit Rd	7:39:00	7:39:00
33	767n	Milsons Point	Spit Rd Opp Bickell Rd	7:36:00	7:36:00
35	767n	Milsons Point	Spit Junction B-Line, Spit Rd	7:38:00	7:38:00
37	B1	Sydney	Spit Junction B-Line, Spit Rd	7:39:00	7:39:00
38	B1	Sydney	Neutral Bay Junction, Military Rd, Stand A	7:44:00	7:44:00
39	B1	Sydney	Wynyard Station, York St, Stand M	7:51:00	7:51:00
40	T9	Central Station	Wynyard Station, Platform 3	7:52:54	7:53:54
42	T9	Central Station	Town Hall Station, Platform 2	7:56:00	7:57:00
43	T9	Central Station	Central Station, Platform 18	8:00:00	8:00:00

I really appreciate your development of this package which is very useful to create route options from the whole timetable. Loan

[mpadge]

Thanks for your encouraging words, and for engaging with the package. There are a couple of ways to approach your first question.

1. The gtfs_route() function, and the underlying gtfs_timetable() function which it calls as a pre-processing step, both have a route_pattern parameter which can be used to filter routes down to desired categories only. You could use this to only nominate the routes you desire. Or,
2. It seems like your first option (via 141) leaves 2 minutes later than your second (via 144), so you can obviously distinguish those just by specifying more precise start times.

It's a bit hard to know exactly what you're asking here, because I'm not sure what your output pasted above actually is - it seems to have all possible routes all mixed together in one data.frame, and so can not actually be the direct output of gtfs_route(). As for your second question: it really should not happen that a transfer leaves before it arrives - the 170X should never connect with B9 at Wynyard Station. If that really is what happens, then we indeed have a problem that needs to be resolved. But for that, we would need some actual reproducible code, which is i think is ultimately what is required to progress here. So could you please:

• Ensure that your entire code is generated by running reprex::reprex()?
• Include a location (URL) from where you have downloaded your original GTFS feed. A convenient way to do this is with lines like the following:

  setwd ("<my>/<directory>") # and delete those details from version you paste here
  if (!file.exists ("sydney-gtfs.zip")) { # or whatever you call your local file
  download.file (url = "<url>/<to>/<gtfs>/<zip>/<file>.zip")
  if (!file.exists ("sydney-with-transfers.Rds")) {
  gtfs <- extract_gtfs("sydney-gtfs.zip")
  gtfs <- gtfs_transfer_table (gtfs) # plus any other parameters you've set
  saveRDS (gtfs, file = "sydney-with-transfers.Rds")
  } else {
  gtfs <- readRDS ("sydney-with-transfers.Rds")
  }
  # ... then on with the code necessary to reproduce your observations described above

• Ensure that you demonstrate the code you used to generate the three different results which you describe above, and which i presume are bundled together in your single table

Thanks!

[loanho23]

Excellent! Thank you very much for your quick answer!

I've tried more options in gtfs_route(), route_pattern doesn't change my result but max_transfers and earliest_arrival helped filter many cases. However, there is still some blends if the ODs route returns many options.

I will create a reproducible example and add it as an additional comment.

[mpadge]

Thanks @loanho23. Note also that I found a bit of a bug in the code which led to some strange-looking routes appearing. Please make sure that you re-install the latest dev version before proceeding. That alone might go some way to fixing some of your previous issues.

[loanho23]

Many thanks @mpadge.

After installing the latest version as you suggested, most of the routes were improved. Appreciated lots.

I have another question that when I set max_transfers = 2, the result still returned more than 2 transfers( the test file attached with the scripts below). I am wondering how you considered number of transfers? Is that based on trip_id or trip_name or something else?

selected_greater_sydney_gtfs_static.zip

library(gtfsrouter)

gtfstest <- extract_gtfs("selected_greater_sydney_gtfs_static.zip") gtfstest$transfers <- gtfs_transfer_table(gtfstest, d_limit = 500, min_transfer_time = 120) gtfsprepared <- gtfs_timetable(gtfstest, day = "tu")

routetest<-gtfs_route(gtfsprepared, from="Pittwater High School, Mona St",to="Central Station", start_time=360010+(6022), max_transfers = 2, earliest_arrival = TRUE)

Thank you very much for your interaction and help!

[mpadge]

The commit linked above updates the description of the max_transfers parameter which should hopefully now explain why you still see more than 2 transfers. The updated description reads:

\item{max_transfers}{If not \code{NA}, specify a desired maximum number of transfers for the route (including but not exceeding this number). This parameter may be used to generate alternative routes with fewer transfers, although actual numbers of transfers may still exceed this number if a value is specified which exceeds the minimal feasible number of transfers.}

That parameter should perhaps be replaced with something more directly usable like a minimise_transfers = FALSE option, but hopefully at least in the current form that is sufficiently clear why you can not reduce numbers of transfers - it is simply not possible to get from Pittwater to Central Station with the feed data as given there with less than 4 transfers.