Working with the California Fire History Database
I spent about three weeks last fall trying to pull fire perimeter data for a site assessment near Santa Rosa, and the standard download process nearly broke me. Here is what actually works. The California Fire History Database is maintained by the California Department of Forestry and Fire Protection (CAL FIRE) and the US Forest Service. It tracks wildfire perimeters going back to the 1800s for some areas, with more consistent digital records from the 1990s onward. You can find it at the CAL FIRE Data Hub, or directly through the California Geographic Atlas. The raw shapefiles are free, which is the good news. The bad news is that the data comes in multiple formats depending on what decade you need, and the file structures change between releases.
California Fire History Database download walkthrough
Start by going to the CAL FIRE Open Data portal. You will see options for historic fire perimeters, annual burn area summaries, and the Fire Behavior Weather data. For most people, the 2007-2024 Fire Perimeter dataset is the one to grab. It is a single ZIP file containing shapefiles broken out by fire name and incident ID. Here is where it gets annoying. The 2007-2024 files use a GeoPackage format in the newer releases, but older queries from the same portal might still serve up ESRI shapefiles if you select the legacy download option. I ended up with a GeoPackage in 2023 and a shapefile in 2024, which meant different import procedures for two pieces of work on the same project. Just note which format you are working with before you open anything. Open the file in QGIS. Yes, use QGIS instead of ArcGIS if you can. The attribute table for the perimeter layer contains a field called FIRE_NAME and a DATE field that is actually stored as text in YYYYMMDD format, not a date type. When I tried to do a spatial join between my site parcel and the fire layer in ArcGIS Pro, the date filtering failed because the field was not recognized as a date. Switched to QGIS, ran a SQL expression on the raw text field, and it took about four seconds. That is a real difference in workflow time.
One thing the documentation does not make clear: the perimeter data is updated monthly for active fires and annually for historical incidents. If you download in March and then again in September, the same fire name might have slightly different geometry because of boundary corrections. I learned this the hard way when a client flagged that the fire perimeter from our March report did not match the map in their September insurance documents. I had to pull both versions and build a comparison. The workaround was simple — always record the download date and the dataset version ID from the attribute table metadata field, and keep a copy of whatever version you used for the project. That metadata field is under FPERIM_VRSN and it tells you exactly which release the data came from. For fires before 2007, you need to go to the historical dataset. These are split by year and by region. A single county like Los Angeles might have five separate shapefiles covering different years and different mapping agencies. The projections are inconsistent too. Most are in NAD83 California State Plane, but a few from the older USFS records are in NAD27. If you are buffering or calculating distances across layers, reproject everything to the same coordinate system first or your measurements will be off by several meters. Another thing nobody mentions: the database includes burn scars from aerial photography, not just ground-mapped perimeters. These are flagged with a specific source code in the attributes. If you are doing ecological analysis or calculating burn severity, mixing burn scar data with mapped perimeters will inflate your burn area numbers. Filter by SOURCE_TYPE and only pull MAPPED_PERIMETER records if that is what you need.
Get the Full Details
The download itself is straightforward. No account required, no rate limiting that I hit, though the GeoPackage files can run over 200 MB for the full 2007-2024 period. If you only need a specific county or fire season, use the QGIS plugin called CAL FIRE Data instead of downloading everything. It lets you query by fire name, year range, or county and exports only the relevant subset. Saves me about ten minutes of filtering time per project. I should mention the limitations too. The pre-1990 data is incomplete. Some fires simply were not digitized. If you are working in a rural area like Modoc or Lassen county and need records from the 1970s, you might find a gap of three or four years with nothing at all. The CAL FIRE mapping effort was sporadic back then. For those gaps, you have to cross-reference with the National Interagency Fire Center database or local county sheriff records, which are maintained separately and rarely integrated into the main dataset. Also, the attribute fields are not standardized across all years. The field names shift between 1995 and 2005. ACRES is one field, BURNED_ACRE is another, and some years use TOTAL_ACRES. If you are writing a script to batch-process multiple years, you will need a field mapping table. I built one that covers about twelve different naming conventions across the dataset. It took me two days to get right, and I lost a day because I assumed a field called SIZE was consistent when it was actually measuring something different in two of the year-groups.
If you are just doing a basic proximity check — is a property within a certain distance of a past fire — the database handles that fine. Load the shapefile, do a buffer, do a select by location. That part is mechanical. The complications come when you need accuracy across time, or when you are combining this data with other layers like landslide susceptibility or fuel models. Those integrations expose the projection inconsistencies and the field naming drift. The portal is at data.calfire.ca.gov and the direct perimeter download link is under the Wildfire section. Bookmark it. The URL structure changes occasionally when they rebuild the portal, and I have lost links twice this year because CAL FIRE moved files between servers without updating their own documentation page.
