You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. I've noticed that read_gtfs() fills missing arrival/departure_time (spec compliant) with 00:00:00. Take the following Google's example feed (https://developers.google.com/transit/gtfs/examples/gtfs-feed), which is included in gtfstools for testing purposes:
The issue persists when saving the GTFS object to disk with tidytransit::write_gtfs(), in which case the 00'00" entries are saved as 00:00:00. MobilityData's GTFS Validator considers this an error, as we can see from the code below (you'll need to use the dev version of gtfstools for that1 [if running the code interactively, the function will open a validation report in HTML format, but I'll include the error in the snippet below anyway]):
I don't know how to handle this case with {hms}, but I'd say that representing missing dates with NA seems to be the best strategy. gtfstools represents dates as strings, so missing dates are represented as "", but I'm not sure if something like that is possible with hms objects.
Footnotes
Testing if validator_gtfs() worked with tidygtfs objects was exactly how I found this behavior :) ↩
The text was updated successfully, but these errors were encountered:
This is indeed unexpected behavior and I think tidytransit did use NA for missing times at some point in the past... Apparently that's not the case anymore so time to fix it :)
Hi. I've noticed that
read_gtfs()
fills missing arrival/departure_time (spec compliant) with 00:00:00. Take the following Google's example feed (https://developers.google.com/transit/gtfs/examples/gtfs-feed), which is included in gtfstools for testing purposes:The issue persists when saving the GTFS object to disk with
tidytransit::write_gtfs()
, in which case the 00'00" entries are saved as 00:00:00. MobilityData's GTFS Validator considers this an error, as we can see from the code below (you'll need to use the dev version of gtfstools for that1 [if running the code interactively, the function will open a validation report in HTML format, but I'll include the error in the snippet below anyway]):I don't know how to handle this case with
{hms}
, but I'd say that representing missing dates withNA
seems to be the best strategy. gtfstools represents dates as strings, so missing dates are represented as""
, but I'm not sure if something like that is possible withhms
objects.Footnotes
Testing if
validator_gtfs()
worked withtidygtfs
objects was exactly how I found this behavior :) ↩The text was updated successfully, but these errors were encountered: