Joint Working Group - Provider Services

• Every other week call at 9am PT / 12pm ET / 6pm CET

Meeting ID: 841 7098 9462 - Passcode 612987
https://us02web.zoom.us/j/84170989462?pwd=WTRlY25wOVhNeS8wQk1iM2QzYkQvUT09

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Add your own name, link, and organization during call

• Michael Schnuerle, OMF
• Steve Brining, Blue Systems
• William Henderson, Ride Report
• Matt Davis, Populus
• Neil Goldader, E&A
• Sebastien Berthaud, Blue Systems
• 21 attendees

Main Topics

1. Retrieve operational zones from operators #639
2. Followup on updates to Requirements endpoint: url security, boolean values, modes, metadata - #608

WGSC Meeting Organizers

• Host: Michael Schnuerle
• Facilitator: Steve Brining
• Outreach: Michael Schnuerle
• Note taker: Joseph Yawn

1. Introduction

   1. No new attendees for introductions

2. Retrieve operational zones from operators #639

   1. We have a way to do this through Policy API, if agencies are using Policy, but we don’t have a method for providers to send back their operational zones through an API.

   2. General feedback of adding to MDS would be a new field in Trips with a GeoJSON. Some concerns about adding a new endpoint.

   3. Alex from San Francisco mentioned in early comments that he would like to see this but come through GBFS instead.

      1. Mitch confirmed that geofencing zones are in GBFS and could be done.

   4. So should we use MDS and communicate this through Policy API or use GBFS for this. Conversation for today’s meeting continues below.

      1. William supports this idea (using GBFS). It is good practice to use what’s already available. MDS could tap into requirements API and make GBFS a part of that. This simply gives us another use case for incorporating GBFS in requirements API.

      2. William: There are definitely cities that would benefit from this (overall how GBFS fits into the regulatory framework). The thing that stands out specifically about this issue, is there are cities who have chosen not to set specific zones but leaves it up to the operators. Cities do still need this for planning purposes. This is specific use case will provide a good start to a larger conversation on GBFS in the regulatory landscape.

      3. William curious if any of the originating Vianova folks have any thoughts.

         1. GBFS proposal is preferred.
         2. Another question that ties into this is the requirements of operating data alongside of operating zones.

      4. Emmett: Effective date for zones (pull request in GBFS) would be useful for reporting purposes.

         1. There is a date time field in GBFS, but not specific hourly time.

         2. Are zones (effective date and time) set by cities or operators?

            1. Usually by cities (i.e. operate until 9 pm)
            2. But, there are some instances where an operator may want to set specific zones that users cannot operate in (i.e. no ride zones)
            3. If this is coming from the city, why not communicate this through the Policy API?
            4. There are lots of overlap between Policy API and GBFS Operation zones and perhaps some alignment that can happen with this.

         3. Marie: Is this about continue to require GBFS but not actually modify MDS?

            1. Yes, continue to require GBFS, but also enumerate which GBFS endpoints are required from the optional ones.

         4. Any operators resistant to publishing this through GBFS?

            1. No comment from operators.

         5. Any third party aggregators or cities that use this GBFS feature?

            1. William: we would use this, provides opportunities to check zones against policy.
            2. Populous: Don’t use it right now but would be interesting to include it.

3. Follow-up on updates to Requirements Endpoint: URL security, Boolean values, modes, metadata - #608

   1. Comments since last meeting:

      1. Lots of examples that were added, updates based on convesations.

   2. Open issues:

      1. Should endpoint URL be included in the requirements API?

         1. Example, policy url is included in requirements API.

         2. What is the purpose of including the URL?

            1. Knowing what the root URL is, which is already published in providers CSV file, will help clarify how you get to the API endpoint. Essentially to make this more discoverable.

            2. There is not MDS specifications on how these URLs should be structured. Lots of variations in URL.

               1. Would be nice if they are consistent, but conversation for another day.

            3. Trips endpoint in Provider API does not list URL, but exploring putting this in Requirements API.

               1. This could create back and forth between operator and city.

               2. Making URL’s consistent would make this easier, but not the case today, so other options is to require provider publish requirements API and match manifest.

                  1. Like idea of the manifest file.
                  2. We couldn’t develop this and have it ready for next MDS release but could start working on it now.
                  3. We could also give recommended URL structures for future, but would need to be in next major change since it is a breaking release.
                  4. In the meantime, it may be good to include URL in Trip Endpoint Names.

               3. Simple thing would be not to include URLS here, but endpoints themselves.

                  1. This is really important, but maybe should be included in next releases.
                  2. We would only put URLs in what the agency is publishing.
                  3. Leave the manifest open for discussions for next releases.
                  4. Want to make sure that we are clear on what URLs to consume so that people are not left to interpret the requirements.

         3. GBFS Required:

            1. Would have to specify version along with optional endpoints.

            2. Would be nice if there is one generic structure for API requirement for GBFS and MDS to avoid confusion.

               1. I.E., required MDS API and GBFS API.
               2. Specific examples on Geography Driven Events.

            3. Open Comments Policy Requirements #646:

               1. Why not have Boolean fields in MDS.

                  1. Do not require that in MDS fields, so this would be first.

               2. SLA requirements could come in here.

                  1. Maybe expected latency fields.
                  2. Mode definition could apply to provider or different MDS versions.
                  3. OMF validators to include in this version?

Decisions/Action Items

• For Requirements, only put agency published URLs in file.
• In Requirements, maybe split provider and agency APIs since they have different definitions (required_integrations vs required_endpoints).
• Add GBFS optional endpoint list and version in MDS Requirements endpoint. Maybe split into its own section within API outside of metadata.
• Use true/false for boolean values in MDS.
• Everyone leave comments on other PR discussions around SLA, latency, modes, feed validators.
• Future discussion about how MDS URLs are structured, and recommendations/requirements from MDS around the format of these. Major release.
• Future discussion of a Manifest file for providers, including operating area, urls, other details. Minor release.

New Attendees N/A