3 ms·

Oof. I've got some training and experience in disaster management, including being a part of the overhead team for the Camp Fire last year through my county's s

Oof. I've got some training and experience in disaster management, including being a part of the overhead team for the Camp Fire last year through my county's search and rescue team. The things they're advertising here just aren't the things that disaster teams need. Nobody on a natural disaster has ever said, "you know what would make this so much easier? ...Blockchain." The only part of the Camp Fire that would satisfy a tech boner would've been Alameda County's drone team. It turns out that they've been fostering a pretty good drone team and they were able to do flyovers of large sections of the disaster area, capturing imagery down to 1cm resolution and piping it back to a mobile GIS center that looked straight out of an episode of CSI. Their work was good enough to satisfy the requirements for a lot of insurance adjusters who would ordinarily have had to physically visit the site. It could've sped up the entire search and recovery operation by several days if it weren't for CalFire's insistence on redoing all of it with pen and paper. The number one technological need for disaster work is communications, hands down. One of the first pieces of infrastructure that falls apart during a major disaster is communications, and it's also the most urgent tech problem to solve, every time, because you can't have teams out in a disaster area with bad comms. We really need some kind of reliable, fast-deploying, low-maintenance radio and cellular infrastructure, and nobody's figured that out yet. Probably the next big pain point is GIS or data management. Our current GIS software is good enough in the hands of skilled operators, but getting data into and out of it is labor intensive and its dataviz isn't exactly cutting edge. A mobile app that interfaced well with it and allowed search teams to bring up a search segment with a limited amount of data through a text message or QR code would be badass. On the data management side, every single event, item of interest, and squawk of radio traffic has to be logged. Every single one. For a big disaster, this turns into reams and reams of dense paperwork and hundreds of man-hours to compile it all. And when teams arrive at IC in the morning, they have to fill out information cards and receive printed packets every single time, because there's no state-level coordinated database of DSWs and no way to quickly organize them by skillsets. This slows down deployment by around 2 hours in the hands of a top-of-the-line management team, and by much more when the incident management team is less experienced. If you're seriously interested in pursuing any of this, feel free to contact me at the email address in my profile. We've already started inter-agency training events for this year's next wildland-urban-interface fire.

chrisweekly 7y ago
+1 Thank you for such a detailed, informed and relevant comment. Merits tons of upvotes.
Bartweiss 7y ago
This is fascinating, thank you. My first thought reading the prompt was that "build tech for disaster recovery" is exactly the wrong direction of approach. There's far more good to be done, more efficiently, by taking existing systems in one category and finding places they can help in the other. "Adding disaster support to tech" might look like Facebook's safe-check-in feature, and "adding tech to disaster recovery" looks like everything you describe. I would imagine the military truisms about technology are every bit as true in disaster management - namely that everything works right up until you need it, and has all the features you don't want but none that you do. Availability tracking for antibiotics sounds great, but it's probably useless unless it works over a crowded 2G connection and lets you manually alter records when the shiny inflow/outflow features can't describe reality. ("Blockchain for supply chain tracking" sounds particularly egregious; when you find out somebody mislabeled things five transactions back, what the heck do you do about it?) Everyone I've known developing for outdoor or rural use is less interested in features than in redundancy, flexibility, and low-tech functionality. It'd be very interesting to work on something like bringing the easiest-to-use GIS solutions for hiking, research, or land development over to disaster recovery (assuming they're better than what you have). There are probably far fewer people qualified to build field-deployment cell infrastructure, but that also sounds fascinating. And all of it sounds far more useful than the IBM challenge.
- thaumaturgy 7y ago
  > ...everything works right up until you need it, and has all the features you don't want but none that you do. I hadn't heard that before, but yep, that's about right. Especially when it's been developed by people without a lot of field experience. > It'd be very interesting to work on something like bringing the easiest-to-use GIS solutions for hiking, research, or land development over to disaster recovery (assuming they're better than what you have). I hasten to clarify here that we don't really want to give up what we've got already for GIS, we'd just love some help extending it. What we use is a specialized offshoot of https://caltopo.com/ https://caltopo.com/, built by the same developer but with additional features designed for search operations. That developer is himself a very experienced and well-liked search and rescue volunteer, and that experience is reflected in the features in the software (including the ability to host it locally). There's going to be a high bar to leap over to adapt anything else to fit the same niche and get the trust and adoption that sartopo already has. But, for various good reasons, we still rely primarily on handheld Garmin GPS units for ground work. These need to be physically connected to a computer to get map data loaded and then search activity unloaded. It takes almost two minutes per device per operational period if nothing goes wrong, so in a massive multi-agency search, you can imagine the bottleneck this creates. As a fall-back, we've started trying to use Avenza. It's ... okay. Anybody can walk up to a wall with a big printed QR code and start using their smartphone for navigation. But it still requires a network connection to get the search area loaded and it's not really ideal for retrieving search activities when a ground team returns to IC. So what would be really sexy is an iOS/Android app that copied basic Garmin features, but had area map data stored locally (a la HereWeGo), and could communicate directly with sartopo to download segments and markers and upload tracks. That would be sooo nice.

chrisweekly 7y ago

+1 Thank you for such a detailed, informed and relevant comment. Merits tons of upvotes.

Bartweiss 7y ago

This is fascinating, thank you. My first thought reading the prompt was that "build tech for disaster recovery" is exactly the wrong direction of approach. There's far more good to be done, more efficiently, by taking existing systems in one category and finding places they can help in the other. "Adding disaster support to tech" might look like Facebook's safe-check-in feature, and "adding tech to disaster recovery" looks like everything you describe. I would imagine the military truisms about technology are every bit as true in disaster management - namely that everything works right up until you need it, and has all the features you don't want but none that you do. Availability tracking for antibiotics sounds great, but it's probably useless unless it works over a crowded 2G connection and lets you manually alter records when the shiny inflow/outflow features can't describe reality. ("Blockchain for supply chain tracking" sounds particularly egregious; when you find out somebody mislabeled things five transactions back, what the heck do you do about it?) Everyone I've known developing for outdoor or rural use is less interested in features than in redundancy, flexibility, and low-tech functionality. It'd be very interesting to work on something like bringing the easiest-to-use GIS solutions for hiking, research, or land development over to disaster recovery (assuming they're better than what you have). There are probably far fewer people qualified to build field-deployment cell infrastructure, but that also sounds fascinating. And all of it sounds far more useful than the IBM challenge.

thaumaturgy 7y ago
> ...everything works right up until you need it, and has all the features you don't want but none that you do. I hadn't heard that before, but yep, that's about right. Especially when it's been developed by people without a lot of field experience. > It'd be very interesting to work on something like bringing the easiest-to-use GIS solutions for hiking, research, or land development over to disaster recovery (assuming they're better than what you have). I hasten to clarify here that we don't really want to give up what we've got already for GIS, we'd just love some help extending it. What we use is a specialized offshoot of https://caltopo.com/ https://caltopo.com/, built by the same developer but with additional features designed for search operations. That developer is himself a very experienced and well-liked search and rescue volunteer, and that experience is reflected in the features in the software (including the ability to host it locally). There's going to be a high bar to leap over to adapt anything else to fit the same niche and get the trust and adoption that sartopo already has. But, for various good reasons, we still rely primarily on handheld Garmin GPS units for ground work. These need to be physically connected to a computer to get map data loaded and then search activity unloaded. It takes almost two minutes per device per operational period if nothing goes wrong, so in a massive multi-agency search, you can imagine the bottleneck this creates. As a fall-back, we've started trying to use Avenza. It's ... okay. Anybody can walk up to a wall with a big printed QR code and start using their smartphone for navigation. But it still requires a network connection to get the search area loaded and it's not really ideal for retrieving search activities when a ground team returns to IC. So what would be really sexy is an iOS/Android app that copied basic Garmin features, but had area map data stored locally (a la HereWeGo), and could communicate directly with sartopo to download segments and markers and upload tracks. That would be sooo nice.