Maintaining existing use cases with recent updates

[heidiguenin]

With the adoption of #147, we heard that the change might break some existing use cases of GBFS and a request to address those concerns. Several different possible options were floated, including creating a version of bike_id (or vehicle_id) that allowed for a persistent id but only for authenticated feeds.

What are folks' thought on this now, a couple months out from #147 adoption?

[sven4all]

I am really in favor of adding an monitoring_bike_status.json (or something like that) what is a authenticated feed with at least static bike_ids. Another addition for this feed could be a last_time_rented timestamp so that disturbances in GPS signals can be detected.

As a representative of different municipalities I am currently referring to free_bike_status.json with the side note that the id's should be static, that is confusing for a lot of operators.

[quicklywilliam]

One thing that seems relevant is that in MDS 0.4.1, Provider is gaining a new "vehicles" endpoint:
https://github.com/openmobilityfoundation/mobility-data-specification/tree/dev/provider#vehicles

This endpoint seems to provide exactly the sort of data and use case that would be provided by a authenticated GBFS feed with stable vehicle IDs. I'd love to see a single standard get adopted here.

Here's the PR for additional context:
openmobilityfoundation/mobility-data-specification#376

[flashspys]

At the moment we are developing a tool that acts more like a middle man. It publishes a GBFS-endpoint for a proprietary source. This middle man of course does not know when a trip has happened, thus it cannot rotate any bike_ids.

[Empty2k12]

In addition to what @flashspys said: The GBFS feed we're providing handles a station based bike rental system. That means, individual riders cannot be reidentified as rides start and end at specific stations. The station density for this provider is not high enough that a station can be tied to specific home / business addresses.

The only thing which having static bike IDs allows in this context is seeing the bike ID on a bike currently in a ride and checking which station this rider came from. In fact, there exists third-party tooling using our GBFS Feed / aggregator that can be used by the provider, law enforcement or any attentive citizen to check if a bike that is currently parked away from a station has been forcefully removed from a station and should be reported to the provider / the police. (There is a big vandalism problem in our city where bikes are torn out of the stations and left somewhere in the city)

If we removed static bike_id s on our station based feed, such third party tooling would also break and cease to exist.

[heidiguenin]

Re: the vehicles endpoint that @quicklywilliam posted - @jfh01, could you speak to that a little bit in terms of some of the use cases that are coming up here?

[jfh01]

As was mentioned, MDS adds a /vehicles endpoint in our 0.4.1 release. This endpoint is intended for use by regulators who want detailed real-time status of all vehicles on the public right-of-way. Compared to GBFS, it offers:

• Authenticated access
• Stable device IDs (and access to whatever ID number is visible on the vehicle)
• Information about all vehicles on the right of way, including those which may be broken, reserved, or on a trip. (Note that location is not provided for on trip vehicles.)
• Information about how and why the vehicle got to where it is (e.g. left at the end of a trip, dropped off by provider, etc.)

We created /vehicles in part because we knew GBFS was considering removing stable device IDs for privacy reasons. Our goal was to offer an authenticated alternative that could meet the needs of regulators who want stable IDs and/or additional information.

We would love to hear from folks in the GBFS community if we got it right, or if there are gaps or other barriers to using /vehicles. It is currently in beta and we would be happy to consider changes that would serve broader community needs.

It is also worth noting that using /vehicles in no way obligates a user to adopt any other aspects of MDS. It would be entirely reasonable to use /vehicles for real-time status without collecting any trip data or other detailed data about vehicle movements.

[stale]

This disucssion has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.