UrbanAnalyst/gtfsrouter

Bug in traveltimes algorithm

mpadge opened this issue · 1 comments

This demonstrates how an increment in the start time window of only 3 minutes yields faster travel times calculated over a full window of one hour:

library (gtfsrouter)
packageVersion ("gtfsrouter")
#> [1] '0.0.5.146'
g <- "/<loca>/<path>/<to>/mannheim-gtfs.zip"
gtfs <- extract_gtfs (g)
#> ▶ Unzipping GTFS archive✔ Unzipped GTFS archive
#> Warning: This feed contains no transfers.txt 
#>   A transfers.txt table may be constructed with the 'gtfs_transfer_table' function
#> ▶ Extracting GTFS feed✔ Extracted GTFS feed 
#> ▶ Converting stop times to seconds✔ Converted stop times to seconds
gtfs <- gtfs_transfer_table (gtfs)
start_time_limits <- 8:9 * 3600
day <- "mo"
s <- "112211"
start_stn <- which (gtfs$stops$stop_id == s)
t1 <- gtfs_traveltimes (gtfs, from = s, start_time_limits, day, from_is_id = TRUE)

start_time_limits <- start_time_limits + 181
t2 <- gtfs_traveltimes (gtfs, from = s, start_time_limits + 181, day, from_is_id = TRUE)

ids <- unique (c (t1$stop_id, t2$stop_id))
res <- data.frame (id = ids, s1 = NA, t1 = NA, s2 = NA, t2 = NA)
res$s1 [match (t1$stop_id, ids)] <- t1$start_time
res$t1 [match (t1$stop_id, ids)] <- t1$duration
res$s2 [match (t2$stop_id, ids)] <- t2$start_time
res$t2 [match (t2$stop_id, ids)] <- t2$duration

index <- which (res$t2 < res$t1)
table (res$t2 [index] - res$t1 [index])
#> 
#> -600 -240 -120  -90  -60 
#>    3  158    1    1    4
table (res$s2 [index])
#> 
#> 29220 29760 
#>   161     6

Created on 2023-04-06 with reprex v2.0.2

Those faster connections all leave within the original start_time_limits window, and so should have been picked up on the first call.

This is actually not a bug at all, but happens because the subsequent faster connections include more transfers. They are not included in the first because they are not minimal-transfer connections there, but excluding that first connection, they then become the fastest and also have more transfers.