Update event_type enum values to snake_case

[chrisyamas]

Summary

In addition to being a normative change (that requires data migration for existing TIDES implementations) this is also a breaking change. This change updates passenger_events.event_type enum values from 'Sentence case' with spaces to snake_case for improved code compatibility.

Resolves #235

Changes

• spec/passenger_events.schema.json updated event_type enum from Sentence case to snake_case. Note: In addition to the snake_case conversion, this PR also removes unnecessary characters/words from several of the enum values for the sake of conciseness. I am eager from TIDES Contributors for input on those modifications. Here are all enum value changes:
  • Vehicle arrived at stop --> vehicle_arrived,
  • Vehicle departed stop --> vehicle_departed
  • Door opened --> door_opened
  • Door closed --> door_closed
  • Passenger boarded --> passenger_boarded
  • Passenger alighted --> passenger_alighted
  • Kneel was engaged --> kneel_engaged
  • Kneel was disengaged --> kneel_disengaged
  • Ramp was deployed --> ramp_deployed
  • Ramp was raised --> ramp_raised
  • Ramp deployment failed --> ramp_failed
  • Lift was deployed --> lift_deployed
  • Lift was raised --> lift_raised
  • Individual bike boarded --> bike_boarded
  • Individual bike alighted --> bike_alighted
  • Bike rack deployed --> bike_rack_deployed
• CHANGELOG.md added BREAKING change entry under [Unreleased] section

Reason for this change

The original 'Sentence case' enum values with spaces (e.g., "Vehicle arrived at stop") create unnecessary friction for some data manipulation operations in code. Values formatted in this way must be quoted in queries, cannot be used as variable names, and require case handling.

The new snake_case format (vehicle_arrived) will yield improvements including:

• no quoting required in SQL queries, making for easier WHERE clauses
• direct mapping to constants/enums within various programming languages
• consistency with common naming conventions in data pipelines
• alignment with other TIDES string conventions

- For reference, see related discussion in Issue #235 and Fall 2025 TIDES Issues Working Group notes from December 1 and December 10.

Review checklist

Per change management policy, the following must be met before feature branch changes can merge to develop branch:

• All JSON files validate
• Reviewed and approved by 2+ contributors or board members

---

Community review status (updated August 27, 2026)

How community review works: Per the TIDES Change Management Policy, a proposal moves forward once at least three TIDES Contributors outside the originating working group publicly comment with a score: Accepted, Accepted with minor changes, or Substantially revised. A few sentences with your read of the proposal is a complete review.

Originating working group (Fall 2025 Issues Working Group, December 1 and 10, 2025 sessions): Christopher Yamas, Gabriel Sánchez Martínez, Ian Thistle, Jay Gordon, John Levin, Joey Reid, Spenser Sutinen. Their work is reflected in the proposal itself; community review comes from Contributors beyond this group.

Review so far: @lauriemerrell has accepted this change and supports extending snake_case to all enums; that scope question is being resolved with the Board Coordinator. Further scored reviews welcome.

Thanks to everyone who has weighed in on this proposal; it is moving into final consideration for v2.0. Further comments are always welcome.

[github-actions]

Documentation available at: http://tides-transit.github.io/TIDES/feature/issue-235-event-naming

[jlstpaul]

This may end up being a separate issue, but I notice that we have bike_rack_deployed, but not bike_rack_raised. We also have ramp_failed but not lift_failed.

[botanize]

Looks good to me

[CTRAN-Sutinen]

Edit: the other events tables need to be updated as well for consistency's sake. if we are going to snake_case enums in passenger events, we should be doing the same in fare events as well.

[lauriemerrell]

@botanize proposal in Contributors meeting 8/13: convert this PR to handle all enums so that snake case is adopted uniformly in the 2.0 release

[lauriemerrell]

putting a request changes review on to indicate the need to update this to handle ALL enums

[jlstpaul]

Here are the other enums in the spec right now.

devices.device_type

Current	Proposed
"Farebox"	farebox
"Fare gate"	fare_gate
"Fare vending machine"	fare_vending_machine
"Passenger counter"	passenger_counter
"Vehicle location"	vehicle_location
"Other"	Other’

fare_transactions.fare_action

Current	Proposed
“Unknown action type"	unknown_action_type
“Purchase"	purchase
”Enter"	enter
"Exit"	exit
"Transfer entrance"	transfer_entrance
"Transfer exit"	transfer_exit
"Add"	add
"New"	new
"Capture"	capture
"Extend"	extend
"Combine"	combine
"Void"	void
"Activate"	activate
"Adjust"	adjust
"Other"	other

fare_transactions.fare_media_id

Current	Proposed
"Cash or coins"	cash_or_coins
"Smart card or ticket"	smart_card_or_ticket
"Magnetic-stripe card or ticket"	magnetic-stripe_card_or_ticket
"Bank card"	bank_card
"Mobile NFC"	mobile_NFC
"Optical scan"	optical_scan
"Button pressed by driver or operator to indicate a boarding or alighting passenger."	button_pressed by_operator
"Other type"	other_type

stop_visits.door_status

Current	Proposed
“Doors did not open"	doors_did_not_open
"Front door opened and back doors remain closed"	front_door_opened_and_back_doors_remain_closed
"Back doors opened and front door remained closed"	back_doors_opened_and_front_door_remained_closed
"All doors opened"	all_doors_opened
"Other configuration"	other_configuration

stop_visits.schedule_relationship

Current	Proposed
"Scheduled"	scheduled
"Skipped"	skipped
"Added"	added
"Missing"	missing

trips_performed.route_type
Since these come from GTFS, should we leave them or change them?

Current	Proposed
"Tram / Streetcar / Light rail"
"Subway / Metro"
"Rail"
"Bus"
"Ferry"
"Cable tram"
"Aerial lift"
"Funicular"
"Trolleybus"
"Monorail"
"Railway Service"
"High Speed Rail Service"
"Long Distance Trains"
"Inter Regional Rail Service"
"Car Transport Rail Service"
"Sleeper Rail Service"
"Regional Rail Service"
"Tourist Railway Service"
"Rail Shuttle (Within Complex)"
"Suburban Railway"
"Replacement Rail Service"
"Special Rail Service"
"Lorry Transport Rail Service"
"All Rail Services"
"Cross-Country Rail Service"
"Vehicle Transport Rail Service"
"Rack and Pinion Railway"
"Additional Rail Service"
"Coach Service"
"International Coach Service"
"National Coach Service"
"Shuttle Coach Service"
"Regional Coach Service"
"Special Coach Service"
"Sightseeing Coach Service"
"Tourist Coach Service"
"Commuter Coach Service"
"All Coach Services"
"Urban Railway Service"
"Metro Service"
"Underground Service"
"All Urban Railway Services"
"Bus Service"
"Regional Bus Service"
"Express Bus Service"
"Stopping Bus Service"
"Local Bus Service"
"Night Bus Service"
"Post Bus Service"
"Special Needs Bus"
"Mobility Bus Service"
"Mobility Bus for Registered Disabled"
"Sightseeing Bus"
"Shuttle Bus"
"School Bus"
"School and Public Service Bus"
"Rail Replacement Bus Service"
"Demand and Response Bus Service"
"All Bus Services"
"Trolleybus Service"
"Tram Service"
"City Tram Service"
"Local Tram Service"
"Regional Tram Service"
"Sightseeing Tram Service"
"Shuttle Tram Service"
"All Tram Services"
"Water Transport Service"
"Air Service"
"Ferry Service"
"Aerial Lift Service"
"Telecabin Service"
"Cable Car Service"
"Elevator Service"
"Chair Lift Service"
"Drag Lift Service"
"Small Telecabin Service"
"All Telecabin Services"
"Funicular Service"
"Taxi Service"
"Communal Taxi Service"
"Water Taxi Service"
"Rail Taxi Service"
"Bike Taxi Service"
"Licensed Taxi Service"
"Private Hire Service Vehicle"
"All Taxi Services"
"Miscellaneous Service"
"Horse-drawn Carriage"

trips_performed.NTD_mode
Since these come from GTFS, should we leave them or change them?

Current	Proposed
"Aerial Tramway"
"Alaska Railroad"
"Bus"
"Bus Rapid Transit"
"Cable Car"
"Commuter Bus"
"Commuter Rail"
"Demand Response"
"Demand Taxi"
"Ferryboat"
"Heavy Rail"
"Hybrid Rail"
"Inclined Plane"
"Jitney"
"Light Rail"
"Monorail/Automated Guideway"
"Other"
"Público"
"Streetcar"
"Trolleybus"
"Vanpool"

trips_performed.trip_type

Current	Proposed
"In service"	in_service
"Deadhead"	deadhead
"Layover"	layover
"Pullout"	pullout
"Pullin"	pullin
"Extra Pullout"	extra_pullout
"Extra Pullin"	extra_pullin
"Deadhead To Layover"	deadhead_to_layover
"Deadhead From Layover"	deadhead_from_layover
"Other not in service"	other_not_in_service

trips_performed.,schedule_relationship

Current	Proposed
"Scheduled"	scheduled
"Added"	added
"Unscheduled"	unscheduled
"Canceled"	canceled
"Duplicated"	duplicated

vehicle_locations.current_status

Current	Proposed
"Incoming at"	incoming_at
"Stopped at"	stopped_at
"In transit to"	in_transit_to

vehicle_locations.gps_quality

Current	Proposed
"Excellent"	excellent
"Good"	good
"Poor"	poor

vehicle_locations.,schedule_relationship

Current	Proposed
"Scheduled"	scheduled
"Skipped"	skipped
"Added"	added
"Missing"	missing

[lauriemerrell]

In GTFS schedule I though those enums were numeric so the styling shouldn't matter?

(Overall, I accept this change and don't have a strong concern about how the GTFS decision falls, but my vote would be for uniformity in TIDES)