Introduction to gtfsio

The General Transit Feed Specification (GTFS) data format defines a common scheme for describing transit systems, and is widely used by transit agencies around the world and consumed by many software applications. Thus, many R packages have been developed to read, write, manipulate and analyse such feeds, such as {gtfs2gps}, {gtfsrouter}, {gtfstools} and {tidytransit}.

Each one of these, however, represent GTFS feeds in a slightly different way, making the interoperability between packages harder to accomplish. At the end of the day, this lack of integration results in a more painful experience to the final user who may want to enjoy functions from different packages.

gtfsio offers tools for the development of GTFS-related packages that aim to increase such interoperability. It establishes a standard for representing GTFS feeds using R data types based on Google’s Static GTFS Reference. It provides fast and flexible functions to read and write GTFS feeds while sticking to this standard. It defines a basic gtfs class which is meant to be extended by packages that depend on it. And it also offers utility functions that support checking the structure of GTFS objects.

This vignette describes the basic usage of gtfsio. Please read get_gtfs_standards() documentation for more detail on the standards for reading and writing GTFS feeds using R data types.

Installation

Before using gtfsio please make sure that you have it installed in your computer. You can download either the most stable version from CRAN or the development version from GitHub:

# stable version
install.packages("gtfsio")

# development version
remotes::install_github("r-transit/gtfsio")

Then attach it to the current R session:

library(gtfsio)

Throughout this demonstration we will be using a few sample files included in the package:

data_dir <- system.file("extdata", package = "gtfsio")
list.files(data_dir)
#> [1] "bad_gtfs.zip"    "ggl_gtfs.zip"    "nested_gtfs.zip"

Basic usage

Reading feeds

To read a feed use the import_gtfs() function. It takes either a local path or an URL to a GTFS .zip file and returns a GTFS object (which is, basically, a list of data frames):

The function reads, by default, all .txt files contained in the .zip file. Alternatively, you can specify which files should be read with the files argument (note: without the .txt extension):

Similarly, you can use the fields argument to read only a few selective fields of a file. These arguments can be combined, offering a great deal of flexibility that can translate into very fast reading times.

These fields are parsed according to the standards for reading and writing GTFS feeds in R. Undocumented files and fields (i.e. not specified in the GTFS reference) are read as character, by default. You can overrule this default with extra_spec (note that only undocumented fields should be specified in this argument). ggl_gtfs.zip contains an undocumented field in the levels.txt file, named elevation. Let’s check the effect of extra_spec:

Writing feeds

Use export_gtfs() to write a GTFS object to disk. Please note that the function assumes that the object is formatted according to the standards for reading and writing GTFS feeds in R - i.e. if it’s not, any conversions should be done before using export_gtfs().

Objects are written as .zip feeds by default, but you can also write them as directories using the as_dir argument:

The function defaults to writing every element inside a GTFS object as a .txt file. As with import_gtfs(), use the files argument to overrule this behaviour:

You can also use the standard_only argument to export only files and fields specified in the GTFS reference (i.e. to leave out undocumented files/fields). In the example below, extra_gtfs contains both an undocumented file (extra_file) and an undocumented field in a regular file (levels$elevation) that are not written to disk when using export_gtfs():

Checking GTFS objects

gtfsio also includes functions to check the structure of GTFS objects. check_file_exists() checks the existence of elements representing specific text files inside an object. It returns TRUE if the check is successful, and FALSE otherwise. assert_file_exists() invisibly returns the object if successful, and throws an error otherwise:

check_field_exists() checks the existence of fields, represented by columns, inside GTFS objects. It returns TRUE if the check is successful, and FALSE otherwise. assert_field_exists() invisibly returns the object if successful, and throws an error otherwise:

check_field_class() checks the classes of fields inside GTFS objects. It returns TRUE if the check is successful, and FALSE otherwise. assert_field_class() invisibly returns the object if successful, and throws an error otherwise:

Please notes that “lower-level” checks are conducted inside each function - e.g. before checking the type of a field, first the existence of such field is checked:

These functions are great for package interoperability. If two distinct packages represent GTFS text files using the same data structure (both {gtfstools} and {gtfsrouter} use data.tables, for example), they just need to add some basic checks before proceeding with operations on objects created by the other package.

So, if {gtfsrouter} requires the transfers element to perform some operations, it might as well perform them on an object created by {gtfstools}, as long as it contains a transfers element. Thus, it could greatly benefit of some assert_*/check_* calls before proceeding with such operations.