Error using setup_r5()

[ismailsaadi]

Hi,

I downloaded the OSM network for the UK from Geofabrik (.pbf), all the UK bus/tram GTFS timetables (.zip), and the UK inter-city rail GTFS timetables (.zip). All files are in the same folder. No elevation map at this stage. I am using Java 21.0.3 and R 4.4.0. When I run:

r5r_core <- setup_r5(data_path)

the multimodal network (.dat) cannot be built. I get the following error:

Using cached R5 version from /Users/ismailsaadi/Library/Caches/org.R-project.R/R/r5r/r5_jar_v7.1.0/r5-v7.1-all.jar
2024-06-06 11:05:23,266 [main] ERROR c.c.r.s.StreetLayer - Continuing to load but ignoring generalized costs due to exception: java.lang.RuntimeException: All ways are expected to have generalized cost tags. Missing: slope_1:forward

Do you think that some data preprocessing is required?

[stupidpupil]

Are you able to give a bit more detail on r5r's output and your data sources? (I'm not aware of a UK, or rather GB, GTFS dataset for rail for example.)

For context, I use r5r to do analysis on a bit of Britain:
https://github.com/stupidpupil/wales_ish_otp_graph/

(And have built a pretty shoddy R package to help handle some of the pre-processing.)

[ismailsaadi]

Yes. Apologies for the ambiguity. Rail timetable data are downloaded from ATOC as .cif files, which I then convert to GTFS using UK2GTFS. Bus timetables are downloaded from the DfT Bus Open Data Service. Regarding the error (with verbose=TRUE), while processing the GTFS files related to the bus data, it suddenly states:

[...]
2024-06-08 13:07:48,923 [main] DEBUG c.c.r.t.TripPattern - Pattern has route_id itm_all_gtfs:1733 and direction_id 0
2024-06-08 13:07:48,925 [main] DEBUG c.c.r.t.TripPattern - Pattern has route_id itm_all_gtfs:5790 and direction_id 0
2024-06-08 13:07:48,927 [main] DEBUG c.c.r.t.TripPattern - Pattern has route_id itm_all_gtfs:68280 and direction_id 0
2024-06-08 13:07:51,952 [main] DEBUG c.c.r.t.TripPattern - Pattern has route_id itm_all_gtfs:76136 and direction_id 0
2024-06-08 13:07:54,714 [main] DEBUG c.c.r.t.TripPattern - Pattern has route_id itm_all_gtfs:11284 and direction_id 0
2024-06-08 13:07:57,230 [main] DEBUG c.c.r.t.TripPattern - Pattern has route_id itm_all_gtfs:26731 and direction_id 0

Finished building network.dat at GTFS//network.dat
2024-06-08 13:08:18,421 [Finalizer] ERROR c.c.g.GTFSFeed - MapDB database was not closed before it was garbage collected. This is a bug!
juin 08, 2024 1:33:05 PM org.geotools.referencing.factory.DeferredAuthorityFactory disposeBackingStore
INFO: Disposing class org.geotools.referencing.factory.epsg.hsql.ThreadedHsqlEpsgFactory backing store
juin 08, 2024 1:33:06 PM org.hsqldb.persist.Logger logInfoEvent
INFO: Database closed

Note that I cannot find the network.dat file (although it's mentioned). I only see united-kingdom-latest.osm.pbf.mapdb and united-kingdom-latest.osm.pbf.mapdb.p.

[rafapereirabr]

Could you please try building the network without thr GTFS files in the directory?

[dfsnow]

Heads up @rafapereirabr, this seems to be related to the MAX_BOUNDING_BOX_AREA_SQ_KM set within R5. If you try to build a network.dat that has a bbox area larger than the statically set 975000km, then the output of the .dat file will fail silently.

Manually compiling an R5 JAR with this limit increased and providing it to r5r or r5py will resolve this problem. I believe this was likely the cause of #379 as well, as I encountered the same error.

[rafapereirabr]

Hi @dfsnow ! Nice to hear from you , and thanks for the heads up!

At least until recently, R5 (and hence r5r) would throw this error message below in case the bbox area of the input data were larger than the statically set 975000km2. This is documented in our FAQ.

“Geographic extent of street layer (5315196 km2) exceeds limit of 975000 km2”

As far as I understand from R5 code, this limit and error message are still simplemented (see here). So if the problem really were the spatial extent of the data, this woul dhave been the error message. Maybe I'm missing something here.

[dfsnow]

At least until recently, R5 (and hence r5r) would throw this error message below in case the bbox area of the input data were larger than the statically set 975000km2. This is documented in our FAQ.

Hi! Oddly, that error does get thrown in r5py but doesn't get explicitly thrown when using setup_r5(). I'm not sure if they use different code paths in R5 or different versions, but r5r definitely isn't throwing that error.

[rafapereirabr]

I just tested r5r::setup_r5() on the OSM data of Brazil and r5r did not throw the error indeed. Thanks for the heads up. We'll look into this in closer detail

[rafapereirabr]

Issue solved in #426, which now makes sure r5r throws an error when the geographic extent of input data exceeds limit of 975000 km2.