All committers have signed the CLA.

Some items to consider, based on OMF staff discussion with SFMTA staff.

1. Should these fields be in the data types for all modes, or in just Passenger Service
2. Potentially add a service_id to better describe the route id
3. Could add another field route_name, or reference it only in external endpoint in Schedule
4. Maybe add stop_sequence to telemetry too
5. Policy and Geography may not need route and stop info, geographic policies should be sufficient
6. A draft of what's in Schedule would be useful to see, like route info, stop sequence, calendar (days of week), calendar dates (month/day of operation), including exceptions
   • GTFS could be the solution here. Would need to make sure route_id, service_id is in GTFS Schedule format, and new GTFS URL (info) field in MDS Trips. GTFS_Stop_id may be needed in events too.
7. stop sequence might not need to go in Trips
8. Might need a gtfs_url in the providers.csv file to track new operator IDs
9. Operators would generate a unique device_id UUID, but can also use VIN, license plate, USDOT id, etc fields.

We will be discussing this at this week's MDS Working Group meeting. Please review and leave your comments and use cases and questions ahead of time.

Hi all,

Replying to earlier discussion points with my thoughts

1. Should these fields be in the data types for all modes, or in just Passenger Service
   I think there is a lot of potential for other modes and the new fields should be for all modes. I would love to hear thoughts from other OMF members
2. Potentially add a service_id to better describe the route id
service_id and route id will both be needed to show what the route is and what times it runs. These can reference routes.txt, calendar.txt, and calendar_dates.txt in GTFS.
3. Could add another field route_name, or reference it only in external endpoint in Schedule
   Referencing routes.txt in GTFS may be the best option here, no route_name field needed
4. Maybe add stop_sequence to telemetry too
   Yes, add stop_sequence to Telemetry
5. Policy and Geography may not need route and stop info, geographic policies should be sufficient
   Policy and Geography endpoints don't need the new fields (stop_sequence, service_id and route id)
6. A draft of what's in Schedule would be useful to see, like route info, stop sequence, calendar (days of week), calendar dates (month/day of operation), including exceptions

• GTFS could be the solution here. Would need to make sure route_id, service_id is in GTFS Schedule format, and new GTFS URL (info) field in MDS Trips. GTFS_Stop_id may be needed in events too.
  Use routes.txt, calendar.txt, and calendar_dates.txt in GTFS as the schedule with route_id and service_id matching GTFS format. I'm not sure if that alone is enough to connect MDS to the GTFS spec, if not a gtfs_url field may be needed in [Trips, Events, Telemetry]. I'm also not sure if the gtfs_url field would be needed in all of them. Would love insight from OMF community on this.

7. stop sequence might not need to go in Trips
   Not sure, depends if stops are in MDS or GTFS. For now, it seems like stop sequence will stay in MDS and GTFS stops won't be needed.
8. Might need a gtfs_url in the providers.csv file to track new operator IDs
   Yes, add a gtfs_api_url field to the MDS provider list
9. Operators would generate a unique device_id UUID, but can also use VIN, license plate, USDOT id, etc fields.
   This sounds good.

I added a new commit to the pull request finalizing a few changes discussed above.

• stop_sequence was added to Telemetry
• service_id was added to Events, Trips, Telemetry
• GTFS integration support was added to documentation in Events, Trips, Telemetry
• gtfs_api_url was added to providers.csv

Open questions:

• Should stop_sequence, route_id, service_id be in the base MDS objects so they can be used for more than one mode (eg, maybe for Delivery Robots too), or should they only be in the Passenger Services mode?
• Do stop_sequence, route_id, service_id need to all be in Events, Telemetry, and Trips?
• What role does MDS Stops play in this, if any?

Hi all,

After the OMF discussion, I will be reviewing the following updates to the pull request with the SFMTA team:

• removing stop_sequence from Trips, Telemetry
• adding stop_id_gtfs to Events
• adding supporting documentation for the gtfs_api_url field in providers.csv (the Adding an MDS Provider ID page)
• adding a gtfs_api_url field to Trips, Events for linking route_id, service_id, and stop_id_gtfs to the correct gtfs url

• adding stop_id_gtfs to Events

I think call this gtfs_stop_id, per some other MDS/CDS naming conventions.

• adding supporting documentation for the gtfs_api_url field in providers.csv (the Adding an MDS Provider ID page)

The gtfs_api_url field can be removed from providers.csv, thus reverting it back to the way it was. Instead adding it to Trips, Events would be enough. Operators can still add their name, website, UUID, and applicable mode to the file, but it doesn't make sense to add a single URL for GTFS.

Summary of changes I made from suggestions:

• removed stop_sequence from Trips, Telemetry
• added gtfs_stop_id to Events
• added shape_id to Trips
• removed gtfs_api_url column in providers.csv
• added a gtfs_api_url field to Trips, Events for linking route_id, shape_id, service_id, and gtfs_stop_id to the correct gtfs url

I have not been involved in the development of MDS over the past few years, but back in 2020 I was collaborating with Ellis & Associates / Lacuna Tech. on a proposal to add fixed-route service to MDS for LADOT (my company manages the fixed route dispatch software and GTFS/GTFS-RT for LADOT). It never really got off the ground, but I'm going to share the notes of where we had progressed to.

I'm not proposing or advocating for anything here, simply sharing for your information. Do keep in mind that this was based on the state of the spec in 2020 and may include assumptions that are well out of date today.
mds_fixed_route.md

Summary of changes I made after discussion with SFMTA team on matching MDS to GTFS format:

• Clarified definitions of route_id, service_id in Trips, Telemetry, Events to match GTFS route-trip schedule format
• Added gtfs_trip_id to Trips, Telemetry, Events
• Removed gtfs_stop_id from Events; MDS existing stop_id field will be used instead

1. Shouldn’t the gtfs_shape_id in MDS Trips for the shapes.txt file be discoverable via the associated route_id, service_id, and trip_id in the GTFS trips.txt file? If so the `gtfs_shape_id' field in MDS Trips is not needed.

2. For the MDS Events stop_sequence field, are these be the same as the GTFS stop_sequence field in stop_times.txt, and should we reference that in the description with a link?

   • Is stop sequence even needed here, and instead use the stop_id field from GTFS (which includes the expected sequence). Even if there is an unexpected stop, the stop sequence can be determined by timestamps in MDS events or telemetry.

3. MDS Events has a trip_ids field to connect to MDS Trips. Can gtfs_route_id, gtfs_service_id, and gtfs_trip_id just be cross referenced via the trip id in MDS Trips? Even if a bus is not on a trip, then referencing GTFS trip info won’t be needed or possible anyway.

4. MDS Telemetry has a trip_ids field to connect to MDS Trips, so can gtfs_route_id, gtfs_service_id, and gtfs_trip_id just be cross referenced via the trip id? Similar to item 3 above.

5. Do MDS Events and MDS Telemetry need a gtfs_api_url field, if they happen when they are not on a GTFS trip? If on a GTFS trip, can it just reference this gtfs_api_url field in MDS Trips via trip_id?

6. MDS Telemetry and MDS Events each have their own timestamp and location fields built in. MDS Telemetry has an MDS stop_id field to reference MDS Stops, and Events has a new GTFS stop_sequence field. But shouldn’t Telemetry and Events have a stops.txt GTFS gtfs_stop_id field to know when the bus stopped at a scheduled GTFS stop along the route?

7. What is the need ofgtfs_service_id in MDS Trips? service_id in GTFS connects to the calendar.txt file, which only are used to "define exceptions to the default service patterns." I may be missing a use case here.

8. In MDS Trips, gtfs_route_id references a route_id in GTFS, but this ID is already part of the trips.txt field that is referenceable via the gtfs_trip_id field. So it may not be needed to be duplicated here.

Let me see if I can summarize all of this.

MDS Events

Current:

• stop_sequence
• gtfs_route_id
• gtfs_service_id
• gtfs_trip_id
• gtfs_api_url

Proposed:

• gtfs_stop_id
• use trip_ids to make GTFS field connections

MDS Telemetry

Current:

• gtfs_route_id
• gtfs_service_id
• gtfs_trip_id

Proposed:

• gtfs_stop_id
• use trip_ids to make GTFS field connections

MDS Trips

Current:

• gtfs_route_id
• gtfs_service_id
• gtfs_shape_id
• gtfs_trip_id
• gtfs_api_url

Proposed:

• gtfs_trip_id
• gtfs_api_url

I may have to turn the proposed fields into a diagram to show the connections between MDS objects and GTFS too, because this is tricky to follow otherwise!

Hi @schnuerle,

We reviewed within SFMTA and agreed with most of your proposal. I will update the pull request with the below.

MDS Events

• remove gtfs_route_id, gtfs_trip_id, gtfs_service_id, gtfs_api_url; These can all be found by linking to MDS trips with MDS trip_id.
• remove stop_sequence; We can get this information ourselves using the stop_id and timestamp fields for each MDS trip_id so this field doesn't need to be part of the spec

MDS Telemetry

• remove gtfs_route_id, gtfs_trip_id, gtfs_service_id; These can all be found by linking to MDS trips with MDS trip_id.

MDS Trips

• remove gtfs_route_id, gtfs_service_id, gtfs_shape_id; These can all be found by linking to GTFS trips with GTFS trip_id and the GTFS API URL.

The remaining issue is gtfs_stop_id in MDS Events and MDS Telemetry. Since SFMTA is planning to use MDS stop_id here, we don't need a gtfs_stop_id field. I won't add it back to the pull request for now, but if you want to add it back as an optional field that other jurisdictions can use that works. Let me know and I will update the pull request to have it as optional.

Thank you looks great and is much simpler!

For gtfs_stop_id in MDS Events and MDS Telemetry, I feel like that is what SFMTA (and others) should use, instead of MDS' stop_id.

MDS stop_id is a UUID, and explicitly references the Stops object, so it would not work as the stop identifier in GTFS that you would be interested in knowing about for Events and Telemetry.

@schnuerle The plan is for SFMTA to actually put all our stops into MDS Stops endpoint and use those, but I will add back in gtfs_stop_id to Events, Telemetry as an optional field in case another jurisdiction wants to use it or SFMTA decides to use it in the future.

Thank you Matt, that makes sense to both have it there to connect to GTFS data, or use MDS Stops.

How are you planning on creating each stop for each route for each operator using MDS Stops? Are all the data fields you need for that in MDS Stops already? Anything else you'd need to support this?

@schnuerle All the operators use the same stops since they are determined by our commuter shuttle stop map so we just made an MDS Stops endpoint that references these stops. We are using the short_name field to write in the stop numbers and have UUIDs for each stop. Right now, the only missing field is there is no regular MDS stop_id field in MDS Events like there is in MDS Telemetry. Do you know the reasoning behind this?

Ok that makes sense for your use of MDS Stops. And I think it's good to add back gtfs_stop_id.

I am not 100% on the reasoning why MDS stop_id is in Telemetry, but not Events. I think it should be added as optional to Events too. You or I can add that as part of this pull request, and look for feedback from the working group on this.

Hi @schnuerle Sorry for the late reply, I have updated the PR one last time by putting MDS stop_id into MDS Events with the same language found in MDS Telemetry.

Hi @schnuerle I wanted to update you that I am planning to leave SFMTA at the end of this week and go to a new position elsewhere. If it's possible to get this pull request merged by the end of the week that would be great. I do feel that it's been thoroughly reviewed and it's ready for merge with the dev branch. If not, the Github handles for the rest of the SFMTA team are: @Mu-yi-Zhou, @monachiu, and @alexdemisch. Please contact them for additional questions on the pull request.

Hi @matthewmarwedel yes, agree it can be pushed to dev. We had a recap at the last working group meeting (see link for slide and recording) about the status of it and gave people another full week to comment. So I will review and push to dev. Thanks for your work and good luck in your new endeavor!

Hi @schnuerle, one issue that's come up with our data providers who manage GTFS files is that MDS gtfs_trip_id requires a UUID while GTFS doesn't.

https://github.com/openmobilityfoundation/mobility-data-specification/blob/dev/data-types.md#trips
gtfs_trip_id | UUID | Required if Applicable | A unique trip ID for the associated scheduled GTFS route-trip. Matches GTFS trip_id in the trips.txt and other files.

https://github.com/google/transit/blob/master/gtfs/spec/en/reference.md#tripstxt
trip_id | Unique ID | Required | Identifies a trip.

There doesn't seem to be overwhelming support within the GTFS community to update their standard to start restricting their trip_id Unique IDs to UUID:
google/transit#518

Since this needs to match GTFS trip_id, shouldn't we update MDS gtfs_trip_id type to be a string instead of UUID?

@ericyco You are absolutely right, I can't believe I didn't see that sooner. It should be a string to keep it generic enough. I'll update.

@ericyco take a look and check my work if you can, for the updates here at PR #937.

@schnuerle looks great, thanks for the quick update on both gtfs_trip_id and gtfs_stop_id!

Alright, merged to dev now, thanks for the catch!