Prototype / Academic Project
WeatherForge originated as a collaborative University of St. Thomas SEIS 745 project with Odin Lee and Jannah ElNemr. David Braun served as the lead developer and primary implementer, writing more than 90% of the application code, while the project as a whole was completed collaboratively by the three-person team.
At a glance
Context
Prototype / Academic Project
Current state
Applied dashboard prototype
Role
Lead developer and primary implementer
Public weather data is large, messy, and hard to use directly for decision support. NOAA archives contain valuable severe-weather and daily-observation records, but the raw files need filtering, cleaning, unit conversion, county joins, and clear dashboard views before they become useful for Minnesota risk analysis.
Data trust: the dashboard has to make large public datasets usable while clearly labeling historical completeness issues and contextual weather averages.
As lead developer and primary implementer, I wrote more than 90% of the WeatherForge application code across its data pipeline, analytics, and dashboard layers. My implementation work included filtering, cleaning, transforming, and packaging NOAA Storm Events and GHCN-Daily data into Minnesota-focused analytics layers and developing dashboard views for statewide trends, county-level impacts, historical time progression, weather context, methods, and live-alert exploration.
I led implementation of the code that curated 55,384 cleaned Minnesota storm-event records and 9,008,748 station-day observations into reusable Parquet layers and a Python Shiny + Plotly dashboard spanning all 87 Minnesota counties.
Dataset sizes and recorded checks within this project’s stated scope.
~35 GB
raw NOAA source archive
used in the working project
55,384
cleaned Minnesota storm-event records
9,008,748
Minnesota station-day weather observations
87
Minnesota counties mapped
1950-06-15 through 2025-12-28
storm-event range
1877-08-05 through 2026-03-22
weather-observation range
The pipeline is shown as explicit stages so the system boundary is inspectable.
Storm Events and GHCN-Daily source files collected as the raw archive.
Records scoped to Minnesota events, counties, and station observations.
Fields normalized, weather units converted, and records prepared for analysis.
Curated analytics layers stored for faster dashboard and analysis use.
County boundaries and population anchors support mapped and normalized comparisons.
Interactive views expose overview, county, temporal, methods, and alert surfaces.
Data sources
Where the pattern matters
WeatherForge is organized as a decision-support dashboard rather than a single chart export.
Implementation details and the artifacts available for review.
The dashboard source and guide describe how the curated Minnesota data is explored.
The pipeline runs from raw public archives through filtering, cleaning, Parquet outputs, county joins, and an interactive Shiny/Plotly surface.
The project demonstrates how public data can be productized into reporting surfaces without claiming forecasting or actuarial precision.
The public repository includes the curated data, data dictionary, and instructions for running the academic dashboard.
Interpreting this work
Possible next steps
Inspect the source, setup instructions, and project documentation.
More portfolio context.
A small explainable Retrieval-Augmented Generation prototype that retrieves local evidence first, applies a relevance threshold, and refuses unsupported questions when the corpus does not justify an answer.
Workflow orchestration layer in active development for managing state, decision flow, and human review inside StormIQ.