-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] - Worksite Triage and Status v10 #317
Comments
|
I am in support of this. Like Jared and Katie, points are easier to see and better provide the details. I "think" it was mentioned on the call today, but I feel we also need to add a "segment" of some kind. Essentially defining the area affected by this worksite. This would essentially be an area within an already established search segment. I think Katie was the one that referred to this. Points provide key details |
We need to get with the Esri Field Maps Team to talk about how we would / would not integrate this with Field Maps Tasks. |
Dave Weber suggests using the words "Sustained US&R operations" in addition to any equipment requirements as part of the definition for Worksites. We need to include a temporal component in the definition. How long do you have to be there? Distilled down to one sentence. |
Latest working definition - A Worksite is a partially collapsed structure, fully collapsed structure, debris pile, or any other location that requires sustained US&R Operations. |
Which app?
QuickCapture
Describe requirements
Real-world Problem: In an earthquake, or any disaster, where structures or debris require heavy US&R techniques, it is critical to TRIAGE those worksites. Where can we do the most good, for the most people, with the resources we have and will have tomorrow?
One of the challenges with the current "RST" approach is that it prioritizes Risk and Probability of Survivors but does not necessarily help with resource allocation and has no built-in status monitoring. The INSARAG Worksite Triage process however, prioritizes 1) Probability of Survivors and 2) Effort (# of hours of work) which can be used to allocate Type I US&R Task Forces, Type III US&R Task Forces, and non-US&R resources appropriately.
Technical Problem: We have created layers, maps, and apps based on the FEMA US&R Rapid Structure Triage Process. However, this process has never been tested in an earthquake scenario and is not readily applied in wide area search. In its current state, it supports to current RST process, but does not support resource allocation or even worksite status tracking. Furthermore, the RST layer was "bound" to the Hazard Assessment process and this has created some additional process and technical challenged.
Technical Solution: We would like to build out a new data model that can be part of SARCOP. We want to simplify it and also more closely align it with the INSARAG worksite triage process. We will not totally abandon the RST process, but we will find a clear path to interoperability.
Proposed Primary Symbology for Triage Phase

Test: https://napsg.maps.arcgis.com/home/item.html?id=fdd5060c53544bbc9824143b42abc10f
Proposed Symbology for Worksite Status
Test: Dashboard https://www.arcgis.com/apps/dashboards/8b7abe051de24a0e8eee61ee2edca307
Current Symbology

Alternatives
Status quo
Other Relevant Info
We will need to review this with the FEMA US&R Advisory Organization, however, we would not be creating any new processes, just "digitizing" them. I'll add the Strategic Goals this supports 1.2.3.2 - Expand the System-level understanding for requesting and integrating INSARAG US&R teams
Priority impact
p1 - time sensitive
Impact
This is critical to our success in a major Earthquake and can also be applied in Wide Area Search scenarios where identifying "worksites" and tracking their status is needed (e.g., Maui Wildfire secondary searches in the commercial district that requires heavy equipment, TC Helene in large debris sites that requires significant delayering +1 Operational Period).
The text was updated successfully, but these errors were encountered: