5 ms·

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. The

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.

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.