Call for Code – Developer competition that seeks solutions for natural disasters(developer.ibm.com)
developer.ibm.com
Call for Code – Developer competition that seeks solutions for natural disasters
https://developer.ibm.com/callforcode/
48 comments
I know you're just being flip, but the benefits of "thoughts and prayers" isn't solely to ask some imaginary being for help.
The benefit is that it directs the attention of the community at large towards the problem. This raises awareness with the hope that those with the means to help will do so.
Its an anti-fragile method of asking the community for help without knowing the specifics of how they can help.
actually, now that I think about it, "Thoughts and Prayers" is no different than a "Call for Code" except that it is generalized to all society instead of just software developers.
The benefit is that it directs the attention of the community at large towards the problem. This raises awareness with the hope that those with the means to help will do so.
Its an anti-fragile method of asking the community for help without knowing the specifics of how they can help.
actually, now that I think about it, "Thoughts and Prayers" is no different than a "Call for Code" except that it is generalized to all society instead of just software developers.
Never understood why fb implemented a way to send a starbucks gift card on someones bday but refuses to associate a "donate to this charity" button when you pick a disaster filter or "mark yourself safe" or whatever
I don't think that pseudocode would work, I'd be more inclined to use something moral and secure like Rust.
Surely we can encode morality in blockchain
I feel like a trojan that hijacks all existing blockchains and kill them would do more good to climate change than any other idea we could possibly come up with. We are burning an awful amount of electricity on something that's not being used for any practical purpose but only by speculators and "investors".
A permanent, distributed ledger of morals would at least be a nice gift to future historians. Now if only we could establish a correctness proof as well...
I bet there are already projects in the making that will immediately claim the cash prize.
From their FAQ: "Applications must be new and built for the 2019 competition between February 12 and July 29 2019, but they may use code that was open sourced and available to all other participants as of February 12, 2019. Other than that, almost anything goes, and you can use any coding languages or open-source libraries."
Stop subsidizing flood insurance for people who live in places that are constantly underwater. Where's my check?
This is very much buzzwords-first and not problems-first.
> Blockchain
Ironic that such a power-hungry technology be used in dealing with natural disasters. If anything, it's just contributing to global warming. Can we please stop pretending that everything on Earth needs a blockchain?
> Blockchain
Ironic that such a power-hungry technology be used in dealing with natural disasters. If anything, it's just contributing to global warming. Can we please stop pretending that everything on Earth needs a blockchain?
Blockchain != PoW. There are plenty of blockchains without the problems you described (like IBM's Hyperledger).
Also blockchain != distributed.
Some of the supply chain applications are interesting because it's more corruption resistant.
As a currency (and a lot of other hyped applications), I agree with you, almost totally useless.
As a currency (and a lot of other hyped applications), I agree with you, almost totally useless.
It is just a stunt from IBM to promote their WATSON software. a 200k$ prize is a small price to pay to get dozens of smart people to team up and work/test/enhance your products for free...
It's more than that. IBM is trying to win developer mind share, future tech decision makers are strategically important to them in their current situation.
I think they might need to accelerate their efforts, I think a lot of people here look at them in a very negative light.
I'd love to see a CEO do for IBM what Satya did for Microsoft. A lot of OSS people thought they were the devil, and yet they've turned that around massively. Unfortunately it seems (from the outside) that IBM is just organisationally crippled from size bloat at this point.
Maybe I'm being naive but what do their 350,000 employees actually do? That's nearly as much as Apple, Google and Microsoft combined.
Maybe I'm being naive but what do their 350,000 employees actually do? That's nearly as much as Apple, Google and Microsoft combined.
Microsoft had a tremendous headcount as well. But I think that there is a subtle and important difference. Developers at Microsoft see themselves as product creators - and within every creator is a passion for the craft that good leadership can unlock. IBM, to my knowledge, has a much larger proportion of their headcount who are "contract maintainers" - doing contracted work where their KPIs implicitly optimize for "how long can we keep/grow this contract" rather than "how good is the product created."
IBM has a cultural issue that will take far more than strong leadership to change - starting to change those incentives would require a disruption to IBM's business model that could truly hurt short-term financial performance, way more than Microsoft's "hey let's start releasing dev tools for Mac/Linux in ways that don't actually cannibalize PC sales - it's not like those devs were going to switch to Windows anyways - but do make it easy for them to become long-term Azure users."
And rather than fighting on the dev-tools turf, they're trying to gain mindshare with AI-as-a-service for people who aren't really innovating in AI. I'm looking at the icons in my Mac's Dock right now, and Microsoft's winning a ton of them with best-in-class IDEs and productivity software. Watson isn't in every startup developer's Dock. Now, if IBM bought Tableau and moved Cognos in that direction, adding generous free usage tiers, maybe they get Watson-branded icons on that Dock? But I doubt this happens any time soon.
IBM has a cultural issue that will take far more than strong leadership to change - starting to change those incentives would require a disruption to IBM's business model that could truly hurt short-term financial performance, way more than Microsoft's "hey let's start releasing dev tools for Mac/Linux in ways that don't actually cannibalize PC sales - it's not like those devs were going to switch to Windows anyways - but do make it easy for them to become long-term Azure users."
And rather than fighting on the dev-tools turf, they're trying to gain mindshare with AI-as-a-service for people who aren't really innovating in AI. I'm looking at the icons in my Mac's Dock right now, and Microsoft's winning a ton of them with best-in-class IDEs and productivity software. Watson isn't in every startup developer's Dock. Now, if IBM bought Tableau and moved Cognos in that direction, adding generous free usage tiers, maybe they get Watson-branded icons on that Dock? But I doubt this happens any time soon.
Satya did amazing things for Microsoft. It shows that recovery is possible, even for a behemoth like IBM.
However, like you said - brilliant fellows aside, IBM employees as a whole are much less technical.Most would never pass a tech interview at FAANG.
However, like you said - brilliant fellows aside, IBM employees as a whole are much less technical.Most would never pass a tech interview at FAANG.
> Maybe I'm being naive but what do their 350,000 employees actually do?
I used to think it was "make chips", but they contracted that out a few years back. IT outsourcing is a big part of it, which tends to drive up staff numbers much faster than in-house projects. They're also still fairly big in business tech like POS systems, although I think that's been shrinking?
(I suppose the other answer is "IBM doesn't know either", given that they've made huge staff cuts to a lot of their older divisions.)
I used to think it was "make chips", but they contracted that out a few years back. IT outsourcing is a big part of it, which tends to drive up staff numbers much faster than in-house projects. They're also still fairly big in business tech like POS systems, although I think that's been shrinking?
(I suppose the other answer is "IBM doesn't know either", given that they've made huge staff cuts to a lot of their older divisions.)
IBM is primarily a service company. They do turnkey software development for large, clueless clients with deep pockets, such as governments across the world.
I agree with you. IBM is late to the show and far behind in terms of Data Scientists using their tools and technologies. I myself ( statistician and data scientist) used IBM products for a short period of time in the context of a PoC. my experience is that, using python/R is much better in the long run than using proprietary software that costs 100k $/year in licencee fees, without forgetting the training /setup cost that comes with any migration to IBM suite.
> using python/R is much better in the long run than using proprietary software that costs 100k $/year in license fees
It does seem like IBM has been caught out by freely available alternatives which are simply better at most scales. It reminds me of what happened to companies selling compilers or corporate VOIP solutions; they didn't just fail to keep up with the market, their entire market was supplanted by open-source solutions and single features in much larger offerings.
IBM has made a fairly productive effort to avoid that, I think, via their consulting/outsourcing divisions and value-added things like cloud solutions. As a result, their data science products are still appealing in terms of ecosystem integration and strong support options for less-technical buyers. But that doesn't seem like a wonderful position to be in long term, since it puts them in competition with AWS/GCP on one end and free tools on the other.
It does seem like IBM has been caught out by freely available alternatives which are simply better at most scales. It reminds me of what happened to companies selling compilers or corporate VOIP solutions; they didn't just fail to keep up with the market, their entire market was supplanted by open-source solutions and single features in much larger offerings.
IBM has made a fairly productive effort to avoid that, I think, via their consulting/outsourcing divisions and value-added things like cloud solutions. As a result, their data science products are still appealing in terms of ecosystem integration and strong support options for less-technical buyers. But that doesn't seem like a wonderful position to be in long term, since it puts them in competition with AWS/GCP on one end and free tools on the other.
That's so true. They need a Steve Ballmer ("Developers, developers!").
It's an old company and struggles with a heavy legacy. They would need more than just a CEO to move things around.. It's a mindset and from the outside, IBM seems to me like an old government building that provides services in areas where it had 10yo+ contracts and clients are too lazy to switch to a better provider.. it's sad, but they will definitely have the ending NOKIA had.. maybe a bit more painful ending.. we can never know :)
I agree that they need more than just a CEO. IBM's problems are very serious:
1. mid-level staff that's not technical, unable to get results quickly (one tends to get that mentality from massive open-ended consulting engagements w/o clear success metrics in place)
2. surreal TV ads aside, their brand is not visible on a daily basis, there's no consumer offering with IBM logo on it
3. there is no modern cloud offering (Softlayer ain't one)
4. their marketing of Watson has been so extreme, and so out of touch with technical realities, it's becoming a liability
1. mid-level staff that's not technical, unable to get results quickly (one tends to get that mentality from massive open-ended consulting engagements w/o clear success metrics in place)
2. surreal TV ads aside, their brand is not visible on a daily basis, there's no consumer offering with IBM logo on it
3. there is no modern cloud offering (Softlayer ain't one)
4. their marketing of Watson has been so extreme, and so out of touch with technical realities, it's becoming a liability
... on the other hand, this is what IBM does have, that I would leverage if I were CEO:
1. solid mainframe business (yes)
2. massive customer list
3. significant infrastructure (softlayer etc) that could be turned into a cloud offering
4. huge long-term consulting engagements that can turn into success stories, if run by ppl capable of delivering quick results
One more thing I would do if I were CEO - I would come up with a way to put that IBM logo in front of people... Perhaps something along the lines of "Alexa for business", based on IBM's flavor of business AI.
1. solid mainframe business (yes)
2. massive customer list
3. significant infrastructure (softlayer etc) that could be turned into a cloud offering
4. huge long-term consulting engagements that can turn into success stories, if run by ppl capable of delivering quick results
One more thing I would do if I were CEO - I would come up with a way to put that IBM logo in front of people... Perhaps something along the lines of "Alexa for business", based on IBM's flavor of business AI.
I dunno, Lou Gerstner (https://en.wikipedia.org/wiki/Louis_V._Gerstner_Jr.) managed to change IBM's direction pretty dramatically back in the '90s.
Of course, the new direction he set them on (stop developing innovative things, focus instead on high-margin consulting and services) is the one everyone's complaining about now. So...
Of course, the new direction he set them on (stop developing innovative things, focus instead on high-margin consulting and services) is the one everyone's complaining about now. So...
Just a sidenote that Nokia reinvented itself and is nowadays doing relatively good in the networking business.
strategically speaking, YES! they are not just promoting a tool among developers/researchers . it's a whole business approach they are taking. But personally I think they are late to the party. Google, Micro$oft, Amazon.. and all the other open source tools ( Python, R...) are offering a better , more flexible and versatile solutions to the public.
I think they were a bit greedy and selfish, because they could have put this challenge on Kaggle for example, and gotten a much higher momentum (where a high concentration of Data Scientists and enthusiasts are doing interesting stuff)..
An idea: provide a service for house buyers and job seekers: see which cities and neighborhoods are in danger of being inundated in the future. Probably it could be integrated with some real estate platform - calculate a simple risk score for the listing using open elevation and traffic data.
We need to start controlled abandonment of those areas already many decades early - starting from not investing more into building there.
This is a very cheap way of massive scale disaster preparedness: not having people where the disaster happens.
We need to start controlled abandonment of those areas already many decades early - starting from not investing more into building there.
This is a very cheap way of massive scale disaster preparedness: not having people where the disaster happens.
Do insurance companies not already do this sort of thing?
I don't know if they look so far ahead? Ie if insurance is just for a few years at a time at once?
There's a paper that proposes long term property insurance, which makes it seem the one year contract is the standard? http://opim.wharton.upenn.edu/risk/library/J2010(JIR)_DJ,HK,...
There's a paper that proposes long term property insurance, which makes it seem the one year contract is the standard? http://opim.wharton.upenn.edu/risk/library/J2010(JIR)_DJ,HK,...
Ahh. That makes sense. So insurance is more interested in the potential for a claim within the current policy cycle and not the long term risk.
That, and in some cases highly-correlated risks get dismissed altogether.
If your neighborhood floods, that's a bunch of insurance claims, but if your city floods, that's potentially a bailout, bankruptcy, or contract exemption for the insurer. (In some cases, like sea level rise in Florida, there's already an understanding that the state is subsidizing insurance that wouldn't be available otherwise.)
So I could definitely imagine some value for a buyer-focused service that carries information about all known risk, not just covered/unsubsidized risk.
If your neighborhood floods, that's a bunch of insurance claims, but if your city floods, that's potentially a bailout, bankruptcy, or contract exemption for the insurer. (In some cases, like sea level rise in Florida, there's already an understanding that the state is subsidizing insurance that wouldn't be available otherwise.)
So I could definitely imagine some value for a buyer-focused service that carries information about all known risk, not just covered/unsubsidized risk.
Kinda. It is why the state of Florida subsidizes homeowner’s insurnace policies.
Otherwise, because of future known risks, it would be untenable.
Also, many formerly vacant parcels of land known to be in the likely paths of hurricanes, have become subdivisions.
I guess that is why flood insurance is a separate and optional policy?
Otherwise, because of future known risks, it would be untenable.
Also, many formerly vacant parcels of land known to be in the likely paths of hurricanes, have become subdivisions.
I guess that is why flood insurance is a separate and optional policy?
yeah but it would never happen to me
I could build a disaster-response version of my wish page https://wishpage.tv/places
People could place a request (or a wish) on the map, that request is public and visible. People at the location can pick up a request (e.g. to make a video or to fly a drone over a volcano). Other people can up-vote requests and even attach money to them (rewards for fulfillment).
Do people really think software is the element that's missing from current disaster prep & recovery efforts? I would've picked money or maybe leadership. Maybe I'm unimaginative.
I certainly don't think missing software is the problem for disaster recovery, but there's something to be said for the idea that disaster recovery is missing from software instead.
Two examples that come to mind: Facebook developing their "check in as safe" feature for disasters, and Uber adding one-sided surge pricing so that they can respond to post-disaster demand without raising prices. Uber's move was mostly about fixing a prior oversight, but Facebook's has provided some fairly novel benefit. Basic mobile internet is both more widely available and more disaster-proof than other communications, so it's a welcome improvement on "people flood the phone system trying to call loved ones".
That said, the biggest opportunities here seem to be in disaster-awareness from developers of existing software. IBM's pitch of "come create novel software for disaster response" looks rather less convincing.
Two examples that come to mind: Facebook developing their "check in as safe" feature for disasters, and Uber adding one-sided surge pricing so that they can respond to post-disaster demand without raising prices. Uber's move was mostly about fixing a prior oversight, but Facebook's has provided some fairly novel benefit. Basic mobile internet is both more widely available and more disaster-proof than other communications, so it's a welcome improvement on "people flood the phone system trying to call loved ones".
That said, the biggest opportunities here seem to be in disaster-awareness from developers of existing software. IBM's pitch of "come create novel software for disaster response" looks rather less convincing.
> I would've picked money or maybe leadership.
I think autonomous systems and AI can greatly reduce the cost of disaster recovery. Search and rescue using drones for example, the NASA Autonomy Incubator was working on a system like that with MIT while I was there [1].
[1]: https://youtu.be/2hRNx_0SWGw
I think autonomous systems and AI can greatly reduce the cost of disaster recovery. Search and rescue using drones for example, the NASA Autonomy Incubator was working on a system like that with MIT while I was there [1].
[1]: https://youtu.be/2hRNx_0SWGw
Exactly. Natural disasters aren't even real, so to speak. They are just weather events that have large scale economic and social impact, i.e. the problem isn't really the storm, but how humans are prepared or not to handle it. If a hurricane hits an island with no human influence or concern, is it still a natural disaster?
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.
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.
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.
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.
> ...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/, 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.
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/, 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.
+1
Thank you for such a detailed, informed and relevant comment. Merits tons of upvotes.
Thank you for such a detailed, informed and relevant comment. Merits tons of upvotes.
I accept PayPal.