Public Web Products
The permission to share content publicly is available to several account roles within the NIFC Org, the NIFC Data Manager and NIFC Public Publisher. These roles are generally restricted to Geographic Information System Specialist (GISS) and Public Information Officer (PIO).
This ability should not be used lightly. Because something can be shared with the public does not mean it should or needs to be.
Careful consideration must be given to each product shared with the public. Always ensure that public content has been approved by the appropriate party at the unit or on the Incident Management Team (IMT) and does not contain any non-public information.
NIFC Org Public Content Policy
The Public Content Policy and other rules and requirements for NIFC Org content can be found in the NIFC Org Rules of Behavior.
Publicly shared content must serve a current, legitimate business need to provide information to the general public.
Publicly shared feature services shall not have Sync or Edit enabled, relative date queries or extent filters shall not be used in any filter or view definition, and the cache control will be set to 5 Minutes at a minimum.
Rate Limiting
When a database is receives an excessive number of requests, it will cease to respond and begin returning errors to protect the system from being overwhelmed. This is called rate limiting and is generally associated with error number 429.
Rate limiting most often occurs when a public service is not configured properly and is included in a map that goes viral, resulting in a massive amount of demand.
Rate limiting is applied to and affects the entire NIFC Org, not just the service(s) causing it. One popular map can prevent
If you receive a 429 error, please report it to the NIFC Admins immediately at wildfireresponse@firenet.gov.
Critical Settings
The most important aspect of public data sharing is ensuring that the content can handle the potential load of thousands upon thousands of views.
In 2020, the official public perimeter service received nearly 3 billion hits (that’s billion, with a B).
This scalability is accomplished through the use of a Content Delivery Network (CDN). A CDN uses many geographically distributed servers to cache and deliver the data as opposed to relying on only the one that houses the source database.
Properly configured services hosted in the NIFC Org will leverage the Esri CDN automatically.
There are three primary settings that will affect a service’s ability to use the CDN (i.e., be cached): Edit, Sync, and Cache Control.
Several query types also effect caching: Relative Date/Time and Extent Filters.
Edit
Editing must be disabled on all publicly shared services.
Enabling editing on a public service will allow anyone in the world to modify the data. There are very few cases where this is desirable and should generally be avoided for that reason alone.
However, the pertinent reason here is that editable services do not use the CDN. When enabled, each call will travel all the way to the database to ensure any edits are performed on the current data state (e.g., you would not want to update a feature that someone else deleted several minutes ago).
Sync
Sync must be disabled on all publicly shared services.
The Sync setting allows users to create a replica of the data such as taking a map offline in Field Maps or creating the Offline Copy of the NIFS in ArcGIS Pro.
Like Edit, having Sync enabled will stop the use of the CDN, forcing each query all the way to the database to ensure currency.
Cache Control
The cache control will be set to 5 Minutes at a minimum for any public service.
The Cache Control setting determines how long the CDN will wait before refreshing the information it has cached.
Only set the cache control higher than 5 minutes if the data is not updated or is not time sensitive. Setting the cache control to 1 hour will potentially result in up to a 1-hour delay in updates being seen by end users as the cache waits to refresh.
Relative Time Queries and Extent Filters
Relative date queries or extent filters shall not be used in any filter or view definition.
Relative time queries and extent filters may produce requests that are not cached on the CDN and therefore have the potential to cause rate limiting.
Relative Time
A relative time query is based off a reference to the current date-time. Another way to think of this is as a rolling time frame, such as:
- FireDiscoveryDateTime is in the last 3 days
- EditDate is not in the last 2 weeks
Extent Filter
Extent filters are configuration options in certain web apps and dashboards. Most often they are used to produce a count or list of features within the displayed area. Every time a user pans or zooms the map with the extent filter, it sends a request for the data within the displayed area which can quickly add up to a significant load.
There are some scenarios where relative time queries and extent filters can be configured and not affect the database.
High-use apps (state or regional) that need to leverage either relative date queries or extent filters may be approved for use by the NIFC Admins with review. To obtain approval, please contact wildfireresponse@firenet.gov.
Hosted Feature Layer Views
The best way to create cacheable services for public use when the data still needs to be editable by someone is through Hosted Feature Layer Views.
A Hosted Feature Layer View is a new service with independent settings that points back to the same data as its parent service.
This allows the implementation of an internal, editable layer for data management, and a cacheable read-only layer for sharing publicly.
Official Services for Public Use
For some data, optimized layers for public use have already been created and are available on the NIFC Open Data Site.
When wildland fire (point) locations and/or perimeters need to be displayed in public content, the official Open Data Site layers should always be used.
Wildland Fire Locations
Point locations for wildfires, prescribed fires, and complexes. Primarily sourced from IRWIN, the Full History will eventually contain historic data from pre-IRWIN systems.
WFIGS - Last 24 Hour Wildland Fire Locations
- Publicly Available
- Limited Attributes
- Features limited to those with a Fire Discovery Date Time within the last 24 hours (see item description for filter details)
WFIGS - Current Wildland Fire Locations
- Publicly Available – Open Data Site Link
- Limited Attributes
- Features limited to incidents recently edited in IRWIN (see item description for filter details)
WFIGS - 2022 Wildland Fire Locations to Date
- Publicly Available – Open Data Site Link
- Limited Attributes
- Features limited to those created on or after January 1, 2022
WFIGS - Wildland Fire Locations Full History
- Publicly Available – Open Data Site Link
- Limited Attributes
- Includes all valid features in the Wildfire Locations data set. See the item description for details on data sources and filter
Wildland Fire Perimeters
Perimeter services use the best available geometry from ranked sources, primarily the NIFS and the InFORM Final Fire Perimeter service. Source polygon attribution is enriched with the IRWIN fields.
WFIGS - Current Wildland Fire Perimeters
- Publicly Available – Open Data Site Link
- Limited Attributes
- Features limited to incidents recently edited in IRWIN with a publicly available perimeter (see item description for filter details)
WFIGS - 2022 Wildland Fire Perimeters to Date
- Publicly Available – Open Data Site Link
- Limited Attributes
- Features limited to those created on or after January 1, 2022, with a publicly available perimeter (see item description for filter details)
WFIGS - Wildland Fire Perimeters Full History
- Publicly Available – Open Data Site Link
- Limited Attributes
- Includes all features in the Wildfire Perimeters data set with a publicly available perimeter (see item description for filter details)
- Full History will eventually include additional perimeters loaded from historic data sets.
Additional Resources