GTFS, GBFS, and the Case for Open Mobility Data Standards

What Open Standards Actually Enable

When transit agencies publish GTFS feeds and bike-share operators publish GBFS feeds, those aren't just data transfers — they're participation in a commons. The value of a GTFS feed is not primarily in what the agency's own trip planning app can do with it. The value is in what becomes possible when hundreds of agencies publish machine-readable schedule data in the same format: third-party trip planners, accessibility apps, transfer optimization systems, academic research, and analytical platforms like Mobvynt can all read that data without custom integration for each agency.

That composability — the ability to combine data from different sources because they share a format — is the economic foundation of multimodal demand analysis. A demand surface that fuses GTFS transit data with GBFS bike-share data and ACS demographic data is only possible because the underlying standards exist. Without GTFS and GBFS, you'd need a separate data integration project for every transit agency and every bike-share operator, making any kind of cross-agency or multimodal analysis prohibitively expensive for all but the largest organizations.

This is why the argument for requiring GTFS and GBFS compliance in all mobility contracts isn't just about technical interoperability — it's about preserving the conditions that make high-quality public transit and multimodal planning analysis possible.

GTFS: What It Covers and What It Doesn't

The General Transit Feed Specification, originally developed by Google in collaboration with TriMet (Portland, Oregon) and published in 2005, defines a standard format for public transit schedule data. The core GTFS specification (often called GTFS-static) covers:

• Route definitions (route_id, route_type, route_short_name, route_long_name)
• Trip sequences (which stops a trip visits, in what order, at what scheduled times)
• Stop locations (latitude/longitude, name, accessibility attributes)
• Service calendars (which service patterns run on which days)
• Fare information (fare rules and fare attributes — though fare data quality in GTFS is highly variable)

GTFS-RT (GTFS Realtime) extends the specification to cover real-time service status: VehiclePositions (current location of operating vehicles), TripUpdates (delay predictions for upcoming stop arrivals and departures), and ServiceAlerts (disruption information). GTFS-RT uses Protocol Buffers for serialization and is designed for sub-minute update frequencies.

Newer extensions — including GTFS-Fares v2, GTFS-Pathways (for station wayfinding), and GTFS-Flex (for demand-responsive service) — are expanding the specification's coverage. The Mobility Data organization (the nonprofit that now maintains GTFS) has been active in standardizing these extensions, though adoption rates vary considerably across agencies.

What GTFS doesn't cover: actual ridership (that's in APC and AFC data, not currently standardized across agencies), service quality metrics, or fare payment transaction data. These data sources are relevant for demand analysis but remain in agency-specific formats — a significant gap in the open data ecosystem.

GBFS: The Bike-Share Standard and Its Limits

The General Bikeshare Feed Specification was developed by NABSA (North American Bikeshare & Scooter Association) and is now maintained by the Mobility Data organization alongside GTFS. The current specification (version 3.0, released 2023) covers:

• Station information and status (for docked systems)
• Free-floating vehicle positions (for dockless bikes and scooters)
• System information and operating hours
• Pricing information
• Geofencing zones (for speed restrictions and parking areas)

GBFS is required for scooter and bike-share operators in many cities as a condition of their operating permit. The requirement typically covers the station/vehicle information and status feeds, which are the real-time availability data. Trip records — the origin-destination pairs that are most analytically valuable for planning — are often not covered by the base GBFS permit requirement, and operators vary in their willingness to share trip-level data.

This creates an important gap: the publicly available GBFS feed tells you where bikes and scooters are available right now, but it often doesn't tell you where trips actually went. For first/last mile analysis at scale, agencies need trip-level data sharing agreements that go beyond the standard permit requirement.

Why Agencies Should Require Compliance in Contracts

There are two contexts where agencies have direct standing to require open data standard compliance: procuring mobility analytics software and negotiating operating permits or data-sharing agreements with mobility operators.

In mobility analytics contracts: require that the vendor produce outputs in GTFS-compatible formats, document their input data requirements in terms of GTFS fields (not proprietary data schemas), and provide data export in standard open formats (GeoJSON, CSV, GTFS scenario files). A vendor whose analytical outputs can only be consumed through their proprietary interface creates lock-in that's particularly problematic when contract terms end and institutional knowledge needs to be preserved.

In micro-mobility operating permits: require GBFS 3.0 compliance as a condition of the permit. GBFS 3.0 is the current standard and includes significant improvements in trip data handling compared to earlier versions. Require trip data sharing (with appropriate privacy protections — GBFS trip data can be anonymized at the trip level without individual rider identification) as a condition of permit renewal. The data should be shared in a format accessible to the city's transportation planning department, not just available through the operator's analytics portal.

We're not saying every mobility operator will enthusiastically comply with open data requirements. Trip-level data sharing in particular may require negotiation, and operators have legitimate concerns about competitive sensitivity of their operational data. The appropriate response is to define the data sharing requirements specifically (anonymized trip-level OD data, aggregated to a minimum cell size consistent with privacy protection) and include them in permit terms from the outset, rather than trying to negotiate them retroactively.

The Fragmentation Problem: When Standards Diverge

Open standards are only valuable to the extent they're consistently adopted. One of the persistent challenges in the GTFS ecosystem is that agencies interpret and implement the specification with varying degrees of completeness and accuracy. Specific issues that affect demand analysis:

• Inconsistent use of optional fields: GTFS has mandatory and optional fields. Optional fields like stop accessibility attributes (wheelchair_boarding), bike-accessible routes (bikes_allowed), and exact vs. approximate stop timing (timepoint) are inconsistently populated. For accessibility analysis, this means you often can't rely on GTFS alone — you need to supplement with other data sources.
• Route shape quality: The GTFS shapes.txt file contains route geometry, but the quality of that geometry varies from sub-meter precision (agencies that maintain it carefully) to significant positional errors (agencies that haven't updated shapes after route modifications).
• Calendar vs. calendar_dates conflicts: The interaction between calendar.txt and calendar_dates.txt (which specifies exceptions to regular service) is a known source of data quality issues. Feeds where calendar_dates exceptions aren't correctly maintained can produce incorrect service pattern inferences.

These aren't arguments against GTFS as a standard — they're arguments for agencies to invest in feed quality maintenance and for analytics vendors to implement thorough validation and quality-flagging pipelines. The standard is sound; the implementation discipline is the variable.

Open Standards and Competitive Procurement

One underappreciated benefit of requiring open standard compliance in mobility contracts is the effect on competitive procurement. When vendors are required to produce outputs in GTFS and GBFS formats, and when input data requirements are specified in terms of standard fields, the evaluation of competing proposals is much more straightforward. Evaluators can ask: "Can this vendor's platform ingest our GTFS feed as-is and produce GTFS scenario exports compatible with our CAD/AVL system?" That's a concrete, testable requirement — unlike "does this platform meet our mobility analytics needs?" which is essentially unevaluable without extensive testing.

Open standards also reduce switching costs when contracts end. If your agency's historical demand surface data is exported in standard formats and your GTFS scenario files are compatible with multiple CAD/AVL vendors, you have genuine choice when procurement cycles come around. That competitive pressure keeps vendors accountable in ways that lock-in cannot.