Skip to content

Web conference notes, 2021.04.29 (Joint Working Group)

Jump to bottom
Michael Schnuerle edited this page Apr 29, 2021 · 13 revisions

Web Conference, 2021.04.29

Joint Working Group - City Services

  • Every other week call at 9am PT / 12pm ET / 6pm CET

Conference Call Info

#red NOTE NEW ZOOM MEETING ID/LINK/PHONE! (as of Jan 1, 2021)

Meeting ID: 841 7098 9462 - Passcode 612987
https://us02web.zoom.us/j/84170989462?pwd=WTRlY25wOVhNeS8wQk1iM2QzYkQvUT09

One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Attendees

Add your own name, link, and organization during call

Agenda

Main Topics

  1. Provider Vehicles, beta, and GBFS
    • Discussion around the Provider /vehicles endpoint, support for moving it out of beta, and a discussion around its connection to GBFS and the GBFS requirement in MDS.
    • /vehicles endpoint in Provider spec
    • #637 - Moving /vehicles out of beta
    • Current GBFS requirement in MDS
    • MDS Vehicles Guide for cities to compare MDS Provider vehicles and GBFS free_bike_status and use cases
    • #641 - Discussion around GBFS requirement

WGSC Meeting Organizers

  • Host: Michael Schnuerle
  • Facilitator: ...
  • Outreach: Michael Schnuerle
  • Note taker: Steve Brining

Minutes

Introduction

  • Just closed request for new steering committee members. Votes coming soon
  • We’re in the 1.2 cycle of releases
  • Asking if there are any topics that come to mind for more topics today or future meetings (not at this time)
  • Review of all the links in the Agenda by Michael Schnuerle (MS)

Discussion

  • Dirk De Kik / Spin brought this topic up
  • Beta: most providers and people they talk to thinks /vehicles is great and could be moved out of beta.
  • DD – I’m in favor of it. Cities ask, we have a permit, do you have a maximum of scooters you can deploy, and may have a daily/weekly/hourly basis.
  • Batteries are improving, so vehicle may be on the street for 5 days, but wouldn’t see it in status changes
  • Aside from status changes, cities have used GBFS for compliance.
  • If we have a problem with our GBFS feed, get dinged by the city.
  • Want to be able to do some things with GBFS. In talking about compliance > would like everyone, for compliance purposes, move to the vehicles endpoint and not use GBFS anymore.
  • They get his quite a bit on GBFS endpoints. Because it’s public, can’t identify individuals. Also, if providers hit all their GBFS datapoints, they run into issues.
  • For SPIN is doesn’t make sense to keep GBFS around for compliance.
  • Wants to leave GBFS just for user acquisition.
  • MS – Thoughts – the way we have it worded in MDS spec, it’s possibly unclear that it should be used as compliance. We could add language that GBFS isn’t for compliance.
  • ACTION ITEM: Make it clear on MDS main repo home page that MDS is the thing to use for compliance, and GBFS is for public facing. Leave thoughts on #641

GBFS

  • Other part > DD would this meet what you’re thinking, or are you thinking of not asking for GBFS at all?
  • DD – it’s a bit weird to ask for it as all. As a commercial company operating vehicles, there are incentives for providers to have GBFS.
  • WH – thinks Spin has a different perspective. Some operators don’t want to have a public GBFS feed. Useful to go to an operator and let them know they need a public GBFS feed. Helps with alignment of overall mobility program. Need to be clear on use cases in general, and this is a chance to do that with MDS/GBFS. If it’s not there, he worries > some operators say they don’t need to and WH/Ridereport says it’s a requirement
  • Sharada Strasmore in DC > agrees with WH
  • WH - thinks it’s clear that it’s needed. Pushing in MDS to remove single vehicles identifiers so individual trip paths can’t be identified. Want to be clear about what GBFS is for, and that cities should require both MDS and GBFS.
  • DD – we’re on 2.2, but want to remove 1.0 feed. Really want to get away from pre-2.0 GBFS but it makes it harder for compliance.
  • DD – clarifying that if both GBFS and MDS used, then MDS vehicles is used for the compliance truth.
  • MS – does say GBFS 2.0 or greater, so no stable vehicle ids.
  • Joseph Yawn / Atlanta: We are experiencing this in Atlanta. The City no longer has Relay Bikes GBFS Feeds publicly available citing privacy concerns
  • Heidi Guenin / MobilityData: Joseph - this is a case where the city should instead be requiring an updated GBFS version as opposed to just giving up on the public data. And one of the reasons that this requirement in MDS is so helpful.
  • Emmett McKinney – we publish a GBFS 2.0 feed with rotating vehicles IDs
  • Personally in favor of keeping GBFS (2.0+) and revised change that Michael suggested, and letting them continue to support previous use cases.
  • MS – EM > you’re saying some people in an agency want to see a vehicles endpoint, as a separate authentication from rest of MDS?
  • EM – we may want to share just the vehicles endpoint if we don’t have to share whole MDS feed.
  • Can have more flexibility without having to pack permissioning into endpoint of their MDS service.
  • DD – haven’t tried to limit one of their endpoints vs another
  • EM – we are ok with the status quo
  • DD – main goal of GBFS is to be public. Are there operational reasons why we wouldn’t have all vehicles in GBFS?
  • For us, we should see MDS vehicles endpoint as a source of truth and have more flexibility around GBFS.
  • Matt Davis > wondering if this conversation would be different in a few months after more adoption of the vehicles endpoint?
  • Vehicles endpoint is just a better source of data for cities
  • Can’t imagine a case where cities with access to both would think they need both at the same level of service standard.
  • MS: Vehicles and GBFS guide: https://github.com/openmobilityfoundation/mobility-data-specification/wiki/MDS-Vehicles
  • DD –> MD it would be great for us to get to that point.
  • MS – back to how to make this more clear
  • What is the wording that we put on the main section under “GBFS Requirement”?
  • MS > Mitch do you have any guidance on this?
  • Mitch Vars (MobilityData) – it’s something we could add.
  • Heide (MobilityData) – this has been coming up a lot in our trainings > train in several languages
  • For GBFS training, they can make it clear, and point out what’s in each and what is missing in each.
  • MV: NABSA on differences between GBFS and MDS: https://nabsa.net/resources/gbfs/
  • MS – encouraging people on call to comment on #641 on making it more clear
  • Thinks GBFS was added since there was a difference, but it’s also a good idea for cities to add so they can make some information public.
  • ACTION ITEM: MobilityData can add talk about MDS vs GBFS use cases and link to the main GBFS repo and MobilityData website to make it clear and create cross links.

Policy Documents

  • JJ – thinks this is more about policy and making good policy documents are written. A lot of cities do speak to having a public GBFS feed. Core issue is about having that GBFS requirement written into city requirements.
  • Shouldn’t this be transferred to city data sharing requirements instead of having it held within provider
  • WH – maybe this should go into the new data sharing requirement?
  • MS – yes, something we could add, a link to the GBFS feed for each provider.
  • WH – maybe one of the goals in moving vehicles out of beta should be to study which cities are still using GBFS instead or using it for compliance purposes.
  • WH > DD do you think OMF should help educate and bring cities along if they are still requiring GBFS or an older version of GBFS?
  • DD – yes, it’s the compliance requirement. Would prefer vehicles vs GBFS
  • ACTION ITEM: Add 1) is GBFS required optional field in metadata and 2) optional GBFS URLs to provider metadata in Requirements endpoint.

Adoption

  • WH – seems like the argument is over the best way to accomplish. More of an adoption issue.

  • MS – part of Angela’s work is to work with cities/providers.

  • MS - Of the 100 cities using MDS, we only have contacts with a few dozen of them.

  • MS - 3rd party provides/operators could have more contacts than us. OMF could use them to help get word out.

  • JJ – been talking to cities about using the vehicles endpoint.

  • Would be very useful if this was a bigger effort.

  • It’s still coming from a provider, and we’re not always seen as the most trustful.

  • Can we get NACTO or NABSA to weigh in, how about other city representatives.

  • MS – makes sense to hit angle from transparency as well at utility

  • MV – appropriate on OMF side to say why vehicles endpoint is better than GBFS for compliance checks.

  • MS – we could add some language on rate limiting and matching that make GBFS not as good

  • WH – talking about using GBFS as a secondary data source to check on MDS.

  • Not always in sync, but there could be glaring issues it could show.

  • MS – sure cities are using this for that sometimes.

  • HG – yeah, people are doing it, there is value, and there is a point where people are doing this without guidance, it might undermine the ecosystem in general. If we’re going to do it, need to do it along with precise documentation.

  • MS – this is something we could add to our agenda for a roundtable or webinar. May need some providers/3rd party to help reach the right people.

  • ACTION ITEM: Angela/OMF can think about a roundtable with cities and MobilityData to talk about how to use Vehicles for regulation not GBFS.

  • ACTION ITEM: add to OMF Vehicles guide some language around rate limiting issues with GBFS, and how data may not match up between MDS and GBFS.

  • ACTION ITEM: Future MD/OMF doc that does a serious side by side comparison of how each are expected to be the same or different, co create the material, agree on hosting location and how to promote it. Then could mention that cities could use it as a secondary source for spot checks or auditing.

  • WH: I’m really appreciating having the GBFS folks in this call, thank you for joining!

  • DD: Yes great to have the GBFS people here

  • HG: Thanks for getting the conversation going on this topic again.

Outro

omf-mds-github-footer

MDS Wiki Home

MDS Links

Working Groups

2.1.0 Release

2.0.0 Release Plan

1.2.0 Release Plan

1.1.0 Release Plan

1.0.0 Release Plan

0.4.1 Release Planning Meetings

0.4.0 Release Planning Meetings

0.3.2 and earlier Release Planning Meetings

Clone this wiki locally