consistent and reproducible IDs for delineated events

[mikoontz]

Hi firedpy team,

Great product! Thanks for making the algorithm reusable. I have a general feature request, and it seems that #33 from @admahood is one specific way to implement it.

As folks start using this algorithm to build event databases beyond the spatiotemporal scope of the original publication of the dataset (https://scholar.colorado.edu/concern/datasets/nv935382p), it would be helpful to ensure that the unique identifiers of the events can be reproduced. For example, the currently published dataset goes through January of 2019 and covers CONUS, but rerunning the algorithm for just February of 2019 to present would (presumably) generate new unique IDs that overlap with the ones already published. That will make it more difficult to join datasets created with firedpy with other fire data (e.g., MTBS, the FRAP perimeters, FPA-FOD) if the FIRED unique identifiers change with each algorithm run.

One idea is to include some metadata associated with each event in the ID. The year, month, and MODIS tile seem like good candidates here, since those are the minimum units of time and space in which the MODIS burned area product are delivered. On second thought, since the algorithm could be based on products other than MODIS burned area, maybe Adam's approach to using the centroid coordinates and event start datetime makes more sense (though you could also include the datetime and centroid in the ID in addition to a random string for readability).

I suppose the short way of saying this is that I think this thought of Adam's might be more important than he gives himself credit for!

[lisestdenis]

Hi Mike, I think some sort of temporal stamp with the id makes sense. Lise From: Michael Koontz <[email protected]> Date: Monday, March 1, 2021 at 9:19 AM To: earthlab/firedpy <[email protected]> Cc: Subscribed <[email protected]> Subject: [earthlab/firedpy] consistent and reproducible IDs for fire events (#35) Hi firedpy team, Great product! Thanks for making the algorithm reusable. I have a general feature request, and it seems that #33<#33> from @admahood<https://github.com/admahood> is one specific way to implement it. As folks start using this algorithm to build event databases beyond the spatiotemporal scope of the original publication of the dataset (https://scholar.colorado.edu/concern/datasets/nv935382p), it would be helpful to ensure that the unique identifiers of the events can be reproduced. For example, the currently published dataset goes through January of 2019 and covers CONUS, but rerunning the algorithm for just February of 2019 to present would (presumably) generate new unique IDs that overlap with the ones already published. That will make it more difficult to join datasets created with firedpy with other fire data (e.g., MTBS<https://www.mtbs.gov/>, the FRAP perimeters<https://frap.fire.ca.gov/frap-projects/fire-perimeters/>, FPA-FOD<https://www.fs.usda.gov/rds/archive/catalog/RDS-2013-0009.4>) if the FIRED unique identifiers change with each algorithm run. One idea is to include some metadata associated with each event in the ID. The year, month, and MODIS tile seem like good candidates here, since those are the minimum units of time and space in which the MODIS burned area product are delivered. On second thought, since the algorithm could be based on products other than MODIS burned area, maybe Adam's approach to using the centroid coordinates and event start datetime makes more sense (though you could also include the datetime and centroid in the ID in addition to a random string for readability). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#35>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA6YEZ7TIRDKICNADUE45R3TBO5AJANCNFSM4YM2VCTQ>.

[admahood]

Right on. I think it might be a good idea to think about that now as well, especially considering we just re-ran firedpy going to 2020, and Max and I were thinking about updating it on CU scholar. If it turns out that updating the code to include location and time-based metadata within the event IDs doesn't take a ton of time, it might be a good idea to do that now and have those new IDs in the next CU scholar update

[mikoontz]

Looks like this is done now, and can be closed?