Web conference notes, 2023.12.07 (MDS Working Group)
MDS Working Group
- Monthly on Thursday at 9am PT, 12pm ET, 5/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
- Intro and announcements
- MDS 2.0.1 Patch Release
WGSC Meeting Organizers
- Host: Pierre Bouffort, Blue Systems
- Facilitator: Michael Schnuerle, OMF
- Outreach: Michael Schnuerle, OMF
- Note taker: Jean Kao, Populus
- Leave comments on open and closed MDS 2.0.1 items
- Will be completed before Dec 15, so leave comments ASAP
- Decisions on Vehicles wording for #882
- /vehicles is snapshot of all vehicles deployed at least in the last 30 days.
- /vehicles/{device_id} will return info on any vehicle ever deployed, present only the last known information about that vehicle
- 23 Attendees
- OMF Slides
-
Recording - Password
A&RmU9L1
Request
- please leave comments on the proposal
- will assume no comment as approval to move forward
Proposal
- /vehicles endpoint should return historical data for minimum past 30 days
- any older data can be retrieved on a per vehicle basis using /vehicles/{device_ID}
- /vehicles/{device_ID} will return only the most recent data for the vehicle, it will not include tracked changes like for example historical associated vehicle_ID
- these changes will be incorporated into a patch release
Next Steps
- for patch release don’t need to go through another formal OMF approval process; only needs steering committee approval
- put on GitHub and get out by end of next week
Discussion
- Matt Davis (Populus): Original intent to set up clarifications; vehicles definition is a leftover from MDS 1.0 when it was real-time; now in MDS 2.0 /vehicles isn’t real-time so needs to be updated
- Michael Schnuerle (OMF): oversight to not update language because of how vehicles stuff split up differently for 2.0 and new /vehicles/status endpoint
- MD: Need to appropriately understand how providers will be populating /vehicles endpoint; what is a “known” vehicle? Populus deals with old data and need to be able to get info on vehicles that may have been deployed years ago and no longer current
- Proposal A: /vehicles has info on all vehicles ever deployed
- Proposal B: /vehicles has to contain info of all vehicles in /status endpoint to have complete dataset
- Proposal C: be able to call vehicles/device_ID for any device ID historically and get that info back
- MS: in old versions could get historical vehicle data; we just want to keep that functionality with new version; is that more of a burden now? Really valuable to be able to get historic data
- Jay Williams (Bird): interpreting in minimal way to provide info on last batch status; concern about maximal is that feels like a different product, thinking of /vehicles as supplemental to real-time endpoint vs turning into a historical endpoint
- MD: /vehicles endpoint intent was to be historical and just oversight that forgot to update
- JW: anything with unbounded lookback is a lot more data and harder to manage on both sides; it feels like this is more than just a patch
- MS: for the concept of device_ID that’s old on demand is this easier?
- JW: better but would still need to do new work to support this; one ID is one vehicle data so more manageable
- JW: as historical endpoint there’s a device_ID and there’s the vehicle_ID on the sticker, association often changes over lifetime of vehicle…
- MS: clarification that device_ID is UUID
- JW: UUID can be associated with different vehicle_ID; if support historical endpoint there’s questions about what needs to be returned wrt vehicle_ID
- MS: older versions did UUID change
- JW: UUID didn’t change, only vehicle_ID
- Pierre Bouffort (Blue Systems): UUID should be constant
- MD: duplicate vehicle_ID are probably fine
- JW: could just return current vehicle_ID but we need to specify this
- MS: seems reasonable that latest update is what’s returned even if this is different than a few years ago
- PB: think this is fine; most of the time city officials don’t care about sticker and changed history for micromobility; for cars this is the license plate; but still fine to keep more recent one
- MS: if still implementing older versions and someone wants historical data you still have snapshots? Would take some effort to mine it and bring it up into the MDS 2.0 feed
- JW: status_changes already have that data in older versions so just along for the ride; would now have to separately generate data, not impossible but just new requirement
- MS: propose potential compromise…
- JW: currently have 21 days of vehicles
- MS: set that to even 30 days to get back in /vehicles for v2.0
- MS: need a cut-off because forever seems like a lot
- MS: is this now a patch or minor release with this change?
- MS: say at minimum 30 days; if no one has a problem with this being a patch release
- PB: 30 days is fine; 99% will do the job; if need more then just talk to operators about how to get data; last 1% not critical to define in spec; patch is okay
- PB: might be too early in adoption of 2.0 to issue minor releases; not convincing minor upgrade
- MS: /vehicles/device_ID suggest that this does go back a long time; what should the threshold be? Important to get more than 30 days by device_ID
- Alex Demisch (SFMTA): agree with PB on not issuing minor release so early in adoption phase
- AD: clarification that /vehicles returns historic data up to 30 days; if want to go beyond that then it’s up to you to recreate this
- MS: can use /vehicles/device_ID to grab older data
- MD: example download old trips then use /vehicles/device_ID to get data on vehicles
- AD: what if there are multiple associations of UUID; only get most recent?
- MD: confirm only most recent
- MS: won’t get changes; seems cumbersome to track changes
- JW: confirm don’t track those changes
- PB: not standard operations; MDS only tracks standard operations
- JW: if you do an agency endpoint send updates and record of changes
- JW: (https://github.com/openmobilityfoundation/mobility-data-specification/pull/882#discussion_r1418006614) comment unrelated
- MS: can JW leave thoughts on notes if anything to add; if add new fields then would be another discussion
- MS: TY for discussion
