UrbanAnalyst / gtfsrouter

Routing and analysis engine for GTFS (General Transit Feed Specification) data
https://urbananalyst.github.io/gtfsrouter/
80 stars 17 forks source link

rcpp_csa | Not compatible with requested type #108

Closed pteridin closed 1 year ago

pteridin commented 1 year ago

Issue

The following code leads to an error when calling gtfs_route.

Error in rcpp_csa(gtfs$timetable, gtfs$transfers, nrow(gtfs$stop_ids),  : 
  Not compatible with requested type: [type=character; target=double].

Code

library(gtfsrouter)

download.file("https://download.gtfs.de/germany/fv_free/latest.zip",
              "IC_ICE_de_zip")
gtfs <- gtfsrouter::extract_gtfs("IC_ICE_de_zip")
gtfs <- gtfsrouter::gtfs_timetable(gtfs,
                                   date = "20230703")

gtfs$transfers <- NULL # optional, not included in file
gtfs <- gtfs_transfer_table (gtfs)

gtfs_route (gtfs,
            from = "Solingen Hbf",
            to = "Leipzig Hbf")

Version

gtfsrouter_0.0.5.163
mpadge commented 1 year ago

Yep, I can confirm the behaviour for me. Interesting, because I'm using the full germany feed very regularly at present, and that works just fine, so there's obviously some difference between the full feed and the IC-ICE one. I'll investigate and get back to you.

pteridin commented 1 year ago

That was a quick fix :)

Thank you!

mpadge commented 1 year ago

Turned out to be just an effect of first calling gtfs_timetable, and then calling gtfs_transfer_table. The above commit now raises an error when attempting that sequence, and tells you to call those two in the other order:

library (gtfsrouter)
packageVersion ("gtfsrouter")
#> [1] '0.0.5.164'
f <- "IC_ICE_de_zip"
if (!file.exists (f))
    download.file("https://download.gtfs.de/germany/fv_free/latest.zip", f)
gtfs <- extract_gtfs(f)
#> ▶ 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_timetable(gtfs, date = "20230703")
gtfs <- gtfs_transfer_table (gtfs)
#> Error: The 'gtfs_transfer_table' function must be called 
#> BEFORE the 'gtfs_timetable' function. Please re-load the
#> feed, directly call this function, and then call 'gtfs_timetable'.

gtfs <- extract_gtfs(f)
#> ▶ 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)
gtfs <- gtfs_timetable(gtfs, date = "20230703")
gtfs_route (gtfs,
            from = "Solingen Hbf",
            to = "Leipzig Hbf")
#>   route_name                     stop_name arrival_time departure_time
#> 1      IC 39                  Solingen Hbf     21:07:00       21:09:00
#> 2     ICE 42     Köln Messe/Deutz Gl.11-12     21:57:00       21:59:00
#> 3     ICE 42                 Siegburg/Bonn     22:10:00       22:11:00
#> 4      IC 39 Frankfurt(M) Flughafen Fernbf     23:59:00       24:01:00
#> 5      IC 39            Frankfurt(Main)Hbf     24:13:00       24:13:00
#> 6      EC 12            Frankfurt(Main)Hbf     24:27:00       24:52:00
#> 7      EC 12                         Fulda     25:48:00       25:50:00
#> 8      EC 12                    Erfurt Hbf     27:14:00       27:16:00
#> 9      EC 12                   Leipzig Hbf     28:48:00       29:53:00

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

(And note that you don't have to set gtfs$transfers <- NULL before constructing a transfer table, and in fact you should not do that, because calling that function will extend any existing tables while respecting any values provided. This is important because even network times can only be calculated horizontally, but stated times may reflect deeply vertical underground stations networks and may be much higher. Those kinds of times are then retained in the table, and new values inserted only where they did not previously exist.)

(And that crappy route is just because the algorithm defaults to Sys.time - specifying a realistic start time like 9 * 3600 gives results more like you'd expect.)