Transit mode not used, problems with GTFS data?

[toreueland]

Brief description of the problem:

When running analyses using the transit mode, either the analysis freezes up or only the walking mode is used, i.e. the results are exactly the same as with "WALK" selected. The example data from Porto Alegre seems to work fine, so I suspect there's an issue with the GTFS files.

Data

All the data seems too large to upload here, but i'm using osm and height data for the province Rogaland in Norway.

NJ_100m.csv
Points on a 100 meter grid for the area. Not sure if I can publish the oppertunity data freely so those are randomized.

GTFS Kolumbus
GTFS Go-Ahead Nordic

Code

data_path <- system.file("extdata/nj", package = "r5r")

r5r_core <- setup_r5(data_path, verbose = TRUE)

departure_datetime <- as.POSIXct("04-07-2024 14:00:00",
                                 format = "%d-%m-%Y %H:%M:%S",
                                 tz = "Europe/Oslo")

mode <- c("TRANSIT", "WALK")

points <- fread(file.path(data_path, "NJ_100m.csv"), dec = ",", colClasses = list(character = "id"))

origins <- points[25230]
destinations <- points[18408]

det <- detailed_itineraries(r5r_core = r5r_core,
                            origins = origins,
                            destinations = destinations,
                            mode = mode,
                            departure_datetime = departure_datetime,
                            shortest_path = FALSE,
                            max_trip_duration = 600,
                            progress = TRUE)

head(det)

Result

Simple feature collection with 1 feature and 16 fields
Geometry type: LINESTRING
Dimension:     XY
Bounding box:  xmin: 5.719 ymin: 58.824 xmax: 5.73611 ymax: 58.84778
Geodetic CRS:  WGS 84
  from_id from_lat from_lon to_id   to_lat   to_lon option departure_time total_duration total_distance segment mode segment_duration wait distance route
1    5633 58.84771 5.733333  3274 58.82406 5.718789      1       14:00:00           51.5           3066       1 WALK             51.5    0     3066      
                        geometry
1 LINESTRING (5.733467 58.847...

This should in reality be a short train trip. I have tested many other locations and ran the accessibility analysis, but i'm facing the same problem.

The GTFS files have the same feed_info. I don't know if this can pose problems but I have tried editing one of them to a placeholder. I have also tried, for example, editing the route_type as I noticed that this GTFS data uses Extended route types. I noticed the example data set provided uses the basic ones, e.g. bus = 3, so I have tried editing them, but this did not fix the issue.

Situation report

[1] �\u0080\u00982.0�\u0080\u0099

$r5_jar_version
[1] "7.1"

$java_version
[1] "21.0.3"

$set_memory
[1] "-Xmx8G"

$session_info
R version 4.4.0 Patched (2024-05-26 r86634 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 11 x64 (build 22631)

Matrix products: default


locale:
[1] C

time zone: Europe/Oslo
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] viridis_0.6.5     viridisLite_0.4.2 interp_1.1-6      h3jsr_1.3.1      
 [5] gtfstools_1.2.0   elevatr_0.99.0    tidytransit_1.6.1 osmdata_0.2.5    
 [9] ggplot2_3.5.1     data.table_1.15.4 raster_3.6-26     dplyr_1.1.4      
[13] sp_2.1-4          sf_1.0-16         r5r_2.0           rJava_1.0-11     

loaded via a namespace (and not attached):
 [1] tidyr_1.3.1        utf8_1.2.4         generics_0.1.3     class_7.3-22      
 [5] KernSmooth_2.23-24 lattice_0.22-6     hms_1.1.3          digest_0.6.35     
 [9] magrittr_2.0.3     grid_4.4.0         jsonlite_1.8.8     backports_1.5.0   
[13] e1071_1.7-14       DBI_1.2.2          gridExtra_2.3      purrr_1.0.2       
[17] fansi_1.0.6        scales_1.3.0       gtfsio_1.1.1       codetools_0.2-20  
[21] cli_3.6.2          rlang_1.1.3        units_0.8-5        munsell_0.5.1     
[25] withr_3.0.0        tools_4.4.0        geodist_0.1.0      deldir_2.0-4      
[29] checkmate_2.3.1    colorspace_2.1-0   geojsonsf_2.0.3    curl_5.2.1        
[33] vctrs_0.6.5        R6_2.5.1           proxy_0.4-27       lifecycle_1.0.4   
[37] classInt_0.4-10    V8_4.4.2           pkgconfig_2.0.3    progressr_0.14.0  
[41] terra_1.7-78       pillar_1.9.0       gtable_0.3.5       glue_1.7.0        
[45] Rcpp_1.0.12        tibble_3.2.1       tidyselect_1.2.1   rstudioapi_0.16.0 
[49] compiler_4.4.0    

[rafapereirabr]

What is the period of reference of your GTFS when you look inside the calendar.txt file ?

[toreueland]

Hi, thanks for the very quick reply. Most routes seem to have a start date from around the middle of may 2024 to december 2024 for the data I have downloaded. I have tried many alternative departure dates, and times, but to no avail.

[toreueland]

I extracted the public transit net to have a look at it. Here, I only have the Kolumbus net imported.

transit_net <- r5r::transit_network_to_sf(r5r_core)

I only see one route opening the transit_net under "Data" in R Studio.

Meanwhile for the POA data there are many other routes:

Not sure what the issue is here.

[rafapereirabr]

This looks like an issue with your GTFS data. I'd recommend using the gtfstools package to check the feed. https://ipeagit.github.io/gtfstools/articles/validating.html

[toreueland]

I've run the valdidator and I do get some warnings. Not sure what to make of all of these, so I have listed some here:

Probably due to extended route types.

I have tried the same gtfs data on gtfsrouter and Network Analyst for ArcGIS Pro and it seems to work fine.

[rafapereirabr]

Humm. Interesting. Does your Kolumbus GTFS use extended route types?

[toreueland]

Yes, I tried editing them to be "normal route types" but it didn't seem to fix the issue.

A solution I found was to use "processed" datasets from gtfs.pro. This works fine, but I don't really know what the issue is.

[rafapereirabr]

Hmmm. I don't really know either. But apparently it's an issue with the GTFS feed and not with r5r.

[tafflin]

Yes, I tried editing them to be "normal route types" but it didn't seem to fix the issue.

A solution I found was to use "processed" datasets from gtfs.pro. This works fine, but I don't really know what the issue is.

Hi, thanks for using gtfs.pro. I am responsible for cleaning and data correction at gtfs.pro. What we do here is fix extended route types that are not compliant with the GTFS reference. In this case, these two route types were assigned route_type=4:
1004,Local Car Ferry Service
1014,Passenger High-Speed Ferry Service

You can find that these route types were mentioned once in google groups discussions but were not included in the extended route types list.

[marsatyar]

@toreueland, did you manage to solve the issue? I encounter the same problem while working on GTFS data for Germany from DELFI.

[rafapereirabr]

@marsatyar , what kind of route types exist in your GTFS feed ?

[toreueland]

@marsatyar I used gtfs datasets from gtfs.pro, which worked fine. Seems like it's now called busmaps.com.

[rafapereirabr]

how about you, @marsatyar ? What kind of route types exist in your GTFS feed ?

[marsatyar]

It consists of various transit modes operating throughout Germany, including bus, rail, including local metro, commuter, regional, and long-distance services, as well as tram and ferry services.

But in my case, I am focusing on finding the travel time matrices specifically for commuter rail service, neglecting the multimodal aspect of the algorithm. Hence, instead of running based on the timetable from my GTFS feed, it uses the walking speed, resulting in an unrealistic travel time. I needed help figuring out what the culprit was here. Is it an overshooting using R5 for the abovementioned case?

[rafapereirabr]

@marsatyar , if you're only interested in travel times by commuter rail services, the simplest solution that comes to mind would be to edit the GTFS feed to remove all other modes. Then , running r5r::travel_time_matrix( mode = "transit") would do the trick.

[marsatyar]

@rafapereirabr I tried to edit the GTFS feed, but it chose the walking route again instead. How about the road network (.pbf)? Should I also replace it with only the railway network?

[rafapereirabr]

You don't need to edit the OSM data. This could be happening because of the date you used in the departure time and the dates included in the GTFS. Please have a look at this questions in our FAQ.