Transit URL Scheme
If you're a iOS Developer, you can use our URL scheme to make your app launch Transit and show nearby routes or get directions for a particular location.
|description||get transit directions between 2 locations|
|parameters||from: latitude-longitude pair or location string of origin|
to: latitude-longitude pair or location string of destination
|notes||Leaving out a parameter will use the user's current location.|
User's current location is taken into account when geocoding address strings.
Query strings are only supported in Transit 2.0+
|Show Nearby Routes|
|description||show nearby transit routes for a location|
|parameters||q: latitude-longitude pair or location string to fetch nearby routes for (Transit 2.0+)|
ll: latitude-longitude pair (deprecated, use q parameter instead)
Open Transit Data Guidelines
Transit uses the GTFS open transit data format. Although it is a standardized, well accepted format, we have observed common pitfalls in the respect of the Specification Reference. If you're working at a transit agency and are in some way connected to the publishing of their open data, here are a couple things you can do to help transit app developers like ourselves:
- Use, and follow the General Transit Feed Specification Reference. Common pitalls include:
- calendars.txt: Calendar dates should only be used for days where the services changes from the regular service (e.g. holidays). Don't use a calendar_dates entry for every single day of service.
- trips.txt: Provide a clean, concise trip_headsign that is going to be helpful to your riders. How do your riders mainly identify the different possible directions? (e.g.: terminus name, cardinal points, outbound/inbound, etc.). Including the route name in this field is redundant and unnecessary.
- trips.txt: If your agency has bi-directional routes (inbound/outbound, westbound/eastbound, etc), set the direction_id field. If you have more than 2 itineraries, it's the only way for us (and riders!) to know which head in the same direction.
- trips.txt: A trip entry should represent the course of a vehicle from point A to point B, not from point A to point B and back to point A. If the vehicle's trip headsign changes over the course of its trip, maybe that's a sign that the trip should be split into 2 separate trips.
- stop_times.txt: Only set the stop_headsign if the headsign changes over the course of a trip. If the headsign remains the same throughout the trip, you should instead use the trip_headsign column in trips.txt.
- Provide real-time schedules:
- Don't waste time and energy reinventing the wheel. NextBus and GTFS-realtime both already offer ways to provide developers with real-time schedule updates, service alerts, and vehicle positions.
- Use consistent values between your real-time and static data sets. For example, your real-time service should return stop names and coordinates (and ideally identifiers) matching the ones in the GTFS feed. This allows developers to use the static data (for itinerary paths, for instance) in combination with the real-time schedules.
- If you're out to design your own real-time API, remember that it will receive a good load of traffic. Keep your response small, only containing the information that is requested. Prioritize JSON over XML. Make it RESTful. Allow developers to register for an API key so you're able to monitor and rate-limit its access. Provide a contact email so developers can report bugs and ask about raising that limit.
- Provide a brand identity guideline:
- If you communicate some or all of your routes using a color legend, provide an official list of the exact color tint to be used for each of these routes. If possible, include these colors inside your GTFS routes.txt file.
- Provide scalable vector versions of your graphic symbols. Prohibit developers from using your logo, not the graphic symbols that help riders identify your routes.