metropolitan-council / serviceadjustmentsapi

Design of Transit Master Service Adjustments API for Adjusted Schedule Data Loader

DRAFT API specification for Service Adjustments

TODO:

• Test on loops (same stop visited twice in the same pattern)
• Detour modifications: same id, or new id with a reference to previous version? If same id will need a modification date field.

Known Issues with OpenAPI definition

• Some optional fields may not be set to nullable
• Handling of adjustment end date vs expected end date hasn't been finalized
• Some fields may be required for GTFS-realtime, but optional for the adjusted schedule, or could be in a simplified format (e.g., string instead of TranslatedString)
• Possibly others!

Adjusted Schedule

This endpoint bundles the information required to apply a service adjustment (detour) to Metro Transit's schedule database.

GTFS-realtime Service Changes APIs

These API endpoints are based on the GTFS-realtime Service Changes v3.1 proposal, or aspects of the spec that have been merged into GTFS-realtime v2.0.

• TripUpdates
• NewShapes: google/transit#272
• NewTrips
• NewRoutes
• NewStops
• ServiceUpdates

serviceadjustmentsapi's Issues

Add the other comments field(s) to the API

This one shows up in the TransitMaster UI under "Other Details" "comments" -
Maybe is Travel_Path table "dispatch notes" ? Will check with Vontas to confirm

Add Path_Name to the API output

Probably not essential for implementing with adjusted schedule, but doesn't hurt and potentially helps communicate Ops' intentions to ensure data are coming through as expected.

Change "new_shapes" in Adjustment to something unique

Some confusion between the detour shape definition and the ServiceChanges shape definition

Add detour nickname to New Shape?

Adjustment.new_shapes.properties.detour_nickname?

ServiceAdjustmentsAPI/ServiceAdjustments_OpenAPI.json

Line 951 in b68d322

"properties": {

Test output for detour on loop

• Find a loop in the schedule, I think a route in the 60s has one

Add corner information to new stops

Some of the Adj Schedule recipient systems need the corner number / corner type field for new stops created in TransitMaster.

The information will be stored as part of the ALTERNATE_STOP table in the TMDailyLog db. The information will be visible wherever stop properties are shown and in the UI of the alternate stop dialog of stop closure and detour adjustments.

It's looking like TransitMaster will have two separate fields each with 4 options-

1. Northbound, Southbound, Eastbound, and Westbound
2. Nearside, Farside, Midblock, and Across From

Identify if ServiceAlerts data should be included in API

Should the information needed to populate ServiceAlerts be included within the same API?

Add comments field for the overall Service Adjustment to API output

I think this is Dispatch_service_adjust table “comments” field, but will check with TransitMaster to confirm