Web conference notes, 2020.05.07 (Provider Services wg) - Docked Micromobility Session

• biweekly call at 11am PST / 2pm EST
• Join Zoom Meeting https://zoom.us/j/627957166

Meeting ID: 627 957 166

One tap mobile:

• +16699006833,,627957166# US (San Jose)
• +19294362866,,627957166# US (New York)

Dial by your location:

• +1 669 900 6833 US (San Jose)
• +1 929 436 2866 US (New York)

Find your local number: https://zoom.us/u/aeJWJsuC2b

• Brady Law (Lyft Software Engineering)
• Heidi Guenin (MobilityData IO)
• Tim Millet (MobilityData IO)
• Jascha Franklin-Hodge (OMF)
• Neil Goldader (E&A)
• Eric Mai (E&A)
• Michael Schnuerle (OMF)
• Bill Dirks (Ride Report)
• Kegan Maher (City of Santa Monica)
• Victor Perron (Blue Systems)
• Matt Davis (Populus)
• Raja Gangopadhya (Remix)

• Michael Schnuerle - Intro Director of Open Source Operations role

• Discuss Working Group Steering Committee structure: 5 contributors voted in by WGSC members. Fill in membership per the charter.

• Issue #374 - Docked Bike Share Systems

• Issue #428 - Modify /trips to represent docked start/end locations

• Issue #438 - Modify /status_changes to represent docked event locations

• GBFS approved approach to dockless /stops PR #219

• Proposed Approach #1: New /stops endpoint

  • PR #427 - MDS-Provider Stops Specification

• Proposed Approach #2: New /stations and /station_status_changes endpoints

  • PR #441 - Add Docked Bikeshare Systems to MDS

• How do we align our approach with the work being done by MobilityData on virtual stations and geofencing in GBFS? (see NABSA/gbfs#219) How does GBFS approach to geospatial references align with MDS Geographies?

• Does our approach to adding per-vehicle-type capacity/availability information make sense and align with direction of GBFS?

• Do we need an historical view of station status available via MDS? If so, should it have its own endpoint or be supported through an existing endpoint?

• How to best share common data types (like stops) across multiple MDS APIs?

Notes by Matt Davis (Populus), supplemented by Michael Schnuerle (OMF):

Provider Working Group 2020-05-07 Notes

Michael Schnuerle intro and talk about Working Group charter as defined in bylaws. By May 21 meeting will have proposal for a revised charter. Need 5 elected Steering Committee members.

Issue #374 Docked Bike Share Systems

• How to integrate docked system information with MDS?

• Hunter from LA created docked bike share issue in Oct 2019

• GBFS has definitions for this in their PR #219

• Don't want to only copy GBFS, but find a good way for MDS to fully represent docked systems.

• Add docked status changes (issue #438) and docked trips (issue #428)

• Comparison/discussion with Tim Millet and Heidi Guenin on the work integrating dockless with GBFS: https://github.com/nabsa/gbfs/pull/219

• Mobility Data contracted by NABSCA to work on GBFS. Google and Lime are using it in 2.0, but in GBFS approval comes once there is a public feed.

• GBFS historically focused on consumer facing data, MDS more focused on providing information to planning and regulatory bodies. Kegan notes that this will not replace GBFS in any way.

• Proposal 1 PR #427 (https://github.com/openmobilityfoundation/mobility-data-specification/pull/427) adds a /stops endpoint to MDS.

  • Neil at E&A - stops data type, similar to GBFS stations/docks, much pulled from there
  • Unique ID for stop, MDS specific. Can be point, or geojson feature collection via geography_id
  • Also related to GTFS so keeping in mind aligning on future transit use
  • Vehicle types in MDS, each capacity count, available, disabled

• Proposal 2 PR #441 (https://github.com/openmobilityfoundation/mobility-data-specification/pull/441)

  • Remix, Raja Gangopadhya - use case is for historical analysis. For compliance and planning.
  • "Vehicle" and "dock" entities
  • /stations endpoint provides a snapshot of station status. Differs from proposal #1 since it has a timestamp filed to capture historic time.
  • Mixes intrinsic/static properties like location and docks with changing info like which vehicles are there.
  • Array for vehicles - list of each vehicle instead of enumeration by type. Docks has same kind of array.
  • /station_status_changes describes the state of the station after some change event. Its payload includes the same information as /stations plus the event that lead to the change. "represents the state of the station after an event listed in the change_type_reason field".

• GBFS

  • Station_Status and station_information - would like to keep the same GBFS names where possible
  • Historic and trip data are not in GBFS, and should only be in MDS since it’s an authenticated data feed.
  • Vehicle types - main difference between them is there is an ‘Other’ in GBFS
  • Folks want to make sure information that's useful to travelers is in GBFS.
  • Heidi Guenin proposes more close collaboration between GBFS and MDS spec development to align definitions, meetings instead of just digitally referencing.

• Brady Law from Lyft called out the overhead of implementing additional or unnecessary API endpoints for providers.

  • One concern was backfilling. OMF could say backfilling data may not be possible - offer guidance.
  • 0.4.1 has a beta feature idea so things can be flagged that way in this spec.
  • Roy Williams from Lyft points out that not all stations are online all the time.

• Questions around whether cities should need to integrate MDS and GBFS in order to get the data needed to answer questions.

  • Jascha points out it's preferable that cities need only integrate with one data standard, for example that's why the /vehicles endpoint was developed so cities didn't need GBFS for live info.
  • Could create for realtime scenario first, then architect for inclusion if historic later if there is a demand, like we did with vehicles. Otherwise risk complexity and burden for providers.

• Folks encouraged to comment on Github issues to keep discussion going.