NIFC Wildfire Perimeter Data Is Bigger Than You Expect, and That Breaks Ingests

The National Interagency Fire Center publishes current wildland fire perimeters through the Wildland Fire Interagency Geospatial Services (WFIGS) ArcGIS feature service. It is the authoritative source for where a fire actually is, as opposed to where satellites detect heat, and it is free and unauthenticated.

It is also a good deal harder to consume reliably than the feature count suggests.

Two hundred features, thirty-six megabytes

Querying the current perimeter layer for everything is the obvious first move:

/FeatureServer/0/query?where=1%3D1&outFields=*&f=geojson

Measured against the live service on 18 August 2026, that request returned 36.1 MB and took 38.6 seconds. The feature count was 201.

That works out to roughly 110 KB of vertices per perimeter. Fire perimeters are digitized from infrared flight lines and field GPS, and they are not smoothed before publication. A single large incident can carry several thousand coordinate pairs at full precision, and precision here means many decimal places of degree, which is far past what any map at any usable zoom will render.

Why this breaks ingest code specifically

Most well-behaved ingest code puts a timeout on outbound fetches. Ten seconds is a common default, and it is a sensible one for the rest of the federal hazard stack. USGS returns earthquakes in well under a second. NWS alert endpoints are similar. A ten-second ceiling is generous for almost everything an emergency data platform talks to.

It is not generous for this endpoint. A response that takes 38.6 seconds cannot arrive inside a ten-second budget, so the fetch aborts, every time, on every run. If the worker is written to fail safely, which it should be, the failure is quiet: the previous perimeters stay in the database and nothing in the interface changes.

The result is a feed that looks fine and is not. We ran into exactly this. Perimeter data went 30 hours stale during fire season before a staleness threshold caught it, and the cause was not the service being down. The service was up the whole time. It was answering a question we could not afford to wait for.

Ask the server to simplify

The ArcGIS REST API can do the reduction server side, which is the part that is easy to miss. Two parameters matter.

geometryPrecision caps the number of decimal places on returned coordinates. maxAllowableOffset applies a Douglas-Peucker style generalization in the units of the output spatial reference, so for WGS84 the value is in degrees.

Measured against the same service, minutes apart:

Query	Size	Time
full precision	36.1 MB	38.6 s
geometryPrecision=5	22.1 MB	11.8 s
+ maxAllowableOffset=0.0005	2.4 MB	5.5 s

A maxAllowableOffset of 0.0005 degrees is roughly 55 meters of positional tolerance. On a perimeter that spans kilometers, that is invisible at any zoom level a person will actually look at, and it is far inside the uncertainty of the perimeter itself. All 201 features survived, with about 70,000 vertices between them and no empty geometry.

Fifteen times smaller, seven times faster, same fires.

What simplification does not touch

This is worth being precise about, because it is where the decision could go wrong. Acreage and containment percentage are attributes on the feature, not properties derived from the polygon. GISAcres, DailyAcres, CalculatedAcres and PercentContained are published values from the incident record.

Generalizing the outline therefore does not move any reported number. If your pipeline computes area from the returned geometry instead of reading the attribute, simplification will change your answer and you should not do this. Read the attribute.

Practical notes for anyone building on WFIGS

• Set the timeout from a measurement, not a convention. The service measured between 3.9 and 38.6 seconds minutes apart. Whatever ceiling you pick, pick it knowing the spread.
• Treat a failed poll as a distinct state. Stale perimeters and no perimeters look identical on a map. If your interface cannot tell a reader which one they are looking at, the reader will assume the more comforting one.
• Prescribed burns are in the layer. Filter on FireCause, IncidentTypeCategory and the incident name if you only want wildfires.
• The perimeter is not the detection. WFIGS perimeters update on the order of hours to twice daily. Satellite hotspot feeds such as NASA FIRMS update within minutes of an overpass. They answer different questions and should not be merged into one count.

Why we published the numbers

Payload sizes and response times for public federal services are not documented anywhere we could find, and they are the difference between an ingest that works and one that fails silently for a day and a half. The measurements above are from a specific service on a specific date, and they will drift as the fire season does. Measure your own.