A stop represents a location where a vehicle stops. A stop can represent a bus pole, a tram stop, a subway station, train station or a specific platform. Ideally a real-world stop should be represented by only one stop within the GTFS feed (see “Stop Too Close” and “Station Too Close” validation warnings).
You define stops and stations in the stops.txt file. The following example shows a simple stops.txt file:
S1,Mission St. & Silver Ave.,,37.728631,-122.431282,,,
S5,Mission St. & 18th St.,,37.761829,-122.419382,,,
S6,Mission St. & 15th St.,,37.766629,-122.419782,,,
S7,24th St. Mission Station,,37.752240,-122.418450,,,S8
Depending on the level of detail that is available in your data, it may make sense to use a stop/station hierarchy. This allows you to group individual stops that belong to a larger structure like a bus terminal or a train station.
We recommend that you use stop station hierarchies for train, metro and tram stations and for big bus terminals with multiple stops. Two bus stops on both sides of a road aren’t considered to be a station.
Assign the following values to the
0 or blank: Stop. A location where passengers board or disembark from a transit vehicle.
1: Station. A physical structure or area that contains one or more stop.
stop_name field should clearly and concisely identify the stop, and should match what's used in your agency's schedules and signage to help riders easily identify stations or platforms. The words “stop”, ”station” (or local translations of those words) should't be added to every
stop_name. Avoid adding stop codes to the
stop_code field contains short text or a number that uniquely identifies the stop for passengers. As with
stop_codes field should be easily recognizable by users from your signage and schedules. Otherwise the
stop_codes field should be left empty.
The following list describes other fields in the stops.txt file.
||You should provide
||You can provide a more detailed description of the stop in