Closed alenastern closed 1 year ago
Hi @alenastern, thanks for opening the issue.
Some clarification on the GTFS side of things: R5 uses its own GTFS-handling libraries and we've found it to be quite "picky" with some GTFS inputs. So your suspicion that the some problem with the GTFS might be causing all of this is quite correct, but we can't easily spot problems in the GTFS and raise errors in the r5r side of things.
I recommend validating your GTFS files using the dev version of {gtfstools}
that includes a wrapper to the MobilityData Canonical GTFS validator. It not only checks if tables/fields exist and are correctly named, but also perform some "business logic" validation, such as checking if there are too fast trips, if some stops are too far from the trip shapes, etc. Most of these problems shouldn't affect the routing process, but perhaps we can identify something relevant to this issue.
Since you also mention that you'd like to programatically check for problems in the feed, the validation output includes a JSON file that can be used to parse potential breaking problems. On sample data, that's how you'd use it:
remotes::install_github("ipeaGIT/gtfstools")
library(gtfstools)
data_path <- system.file("extdata/spo_gtfs.zip", package = "gtfstools")
output_path <- tempfile("validation_result")
validator_path <- download_validator(tempdir())
validate_gtfs(data_path, output_path, validator_path)
You could then inspect the validation result as HTML or JSON to see if some issue relates to this problem.
On top of Daniel's suggestion, please note that the output message of r5r
says "No transit stops were reached or no transit modes were selected."
I woud suspect that, perhaps, your origin / destination points are not in the same region of the GTFS.zip and OSM.pbf data used to create the network. I would suggest ploting the network data and the origin / destination points to check if that's the case. You could do that with little effort with code along these lines:
library(r5r)
library(ggplot2)
# extract transit network from r5r_core
transit_net <- transit_network_to_sf(r5r_core)
# plot
ggplot() +
geom_sf(data=transit_net$routes) +
geom_point(md_start_points_transit_n, aes(x=lon, y=lat))
Hi @alenastern -- much of the GTFS logging/validation in R5 is tailored to the Conveyal cloud platform for regional accessibility mapping. For example, we added a set of validation messages to our user interface last year (https://docs.conveyal.com/changelog/2021/05/15/). I'm not sure how well suited this validation is for logging in third-party tools like r5r, but I would be happy to chat more with you if it might be helpful.
Thank you all so much for your help and I apologize for the delay in following up.
@dhersz - as you predicted, an issue with some GTFS files was causing the issue and the dev version of gtfstools
was very helpful in getting to the bottom of things! One challenge I found using the tool for the purposes of validating gtfs inputs for routing in r5r
is that validate_gtfs()
identifies a large number of errors, only some of which cause transit routing to break in r5r
. As a user, it would be amazing to have some field that indicates which errors would be "critical errors" in that way though I realize that may not be feasible! I was able to identify the specific errors in my case through a bit of digging, which I've outlined here in case it's helpful.
@ansoncfit - one challenge I found with debugging these errors is that it seems that r5 deviates a bit from the gtfs static reference in what is valid in both of these cases. I'm not sure if this is more clear in the user interface, but it would be amazing to give users a heads up on where r5's data requirements deviate from the reference (or potentially align r5 with the gtfs static reference in these cases).
Issue 1: the monorail route type
One of the transit agencies in my focus area is a monorail, and includes routes with route_type
= 12 in routes.txt
, which is the valid gtfs code for monorail but caused the r5r
transit routing to return no results as described above.
Issue 2: headway_secs
equal to 0
Values of 0 for headway_secs
in the frequencies.txt
file cause the transit routing to return no results. This case is a bit less clear because the gtfs reference indicates "non-negative integers" are valid values for headway_secs
, which I'd interpret to include 0 as a valid value, but I realize that might just be my interpretation!
I hope this is useful to you all in your work creating such tremendously useful software (truly, thank you!). Please let me know if you have any questions and thank you again for your help!
Hi @alenastern,
Regarding monorails, starting with v6.6 r5 accepts GTFS route_type
= 12 and maps it to the r5 TRAM
mode. Further details are available at https://docs.conveyal.com/prepare-inputs#uploading-gtfs-feeds
Awesome news @ansoncfit! Thank you!
Hi @alenastern . I guess we can close this issue, right? Or are there any pending problems ?
closing this issue due to inactivity. Happy to reponen it if the issue persists
Hello! I'm using r5r to create origin-destination travel time matrices using
r5r::travel_time_matrix()
. The problem I'm running into is that my graph is building successfully (returningnetwork.dat
and not producing any obvious error messages when I inspect the verbose console output), yet when I try to find transit routes usingtravel_time_matrix()
as shown below, the code runs but doesn't return anything.I suspect the problem is with some of the input GTFS files, as when I delete some of the files and try rebuilding the graph, I'm able to successfully obtain transit routes using the identical code below. I identified the GTFS files that I suspect are causing the issue using
tidytransit::read_gtfs()
to validate the GTFS files (see full function below), and identified that some files had non .txt files in the zip file (generally a pdf developer agreement). I cleaned the GTFS files to remove the non .txt files, and then was able to runtidytransit::read_gtfs()
successfully on all my GTFS files without error. However, I continued to have the same issue withtravel_time_matrix()
for transit trips until I removed the cleaned GTFS files for the agencies that were having issues. This makes me think that there is some other issue in one or more of these files affecting the graph build, but I'm not able to figure out what it is. I inspected thesetup_r5()
output for those agencies specifically and also didn't identify any clear errors.I've included two
travel_time_matrix()
calls in the code example below: the first runs on the full set of start and end points and the second on a subset. The first call runs and returns similar console output as the second (notably the "Skipping transit search. No transit stops were reached or no transit modes were selected" messages), but only the second call returns the "java.util.concurrent.ExecutionException".I also tried inspecting the transit elements of the graph using
transit_network_to_sf(r5r_core)
and did find that a transit network was present.My questions are:
Thanks so much for your time and for creating such a great package!
Example
Function to validate gtfs files:
Selected console output for second
travel_time_matrix()
call above: