13. Februar 2025incendios-en-argentina.netlify.app

Visualizing Wildfires: A Satellite Data Project

How I transformed my concern for wildfires in Argentina into a web application that makes satellite data accessible to everyone.

Live-Ansicht

Introduction

In early 2025, news began to spread about wildfires and hotspots in southern Argentina. At first, information arrived indirectly through videos, images, and messages from people in affected areas. Major media outlets gradually picked up these stories, but information remained scarce and fragmented. Driven by my passion for mountains and nature, I decided to search for more information online. The deeper I looked, the more I realized that available data was limited and poorly updated. I wondered: is there any resource that shows on a map which areas are affected, which hotspots remain active, or which areas have already been reduced to ashes? Assuming this satellite information existed, I imagined some entity would have already created an accessible visualization. To my surprise, this wasn't the case-at least not in a simple and direct way. Services like NASA's FIRMS or the CONAE hotspot catalog existed, but most were buried in government portals with unfriendly interfaces or required specific technical knowledge to interpret. That's when my project was born: how could I build an interactive map to visualize hotspots in Argentina in real-time, in a simple and intuitive way? Here is the live application

Concept

I began by exploring FIRMS, analyzing how their platform worked. Although I had previously worked with maps, I had always consumed data from external APIs designed specifically for mapping. With FIRMS, I discovered they offer WFS (Web Feature Service) and WMS (Web Map Service) with open data extracted and processed from NASA's MODIS and VIIRS sensors. Since the data is global, I conducted an initial test by limiting the area to Patagonia, Argentina, and positioning GeoJSON elements on a custom map using react-leaflet. Evaluating the result, I noticed that the data wasn't very complete and only provided confidence level (useful for determining whether a hotspot is actually an active fire and not, for example, an area with volcanic activity). When visualizing the map with markers, I detected that it wasn't possible to differentiate between hotspots of different magnitudes or intensities. At this point, I had:

A functioning basic map
The logic for positioning markers

All that remained was improving the data source. Diving deeper into my research, I discovered that Argentina's CONAE (National Space Activities Commission) processes and distributes similar information for South America, extracted from the same sensors and satellites. The crucial difference is that their data includes much more valuable information:

Pixel brightness temperature (FP_T21/FP_T31 for MODIS, FP_TI4/FP_TI5 for VIIRS)
Radiative power (FP_Power in MW)
Detection confidence level (FP_Confidence)
Precise pixel dimensions (SCAN/TRACK)
Political divisions (province/department)

However, accessing this data presented significant challenges:

Fragmented documentation: Technical information was scattered across multiple PDF documents and web pages.
Unintuitive interfaces: The official web application required multiple steps to perform basic queries.
Mandatory registration: Registration was required to download any data.
Limited visualization: Visualization tools were basic and not very interactive.

Despite these obstacles, I discovered that CONAE exposes this data through geospatial web services (WFS), which simplified my work to just changing the service I initially consumed.

Technology

To implement my idea, I decided to create a rapid prototype with technologies I knew well:

Vite + React: For quick development and deployment
React-Leaflet: A library that facilitates the integration of interactive maps in React applications
ArgenMap: As a base tile provider, offering detailed maps of Argentina
GeoJSON: To process vector data of hotspots obtained from CONAE's WFS service

The development process followed these steps:

Obtaining hotspot data: After my initial experience, I decided that in the near future I would develop my own data extraction and processing. To prepare for this scalability, I designed a class that manages data retrieval in a modular way:

class FireService {
    private static readonly WFS_BASE_URL = "https://geoservicios.conae.gov.ar/geoserver/GeoServiciosCONAE/wfs";

    private static async fetchWFSFires(layerName: string, startDate?: Date, endDate?: Date): Promise<WFSResponse> {
        const params: Record<string, string> = {
            service: "WFS",
            version: "2.0.0",
            request: "GetFeature",
            typeName: `GeoServiciosCONAE:${layerName}`,
            outputFormat: "application/json",
            srsName: "EPSG:4326"
        };

        try {
            const response = await axios.get<WFSResponse>(this.WFS_BASE_URL, {
                params,
                headers: {
                    Accept: "application/json, text/plain, */*",
                    "Accept-Language": "en-US,en;q=0.9,es;q=0.8"
                }
            });

            let filteredFeatures = response.data.features;

            filteredFeatures = filteredFeatures.filter((feature) => {
                const confidence = feature.properties?.FP_Confidence as number;
                return confidence >= MIN_CONFIDENCE_TOLERANCE;
            });

            const formattedResponse = {
                ...response.data,
                features: filteredFeatures,
                numberMatched: filteredFeatures.length,
                numberReturned: filteredFeatures.length,
                totalFeatures: filteredFeatures.length
            };
            if (startDate && endDate) {
                return this.filterByDate(formattedResponse, startDate, endDate);
            }
            return formattedResponse;
        } catch (error) {
            console.error(`Error fetching ${layerName} data:`, error);
            throw new Error(`Failed to fetch ${layerName} fire data`);
        }
    }

    private static filterByDate(data: WFSResponse, startDate: Date, endDate: Date): WFSResponse {
        const startStr = startDate.toISOString().split("T")[0];
        const endStr = endDate.toISOString().split("T")[0];

        const filteredFeatures = data.features.filter((feature) => {
            const featureDateStr = (feature.properties?.Dia as string).split("T")[0];

            return featureDateStr >= startStr && featureDateStr <= endStr;
        });

        return {
            ...data,
            features: filteredFeatures,
            numberMatched: filteredFeatures.length,
            numberReturned: filteredFeatures.length,
            totalFeatures: filteredFeatures.length
        };
    }

    private static async fetchMODISFires(startDate?: Date, endDate?: Date): Promise<WFSResponse> {
        return this.fetchWFSFires("FocosDeCalor", startDate, endDate);
    }

    private static async fetchVIIRSFires(startDate?: Date, endDate?: Date): Promise<WFSResponse> {
        return this.fetchWFSFires("FocosDeCalorVIIRS", startDate, endDate);
    }

    public static async getAllFires(startDate?: Date, endDate?: Date): Promise<WFSResponse> {
       // Here we can get all data together and preprocess it if necessary
    }
};

The new information about hotspots allowed me to dimension the markers according to pixel size and radiative power (FP_Power), achieving a much more informative visual representation.

Integration with WMS for geographic context: I added a WMS layer that shows human settlements and populated centers, allowing quick visualization of which communities might be at risk:

<WMSTileLayer
    url="https://wms.ign.gob.ar/geoserver/idera/bahra/ows"
    layers="bahra"
    format="image/png"
    transparent={true}
    version="1.3.0"
/>

Challenges and Solutions

During development, I faced several technical challenges that required creative solutions:

1. Data Volume

The WFS service could return thousands of points for extended periods, negatively impacting browser performance and user experience. Solution: I implemented a clustering strategy that groups nearby hotspots when the map zoom is distant, dramatically improving performance without losing critical information.

<MarkerClusterGroup
    iconCreateFunction={createClusterCustomIcon}
    maxClusterRadius={30}
    zoomToBoundsOnClick={true}
    spiderfyDistanceMultiplier={2}
    showCoverageOnHover={false}
    animate={true}
>
    {fires && (
        <GeoJSON
            data={fires}
            pointToLayer={createFireIcon}
            onEachFeature={createFirePopup}
        />
    )}
</MarkerClusterGroup>

This solution not only improved performance but also provided a clearer visualization of hotspot concentrations.

2. Service Limitations

CONAE's WFS service has limitations regarding the number of features it can return in a single query, making it difficult to obtain historical data or data for extensive areas. Solution: I developed a system of paginated and parallel queries that request data in smaller batches and then combine them on the client side, allowing visualization of more extended periods without exceeding service limits.

Impact and Next Steps

This project, born from a personal concern, has evolved rapidly. To enhance its impact, my next steps include:

Integration of burned area data: CONAE offers monthly burned area products derived from MODIS data that will allow analysis of post-fire impact and the evolution of affected areas over time.
Customized alert system: Allow users to define areas of interest (such as properties, nature reserves, or communities) and receive notifications when new hotspots are detected in those areas.
Migration to NextJS: To improve scalability, I plan to migrate the project to NextJS, leveraging its caching capabilities and server-side rendering (SSR) to optimize data processing and delivery.
Mobile optimization: Improve the experience on smartphones and tablets, crucial for field users such as firefighters, park rangers, or rural producers.
Predictive models: Integrate meteorological data and propagation models to estimate the risk and possible expansion of active fires, transforming the tool from informative to preventive.

Conclusion

This project demonstrates the power of democratizing scientific data through intuitive interfaces. Satellite information about fires already existed but remained effectively "hidden" behind complex interfaces and cumbersome processes, inaccessible to those who need it most. Visit the live application to explore the final result. The most sophisticated technology loses relevance if it's not accessible to its potential beneficiaries. My goal with this application is to build bridges between scientific institutions and communities, especially in situations where timely access to information can make the difference between prevention and tragedy.