MDS Working Group

• Weekly Thursday 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)

Note: We are now collecting attendees upon entry into the Zoom meeting. An attendee count will be posted here after the meeting:

26 Attendees

Main Topics

• Requirements Preview and deep dive
  • #608, PR #646 - New endpoint in Policy for agencies to describe program requirements digitally to allow operators and the public to see what MDS and GBFS versions, APIs, endpoints, and fields are required.
  • We will give an introductory presentation about this forthcoming feature, and take your questions.
  • Note this meeting will be recorded and posted for anyone to view later.

WGSC Meeting Organizers

• Host: Michael Schnuerle
• Facilitator: Jascha Franklin-Hodge
• Outreach: Michael Schnuerle
• Note taker: Jean Kao

Resources

• Slides
• Meeting Recording - Passcode: wT6G7g^t

Action Items

• Generally positive feedback for this feature! Please leave your positive thoughts (or comments, negative thoughts) on this Issue #608 so we can catalog and reference them and finish this feature for MDS 1.2.
• Create new issue about how to add cap counting, other metrics, and how they are calculated in Reqs for a future release. Lime could open this issue, or someone else who has thoughts on this idea.
• Resolve question about using 'null' for disallowed items. Comment in PR, reference Google example
• For Provider Reports, look at what other things could be added, per Lime's suggestion.

Notes

Michael presented overview of Policy Requirements

• City Permit Requirements review
• v1.2.0 new APIs and endpoints - 1 new one only: requirements
• Policy Requirements overview
• Parts of Requirements
• Examples
• Reasons to Have Disallowed Items
• Important Notes
• Supplemental Support/Additions
• Future Additions
• Questions

Discussion William Henderson (RideReport): Did we discuss using null instead of dropping values for disallowed fields?

• creates ambiguity because sometimes fields are null
• recommends Google style guide
• could have a special value that’s omitted
• don’t have great recommendation
• will leave comment in GitHub MS: discussed briefly, open for discussion
• this feature is meant to be nonbreaking release so we have to be careful
• having structure better than removing entirely
• null can signify that it's on purpose
• will leave comment in GitHub

Brandon Haydu (Lime): generally excited by this, will be helpful

• could this be a good place to put in description of count methodology, helpful for providers to have clarity on this
• lots of cities ask for CSV reports, is there a way to outline those, way for cities to publish what fields they’re requesting outside of MDS MS:
• re: methodology, great idea but maybe future idea - can use Metrics now which has this build in. Not sure how to implement it within Reqs
• re: other city data - recommends using Reports endpoint (https://github.com/openmobilityfoundation/mobility-data-specification/tree/ms-requirements/provider#reports---response), better to enhance this feature than to add reports to Policies API

Sanjiv Nanda (SANDAG): Michael, what is an example of a use case? You mentioned that a use case helps transparency and I wanted to understand that. Thanks. MS: see What’s Possible with MDS? (https://www.openmobilityfoundation.org/whats-possible-with-mds/) that contains link to Airtable of use cases. These 50 or so use cases could be added to and given a unique identifier to reference. This is good for GDPR, and any other use case list made by a city, provider, non-profit, data spec, etc.

Emmett McKinney (Superpedestrian): reduces uncertainty so useful for them MS: as a provider is this difficult to support? EM: difficulty is the same as any proliferation of parallel standards, certainly worth it to support, another difficulty could be version control and completeness - new schema. Still helps to recompute responses, as described in a previous MDS release.

MS: as initial requestor (https://github.com/openmobilityfoundation/mobility-data-specification/issues/608) what does RideReport think WH: all initial use cases are served by these requirements

• one thing that’s underlying this issue and motivating, re: GDPR the more explicit an agency can be the better to minimize data from a privacy/compliance perspective in the international landscape this is a huge step forward
• one potential improvement is allowing operators to see ahead of time what’s required allows for efficiencies via precompute vs autogenerating

Alex Demisch (SFMTA): this is helpful, will be more valuable as modes gets built out

JF: Great work Michael!

OMF Announcements

• Leave your feedback on #608

New Attendees

• N/A