Every tap, every ticket.

Fare devices log each payment with a time, a device and a product. The sample is a regional card system's record for one agency, so it also shows riders arriving from other operators.

taps over days
distinct cards, taps each on average
of taps follow a tap on another operator's system
of taps charged a cash fare; the rest were passes, transfers or zero-fare

The TransferServiceProvider field. The card system's central record and the agency itself are the defaults; the rest are riders arriving from other operators, the cross-agency link already present in one agency's file.

Two peaks, morning and afternoon. Compare the boardings-by-hour chart on the passenger counting page.

The fare file stops on September 19, so it covers nineteen of the thirty service days the other files do.

Codes as the vendor records them; the data dictionary gives their meanings. Codes, not names, are what an adapter has to translate.

The fare system's own route key, which matches neither the timetable's nor the vehicle system's. See cross-checks.

Fare data is the closest thing an agency has to a record of demand, and the only file here that can point to a person: the card serial links taps into a trail. The site counts cards; it never shows one.

That is why three of its columns are restricted and why, in the federated design, fare data crosses only aggregated or inside a clean room. The transfer field shows what the region gains from doing that carefully.

Rows: One per tap, 18 columns, with a header
Days: to
Cash fares: Median when charged
Locations: device locations, lines
Shared as: TIDES fare transactions
Feeds: Regional revenue and transfers, origin–destination, ridership forecasting