Thermal activity detected by the VIIRS sensors on the NOAA/NASA Suomi NPP, NOAA-20, and NOAA-21 satellites during the last 7 days. A brief summary of the item is not available. Add a brief summary about the item.
Feature layer
from
Item created: Apr 1, 2020 Item updated: Feb 22, 2025 View count: 131,646,391
Description
Consumption Best Practices:
- As a service that is subject to very high usage, ensure peak performance and accessibility of your maps and apps by avoiding the use of non-cacheable relative Date/Time field filters. To accommodate filtering events by Date/Time, we suggest using the included "Age" fields that maintain the number of days or hours since a record was created or last modified, compared to the last service update. These queries fully support the ability to cache a response, allowing common query results to be efficiently provided to users in a high demand service environment.
- When ingesting this service in your applications, avoid using POST requests whenever possible. These requests can compromise performance and scalability during periods of high usage because they too are not cacheable.
Scale/Resolution: 375-meter
Update Frequency: Hourly using the aggregated live feed methodology
Area Covered: World
What can I do with this layer?
This layer represents the most frequently updated and most detailed global remotely sensed wildfire information. Detection attributes include time, location, and intensity. It can be used to track the location of fires from the recent past, a few hours up to seven days behind real time. This layer also shows the location of wildfire over the past 7 days as a time-enabled service so that the progress of fires over that timeframe can be reproduced as an animation.
The VIIRS thermal activity layer can be used to visualize and assess wildfires worldwide. However, it should be noted that this dataset contains many “false positives” (e.g., oil/natural gas wells or volcanoes) since the satellite will detect any large thermal signal.
Fire points in this service are generally available within 3 1/4 hours after detection by a VIIRS device. LANCE estimates availability at around 3 hours after detection, and esri livefeeds updates this feature layer every 15 minutes from LANCE.
Even though these data display as point features, each point in fact represents a pixel that is >= 375 m high and wide. A point feature means somewhere in this pixel at least one "hot" spot was detected which may be a fire.
VIIRS is a scanning radiometer device aboard the Suomi NPP, NOAA-20, and NOAA-21 satellites that collects imagery and radiometric measurements of the land, atmosphere, cryosphere, and oceans in several visible and infrared bands. The VIIRS Thermal Hotspots and Fire Activity layer is a livefeed from a subset of the overall VIIRS imagery, in particular from NASA's VNP14IMG_NRT active fire detection product. The downloads are automatically downloaded from LANCE, NASA's near real time data and imagery site, every 15 minutes.
The 375-m data complements the 1-km Moderate Resolution Imaging Spectroradiometer (MODIS) Thermal Hotspots and Fire Activity layer; they both show good agreement in hotspot detection but the improved spatial resolution of the 375 m data provides a greater response over fires of relatively small areas and provides improved mapping of large fire perimeters.
Attribute information
- Latitude and Longitude: The center point location of the 375 m (approximately) pixel flagged as containing one or more fires/hotspots.
- Satellite: Whether the detection was picked up by the Suomi NPP satellite (N) or NOAA-20 satellite (1) or NOAA-21 satellite (2). For best results, use the virtual field WhichSatellite, redefined by an arcade expression, that gives the complete satellite name.
- Confidence: The detection confidence is a quality flag of the individual hotspot/active fire pixel. This value is based on a collection of intermediate algorithm quantities used in the detection process. It is intended to help users gauge the quality of individual hotspot/fire pixels. Confidence values are set to low, nominal and high. Low confidence daytime fire pixels are typically associated with areas of sun glint and lower relative temperature anomaly (<15K) in the mid-infrared channel I4. Nominal confidence pixels are those free of potential sun glint contamination during the day and marked by strong (>15K) temperature anomaly in either day or nighttime data. High confidence fire pixels are associated with day or nighttime saturated pixels.
- Please note: Low confidence nighttime pixels occur only over the geographic area extending from 11 deg E to 110 deg W and 7 deg N to 55 deg S. This area describes the region of influence of the South Atlantic Magnetic Anomaly which can cause spurious brightness temperatures in the mid-infrared channel I4 leading to potential false positive alarms. These have been removed from the NRT data distributed by FIRMS.
- FRP: Fire Radiative Power. Depicts the pixel-integrated fire radiative power in MW (MegaWatts). FRP provides information on the measured radiant heat output of detected fires. The amount of radiant heat energy liberated per unit time (the Fire Radiative Power) is thought to be related to the rate at which fuel is being consumed (Wooster et. al. (2005)).
- DayNight: D = Daytime fire, N = Nighttime fire
- Hours Old: Derived field that provides age of record in hours between Acquisition date/time and latest update date/time. 0 = less than 1 hour ago, 1 = less than 2 hours ago, 2 = less than 3 hours ago, and so on.
Note about near real time data:
Near real time data is not checked thoroughly before it's posted on LANCE or downloaded and posted to the Living Atlas. NASA's goal is to get vital fire information to its customers within three hours of observation time. However, the data is screened by a confidence algorithm which seeks to help users gauge the quality of individual hotspot/fire points. Low confidence daytime fire pixels are typically associated with areas of sun glint and lower relative temperature anomaly (<15K) in the mid-infrared channel I4. Medium confidence pixels are those free of potential sun glint contamination during the day and marked by strong (>15K) temperature anomaly in either day or nighttime data. High confidence fire pixels are associated with day or nighttime saturated pixels.
- March 7, 2024: Updated to include source data from NOAA-21 Satellite.
- September 15, 2022: Updated to include 'Hours_Old' field. Time series has been disabled by default, but still available.
- July 5, 2022: Terms of Use updated to Esri Master License Agreement, no longer stating that a subscription is required!
An in-depth description of the item is not available.
Tables
Basemap
Project Contents:
Solution Contents
Contents
Layers
Screenshots
Terms of Use
No special restrictions or limitations on using the item's content have been provided.
Details
Dashboard views: Desktop
Source: Feature Service
Creating data in:
Published as:
Other Views:
Dependent items in the recycle bin
Applicable: 2d
Data updated: Feb 22, 2025, 6:17 PM
Schema updated: Feb 22, 2025, 6:17 PM
Size: 0 KB
ID: dece90af1a0242dcbf0ca36d30276aa3
Image Count: 0
Image Properties
Layer Drawing
Using tiles from a cache
Dynamically from data
Share
Owner
Folder
Categories
This item has not been categorized.
Tags
viirs, fire, fires, LANCE, FIRMS, NOAA20, NOAA-20, SuomiNPP, Suomi NPP, SNPP, hotspot, hotspots, hot spot, hot spots, detections, detection, VNP14IMG_NRT, thermal, EOS, NASA, wildfire, hosted, environment, esri_environment, earth observations
Credits (Attribution)
No acknowledgements.NASA
Comments (92)
Working to resolve an issue with the layers.
Service back to normal.
Hi, is there a problem with the layer? Failed to add data: https://services9.arcgis.com/RHVPKKiFTONKtxq3/arcgis/rest/services/Satellite_VIIRS_Thermal_Hotspots_and_Fire_Activity/FeatureServer ERROR: code:504, Your request has timed out., Proxy server got bad address from remote server (verify the server is running).
Thanks, it's now working!
We are experiencing a global issue that effects the services on this Org site. We are working to resolve this as quickly as possible. Thank you and sorry for any inconvenience!
NASA’s Fire information for Resource Management System (FIRMS) has recently introduced access to VIIRS active fire detection data from NOAA-21. Is NOAA-21 Data in this layer now?
Awesome!! You guys are the best!
Good news, the NOAA-21 satellite just came back online and we were able to finish the assessment. Data matches up and we were able to add this to the Layer update.
The service is currently using NOAA-20 data, but we can evaluate the NOAA-21 update and review it's impact if we were to upgrade. No commitments here, but if the schema is close enough and it doesn't adversely impact users, no reason we can't switch over. Thank you for the suggestion!
Hello, I believe the transparency symbology for this layer is reverse from what is intended. Currently new points have a 70% transparency and older points are displayed as opaque.
Great find! Thank you for noticing the discrepancy, I flipped the high/low range to properly reflect the transparency by age. Not sure what triggered the change, but we'll keep an eye on it!
Hey, it looks like the data update is taking longer than expected. The data is already updated in FIRMS but it hasn't been updated here yet. I'm in GMT +7. Usually the data is updated around 3-4.30 PM. Now I have to wait until 5-9 PM.
Over the past 5 days we have seen intermittent timeout issues accessing the 'firms' source data. This could be causing some of the delays you are seeing as the update routine would have to wait to retry during the next run an hour later. These issues usually clear up within an hour or two. As a safeguard, I set the routine to run more frequently to check for updates more regularly, though the source does not update but one an hour. This should allow the routine to compensate more quickly.
I've tried using another devices and clear the cache, the update is still late. I did set filter and pop up configuration, perhaps it could cause the delay?
Looking back at the processing logs, the feed routine has been updating every hour without issue. The last reported incident was a month ago. Could the client side cache be causing an issue?