Joint MDS Working Group

• Every 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)

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

19 Attendees

Main Topics

• Policy Requirements - PR #646, Issue #608
  • Note updates from last meeting
  • Is all of Requirements a breaking change as is written?
    • Yes since if agencies can now require specific optional fields, providers may not have support for these fields in previous 1.0 or 1.1 MDS versions
    • Can mitigate by clarifying that while in beta, required things are just requested for now, but will be required in the next major release.
  • Discuss the concept of 'disallowing' specified endpoints and required fields
    • What are the benefits and real-world use cases of this for agencies?
    • What are the repercussions of this if implemented?
    • Does this place a burden on providers to implement by removing fields that have always been required?
    • Example for discussion

WGSC Meeting Organizers

• Host: Steve Brining
• Facilitator: Michael Schnuerle
• Outreach: Michael Schnuerle
• Note taker: Jean Kao

Action Items

1. MS to clarify by renaming "Agency Requirements" to “Agency Program Requirements” (DONE)
2. each beta feature should get its own Issue for discussion, like Vehicles and Stops have (DONE - see new Issues and beta Label)
3. Agreed that disallowed APIs don't make sense. Certainly fields do, open discussion about how to implement endpoints.
4. create wording around how cities can use Requirements endpoints to require data from providers - see discussion
5. legal/audit conversation around disallowing endpoints - see discussion
6. get feedback from providers about "disallowed" concept since this is harder for them than other things, and on required fields/endpoints too, since there were no representatives on the call - see discussion
7. William H to start a discussion in the repo about getting trip start/end point data
8. Neil G to make an issue about SLAs in Reqs

Note on updates from last meeting

• See link above in agenda for list of updates

Agency Requirements Repo*

• OMF hosted optional area for Agency Requirements
  • discussion: the term “agency” could be confusing as is because it can mean different things in different MDS contexts
  • action item: MS to clarify by renaming to “agency program requirements” or something similar (DONE)

Is all of Requirements a breaking change as-is written?

• background: a new Requirements endpoint under the Policy API that allows agencies to digitally express only the data they need for their jurisdiction and operating permit.
• discussion:
  • want to be careful about what’s considered a breaking vs nonbreaking change
  • nonbreaking changes are not just about code but also about downstream impacts
  • what does it mean for providers to be “MDS compliant” in regards to optional fields (is it optional for providers, or optional for agencies to require)?
  • Should “MDS compliant” only apply to non-beta endpoints?
  • so how do beta endpoints required by cities fit into this
  • we need to find a way to support city needs, which sometimes include MDS beta endpoints
  • We want to encourage beta usage as written, but cities could chose to implement it differently and bring that feedback to the WG
• action item: general to MDS, each beta feature should get its own Issue for discussion, like Vehicles and Stops have.
• action item: add wording around how cities can use Requirements endpoint to require data from providers

Discuss the concept of 'disallowing' specified endpoints and required fields

• differences in endpoints vs fields in that endpoints are binary - either provided/requested or not (eg, MDS as a kit-of-parts), while fields can be optional
• fields can be required or disallowed, but if not specified in either they would be in a third state: required, disallowed, and up to provider
  • for endpoints instead of disallowing could flip this around to say only need to provide what’s requested, anything not requested is implicitly not to be provided nor to be given access to
  • some endpoints have more privacy issues so cities may want to be explicit in disallowing to avoid exposure
  • however, in MDS endpoints aren’t “required” what does it mean for a city to “disallow” an endpoint that isn’t really required in the first place?
  • there are a lot of abuses of MDS spec so maybe we should have required and allowed endpoints
  • “disallowing” fields makes more sense since fields are explicitly required or optional, and cities may want to “disallow” a required field
  • real world example: using Trips Endpoint just require O/D but not route geometry (see below)
• action items:
  • need to have a legal/audit conversation around disallowing endpoints
  • need to get feedback from providers since this is harder for them than other things and there are no representatives on the call

Trips endpoint “hack” wrt "disallowed" fields

• use cases:
  • SFMTA using MDS for scooters, bike, moped data but they have different permit authorities and the city is interested in different data for them
    • scooters and bikes have similar permits as they use the same city infrastructure
    • mopeds operate under a parking permit because they more like automobiles and so the city isn’t interested in route information since it’s just a small percentage of street usage (and they don’t use bike infrastructure) but the city does want start/end point data because of parking
    • SFMTA using Trips endpoint to request start/end point data from moped providers because they already have a data pipeline to analyze O/D data but have “disallowed” the rest of the route geometry
    • DDOT’s moped program is still in pilot so haven’t yet required data but see SFMTA’s point
    • moped permit is cross between bike permit and car sharing permit so parking is an issue
    • tried tracking parking usage with their car share program but it was too complicated so don’t see trying again with mopeds
  • is this a common use case?
  • if so should discuss a way to better support cities in getting trip start/end points by adding fields instead of excluding them, ideas include:
    • cities can use trip_ID in status changes to get this data without “disallowing” fields but then cities would need to set up a new O/D data process
    • Could add properties to the route GeoJSON that describe a point (start, on trip, end) so start and end could only be returned and specified via Req endpoint - might be a breaking change
    • different forms of geospatial data could be returned (polygons, GDEs)
    • change accuracy (maybe a way to specify this in Req per endpoint/field/globally)
• action item: William H to start a Discussion in the repo

Requirements endpoint and SLAs

• discussion:
  • how could Requirements support route geometry to get accurate data?
  • SLAs could be a compelling use case for the Requirements endpoint
  • SLAs should be added in next release as it's a good idea but not time for this release
  • Could include other info like GPS accuracy of some/all points required by agency
  • Could include number of telemetry points per minute in a route
    • Vianova: some providers provide less than 6/m and don't follow rules in spec
    • but since it's already specified in spec to return all known points, city should talk to provider to be in compliance with MDS
• action item: Neil G to make an issue on SLAs in Reqs

New Attendees

N/A