A key part of good coordination is good data and information management. If this is done well, a clear picture of what can often be a confusing situation can be given to responders and decision-makers, who in turn can make the appropriate response in a quick and timely fashion for those who need it most. Done badly, it can lead to the wrong decisions being made, or add to the confusion by duplicating data or misinformation.

Having organised and well structured data can help in good coordination. Many organisations have their own processes and workflows, which are important for them to work efficiently. They are also important any time there is a handover or rotation of personnel. A verbal handover may not always be possible, but if those involved are familiar with data naming conventions and folder structures then the handover process is far easier. Having a well-organised system also allows teams to work at a quick pace, as it should be easier to find data or identify any gaps

The data cycle describes the various stages that data is created, used, updated and stored. This data cycle can be divided into five sections, which occur before, during and after the trigger event. Each individual part of the cycle may include its own internal processes, and these are highlighted in the following page.

Data preparedness

This is done prior to any response. Preparedness activities may include looking for data (spatial or non-spatial), contacts (organisations and individuals), or country or organisational workflows about the area of interest. Data should be processed so that it is clean and complies with data naming conventions, and stored in a structured way based on organisational processes.

Data scramble

This is the process by which data and information is gathered whilst an individual or organisation is mobilising after the trigger event – sometimes called the crash move phase. The purpose of the scramble is to obtain data and information that may be needed during the initial phase of a response. As internet connections can often be poor or non-existent early on, deploying with some data to begin with is vital. Data scrambles should be intelligence led; aiming to anticipate what might be needed in the future and not just for the initial mapping.

Mission

The mission cycle is similar to that of the data scramble, but occurs once situational data becomes more readily available. As new data is created or discovered, it may be important to share it on relevant platforms, including the Humanitarian Data Exchange, in-country GIS and information management working groups. Throughout the duration of a response, efforts should be made to work with partners that data and products can be handed over to, in order to establish long-term continuity. Training of partner organisations may be required.

Archive

At the end of a response all data should be archived so that if there is another response or follow-up work, the data is readily available. It is important to try and clean and document the data as much as possible.

Start your journey into GIS and Information Management with a few quick tips.

When you receive data either as part of a data scramble or in the field, all aspects of the acronym CUSTARD should be questioned and recorded as some form of metadata, so that it can be referred to later on. CUSTARD stands for:

• Coordinate system

• Units

• Source

• Triangulate

• Absent values

• Restrictions

• Date

Coordinates

If coordinates are provided, find out what form they take. Are they decimal degrees (DD, e.g. -1.283333, 36.816667, degrees minutes seconds (DMS, e.g. 1° 17′ 0″ S, 36° 49′ 0″ E), or something else?

Units

What is the unit of measurement? For example, is it individuals, families, buckets, tonnes? It is also important to find out how big the unit is. In the case of families – what is the average size of a local family, for buckets – how big is the bucket, e.g. 2 litres, 5 litres, 10 litres etc?

Source

Where has the data come from, who collected the data and how was it collected, e.g. a census or assessment? These questions are important to ask as they may give an indication of the quality and validity of the data. You may also wish to get more data or ask further questions from the source at a later date. It is important to record the contact details of the source so that you can get back to them if necessary.

Triangulate

Look at the data and ask ‘does it look right?’. Compare it with other data you may have and see if it makes sense. If it doesn’t, then ask the source questions about it.

Absent values

Look for any absent values and check what an ‘empty cell’ means. Is it meant to be empty, or is the data missing?

Restrictions

This information will primarily come from the source, but it is important to understand the restrictions of the data. There may be licensing issues that need to be resolved or limitations based on a specific licence. It could be that the user has permission to use and create products from the data, but they can’t share it with other organisations. Commercial or protection issues may restrict the use and sharing of data.

Date

Find out when the data was collected or created. This will give an indication of how old it is and its currency. Population data, for example, is often based on a census that may happen every 10 years, so if you receive census data that is eight years old it’s likely the population has changed significantly in that time. At any acute phase of an emergency response situational data, such as the affected population, could be changing many times a day, and having a date and time stamp is important to report.

Although many of the examples in this guide are static jpg maps there are many different types of visuals that you could use to show the information you are given. It is important to chose the most appropriate format to answer the question(s) and the one that will make it easiest for them to make their decisions. Here is a quick guide to the different formats using the same data to start with.

Maps

Great for understanding spatial data - where was the earthquake, where are the affected people, where are nearest water points to the camp? The map will show you the geographic scope and scale of a disaster and of the response. It will help users understand if the response is focused on one area when there might be other locations and people affected to. So any time the question has where in it start to think about a map.

There are two basic formats of maps - static and web maps.

Static maps

These are the traditional paper based maps where the information shown is reasonably limited. Field workers like them because they can be printed out, written and drawn on and kept in your pocket. Headquarters like them because they can be added to reports and presentations. They do however lack the ability for a lot of interaction, able to add additional data or do detailed and complex analysis. They are normally produced using GIS desktop tools such as ArcGIS or QGIS and require a certain amount of technical skill and knowledge.

Web maps

These are online maps and much more common these days and we have been using them more in our everyday lives as the internet and mobile phones have developed. They allow for more complex interaction from zooming and panning around at different scales, to route finding and searching, to switch layers of data on or off, adding additional layers of data and performing complex analysis.

They are more complex in nature to setup and require a greater level of support including web hosting, data management and more often than not the internet. There is the ability to for web maps to have close-to- or near-realtime data fed to them. There are numerous online tools that you may have used day to day such as Google Maps and Google Earth to more complex web tools such as Mapbox, Leaflet and ArcGIS Online. They require technical skill and knowledge, a way of hosting and publishing them.

Other visuals

There are other formats beyond a map and can be equally valid formats to use.

Tables

Tables allow for reporting of text and numbers where precision is needed. Think about the layout of the table and consider sorting the data rows into something meaningful. i.e. if the table is to show the top five priorities of the affected population, sort the table so that the highest priority is shown first. You can use a spreadsheet or word document to produce a table.

Charts and graphs

There are many types of charts and graphs and most of us will be familiar with bar and pie charts. They are good at showing the relationships and trends of data. They are an easy way to convey data in visual way if done well. Aim to keep them as simple as possible with minimal categorisation. Look to highlight the trends and relationships. Spreadsheet tools such as Excel and Google Sheets allow for graphs and charts to produced, or you can use more complex coding tools such as D3.js and Chart.js for more complex, data driven, interactive versions.

Infographics

A combination of words, graphs, maps and other graphics, infographics aim to provide the user with information quickly and easily. They take time to design and create and most likely be done away from the hustle and bustle of a busy coordination centre. You can generate these using a variety of tools (excel, word, powerpoint) to produce the individual elements before adding the all into a single graphic or use tools like Adobe Illustrator to generate it all in one place.

Dashboards

More often than not these are online and provides an up to date summary of indicators and act as a progress report of what is going on in a response. They may contain tables, charts and graphs and maps. They can be fed information close-to- or near realtime so that they are always current. There are a variety of dashboard tools such as Tableau, PowerBi and Google Data Studio.

The map and information management wall is a way of displaying maps and products in a structured way. Each operations room should have one, but it may be necessary to have two: a public one outside the operations room, and an internal one for office and operations staff use. The information may be subtly different.

There are many ways to organise the wall – depending on the type of deployment – but the following should be considered:

• headings could be part of the product planning cycle

• columns should be thematic

• rows could be

  • regions

  • sub themes

  • temporal

This is the process by which data and information is gathered whilst an individual or organisation is mobilising after the trigger event – sometimes called the crash move phase. The purpose of the scramble is to obtain data and information that may be needed during the initial phase of a response. As internet connections can often be poor or non-existent early on, deploying with some data to begin with is vital. Data scrambles should be intelligence led; aiming to anticipate what might be needed in the future and not just for the initial mapping.

This is typically, but not exclusively, basemap and baseline data. Some early situational data may be acquired. It should include the following steps.

Requirements definition

Based on what is known in the early stages, the aim is to established the data necessary to mount an effective humanitarian response and should include:

• Disaster overview - establish the facts of the disaster from Office for the Coordination of Humanitarian Affairs (OCHA) reports, ACAPS and other publishing services, including media outlets.

• Area of interest - where is the disaster and what is its geographical reach? Which part of the country is in, or is it over single or multiple countries? What additional data is required to put the affected country in context when mapping – this might mean that some data (primarily basemap data) from neighbouring countries may be required.

Dataset discovery

Establishing what data is available. Using any preparedness work, make contact with people and organisations, check your post-mission archives.

• Data preparedness - check your data preparedness activities and see if there are data and contacts available.

• Post mission archives - check for data from previous responses. There may be good datasets, particularly basemap and baseline, available.

• Humanitarian Data Exchange - this may have Common Operational Datasets (CODs), data that all responders should try and use, for the area of interest.

• Organisational and individual contacts - these may be primarily based on contacts established during any preparedness work or a simple internet search.

• Situational data - can be gained from situational reports from lead organisations such as OCHA, GDACS, IFRC or ReliefWeb, as well as both national and international news reports.

Data acquisition

The actual process of downloading or obtaining the data. Beyond saving it to an appropriate location, it is useful to keep an original copy of the files. See Preparation for further details.

Check all aspects of the acronym CUSTARD, which stands for: coordinate system; units; source; triangulate; absent values; restrictions; date. See receiving data in the field for more details.

Resolve usage issues - understanding what, if any, limitations of using the data might be. There might be license agreements with providers that need to be signed or agreed. Data may be limited to particular uses, and this should be recorded.

Data preparation

The process for making the data ready for use. See the sections on Data naming conventions and Folder structures, which describe the reasons and process of data management.

• If you haven’t done so, save a copy of the data in its original format. This means that if you later have an issue or make a mistake, you can roll back to an original version.

• Make sure the data opens in the correct software.

  • For GIS data.

    • Make sure it opens in ArcGIS or QGIS.

    • Check the projection and coordinate system. If required re-project. Record the projection and coordinate system in a metadata file and your data scramble spreadsheet.

    • Clip to the area of interest.

  • For spreadsheet data.

    • Make sure it opens in Excel.

    • Look at cleaning the data so it can be used in joins (look at column headers, remove merged cells, etc) for use in GIS. A clean spreadsheet also allows for created manipulation and analysis of the data through pivot tables and filters.

    • If there are coordinates in the data, create a shapefile from it for use in a GIS platform.

• Save a copy of the processed data to a working folder using the appropriate data naming convention.

• Fill out any additional notes and metadata in your data scramble spreadsheet.

Review

The data should be periodically reviewed to establish any gaps, and to adjust the requirements definition as needed, for example if the area of interest becomes bigger, or there is a significant aftershock. This could be every few hours or every couple of days depending on the speed of the scramble and response.

Final cutoff

This may happen if you are moving in to the affected area and need to make sure you or your organisation have all the data stored locally. It may be that the scramble continues after the final cutoff, but at this stage it should be looking for a few very specific datasets rather than lots of data that may be hard to locate in the field. It is useful to include a summary of the scramble including:

• what data has been acquired – include what information was found, but also summarise the gaps

• recommendations – is there one preferred dataset over another?

• license information - what is the license terms for the data.

• known issues – e.g. some data isn’t as accurate as others; geographical administration boundaries don’t all align to each other.

It is import to have some sort of naming convention so that data can be easily managed and understood by the user. MapAction has developed a data naming convention that is split into a number of clauses. These clauses capture a large number of important metadata details without the need for a full metadata file. The MapAction data naming convention looks like this:

• geoextent_datacategory_datatheme_datatype_scale_source_permission_freetext

  • e.g.

    • lbr_admn_ad1_py_s0_gaul_pp_counties

    • phl_tran_rds_ln_s0_openstreetmap_pp_roads

    • hti_evt_epi_pt_s0_usgs_pp_epicentre

The purpose of each clause is as follows:

• geoextent - this describes the area that the data covers. Typically this is at country level and the ISO3 country codes are used in the clause.

• datacategory - this provides a broad description of the content, e.g. health data, population data, transport data. It uses a four letter description.

• datatheme - this a more detailed description of the content based on datacategory, e.g. hospitals, number of IDPs, road type data. It uses a three letter description in the clause.

• datatype - this is the geometric type of the spatial component of the layer, e.g a point, line, polygon, table, etc. It uses a two/three letter description in the clause.

• scale - this represents the order of magnitude of the scale at which it is appropriate to display the dataset. It does not represent the survey scale, resolution or other concepts of scale. This is intended to distinguish multiple datasets that are useful at different scales. It uses a two letter description in the clause.

• source - describes the original source of the dataset. It can use as many letters as necessary in the clause.

• permission - this describes both the permissions for redistributing data, and for distributing maps derived from the data. It can help with assigning a licence. It uses a two letter description in the clause.

• freetext - this provides free text to describe in greater detail, if needed, what the data is, e.g. the administration level name (states, counties, districts, etc). It can use as many letters as necessary in the clause.

This is just one method of naming data and can use this or create one that suits the needs of your project or organisation.

There are an increasing number of individuals, groups or agencies that have the capacity to manage information in disaster and emergency relief efforts. This can lead to challenges in the overall awareness and coordination of different information at either an individual or an organisational level.

A matrix can consolidate knowledge of what is happening in terms of information management for each type of end use, from data provision through to situation awareness and overall humanitarian footprint information, to more specific cluster and specialist needs.

A well-organised folder or set of folders allows people to find information quickly and efficiently. This should be done from the start of a response and maintained throughout. The following the describes the MapAction folder structure:

• YYYY-MM-DD Country

• GIS

  • GIS Tasking

  • Original data

  • Active data

  • Mapping

  • Field Transfer

• Operations

GIS

This folder contains all the data, templates and outputs used in the GIS workflows. Within this folder there are the following subfolders:

• GIS tasking - this folder contains the map request sheet, data naming convention details, and a quick metadata template.

• Original data - this folder contains data found before the deployment begins/began. A folder is created for each new data source found, e.g. 101_Bartholemews.

• Active data - this folder contains the operational datasets. This data has been assessed and thought fit for purpose. The data has been processed and renamed according to the data naming convention. It is sorted by datacategory. For example, a transport dataset may have been split into roads, railways and airports. These would sit as separate shapefiles under the 223_tran folder. All maps will source this folder first for data to be included on the map or other product. The folders have a three digit prefix and then a four character type descriptor. The data is named according to the MapAction data naming convention.

• Mapping - this folder contains all maps, whether received from third party resources or created by MapAction. Project files are also stored here. ArcMap MXDs are stored in the 33_MXD_Maps folder, whilst any Google Earth KML created is stored in the 36_KML_Products folder. This folder also stores mapping products (.pdf, .jpg) and templates (.ppt, .mxd).

• Field transfer - contains data transferred between the different locations once a deployment has begun. It allows segregation of original data and data which has been subsequently updated and pushed to the field location.

Operations

This administration folder contains all documents and information required to support a response, including contact details, meeting schedules, photographs and reports.

When producing maps it is important for the data to be represented in a clear way that the user can understand. The symbols or icons should be representative of the data being shown. A map should not show too much information and only used the data that is going to support the overall theme of the map. Too much information may make the map confusing to the user.

Colour considerations and cautions

Colour blindness – this is quite a common problem. Most people with colour-vision deficiency have difficulty distinguishing between red and green. ‘Red-green’ deficiency affects one in 12 men and one in 200 women globally and can make it hard for them to tell the difference between reds, oranges, yellows, browns and greens. They may also have difficulty distinguishing between shades of purple and may not be able to tell red from black. ‘Blue-yellow’ deficiency – affecting vision of blues, greens and yellows – is another form of colour blindness that is much rarer. This Brilliant Maps blog explores what maps look like to people with colour-vision deficiency.

Format, use and context – colours look different on screen compared to paper, so the ways in which a map is distributed and used should affect colour choice. If a map is intended to be desktop printed, questions around the quality and availability of printers and inks arise. If a colour map is printed in black and white, will it still be fit for purpose? If a map is shown via a projector, will details be visible?

Cultural significances – colours have different meanings and associations in different parts of the world. For example, in some cultures, death is associated with black; in others, with white. Red can be associated with danger, good fortune or grief and death, among other things, depending on where you are. This is one good reason why team diversity, as well as awareness of and consideration for different cultures, is important in mapping – as elsewhere in life.

Resources

The following two examples are tools that can help in representing data in a clear way.

Humanitarian icons

OCHA Humanitarian Icons

The United Nations Office for the Coordination of Humanitarian affairs (OCHA). MapAction has supported in the creation of the various GIS ready formats for ESRI (ArcMap and ArcGIS Pro) and QGIS.

ColorBrewer

ColorBrewer 2.0

This is a tool that can help in the use of colour in a map particularly in choropleth maps where colours are used to represent a classified data. In these maps it is recommended not to use more that six classifications as if it is more than that then it is harder to distinguish by the human eye. The ColorBrewer tools allows the map creator to test different colour palettes for different classifications but also making sure that they are colour blind and photocopy friendly.

A response is not a static thing and there are constant changes in the information being received. Maps show the spatial dimension (the where) of a response but they, as well as other visuals, can also be used to show change over time or the temporal dimension. Potentially any data that has a date or timestamp can be used.

Below is are some approaches on how to use and visualise temporal data.

Examples of temporal data

• Cyclones and storms - a cyclone will move along a particular path (track) and forecasters will report on it's location. In their reports it might show it's location and known wind speed at a particular time. This is a fairly straightforward example of using temporal data to show where the cyclone has been and where and when it is forecasted to go.

• Affected population - over the initial days of a disaster as responders seek to understand the situation there will be reports of numbers of affected people for different locations. These are like to go up and down over time as the information becomes clearer.

• Health caseloads - in a epidemic or pandemic the number of people who have been recorded as to having the thing that has caused the epidemic will change.

• Market prices - the price of a commodity at a market will go up and down over time depending on the demand for it.

Receiving temporal data

There are a number of things you should do with temporal data in addition to the recommendations in the receiving data section:

• When did you receive it - record when you received the data.

• Check to see when it was collated and for how long is it valid for - this will give the data some currency.

• Check the frequency of the data collected - is it in hours, days, weeks, months, years, etc. In some cases, this could be recorded as day 1, day 2, day 3, etc or in some health emergency epiweek 1, epiweek 2, etc - check when this period start.

Understanding temporal data

The key thing with temporal data is that you should be looking for changes, patterns and trends to the data over time. Things to understand are:

• Changes - this is a comparison between two datasets. Calculate what the change is in the number. You may wish to use absolute numbers and/ or as a percentage. What you are trying to identify is if there an increase, decrease or no change at all.

• Patterns and cycles - look for patterns in the data and see if you can attribute reasons as to why there is a recurring pattern. For example in a epidemic, it might be observed over time that the daily number of cases might be lower on Monday. This might be attributed to the lower number of testing that occurs over a weekend. In agriculture, crops grow in different seasons and so it can be expected to only see certain foods in the market around the harvest time for that crop.

• Trends - this is a longer term view of the data and requires a number of datasets over time to begin to understand what might be happening over time. For example, an area might find that the traditional seasonal rains have started to arrive earlier or later, with more or less intensity. You might consider various statistical methods such as using a moving average to smooth out short term fluctuations.

How to visualise temporal data

There are a number of types of visualisation tools and techniques that you can consider using to represent your temporal data.

Graphs

These are a very useful method of visualising data over time and can help the user see patterns and trends. The temporal element should be used on one of the axis. Traditional examples include histograms, line and gantt charts but there are other examples such as sparklines, rose charts or a heat map that you may wish to consider when looking at changes, patterns or trends. Calendars, timelines and timetables are good ways to show a sequence over a period of time. Further examples can be found here - the data visualisation catalogue.

Maps

Maps or likely a series of maps can be used to represent temporal data along side the spatial element. Consider using symbols like up and down arrows to show the change. You may wish to include a series of maps in the same page layout. For example, if you wanted to show monthly rainfall, you may include a map frame for each month in the same page layout.

For maps that include forecasted data it is recommended to differentiate between forecasted and actual measurements. In the example below you will see this is done using solid (actual) and dashed (forecasted) lines. Likewise, it is good practice to label point data with a time or date stamp.

Animations and interactive visuals

Short animations can be a useful and more appealing way of showing changes over time. Examples of this might be showing the movement of a cyclone along it's track and see when the most intense parts occurred. An animation might require more time to prepare depending on the software and technical skills available.

Any visual tool that allows the user to interact with the data can be beneficial and where temporal data is available a slider should be included. A swipe map, whereby the user can swipe between two images can be an effective way of comparing before and after the event.

Other recommendations

A really simple way of showing time is to time or datestamp your products to show when it was produced or when the data is from. You can achieve this by including a time or date in the title, or in the metadata fields of the map or data. This is particularly the case when generating new versions of the product. It is even more important if there is a rapid turnover and frequency of updates such as in a search and rescue response.

A map is made up of different layers data, each showing new information that gives additional context to the layer above. In a humanitarian context these layers can be grouped into three data categories.

Basemap

This is geographic data that is used as background mapping. Some form of basemap data is needed for every map. Examples of basemap data include:

• administrative boundaries

• settlements

• transport

• physical

• elevation

Baseline

This is typically demographic data about the country or area of interest (AOI) before an emergency. This data allows you to compare situational data against ‘normal’ conditions. Examples of baseline data include:

• number of schools

• health facilities

• election results

• population

Situational

This is data for the country or area of interest (AOI) produced after the emergency. It is the most important data that you are trying to show on the map. Situational data has some currency to it and some of it may become baseline data over time. Examples of situational data include:

• number of internally displaced people (IDPs)

• infrastructure damage

• earthquake epicentre

• flood extents

• road status