Personal city-data projectInteractive baseline prototype

Harrisonburg OS

Understand a city before trying to change how it moves.

A map-based prototype that combines Harrisonburg’s public geography and traffic-volume records with a synthetic movement model. It is a foundation for studying demand and, eventually, comparing signal strategies.

My role: Problem framing, public-data integration, and simulation product development
Built with: Public GIS, VDOT traffic data, Census estimates, interactive mapping

Harrisonburg OS showing its actual city map, simulation clock, network layers, and modeled activity cards. — The working baseline: public map geometry with modeled vehicle and population layers. The displayed activity is simulated.View full size

Actual hosted prototype captured September 27, 2026. Public-source records, derived estimates, and synthetic outputs are distinguished in the application. The VDOT live-feed connection remains disabled.

Why I built it

Living and studying in Harrisonburg made me curious about how class schedules, residential trips, businesses, and events concentrate demand at particular intersections. I chose that local problem for my datathon work.

I want to understand the whole city, including residents and commuters alongside JMU students. The longer-term question is whether a data-based simulation can help compare changes before anyone changes a real intersection.

My part in the work

I’m connecting the data and shaping the model around that question. The current build brings geography, annualized road-volume records, aggregate population inputs, and an inspectable simulation interface together. The work is as much about deciding what each dataset can support as it is about drawing moving dots.

How the pieces connect

Ground the map
Street geometry, the city boundary, terrain, and mapped signal locations establish the geographic context.
Connect aggregate inputs
VDOT road-volume records and Census-based population and employment-flow inputs feed compact model artifacts.
Model movement
Time profiles and deterministic routes create weighted vehicle agents and anonymous synthetic population groups.
Inspect the assumptions
Layer controls, source lineage, and the intersection inspector expose what is observed, derived, or simulated.

Inside the work

Actual screens, with the reasoning beside them

Inspect a place, not just a dot.

Selecting a signal cluster opens its mapped street names, coordinates, location-validation status, and simulated phase. This example is the West Market Street and South Dogwood Drive location.

A mapped location and a real timing plan are different kinds of evidence. The inspector explicitly labels timing as synthetic; the phase colors are not the city’s operational signals.

Harrisonburg’s top-down map with the West Market Street and South Dogwood Drive intersection inspector open. — The inspector separates location corroboration from the provisional signal-phase display.View full size

Trace every layer to its inputs.

The source registry connects the map’s layers to their input records, transformations, assumptions, and outputs. The inspected build lists 24 retained records, including active inputs, model assets, reference material, and a pending connection.

For example, VDOT’s 2025 road-volume data supplies 134 deduplicated links. Census-based inputs support 33 statistical zones and 421 generalized household clusters. Those aggregates help construct a model; they do not identify individual residents or observed trips.

Harrisonburg OS with its Data source registry open beside the map, including active, reference, and pending source categories. — The registry keeps public observations, inferred estimates, synthetic models, and proposed inputs visibly distinct.View full size

Decisions that shape the project

Build the geographic foundation first

Scenario comparisons need a network whose locations, provenance, and limitations can be inspected.

Use aggregates to model population

Weighted anonymous groups and generalized origins provide citywide context without presenting the movement of real people.

Separate animation from validation

A moving map is not evidence of accurate traffic prediction. The interface identifies provisional demand, signal phases, and presentation metrics.

Where it stands

The prototype has a working map, layers, clock controls, source registry, and intersection inspector. It uses VDOT and Census-derived inputs, but vehicle agents do not yet respond to the displayed signal phases. Delay and queue-risk cards are presentation formulas, not validated traffic-engineering measures. Live VDOT/SmarterRoads access is pending.

What comes next

Validate network behavior, connect vehicle movement to signal logic, and develop reproducible baseline-versus-adaptive comparisons before claiming that a strategy improves traffic.