Several live mapping technologies like Ushahidi already have a very basic geo-fenced alerts feature. Lets say I am interested in the town of Dhuusamareeb in Somalia. I can point my cursor to that location, specify the radius of interest around this point and then subscribe to receive email and/or SMS updates for any new reports that get mapped within this area. If I’m particularly interested in food security, then I can instead subscribe to receive alerts only when reports tagged with the category “food security” is mapped within this area. This allows end users to define for themselves the type of granular information they need—a demand-based solution as opposed to a supply-side (spam-side?) solution.
But this feature is old news. There’s only so much use one can get from a simple subscribe-to-alerts feature. We need to bring more spatial and temporal geo-fencing solutions to crisis mapping. For example, I should be able to geo-fence different parts of a refugee camp and customize the automated alerts feature such that a 10% increase over a 24-hour period in the number of reports tagged with certain categories and geo-located within specified geo-fences sends an email and/or SMS to the appropriate teams in charge.
The variables that ought to be customizable by the user include the individual geo-fences, the time period over which a percentage change threshold is specified (eg., 1 hour, 4 hours, 24 hours, 2 days, 1 week etc.), the actual percentage change (eg., 5%, 20%, 80% etc) and the type of categories (eg., food security, health access, etc). In addition to percentages, users should be able to specify basic report counts, e.g., notify me when at least 20 reports have been mapped within this section of the refugee camp.
This kind of automated, customized geo-fencing threshold alerts feature has many, many applications, from public health, to conflict early warning, to disaster response, etc. Combining this type of geo-fenced alerts feature with check-in’s will make crisis mapping a lot more compelling for decision support. One could customize specific actions depending on where/when check-in’s take place and any additional content (eg., status update) included in the check-in. See my previous blog post on “Check-In’s with a Purpose: Applications for Disaster Response.”
These actions could include emails, SMS, twitter alerts, etc., to specific individuals with pre-determined content based on the parameters of a check-in. Actions could also be “physical” actions, not just information communication. For example, a certain type of customized geo-fenced alert, depending on where/when it happens, could execute a program that turns on a water pump, changes the temperature of a fridge storing vaccines, etc.
We need to make live mapping technologies more relevant for real-time decision support and I believe that geo-fencing is an important step to that affect.
p.s. Naturally, GIGO (garbage-in, garbage-out) still applies. That is, if the data is of poor quality or not existant, adding automated geo-fencing alerts is not going to improve decision-making. But that’s the case for any data processing feature. So my colleague Brian Herbert and I are in the process of adding geo-fenced alerts features to the Ushahidi platform.
iRevolutions 