Web conference notes, 2021.11.10 (MDS Working Group)
MDS Working Group
- Every other Thursday at 9am PT / 12pm ET / 6pm CET
- This meeting is on a WEDNESDAY
Zoom Registration Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4
One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York) - though we encourage Zoom
Note: Attendees register upon entry into the Zoom meeting. An attendee count will be posted here after the meeting.
32 Attendees
Main Topics
- Release of MDS 1.2! - Michael Schnuerle, OMF
- Policy API - E&A, Marie Maxham
- Use cases cities need to support when digitally defining their policy using the MDS Policy API
- Populus - Jean Kao - discuss use case doc
- Bird - Ben Handzo - discuss example spreadsheet, ask for public feed URLs
- What use cases are being supported now (in doc) and which are not being supported yet (in open issues)
- How this impacts interpretation by providers
- If you are producing or consuming Policy now, we certainly want to hear your experiences.
- Is there need for on-trip policies? Or does trip start/end cover these?
- How is the current immutability of trips working for Policy users? Is there a better/different way?
- Use cases cities need to support when digitally defining their policy using the MDS Policy API
- Prework:
- Policy Use Case document OMF MDS 2.0 Policy Use Cases
- Includes list of any public Policy APIs - add yours!
- Discussion area for your feedback here
- Policy Use Case document OMF MDS 2.0 Policy Use Cases
WGSC Meeting Organizers
- Host: Marie Maxham, E&A
- Facilitator: Ben Handzo, Bird
- Announcements: Sebastien Berthaud, Blue Systems
- Outreach: Michael Schnuerle, OMF
- Note taker: Jean Kao, Populus
- MS: add relevant use cases from database to Policy use case doc - Done, see Publish Event Areas and Emergency Guidance
- MS: add new issue to Github about aligning CDS and MDS more - Done, see issue in CDS
- Everyone: add links to public Policy URLs, or copies of content from private Policy URLs in the document
- Everyone: contribute use cases and comments in the use case document
- Everyone: Leave feedback in discussion area
- Everyone: Comment on open issues or open your own issue about Policy
Goals
- where is it working or not working now
- simplify AND expand
Real world issues in current policy examples
- Null is being used, which is allowed, but maybe bad. But Null means you don’t care what the value is - not clear in spec.
- Different rule units, seconds vs count, can cause complecity
- Pick a unit for speed and stick with it. Meters per second is hard. Why not just use km/hr?
- Fees for time are more common
City Policy Examples
- requirements with complex polygons can be very difficult to digitally implement
- example: # vehicles per block face has a polygon for every block face
- example: required parking corrals can be very small (and many) polygons as cutouts
- are hyper complex polygons may not need to be part of our data model - could require complexity threshold
- historically used geojson because this tooling widely used and available but doesn’t work for everything, like curbs. Doesn't support points and radius directly.
- cap on geography complexity
- chunking geography
- reconsider data models
- consider policy inverse if simpler, for example required parking vs no parking
- requirements that apply to many polygons can also be unclear if it’s for each polygon or across the aggregate of polygons
- many to many relationship between policies and geographies may be needed
- example: Baltimore equity zone, is the min per zone or for all zones altogether
- example: also applies to parking corrals
- need to be able to support more complex trip fees
- example: LADOT wants different fees depending on the start and/or end of the trip
- Fees based on both start and end locations. Or cents per mile traveled, like VMT (see proposed issue #722 about adding more data to trips in Agency)
- Two ways to address this: multi-event policies, or/and adding more metadata or event types
- Leaning toward the latter. And it has clear tie-ins to multi-modal support
- combination of multiple events + metadata
- helpful to get smaller chunk of geographies in request using pagination
- helpful to allow querying of geographies like other MDS endpoints to reduce file size.
- how can we allow flexibility to model policies while creating sensible defaults?
- Policy should be a translation layer that takes city policies and turns them into something that’s consumable and implementable (digitally) by operators (hear, hear, all agree)
- might be useful to have a template to define a use case, to help standardize them in some way
Future note
- Allow google, Waze, etc consume policy, note about work zone data exchange and welcome cities and companies in for a discussion, part of a larger conversation
Policy API Use Cases
- clarity around using null
- null means ignoring field and moving on to look for other fields
- example: max = null is okay as long as min is specified
- do we need a tool that helps translate Policy APIs as written to see if they make sense?
- we don’t have access to Policy APIs that aren’t public
- Mobility Data is discussing a GBFS validator
- MDS repo has a compliance engine that can be used for certain types of validation
- taking policies and having them ingested into what the world should look like, less like schema and more like rules engine
- how will Policy be extended to new modes?
- any changes to policy have to contemplate new modes coming picture
- wide lens to evolve policy that don’t constrain it for what’s coming down the pipe
- Policy API issues can be worked out in issues, real meat is in the city examples of policies and being able to clarify how we’re going to express city needs in a way that makes sense
Using Policy API for consumer-facing apps
- JE: LADOT encouraging Google and Waze to start ingesting MDS
- JFH concerns about policy being used to convey operations to operator also at the same time as a tool conveying street closures to public, two distinct use cases, underlying data for MDS not intended to be public facing
