search

openmobilityfoundation / mobility-data-specification

A data standard to enable right-of-way regulation and two-way communication between mobility companies and local governments.
https://www.openmobilityfoundation.org/about-mds/
Other
688 stars 232 forks source link

Support for fixed-route services #922

Open Mu-yi-Zhou opened 1 week ago

Mu-yi-Zhou commented 1 week 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

Impacted Spec

For which spec is this feature being requested?

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 week ago

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

schnuerle commented 1 week ago

From WG meeting:

image image

Gaps in the passenger services mode for current fields.

  1. Route identifier, like for transit routes. For Geography and Jurisdiction, data APIs
  2. Stopping event, linked to a stop ID. In Event API
  3. 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 week 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 week 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 week 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 days 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)

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

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

jiffyclub commented 3 days 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 2 days ago

I think at least we will need:

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>