Web conference notes, 2025.03.13 (MDS Working Group)
- Monthly on Thursday at 9am PT, 12pm ET, 5/6pm CET - open to the public
-
Zoom Registration and Join Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4
- One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)
- Signup to the Mailing List for emails and calendar invites
MDS Real Time Policy Improvements
While MDS Policy can be real-time if required by the city 1) the spec doesn't explicitly say this and 2) there is not a good way to get the latest policy because the entire policy has to be downloaded to be checked for an update.
- Intro and announcements (10 min)
- Fixed Route Services #927 Recap (5 mins)
- MDS Real Time Policy Improvements
- Real-time improvements for MDS Policy (20 mins) - Discussions:
- Discussion/Comments (20 mins)
WGSC Meeting Organizers
- Host: Pierre Bouffort, Blue Systems
- Facilitator: Michael Schnuerle, OMF
- Preparation: Michael Schnuerle, OMF
- Outreach: Michael Schnuerle, OMF
- Note taker: Michael Schnuerle, OMF
- Review and leave feedback on Policy real-time updates in PR #928
- Fixed Route Services has been pushed to "dev" branch as part of draft MDS 2.1 Release. See #927
- Any feedback on OMF member voting process for new MDS WGSC members
- New MDS WGSC members elected, see new roster
- 41 Attendees
- OMF Slides
-
Recording - Password
T#G5W4va
Announcements
MDS Steering Committee vote by OMF members and WG Contributors
- email vote, requirements to vote, one vote per member org, GitHub account required
- following bylaws to a tee, looking for feedback, possibly refine bylaws later if needed with board
- 9 total members
OMF Events
- Settle Open Mobility Mixer
- Webinar for Curb Policy Regulations next week, resource paper will be released
- Boston, Curbivore, CoMotion Miami, IPMI, NACTO, etc
- All up to date OMF Events: https://www.openmobilityfoundation.org/2025-calendar/
Fixed Route status
Fixed Route Services #927
- Open for review for the next two weeks, read and leave your comments
- Published to
devbranch after that
Real Time MDS Policy
MDS has from the beginning already has had real time policy
- During years of implementing, we have suggestions for improvements, efficiencies, file sizes
MDS Policy overview
- 67 known jurisdictions around the world publish MDS Policy data feeds
- Dozens of operators consume digital policy from these cities
- Many vendors help cities create these feeds, or help operators ingest the feeds
- Recent MDS Policy Projects:
- Seattle’s real-time 911 for AVs
- LADOT’s large events for AVs
- World Cup cities
Real Time Policy improvements
Open Issue #906 from May, and Pull Request #928
Currently includes the following changes:
- Real-time language clarification and examples
- Noting that agencies may manage their public Policy feeds, for example with an API key
- Policy uniqueness note to prevent identical policy duplication
- last_updated parameter to return only the last updated date
- active_only parameter to return only current, active policies
- A Policy object relationship diagram.
To possibly come in future PRs:
- Additional relevant policy examples
- A push endpoint option
- A new Message/Notification/Communication endpoint/API
- Adding a max_update_interval field like in Requirements to note how frequently the file may update
Review each change
Non breaking changes
Real-time language clarification and examples
- Added more use cases in top description
- Adding more real time language in background area
Noting that agencies may manage their public Policy feeds, for example with an API key
- language about how vendors can manage their API feeds
- Helps with preventing unintentional abuse of data feeds
- Communicate a recommended refresh rate of your feed by email
Policy uniqueness note to prevent identical policy duplication
- Ensure policies are not duplicated in the policy file
last_updated parameter to return only the last updated date
- returns only the version and the last updated timestamp
- very small file 1/4 of a kilobyte
- NOTE: add example of this file from PR, see Schema section
active_only parameter to return only current, active policies
- New option to shrink file size
A Policy object relationship diagram.
- Diagram in Mermaid code, auto generated
- May need cleanup, how useful is this?
- Maybe text instead of diagram, or image instead of Mermaid?
- 2 comments saying this is useful
Future larger Policy changes
Additional relevant policy examples
- probably move examples to an external file and link to it
- add more real time examples and ones using
Adding a max_update_interval field like in Requirements to note how frequently the file may update
- iso code for refresh interval, like in MDS Requirements
- like idea, if optional
- might be problematic since Policy has a legal expectation, compliance, liability
- What is the usability of this in practice? If it's once a month, so that's the poll, but the city decides to update it in 2 weeks, then the operators don't check.
- Understand it's meant to be indicational, but not much of MDS Policy is indicational, more rules and requirements
A push endpoint option
- Instead of just pull, add a push endpoint option like we do with MDS Agency/Provider
- Only changes go out in chunks to operator, small file sizes, only when there is an update
A new Message/Notification/Communication endpoint/API
- proposed in Pierre comment
- communicate things that might normally come through in an email or text or call from city to operator
- Policy limitation is it's only regulation and policies, not just info
- Policy limitation is it's only a pull, not a push, when you want to check for updates, does not change most of the time
- Idea of a new API for city to push data to operators. Rely on existing APIs, not messenger, not email, not redo Policy, but let them know there is a change, go look it up in Policy/311/etc
- Raquel from Phoenix: motorcade issues, private info, push to AV operators, but not beyond that
- Idea is this would be private, not public
- MDS Policy, could it be private, private feeds to operators, maybe keep Policy general so it's not a public motorcade, but info on general geofence
- Resource consumption of endpoints is resource intensive, worse if public.
- Different levels of security, API key access, still public. Maybe another level with handshake key
- Could have public and private Policy endpoints? Which ones to check
- Salvador LADOT - interested in Notification system. LA Marathon example, efficient comm like this. Still updating Policy feed, but want to let them know there is a change
Everyone leave your comments in issue and pull request.
Pierre and staff may add new ideas. Others may as well. Will revisit and discuss more later.
Michael Schnuerle (OMF) 11:43 Up to date OMF Events: https://www.openmobilityfoundation.org/2025-calendar/
Agenda for today if you want to follow along: https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2025.03.13-(MDS-Working-Group)
Deb Gangopadhyay (Beam Mobility) 15:27 Hello, I’m Deb Gangopadhyay, Co-founder and President of Beam Mobility, a shared micromobility operator for standing e-scooters, e-bikes and e-mopeds with services across Asia Pacific across (North Asia (Korea), Oceania (Australia/New Zealand), South East Asia (Indonesia, Malaysia)) and, recently, in the U.S. where we just launched in Albuquerque and Tulsa. Very nice to meet everyone! I’m always happy to chat - feel free to reach out at [email protected]. My background is in shared micromobility where I have been working the last 7 years, and I’m keen to work wit this group to help improve openness and collaboration between cities and operators for micromobility and to learn more about the initiatives of the OMF that I’m not as familiar with.
Michael Schnuerle (OMF) 16:49 Fixed Route https://github.com/openmobilityfoundation/mobility-data-specification/pull/927
Suresh Lokiah 18:35 Joining for the 1st time here, is the prev meeting recorded
To learn about the background for this change
Or the requirements
Michael Schnuerle (OMF) 19:38 Here is the recording and notes from last meeting. https://github.com/openmobilityfoundation/mobility-data-specification/wiki/Web-conference-notes,-2025.02.13-(MDS-Working-Group)
Suresh Lokiah 19:44 TY
Matt Thrasher (Waymo) 22:13 Hello, I am a Product Manager at Waymo. I am excited to join this group! I am here to facilitate Waymo’s participation in OMF from a technical and product perspective. Great to meet you all.
Michael Schnuerle (OMF) 27:04 Link to real time policy PR https://github.com/openmobilityfoundation/mobility-data-specification/pull/928
Gene Leynes | Chicago 35:11 I think it's useful.
Alex Demisch SFMTA 35:32 agreed - doesn't hurt to see the relationships visually
Gene Leynes | Chicago 35:33 I think the ED is important and should be expanded.
Gene Leynes | Chicago 39:05 Gene Leynes - City of Chicago
I previously worked on / led smart city and data science initiatives for the city, collaborating closely with transportation and other departments. Following our IT restructuring last year, I landed into an Enterprise Architect role, where I've been focused on AI/GenAI policy development.
I became an Open Mobility Foundation MDS Steering Committee member in 2024. Also, I strongly support the OMF/GitHub "policy as code" approach.
Deb Gangopadhyay (Beam Mobility) 47:35 Agree on making the field optional - that allows for usage that’s urgent at the risk of some confusion until there’s a new major version that supports a push architecture, which may be better for the long-term mechanism with less timing confusion.
Michael Schnuerle (OMF) 47:44 Push notification https://github.com/openmobilityfoundation/mobility-data-specification/issues/906#issuecomment-2688934169
Michael Schnuerle (OMF) 52:17 Could have just a few fields. Required: Description, date/time. Optional fields like: policy id, geography id, external reference id (311 request Id, permit, etc), URL, vehicle id
Deb Gangopadhyay (Beam Mobility) 01:01:06 Maybe different keys can limit information accessed. Ex. If there is operator specific policy that should only be shared with that operator, an operator specific key can be used, and the policy would have some indication that the policy is only exposed to that operator.
Alex Demisch SFMTA 01:01:09 I really like this idea of a push Policy API. Agree that we'll need to think through intended audiences and authentication. In our Stage 2 SMART application (which we didn't get), we included the idea of communicating emergency response avoid the area (ATA) zones via MDS policy. It also got me thinking about this as a way for City departments to communicate more efficiently, e.g., SFMTA is a transit operator and we're only notified of ATAs via phone calls
Rachel Castignoli - Austin, TX 01:01:46 @Salvador Gutierrez (LADOT) we had an issue at the Austin marathon a few weeks ago setting up cones at 3 am. So maybe ask for extra time more than the stop time in your TCP
Thank you Michael & Pierre
