Share Public Web Products

The continued growth and expansion of the NIFC AGOL Org has meant that the NIFC AGOL Org has entered a new phase of public publishing. To keep in line with DOI security policies, tighter controls and oversight of public content shared from the NIFC AGOL Org have been created. 
Any user that needs to have non-emergency content shared with the public must fill out the Public Publishing Request Form. The NIFC Data Manager role is the only role that can share content to the public. This is to ensure that on an active incident, emergency and incident related content can be shared with the public without having to go through the form and approval process. Users in the Data Manager role, not on an active incident, must go through the approval process.

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. 

If you receive a 429 error, please submit a Support Request.

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 affect 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 submit a Support Request.

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.