Bundled gbfs/static/systems.csv is stale (220 vs 1520 live systems, missing 4 columns)

[jakehadar]

The systems.csv snapshot bundled in the package (`gbfs/static/systems.csv`) is significantly out of date compared to the live upstream file at https://raw.githubusercontent.com/NABSA/gbfs/master/systems.csv.

Diff summary

	Local (`gbfs/static/systems.csv`)	Remote (upstream)
Systems	220	1,520
Columns	6	10

• The local file is missing 1,412 systems added upstream since the snapshot was taken.
• 114 System IDs present in the local file no longer exist upstream (renamed or retired) — including `NYC`, the same stale ID fixed in Documentation and example: "NYC" is no longer a system_id #8 for the README/examples. The underlying data file still has it.
• The remote file has picked up 4 columns the local file predates: `Supported Versions`, `Authentication Info URL`, `Authentication Type`, `Authentication Parameter Name`.

Why it matters

`systems_provider_local_csv` (`gbfs/providers.py`) is a documented, exported offline alternative to the live-fetch provider, and the CSV is shipped as package data (`setup.py`, `MANIFEST.in`). Anyone using the offline/local path gets 220 stale systems, 114 of them dead IDs, and none of the 4 newer columns.

Next step

Before refreshing the file, confirming whether `systems_provider_local_csv` is actually wired into any default/consumer-facing code path, or only reachable if a caller explicitly opts into it.

[jakehadar]

Traced usage of `systems_provider_local_csv` across the whole package to scope the actual blast radius:

• `SystemDiscoveryService` (`gbfs/services.py:67`) hardcodes its class-level default to `systems_provider_remote_csv` — the live-fetch provider.
• `systems_provider_local_csv` (`gbfs/providers.py:14`) is referenced nowhere else in the package except its own definition and the `all` export list.
• The only place it's actually instantiated is `gbfs/tests/test_services.py:9,13`, which explicitly passes it in.
• `gbfs/init.py` re-exports nothing, and both the README walkthrough and `gbfs/examples/basic_usage.py` call `SystemDiscoveryService()` with no arguments — every documented/example path goes through the remote provider.

So `systems_provider_local_csv` is live code, not dead code, but it's an opt-in escape hatch: nothing in the package's own defaults, examples, or docs ever exercises it. Only a consumer who explicitly imports it and passes it to `SystemDiscoveryService(systems_provider=systems_provider_local_csv)` is affected by the staleness described above. Narrows the urgency, but doesn't remove the need to fix it — the offline path should still return valid, current data if we're going to keep shipping it.

[jakehadar]

Resolved. The scheduled workflow (#14) has now run successfully twice via manual dispatch, producing #15 (merged) which refreshed `gbfs/static/systems.csv` from 220 to 1,520 systems and picked up the 4 new upstream columns. `master` now reflects current upstream data.

#16 also fixed a related fragile test (`test_services.py` hardcoded the now-defunct `ABU` system ID), so future automated refreshes shouldn't break the suite.

Closing — the weekly cron trigger runs the identical job definition, so no need to wait on it specifically to confirm this works.