Web conference notes, 2021.07.29 (Joint Working Group)

Web Conference

Joint MDS Working Group

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

Conference Call Info

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)

Attendees

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

19 Attendees

Agenda

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

Minutes

Note on updates from late meeting

• OMF hosted optional area for Agency Requirements
  • discussion: the term “agency” could be confusing because it can mean different things in different 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 endpoint Requirements 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”
  • “MDS compliant” should 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
• action item: create wording around how cities can use Requirements endpoint to require data from providers

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

• discussion:
  • differences in endpoints vs fields in that endpoints are binary - either provided or not - but fields have a third state - yes, no, and optional
  • 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:
  • would 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

• discussion:
  • 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
    • add start/end points explicitly in trips
    • drop routes
    • different forms of geospatial data
    • change accuracy
• action item: WH 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
• action item: NG to make an issue on SLAs

Action Items

• MS to clarify by renaming "Agency Requirements" to “Agency Program Requirements” or something similar (DONE)
• create wording around how cities can use Requirements endpoint to require data from providers
• legal/audit conversation around disallowing endpoints
• get feedback from providers about "disallowed" concept since this is harder for them than other things and there are no representatives on the call
• WH to start a discussion in the repo about getting trip start/end point data
• NG to make an issue about SLAs

New Attendees

...