Create your data feed
Routes describe how agencies communicate their services to riders. You define routes in the routes.txt file, which has the following structure:
The following example shows a simple routes.txt file:
17,A,Mission,"The ""A"" route travels from lower Mission to Downtown.",3
You should organize route.txt entries in the same way as you communicate the physical routes or lines to your riders. For example, group your timetables by route in routes.txt, just as you would when presenting them on a website or in a printed booklet. The structure of your routes.txt file should correspond directly to these timetable routes.
To ensure a quality data feed, follow these best practices in modeling your routes:
route_text_colorfields help users to identify a route.
- These values should be consistent with colors in schedules, maps, signage or labels on the vehicle.
- Use contrasting colors for the
route_text_colorfields, as they are used as text and background colors when displaying route names.
- If your agency doesn't use colors, it’s fine to leave these fields empty.
route_urlshould lead to a webpage that provides information about the particular route.
route_desc: Enter a description of the route using the
Routes vs. Trips
Do not break a physical route into multiple entries in routes.txt to represent different route variations,(such as direction of travel.) Instead, use trips.txt features to model those variations. If you see multiple entries in routes.txt with the same
route_long_name, this is a sign that routes have been needlessly subdivided.
R10,10,Airport - Downtown,3
R20,20,University - Downtown,3
Routes in your GTFS feed should use the same naming as the physical routes or lines communicated by your agency. City networks often use numbers, letters, or colors to distinguish different lines and routes. However, intercity trains, long distance buses or ferry services are often identified by their type or by the name of the operator, and these identifiers should be used as route names.
Don't include words like "line" or "route" in route names. The value of the
route_short_name field should be a number or a short identifier. Don’t duplicate this value in the
route_long_name field, since they are generally shown next to each other. If the route doesn't have both a
route_long_name and a
route_short_name, you can leave one field empty.
We always prefer to show the
route_short_name. If the
route_long_name contains the name that is used for communication, the
route_short_name should be left empty.
The following are examples of route modeling:
- Bus line 1 operates between A - B - C - D - E - F. Some trips only operate between A and D, some trips skip B, C and E. This should be modeled as one route “1” in the feed including trips from A to F, F to A and all variations.
- If the trips that skips B, E and E are communicated as separate line “1 Express” to users in schedules, maps and signage they should be modelled as separate route “1 Express” in the feed as well.
The Zürich tram network uses numbers and colors to identify the different lines:
trip_headsign: “Zürich, Albisgütli”]
trip_headsign: “Zürich, Zoo”]
National rail services in Great Britain are communicated by the name of the operator:
route_short_name: “South West Trains”,
trip_headsign: “London Waterloo”]
National rail services in Europe are communicated by the type of train:
ICE 801 Berlin Südkreuz
trip_headsign: “Berlin Südkreuz”,
trip_headsign: “Interlaken Ost”]
Long distance buses in Argentina are communicated by the name of the operator:
trip_headsign: “Rafael Castillo”]