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), 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.