travel_time_matrix error: java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException. GTFS or r5r issue?

[hugocbustamante]

Brief description of the problem:

Hello there! I've tried to calculate travel time matrix for Transit mode using GTFS data of The Netherlands and I get the following error:

Error in .jcall("RJavaTools", "Ljava/lang/Object;", "invokeMethod", cl, :
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException
In addition: Warning messages:
1: In assign_points_input(origins, "origins") :
'origins$id' forcefully cast to character.
2: In assign_points_input(destinations, "destinations") :
'destinations$id' forcefully cast to character.

I've read other similar issues here and they seem to mostly relate to GTFS problems. However, I was able to calculate the travel time matrix with r5r version "1.1.0" and java jdk-11. Thus, I'm wondering if my problem is really in the GTFS side. I tried multiple GTFS files from NL but none of them seem to work with the latest r5r version.

Data files:
The files I used are too large to attach, but you can find them in:

• GTFS: https://transitfeeds.com/p/ov/814/20230305
• osm: netherlands-230101.osm.pbf

Thanks in advance for the help.

Reproducible example here

library(r5r)
options(java.parameters = '-Xmx16G')

library(bit64)
library(tibble)

r5r_core <- setup_r5(data_path = path, verbose = FALSE, overwrite = TRUE)

All_Existing_Nodes <- tibble(
  id = as.integer64(c(1, 2, 3, 4, 5)),   # Integer64 column
  lon = c(3.848480, 3.850004, 3.854776, 4.093418, 4.091302),   # Numeric longitude values
  lat = c(51.75870, 51.76108, 51.75399, 51.75992, 51.79841)   # Numeric latitude values
)

transit_travel_matrix_2023<-travel_time_matrix(
  r5r_core = r5r_core,
  origins = All_Existing_Nodes,
  destinations = All_Existing_Nodes,
  mode = "TRANSIT",
  mode_egress = "WALK",
  departure_datetime = as.POSIXct("28-03-2023 08:00:00", format = "%d-%m-%Y %H:%M:%S"),
  time_window = 30L,
  percentiles = c(1L,20L,50L,80L),  
  max_trip_duration = 60L,
  walk_speed = 3.6,
  max_rides = 3,
  n_threads = Inf,
  verbose = F,
  progress = T,
  output_dir = NULL
)

Situation report here

$r5r_package_version
[1] ‘2.0’

$r5_jar_version
[1] "7.1"

$java_version
[1] "21.0.4"

$set_memory
[1] "-Xmx16G"

$session_info
R version 4.3.3 (2024-02-29 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19045)

Matrix products: default


locale:
[1] LC_COLLATE=English_United States.utf8  LC_CTYPE=English_United States.utf8   
[3] LC_MONETARY=English_United States.utf8 LC_NUMERIC=C                          
[5] LC_TIME=English_United States.utf8    

time zone: Europe/Amsterdam
tzcode source: internal

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

other attached packages:
[1] rJava_1.0-11    RPostgres_1.4.6

loaded via a namespace (and not attached):
 [1] lubridate_1.9.3   bit_4.0.5         blob_1.2.4        r5r_2.0           pkgconfig_2.0.3   timechange_0.3.0 
 [7] generics_0.1.3    bit64_4.0.5       lifecycle_1.0.4   cli_3.6.2         vctrs_0.6.5       DBI_1.2.3        
[13] data.table_1.15.4 compiler_4.3.3    rstudioapi_0.16.0 tools_4.3.3       hms_1.1.3         rlang_1.1.3   

[rafapereirabr]

Thanks @hugocbustamante for opening this issue. I was able to reproduce the error. The code works fine when calcuating a travel time matrix for "WALK" mode, but it throws that error with "TRANSIT".

When you say you were able to calcuate a travel time matrix for "TRANSIT" using r5r version "1.1.0", were you using this exact same GTFS data ?

[hugocbustamante]

Hi @rafapereirabr, thanks for your quick reply. Yes, I was able to calculate it with the exact same GTFS data.

[rafapereirabr]

Hmm. That's strange. We'll have to look into this, but we need someone who knows Java because the source of the problem would probably be in the Java side of r5r. @hugocbustamante , would you have any experience with Java?

[hugocbustamante]

Unfortunately not, @rafapereirabr :(

[robrik87]

I have the same issue but with GTFS-data from Sweden.

[rafapereirabr]

Have you tried diagonosing the quality of your GTFS feeds ? If not, I would strongly recommend to do so using the {gtfstools} package. You can install the dev version directly from Github while we're working to put it back on CRAN

[erik-toi]

I have a similar issue with data from Norway. I have tried validating the GTFS and find several errors. Do you have any tips on how to fix GTFS feeds?

[robrik87]

I have a similar issue with data from Norway. I have tried validating the GTFS and find several errors. Do you have any tips on how to fix GTFS feeds?

@erik-toi @rafapereirabr

I found a solution that works! On the website busmaps.com, there are GTFS files that have been improved in terms of codes and structure. When I used their GTFS file for Sweden, the program ran successfully, with the exception that I needed to change route_type 1501 to 3.

Unfortunately, I don't know exactly what it is in their file that makes it work. I tried to compare it with my original file (which originally comes from the same source), but I can't quite figure out what the difference is. If anyone can help identify the exact problem, I'd be very grateful.

Anyway, busmaps.com's GTFS files work as a solution, and I'm very thankful that they provide them openly. However, I'd still like to understand what the underlying problem is.

[rafapereirabr]

Hi all. There could be different things happening here.

• Possible cause: GTFS quality: Some cases might result from GTFS with poor quality an internal inconsistencies.

  • suggestion: if you want to investigate whether this is your case, I suggest using the Canonical GTFS Schedule Validator. You can use this tool directly on the link, or use it via the {gtfstools} pacakge in R. See this vignette. The package is currently out of CRAN and going through maintenance, but you can use the dev version from github

• Possible cause: extented route types: There is a posibility that R5 cannot deal with some particular extented route types

  • I don't think this is the case because, according to this, the Conveyal team has already accounted for R5 extented route types (e.g. route_type 1501) a long time ago.

• Possible cause: the latest version of R5 being more strict with GTFS quality

  • I don't know if this is the case.

A temporary fix, and which allows you to test if this possible cause is plausible, is to use the previous version of {r5r}. The code below install the previous version of r5r v1.1.0, which was built on top of R5 v6.9.0 Please note that this older version depended on Java 11.

# install java 11
rJavaEnv::java_quick_install(version = 11)

# install previous version of r5r that 
remotes::install_version("r5r", version = "1.1.0")

If all you could, please try running your analyses with the previous version of r5r and let us know if it works.

[erik-toi]

Thanks a lot for your tips. I tried the third alternative, installing the previous version of r5r, and it works. I was able to calculate transit trips with the same gtfs file.