Elevating Status of Realtime Feed

[black-tea]

Suggesting moving the real-time feed from a subsection of the Trips endpoint to its own section to clarify that it is a separate requirement with a separate endpoint

[dyakovlev]

+1, this is an important requirement and a little hidden in the current documentation. It would also be useful to clarify whether providers are expected to update the GBFS master list as part of their implementation.

[thekaveman]

If we're going to elevate the GBFS spec, I think we can/should do some more work to describe the MDS interpretation of what complying with GBFS means. I think we need to answer at least these questions:

• @dyakovlev asks do providers register with the GBFS registry? I would think yes
• should system_id be consistent between MDS and GBFS? again, yes
• should bike_id be consistent between MDS and GBFS? What is the corresponding field in MDS device_id or vehicle_id? Yes they should be consistent but I'm not clear enough on GBFS implementations, is bike_id generally the visible ID that a user might see on the bike or in the app?

We should probably also clarify (more as a TLDR; than anything) what it means for dockless mobility providers to comply with GBFS. My interpretation is:

• system_information.json is always required
• free_bike_status.json is required for MDS
• station_information.json and station_status.json don't apply for MDS

[hunterowens]

@thekaveman I've gone ahead and add some interpretation remarks. Given that GBFS doesn't really yet support dockless mobility, it's a little hard to fully bake this, but I've made some changes that should achieve the goal (allowing integration in realtime availability apps by the public) without too much insanity.

Changelog:

• remove requirement for historical GBFS
• require system_information.json
• require free_bike_status.json

This doesn't require than companies register in the GBFS registry, because the registry is city/region specific. Hoping that @noonhub @sethherr and others who have NABSA connections can make progress on getting first class dockless support into GBFS.

If that isn't happening, I think it would be best to remove the GBFS requirement from MDS and require some sort of realtime availability MDS feed. For now, I think this pull request makes key clarifications while preserving options.

[black-tea]

Thanks for the edits. The point of my initial commit is that the MDS currently does state a requirement for a GBFS-like feed, and we've received a few different comments/questions from providers suggesting that there is some confusion around this requirement. Agree with @hunterowens that we should be clear on whether we do or don't require the feed. However, I don't see how that is related to why it is currently buried in the trips endpoint spec.

[thekaveman]

Yeah this looks good.

[thekaveman]

I don't see how that is related to why it is currently buried in the trips endpoint spec.

I think the point is, if we are about to unbury it, it shouldn't presented in the same after-thought context that it was previously. Treat like it a real section, with some explanation.

I think @hunterowens change is good.

[black-tea]

Thank you @thekaveman!