Support for fixed-route services

Mu-yi-Zhou commented 1 month ago

Is your feature request related to a problem? Please describe.

The SFMTA is getting regulated commuter shuttles on MDS 2.0, and we have issues when fitting some service attributes into the existing data schema of Passenger Service. 1) route identifier; 2) stop_id and stop_sequence by route; 3) stop_id linked with an event of stopping.

We are proposing a new mode of fixed route services, for example, commuter shuttle, private transit (that used to operate in SF).

Describe the solution you'd like

1) add a new mode of fixed route service 2) adding route_id, stop_id, stop_sequence to existing endpoints.

Is this a breaking change

Maybe breaking

Impacted Spec

For which spec is this feature being requested?

agency
policy
provider

Describe alternatives you've considered

adding route_id, stop_id, stop_sequence to existing endpoints

Additional context

Draft field mapping document

See also Issues #919 and #920.

See the recording and discussion from the public MDS WG meeting.

schnuerle commented 1 month ago

We'll be talking about this to tomorrow's MDS WG meeting.

schnuerle commented 1 month ago

From WG meeting:

SFMTA already receives telemetry data in a bespoke format for operators.
Review permit annual, and review each stop for usage.
Need geofencing and restricted entrances based on size and weight, speed, slow streets
Citations through GPS data, important for program.
Each operator has a route for their shuttle and defined stops

Gaps in the passenger services mode for current fields.

Route identifier, like for transit routes. For Geography and Jurisdiction, data APIs
Stopping event, linked to a stop ID. In Event API
Sequence of stops for each route

Routes for most operators should be private, provided for their own client. Desire to mirror some of the data models in GTFS.

schnuerle commented 1 month ago

Work done in a proposal by APIsTech w/ SFMTA already on mapping each needed field to MDS.

https://docs.google.com/document/d/1xnNx0z2aRkDwT0IdAXqvWvrpcJ0vK5jDNUW_zxgl_pM/edit?usp=sharing

schnuerle commented 1 month ago

I'd like to also mention an emerging standard from CalITP called TODS (Transit Operational Data Standard). It's meant for regulators to track bus activities, by supplementing GTFS with private feeds for that. It's more simplified in scope and structure vs MDS.

The format is more like GTFS (CSV format) than MDS (authenticated API structures), and doesn't cover all the use cases here especially around communicating to operators geofencing and operational rules and fees/incentives and restrictions. It also doesn't have GPS points/breadcrumbs, or route deviation tracking.

jiffyclub commented 1 month ago

Following up on the working group call: I think fixed-route functionality for MDS could be a great addition. I took a quick look at the GTFS spec and while it looks like it would contain the necessary information, the format does look cumbersome and not well suited to APIs. I think fixed-route functionality could have utility across a number of modes so I would first attempt to support that independent of any mode. We could potentially make changes to the Event, Trip, and Policy specs to better support bus-ish service if necessary, especially under the passenger services mode.

monachiu commented 4 weeks ago

That will be a great start to incorporate the 1) route identifier; 2) stop_id and stop_sequence by route; Which endpoints should these fields affiliated with? Will it be in the telemetry endpoints? When there are multiple stops in each route, will each stop in individual event or each event with multiple stops. The stop sequence is for the order of stops. The values must increase along the trip but do not need to be consecutive.

Based on the existing passenger mode to modify for the Shuttle Vehicle States Events draft (stop at multiple stop locations)

jiffyclub commented 3 weeks ago

I think this would mostly affect the Events API. Maybe we could add a passenger_pick_up_drop_off event type that can be used to go from the on_trip state to the stopped state to make clear the purpose for the stop. Then the trip_resume event type could be used to go back to the on_trip state.

MDS already has the concept of mode-specific trip fields (example for passenger services), I think it could make sense to have mode-specific event attributes as well for things like the stop ID and sequence number.

Mu-yi-Zhou commented 3 weeks ago

I think at least we will need:

route_id in trips, events, geography, policy
stop_id in events, telemetry, geography, policy

I would propose a new endpoint for schedule with fields route_id, stop_id, stop_sequency. Or we can point to the GTFS schedule if that works - i haven't looked into it

monachiu @.***> 于2024年10月28日周一 16:31写道：

That will be a great start to incorporate the 1) route identifier; 2) stop_id and stop_sequence by route; Which endpoints should these fields affiliated with? Will it be in the telemetry endpoints? When there are multiple stops in each route, will each stop in individual event or each event with multiple stops. The stop sequence is for the order of stops. The values must increase along the trip but do not need to be consecutive.

Based on the existing passenger mode to modify for the Shuttle Vehicle States Events draft (stop at multiple stop locations)

From vehicle_state To vehicle_state trip_state event_type stop_id stop_sequence Description stopped on_trip on_trip trip_start N/A N/A Start a trip on_trip stopped stopped trip_stop 13900 2 The vehicle has stopped at shuttle stop while on a trip to pick up or drop off passenger stopped on_trip on_trip trip_resume N/A N/A Resume a trip that was previously stopped (e.g. picking up or drop off passenger) on_trip stopped stopped trip_stop 14446 5 The vehicle has stopped at shuttle stop while on a trip to pick up or drop off passenger stopped on_trip on_trip trip_resume N/A N/A Resume a trip that was previously stopped (e.g. picking up or drop off passenger) on_trip stopped stopped trip_stop 20045 10 The vehicle has stopped at shuttle stop while on a trip to pick up or drop off passenger stopped on_trip on_trip trip_resume N/A N/A Resume a trip that was previously stopped (e.g. picking up or drop off passenger) stopped available N/A trip_end N/A N/A The shuttle trip has been successfully completed

— Reply to this email directly, view it on GitHub https://github.com/openmobilityfoundation/mobility-data-specification/issues/922#issuecomment-2442865704, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBXIIFALDGNEY7ZE3RHONKTZ53COLAVCNFSM6AAAAABQPGRV5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBSHA3DKNZQGQ . You are receiving this because you authored the thread.Message ID: <openmobilityfoundation/mobility-data-specification/issues/922/2442865704@ github.com>

Joe-I-source commented 3 weeks ago

Hey folks, Jumping in a little late. Other considerations would include traditional transit metrics, passing load, productivity (passengers/revenue hour). Finally, if there aare public intermodal facilities that are utilized by the shuttles, there is an opportunity to track dwell time and ridership.

openmobilityfoundation / mobility-data-specification