WWU TDM & Parking Dashboard /How This Dashboard Works
Rev. 2026-07-23 Concept mockup
What this is
The ebb and flow of campus mobility
This dashboard shows the ebb and flow of movement to campus, across seasons, time of day, and day of week, not just a snapshot of any one of them.
TransitParkingBike
The problem
Several systems running side by side
Parking, transit, and biking are managed by different people, measured by different equipment, and reported on different schedules. That's normal for a transportation program this size, but it makes the three modes hard to see together, and harder still to compare against each other over time.
Parking lives in patrol logs. Transit lives in a transit agency's own systems. Bike counters are a separate piece of hardware entirely. Left alone, these are three unrelated spreadsheets that happen to describe the same campus.
But they describe the same people. A student or employee who drives most days might bike in on a nice one, or catch the bus when the car's in the shop. The three modes aren't three separate stories, they're three views of the same population making different choices on different days.
One person
Monday
drove, parked
Wednesday
rode the bus
Friday
biked in
What this dashboard does
Puts all three on one timeline
Rather than leave parking, transit, and bike as three separate reports, the dashboard lines them up against the same calendar, so an admin, or anyone on campus, can look at one point in time and see what was happening across all three at once, next to the history that gives it context. That alignment is the actual point. This page explains how the WWU Transportation Demand Management (TDM) Dashboard brings them together onto one shared axis.
Program start
Transitlast update May 31
Parkinglast update Jul 13
Bikelast update Jul 22
Today
Three sources, three different last-updated dates, plotted on one shared axis rather than three separate ones. Each source's freshness is visible at a glance, and the gap between "last update" and "today" is shown honestly rather than smoothed over.
Why the dates don't match
How each source actually arrives
Data for parking, transit, and biking are collected and refreshed in three different ways, with different frequencies.
ParkingGenetec/T2 LPR reads
Checked every 6 hrs
The check itself runs on schedule, but a zone only shows reads while a patrol vehicle is actually driving it. The time we have for parking data is not when someone arrives on campus, but rather when the parking enforcement patroller scans the plate. That's why the dashboard marks unpatrolled days separately instead of treating them as zero.
TransitWTA Quick Site farebox + APC
Uploaded by hand ~quarterly
WTA's export gets reviewed and uploaded by an admin rather than pulled automatically, so this data is more episodic than the other two. WTA collects badge swipes at the farebox on each bus, and we can separate WWU fares from other riders. But this data only reaches us about once a quarter, since the agency needs to clean it before handing it over.
BikeEco-Counter INs only
Checked every 6 hrs
A hardware counter reports on its own, with no patrol step and no upload step in the way. The campus has installed two counters so far, with a third planned soon. This data refreshes in almost real time.
Limitations of the dashboard
What each number can and can't tell you
Lining the three sources up on one timeline doesn't erase what each one can't do. Those limits are named everywhere the number appears, not buried in a footnote.
Parking
A relative pressure index, not an occupancy census. A zone showing zero may mean no patrol that day, not no demand, so unpatrolled days render in a lighter shade rather than counting as a true zero.
Index Not a census
Transit
Farebox data tells where people got on and how they paid. But we don't know where they got off. It is a pretty good assumption that most riders get back on the bus for a return trip at or near where they got off the bus.
Boardings Quarterly lag
Bike
Counts entries only, not a net flow. Counters went live in June 2026, so this mode is still establishing baseline: no trend deltas or averages are shown until roughly one WWU quarter of real history exists.
INs only Only two locations
How to read it
Look for direction, not a single number
Trend, not verdict
Every chart here is built to show direction of travel between the infrequent survey cycles that used to be the only picture available, not to stand in as a precise count on any single day.
Hourly is now real
Hour-of-day patterns are built from actual timestamped records for all three modes, no synthetic curve filling in the gaps. Where history is thin, the chart says so directly.
Live vs. published
What the public dashboard shows is a deliberately published snapshot, a step or two behind this live view by design. Publishing is a decision an admin makes, not an automatic mirror of the live feed.