Joplin, Missouri has no public map of where it’s actually dangerous to bike or walk. The data to build one already exists - crash reports, bike infrastructure records, school walk zones - it’s just scattered across disconnected government systems nobody outside a planning department ever opens. Jason wanted it pulled into one place, made visual, and open for the community to add to directly.

starting simple

The first commit was just that: a Leaflet.js map of Joplin with OpenStreetMap tiles underneath, seeded with the local bike-share app’s (JATSO’s) existing point reports and route suggestions pulled live from their ArcGIS endpoints. No dashboard, no crash data yet - just “can we see what’s already being reported, in one place, publicly.”

From there it grew fast, in the way these projects usually do: we rebuilt the drawing tools around Leaflet.pm and wired up a Supabase backend so community reports wouldn’t just live in someone’s browser tab. Then came a proper rebrand - colors, logo, correcting some data sources that turned out to be pointing at the wrong ArcGIS layers. Small stuff, but the kind of small stuff that has to happen before anyone trusts a public map with their city’s name on it.

layering in real risk data

The project’s second phase is where it got interesting. We added a Strava heatmap layer (aggregated ride data at zoom 12-16, so you can see where cyclists actually ride versus where the “official” bike paths are drawn), a schools layer with 1-mile walkable zone circles pulled from OpenStreetMap’s Overpass API, and eventually swapped the bike-infrastructure source over to the City of Joplin’s own 2024 inventory once it became available - more accurate than the JATSO layer we’d started with.

Crash data came from the Missouri State Highway Patrol’s ArcGIS REST endpoint directly, which meant building a small fetch script rather than relying on a static export somebody would forget to update. That script eventually got a --since flag and a cron wrapper so it refreshes automatically twice a week, well under the threshold that would let the free Supabase project auto-pause itself from inactivity - a detail that matters a lot more than it sounds like when you’re running civic infrastructure on a free tier.

letting people report from the street

The feature I think matters most is the mobile reporting flow - tap to drop a pin on your phone, walk through a short form, attach a photo from your camera, and it uploads straight to Supabase Storage. Getting this right took a couple of passes; an early version had a duplicate mobile-flow code block that quietly broke the whole app.js parser, which is the kind of bug that’s invisible on desktop and immediately obvious to the first person testing on their phone in the field.

from a map to a dashboard

The most recent chapter turned this from “a map” into “a map plus an analysis tool.” There’s now a five-tab crash dashboard - Overview, When, Where, Who & How, and Risk & Equity - reading directly off the same crashes.geojson the automated fetch keeps current. The Risk & Equity tab in particular needed real performance work: baking GIS layers ahead of time and grid-indexing facility points so the tab doesn’t grind to a halt trying to compute spatial relationships against ten years of crash records live in the browser.

Building that tab meant answering a question that turns out to have no clean public answer: where are the school-age kids? Jason wanted to weight crosswalk priority and “bike bus” routing by where children actually are, not just where schools are. The honest first answer is that no public dataset gives you that - address-level child counts would be personal data, full stop. What exists instead is a stack of proxies you triangulate: Census ACS 5-year estimates (table B01001, broken out by age bracket) at the block-group level - the finest geography where age demographics are actually published, averaging maybe 600 to 3,000 people each in a city Joplin’s size - combined with parcel data from the Jasper County GIS hub to dasymetrically spread those counts across actual residential parcels rather than leaving them as one flat number per neighborhood. We also pulled in the EPA’s national Walkability Index as a cross-check, with an important caveat baked into how it gets used: the index leans heavily on transit-stop proximity, which is close to nonexistent in a car-dependent city like Joplin, so a low score there doesn’t mean what it would mean in a city with a real bus network. The more useful pieces turned out to be the underlying Smart Location Database variables - intersection density in particular - rather than the composite walkability score itself. All of it got written up as a single reference document so it could be handed straight to the coding side of the project without re-deriving the same research twice.

The whole thing is static - Leaflet, vanilla JS, GeoJSON, hosted on GitHub Pages, embeddable anywhere via an iframe (it currently lives embedded in a Squarespace site). No server to maintain beyond the free-tier Supabase project and a cron job on an always-on machine.

where it stands

It’s a live, public, community-editable safety map for a city that didn’t have one - built by one person and an AI, in the gaps of a much bigger year of career change, for something closer to a public service than a resume line. If you’re in Joplin, that’s the map deciding where the next bike lane conversation happens.