Fire Disturbance Data Processing

[jdduh]

See #49 for fire data sources. Please note the spec of the fire data might continue to evolve.

1. Clip the NIFC ArcGIS Server feature services to the AOI layers.gdb - firehistory and firecurrent
2. It appears that the output featureclasses contains multipart features, i.e., each attribute record represents a unique fire regardless if the original fire polygons are divided by clip tool
3. Delete all polygons in the firehistory layer that have a FIRE_YEAR prior to 1981
4. Retrieve the fire year from the attr_FireDiscoveryDataTime in the firecurrent layer
5. Create standard YEAR field in both firehistory and firecurrent and merge them into nifcfire layer for subsequent processes

[jdduh]

A sample AOI (13309220_ID_USGS_Mf_Salmon_R_at_Mf_Lodge) is uploaded to the ftp server, under the BAGIS_aois\Fire_Disturbance_AOIs folder.

[lbross]

What other fields do we want in the new nifcfire layer? Just the year?

[jdduh]

Yes, just the year.
There should be a step 4.5 to remove duplicate fires in firecurrent and firehistory (keep the duplicates in firehistory and remove them from firecurrent). firecurrent is a temporary/working dataset that is waiting for validation, It still contains fires that were validated and had been moved into firehistory.

4.5. Find the most current year in the firehistory and delete fire records prior to that year from the firecurrent before merging.

Notes: it's unclear if the validation was done on a fixed timetable or case-by-case for individual fires. There should be a logic to check if a fire record to be removed from firecurrent actually exists in firehistory. Fire boundaries of the same fire in firecurrent and firehistory are very likely to be different (i.e., the geometry was altered during the validation).

[lbross]

It appears we can join firecurrent and firehistory using firehistory.IRWINID and firecurrent.polyIRWINID. Let's use IRWINID {63FFB3A1-2BC3-4E08-9C97-B17F9A05F22B} from the 13309220_ID_USGS_Mf_Salmon_R_at_Mf_Lodge AOI as an example. There is a 2021 record for this fire in firehistory and a record in firecurrent. Should we exclude the record from firecurrent as a duplicate?

Edit: I recommend adding irwinid to the nifcfire layer. It will be helpful for debugging purposes so that we can find the record(s) in the source tables.

[jdduh]

Please use and keep IRWINID in the fire layers.

https://www.nwcg.gov/publications/pms936-1/data-preparation/incident-information

[lbross]

Maintaining google drive document with geoprocessing steps

[lbross]

Some details on the data I have found. It looks like they didn't start using IRWINID until 2016, thus there are many records in firehistory with a null IRWINID. This shouldn't cause a problem with the merge because the oldest records I have found in firecurrent are from 2020. However, I added INCIDENT to the fields in the new fire layers so we have a way to identify them. I don't know if there is another primary key we could use to identify the older records?
Also, I have found multiple duplicates in firehistory where records have the same irwinid. I don't know if this is a problem?

[jdduh]

The fire ID (primary key) is for reconciling the duplicate records in the historical and current fire datasets. I have to assume all the data in the historical dataset is correct, unless we spot obvious errors.

[lbross]

I don't see a field named fire ID in either layer. There is a field called UNQE_FIRE_ID in firehistory that appears to be truly unique, and a field called attr_UniqueFireIdentifier on firecurrent. These keys appear to match between the two layers and is used earlier on the firehistory layer. The oldest records with this field populated are from 2006. Maybe we should use this instead of IRWINID to eliminate duplicates between firehistory and firecurrent?

The duplicates I find in the historical fire dataset are interesting. Take a look at this IRWINID on the firehistory layer in 13309220_ID_USGS_Mf_Salmon_R_at_Mf_Lodge: {30BCC069-947B-43F3-B139-0761FD79C4BD}. It is the same fire because the name and area are the same. However, the records have different UNQE_FIRE_ID and were generated by different agencies: USGS and BLM. I doubt that NWCC will want to duplicate the area of these fires in the statistics.

We could add a step to de-dup them using the IRWINID, but as I said previously, IRWINID only goes back to 2016.

[jdduh]

I meant the IRWINID. We only need IRWINID for reconciling the duplicates between firehistory and firecurrent.
I will verify with NWCC how they want to handle areas that were burned multiple times in the same time period (annual or 5-year). If they are fine to not count the reburned areas multiple times, then we can just dissolve all the burn area polygons into one flat polygon. This should automatically take care of the duplicated records in the firehistory layer.

[lbross]

In this google slide deck there are references to USGS MTBS raster data. Are these steps we should be adding to Fire Disturbance Data Processing? If so, is there a spec beyond clipping the WMS to the AOI?

[lbross]

Do we want to fold these data sources into the data source architecture that we are using for the other BAGIS-Pro layers? If so, then I will need a heading and a description. Do we want to add them to the existing batch tool title page? Or have a separate title page for fire data sources?