Web conference notes, 2026.05.07 (MDS Working Group)

• 00:05:27 Andrew Glass Hastings (OMF): Hello All! Welcome to this MDS Working Group!

• If you haven’t already go ahead and change your name to incluce your city, org or company. Click the 3 dots next to your name and click rename. This helps everyone better know who is on the call.

• 00:07:00 Mollie D'agostino Mollie D'agostino: Mollie Cohen D’Agostino

• Executive Director, UC Davis Mobility Science Automation and Inclusion Center (MOSAIC)

• Senior Policy Analyst, Institute of Transportation Studies at UC Davis

• 00:07:01 Becky Edmonds, Seattle DOT: Becky Edmonds, Seattle Department of Transportation, Shared Mobility Program Manager (excited to hear more from my colleague Armand about what he's doing!)

• 00:07:58 Raquel Corchado: Raquel Corchado, Chicago Dept of Transportation, Program Manager for Data & Innovation, work a lot with micromobility, pdds and emerging technology and pilots

• 00:11:11 Michael Schnuerle (OMF): Reacted to "Mollie Cohen D’Agost..." with 👋

• 00:11:16 Michael Schnuerle (OMF): Reacted to "Raquel Corchado, Chi..." with 🎉

• 00:11:23 Andrew Glass Hastings (OMF): Will you or your team be in Minneapolis next week for NACTO? Want to learn more about MDS and CDS and the world of digtial infrastructure generally - join us at a unique in-person OMF Academy Session co-hosted by INRIX next Tesday in Minneapolis! Register below and please share…

• https://www.eventbrite.com/e/omf-academy-workshop-at-designing-cities-2026-co-hosted-by-inrix-tickets-1986342870998?aff=oddtdtcreator&keep_tld=true

• 00:11:32 Michael Schnuerle (OMF): Calendar https://calendar.google.com/calendar/u/0/embed?src=openmobilityfoundation.org_g6gsaccjvijnmlhigfpj01ngp0@group.calendar.google.com&ctz=America/Los_Angeles

• 00:11:54 Amanda Harshbarger (Verra Mobility): Reacted to "Becky Edmonds, Sea..." with ❤️

• 00:11:59 Ellen Partridge, Equiticity, Chicago: Reacted to "Raquel Corchado, Chi..." with 🎉

• 00:16:33 Michael Schnuerle (OMF): Boston brought this need to the OMF and created this issue, which lead to its development by the community and inclusion in MDS 2.1 https://github.com/openmobilityfoundation/mobility-data-specification/issues/957

• 00:16:51 Andrew Glass Hastings (OMF): Reacted to "Boston brought this ..." with 👏

• 00:25:27 Michael Schnuerle (OMF): When you can share the names of the companies using MDS as they come on board, let us know so we can add them to the list of 200 operators we are aware of around the world: https://www.openmobilityfoundation.org/mds-users/

• 00:26:07 Armand Shahbazian (Seattle DOT): Reacted to "Becky Edmonds, Seattle Department of Transportation, Shared Mobility Program Manager (excited to hear more from my colleague Armand about what he's doing!)" with ❤️

• 00:26:53 Aylene McCallum - OMF: I'm curious - do other cities have something similar to Boston's Data Dictionary?

• 00:27:54 Halina Do-Linh (LADOT): I love documentation! This is awesome🎉

• 00:28:42 Aylene McCallum - OMF: Reacted to "I love documentation..." with 👋🏻

• 00:28:57 Aylene McCallum - OMF: Reacted to "I love documentation..." with ❤️

• 00:30:25 Matt McBride: Replying to "I'm curious - do other cities have something similar to Boston's Data Dictionary?"

• No but NYC DOT is planning on collecting delivery data soon. Hope to mirror this!

• 00:30:46 Matt McBride: Would love to connect!

• 00:31:20 Aylene McCallum - OMF: Reacted to "No but NYC DOT is pl..." with 🚀

• 00:32:03 Michael Schnuerle (OMF): Can you share your slides in the chat, which has links for everyone to see? I’ll add them to the final slides and notes.

• 00:32:41 Oskar Jahr (Municipality of Bergen): Super super interesting presentation, thank you so much. Hands-on, practical and some easy moves that I think a lot of participants can use in their own jurisdictions!

• 00:32:56 Aylene McCallum - OMF: Thank you so much for working so diligently to "get to yes"

• 00:33:32 Gonzalo Martinez Santos | CurbIQ (Arcadis): Reacted to "Super super interest..." with 💯

• 00:34:14 Sam Brenner: Slides here! https://docs.google.com/presentation/d/1QtIXApggHTxvO6iDVIs96VbpxWiyGWW4OcM7-m9lYYM/edit?usp=sharing

• 00:34:23 Michael Schnuerle (OMF): Will you be publishing a version of the data on your open data site?

• 00:34:28 Raquel Corchado: Reacted to "Slides here! https..." with ❤️

• 00:34:31 Halina Do-Linh (LADOT): Reacted to "Slides here! https:/..." with ❤️

• 00:34:42 Michael Schnuerle (OMF): Reacted to "No but NYC DOT is pl..." with 🚚

• 00:35:34 arti gupta: Replying to "Would love to connec..."

• As Cities are defining their own data dictionary, does it make sense for MDS to filter their data dictionary to most common elements that cities and vendors are sharing and put the other data elements as additional. One possibility might be to tag the data elements that cities and vendors are sharing, this may help other cities and vendors to work through their negotiations .

• 00:36:12 Michael Schnuerle (OMF): INRIX opened this “pull request” and an issue to get this optional field added for micromobility. https://github.com/openmobilityfoundation/mobility-data-specification/pull/975

• 00:36:46 Mollie D'agostino Mollie D'agostino: Reacted to "Slides here! https://docs.google.com/presentation/d/1QtIXApggHTxvO6iDVIs96VbpxWiyGWW4OcM7-m9lYYM/edit?usp=sharing" with 👍

• 00:37:16 Michael Schnuerle (OMF): Again here, the city can define with a data dictionary how standard, access, member apply in their locality and program.

• 00:38:10 Sam Brenner: Replying to "Will you be publishi..."

• We’ve skated around that question for now; I have brought up using the data as part of research partnerships the City has with universities and did not get an enthusiastic yes.

• Hoping once we get through the technical work and data is actually being shared we can talk with providers about opportunities to make use of the data outside of the transportation dept.

• 00:38:55 Raphael Dumas: Dunno if this is a bit gauche since Toronto's ride-hailing data requirements kind of precede MDS. But since I was last in one of these meetings, we have published 8 years of aggregated ride-hailing passenger & vehicle data to our OpenData

• https://open.toronto.ca/dataset/private-transportation-companies-vehicle-operating-data/

• https://open.toronto.ca/dataset/private-transportation-companies-summary-and-trip-data

• 00:39:23 Michael Schnuerle (OMF): Reacted to "Dunno if this is a b..." with 👀

• 00:39:29 Ellis Coldren | City of Boston: Reacted to "Dunno if this is a b..." with 👀

• 00:39:32 Aylene McCallum - OMF: this is great Michael! Thank you for sharing this great work from INRIX!

• 00:39:50 Sam Brenner: Reacted to "Dunno if this is a b..." with 👀

• 00:40:12 Michael Schnuerle (OMF): Reacted to "Dunno if this is a b..." with 🎉

• 00:42:22 Michael Schnuerle (OMF): Replying to "Dunno if this is a b..."

• NYC and Chicago share this kind of data too, maybe other cities. Love to see good open data. Would also love to see cities shift to using MDS 2.1 for ride hail and taxis (many planning to or are, like LADOT).

• 00:42:43 Jeff Kaplan: Reacted to "Dunno if this is a..." with 👀

• 00:42:45 Oskar Jahr (Municipality of Bergen): Reacted to "Dunno if this is a b..." with 👀

• 00:43:29 Raphael Dumas: I think our (published) trip data are not as fine a resolution as those datasets, but we appear to be the only agency publishing data on the full lifecycle of the vehicle

• 00:43:51 Remi Kuti: Hi everyone, I’m Remi Kuti, Founder of UrbanShield in London.

• We focus on infrastructure-led safety and compliance systems for shared micromobility, particularly around real-time safety visibility, operational intelligence, and city-level governance.

• I’ve been following MDS 2.1 closely, especially around incidents and policy integration.

• Great to be here.

• 00:44:28 Gonzalo Martinez Santos | CurbIQ (Arcadis): Reacted to "Dunno if this is a b..." with ❤️

• 00:44:35 Michael Schnuerle (OMF): A little technical, but here is one of the many changes in MDS 2.1 that allow real-time (down to the second) digital policy and geofencing being pushed out, thanks to Seattle and Blue Systems, and feedback from the community. https://github.com/openmobilityfoundation/mobility-data-specification/tree/release-2.1.0/policy#policies---create

• 00:48:51 Michael Schnuerle (OMF): Reacted to "Hi everyone, I’m Rem..." with 🌟

• 00:49:03 Michael Schnuerle (OMF): Reacted to "I think our trip dat..." with 🌟

• 00:49:25 Michael Schnuerle (OMF): Reacted to "We’ve skated around ..." with ✅

• 00:49:47 Aylene McCallum - OMF: Reacted to "Hi everyone, I’m Rem..." with 👋🏻

• 00:50:05 Michael Schnuerle (OMF): Reacted to "A little technical, ..." with mds

• 00:52:07 Armand Shahbazian (Seattle DOT): Here's our summary report of the 911 alerting project: Broadcasting the Locations of Emergency Vehicles to Robotaxi Operators to Improve Safety and Mobility

• 00:52:21 Armand Shahbazian (Seattle DOT): and our project website 🙂 Digital Conflict Area Awareness Management Program - Transportation | seattle.gov

• 00:53:43 Michael Schnuerle (OMF): Reacted to "Here's our summary r..." with 🚨

• 00:54:01 Michael Schnuerle (OMF): Reacted to "and our project webs..." with 🚒

• 00:56:43 Raphael Dumas: Is the ERD a mermaid diagram?

• 00:57:05 Michael Schnuerle (OMF): Reacted to "Is the ERD a mermaid..." with 👀

• 00:58:16 Andrew Glass Hastings (OMF): A couple things to keep in mind with WZDx, as Halina mentioned, it was developed by USDOT for planned work zones on interstate HWYs. It was not developed for unplanned or emergent events. It also is not in active development right now, and is used by only a handfull of state DOT’s around the country.

• 00:58:17 Aylene McCallum - OMF: If you've really enjoyed this session and want to make sure your colleagues understand and enjoy it too - encourage them to attend our in-person OMF Academy workshop at NACTO - https://www.eventbrite.com/e/omf-academy-workshop-at-designing-cities-2026-co-hosted-by-inrix-tickets-1986342870998?aff=oddtdtcreator

• 00:59:00 Raphael Dumas: Reacted to "A couple things to k..." with 😧

• 00:59:20 Aylene McCallum - OMF: The workshop will be held on Tuesday (May 12) morning -it is free and available to anyone - and while we would love for you to attend the entire session, it is not required (but we will be offering yummy treats and refreshments!)

• 01:01:12 Michael Schnuerle (OMF): For CicLAvia, are scooter, robot delivery, and AV ride-hail (Waymo) companies actively using this MDS Policy you have published for the event?

• 01:01:48 Halina Do-Linh (LADOT): Replying to "Is the ERD a mermaid..."

• Yes, it is!

• 01:01:54 Michael Schwartz, INRIX: Was just going to ask about asset based changes versus Geofences. Do any of the consumers of the data talk about losing the granularity of lane-based spec of WzDX versus geofence based MDS?

• 01:02:07 Armand Shahbazian (Seattle DOT): Reacted to "A couple things to keep in mind with WZDx, as Halina mentioned, it was developed by USDOT for planned work zones on interstate HWYs. It was not developed for unplanned or emergent events. It also is not in active development right now, and is used by only a handfull of state DOT’s around the country." with 😧

• 01:03:07 Raphael Dumas: Thanks all for the great presentations!

• 01:04:35 Halina Do-Linh (LADOT): Thank you all!

WEBVTT

1 00:00:03.500 --> 00:00:09.650 Michael Schnuerle (OMF): All right, welcome everyone to the Open Mobility Foundation's MDS Public Working Group Meeting.

2 00:00:09.760 --> 00:00:18.959 Michael Schnuerle (OMF): I'm Michael Schnurla, Director of Open Source Operations for the OMF, and today we're going to give you a little update on MDS 2.1,

3 00:00:19.110 --> 00:00:26.660 Michael Schnuerle (OMF): And, also take and watch a lot of great presentations from cities who are already using

4 00:00:26.930 --> 00:00:44.590 Michael Schnuerle (OMF): new features in MDS 2.1, and take your questions, and even set up for a future meeting. So, a little bit of housekeeping. Can you set your organization, add your organization and your name in the participant list? I see about

5 00:00:44.950 --> 00:00:48.229 Michael Schnuerle (OMF): Maybe less than half of you have that already, so if you wanna…

6 00:00:48.450 --> 00:00:55.479 Michael Schnuerle (OMF): Add your organization afterwards, edit your name, and that helps us know who you're representing, and helps with note-taking.

7 00:00:56.590 --> 00:01:01.339 Michael Schnuerle (OMF): Mute yourself for now, but feel free to introduce yourself in the chat.

8 00:01:01.510 --> 00:01:02.760 Michael Schnuerle (OMF): And,

9 00:01:03.040 --> 00:01:09.119 Michael Schnuerle (OMF): And then that way, we'll know who you are, and give you a little bit… give us a little bit of background about yourself.

10 00:01:09.280 --> 00:01:22.659 Michael Schnuerle (OMF): Use the chat to leave questions as we go, so we're going to have presentations from cities and companies. You can feel free to leave questions as you think of them in the chat, and we'll get to them at the end of the presentations.

11 00:01:23.190 --> 00:01:33.130 Michael Schnuerle (OMF): And then when we do have, some Q&A after each one, raise your hand if you want to ask a question. And this meeting is being recorded and will be published with notes.

12 00:01:34.350 --> 00:01:40.240 Michael Schnuerle (OMF): So we'll do some quick announcements, and then we'll have four presentations, one from Boston.

13 00:01:40.270 --> 00:01:55.510 Michael Schnuerle (OMF): about MDS and delivery, which is part of 2.1. NRIX is going to be talking about a few cities and their special fare programs, which were added in 2.1. Seattle will have an update on their real-time digital policy and geofencing.

14 00:01:55.530 --> 00:02:07.619 Michael Schnuerle (OMF): for AV Ridehill, which is… the real-time part of that is being leveraged as part of 2.1, and LADOT will have something similar to share

15 00:02:07.910 --> 00:02:14.589 Michael Schnuerle (OMF): in a little more detail around the use of MDS policy for Cyclavia vehicles and events.

16 00:02:17.100 --> 00:02:25.779 Michael Schnuerle (OMF): Alright, introduction, the OMF is a global nonprofit created in 2019, and we help cities and companies get to yes.

17 00:02:26.890 --> 00:02:38.640 Michael Schnuerle (OMF): Everything we do is built in the open, online on GitHub, and in meetings like this, public meetings, webinars, always open to getting emails or notes from you.

18 00:02:39.190 --> 00:02:41.610 Michael Schnuerle (OMF): Through our website, or through GitHub.

19 00:02:43.040 --> 00:02:56.259 Michael Schnuerle (OMF): And the mobility data specification is the spec we're talking about today. It enables right-of-way regulation, digital policy, geofencing, and two-way digital communications between mobility companies and public agencies worldwide.

20 00:02:56.410 --> 00:03:14.140 Michael Schnuerle (OMF): The OMF board is currently reviewing MDS 2.1. The official review starts during an in-person board meeting at NACTO, so hope to see you all at NACTO, look us up. And, after that, it'll go through a period of review and eventually be published.

21 00:03:15.160 --> 00:03:21.809 Michael Schnuerle (OMF): I'd like to thank our steering committee members on the right here, many of which who are presenting today, so the steering committee

22 00:03:22.160 --> 00:03:32.680 Michael Schnuerle (OMF): was the inspiration for doing the presentations you see today. If at the end of these presentations you all, anyone on the call would like to present at a working group meeting.

23 00:03:32.680 --> 00:03:45.260 Michael Schnuerle (OMF): like this one, or maybe 10 minutes at one of our regular working group meetings, please reach out to me, and I'll talk to you about your presentation and try to get you slotted for one of our next meetings.

24 00:03:46.550 --> 00:03:58.879 Michael Schnuerle (OMF): MBS 2.1 supports all of the modes and vehicles and types of services that you see here across the range of micromobility, passenger, fleet, and delivery.

25 00:03:59.460 --> 00:04:03.360 Michael Schnuerle (OMF): This is… we'll be talking about a lot of these different things today.

26 00:04:04.460 --> 00:04:21.120 Michael Schnuerle (OMF): It is global, over 200 commercial mobility service providers send MDS to cities or receive it from cities, and these companies operate in over 1,200 cities in dozens of countries around the world, and represent billions of trips taken.

27 00:04:22.460 --> 00:04:28.179 Michael Schnuerle (OMF): And our other specification, CDS, is something that works together with MDS. They both

28 00:04:28.390 --> 00:04:46.889 Michael Schnuerle (OMF): share digital policy, have data sharing from companies or operators, and provide metrics that can be used independently or cooperatively. And MDS is more focused on vehicle location, status, incidents, and trips, and CDS is focused around infrastructure objects and

29 00:04:46.890 --> 00:04:49.520 Michael Schnuerle (OMF): Activity tracking at those locations.

30 00:04:52.060 --> 00:04:56.379 Michael Schnuerle (OMF): So I'll let Aileen talk about our members, our commercial members.

31 00:04:57.780 --> 00:05:15.490 Aylene McCallum - OMF: I want to have, or express a big, shout out of appreciation to our commercial members. These are our six Premier members, Blue Systems, Core by Q, InRex, Passport, Transito, and Umojo. And then let's move over and…

32 00:05:15.680 --> 00:05:24.099 Aylene McCallum - OMF: Let the next slide, and we'll showcase our associate members as well. These members collectively help support the work that we do.

33 00:05:24.100 --> 00:05:48.980 Aylene McCallum - OMF: Both in keeping the standards and specifications that we steward up to date and relevant to today's modern technology, and also the modern problems that all of our cities are experiencing. But they also support our programming to help support cities and the private sector use the specifications. So, through our OMF Academy.

34 00:05:48.980 --> 00:05:56.429 Aylene McCallum - OMF: work, we were able to turn around and provide support to the OMF's members, to help them understand

35 00:05:56.430 --> 00:06:11.670 Aylene McCallum - OMF: how this digital infrastructure works, and specifically how to use MDS and CDS to, address modern-day problems in cities. So, thank you so much to our, Premier and associate members. We… we can't do it without you.

36 00:06:13.990 --> 00:06:14.900 Michael Schnuerle (OMF): Exhaling.

37 00:06:15.020 --> 00:06:31.439 Michael Schnuerle (OMF): And I'll point out our OMF calendar that you can follow along with visually or subscribe to. Here's a link to it, and you can see in the middle there, we're going to be at NACTO. I'll put this link in the chat, so feel free to subscribe at the bottom here, or use other links.

38 00:06:31.700 --> 00:06:33.500 Michael Schnuerle (OMF): As needed.

39 00:06:35.780 --> 00:06:41.309 Michael Schnuerle (OMF): So we try to keep every public, public part of the OMF on this calendar.

40 00:06:43.570 --> 00:06:50.520 Michael Schnuerle (OMF): Alright, we're gonna… I'm gonna talk… actually, I think we're just gonna jump into the presentation, so…

41 00:06:50.670 --> 00:06:59.269 Michael Schnuerle (OMF): Let me see if there's anything else to talk about with 2.1. I said it's in the review process, if you missed that earlier in the call, but it should be released.

42 00:06:59.390 --> 00:07:09.989 Michael Schnuerle (OMF): if things go well in June sometime, officially, and that'll become the new standard for the MDS repository, the homepage at MDS, the spec.

43 00:07:10.160 --> 00:07:18.319 Michael Schnuerle (OMF): And, the board is reviewing it at NACTO. So, what we have today is four different presentations.

44 00:07:18.400 --> 00:07:37.020 Michael Schnuerle (OMF): And each one is going to be talking about some new feature that is in MBS 2.1 that they're already using, and maybe some features they're planning to use once it's approved, or once they get it implemented. But they're all pretty interesting use cases, and

45 00:07:37.260 --> 00:07:41.899 Michael Schnuerle (OMF): Like I said, think about, questions you have, leave them in the chat.

46 00:07:42.070 --> 00:07:46.620 Michael Schnuerle (OMF): We'll have a little Q&A at the end. Each presentation will be about 10 minutes.

47 00:07:46.790 --> 00:07:58.630 Michael Schnuerle (OMF): And, at the end of this, if you feel like you'd like to present on something you're going to be implementing or have implemented for MDS or MDS 2.1, you can email me and we can schedule it for a future meeting.

48 00:07:59.420 --> 00:08:09.779 Michael Schnuerle (OMF): So, here are the presentations. We're gonna start with Boston, talking about MBS and delivery, so I will stop sharing my screen.

49 00:08:10.420 --> 00:08:17.240 Michael Schnuerle (OMF): And, I know that we have a lot of people from Boston, so anyone can share their screen and start presenting.

50 00:08:22.320 --> 00:08:33.619 Sam Brenner: Thanks, Michael. I will… Alright, I will share my screen, and oh, what's going on here?

51 00:08:40.350 --> 00:08:55.940 Sam Brenner: Okay, so… Hi everybody, my name is Sam Brenner. I sit in the City of Boston's Office of Emerging Technology, have been working with OMF for some time on a lot of CDS stuff, and now very excited to be working with them on some MDS stuff.

52 00:08:56.030 --> 00:09:17.429 Sam Brenner: What we'll be talking about today is the City of Boston recently published an ordinance, or passed an ordinance, requiring food, delivery app providers to share data with the city. And, after having some really productive conversations with these providers, we've actually started to, like.

53 00:09:17.480 --> 00:09:27.889 Sam Brenner: building, the data infrastructure to actually collect, MDS data from these providers. So, wanted to just give a couple quick notes on, like.

54 00:09:27.890 --> 00:09:46.729 Sam Brenner: how those conversations went with the providers, and to use Michael's words, how to get to yes. And then also wanted to share, I have Ian from our analytics team, and Ellis from our data engineering team, who are going to share some notes just about, like, some of the more, like, technical aspects of how

55 00:09:46.730 --> 00:09:48.170 Sam Brenner: We got this implemented.

56 00:09:48.180 --> 00:09:57.000 Sam Brenner: So, without further ado… About the food delivery ordinance, so…

57 00:09:57.030 --> 00:10:06.040 Sam Brenner: The purpose of the ordinance was the City of Boston felt that there was a lot of unsafe behavior happening on the street. We also had a lot of problems with congestion, and from a…

58 00:10:06.040 --> 00:10:19.339 Sam Brenner: Data perspective, the city didn't have the data it needed to, like, really make planning decisions around where, different safety implementations should be made, or where, like, new loading zones should be put up.

59 00:10:19.340 --> 00:10:25.759 Sam Brenner: And as… and so, in order to become a… if you…

60 00:10:25.760 --> 00:10:33.339 Sam Brenner: So Ordin said that if you do more than, I think, a million orders in the city in a year, you needed to get,

61 00:10:33.370 --> 00:10:43.030 Sam Brenner: A special license that had some insurance requirements, but also included a, A data requirement, and…

62 00:10:43.460 --> 00:10:50.350 Sam Brenner: one of the things that jumped out to us in talking to the Transportation Department when they passed the ordinance is that,

63 00:10:50.350 --> 00:11:15.289 Sam Brenner: they had some really complex, like, policy and planning questions, and, we were really concerned at the start that unless we collected the data in the right way, and in a flexible format, that we would end up with lots and lots of data that would not be useful. So, it was, you know, I think there will be, like, many new questions that come out after we start getting data, but, we're really excited to

64 00:11:15.290 --> 00:11:32.359 Sam Brenner: leverage MDS for this, because we felt like it's a flexible enough and comprehensive enough format that, once we do start getting data from providers, the city is going to have a much easier time managing that data.

65 00:11:32.360 --> 00:11:39.289 Sam Brenner: Part of that came from talking to many cities that do already get data from, providers.

66 00:11:39.580 --> 00:11:47.959 Sam Brenner: either delivery providers or, like, just taxi providers. You know, a lot of cities right now are just getting massive, massive, Excel spreadsheets that…

67 00:11:47.970 --> 00:12:10.690 Sam Brenner: show up in inboxes and don't go anywhere. So, yeah, didn't want that to happen again. So we're like, let's jump into MDS and make this data useful. So, as you might expect, initially, when we started talking to providers, they said, no, we're not gonna do this, this would be a big cost to, us to set this up.

68 00:12:10.690 --> 00:12:15.199 Sam Brenner: the three main concerns that they had, first was exposing algorithms,

69 00:12:15.790 --> 00:12:33.479 Sam Brenner: just plainly, if you look at the documentation online, like, they all publish a lot, like, they all have the engineering blogs, which kind of explain how a lot of the stuff works, and the number of variables you need to have in order to actually, like, recreate these algorithms just aren't…

70 00:12:33.480 --> 00:12:45.549 Sam Brenner: you know, I don't think that that feedback really passed the smell test. The other concern that they had is around data security, so I think there is, like, a somewhat legitimate

71 00:12:45.550 --> 00:12:58.469 Sam Brenner: concern around revealing trade secrets. And so, you know, understanding order volumes and, where orders are happening, that was something that they were really, not…

72 00:12:58.630 --> 00:13:16.070 Sam Brenner: they did not want, other… other providers being aware of. And then lastly, they looked at this as something that would cost them money, time and money and resources to do, and so obviously that's not something that they were… were excited about.

73 00:13:16.750 --> 00:13:32.719 Sam Brenner: the conversations kind of went the same way with all of the providers we spoke to. First, somebody from, like, their lobbying department would reach out and set up a meeting. That meeting would consist of a lot of lawyers who all reiterated these concerns on the behalf of their engineers.

74 00:13:33.950 --> 00:13:51.229 Sam Brenner: one thing that really helped us through this conversation is the fact that the ordinance requires this data. It didn't necessarily specify it has to be MDS, but the law said, or the ordinance said that, like, you are going to share this data. And I think…

75 00:13:52.180 --> 00:14:03.249 Sam Brenner: The way that the conversation became productive, as soon as we could actually get some technical folks from the companies, to actually could

76 00:14:03.540 --> 00:14:16.169 Sam Brenner: talk about what it would take to get the data, and I think once we were able to bring technical folks into the room and realize that they have… they have the things that we want, and… and…

77 00:14:16.410 --> 00:14:19.979 Sam Brenner: The requests that we have are not,

78 00:14:20.180 --> 00:14:28.969 Sam Brenner: you know, it's all doable. The conversation started having… becoming much more productive. I think the biggest…

79 00:14:28.990 --> 00:14:35.569 Sam Brenner: blocker was just, in the conversations, for the most part, was around the API, so,

80 00:14:35.570 --> 00:14:53.720 Sam Brenner: everybody said, we've never done this before. I think there are legitimate security concerns around setting up new APIs, like, public APIs. And the way that we got around that conversation is we decided with all of them that we would set up an S3 sharing bucket, so for those that don't know, it's kind of like a…

81 00:14:53.860 --> 00:15:10.559 Sam Brenner: you know, it's like a share drive for sharing data, and it is essentially, like, rather than sharing data through an API, like, we just give them credentials, and they're able to drop it directly into a storage container that is owned by the city.

82 00:15:11.750 --> 00:15:26.419 Sam Brenner: it did take a little bit of convincing to do that, because… but they, you know, what we heard from everybody else was, like, they would much prefer to do this by email, which doesn't make any sense, because that's, like, far less secure than an S3 bucket. But ultimately, like.

83 00:15:26.980 --> 00:15:29.130 Sam Brenner: You know, we felt…

84 00:15:29.130 --> 00:15:53.230 Sam Brenner: as we were having the conversations that focused on an API, in all the cases, they went nowhere. Once we opened up this third door to, like, a shared… a shared S3 bucket, it became really productive, and then we stopped having the conversation of how does the data get from point A to point B, and really started being productive around, like, okay, how do we make this data standard work, and started being able to, like, share notes on both sides over, like, how this

85 00:15:53.230 --> 00:15:59.459 Sam Brenner: you know, what it's actually going to look like. And now we're in the process now where providers are sharing us test data, and we're

86 00:15:59.460 --> 00:16:04.980 Sam Brenner: Refining our data dictionary, and, you know, we're in the process of developing

87 00:16:04.980 --> 00:16:19.770 Sam Brenner: our, like, data validation tools on their test data. So, once we, yeah, got over that big hurdle of the API, we feel like we have a clear line of sight to actually, like, getting this data and getting it in a format that we're excited about.

88 00:16:19.770 --> 00:16:25.560 Sam Brenner: So, with that, I'll pass it over to Ian. He'll talk a little bit about,

89 00:16:25.800 --> 00:16:30.369 Sam Brenner: Our data dictionary that we put together, a big part of this project was just thinking through

90 00:16:30.500 --> 00:16:38.270 Sam Brenner: how we would define the data requirements in the ordinance in MDS terms, and…

91 00:16:38.530 --> 00:16:44.560 Sam Brenner: yeah, there was a lot of really great thinking on Jen's part to make that happen, so I will pass it over to him.

92 00:16:47.240 --> 00:16:51.000 Ian Smith | City of Boston: Perfect. Thanks, Sam. Yeah, so…

93 00:16:51.210 --> 00:16:58.720 Ian Smith | City of Boston: Very early on in our conversations with providers, it became very clear that there was a need to come up with

94 00:16:59.450 --> 00:17:00.839 Ian Smith | City of Boston: our own

95 00:17:01.070 --> 00:17:11.410 Ian Smith | City of Boston: data dictionary of sorts, because while there's a ton of great documentation on MDS available that we could just provide links to,

96 00:17:11.410 --> 00:17:27.370 Ian Smith | City of Boston: The need for this data really goes back to this ordinance, and so we're only asking for a subset of all of the various, like, variables that could be asked for, and basically, we had to map them to the…

97 00:17:27.569 --> 00:17:39.040 Ian Smith | City of Boston: the data asks of the ordinance. So, what we ended up doing is, writing up, like, a data dictionary and transmission guide, which…

98 00:17:39.100 --> 00:17:49.659 Ian Smith | City of Boston: is basically a long document, I think Sam had it linked in the sign, that defines the data reporting requirements for the delivery providers operating under the new ordinance.

99 00:17:49.800 --> 00:17:59.880 Ian Smith | City of Boston: And, you know, we explicitly say that it maps these ordinance requirements to MDS 2.1 with links to all the MDS documentation.

100 00:18:01.090 --> 00:18:02.580 Ian Smith | City of Boston: I'll actually…

101 00:18:02.840 --> 00:18:04.340 Sam Brenner: Do you want to pull it up, Ian?

102 00:18:04.340 --> 00:18:07.359 Ian Smith | City of Boston: Pull it up and share, instead of just talking through it.

103 00:18:10.930 --> 00:18:14.280 Ian Smith | City of Boston: And I'll go through it pretty quickly, because it might… maybe is kind of a…

104 00:18:15.120 --> 00:18:30.140 Ian Smith | City of Boston: dense document. But basically, there's two important tabs here. We have, like, an overview page in the README, but our data dictionary, sort of establishes this hierarchy of vehicle movements that was

105 00:18:30.370 --> 00:18:45.200 Ian Smith | City of Boston: A lot of conversation and thinking through the distinguish, like, how to distinguish, journeys from trips, from orders, because this is not necessarily how the providers were thinking about, how their operations work.

106 00:18:45.350 --> 00:19:04.599 Ian Smith | City of Boston: And then we have all of the variables that we're asking for with some information about their format and some notes, a link to the MDS documentation, and a column that calls out the specific ordinance reporting requirement, which is the reason why we're asking for those specific variables.

107 00:19:05.100 --> 00:19:17.009 Ian Smith | City of Boston: it's a little bit… We had to get a little bit creative with some of these, because one of the things that we ran into, because all of this data being, you know, given to the City of Boston.

108 00:19:17.300 --> 00:19:24.709 Ian Smith | City of Boston: subject to things like public records requests. We wanted to thoughtfully consider the privacy of

109 00:19:24.710 --> 00:19:33.439 Ian Smith | City of Boston: constituents receiving the deliveries. So we're doing things like asking for the address, the name, and the coordinates of the vendors.

110 00:19:33.440 --> 00:19:51.160 Ian Smith | City of Boston: But for the actual deliveries to somebody's house, we're only asking for, a statistical area, which is just at the census block group level, so we have some additional, like, links to help, the providers figure out how to provide this information to us.

111 00:19:51.170 --> 00:19:56.949 Ian Smith | City of Boston: And so you can see this is really just a subset of all of the MDS variables that we're asking for.

112 00:19:57.560 --> 00:20:04.780 Ian Smith | City of Boston: And then as another, way to make it easier for the providers to start preparing the data for us, because they're really…

113 00:20:05.310 --> 00:20:18.579 Ian Smith | City of Boston: from our understanding and their experience, with providing data to cities in the past, it has been in, like, a flattened CSV that is shared over email. We sort of out, like, lined up

114 00:20:19.110 --> 00:20:21.869 Ian Smith | City of Boston: All… a subset of possible…

115 00:20:21.950 --> 00:20:32.570 Ian Smith | City of Boston: deliveries that could happen, and our vision for how we wanted those to be mapped out. So we have, sort of, like, what different types of trips would look like, and how they fit into the hierarchy.

116 00:20:32.570 --> 00:20:48.399 Ian Smith | City of Boston: some descriptions about how we want this data, and then just some fake data, in the exact format that we're asking for it in. And this goes on to be, like, a bit more complex. You can see we're starting to pick up

117 00:20:48.610 --> 00:21:12.640 Ian Smith | City of Boston: orders from a vendor and delivering to multiple customers, we provide examples of what that looks like, and then we finally end up with, like, some of the more complicated, examples. And we've found that these are really, useful examples to provide to get everybody on the same page for what we mean about the hierarchy of vehicle movements and how we're thinking of the distinguishments between journeys and trips and orders.

118 00:21:12.950 --> 00:21:23.779 Ian Smith | City of Boston: And then the second part of this document is our serialization and transmission guide that we wrote, which talks about all of the different ways that we

119 00:21:23.860 --> 00:21:42.729 Ian Smith | City of Boston: will accept the data in it. You know, we note that the provider-hosted API is the preferred method. We also are offering to, you know, push the data through a city-hosted API, but like Sam said, you know, the providers we're working with have all settled on this city-hosted file share.

120 00:21:42.730 --> 00:22:00.749 Ian Smith | City of Boston: option. And this document just starts to go into, some explicit rules about how we want the data and how we envision, you know, by creating some fake data and thinking about what the approximate size of these files are going to be, walking through some assumptions, like.

121 00:22:00.750 --> 00:22:19.580 Ian Smith | City of Boston: All trips need to go with a journey, and you know, if we're asking for these files for every day, then, you know, what happens if something starts at 11.55 PM, but completes the next day? So we sort of map out, you know, some of these things that we might expect to happen.

122 00:22:19.590 --> 00:22:33.240 Ian Smith | City of Boston: Yeah, feel free to take a look at these documents, and then we'll wrap up with, I think, Ellis, with some information on the… our work that we're doing to validate the data as it comes in.

123 00:22:33.810 --> 00:22:58.759 Sam Brenner: If I could just interject with just one quick note that I think will be useful for people on the transmission data. So, our ordinance stipulated that the data was due, like, one month after the end of the quarter, so we had to prepare for a possibility of a vendor providing a quarter's worth of data in one transmission, which, you know, technically would be an incredibly difficult

124 00:22:58.760 --> 00:23:07.619 Sam Brenner: probably impossible thing to process. So, yeah, just highlighting that, you do need to be really thoughtful about the way

125 00:23:08.150 --> 00:23:19.369 Sam Brenner: the frequency in which the data is sent, and for a lot of reasons, you know, that's what makes APIs great, but in the case where you go with an S3 bucket, it just presents more things to think about. So…

126 00:23:19.530 --> 00:23:20.380 Sam Brenner: Alright.

127 00:23:21.500 --> 00:23:25.180 Ellis Coldren | City of Boston: Absolutely. Hi, everyone. Thank you, Sam and Ian.

128 00:23:25.450 --> 00:23:42.829 Ellis Coldren | City of Boston: Sam, could you actually reshare your screen for the last few slides? As Ian and Sam mentioned, there were some security concerns that the delivery providers had regarding the security of the method of transmission, in addition to the security of the data storage.

129 00:23:42.850 --> 00:23:45.749 Ellis Coldren | City of Boston: And so I… this is a future…

130 00:23:46.310 --> 00:24:01.659 Ellis Coldren | City of Boston: So, yeah, so we had 3 options for the provider-hosted API, city-hosted API, and the city-hosted file share, which is the S3 bucket that most of the providers chose. We do have one or two providers who have mentioned that they'd be interested in hosting an API in the future, which is

131 00:24:01.660 --> 00:24:20.560 Ellis Coldren | City of Boston: Great, because it's our preferred method. And then here are some details that we provided that would be part of our, like, requirements for each of those delivery options. So, if they host an API, we should be able to query, data from that API at least one year from the trip date, so if something

132 00:24:20.560 --> 00:24:25.070 Ellis Coldren | City of Boston: If there was a trip that occurred on the 6th of May 2027,

133 00:24:25.470 --> 00:24:36.599 Ellis Coldren | City of Boston: or 2026, in May 2027, I should still be able to query that. And then just some other details regarding the, batches.

134 00:24:36.760 --> 00:24:52.459 Ellis Coldren | City of Boston: for each API request, and then for the file share S3 bucket, we had some specifications for how files should be named, so that when we set up our ETL pipeline to extract the data from the

135 00:24:52.460 --> 00:25:06.929 Ellis Coldren | City of Boston: shared bucket, we will be able to do that programmatically. If there was a lot of variation in the way the files would be named, then every time we pull, we would have to change something in the script. So the next slide talks a little bit more in depth about that.

136 00:25:06.990 --> 00:25:17.970 Ellis Coldren | City of Boston: So, the way that the city's data warehouse and ETL pipelines are set up, the data is extracted via a Python script that's scheduled in Apache Airflow.

137 00:25:18.190 --> 00:25:24.009 Ellis Coldren | City of Boston: And then we use dbt, which is the data build tool. Yes, New York City

138 00:25:24.180 --> 00:25:28.949 Ellis Coldren | City of Boston: Absolutely would, be happy to talk through some of these other technical…

139 00:25:29.250 --> 00:25:45.759 Ellis Coldren | City of Boston: specifications, because I assumed that there would be a lot in common between our two processes. But we use Data BuildTool where we can validate the data and add tests such as, you know, this field can't be null, the trip ID has to be unique.

140 00:25:45.890 --> 00:26:05.400 Ellis Coldren | City of Boston: And this is also the step where we can create custom tables for different stakeholders, like, if there's a specific person who's really interested in, like, where are all the restaurants, I can… you can create a custom table for them. And then that data is loaded into the city's BigQuery database for analytics purposes.

141 00:26:05.680 --> 00:26:07.899 Ellis Coldren | City of Boston: And just touching on the security.

142 00:26:08.100 --> 00:26:16.829 Ellis Coldren | City of Boston: questions of the third-party providers. Again, they were concerned with who has access to the data, because this is a public

143 00:26:17.500 --> 00:26:20.909 Ellis Coldren | City of Boston: We work for… it's a public service.

144 00:26:21.220 --> 00:26:33.210 Ellis Coldren | City of Boston: all of the data is requestable via a public records request. So that was part of the conversations that we had that I think are,

145 00:26:33.420 --> 00:26:40.709 Ellis Coldren | City of Boston: one of the people on the project BT, in BTD, Amelia, Had a lot of very…

146 00:26:41.920 --> 00:26:47.269 Ellis Coldren | City of Boston: She had a lot of conversations about the public records request, and…

147 00:26:48.140 --> 00:27:01.410 Ellis Coldren | City of Boston: So once it's in the BigQuery database, we can determine who has access, just on… there's group-level access and also individual-level access, so it would be BTD and analytics team, and then anyone who creates a public records request for it.

148 00:27:07.080 --> 00:27:08.030 Michael Schnuerle (OMF): Alright.

149 00:27:08.140 --> 00:27:15.740 Michael Schnuerle (OMF): That is fantastic, that's great to see. You obviously put a lot of work into this with the data dictionary and the conversations, and…

150 00:27:15.920 --> 00:27:24.679 Michael Schnuerle (OMF): I think they sort of mirror conversations around micromobility from, you know, 7, 8 years ago, 6 years ago.

151 00:27:26.250 --> 00:27:33.249 Michael Schnuerle (OMF): So, anyway, good work to get through into, sort of, new markets and new uses for MDS, and I think the

152 00:27:33.540 --> 00:27:39.849 Michael Schnuerle (OMF): being one of the first, it's a challenge and a lot of extra effort, so hopefully other cities, like New York and the chat.

153 00:27:39.980 --> 00:27:51.179 Michael Schnuerle (OMF): can learn from you all. There's other questions in the chat, and I'm gonna leave you to answer them in the chat so that we can move on to the next presenter.

154 00:27:51.220 --> 00:28:10.119 Michael Schnuerle (OMF): I think, as usual, we're… the presentations are good, and we're probably overbooked for today, but I'm gonna move on, and maybe, as you get learnings from this, the data you get, maybe come back again and present on that. So thank you very much. So next up is Michael Schwartz from INRIX.

155 00:28:10.320 --> 00:28:15.959 Michael Schnuerle (OMF): And, please go ahead and proceed, Michael, and I'll leave some other questions in the chat as well.

156 00:28:17.760 --> 00:28:19.220 Michael Schwartz, INRIX: Alright, hold on…

157 00:28:23.530 --> 00:28:30.199 Michael Schwartz, INRIX: Alright, I'm gonna go to slideshow, and I always mess this up in Zoom, so just let me know if I need to switch my screen.

158 00:28:31.840 --> 00:28:37.049 Michael Schwartz, INRIX: You guys seeing… The notes version, or the full slide version?

159 00:28:37.300 --> 00:28:39.259 Michael Schnuerle (OMF): Oh, we're seeing the notes version.

160 00:28:41.840 --> 00:28:43.040 Michael Schnuerle (OMF): There you go. That's it.

161 00:28:43.040 --> 00:28:43.610 Michael Schwartz, INRIX: Okay.

162 00:28:43.740 --> 00:28:44.650 Michael Schwartz, INRIX: Yes.

163 00:28:44.800 --> 00:29:01.769 Michael Schwartz, INRIX: All right, I will try to move more quickly. This is actually, it was sort of a very targeted use case and a probably smaller change in MDS 2.1 that, I worked with Michael and OMF to kind of slip in towards the end, but I think solves a long-standing use case for micromobility.

164 00:29:02.160 --> 00:29:04.820 Michael Schwartz, INRIX: Okay.

165 00:29:04.870 --> 00:29:29.610 Michael Schwartz, INRIX: So, I think most people who are working in the shared micromobility space know that equity is a pretty key component. Almost every city has some type of equity component to their program. A lot of them are geographically based, where they require a certain number of vehicles to be deployed in certain areas. A lot of the operators actually have their own access programs, is probably the more generic term, but basically a program

166 00:29:29.610 --> 00:29:37.030 Michael Schwartz, INRIX: Where people who qualify, either by income or some other type of program, are able to get free or reduced fares.

167 00:29:37.030 --> 00:29:55.189 Michael Schwartz, INRIX: And we've sort of, at Ride Report, treated it a little bit like a bit of a white whale, to try and get more access to that data. The way the operators tend to share it has been in sort of these monthly or quarterly dumps that are basically like, here's how many access program trips we have, and literally zero, granularity to it.

168 00:29:55.190 --> 00:30:19.389 Michael Schwartz, INRIX: And most of the time, there's been a little bit of, knowing that it's sensitive data, and MDS doesn't include any PII or any demographic data, it's all about the vehicles, just sort of saying, you know, this is too sensitive, we're not going to share anything more specific. I think, MDS2, I think it was, where they put in the reports, so you're able to look for special programs, but again, it's really at the spreadsheet level, it's not really leveraging the power

169 00:30:19.390 --> 00:30:20.550 Michael Schwartz, INRIX: of MDS.

170 00:30:20.550 --> 00:30:21.680 Michael Schwartz, INRIX: So…

171 00:30:21.690 --> 00:30:35.139 Michael Schwartz, INRIX: We worked, collaboratively with the operators on just a pretty subtle update, to MDS 2. MDS2, as part of MDS 2.1, leveraging a piece of the code

172 00:30:35.140 --> 00:30:58.590 Michael Schwartz, INRIX: That is mostly for, passenger services, I think is the main place where it shows up. It's called fare attributes, and basically it's about, you know, how do you… what type of fare are you collecting? Is it a meter versus a flat rate? And, some things along those rates that seems more of a taxi or TNC kind of thing. But it seems like kind of the most logical place to put this, in micromobility, to basically

173 00:30:58.590 --> 00:31:20.239 Michael Schwartz, INRIX: be able to tag trips and say, are you sort of a standard trip? Are you part of an access program? Or, particularly for dock-based and public sector focused, you know, are you a member? Do you have some sort of membership that allows you a different set of trips? And we worked really closely with the operators, just knowing that it was sensitive, and they were going to be very hesitant to share stuff.

174 00:31:20.240 --> 00:31:44.280 Michael Schwartz, INRIX: And sort of came up with what was a relatively light lift from a technical standpoint, and would sort of address all of their concerns they had about working with this sensitive population, and knowing that, you know, we want to make sure to aggregate at a level where we're not revealing any individual trips. So we started with some larger markets when we did this, and so we implemented this in Denver, who's long actually had this as a requirement for their program, but

175 00:31:44.280 --> 00:32:09.209 Michael Schwartz, INRIX: kind of with their RFP that came out this spring, really moved towards enforcing this requirement. And so what it allows us to do, I don't know if you can see my mouse or not, but on the left-hand side, you can, filter. This is access programs, this is our routes module, and what we were able to see in this is that there's actually certain segments in parts of the city where people, who are taking, free or reduced fare

176 00:32:09.210 --> 00:32:22.279 Michael Schwartz, INRIX: trips are traveling that, at a much higher rate than people who pay the standard amount, or the program as a whole. And so you're able to see, okay, well, this is, you know, perhaps where some target improvements, or where we're seeing this taking place.

177 00:32:24.370 --> 00:32:38.049 Michael Schwartz, INRIX: Similarly, you can track, some of the outcome metrics from some of your equity programs. So this is… these are opportunity areas, again, in Denver, which is where they've tried to… they've required a certain deployment, they've even reduced

178 00:32:38.050 --> 00:32:49.919 Michael Schwartz, INRIX: some of the fare for standard programs, for trips that begin or end in this area. And we're able to see that in this particular case, you know, it nearly matches in terms of the access program trips

179 00:32:49.920 --> 00:32:58.770 Michael Schwartz, INRIX: as the standard trips. And again, by filtering it to the specific areas, you can actually look at how successful those deployment approaches are working.

180 00:32:59.320 --> 00:33:23.010 Michael Schwartz, INRIX: And then I think something that was seen as a little bit of a boon to the operators, or a little bit more motivation for them to comply with this, we also… you're able to do per-trip fees. You can think about charging different amounts for those programs. So if you charge, say, you know, a quarter per trip, or whatever it may be, maybe you charge a reduced amount, or even subsidize your access fare program, since these are priorities for cities, and

181 00:33:23.010 --> 00:33:29.479 Michael Schwartz, INRIX: It's acknowledging that this is a public benefit. Maybe they'll… they don't qualify for the same, fee amount.

182 00:33:29.490 --> 00:33:52.740 Michael Schwartz, INRIX: So those are just some of the things that you can do in the implementation. And again, it was sort of a nice, quick win right at the end of the 2.1 sprint, and it's elegant. We have, a few of the operators who complied with this already. It's still sensitive enough that the operators sort of… it's optional in the spec, and the operator's sort of requesting you work individually with each city, rather than roll it out blanket. I think, you know.

183 00:33:53.300 --> 00:34:06.049 Michael Schwartz, INRIX: programs like Ride Report, we already aggregate to protect some of the anonymity and some of the sensitivity around it, but I think if it's a very small program, there's some feeling of targeting an even smaller component of a small program, you could start to

184 00:34:06.050 --> 00:34:14.480 Michael Schwartz, INRIX: get into some sensitivity issues. But I think it's something that I think I could see becoming much more commonly used, in 2.1 and beyond.

185 00:34:14.580 --> 00:34:18.209 Michael Schwartz, INRIX: So that's it. I'm moving quick, quickly here.

186 00:34:19.860 --> 00:34:27.630 Michael Schnuerle (OMF): Thank you, Michael, appreciate that. Yeah, it's a great use of a minor change to MDS to have a big impact

187 00:34:27.719 --> 00:34:44.440 Michael Schnuerle (OMF): in certain… in cities that want to use it, and like I said in the chat, you know, each city, I think, you could maybe clarify this, has the ability to define what standard access and member mean for their program, and so there's flexibility there to make that work.

188 00:34:45.040 --> 00:34:53.989 Michael Schwartz, INRIX: Yeah, that's right. Each city does… my recommendation is, you know, to work closely with your operators. Like, for example, we sort of defined… I think everybody knows in

189 00:34:53.989 --> 00:35:08.299 Michael Schwartz, INRIX: for, say, as an example, Lime, they have, sort of, your standard pay by the minute, and then they have, sort of, bundled fares, they have also, you can buy a bunch of minutes and then draw them down, and we basically said, all of that is standard rate, because everybody from the public has access to that.

190 00:35:08.300 --> 00:35:14.429 Michael Schwartz, INRIX: we're not going to actually distinguish between those, because that's less of what the city is trying to get at. They're really looking at who…

191 00:35:14.480 --> 00:35:26.809 Michael Schwartz, INRIX: qualifies for a discount program, and they called that their access program. And, their strong preference was to just have two, have it be binary, standard, and access. But again, I think it's something that, yeah, cities, operators, and

192 00:35:26.810 --> 00:35:37.250 Michael Schwartz, INRIX: third parties, like, like Ryderport as needed, could be something that could be talked about back and forth, of what's feasible technically and what makes the most sense, best bang for your buck in terms of leveraging the spec.

193 00:35:39.770 --> 00:35:53.700 Michael Schnuerle (OMF): Great. If people have other questions for Michael at NRICS, feel free to leave them in the chat, and there are a few comments, I think. But, we will move on to the next presenter.

194 00:35:53.840 --> 00:36:12.440 Michael Schnuerle (OMF): Which is Seattle, and we… I'm going to give a little preamble here. I think Seattle has presented before on the work they're doing, and so Armand is going to talk about that a little bit again, and give a little bit of an update. But it… what Armand is talking about will lead into our last presenter, LADOT, because they are also doing something similar.

195 00:36:12.560 --> 00:36:18.860 Michael Schnuerle (OMF): And so, want to set that up. So, Armand, go ahead and… Take it away.

196 00:36:19.270 --> 00:36:22.139 Armand Shahbazian (Seattle DOT): Awesome, thank you. And can you guys see my screen?

197 00:36:22.290 --> 00:36:23.440 Michael Schnuerle (OMF): Yes.

198 00:36:23.440 --> 00:36:26.249 Armand Shahbazian (Seattle DOT): Okay, perfect. I'll try to move quickly also through this.

199 00:36:26.370 --> 00:36:35.960 Armand Shahbazian (Seattle DOT): So thanks everyone, I'm Arman Shabazian, I'm the Electric and Automated Mobility Policy Advisor at the Seattle Department of Transportation, and I manage our autonomous vehicle program.

200 00:36:36.910 --> 00:36:51.729 Armand Shahbazian (Seattle DOT): So for some… okay, let's see if this goes… there we go. So for some background on the project, our goal was to provide critical city data in an open, machine-readable format for use by any transportation operator.

201 00:36:51.760 --> 00:37:14.400 Armand Shahbazian (Seattle DOT): So critical city data, in this case is 911 information. Machine-readable format is through MDS, and any transportation operator, our initial focus is autonomous vehicle companies, but this is also intended to be used by mapping companies, OEMs, and anyone that's able to read our API.

202 00:37:15.780 --> 00:37:37.920 Armand Shahbazian (Seattle DOT): The reason we worked on this project was we know that AV companies are heavily reliant on remote fleet support to assist vehicles near challenging, scenes, especially around emergency response. And as time has gone on, and we talk to peer cities, we've really seen that AV companies continue to rely on third-party tools to help them with this.

203 00:37:37.920 --> 00:38:02.009 Armand Shahbazian (Seattle DOT): There are a few out there that basically listen to police and fire public radio feeds and try to infer information on emergency response. We know both Zoox and Waymo use these services in the different markets that they operate in, and so our goal with this project is to say, you know, you don't need to rely on a third party, you can just get this data directly from us.

204 00:38:02.010 --> 00:38:03.650 Armand Shahbazian (Seattle DOT): In MDS.

205 00:38:05.320 --> 00:38:30.179 Armand Shahbazian (Seattle DOT): And we know that we have importance for this work because there continues to be examples where autonomous vehicles are challenged by the interaction between first responding vehicles. In this case, there was a shooting in Austin, Texas, and a Waymo vehicle became stuck and blocked an ambulance, and during the discussion of why the event occurred, it was revealed

206 00:38:30.180 --> 00:38:38.109 Armand Shahbazian (Seattle DOT): that while the city did share some general information on the emergency with Waymo and other AV companies.

207 00:38:38.110 --> 00:38:52.450 Armand Shahbazian (Seattle DOT): The AV companies didn't have any way to understand the severity of the incident, to really shape how they adjust their routing, which is something that our system addresses by sharing much more granular information with AV companies.

208 00:38:54.160 --> 00:39:03.449 Armand Shahbazian (Seattle DOT): And beyond AV, we know that this can be really beneficial for other mobility operators, including transit taxi mapping companies and TNCs that are operating today.

209 00:39:04.670 --> 00:39:20.620 Armand Shahbazian (Seattle DOT): So what we had was a very rudimentary system of sharing out traffic incident alerts via social media and text messages. And, don't be embarrassed if your city or jurisdiction is also doing this, because we still continue to do this.

210 00:39:20.620 --> 00:39:29.800 Armand Shahbazian (Seattle DOT): So this is the system that we had. Obviously, it doesn't work very well, and it requires that transportation companies, like AV companies.

211 00:39:29.800 --> 00:39:38.179 Armand Shahbazian (Seattle DOT): Need to constantly be monitoring our social media feeds to understand where there are, emergencies and other, blockages.

212 00:39:39.430 --> 00:40:00.379 Armand Shahbazian (Seattle DOT): We wanted to make sure that this system could work for a wide audience because early awareness helps inform routing, and we've seen a lot of benefit when companies know in advance where there might be instances that they should either patch in remote fleet support, or if you're a human driver, adjust your routing before you get into a sticky situation.

213 00:40:02.080 --> 00:40:26.910 Armand Shahbazian (Seattle DOT): So the solution is our integration directly with Seattle's 911 dispatching software. This is a screenshot of the public view, so the view that our system is using has significantly more data, but this is what we provide to the public today. It, as you can see, provides a lot of information, including date and time, number of units, what units specifically are being sent to a scene, which scene is

214 00:40:26.910 --> 00:40:29.049 Armand Shahbazian (Seattle DOT): Versus which ones have closed.

215 00:40:29.050 --> 00:40:40.290 Armand Shahbazian (Seattle DOT): address, and then the type of emergency. On the back end, we also provide a lot more information, such as final location of vehicles where they're parked, and level of severity of the incident.

216 00:40:41.110 --> 00:40:45.260 Armand Shahbazian (Seattle DOT): So there's, like, a little zoom in on… on some more granular information.

217 00:40:45.730 --> 00:41:08.180 Armand Shahbazian (Seattle DOT): So what we developed with our partner, Blue Systems is this direct integration. So we've given Blue Systems access directly to our 911 dispatch, so that as dispatches are created and adjusted, that information is being sent directly to the Blue Systems platform, which allows them to translate

218 00:41:08.180 --> 00:41:32.560 Armand Shahbazian (Seattle DOT): that information into MDS, and then specifically into the policy API. So there's a real-time connection to Blue Systems that allows for that. Blue Systems has developed a rule-based translation engine that assigns various policies to the different emergency types, and this was informed by our engagement with first responders and AV companies. And then we published that API

219 00:41:32.630 --> 00:41:53.779 Armand Shahbazian (Seattle DOT): And we provide access keys to different operators, so we know who is using it. The system is very easily replicable for different cities. If you use our same dispatching software, which many other jurisdictions do, it's called Central Square, it'll be very easy to integrate, and if you use a different dispatching software, it's not much work to,

220 00:41:53.780 --> 00:41:56.729 Armand Shahbazian (Seattle DOT): Create a copy view for this type of integration.

221 00:41:56.900 --> 00:42:05.629 Armand Shahbazian (Seattle DOT): But it also is respecting, you know, different city-by-city needs, by being able to adjust the rule-based mechanism for the policies.

222 00:42:05.930 --> 00:42:10.010 Armand Shahbazian (Seattle DOT): And like I've mentioned a few times, it's not just limited to autonomous vehicles.

223 00:42:11.330 --> 00:42:21.669 Armand Shahbazian (Seattle DOT): Today, you know, this project was really essential because of our collaboration with the fire department. What we've heard from the fire department is that they want

224 00:42:21.670 --> 00:42:33.270 Armand Shahbazian (Seattle DOT): policies to be created almost immediately, but there is, as you can imagine, some delay with the time that it takes to do this translation. The Blue Systems platform does the

225 00:42:33.270 --> 00:42:58.250 Armand Shahbazian (Seattle DOT): their work from receiving the dispatches to translating them, almost immediately, but where we had a hang-up is, previously, MDS was limited to a pull method for operators to access the information. So essentially, if you're an AV company, we give you access to the API. You have to pull that information on a set interval, and so what we arrived at was a 5-minute frequency to achieve

226 00:42:58.810 --> 00:43:22.899 Armand Shahbazian (Seattle DOT): what we called near real time, so that they would get new information every 5 minutes. One of the benefits of MDS2.1 is that we're able to now, move over to a push method, so that's something that we're continuing to work on with Blue Systems, which is to now shift from operators needing to pull this information to us being able to push information to them, which allows it to actually be in real time.

227 00:43:25.130 --> 00:43:45.999 Armand Shahbazian (Seattle DOT): This is also very timely with other developments, specifically California Assembly Bill Number 1777, which, starting this summer, very exciting, thank you, our California colleagues, will authorize emergency response officials to issue emergency geofencing messages, and would require companies to direct their fleets to avoid areas.

228 00:43:46.000 --> 00:43:49.879 Armand Shahbazian (Seattle DOT): Within 2 minutes of receiving emergency geofencing messages.

229 00:43:49.880 --> 00:44:08.449 Armand Shahbazian (Seattle DOT): So when we created this, initiative, a year… more than a year ago, this did not exist, and I think this really validates the, way that we're working to replicate this in other cities. And specifically in California, which California cities have lots of deployed AVs.

230 00:44:08.450 --> 00:44:17.169 Armand Shahbazian (Seattle DOT): The cities and local jurisdictions are now going to be empowered to create a system like this and use it to send geofences and emergency messages.

231 00:44:17.170 --> 00:44:37.060 Armand Shahbazian (Seattle DOT): out, which is very exciting. Here in Seattle, we don't have any deployed AVs, we only have AVs testing. So, you know, we love our system, it's… we're really fortunate to be able to test it in a simulated capacity, but we're very excited for other jurisdictions to be able to use it to actually benefit how AVs are operating on their streets.

232 00:44:39.160 --> 00:45:02.979 Armand Shahbazian (Seattle DOT): Something else that we're looking to work on, with Blue Systems as we, sort of expand the capabilities of the system is to be able to share out other information, such as work zones and temporary closures. So this might be, you know, there is an opportunity to automate this as well, but this could also look like us manually drawing in, where we know there are going to be, like, a parade or, a key,

233 00:45:02.980 --> 00:45:04.710 Armand Shahbazian (Seattle DOT): Piece of construction work happening.

234 00:45:04.740 --> 00:45:09.389 Armand Shahbazian (Seattle DOT): So that we're able to share that information out in addition to the real-time 911 data.

235 00:45:11.240 --> 00:45:35.669 Armand Shahbazian (Seattle DOT): This also builds on our existing initiatives, such as our real-time curb availability and digital curb space information. So, I… what we're trying to arrive at is that there's a lot of nexus here between how MDS and CDS work together. You know, if we're able to share real-time conflict zone, while we're also sharing areas that AV companies can pull over to do safe pickup and drop-off, there's a lot of opportunities for these digital platforms

236 00:45:35.670 --> 00:45:39.950 Armand Shahbazian (Seattle DOT): To provide a holistic set of data to operators.

237 00:45:42.050 --> 00:45:53.650 Armand Shahbazian (Seattle DOT): So to conclude, AVs are impacting cities today, and we're working to innovate to make sure that AVs improve the transportation system and provide safe and affordable access to places and opportunities.

238 00:45:53.790 --> 00:45:59.630 Armand Shahbazian (Seattle DOT): Thank you, and feel free to reach out if you'd like to learn more about our project.

239 00:46:02.290 --> 00:46:18.560 Michael Schnuerle (OMF): Thank you so much, Amand. It's great to hear an update on that, and I will say, I feel like your presentation is very well polished. I think you've probably given it a lot, or at least refined it over the last few months, so good job.

240 00:46:18.990 --> 00:46:19.350 Armand Shahbazian (Seattle DOT): Thank you.

241 00:46:19.900 --> 00:46:28.500 Michael Schnuerle (OMF): Alright, la- please ask Armand questions in the chat, if you have any, and Armand, feel free to share any resources or links you have.

242 00:46:29.100 --> 00:46:32.860 Michael Schnuerle (OMF): Next and last up is LADOT.

243 00:46:33.150 --> 00:46:38.589 Michael Schnuerle (OMF): And so I know we have multiple people. Lena, hi. Are you going to be sharing today?

244 00:46:39.820 --> 00:46:42.010 Halina Do-Linh (LADOT): I will. Vlad's gonna kick us off, but I'll be sharing.

245 00:46:42.010 --> 00:46:43.610 Michael Schnuerle (OMF): Okay. Great.

246 00:46:44.050 --> 00:47:01.560 Vladimir Gallegos (LADOT): Hey everyone, so Vladimir here at LADOT. I'm a supervising Transportation Planner here at LADOT, and part of the team that helps manage the commercial rideshare mobility that does permitting for taxis, scooters, robot deliveries, and

247 00:47:01.560 --> 00:47:12.829 Vladimir Gallegos (LADOT): Also, we do metro bike share and car share, and we also do, like, integration of data of MDS and how all that stuff works with our GIS group.

248 00:47:12.890 --> 00:47:15.450 Vladimir Gallegos (LADOT): our, Special Traffic Operations Group.

249 00:47:15.540 --> 00:47:25.999 Vladimir Gallegos (LADOT): And, I'm also here with my colleague and, the real brains behind a lot of things, Helena. Do you want to introduce yourself?

250 00:47:26.960 --> 00:47:44.859 Halina Do-Linh (LADOT): Yeah, hi everyone, my name's Helena Dolan, pronouns are she, her. I'm a data analyst on the commercial rideshare mobility team. And I think what Vlad's getting at is that we are able to use the MDS spec and some other specs to really break down the silos across departments and, you know, have more uniform workflows.

251 00:47:44.860 --> 00:47:51.820 Halina Do-Linh (LADOT): So to kind of, ground you all into the different processes we are talking about.

252 00:47:51.820 --> 00:48:16.480 Halina Do-Linh (LADOT): I want to start with just sharing the two different workflows that we're talking about here. So, our special traffic operations team, something that they do is they create traffic management plans. And right now, they are piloting this by using the Causeway One Network platform, which allows them to create a traffic management plan, and also what this platform does is it allows it to format it into the WZDX spec.

253 00:48:16.550 --> 00:48:41.389 Halina Do-Linh (LADOT): which stands for Work Zone Data Exchange Spec, and if you're not familiar with it, I believe this was a spec that was developed on the US DOT level, so it's more of a state-level MDS spec. It is not in active development right now, but it was the last spec that was, developed to address and standardize road events. And so, from that spec, the Causeway 1 network

254 00:48:41.390 --> 00:48:51.830 Halina Do-Linh (LADOT): platform makes the WZDX data feed, and they make that data feed available to the different navigation apps. So, when I say navigation apps, I mean

255 00:48:51.830 --> 00:49:11.709 Halina Do-Linh (LADOT): Google Maps, Apple Maps, and Waze, and then that is automatically available, and anyone who is using, you know, Google Maps to get somewhere, and then it's available for them to see. So what was great about the Special Traffic Operations team using this is now their traffic management plan and the road events that they're using or creating can now be available easily to the public.

256 00:49:11.710 --> 00:49:34.820 Halina Do-Linh (LADOT): And what we're doing on our side, on commercial rideshare mobility, is often, if they are creating a traffic management plan, and they need to inform us that the different modes that we are permitting, such as micromobility, taxi, personal delivery devices, and all the other ones that Vlad mentioned, we need to work with them so that we can get that data and then create a MDS policy to share out with our operators.

257 00:49:34.820 --> 00:49:53.929 Halina Do-Linh (LADOT): Because our operators aren't necessarily using, you know, these navigation apps to determine where or where they shouldn't deploy. And so what our workflow looks like when we are creating a geofence policy is we are using our partner's Blue System Mobility Manager platform, and what they do for us is they format it into the MDS spec.

258 00:49:53.930 --> 00:50:18.589 Halina Do-Linh (LADOT): and then send that information out through an MDS Policy API, and then it gets shared with our private transportation operators. And so what we have here are two very separate workflows, and there's not really a way to connect them. And I think something that you have all dealt with in the past is, you know, often when, you know, we heard this from Boston, when bureaus or divisions are sharing data with each other, it's, like, in email, or it's

259 00:50:18.590 --> 00:50:32.130 Halina Do-Linh (LADOT): in PDF, and so that's what the Special Traffic Operations team was often doing with us, is they were sharing this traffic management plan in a PDF format, which does not contain, you know, meaningful spatial data that we can pull from that PDF.

260 00:50:32.220 --> 00:50:46.269 Halina Do-Linh (LADOT): And so, from this example, we were able to create a connection between the WZDX feed and when we are creating that geofence policy, so that we could better automate and programmatically,

261 00:50:46.270 --> 00:51:04.540 Halina Do-Linh (LADOT): create a geofence policy to then share with our operators. And so we were able to pilot this with the most recent, Ciclovia event that happened in April in LA, which is where all of our streets are shut down and are available for just, like, active transit mode, such as biking, walking, scootering, and all those things.

262 00:51:05.650 --> 00:51:30.579 Halina Do-Linh (LADOT): And so this is what it looks like on the technical side, and this is what the WCDX data model and data feed looks like. So I know this is a lot of information, but just to show that from that one data feed, you can see multiple road events, and that road event then has a set of geometry associated with it, it has a set of core details associated with it, it has some event properties, and so on and

263 00:51:30.580 --> 00:51:32.500 Halina Do-Linh (LADOT): and so forth. And…

264 00:51:32.510 --> 00:51:57.220 Halina Do-Linh (LADOT): From all of this data, what I'm pulling from is the core details, so I'm looking for that Ciclovia event, and then I'm pulling the geometry associated with it, as well as all of the related road events from it. And what that looks like, if I keep scrolling down, is this. So from that TMP plan, we are able to pull the reference points and the road segments, and this is what this traffic… special traffic operators are using.

265 00:51:57.220 --> 00:52:04.940 Halina Do-Linh (LADOT): what the engineers are using when they're on the ground for this event. And so this is the reference points and road segments, again, for the Cyclavia event that just happened.

266 00:52:04.940 --> 00:52:26.640 Halina Do-Linh (LADOT): And for me, when I'm wanting to create a geofence, I don't need these reference points necessarily, and I just need the route. I just need to tell the different micromobility operators and the PDDs and autonomous vehicles, just stay out of the route for this temporary time. And so I just pulled the route and the segments that I needed, and then I created a 50 meter buffer around to create the geofence that we needed.

267 00:52:26.640 --> 00:52:31.149 Halina Do-Linh (LADOT): And then this last layer here stands for CRM Geofence, and…

268 00:52:31.420 --> 00:52:49.480 Halina Do-Linh (LADOT): kind of going back to that, before, you know, we had that connection, what would happen is that PDF would get sent to us from STO, or Special Traffic Operations, and then someone on our team would look at that PDF, and then look on a map on, like, you know, ArcGIS Pro or something, and then manually draw it out to match it as best as possible.

269 00:52:49.480 --> 00:53:12.790 Halina Do-Linh (LADOT): Which can, you know, there's a lot of error that could happen there. So it's much better that we can, like, pull from the source exactly. But the CRM geofence, what that represents is the manual geofence that someone on our team drew. So just showing that, you know, this really does work, where we can automatically and programmatically pull from the data and still get, like, similar and same results.

270 00:53:12.790 --> 00:53:18.129 Halina Do-Linh (LADOT): That we want. And another… oh yeah, go ahead, Vlad, if you wanted to share.

271 00:53:18.290 --> 00:53:36.930 Vladimir Gallegos (LADOT): So, just as a situation, like, right now we're dealing with large events in the city of Los Angeles. We are having to deal with, like, the traffic signal systems coordination, the transit shuttles support team, the rideshare coordination, the micromobility, which is under our team, but also the parking management team, and then the emergency management.

272 00:53:36.930 --> 00:53:43.140 Vladimir Gallegos (LADOT): you know, team. All these teams have different ways and different types of maps in how they're thinking about these things.

273 00:53:43.510 --> 00:53:51.330 Vladimir Gallegos (LADOT): And there are specifications that are… are not up-to-date, that don't meet every month, that don't… that aren't up-to-date.

274 00:53:51.460 --> 00:54:06.509 Vladimir Gallegos (LADOT): And not all states, not all cities use these things. This just happens to be a legacy specification that some people in the city in California use that we are trying to find and to hook into, using MDS as our base, right?

275 00:54:06.740 --> 00:54:16.410 Vladimir Gallegos (LADOT): all your cities have some kind of mapping or some system, all your states have something that has… is like an STO software. The question is, like, what do you need to hook into?

276 00:54:16.480 --> 00:54:29.300 Vladimir Gallegos (LADOT): in your state, in your city, right? And how is it that MDS can hook into there and enrich that data, or kind of work that out, you know? It would be really great to do a survey of, like, what in your states

277 00:54:29.300 --> 00:54:43.229 Vladimir Gallegos (LADOT): are your, kind of, your causeway, your systems of reaching out and sharing this type of data, because I think that is that… a trajectory that MDS and OMF can really solve.

278 00:54:43.590 --> 00:54:50.209 Vladimir Gallegos (LADOT): And because we don't… we don't know how to update this spec that hasn't been updated for a long time, right?

279 00:54:50.570 --> 00:54:52.930 Halina Do-Linh (LADOT): Yeah, but we're leveraging it, which is great.

280 00:54:52.930 --> 00:54:53.939 Vladimir Gallegos (LADOT): Leveraging it, yeah.

281 00:54:54.160 --> 00:55:09.720 Halina Do-Linh (LADOT): And the last thing I'll share here is, just going back to my very rudimentary slides, is, you know, a way that we can expand this, too, is by utilizing CDS data. So, for example, our parking management team, we recently, was at Compost, did a SMART grant, and…

282 00:55:09.720 --> 00:55:20.179 Halina Do-Linh (LADOT): mapped out all of the different, you know, assets and things in downtown. And so, thinking forward how this could really, you know, we could expand this with our special traffic operations team is…

283 00:55:20.180 --> 00:55:45.180 Halina Do-Linh (LADOT): If they say, hey, there's a road closure or an event happening here, whether it's the Oscars or Ciclovia, and I need to make a MDS policy API, but then our special, or our… there's so many names… but then our parking management team can pull all this information in, and then see, okay, in this geofence that's happening, which parking meters are being affected by that? Which assets are being temporarily affected by this

284 00:55:45.180 --> 00:55:58.829 Halina Do-Linh (LADOT): geofence. So we could really utilize these different specs to then create, you know, the more comprehensive geofence that, you know, creates a policy to not only inform our private operators, it informs the general public.

285 00:55:58.830 --> 00:56:07.369 Halina Do-Linh (LADOT): And it informs our internal staff about what assets are being impacted, and this is all in, like, a standardized way. So just really excited thinking about, you know.

286 00:56:07.430 --> 00:56:16.800 Halina Do-Linh (LADOT): How we can use these different specs and standards to just break down the silos across our departments and our teams, and work more efficiently in the city.

287 00:56:18.100 --> 00:56:19.040 Halina Do-Linh (LADOT): Thank you all.

288 00:56:22.020 --> 00:56:23.009 Vladimir Gallegos (LADOT): Yeah, thank you, everyone.

289 00:56:23.010 --> 00:56:28.359 Michael Schnuerle (OMF): Yeah, that's great. Great presentation. I like to see the detail.

290 00:56:28.490 --> 00:56:40.000 Michael Schnuerle (OMF): In CDS, we had some presentations around how cities set up their digital infrastructure and their workflows internally and externally, so something like that is really good to see for MDS as well.

291 00:56:40.210 --> 00:56:45.360 Michael Schnuerle (OMF): I had a question in the chat for the events,

292 00:56:45.720 --> 00:56:58.829 Michael Schnuerle (OMF): the event Cyclavia. We have Cycluvia in Louisville, which we modeled after LAs, and L-O-U is for Louisville, so I say them… I say Cycluvia by default.

293 00:56:58.830 --> 00:57:01.859 Vladimir Gallegos (LADOT): I thought it was an accent. I thought it was an accent. I was like, okay.

294 00:57:02.080 --> 00:57:06.290 Michael Schnuerle (OMF): Cycluvia, yeah, you're Cyclavia, of course, right?

295 00:57:06.540 --> 00:57:15.530 Michael Schnuerle (OMF): But, do you… are you getting… you mentioned the slide, or the document, scooter, robo… robot delivery, and AV ride hail companies like Waymo.

296 00:57:15.660 --> 00:57:25.009 Michael Schnuerle (OMF): how are they… how do you know they're ingesting the MBS Policy API, or is that, like, their main method to get the information, or are there other methods, too?

297 00:57:26.700 --> 00:57:34.740 Vladimir Gallegos (LADOT): we are directly… we have a feed that we send through Blue Systems, that Blue Systems set up, that sends them policy. The thing is that they don't…

298 00:57:34.850 --> 00:57:40.750 Vladimir Gallegos (LADOT): digitally acknowledge the signature of receiving. They actually will send us an email saying, we have

299 00:57:40.910 --> 00:57:42.729 Vladimir Gallegos (LADOT): We have received it, thank you.

300 00:57:43.080 --> 00:57:43.990 Michael Schnuerle (OMF): Oh, okay.

301 00:57:44.280 --> 00:57:45.300 Vladimir Gallegos (LADOT): Or Pierre, here.

302 00:57:45.300 --> 00:57:45.929 Michael Schnuerle (OMF): Yeah, yeah.

303 00:57:45.930 --> 00:57:58.640 Pierre Bouffort (Blue Systems): Yeah, and just to chime in very quickly there, we also have, as you remember, in version 2.1, I've pushed for authentication of the policy API.

304 00:57:58.640 --> 00:58:11.360 Pierre Bouffort (Blue Systems): Meaning we now have the possibility to, you know, request operators to authenticate when fetching the policies, which, technically speaking, allows us to get logs of who fetched the policies, who receives the policies, and when.

305 00:58:11.360 --> 00:58:23.829 Pierre Bouffort (Blue Systems): So that allows… that's also one of the use cases and one of the reasons we wanted to push for this authentication system, because then that means we have technical logs of who received the policies, who fetched them, who received the push, and when.

306 00:58:27.080 --> 00:58:32.280 Michael Schnuerle (OMF): Great. So is that something that is implemented, or it will be when…

307 00:58:33.040 --> 00:58:33.880 Pierre Bouffort (Blue Systems): Oh, it is implemented.

308 00:58:33.880 --> 00:58:35.189 Michael Schnuerle (OMF): 2.0. Yeah, it is.

309 00:58:35.420 --> 00:58:37.230 Michael Schnuerle (OMF): Great, so you do know that. Great.

310 00:58:37.960 --> 00:58:40.179 Michael Schnuerle (OMF): Well, great presentation, thank you all.

311 00:58:40.370 --> 00:58:46.780 Michael Schnuerle (OMF): We're at time, but if anyone has final questions, please feel free to ask them. Thank you.

312 00:58:47.090 --> 00:58:50.290 Michael Schnuerle (OMF): Vlad and Alina for that presentation.

313 00:58:50.700 --> 00:58:59.689 Michael Schnuerle (OMF): June 4th is our next meeting, so, you know, in the meantime, think about how you can use MDS 2.1 and you can get to know it.

314 00:59:00.070 --> 00:59:12.060 Michael Schnuerle (OMF): from our prior meetings, recordings, and online documentation. And let us know if you have any barriers to implementing that, or questions. We're here to help.

315 00:59:12.500 --> 00:59:23.620 Michael Schnuerle (OMF): And thank you for the great presentations today, and like I said earlier, if you want to present at a future meeting and you're on this call or watching the recording, let us know.

316 00:59:23.740 --> 00:59:26.929 Michael Schnuerle (OMF): And we can talk to our steering committee and arrange that.

317 00:59:27.640 --> 00:59:28.609 Michael Schnuerle (OMF): Thank you all.

318 00:59:30.040 --> 00:59:30.900 Vladimir Gallegos (LADOT): Thank you all.