Mapping Aid

This post is written by Reid Porter at Interaction on last month’s miniTAG meeting on publishing and visualising project location data using IATI. 

Subnational location information is repeatedly identified as critical for both donors and implementers to understand and learn from development activities around the world. Information on who is doing what and where allows development organisations to maximise impact by finding gaps in funding, identifying partners and avoiding duplicative efforts.

However, there continues to be confusion around how location data should be published, and many are interested in best practices for producing and visualising this data. To address this, the Initiative for Open Ag Funding brought together data publishers, GIS (Geographic Information Systems) specialists, and other interested parties in December 2017 to review the standard set by the International Aid Transparency Initiative (IATI) on publishing location data and share lessons on how to create, share, and use GIS data.

Here are some of the thornier topics we discussed:

How should National Projects be accounted for?

Some projects benefit a whole country and don’t have meaningful locations; think of all the projects that develop the capacity of national institutions to deliver health services or compile better statistical data, for instance. A user would expect these projects to be included when searching “all projects in country A” through a map. However, visualising such projects on a map in an intuitive manner can be a challenge.

There are some basic dos and don’ts for designating national-level projects in the IATI standard – spelled out in IATI’s guidance – that most parties more or less agree on. The country where development projects (referred to as “activities” in the IATI Standard) take place should always be input in IATI’s “Recipient Country” field. The “Activity Scope” field should be used to denote that a project is being implemented at the “National level.” However, there was a question on whether publishers should also list the country and its coordinates in the Location section of the standard.

IATI guidance clearly states that the “Location” field is for “the sub-national geographical identification of the target locations of an activity…” This suggests that national level information should not be added here. However, some organisations expressed concern that their scores on indices such as the Aid Transparency Index would be dinged for leaving this information out, and thus decided to enter centroid coordinates for the entire country in the “Location” field.

Why does all this matter? When tools are created to visualise IATI location data, if these complexities are not considered, data can be misrepresented. For example, if centroid points for national level projects are entered without clearly indicating that they represent a national level project, it can seem like there are a large number of projects taking place in the middle of the country when that isn’t really the case. Many suggested that when representing data on maps, national activities (be they general budget support, policy interventions, etc.), should be considered wholly separate from activities that happen in or benefit specific areas “on the ground,” but again, the risk is that not visualising national level activities drastically understates the story of aid in that country.

Perhaps the challenge can best be represented by a simplistic thought exercise:

Pretend you’re working in country X, region Y, district Z (in other words, X contains Y, and Y contains Z).

There is one national-level policy-based initiative being implemented in country X, a health program occurring throughout region Y, and a small capacity-building project happening in district Z.

How many projects are being implemented in district Z?

A) 1
B) 2
C) 3
D) It depends…

In addition, a fourth project is training teachers from region Y in the main city of a neighboring region, call it region W. Now, how many projects would you say benefit people in district Z?

So what’s the solution?

1. When building a mapping tool, it is critical to take into consideration the “Activity Scope” and appropriately handle national level projects, either by not including them, layering and labeling them separately on the map, or by listing them separately.
2. In addition, transparency indices should take into account the activity scope to make sure that national level projects don’t lose points on their score.
3. Publishers should then confidently follow the IATI definition to only use the location section for sub-national locations, and use the recipient country and activity scope to denote national level projects.

Points vs. Polygons

Currently the IATI standard allows publishers to enter latitude and longitude, along with additional information such as the Geographic Class, which allows users to understand if the listed location is an Administrative Region, a Populated Place (eg. city or village), a structure, or another type of location; and the Geographic Location Reach, which indicates whether the location relates to the activities or the beneficiaries of the project. With the addition of the GeoID, locations that are administrative divisions, and perhaps better represented by the shape/polygon of the admin location, can be linked back to the polygon rather than entering latitude and longitude. However, IATI does not itself store the polygons. This means that the developers of the visualisation platform have to not only perform this linking on their end, but also find an appropriate source to use for importing shapefiles (for instance, GADM).

However, for projects coded at an Admin level, there still remains the question of whether admin levels should be displayed as points or as polygons when developing GIS tools. The discussion resulted in agreement that it depends on the purpose of the tool, but no matter what, locations should be clearly labeled with the level (Geographic Class) to which they are coded. For example, users should be able to either select between geographic class, or classes should be differentiated by different shapes, colors, or other visual clues. Highlighting polygons makes it clear that project activities benefit or take place throughout the admin level, however, this can limit the ability to layer it with other types of contextual data, such as fertility, malnutrition, or poverty rates, all of which are frequently represented as shades of color within a polygon.

Matching Results to Locations

It was noted that the standard does not currently allow results to be linked to locations, so we’re unable to disaggregate indicators geographically. That may be forgivable/unnecessary for programs that are implemented more or less uniformly across different areas (i.e. teachers trained in every district within the project area), but it becomes trickier when specific interventions are differentiated by locations (i.e. teachers are trained in some districts, but in others the focus is on other aspects like in-class technology). This is important information for those trying to identify what has taken place at each location and what the results where, instead of inferences being made that might not be correct. On the other hand, this may very well be an edge case that would add further complexity to the IATI standard in order to accomodate.

Is it safe to publish locations?

Concerns over security were shared if location data could possibly connect to results or other data shared that could have private, sensitive data. It was noted that geocoding activities at a slightly higher level can help avoid these issues. Slightly more technical publishers may wish to consider other methodologies, such as the random geographic displacement algorithm that Demographic Health Surveys (DHS) use to obscure the locations of respondents while maintaining a high level of geographic detail.

What tools are there for producing/publishing location data?

Some organisations, such as World Bank and UNDP, shared how their internal project management systems allow for project managers to enter location information, and are typically linked to Geonames (an geographic database and gazetteer) to produce the rest of the information needed to publish to IATI.

Development Gateway has also created an Autogeocoder tool that allows for uploading documents that contain location information. The tool reads through the documents and suggests locations for the user to validate or supplement with additional information. The tool has been implemented in the Initiative for Open Ag’s Publisher’s Toolchain, and soon a standalone geocoding tool will be launched which integrates autogeocoding with an existing manual geocoding platform. The tool is open source and will be available for organisations to plug into their own systems or to use the standalone system within their own processes. We are eager to share this tool as soon as it is live!