Web conference notes, 2020.05.07 (Provider Services wg)

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

Attendees

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)

Agenda

Announcements

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.

Background/context setting

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

Two Approaches

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

Key discussion questions

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?

Minutes

Notes by Matt Davis (Populus):

Provider Working Group 2020-05-07 Notes

Issue #374 Docked Bike Share Systems

How to integrate docked system information with MDS?
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
GBFS historically focused on consumer facing data, MDS more focused on providing information to planning and regulatory bodies.
PR #427 (https://github.com/openmobilityfoundation/mobility-data-specification/pull/427) adds a /stops endpoint to MDS.
PR #441 (https://github.com/openmobilityfoundation/mobility-data-specification/pull/441)
- "Vehicle" and "dock" entities
- /stations endpoint provides a snapshot of station status. Mixes intrinsic/static properties like location and docks with changing info like which vehicles are there.
- /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".
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.
Brady Law from Lyft called out the overhead of implementing additional API endpoints.
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.
Folks encouraged to comment on issues to keep discussion going.