Closed asadowns closed 6 years ago
1) I think we can ditch the "time" parameter, as you can use status_change
(introduced in #26) to construct an availability view to allow cities to view devices on street over time.
2) MDS should require some sort of public, real time feed with consistent URLs a la GBFS with only the free_bike_status.json
required. Does anybody have some sort of idea on how GBFS is adapting and if we should roll our own or cite them?
(Re 2:) Based on my reading of the spec and conversations at NABSA, GBFS is well-suited to dockless operations. The GBFS spec does not require station_status.json
. Many providers are already exposing free_bike_status.json
in some areas.
The spec does require system_information.json
, but perhaps requiring just free_bike_status.json
, publicly accessible, is sufficient.
Ref: https://github.com/NABSA/gbfs/blob/master/gbfs.md Ref: https://ddot.dc.gov/page/dockless-api
I think #108 addressed this. Feel free to open another issue if there are still outstanding questions.
The bottom section of providers mentions that providers should expose a GBFS feed as well. Is it possible to provide more detail around the specifics and intention here.
There are number of parts of GBFS that don't apply clearly and directly to dockless mobility devices. It might be helpful to specify what specific pieces of GBFS should be implemented and in what manner that makes sense for dockless mobility devices.
Also, it's not clear what "exposed" means here. Would this fall under the same security as the proposed MDS endpoints?
Any clarification greatly appreciated!
Relevant section quotation: