Error with TRANSIT mode: java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException

[Fang822]

I'm experiencing an issue when using the travel_time_matrix() function with TRANSIT as a mode. When my OD dataset contains only WALK or BICYCLE, everything runs fine. However, when there are OD pairs with TRANSIT, I get the following error:

Error in .jcall("RJavaTools", "Ljava/lang/Object;", "invokeMethod", cl, :
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException

I saw some previous issues where you suggested checking for errors in the GTFS dataset. I have already validated and corrected the GTFS data, but the problem persists. Could you help me identify what might be causing this error?

Below is a minimal reproducible example with sample OD data:

https://drive.google.com/drive/folders/1mojWAO-NPVNi8uHqhm6O44eMmw5fL4vM?usp=drive_link

library(r5r)
library(sf)
library(data.table)
library(ggplot2)
library(akima)
library(dplyr)
library(rJava)
library(openxlsx)

options(java.parameters = "-Xmx16G")

data_path <- "Z:/Lahti/roadnetwork"
r5r_core <- setup_r5(data_path, verbose = FALSE)

od_data <- fread("Z:/Lahti/OD/Exampledata.csv")

results <- lapply(1:nrow(od_data), function(i) {

origin <- data.frame(id = as.character(i), lat = od_data$origin_lat[i], lon = od_data$origin_lon[i])
destination <- data.frame(id = as.character(i), lat = od_data$destination_lat[i], lon = od_data$destination_lon[i])
mode <- od_data$mode[i]

origin <- bind_rows(origin)
destination <- bind_rows(destination)

travel_time <- travel_time_matrix(r5r_core = r5r_core,
origins = origin,
destinations = destination,
mode = mode,
departure_datetime = as.POSIXct("2025-03-24 09:00:00"),
max_walk_time = 60,
max_trip_duration = 300)

#print(travel_time)

travel_time$id <- i

return(travel_time)
})

final_results <- rbindlist(results, fill = TRUE)

write.xlsx(final_results,"Z:/Lahti/result/exampleresult.xlsx")

[rafapereirabr]

I cannot download the sample data

[Fang822]

I cannot download the sample data

I am very sorry.
https://drive.google.com/drive/folders/1mojWAO-NPVNi8uHqhm6O44eMmw5fL4vM?usp=sharing
Does this link work?

[mountainMath]

I am getting the same error. Here is my code that fails. (It used to run on oder versions of r5r)

library(tidyverse)
library(sf)
options(java.parameters = "-Xmx8G")
library(r5r)

centre <- tibble(id="centre",lon=-122.75, lat=49.28)
mask <- centre |>
  st_as_sf(coords = c("lon", "lat"), crs = 4326) |>
  st_buffer(60000)

osm_path <- tempdir() # set to something more permanent to avoid having to download it every time
bc_osm_path <- file.path(osm_path,"geofabrik_british-columbia-latest.osm.pbf")
if (!file.exists(bc_osm_path)) {
  options(timeout = "1000")
  download.file("http://download.geofabrik.de/north-america/canada/british-columbia-latest.osm.pbf",bc_osm_path)
}
r5r_path <- tempfile()
dir.create(r5r_path)

#gtfs_url <- "https://transitfeeds.com/p/translink-vancouver/29/latest/download"
gtfs_url <- "https://gtfs-static.translink.ca/gtfs/History/2025-03-28/google_transit.zip"

translink_path <- file.path(r5r_path,"translink_GTFS.zip")
temp_path <- file.path(tempdir(),"translink_GTFS.zip")
download.file(gtfs_url,translink_path)

bc_pbf_path <- file.path(r5r_path,"geofabrik_british-columbia-latest_clipped.osm.pbf")

# cut down on extent of the road network to speed things up
system(paste0("osmconvert ",bc_osm_path," -b=",
              st_bbox(mask) |> round(digits = 4) |> paste0(collapse=","),
              " -o=",bc_pbf_path))

r5r_core <- setup_r5(data_path = r5r_path,overwrite=TRUE)
departure_day <- "2025-03-25"
departure_time <- "08:30:00"
departure_datetime <- as.POSIXct(paste0(departure_day," ",departure_time), format = "%Y-%m-%d %H:%M:%S")

isochrone_30 <- isochrone(r5r_core,
                          origins=centre,
                          mode = c("TRANSIT"),
                          max_walk_time = 20,
                          cutoffs = c(15, 30,45,60),
                          departure_datetime=departure_datetime) |>
  mutate(isochrone=factor(isochrone))

[rafapereirabr]

We have implemented a few changes to {r5r}. Could you please try again using the dev version to see if the issue persists ? To install de dev version, run the code below.

# remove previous version
utils::remove.packages('r5r')

# install dev version with latest features
devtools::install_github("ipeaGIT/r5r", subdir = "r-package")

[mountainMath]

I am still getting the same error message.

Error in .jcall("RJavaTools", "Ljava/lang/Object;", "invokeMethod", cl,  : 
  java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException

Sessioninfo:

R version 4.4.2 (2024-10-31)
Platform: aarch64-apple-darwin20
Running under: macOS Sequoia 15.4

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.12.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Vancouver
tzcode source: internal

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

other attached packages:
 [1] r5r_2.1.099999  sf_1.0-20       lubridate_1.9.4 forcats_1.0.0   stringr_1.5.1   dplyr_1.1.4    
 [7] purrr_1.0.4     readr_2.1.5     tidyr_1.3.1     tibble_3.2.1    ggplot2_3.5.1   tidyverse_2.0.0

loaded via a namespace (and not attached):
 [1] s2_1.1.7                  generics_0.1.3            class_7.3-22              KernSmooth_2.23-24       
 [5] stringi_1.8.4             hms_1.1.3                 magrittr_2.0.3            grid_4.4.2               
 [9] timechange_0.3.0          e1071_1.7-16              backports_1.5.0           DBI_1.2.3                
[13] scales_1.3.0              cli_3.6.4                 rlang_1.1.5               units_0.8-7              
[17] munsell_0.5.1             withr_3.0.2               tools_4.4.2               sfheaders_0.4.4          
[21] tzdb_0.4.0                checkmate_2.3.2           colorspace_2.1-1          vctrs_0.6.5              
[25] R6_2.6.1                  proxy_0.4-27              lifecycle_1.0.4           classInt_0.4-11          
[29] pkgconfig_2.0.3           rJava_1.0-11              pillar_1.10.2             gtable_0.3.6             
[33] glue_1.8.0                data.table_1.17.0         Rcpp_1.0.14               xfun_0.50                
[37] tidyselect_1.2.1          rstudioapi_0.16.0         knitr_1.48                mountainmathHelpers_0.1.4
[41] wk_0.9.4                  compiler_4.4.2 

[rafapereirabr]

@mountainMath , your problem seems to be caused by an issue of using osmconvert to crop the OSM data. See this comment and this issue upstream in R5. Alternatives here would to crop the OSM data using another tool, like Osmosis or Osmium (there is the R package rosmium). Have you tried any of these other tools ?

[rafapereirabr]

Update for @mountainMath . I've downloaded the OSM for Vancouver using the code below, and managed to create the network and calculate isochrones for car and for walking. I only get the error when I try to run the isochrone() function for the mode "transit", which raises the suspicion that the error is being caused by the GTFS data.

Looking at the log of building the network (see the file r5rlog_yyyymmdd.log in the data path, I've found these two messages that suggest the error is indeed in the GTFS feed.

00:24:04.488 [main] WARN com.conveyal.gtfs.GTFSFeed - Feed contains high priority errors, not finding patterns. It will be useless for routing.
00:24:04.488 [main] INFO com.conveyal.gtfs.GTFSFeed - Detected 13776 errors in feed.

I don't know what could be causing these "high priority errors", but R5 is clear here that these error compromise routing. On the r5r side, what we can do is probably to use a trycatch to detect this error and throw a more informative error messsage. Ideally, though, I think this deserves to be investigated upstream with R5 to see what characteristics of the GTFS are causing this.

Ping to @BardyBard to let you know about this.

code to download Vancouver OSM

library(osmextract)

vancouver_osm_info <- oe_match("Vancouver", provider = "geofabrik")

oe_download(
  file_url = vancouver_osm_info$url, 
  file_size = vancouver_osm_info$file_size,
  provider = "geofabrik",
  download_directory = "."
)

reprex

options(java.parameters = "-Xmx8G")
library(tidyverse)
library(sf)
library(r5r)

library(osmextract)

vancouver_osm_info <- oe_match("Vancouver", provider = "geofabrik")

oe_download(
  file_url = vancouver_osm_info$url,
  file_size = vancouver_osm_info$file_size,
  provider = "geofabrik",
  download_directory = "."
)


centre <- tibble(id="centre",lon=-122.75, lat=49.28)

r5r_core <- setup_r5(data_path = ".", overwrite=T, verbose = T)
departure_day <- "2025-03-25"
departure_time <- "08:30:00"
departure_datetime <- as.POSIXct(paste0(departure_day," ",departure_time),
                                 format = "%Y-%m-%d %H:%M:%S")

isochrone_30 <- isochrone(r5r_core,
                          origins=centre,
                          mode = c("car"),
                          max_walk_time = 20,
                          cutoffs = c(30,45,60),progress = T,
                          departure_datetime=departure_datetime) |>
  mutate(isochrone=factor(isochrone))

plot(isochrone_30)

[Fang822]

We have implemented a few changes to {r5r}. Could you please try again using the dev version to see if the issue persists ? To install de dev version, run the code below.

# remove previous version
utils::remove.packages('r5r')

# install dev version with latest features
devtools::install_github("ipeaGIT/r5r", subdir = "r-package")

Hi, I tried again and still getting the error Error in .jcall("RJavaTools", "Ljava/lang/Object;", "invokeMethod", cl, :
java.util.concurrent.ExecutionException: java.lang.ArrayIndexOutOfBoundsException

This is the session info:

r5r::r5r_sitrep()
$r5r_package_version
[1] ‘2.1.99999’

$r5_jar_version
[1] "7.3"

$java_version
[1] "21.0.6"

$set_memory
[1] "-Xmx8G"

$session_info
R version 4.4.3 Patched (2025-02-28 r87868 ucrt)
Platform: x86_64-w64-mingw32/x64
Running under: Windows 10 x64 (build 19045)

Matrix products: default

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

time zone: Europe/Helsinki
tzcode source: internal

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

other attached packages:
[1] dplyr_1.1.4 akima_0.6-3.4 ggplot2_3.5.1 data.table_1.17.0
[5] sf_1.0-20 r5r_2.1.099999 rJava_1.0-11

loaded via a namespace (and not attached):
[1] generics_0.1.3 class_7.3-23 KernSmooth_2.23-26
[4] lattice_0.22-6 digest_0.6.37 magrittr_2.0.3
[7] grid_4.4.3 pkgload_1.4.0 fastmap_1.2.0
[10] processx_3.8.6 pkgbuild_1.4.6 sessioninfo_1.2.3
[13] backports_1.5.0 e1071_1.7-16 DBI_1.2.3
[16] urlchecker_1.0.1 ps_1.9.0 promises_1.3.2
[19] purrr_1.0.4 scales_1.3.0 cli_3.6.4
[22] shiny_1.10.0 rlang_1.1.5 units_0.8-7
[25] munsell_0.5.1 ellipsis_0.3.2 withr_3.0.2
[28] remotes_2.5.0 cachem_1.1.0 devtools_2.4.5
[31] tools_4.4.3 checkmate_2.3.2 memoise_2.0.1
[34] colorspace_2.1-1 httpuv_1.6.15 curl_6.2.2
[37] vctrs_0.6.5 R6_2.6.1 mime_0.12
[40] proxy_0.4-27 lifecycle_1.0.4 classInt_0.4-11
[43] fs_1.6.5 htmlwidgets_1.6.4 usethis_3.1.0
[46] miniUI_0.1.1.1 pkgconfig_2.0.3 desc_1.4.3
[49] callr_3.7.6 pillar_1.10.2 later_1.4.1
[52] gtable_0.3.6 glue_1.8.0 profvis_0.4.0
[55] Rcpp_1.0.14 tidyselect_1.2.1 tibble_3.2.1
[58] rstudioapi_0.17.1 xtable_1.8-4 htmltools_0.5.8.1
[61] compiler_4.4.3 sp_2.2-0

[mountainMath]

Thanks for looking into this and clearing things up @rafapereirabr, the issue that has come up for me was with transit only. (Although there are lots of warning messages about turn restrictions and other OSM issues.)

I just tried to re-run this with old TransLink GTFS data that I used to be able to run this on, and with the update that old code now runs through again, it failed with the previous version of the package. So that's a clear improvement. (Archived GTFS feed at "https://transitfeeds.com/p/translink-vancouver/29/20230901/download") Unfortunately the current GTFS feed does not run through, I am not sure what the difference is, both seem equally buggy when putting them through a feed validator.

I'll talk to TansLink folks to try and figure out if anything changed on their end that might explain this. In the meantime, do you know of a tool that one could use to clean up GTFS feeds?

[rafapereirabr]

to clean up GTFS feeds, I would {gtfstools}, which comes with a convient function to run the validator.

[rafapereirabr]

@Fang822 , could you please try running the anaysis only using walking as a transport mode ?

[mountainMath]

Thanks @rafapereirabr, I have used gtfstools for running the validator and other tasks, but I am not sure how to use it to clean up GTFS feeds. I have tried simply reading and writing a feed, and reading, calling the remove_duplicates() function and writing on the new Translink feed that causes r5r to crash, but none of that resolved the issues.

[Fang822]

@Fang822 , could you please try running the anaysis only using walking as a transport mode ?

Thanks for your attention. The analysis only using walking and cycling is fine, but with Transit mode, that will cause an error. I tried to clean the GTFS data, but I don't think it is the reason why the transit mode doesn't work, because the stop URL is optional in GTFS data.

[lgarcia2422]

@rafapereirabr
Hello, are there any updates to this issue. I have been having trouble getting r5r to even create a network.dat when GTFS data is included - similar to the issue described above, it is able to create the network.dat when it's just using an osm.pbf or osm.pbf + tiff. Please let me know if there is any news on this issue. Thanks!

[rafapereirabr]

Hi @lgarcia2422 . This issue seems to be cause by problems in the GTFS feed, not in R5 or r5r. As mentioned above, I recommend using the {gtfstools} to diagnose what that error could be. In the new version of r5r, running the function setup_r5() will also save the R5 log to the data path to help finding eventual errors. You can test this by installing the dev version for now, but we hope to get a new version on CRAN in the next few days.