logoalt Hacker News

Show HN: Signet – Autonomous wildfire tracking from satellite and weather data

53 pointsby mapldxtoday at 12:01 PM13 commentsview on HN

I built Signet in Go to see if an autonomous system could handle the wildfire monitoring loop that people currently run by hand - checking satellite feeds, pulling up weather, looking at terrain and fuels, deciding whether a detection is actually a fire worth tracking.

All the data already exists: NASA FIRMS thermal detections, GOES-19 imagery, NWS forecasts, LANDFIRE fuel models, USGS elevation, Census population data, OpenStreetMap. The problem is it arrives from different sources on different cadences in different formats.

Most of the system is deterministic plumbing - ingestion, spatial indexing, deduplication. I use Gemini to orchestrate 23 tools across weather, terrain, imagery, and incident tracking for the part where clean rules break down: deciding which weak detections are worth investigating, what context to pull next, and how to synthesize noisy evidence into a structured assessment.

It also records time-bounded predictions and scores them against later data, so the system is making falsifiable claims instead of narrating after the fact. The current prediction metrics are visible on the site even though the sample is still small.

It's already opening incidents from raw satellite detections and matching some to official NIFC reporting. But false positives, detection latency, and incident matching can still be rough.

I'd especially welcome criticism on: where should this be more deterministic instead of LLM-driven? And is this kind of autonomous monitoring actually useful, or just noisier than doing it by hand?


Comments

takahitoyonedatoday at 3:42 PM

Aggregating disparate government feeds with completely out-of-phase polling schedules into a unified state machine is notoriously painful. I am curious how your Go service handles the rate limits of the NWS API, which historically drops connections right when usage spikes during actual emergencies. If you ever expose this via webhooks, it would make an incredible backend for building localized mobile push notifications where standard cell-broadcast alerts are too broad or slow.

rouanvdetoday at 3:41 PM

Please add more of the world, and it would be great to see some of the imaging data overlayed to visually see where the fire is and scale

redgridtacticaltoday at 2:44 PM

Really interesting approach. The multi-source fusion is where the real value is — any single satellite feed has too many false positives from industrial heat, sun glint, etc. Correlating FIRMS + weather + fuel models is what experienced fire analysts do mentally, so automating that loop makes sense.

On your question about deterministic vs LLM-driven: I'd lean toward keeping the spatial indexing, deduplication, and basic threshold logic deterministic. Those are well-defined problems with known-good algorithms. The LLM adds value where you're synthesizing ambiguous evidence — "is this cluster of weak FIRMS detections near a known industrial site, or is it a new start in timber?" That kind of contextual reasoning is hard to codify as rules.

One operational question: have you thought about how this integrates with existing incident management workflows? Wildland fire teams run everything through ICS structures and often have limited connectivity on the fireline. Being able to push a structured alert (lat/lon, confidence level, fuel type, weather conditions) into their existing tools would be a big deal for adoption.

show 1 reply
doodlebuggingtoday at 2:48 PM

Interesting. I think there are other services doing the same thing including one linked by another commenter.

When checking the Evidence tab for data that supports the conclusion that there could be a fire in progress I found that it could be improved by excluding the evidence posts for all the mapped fire locations except the one that the user clicked. Presently, if you click that Evidence tab you get a roll of links to posts or mentions or whatever for every fire. I believe that a user would most appreciate data that pertains to the fire they are trying to monitor.

I am not a fan of grey text. It does not improve site navigability or usability and it can get lost in screen glare unless bold grey text is used. It would still be grey text though and I am still not a fan. Perhaps shades of blue or yellow to contrast with the black bar.

Example in case you are thinking of modifying the page - Your top frame has the ap name "SIGNET" in white capitals. Right next to that is an orange dot, probably to signify that something is happening or that the site is "LIVE". Notice that "LIVE" is not only in grey text, beside an orange dot which will be the eyeball magnet, but it is also a smaller font than the ap name "SIGNET".

From my perspective, the site would be improved by changing grey text to a more contrasting color and asking the question - "What information should be the most important topic on this page?" In that way you can optimize it for your users.

Before posting this comment I went back to check that the points I hoped to make were valid points. It turns out that not all "Evidence" links have evidence for every fire on the map. I randomly chose the Custer County Incident when I checked that and found all sorts of stuff pertaining to Texas fires. Perhaps this is not a huge problem for you to solve. I checked the Rapides Parish Incident in Lousyana and it only has data about that event.

Maybe some cleaning of links is in order.

show 1 reply
quickrefiotoday at 3:20 PM

Interesting project. Combining satellite detections with weather data seems really powerful.

show 1 reply
gorfian_robottoday at 3:16 PM

have you shared this with the WatchDuty folks?

gnerd00today at 3:10 PM

the graphically slick intro suggests this is something that could appeal to "investors" or similar ...

show 1 reply
BloodAndCodetoday at 12:32 PM

[dead]

mileszhangtoday at 3:26 PM

[dead]