10 Ways to Boost Your GTFS

If your GTFS comes from a CAD/AVL software, you likely have shapes.txt included in your GTFS. If it comes from scheduling software, or is made using spreadsheets, it likely does not.

Shapes can give riders a sense of 'how long' a trip is going to take - some riders will prefer shorter trips over longer (but quicker) ones, and shapes are the easiest way to convey length.

Loop routes can be tricky to describe using trip-level headsigns. Stop-level headsigns (which act like the scroll on a bus' headsign) can change the headsign value mid-trip.

Not sure what to set as the stop-level headsign? Pick 1-2 landmarks or significant stops along the loop, and set the headsigns to switch out at those stop. So, if you have a loop that will run between the downtown plaza and Wal-Mart, have one headsign read "Wal-Mart" for all stops before Wal-Mart, and then at Wal-Mart, have the stop headsign read "Downtown" for the rest of the stops.

Stop names are one of the most ambiguous parts of the GTFS spec, but a good metric to improve them is to ensure they are short and consistent. Many applications will abbreviate long stop names, so striking the balance between detail and brevity is key.

Cut down on the 'chaff' in your stop names by removing periods after abbreviations (like Ave instead of Ave.), use & instead of 'and', and avoid unnecessary directional information like 'across from' or 'northbound.' Remember that stop information is geolocated, so riders (even blind riders) are going to be directed to the actual stop location.

Fares in GTFS can only account for one-way, full price fares, but even including those can give riders using multiple agencies a sense of how much they may expect to pay on a trip. If a trip requires three different agencies (such as an intercity trip), if even one of the three agencies does not publish fares, no fare will calculate. Improvements to fares is in the pipeline for GTFS, but for now, including base one-way fares in your GTFS ensures you are supporting the ecosystem.

Routes can be any color, but the best way to ensure your routes are visible to all riders using any application is to ensure the contrasting route_text_color is sufficient. Online tools like WebAIM will tell you whether black or white has higher contrast against your route's color. Even if you *think* it should be one or the other, people's vision varies wildly and those with visual impairments might see something entirely different.

feed_info.txt is a simple file to add to your GTFS and helps consumers know which GTFS dataset they are looking at. Since your feed may be produced by a vendor, or another agency, you can help apps know who to contact about the data in the GTFS, indicate when the feed is 'good until,' and what version number/schedule bid the GTFS represents. Extremely helpful for when all your GTFS files are simply called "gtfs.zip" to accommodate static URLs!

Many routes in GTFS are true loops - routes that do not service the same street more than once - but many more are described as loops just because that's how their timetables look on the PDF. A good rule of thumb is if there are stops on both side of the street that service the same route, it should be broken up by direction.

Breaking a trip into two directions allows apps like the Transit App to better direct riders toward the best stop to reach their destination quickest. Especially if missing stop-level headsigns for a loop, riders cannot 'see' whether they should get on at the stop on one side of the street, or the other.

Your GTFS may come from a CAD/AVL or scheduling system, which may include abbreviations, operational terms, or hacks. Remember that your GTFS is for riders and should read like your web and print collateral. Check stop names, route names, and headsigns for internal terms that do not affect riders, or would be confusing to a new rider. Common missteps include headsigns like "DWNTN TC" instead of "Downtown Transit Center" or route numbers that are not listed elsewhere like "5: Green Route" when riders only ever see "Green Route."

Nothing excites a rider like seeing three blue bus icons all clustered together, where each one is for a different service and named slightly differently than others. When sharing stops with other agencies, make sure to coordinate data points like the latitude and longitude used, stop name, and if possible, stop_code. Some apps like Google Maps will occasionally aggregate stops that are close to one another, but the best way to ensure multi-agency services show on a single stop is to have the data look the same across all the GTFS using that stop. Also reduces the need to have an edit war on the stop name.

The National Transit Map aims to be the most comprehensive database of transit in the US, and getting every agency - from small senior center shuttles to New York's MTA - in there will be no small task. Do your part and make sure your GTFS is there and plant your flag on the NTM!

Learn more about how to register for the National Transit Map.