I’ve run head first into the internet connectivity divide; my parents, located north of Williams Lake near Soda Creek have been put under Evacuation Order - they do not have internet. I, surrounded by connectivity, have discovered an evacuation order for their area at 8:00PM - it had been posted online at 2:09PM. My parent’s home phone rings, but there’s no answer. I leave a message to let them know about the evacuation, and that I’m assuming they’re on the road. With no way to contact them, I begin wading through crisis information scattered across multiple government websites to find safe route options for my folks for when we connect. Thus begins a crash course in crisis information management and open data, leading to some key lessons, and bc-fires.echosec.net.
While trying to find my parents via relatives on Facebook, I’m swamped within 15 minutes of attempting to create safe route options from the three main resources:
- Road closures due to fires on DriveBC (twitter: @DriveBC)
- Evacuation Alerts and Orders from EmergencyInfoBC (twitter: @EmergencyInfoBC)
- Fire locations (especially the one threatening my parents home) via the BC Wildfire Service Active Wildfires map (which was suffering periodic outages due to load)
There is no single consumable overview of this scatter of information, it’s too much for crisis situation. Luckily, these sources all have equivalent open data endpoints available.
An on-the-nose name, Open Data is created when varying levels of government, organizations and agencies open up their stores of information to developers for use in products or projects. The underlying philosophy is that public data can be used for the common good by the private sector, developers, data journalists, and others.
Using DataBC, DriveBC and the BC Wildfire Services data, I’ve cobbled together the first version of bc-fires.echosec.net in a couple hours. It displays the three key source sources on one map using the Google Maps API, a programing toolkit for creating maps, along with the addition of Google's live traffic layer.
Surveying the map, it's clear given the road closures, traffic, and locations of the wildfires, combined with some light profiling, that my parents would have traveled north, or gone to Williams Lake. Reaching out to relatives who live in, or have checked in to Quesnel via Facebook I’ve found my parents by the time I open the second chat window. They are safe, but I can’t quite let the map go.
Choosing the Open Data Toolkit
Monday morning, I share the map I’ve hacked together with my coworkers at Echosec. The company responds by providing me with an ArcGIS Online login. This online “Geographic Information System” product is a map building toolkit from ESRI, and luckily the best fitting tool for the job.
While the Google Maps API is strong, it has a few blindspots when it comes to consuming traditional GIS formats (like WMS). For these non-google data formats to work, there is a lot of coding overhead to parse the data and map it.
The ESRI’s ArcGIS is an excellent fit as:
- It’s robust enough to provide a basic base feature set
- It consumes GIS, Google’s mapping data (KML), and others formats (like spreadsheets) near omnivorously
- It facilitates rapid implementation, either through ease of coding or customization
- It handles the load of the potential audience
- It consumes as many forms of data possible
- It supports desktop and mobile devices, for the best reach to potential users. Though the support for mobile is “nominal”.
That’s valuable for building something like BC-Fires.Echosec.Net on the fly.
How on the fly you ask?
As I’m building the map’s second iteration, I’m listening to CBC Radio’s call-in wildfire coverage, an idea culled from Daniel Pedraza from UN Global Pulse during his excellent Big Boulder conference presentation. There are repeated calls asking for wind-speed, so those affected can discern the direction and potential speed of the wildfires. I search in an ArcGIS “Living Atlas Layer” containing wind-speed, and add it to the map. It’s not perfect, and the data is thin, but every bit helps.
CBC listeners need to know the extent of the fires, not just their point locations. From the DataBC warehouse I add the current fire perimeters, to give a better idea of the areas affected. Another chief concern was the location of ESS Evacuee Reception Centres. Unable to find an existing map, I create a Google spreadsheet of centres and addresses, combine it with a geocoding script, web-publish it as a CSV, and have the map pull those in. One of the best finds was open data from the Cariboo and Thompson-Nicola Regional Districts, respectively, which maps the Evacuation Alerts, and Evacuation Orders.
The biggest request through social media once the key data was in place? Make the map mobile friendly. So, one more rebuild.
Keys for sourcing data in a crisis: listen and be responsive. Radio and social media calls for information define the user requirements in a situation like the BC Wildfires. With a mobile map offering basic information in place, and with the support of Echosec, I start to look at additional data that would provide a better view of the situation.
Looking Beyond the Obvious Open Data
While regional data, provincial, and municipal information is the obvious choice to map, there was a need for a better sense of what the wildfires were doing. For that I looked further afield; NASA.
From previous work, I had a vague notion of a variety of NASA “open data” satellite imagery. Digging around I found satellite data that showed the leading edges of the fires, that despite being 24 hour delayed, provide information on the fires’ progress during off hours when other OpenData staled. If anyone needs an argument for NASA funding, I’d point to the continued escalation of wildfires and flooding across North America.
Still, the information available doesn’t give the “picture is worth a 1000 words” view on the ground, though. So to augment the addition of DriveBC highway cameras to the map, Echosec, being a social media search and discovery platform provided a stream of located tweets from select social media users, journalists, & emergency response organizations for additional information and images.
Lesson one for any government department or crisis management organization; Social Media may be the communications king, but the emperor periodically has no clothes. Facebook and Twitter are the first places those on the 3G side of the internet connectivity divide look for information, and communication. For those on the landline or 2G “data free”downside of divide they are connected in person, by phone and by SMS to those with internet/data access. The implication is that every social media user has your distribution point for crisis information, much as Open Data distributes the load of crisis information across multiple websites and agencies.
As an organization or government dealing with a crisis you need to be there first with the social media messaging seeding it for sharing, thus creating the source before speculation or misinformation takes hold.
If there are community groups that have sprung up around a crisis, like the BC Wildfire Evacuee Support Group on Facebook or @BCWildfireHelp on Twitter, these are just as valuable for reaching your audience as radio or television. Reach out, inform, answer, and, if needed, correct. Interact on social media, the same way you would manage a hotline. Doing that requires social media search and analysis, which is where tools like Echosec can help.
Beyond that, social media can provide valuable on-the-ground data; much as DriveBC highway cams integrated into the map give a sense of the environment, so did social media. Consider the potential of a crisis-time initiative like encouraging the public and media to geo-locate resources like gas or available groceries, or new fires? Suddenly you’ve a powerful means of collecting information. Likewise, crisis response organizations can monitor social media to identify and address rough spots in their process, or streamline check-in processes.
Conclusion: Addressing the Issues
BC-Fires.echosec.net was built on the fly, so there are issues. In an evacuee situation, mobile usability is foremost. Unfortunately, the map on a smartphone is at best “serviceable”. This usability was a balance between the speed of implementation provided by ESRI’s ArcGIS Online WebAppBuilder, and the time and development of a mobile-first template. A project for the future would be to create a template with proper touch areas, a better layer management drawer, and less steps to get to pop-up content.
In the future too, there are larger scale issues to attack.
The promise of open data is essentially that, “if you provide it, someone will build the needed product”. That may be true, but as a government it wouldn’t hurt to hedge the bets for future crises with official aggregation information. Wildfires in BC and California are now repeated seasonal occurrences as the jetstream continues to slide northward creating tinder-dry summers. This type of emergency information problem is not going away, and BC-Fires.echosec.net proves it doesn’t take a massive team or budget to get the basics in place very quickly.
A tougher technological issue is that in a crisis situation, cellular and broadband connectivity can degrade as infrastructure is destroyed, or if the individuals affected live in an area without internet connectivity. As a bridge between the connected and 2G (or landline) worlds, natural language processing and machine learning are capable of responding to 2G/SMS requests for information. It is not a stretch to envision an automated response to a text of on “On highway 24 near Roe Lake, is the road to 100 Mile House open?”, by an EmergencyInfoBC “bot” given the available APIs. Beyond that, the CBC Radio is still there, it’s not just for requirements after all.
With co-ordination, open data, innovation, and imagination, the systems for crisis communication could be much more robust than the aggregation of data into a map. The key isn’t one solution, but multiple modes of communication driven by open data, that gives evacuees on the ground the information they need, when and where they need it.
Sidebar: With Providing Open Data comes Great Responsibility
Working with the Open Data powering the bc-fires.echosec.net map has resulted in a few recommendations for providers:
- Foremost, a crisis can be a 24 hour, 7 day a week event, Open Data can not afford to be static during this time.
- Current Information is not only key to decision makers, but to those individuals on the ground trying to navigate their way through a crisis
- Endpoints should remain static:
- If these need to change due to load, publicize the change. People are depending on your data source across multiple outlets.
- If possible, keep the format consistent, and forward to the new endpoint
- Endpoints need an architecture that will withstand the load, be that external hosting, or caching. One of the best recent developments is BC Wildfire Service moving it’s active wildfires map to ArcGIS online which is excellent at withstanding high load scenarios.
- Abstract the data from the presentation so that those consuming your data can visualize it in new ways. Again, in its move to ArcGIS Online, BC Wildfire Service is setting a great president by abstracting presentation from the data. The previous KML dictated the icons representing a fire; the new data point, by way of example, allows the Echosec map to show the size of a fire by scaling the icon based on the hectares consumed.
Learn How Echosec Supports Emergency Services and First Responders in Times of Crisis