MDS Working Group

• Every other Thursday at 9am PT / 12pm ET / 6pm CET

Zoom Registration Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York) - though we encourage Zoom

Note: Attendees register upon entry into the Zoom meeting. An attendee count will be posted here after the meeting.

25 Attendees

Main Topics

• Status of MDS 1.2
• MDS 2.0 Release Planning
  • Review release plan page
    • Features: Modes Infrastructure, 3 new Modes, Policy Reimagining, breaking changes
      • Leverage 3 Member Networks for specific mode discussions
    • Schedule drafted
  • Goal Setting for 2.0
    • WG member thoughts for other features to consider
    • Bring your concrete use cases and city/org support with your ideas
  • Could have breakout meetings for certain topics

WGSC Meeting Organizers

• Host: Steve Brining, Blue Systems
• Facilitator: Michael Schnuerle
• Outreach: Steve and Michael
• Note taker: Steve Brining, Blue Systems

• If you’ve added an issue and think it should be in 2.0, put a comment to that affect in comment area of the issues
• Also, if you haven’t put anything yet in github, make issue or come to next meeting.
• JFH: We’re seeing a lot more cities roll Policy into their permits. Wants to find out from cities using this, how is it working for you?
• Note about next meeting date/time and that feedback is welcome
  • Next meeting is two Thursdays from now, November 11^th
    • Holiday > Veteran’s day, will need to work around

• JFH: Rolling out privacy principals and website just went live for it
• AG noting: Here is more information about it - we’re thrilled to be a part of it! -> https://www.openmobilityfoundation.org/endorsing-the-privacy-principles-for-mobility-data/

• MS – going over 1.2 features
• Highlighting policy requirements
• Timeline was 10 months, starting in January
• Board just approved this release, Kegan Mahar and MS working on launching early next week. Will be ready and available on main page of MDS repository
• Direct link: https://github.com/openmobilityfoundation/governance/wiki/Release-1.2.0

MS: Review of release plan: https://github.com/openmobilityfoundation/governance/wiki/Release-2.0.0

MS: Biggest feature is Modes

• How do we make that happen within MDS structure and have a document for guidelines and what is wanted. Setting up framework is important
• We wanted to launch these from the start since they are being incorporated into cities already.
  • Self-driving delivery bots
  • Car share
  • Passenger services\taxi
• Reminder that there are member networks on these three modes already that OMF members can join

MS: Also want to cover policy reimagining and may have a few meetings for policy specifically

• Noting since it’s 2.0 that we can break things here
• MS’s Siri kicks in “sorry, I didn’t understand that”
• AG: Ha! Maybe Siri doesn’t want to break things

MS: Going over open issues page that we can go over and asking and if you’ve added an issue and think it should be in 2.0, please speak up so we can discuss here. https://github.com/openmobilityfoundation/mobility-data-specification/issues

MS: Opening the discussion to issues that have already been created or ones that you think should be created

1. Frederic Robinet talking about https://github.com/openmobilityfoundation/mobility-data-specification/issues/705

• MS - you’re wanting to
• Hannah Adeponu, city of Omaha I think we would benefit from this information in Omaha
• MS: Thoughts on how this could fit into MDS
• JFH: This could be part of the Modes work in the vehicle attributes field (trip attributes and some other fields will also be new). We’ll need to sort out the rules for these going forward
• MS: Would be worthwhile to find out what’s important to people, like swappable batteries mentioned here.
• EM: Noting a similar discussion on capturing vehicle attributes, and wondering which need to go on MDS side vs GBFS side
• JFH: noting: https://github.com/NABSA/gbfs/pull/370

2. Jean Kao: I added the request for a field around vehicle locks. We’ve heard this is an issue with some of our city customers and wondering if other cities would be interested in having this information. https://github.com/openmobilityfoundation/mobility-data-specification/issues/706

• JK: Request from Oakland on finding out if 1- the vehicle has them and 2- if they are being used. It’s a requirement for Omaha
• EM: Talking about a requirement that trips can only end if scooter locked/start if locked
  • Would need to infer lock status based on most recent event versus a stream of lock/unlock events coming in.
  • Maybe could add this as extra information on a trip end event
• JJ: Noting just because there is a lock event doesn’t mean it was locked and parked properly, so could be challenging to enforce proper parking.
• EM: Question about use case > JK: City is reporting some don’t have locks at all?
  • JK: Hearing there are some vehicles without locks
  • JJ: Lock-to is a requirement in Oakland
  • EM: Noting some of these vehicles likely came from another operating area that doesn’t have this rule.
• JFH: Interesting point, that you can’t be sure that a vehicle reported to a jurisdiction isn’t natively from there and abides by all the rules for operation.

3. FR: Seeing more hardware devices and sensors being added to vehicles in the street, and would be interesting to access some of this data

• MS: What is an example

• FR: Noting Spin adding extra information

• MS: Link to share?

• FR: https://www.theverge.com/2020/12/17/22178595/spin-scooter-drover-ai-parking-riding-nyc

• HA: https://www.washingtonpost.com/technology/2020/12/17/escooters-ford-spin-detection-equipment/

• MS: We’d need some use cases for how to use this information and if anyone has thoughts on how to add this to MDS, make an issue in GitHub

• BH: A lot of interesting technology going into vehicles right now but not sure adding to MDS is right move yet, but down the road, yes.

• MS: Have you gotten some requests from cities that would like to see some of that information?

  • BH: Too soon, things could be different in 6 months
    • Challenging to provide a specific piece of data to the city

• MS > JJ: Can you provide a little more info on this?

  • EM: Have had at least one city ask us about sidewalk data. Wondering what is an appropriate level of aggregation.
  • Only seems useful if you’re going to fine a rider or operator
    • PP: Who may or may not pass that fine on
  • MS: reminding about Provider reports, which allows for aggregated counts of things over time, that this could be used.
    • EM: Reminds me of a different issue, geography is by polygons and nodes vs maybe a network for sidewalks
  • JFH: If anyone working on the concept of how we define a street network that’s aggregated, would like to see that, thinks broadly speaking if we had in MDS a data structure that allowed us to reference pieces of the street network and apply data to nodes and segments. Supports idea of starting work on how to express this concept and apply to Agency, Provider, and even Policy
  • ZB: a network geography makes sense for Bus routes
  • HA: or for protected/unprotected bike lane networks
  • MS : Getting data directly from provider may be complicated in relation to street segments

• JFH: We’re seeing a lot more cities roll Policy into their permits. Wants to find out from cities using this, how is it working for you?
  • Heard anecdotes on things that could use some work
  • As policy use grows, would be great to apply lessons learned back into the spec.
  • Feel free to throw into a discussion or even an issue
  • Would like to see MDS 2.0 bring Policy up to a level of maturity similar to Agency/Provider
  • FR: Have an issue on clarifying list
  • FR: Some local IT doesn’t have the capability of reading the endpoint so they made a flat file for them. Discussed with Ben\Bird on adding to 2.0
    • MS: Asking FR to make an issue

MS:

• https://github.com/openmobilityfoundation/mobility-data-specification/issues/714
• https://github.com/openmobilityfoundation/mobility-data-specification/discussions/715

BH: Operators implement policies in a different way. Some operators need a polygon vs a point

• Hard to do geographic joins if you’re dealing with large shapes
• Would like to have some guidelines on shape size, overlays of zones on top of each other and how it gets implemented. Example of a no ride zone not also being a no park zone.
• PP: Could we define a standard for “close enough” so providers could generate simplified approximations?
• FR: Totally agree on the polygon complexity, even for web
• PP: (Perhaps with reference to the expected precision of GPS)
• EM: Talking about grouping policies to similar zones, might be useful on ways to group them together based on regulatory similarities.
• BH: Talking about the translation from planning to what then shows up on a map for users

BH: Also thinks previous policy should be a mandatory field, since hard to track

• JFH: There is a mechanism baked into MDS to replacement policies.

MS: Noting, for a policy was having zero time instead of zero count of vehicles.

MM: Intention was to, if you have tons of policies, you won’t use the flat file. If you have any complexity at all, you want to set up a server for the active policies. Lacuna server allows to serve for active policies

• MS: You can search for just active policies?
• MM: Yes
• MS: Can you leave a comment?
• MM: yes, and on previous policy being optional, that some may not have a previous policy. Also, if you know the end dates, it’s easy to determine. If there’s no end date, you need to track it down.
  • You may terminate the policy early
  • If you publish policies monthly, then some could not be renewed.
• BH: See a lot of back and forth on how this should be drawn up.
  • Lime doesn’t pull all current policies, there is a lot of looking at previous policies to see what needs to expire.
  • A lot of QAQC
  • There’s a bit of back and forth going on to figure out where to go on policy

MS: Does policy need pagination support?