gtfs2nx

gtfs2nx is a small, MIT-licensed Python library from the ai4up organization on GitHub that converts public-transit schedule data in the General Transit Feed Specification (GTFS) into a routable NetworkX directed graph. Its purpose is narrow and well-defined: turn a GTFS feed (typically a ZIP of standardized CSV tables such as stops, trips, stoptimes and routes) into a graph object that can be analyzed with the standard NetworkX toolkit, without the analyst having to reconstruct network topology and travel costs from the raw tables by hand. Installation is a single pip install, and the core call is `gtfs2nx.transitgraph('feed.zip')`, which returns the graph directly.

The distinguishing design choice is how it models the network for realistic routing. Rather than treating every stop as a shared node, gtfs2nx splits stops so that each node belongs to a single route, then reconnects routes through synthesized walking-transfer edges. Transfer cost is computed as walking time plus half the average headway (headway/2), approximating the expected wait a passenger incurs when changing lines. During construction it cleans the feed by dropping trips with unrealistic speeds or travel times and repairing contradictory stop sequences and departure times, and it precomputes node and edge attributes: per-stop service frequency, average segment travel times, and edge weight values in minutes. The transit_graph() function exposes parameters to restrict a time_window (e.g. the morning peak), filter route_types (for example buses only), and cap walk_transfer_max_distance in meters.

Because the output is a plain NetworkX graph, the weighted edges plug straight into Dijkstra shortest paths, travel-time isochrones, and centrality measures, which makes gtfs2nx suited to transit accessibility studies, network-structure comparison, and machine-learning pipelines (the ai4up context includes using such graphs to validate or infer missing GTFS data). It occupies the same niche as tools like peartree, gtfs2graph and City2Graph, differing mainly in its emphasis on realistic transfer times rather than raw schedule expansion.

Its limitations follow from its scope. The frequency/head-half model yields a static, average-case graph rather than a fully time-expanded timetable, so it does not capture exact departure-time chains the way schedule-based routers do. It has no built-in street network and relies on straight-line walking transfers within a distance threshold, and as a modestly maintained research-oriented project its documentation is limited to a README, an API page and a getting-started notebook.