Challenges

Even with the implementation of GTFS-Fares v2 and the improvements this will bring in displaying fares data to riders, fares for intercity bus services are often highly complex and sometimes not able to be fully represented in the GTFS feed specification.

Intercity bus service often has distance-based pricing (also known as zone-based), where riders pay a specific fare depending on where they board and exit the vehicle. The further they go, the more they pay. Fares v2 brings this functionality to GTFS building and will greatly improve the ability of transit providers to display their intercity bus fares.

However, dynamic pricing is unable to be represented in GTFS. FlixBus and Greyhound are two examples of transit providers who change the price of a trip based on such factors as day of the week, holidays, occupancy levels, etc. For some of these providers, especially private for-profit organizations, fares data and pricing models are considered confidential proprietary information.

Another feature that is difficult to represent in GTFS are discounts. Fares for local fixed-route services are generally constant and change very infrequently. Conversely, fares for intercity bus services can change frequently, especially if the organization running the service operates as a for-profit. For some providers, such as Amtrak, discounts seem to be an important part of their business model. Advanced booking discounts, 50% off and Buy-One-Get-One discounts, sales and promotions can be crucial in driving business. The amount of variability and frequency of change in these fares models can be difficult to produce in GTFS.

Code sharing is a business arrangement, common in the aviation industry, in which two or more airlines publish and market the same flight under their own airline designator and flight number as part of their published timetable or schedule. This arrangement is sometimes used in public transportation as well, particularly intercity bus service.

Amtrak does this frequently through their Thruway Connecting Services Program. Intercity buses, operated by contracted third parties, run parallel to Amtrak train service and sell their tickets through Amtrak's website. For example, in Oregon, riders can go from Eugene to Portland on either Amtrak's Cascades train service or the Cascades POINT intercity bus service. The challenge is ensuring that riders know whether they are buying a ticket for a train or a bus and who the third-party contractor is, both on Amtrak's website and trip-planning apps. In the previous example, riders may think they are taking an Amtrak train then be surprised when a POINT-branded bus pulls up.

Similar challenges arise with intercity providers who contract out some of their service. FlixBus is one such provider who operates some trips directly, using FlixBus-branded buses, while other trips are operated by third-party contractors, using their own branding, on behalf of FlixBus.

It can be quite difficult to implement code sharing well in GTFS. Most of the time, the "master agency" is the only operator name given on trip-planning applications. Riders need to know what kind of vehicle they booked their trip in, who is operating the service, what branding to look for as they wait for their ride, and who they can contact if they have any questions.

Intercity bus service and local city bus service are two distinct types of services and thus operate two very different types of vehicles. Local services typically use regular transit buses. Intercity bus services typically use motorcoaches.

Motorcoaches offer riders a variety of comforts and amenities including onboard restrooms, large cushioned seating, extra legroom, power outlets, wi-fi, climate control, and more. Such features are essential for long-distance, multi-hour trips, yet this information cannot be represented in GTFS.

It is imperative that transit operators provide this information, in detail, on their website and use the GTFS fields available to them to reference and link back to their information sources. Riders will be much more likely to book an intercity trip if they know the kind of vehicle they will be taking and the amenities available to them. If vehicle details and amenities cannot be provided in the GTFS, they must be provided elsewhere; ticket sales could very well depend on it.

Intercity bus routes, especially those that are longer, may cross time zones and need to be accounted for in the GTFS.

A transit agency as described in agency.txt can only be associated with a single time zone. If there are stops that exist in a separate time zone from the one associated with the agency (usually the timezone which has the majority of trips in it), then that can be accounted for by adding time zones to all stops in stops.txt using stop_timezone. If this value is omitted, all stops will default to the agency timezone. Therefore, stop time zones only need to be added if stops exist outside the agency timezone.

The time zone associated with the agency should be used as the exclusive timezone for scheduling trip stop times. For example, if the agency time zone is Eastern Standard Time and the trip happens to begin at a stop in Central Standard Time at 9:00 am, then that trip should be scheduled to start in the GTFS at 8:00 am.

When including stop time zones in the GTFS, consistent formatting must be maintained across time zone values. Do not mix-and-match values with different prefixes, such as “US/Central” with “America/New_York.”