Vehicle Locations
Providing up-to-date and accurate vehicle locations allows riders to minimize wait times and have more confidence in their trip plans.
When agencies publish GTFS real time feeds with vehicle locations, Transit and other third parties have all the necessary information to display the precise location of the rider’s vehicle, making it easier for these third parties to track the vehicle’s movement.
Required Fields
Crowding
Non-Standard APIs
Although we recommend agencies follow the GTFS Real Time standard for vehicle locations, if you are using an alternative API format, we have some best practices outlined in the section dedicated to non-standard APIs.
Required fields
In order to display vehicles on the relevant trips, we require a Trip Descriptor field, which Transit uses to determine exactly what trip the update refers to. To this end, please include a trip ID that corresponds with a valid trip in the static GTFS data.
The position field must include a latitude and longitude, and vehicle IDs should also be included.
Best practices
- Provide updates as frequently as possible. Transit will request vehicles every 10 seconds.
- Include accurate timestamps for both the vehicle (when the location was received) and the feed (when it was last updated).
Crowding
When users tap their line in the app, they see a map showing the real-time locations of transit vehicles along their route.
When the data is available, the vehicle icon shows both the last update of the vehicle's location and its crowding level. 
The Occupancy Status field includes seven levels of vehicle crowding info. Transit displays three levels: not crowded, some crowding, and crowded. 
How our values match with GTFS RT crowding values
| Definitions | |
|---|---|
| Empty | Not crowded |
| Many seats available | Not crowded |
| Few seats available | Some crowding |
| Standing room only | Crowded |
| Crushed standing room only | Crowded |
| Full | Crowded |
| Not accepting passengers | Crowded |
- Crowding information provided in your vehicle positions feed is visible on the vehicle icon, and in the vehicle information sheet that appears when a rider taps a vehicle’s icon.
- Additionally, there are stop-level crowding predictions, which are based on historical data (when available), as well as real time data.
- For example, if a vehicle is currently empty, but historically “fills up” at a certain stop before the rider’s, we can infer the expected crowding level by the time the rider boards the vehicle.
Best practices
- Include real time crowding information when it’s available.
Non-standard APIs
Not all agencies are able to produce GTFS RT feeds for third parties. We do our best to work with feeds in other formats.
In order for Transit to be able to associate a vehicle to the correct route, we need to know either its trip ID, or its route and headsign.
Matching with Trip IDs: The best way to associate real time data with a scheduled item is by using the trip ID.
Matching with routes and headsigns: If it's impossible to include a trip ID in your API, we can also use fields to match the route and headsign. The route ID or short name can work, as long as they use the same identifiers as the static GTFS. Similarly, the headsign should also directly match the static data.
Additional requirements
- Vehicles should have some way of determining how old the location report is (like a timestamp, or the age in seconds). They must also include latitude and longitude, and ideally should include a vehicle ID.
- If available, we will display crowding information: Please see the crowding section for more details.
- Server requirements: Vehicle locations are fetched every 20 seconds, and we fetch the state of the entire network – not just vehicles for a specific user. For this reason, we prefer unitary endpoints that provide all vehicles in revenue service, or requests by route. Requesting vehicle locations per stop may be feasible for some very small agencies, but we tend not to support this method as it results in unsustainably high server requirements for both Transit and the agency in question.
Best practices
- Use trip IDs when possible, or make sure that routes and headsigns match the static GTFS.
- Ensure your server is able to respond to frequent requests for each route in your system.