Feed features
Suggestions
Counts come from tt.features(); advisory pointers
from tt.suggestions(). Routing is not altered.
Load a different GTFS feed
Browsers block remote fetches unless the publisher sends
Access-Control-Allow-Origin. The
Mobility Database
CDN at files.mobilitydatabase.org mirrors over
6,000 GTFS feeds worldwide and serves them with permissive
CORS: every URL on a feed's
/feeds/gtfs/mdb-… page should work here.
transport.data.gouv.fr
and GitHub-raw URLs are similarly CORS-friendly.
Direct transit-authority URLs (BART, TfL, etc.) usually
aren't; paste them here to find out, but expect a network
error in most cases.
© OpenStreetMap contributors · © Carto
Stop-to-stop
A simple query: pick two stations, set a departure time, get the Pareto front of (transfers, arrival) journeys. Each row is one journey; vulture returns one per trip count between zero and the cap.
Departure window
"I want to leave between X and Y: what are my options?" rRAPTOR scans every departure in a window in a single reverse-chronological pass and Pareto-filters on (later depart, fewer transfers, earlier arrival): entries that are strictly worse than another departure are dropped. The output is the useful subset of choices for that window.
Walking footpaths
Many GTFS feeds ship a sparse or empty transfers.txt, so out of the
box no walking transfers exist between physical stops. Vulture's
with_walking_footpaths(max_distance_m, walking_speed) uses an R*-tree
over an equirectangular projection of stop coordinates to add bidirectional
walking edges between every pair of stops within reach, and the cap is
enforced per leg: the resulting graph is marked transitively closed so
the routing runtime takes one walk per round and won't quietly stitch
short hops into a kilometres-long chain. Toggle it below to see how routing
changes: for Delhi Metro most stops are line-internal so the difference is
small, but the mechanic is the same on any feed.