Web conference notes, 2021.05.20 (Joint Working Group)

Web Conference, 2021.05.20

Joint Working Group - Provider Services

Every other 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

Add your own name, link, and organization during call

Michael Schnuerle, OMF
William Henderson, Ride Report
Matt Davis, Populus
Marie Maxham, E&A
Tijs de Kler, City of Amsterdam/CDS-M
19 attendees

Agenda

Main Topics

Requirements endpoint in Policy API
- Review the first draft of spec work on an in progress feature branch
- Pull Request #646 is the working area for specific suggestions and review.
- Based on draft work done in the City Requirements API document
- Relates to discussion in Issue #608
- This new public endpoint would be served by cities and allow them to clearly describe what data they are asking providers for (and what data they do not want) and could be referenced by city policy/permit documents for clarity and discovery.

WGSC Meeting Organizers

Host: Michael Schnuerle
Facilitator: ...
Outreach: Michael Schnuerle
Note taker: William Henderson

Minutes

Decisions

rename endpoints to required_endpoints, mds_apis=> required_apis
don't add required_if_available_fields or disallowed_fields to this PR. Clarify required come by default.
remove omf_review and omf_review_date fields. Open new issue to discuss in broader context
add start/end dating for each MDS API to allow past and future work. EG effective_date and end_date

Action Items

Michael to update style to have nested objects documented with a top level table that links to sections defining the sub-objects, like Geography
Michael to consider having Requirements API contain outdated and future requirements objects, in parallel to the way Policy endpoint does it.
Michael to add documentation suggesting a link to requirements file go in cities operating requirements
File new issue on the concept of OMF (or others like third parties) reviewing things
William Henderson to file issue on disallowed_fields/endpoints/apis future field
Clarify how you would specify how to use Geography Driven Events with the 'event_geographies' field requirement.

New Attendees

Zach Bouz from LADOT came. Usually participates in privacy committee, Requirements API came up there recently.
Also joined: Tijs de Kler, from the city of Amsterdam. Developer/technical guy, and involved in the European initiative for CDS-M (City Data Standard Mobility)

Discussion of #608 – Ability to express data sharing requirements

This new public endpoint would be served by cities and allow them to clearly describe what data they are asking providers for (and what data they do not want) and could be referenced by city policy/permit documents for clarity and discovery.
Michael walked us through the Working Draft document which contains a lot of context on why this API is needed and what it intends to do
PR is now live, Michael took us through it at a high level
- William: style thing – nested objects usually documented with a top level table that links to sections defining the sub-objects
- Emmett: how would this be versioned? how frequently updated?
  - Michael: increment version number, last_updated . Would get history if you use Github. There is some existing guidance on update frequency for Policy, might need to be updated some.
  - Michael: has also been some discussion around specifying an effective_date and end_date in metadata.
  - Alex: would be nice to be able to future-date it.
- Alex: any value to having historical info be queryable?
  - Michael: could be that old replaced requirements versions live in file and it grows
  - William: consistency between Policy and Requirements - use same mechanism for replacing old versions.
- Emmett: pointing folks to this resource. reference the requirements file in permits?
  - Michael: could suggest it go in operating requirements
- Emmett: Often see this idea of "required if available" in permits, should that be represented? For example, instantaneous feed over ground.
  - William: another example, GPS.altitude and heading are required if available
  - Michael: how to accomplish that?
  - William: could be new fields just like required fields,required_if_available_fields. Might also be helpful to have another field like disallowed_fields for an agency to be able to say "we don't want that, you can't share that"
    - John Ellis: example of cameras in sidewalk robots, allow cities to say "you can't share that"
    - Michael: maybe we do that later?
    - William: will file an issue on disallowed_fields as a future addition
- William: rename endpoints to required_endpoints
  - Michael: also mds_apis=> required_apis
- William: use case for omf_review field?
  - Michael: if Agency decides to make this file on their own and host it. They could do it, but they'd have to mark this as 'no'. When they ask for review, they get an Agency ID and we can make sure it makes sense. So it's two things:
    - way for agencies to feel more confident
    - to provide a better quality requirements feed to providers
  - Josh: one example here is having an API being publicly required
    - John: to that point Josh, the pattern - the MUTCD has all these patterns and they are signed off on by insurance-backed engineers. By suggesting this is only OMF it might be not be in the best interest. A concept of 'this has been reviewed' is sound, but is it only OMF?
    - William: plus one'd, larger conversation that warrants a separate issue and discussion
  - Josh: came out of generator discussion. we're still going to do our own review, it's not a rubber stamp but there is still so much copy-pasting of policies, this gives us some assurance and puts us on level-ground with cities.
    - John: to follow on, instead of OMF review, could create OMF-managed set of tool manufacturers who could be help find and fix issues. would be similar to how things are managed today, as the physical manifestation of policy. Tools are under contract to cities to create good policies that are compliant and accurate.