Executive Summary & Protocol Overview
The protocol treats satellite fire detections as candidate evidence, not dispatch-ready incidents. Translating raw thermal data into actionable dispatch alerts requires a strict decision chain that accepts only feed records with usable geolocation, acquisition time, and sensor metadata. Primary inputs are thermal anomaly records from MODIS active fire products at roughly 1 km nominal resolution and VIIRS active fire products at approximately 375 m. We access these typically through NASA FIRMS API formats such as CSV, GeoJSON, or KML.
For near-real-time satellite-derived detections, the operational clock must be measured from feed availability rather than from ignition. NASA FIRMS near-real-time products are commonly available within roughly 1 to 3 hours after satellite observation, depending on the source and downlink path. Once the data is available, the dispatch pipeline separates four timestamped checkpoints: feed receipt, verification completion, payload handoff, and dispatch-center acknowledgment. Each checkpoint is logged in UTC with millisecond precision for auditability.
For the recent fire-season operating window, the baseline latency target in this methodology is about one to three minutes from verified anomaly creation to outbound dispatch handoff. This target explicitly excludes satellite overpass and upstream feed publication delay, focusing entirely on the controllable routing infrastructure.
Data Ingestion and Initial Anomaly Detection
Ingestion begins with scheduled polling of satellite fire feeds, followed by schema validation and coordinate normalization. The system first decides whether a record is structurally usable. Requesting thermal detections by bounding box or jurisdiction polygon rather than global download reduces transfer volume and simplifies jurisdictional routing when serving a single agency.
Coordinate normalization stores latitude and longitude in WGS 84 decimal degrees. We extract the acquisition time in UTC, sensor type, scan or pixel size where supplied, brightness temperature fields, and upstream confidence labels as separate queryable attributes. Polling cadence is configured between about 5 and 15 minutes for API checks during high-risk periods. This frequency respects upstream rate limits while caching unchanged query windows to avoid duplicate ingestion.
Field Note: A robust deduplication key should combine the source sensor, acquisition timestamp, latitude-longitude rounded to the product’s effective spatial precision, and the upstream detection identifier when available.
For seasonal operations, ingestion queues retain raw records for roughly 7 to 30 days. Processed verification logs remain accessible for at least one full fire season to support post-incident review and system auditing.
Algorithmic Verification and False Positive Filtering
Verification is staged so that deterministic exclusions run before model scoring. The pipeline first checks whether the hotspot overlaps known non-wildfire heat sources, recent burn scars, or water bodies. Historical burn-scar checks compare candidate hotspots against recent fire perimeters and burn severity layers covering approximately the preceding 30 to 365 days. Residual heat and exposed dark surfaces frequently distort thermal interpretation.
A thermal anomaly located inside a mapped refinery or flare-stack buffer can look urgent in raw satellite data but should not become a wildfire dispatch alert unless secondary evidence shows spread outside the industrial footprint. Known-source suppression lists include power plants, refineries, mines, landfills, flare stacks, and recurring permitted-burn locations. These lists are refreshed at least monthly during active operations.
Spatial clustering groups detections within a configurable radius tied to sensor resolution: approximately 375 m to 1 km for same-sensor detections, with a wider buffer applied only when fusing MODIS and VIIRS observations. Temporal clustering requires at least one corroborating signal inside a roughly 10 to 60 minute verification window when additional satellite, camera, lightning, or ground sensor data are available. The system preserves both the upstream satellite confidence field and the local verification score; overwriting the satellite value removes evidence needed for later quality review.
While verification data supports rapid anomaly classification, heavy cloud cover, smoke layers, steep terrain shadows, and closed-canopy fuels temporarily degrade detection confidence. The protocol routes ambiguous high-risk detections to secondary evidence sources rather than suppressing them automatically.
Payload Construction for Computer-Aided Dispatch (CAD)
Payload construction starts only after verification assigns an alert state. The builder selects the jurisdiction, converts the detection geometry into the CAD system’s accepted location format, and attaches the required metadata. A minimum CAD payload includes a unique alert ID, UTC detection time, UTC verification time, latitude, longitude, location uncertainty or sensor resolution, jurisdiction code, confidence class, sensor source, and recommended response category.
Geospatial and Weather Enrichment
Geospatial metadata includes slope class, aspect where available, nearest road or access point, land ownership or response area, and distance to mapped wildland-urban interface when the agency maintains a vetted WUI layer. Weather enrichment attaches wind direction and wind speed using the closest trusted forecast or observation grid cell. The weather timestamp is preserved so dispatch staff can identify stale values.
JSON payloads use explicit field names and ISO 8601 UTC timestamps. XML payloads maintain a stable schema version so legacy CAD parsers do not break after field additions. For current integrations, payload templates are version-controlled. Any field change affecting CAD parsing goes through a typical 5 to 10 business day validation window with the receiving agency.
API Integration and Secure Routing Protocols
Routing decisions are made from the receiving agency’s technical capability and policy constraints. The preferred path is a mutually authenticated HTTPS endpoint using modern TLS, because it supports structured data exchange. Transport uses TLS 1.3 where supported, with certificate rotation procedures documented before fire-season cutover. Agencies unable to support TLS 1.3 are recorded as an exception with a compensating control.
A CAD endpoint may accept an HTTPS payload and still fail to create a dispatch-visible incident because the XML schema version, jurisdiction code, or mandatory location field does not match the agency’s production parser. NG9-1-1 interoperability planning references the NENA i3 architecture, focusing on structured incident data, location-aware routing, and auditable message exchange across emergency-service networks.
Context dictates the routing mechanism. A mountain county with sparse broadband may need SMS or secure email fallback for initial alerting, while an urban-edge agency with NG9-1-1-aligned infrastructure can use structured webhooks and automated acknowledgment states. Webhook acknowledgments record at least three states: payload received by endpoint, payload accepted by CAD or relay, and alert acknowledged by dispatch workflow when the agency exposes that state. Legacy routes preserve the same incident-candidate identifier across REST, secure SMTP, and SMS-derived notifications so duplicate alerts can be reconciled during after-action review.
For agency onboarding, endpoint testing includes certificate validation, payload schema validation, jurisdiction routing, acknowledgment capture, and a simulated endpoint outage before production activation.
Latency Optimization and System Redundancy
Latency optimization focuses on the controllable portion of the chain: ingestion after feed publication, verification, payload assembly, and routing. The system prioritizes events by risk context, keeping processing times minimal. Edge workers cache jurisdiction polygons, known heat-source masks, recent alert IDs, and current routing endpoints so verification can continue during short upstream database interruptions.
Important: During systematic validation, retry logic uses exponential backoff with bounded attempts—evaluated at approximately 5, 15, 45, and 120-second intervals—followed by escalation to a secondary route rather than indefinite silent retry.
Redundant routing uses at least two independent paths when available: a primary HTTPS webhook and a preapproved alternate such as secure SMTP, SMS relay, or a regional emergency communications bridge. Endpoint health checks run about every 1 to 5 minutes during active fire-weather periods and every 15 to 60 minutes during low-risk monitoring periods, with failures visible to operations staff.
During high-risk operating periods, latency dashboards display feed receipt age, queue depth, verification duration, outbound routing duration, and acknowledgment lag as separate measures rather than one blended number.
Academic Sources
Reference selection is limited to operational standards and canonical data documentation that an agency can independently verify. The methodology anchors data acquisition to NASA Earthdata FIRMS documentation, which describes access to active fire and thermal anomaly data through API and download formats, including near-real-time products derived from MODIS and VIIRS sensors. NG9-1-1 interoperability aligns with NENA i3 materials, which define the architectural model used for interoperable emergency-service data exchange, location handling, and routing concepts.
Agency-specific CAD schemas, endpoint authentication, and acknowledgment semantics are captured in a local interface-control document approved before production routing. For methodology maintenance, source documentation is reviewed at least once before each regional fire season and again after any upstream API, data product, or emergency-routing standard change.
Bottom Line: Stop treating satellite fire detections as standalone alerts and engineer them as structured evidence payloads. Mandate TLS 1.3 webhooks with strict JSON schemas for all new CAD integrations, and deprecate unstructured email or SMS alerts entirely for primary dispatching. If an agency cannot support automated acknowledgment states, route the data to a secondary verification desk rather than dumping unverified coordinates into their live dispatch queue.
Discussion
No comments yet.