A trip is a sequence of two or more stops within a specific time. You define trips in the trips.txt file with this structure:
trips.txt |
---|
route_id |
service_id |
trip_id |
trip_headsign |
block_id |
Example of a simple trips.txt file:
route_id,service_id,trip_id,trip_headsign,block_id
A,WE,AWE1,Downtown,1
A,WE,AWE2,Uptown,2
Headsign information
The trip_headsign
field should contain text that appears on the vehicle or signage that identifies a specific line variant to passengers. It shouldn’t duplicate the values in the route_short_name
or route_long_name
.
A headsign typically has information about a trip destination. However, if it’s similar to other passenger signage, you can also use a direction like “inbound or outbound.”
It’s not mandatory, but we recommend you provide a trip_headsign
. If you don’t, we use the name of the last stop as the trip_headsign
in routing results. However, this practice may change and you shouldn't rely on it as a long-term solution.
Circular trips
A circular or loop trip follows a circular path. The guidelines for headsigns apply to circular trips. For example, you must provide headsign information that shows passengers the direction in which the vehicle is going.
To indicate a change of direction, provide stop_headsigns
in the stop_times.txt file. The stop_headsign
describes the direction for trips that depart from the stop for which it's defined. You can add stop_headsigns
to each stop to allow you to change the headsign information along a trip.
Important: Do not define a trip where a bus goes between 2 endpoints as a circular or loop trip in the stop_times.txt file. Instead, split the trip into 2 separate trip directions.
Examples of circular trip modeling
Circular trip with changing headsign for each stop
Trip_id,arrival_time,departure_time,stop_id,stop_sequence,stop_headsign
trip_1,06:10:00,06:10:00,stop_A,1,”B”
trip_1,06:15:00,06:15:00,stop_B,2,”C”
trip_1,06:20:00,06:20:00,stop_C,3,”D”
trip_1,06:25:00,06:25:00,stop_D,4,”E”
trip_1,06:30:00,06:30:00,stop_E,5,”A”
trip_1,06:35:00,06:35:00,stop_A,6,””
Circular trip with two headsigns
Trip_id,arrival_time,departure_time,stop_id,stop_sequence,stop_headsign
trip_1,06:10:00,06:10:00,stop_A,1,”outbound”
trip_1,06:15:00,06:15:00,stop_B,2,”outbound”
trip_1,06:20:00,06:20:00,stop_C,3,”outbound”
trip_1,06:25:00,06:25:00,stop_D,4,”inbound”
trip_1,06:30:00,06:30:00,stop_E,5,”inbound”
trip_1,06:35:00,06:35:00,stop_F,6,”inbound”
trip_1,06:40:00,06:40:00,stop_A,7,””
Pickup & drop-off types
By default, pickups and drop offs are assumed to be regularly scheduled pickups and drop
offs.
The pickup_type
field in the stop_times.txt file indicates whether:
- Passengers are picked up at a stop as part of the normal schedule
- A pickup at the stop is unavailable
- Passengers must call the agency or notify the driver to arrange a pickup at a particular stop
The drop_off_type
field in the stop_times.txt file indicates whether:
- Passengers are dropped off at a stop as part of the normal schedule
- A drop off at the stop is unavailable
- Passengers must call the agency or notify the driver for drop off at a particular stop
Valid values are:
- 0 or empty: Regularly scheduled pickup or drop off
- 1: No pickup or drop off available
Important: While pickup_type
and drop_off_type
of 2 or 3 is part of the GTFS spec, Google Maps does not currently support these types.
Non-revenue, or deadhead, trips that don’t provide passenger service should be marked with pickup_type
and drop_off_type
value of 1 for all stop_times rows.
On revenue trips, internal “timing points” for monitoring operational performance and other places, like garages where a passenger cannot board, should be marked with pickup_type
/ drop_off_type
= 1.