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.