Possible Bug : transit_network_to _sf() not generating routes

[ichsan2895]

How to reproduce:

library(r5r)
library(tidytransit)
library(mapview)
library(sf)
library(dplyr)
library(tidyverse)
library(ggplot2)

options(java.parameters = "-Xmx2G")

# First, I validate the GTFS so it has routes shapes in shapes.txt
local_gtfs_path <- "r5rv1-highway-gtfs-bogor/angkots-v2-gtfs.zip"
gtfs <- read_gtfs(local_gtfs_path)
gtfs <- gtfs_as_sf(gtfs)
ggplot() +
  geom_sf(data=gtfs$shapes, aes(color=shape_id)) +
  theme_void()

# I make sure all requirement meets for building GTFS
bogor <- tidytransit::read_gtfs(local_gtfs_path)
validation_result <- attr(bogor, "validation_result")
validation_result %>% dplyr::filter(file_spec=="req" & field_spec =="req")

path <- "r5rv1-highway-gtfs-bogor"
r5r_core <- setup_r5(data_path = path, verbose = FALSE)
transit_network <- transit_network_to_sf(r5r_core)
transit_network

ggplot() +
  geom_sf(data=transit_network$routes, aes(color=mode)) +
  theme_void()

network_settings.json

{"r5_version":"6.7", "r5_network_version":"nv2", "r5r_version":"1.0.0", "creation_date":"2023-02-05T11:03:22.119315", "pbf_file_name":"r5rv1-highway-gtfs-bogor/2023-01-26_highway_Bogor.osm.pbf", "gtfs_1":"/r5rv1-highway-gtfs-bogor/angkots-v2-gtfs.zip", "use_elevation":"false", "elevation_cost_function":"NONE", "tiff_file_name":""}

[ichsan2895]

Here is it the file that has the problem BugSearch_Bogor_GTFS.zip

[rafapereirabr]

Hi @ichsan2895. Thanks for opening this issue and provided the a reproducible example with the data. It seems the GTFS has quite a few problems and I suspect some of these problems might be causing the issue reported.

On a quick inspection, I see for example that the trip AK-01 basically has one single stop, kb-gedong-sawah. I'm not sure this is what is causing the reported problem but it certainly raises a red flag about other problems in the GTFS data.

It seems that {tidytransit}'s validation is not capturing this and other types of errors (heads of @polettif). For a more thorough validation of the GTFS data, I would suggest using gtfstools::validate_gtfs. This function can take a few minutes for large GTFS feeds. Code example below.

library(gtfstools)

local_gtfs_path <- "./r5rv1-highway-gtfs-bogor/angkots-v2-gtfs.zip"

gtfs <- gtfstools::read_gtfs(local_gtfs_path)
head(gtfs$stop_times)

# download validator
gtfstools::download_validator(path = '.')

# validate gtfs
gtfstools::validate_gtfs(gtfs = local_gtfs_path, 
                         validator_path  = 'gtfs-validator-v4.0.0.jar',
                         output_path = './')

See the outpu report in html.

[ichsan2895]

Hello @rafapereirabr , thanks for pointing out the GTFS problem. Yes, the GTFS is not made by me, so I don't know the data quality.

Tidytransit doesn't detect that problem too

But, the gtfs_validator from mobility_data , detect the problem too.

The problem is same as you said, GTFS$stop_times$stop_sequence doesn't properly adjusted

Now, the problem was solved (after I repaired the GTFS$stop_times$stop_sequence) and thank you for helping me

[polettif]

It seems that {tidytransit}'s validation is not capturing this and other types of errors (heads of @polettif). For a more thorough validation of the GTFS data, I would suggest using gtfstools::validate_gtfs. This function can take a few minutes for large GTFS feeds. Code example below.

Yes tidytransit's validator works on a very basic level, it mainly checks if any required files are missing and fields are in the right format. There's no check on internal consistency (e.g. are ids shared across tables or this example of inconsistens stop times). I'll have a look into gtfstools::validate_gtfs though, maybe we should rename tidytransit's function to check_files_and_fields or something like that.