system_id and aggregated feeds

[mplsmitch]

The system_id field was added to free_bike_status in v3.0RC as part of #219. It's unclear exactly what the purpose was but it's defined in 3.0RC as

Identifier referencing the system_id field in system_information.json. Required in the case of feeds that specify free (undocked) bikes and define systems in system_information.json.

This poses a number of problems. First, the specification was never intended to be used to produce aggregated feeds that include data from multiple geographic areas. The issue of aggregated feeds has come up in the past, see #127 for an example.

Secondly, the definition above refers to systems (plural) but system_information.json doesn't support the definition of more than one system.

Additionally, this would potentially invalidate other files in the specification. For example if a feed contains data from multiple cities where hours of operation differed, this is not supported by system_calendar or system_hours. If an alert were published via system_alerts warning of a severe weather event (or anti-government insurrection) in a feed containing data from multiple cities, it would be unclear where the danger was.

A further argument against aggregated feeds is the municipal regulation use case. If a city or permitting agency is using GBFS data to monitor compliance or enforce regulation, it seems unreasonable that they should have to parse feeds to extract only those data that are relevant to the system that they permit. It would also mean that any optional files or fields that are required via regulation would be published for all the aggregated geographies.

Since this question has come up more than once, we added some guidance in #271 to clarify use of system_id

Each distinct system or geographic area in which vehicles are operated should have its own system_id

and I've been planning to open a PR to move this from a recommendation (should) to a requirement (must) under 3.0.

I can see two directions this could go. We could simply remove system_id from free_bike_status in 3.0RC and then further clarify what constitutes a system under the specification. Alternatively we could go in the other direction and extend the specification to properly support aggregated feeds. This would be a very significant change and require the extension of just about every one of the endpoints.

Please weigh in and let me know your thoughts

[stale]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 60 days 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.

[nbdh]

Hi @mplsmitch,

while writing up #353 I noticed this newly introduced field and I'm sharing your confusion about the purpose of this field.

Eventually asking in #219 for the proposed meaning could shed some light upon this?

Otherwise I'd clearly encourage to go with

We could simply remove system_id from free_bike_status in 3.0RC and then further clarify what constitutes a system under the specification.

this proposal.