SparkGuard

Inspiration

Living in Canada, wildfires aren't some abstract problem — the 2023 season burned over 18 million hectares and blanketed Montreal in smoke for weeks. We started looking into how fire detection actually works and were surprised to find that NASA literally gives away live satellite fire data for free through their FIRMS API. The problem is that the data is just raw CSV coordinates — there's no context around it. If you're a responder looking at a fire, you'd have to go to a separate weather site, a separate map for terrain, another source for perimeter info, and piece it all together yourself.

We wanted to see if we could bring all of that into one place and make it actually useful.

What it does

SparkGuard shows live fire detections from NASA's VIIRS satellite on a 3D globe. You can see active fires around the world, and when you click on one, a side panel loads up with contextual information pulled from several free APIs:

Fire data — location, intensity (FRP in megawatts), confidence level, brightness temperature, and whether it was detected during day or night
Weather — current temperature, wind, humidity, precipitation, and a 24-hour forecast for that exact location, from MET Norway
Region info — what type of biome and vegetation is at that location, land cover, a rough dryness index, nearby protected areas, and the nearest populated place — pulled from OpenStreetMap and Open-Meteo
Fire perimeters — for US and Canadian fires, we pull the official perimeter boundaries showing how big the fire is and how contained it is

We also added a "Responder Brief" button that puts all of this into a quick summary you can read at a glance.

It's not a finished product by any means — it's a working prototype that demonstrates the concept of pulling scattered public data into one unified view.

How we built it

We used React with TypeScript and Vite for the frontend, and Tailwind CSS for styling. The globe is react-globe.gl, which is a wrapper around Three.js.

Most of our time honestly went into wrangling the data layer. Each API has its own format and quirks, so we wrote separate service modules for each one:

NASA FIRMS — returns CSV that we parse and convert into map points
MET Norway — gives us weather data, but we had to proxy it through Vite because of header requirements
OSM Overpass — lets us query what kind of land and vegetation exists at a coordinate
OSM Nominatim — reverse geocoding to figure out what country/city a fire is near
Open-Meteo — humidity and precipitation data that we use to estimate a dryness index
WFIGS and CWFIS — government fire perimeter data for the US and Canada

We added basic caching so we're not hammering these APIs on every click, and we load multiple data sources in parallel when a fire is selected so the panel doesn't take forever.

Challenges we ran into

The biggest surprise was that the satellite product we originally used (VIIRS SNPP) just… stopped returning data. No error, no deprecation notice — just empty CSV files. We spent a while thinking our parser was broken before realizing the satellite product itself was dead. We had to test a few alternatives before landing on NOAA-20.

NASA's documentation also says confidence values are words like "high" or "low", but the actual API returns single letters ('h', 'n', 'l'). Our parser didn't handle that at first, so every fire was showing 50% confidence.

Performance was another issue. Some days there are thousands of VIIRS detections, and rendering all of them as 3D points on the globe made it really laggy. We had to add downsampling to cap it at around 2,000 points, making sure the highest-intensity fires are always kept.

The Overpass API for region data can also be pretty slow (sometimes several seconds), so we had to add loading states and cache results to keep the experience from feeling sluggish.

And then there were smaller annoyances like CORS issues with MET Norway — browsers strip custom headers from fetch requests, so we had to set up a proxy in our Vite config to make it work.

Accomplishments that we're proud of

It uses real data. We started with placeholder/mock data and eventually replaced all of it with live API calls. Nothing on screen is hardcoded — if you click a fire, the weather, region info, and location data are all coming from actual APIs in real time.
It works anywhere on the globe. We tested fires in Canada, the US, Australia, and Central Africa and the system returns useful data for all of them since the APIs we use have global coverage.
The region intelligence feature. Combining three different APIs (Overpass for land use, Nominatim for geocoding, Open-Meteo for weather/elevation) into one "Region Intelligence" panel was tricky to get right, but it gives a lot of context about what's actually burning and who might be affected.
The globe interaction. Small thing, but when you click a fire the globe stops spinning, zooms in, and highlights your selection with a visible marker and pulsing ring. It makes it feel responsive and clear what you're looking at.

What we learned

Free APIs are amazing but unpredictable. NASA, OpenStreetMap, MET Norway — they all provide incredible data at no cost, but they each come with their own undocumented behaviors, rate limits, and formatting surprises. A lot of our debugging time was spent figuring out what the API actually returns vs. what the docs say.
Real data breaks things that mock data doesn't. When we were using fake data everything looked great. The moment we switched to live feeds, we hit parsing issues, empty responses, and edge cases we never anticipated.
You have to think about performance early. We learned the hard way that "just render everything" doesn't work with thousands of 3D points. Downsampling and caching weren't nice-to-haves, they were necessary for the app to be usable.
Scope management is hard. We had a lot of ideas for features (AI predictions, push notifications, mobile support) but had to focus on getting the core data pipeline working reliably first. It's better to have one thing that works well than five things that are half-done.

What's next for SparkGuard

There's a lot we'd still like to build if we continue this project:

Fire spread prediction — using wind and terrain data to estimate where a fire might move over the next few hours. This is a hard problem but the data for it is mostly there already.
Push alerts — notify users when a new fire is detected in an area they care about
Historical data — let users look at past fire seasons to spot patterns and high-risk zones
AI-generated briefs — use a language model to turn the raw data into more natural, tactical language instead of just listing numbers
Better mobile experience — right now the 3D globe is really designed for desktop. A simplified map view for phones would make it more practical for people in the field.

Some of these are ambitious and would take significant work beyond what we've done so far, but the foundation is there.