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

• Kickoff - Steve Brining, Blue Systems
• Sharing MobilityData Survey link
• Review of Modes work so far - Michael Schnuerle (OMF)
• Task Force Updates
  • Modes Architecture Task Force
    • Volunteer work on feature branch - see PR #745
    • Specific mode updates
      • kiwibot/san jose
      • taxi/lacuna/LADOT/SFMTA
      • carshare/oakland/populus
  • Policy Reimagining Task Force
  • Unification Task Force

WGSC Meeting Organizers

• Host: Steve Brining, Blue Systems
• Facilitator: Michael Schnuerle, OMF
• Outreach: N/A
• Note taker: Steve and Michael

1. Continue work in Task Forces
2. Someone can make a proposal for Policy discussions:
   • defining a what a trip is?
   • what is the lookback period?
   • are fees part of policy object or outside?
   • implement the idea of a device heartbeat

• MobilityData survey: https://mobilitydata.typeform.com/21IndustrySurv
• They manage the public GBFS specification

• Review of Modes work so far - Michael Schnuerle (OMF)
  • MS – trying to set up the framework to add new modes
    • Then work on adding modes into MDS and make sure the architecture meets the needs of each mode based on real world experience
    • Have a good blueprint but want to move forward into next few weeks
  • MS – following up on an email to the working group on adding
    • Got a few replies from Lacuna and LADOT
      • MM did a lot of work on a pull request (PR #745)
  • On PR # 745 https://github.com/openmobilityfoundation/mobility-data-specification/pull/745
    • MM – Phase one, made minor changes
      • Fair amount of work needed for new verbiage to define the different modes
      • Placeholder introduction to these docs is at the top of the PR
      • Wanted to go over the structure of it today, and avoid as much redundancy as possible
        • Worked on avoiding overlap in event types
        • For example if you need a state, it won't affect the top level list.
        • For micro mobility, you can see the valid states that pertain to that mode
      • Also for event times, worked on the same updates, but for now it's a 1:1 mapping.
      • Finally, looking for feedback on the structure, reminder that you can leave comments on the PR, proofreading welcome.
    • SN - I like it! (referring to the PR so far)
• Task Force Updates
  • Modes Architecture Task Force
    • Volunteer work on feature branch - see PR #745
    • Specific mode updates

• Kiwibot providing a little background of their work so far

  • CC – talking a little about what they've done so far as a business perspective

    • Will map areas focusing around where the Olympics are
    • Pilot will start in around 2 months
• WH – is there any risk to make changes to something that's in the field before it's finalized?
  • MS – all three are being used in the field
  • WH – may be some issues if vendors don't want to change
  • MS – for taxi situation, E&A will rework, but since they are working on the ground, shows there is a need for it.
  • WH – great to field test concepts, but don't want to prioritize one city's need over 99% of the other cities.
  • Discussion on implementing a final architecture based on early implementations, and being careful not to consider early work final.
    • MM – for example in LA we're not considering it the final.
    • MS – nothing preventing other groups from getting involved either.

• AD – Has been working on the modes task force and open to suggesting if anyone else on the Lacuna side has them but working
  • On NG's PR for taxis

• No updates on car share today

Policy Reimagining Task Force Update:

• JK – JK and SB working together on the policy task force
  • Have meeting notes posted in the task force area
• JK – want to think about where fees might fit into this. Is it a part of policy or a separate endpoint.

Unification Task Force Update

• MS > MM I know you've been busy with modes, is there anything to share
  • MM – working on a document and permission to share from LADOT\Jarvis
• MS > WH any comments on unifications
  • WH – not at this time, will go with MM's work at this time.

JJ - Related to the fees discussion, it would be great if this can spark some agreement and OMF recommendation on what is considered a trip, as well as the bigger discussion about things like lookback periods, and other policy related metric calculations.

• JJ – in context of policy discussion, it would be great if there is a standard for defining a trip, related to fees.
  • On evaluating against deployment requirements as well.
• JJ – some aggregators might filter out trips that might be too short or too long, as these could factor into fees. They consider what is a trip differently than cities.
• MS > JK do you have problems defining trips?
  • JK – sometimes what we see as a trip may not be a trip in real life. For example a 10 meter trip.
• WH – has own filtering rules that they work with cities on. Noting that state machines are hard. Short trips, phantom trips, orphan trips that leave the ROW and disappear. RideReport does some filtering, but may be at state machine level.
  • WH – should be 1:1 with the operator's own billing system.
  • JJ – Yes, this is what I'm talking about
• PP – are you worried about trips the state machine produces that aren't real or something else?
  • WH – state machine we defined has little to do with the state machine and business logic that's out in the real world. How can we create a stronger parallel between actual business logic
• MD – recently an operator brought up an issue with a definition of parking. The operator wanted to define it as a visit by an employee would reset the dwell time count vs the city saying that this doesn't matter, it's the static time vehicle not moving.
  • On state machine conversion, not resonating as much as information flow
  • WH – noting that sometimes the vehicle isn't there
  • MD – it's nice when it's spelled out in the standard but in practice we're finding out cities want different things
  • WH – where we need to work with MDS where a lookback period, for example, needs to be specified in order to be standard MDS
• WH – today vendors are doing things on behalf of cities that are causing vendors a lot of pain
  • JJ – agrees with this, wondering if any cities have asked for a specific lookback period? Brings up just pointing out it may not be a policy issue. Wants to try to reduce splintering related to lookbacks and trip definitions.
    • WH – yes, they have
    • MD – a city told them it was advantageous to tune the lookback period based on the needs of the market. A short lookback in an area with a lot of loss so removing them sooner. Versus a longer lookback where there is less scooter loss
    • BH \ Lime – were talking about an area where they were having an issue, two things
      • Vehicles have better batteries and can side on streets much longer
      • On flipside, if lookback period longer, have the reverse, where scooters that aren't where they think they are (vandalized, stolen) that they don't really want those showing. Spend a lot of time in talking with cities are discrepancies in how they count trips.
    • EM \ Superpedestrian – have gone back and forth with cities on billed trips vs attempted and what constitutes a vehicle being parked. It's a real-world implementation on what means it's parked or not parked.
      • Also wants to respond to conversation on how the standard should drive city policies. Talked to a city on being parked too long. City asked for them to send an event that would reset the count for how long it had been deployed.
        • WH - @Emmett yes, we had a city ask for exactly this. It breaks the spec! Luckily we convinced them to take another approach…
        • SMB - Is that like a heartbeat, with the vehicle saying "I'm still here and ok and not stolen/broken?"
          • AD - Has a heartbeat event been proposed previously? I think there was a discussion about that a while ago but I might be not remembering correctly. I agree that it could be useful
          • MD - @Steve, yes. I think it could actually be a big help.
          • MS – can't you use vehicles as the heartbeat?
          • EM – we use vehicles feed as a record of status changes
          • WH - Heartbeat is smart. Then we could say at a technical level "the heartbeat period is always X" but cities could still say "the consequence of a failed heartbeat is Y"
        • WH – maybe we could solve with documentation

PP - Is it worth thinking about the philosophy of process for adopting existing implementations / encouraging implementations to be created with adoption in mind. It brings to mind the way the W3C has developed HTML and HTTP standards, sometimes playing catchup to browsers and servers and sometimes leading the way. How can we think about what practices to encourage for implementations where we don't have a spec yet, and what practices can we follow to create specs people are more likely to actually implement?

• These questions were brought to my mind by the discussions about other modes, and/or the taxi implementation my company, Lacuna, is working on.
• WH - Agreed, Peter! You said it much better than me, that's exactly what I'd like to see
• SN - In my view the push/pull is created by adoption. If you have an implementation that doesn't support the needs of many, or is hard to implement, it won't get adopted and the standards body gets to play the role of arbiting between an existing implementation and wide adoption.
  • Implementers develop insight on what would be a good specification.
• PP - So better to prefer implementation first?
• SN - Yes, in my opinion. And then, if you want wide adoption, you would need to be open to rearchitecting and sometimes throwing out working code.
• Angela G (OMF) - It's worth thinking about and discussing. It's also important that these conversations both exist in this space and also that we engage with our organization's leadership – OMF's strategy committee, Technology Council, our Board of Directors. This is something we do regularly (for example, we brought some of these high-level strategic questions to our Strategy Committee last week). Another thing that is important to consider is what outcomes do we expect or need as a result of these discussions.