forecast micromobility station rebalancing needs from gbfs station status history
domain: micromobility-general · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Archive station_status.json snapshots (num_vehicles_available, num_docks_available, is_renting, is_returning) at a fixed polling interval to build a time series per station_id.
Join against the corresponding station_information.json capacity fields (capacity, and in GBFS 3.0 the per-vehicle-type vehicle_types_capacity/vehicle_docks_capacity) so raw counts are normalized against each station's actual capacity.
Compute simple empty/full-dock risk indicators (e.g. rolling minimum/maximum availability by hour-of-day and day-of-week) as a baseline before reaching for more advanced forecasting models.
Cross-check station polling frequency against each feed's own ttl/last_updated fields — forecasting off a feed you're over- or under-polling relative to its actual update cadence will bias the time series.
Validate any capacity assumptions against real vehicle_types.json data if the system serves multiple vehicle types, since a station's total capacity can be split unevenly across types.
Known gotchas
GBFS station_status is a real-time snapshot feed, not a historical API — there is no standard endpoint for historical availability; you must build your own archive by polling and storing snapshots over time.
Station capacity fields are static/slow-changing while status is near-real-time — don't assume capacity itself needs the same polling frequency as availability counts.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?