🚀💻 – Passenger Counts at Fare Gates Without Fare Transactions

[chrisyamas]

WMATA operates in situations where fare gates are opened in "free mode" without requiring fare taps, resulting in passenger count records that are not linked to fare transactions. While the fare collection and passenger counter systems are separate, it may be possible to link these records before converting the data into the TIDES format.

This raises the following key questions and considerations:

• Schema Placement:
  Where in the TIDES schema should these faregate passenger counts be recorded?

  • The Passenger Events table currently requires a vehicle_id, which is not applicable in this context.
  • Should this become a new extension of TIDES for handling faregate passenger counts at the station level?

• Aggregation Level:
  Passenger counts at fare gates might best aggregate at the station level, similar to how fare transactions aggregate at the route/trip/stop or station level.

• Linking Fare Transactions and Passenger Counts:
  In some instances, there may be a way to link faregate transactions and passenger counts, but it requires further investigation.

Proposed Next Steps:

1. Confirm the schema placement for faregate passenger counts.
2. Discuss whether this should be a TIDES extension specifically for handling station-level counts without associated fare transactions.
3. Determine feasibility of linking passenger counts to fare transactions prior to merging into TIDES format.
4. Document use cases for this scenario (e.g., tracking free-mode usage, fare evasion monitoring).

Dependencies:

• WMATA input on how faregate data is currently processed.
• Technical review of the existing TIDES schema to identify gaps.

Additional Context:

This issue was initially raised by Michael Eichler at WMATA in August 2024, noting that passenger counts at fare gates could provide valuable insights for tracking fare evasion and free-mode usage. However, the existing TIDES schema does not fully support this use case, prompting the need for further exploration and possible schema extensions.

[chrisyamas]

We've been digging into this faregate issue that WMATA raised earlier this year, and wanted to share some thoughts on how we might approach it.

The Problem in a Nutshell

WMATA sometimes operates fare gates in "free mode" (no fare required), which creates passenger count records without corresponding fare transactions. The current TIDES spec doesn't have a great place to put this data, since:

• The passenger_events table requires a vehicle_id (not applicable for stations)
• The fare_transactions table is designed for, well, fare transactions (which don't exist in free mode)
• The station_activities table is too aggregated for event-level data

This isn't just a WMATA-specific problem - any agency with gatelines or turnstiles likely faces similar challenges tracking passenger movement at stations.

Possible Solutions

After thinking through this, I see three main options:

Option 1: Create a New "Faregate Events" Table ✨

This would be a dedicated table for tracking passenger movement through faregates:

faregate_events
- faregate_event_id (PK)
- service_date
- event_timestamp
- stop_id
- device_id
- event_type (Entry/Exit)
- operation_mode (Free mode/Normal mode)
- linked_transaction_id (optional)
- event_count

This approach:

• Follows TIDES' existing pattern for event tables
• Provides event-level detail
• Works for both free mode and normal operations
• Allows optional linking to fare transactions when they exist

Option 2: Extend Station Activities Table

We could enhance the existing station_activities table with more granular time periods and flags for free mode operation. Simpler approach, but might not provide the event-level detail needed.

Option 3: Create a Formal TIDES Extension

Develop a "Station Infrastructure Extension" that includes faregate events, station equipment, etc. More comprehensive but potentially more complex.

Why This Matters Beyond Free Mode

A faregate events table would be useful for:

• Station performance monitoring: Track passenger flow, gate utilization, peak periods
• Safety applications: Evacuation modeling, crowd management
• Operational planning: Maintenance scheduling, staff deployment
• Revenue protection: Fare evasion monitoring, special event management
• Data completeness: Filling gaps in passenger journey tracking

My Recommendation

I think Option 1 (new faregate_events table) makes the most sense because:

1. It's consistent with how TIDES handles other event data
2. It provides the necessary detail while maintaining a clean data model
3. It's flexible enough to handle various operational scenarios
4. It addresses a genuine gap in the current spec

This would require Board approval since it extends the core specification, but the implementation cost seems modest compared to the analytical value gained.

Next Steps?

If others agree this is worth pursuing:

1. We could refine the proposed schema based on feedback
2. Gather input from other agencies with fare gates
3. Develop a formal proposal for the Board
4. Consider how this would integrate with the rest of the TIDES ecosystem

What do you all think? Is this the right approach? Are there other considerations we've missed here?

[botanize]

Station activities is a summary table, so I don't think option 2 is a good fit.

However, instead of a faregate events table, could this be a more generic device events table?

[jaygordon]

I think it's useful to have a flexible file/table definition for instantaneous events in general. For vehicle data, I see passenger_events as a catch-all for any instantaneous vehicle-based event that isn't a stop_visit or vehicle_location despite it's name. (I can imagine it being slightly extended to capture non-passenger-related events, like drivers logging into the system or the bus recognizing that it's on a new trip.) I think this type of catch-all table is very useful and in some cases necessary for non-vehicle-based events as well.

Off the top of my head, two ideas that come to mind are:

1. Broadening @chrisyamas 's suggested faregate_events file/table to cover discrete, instantateous events from any type of stationary device (that is, any device that requires some kind of place ID but not a vehicle ID) and that isn't a fare_transaction, (which has many non-generizable fields). This might include things like stationary passenger counters in a walkway between subway platofrms that produce discrete entry/exit records, or various system messages from ticket vending machines, rail signaling equipment, etc.
2. Broadening it even further to handle vehicle-mounted, stationary, or mobile devices. This is a bigger structural change and would combine option 1 with what is currently the passenger_events table, and would also handle things like a roaming conductor or fare inspector's handheld validator or counter, which might record lat/lon but not station ID or vehicle ID. The drawback here is that it would require a case-specific definition of which combination of vehicle ID and place ID are required or prohibited. A benefit is that there would be one general purpose table, with a single (though probably large) enum of event types.

There are probably many other pros/cons I'm not thinking of but it would be interesting to discuss.