Location, Location, Location: A miniTAG on how project location data should be published and visualized through 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 organizations to maximize impact by finding gaps in funding, identifying partners and avoiding duplicative efforts.”

However, confusion around how location data should be published remains, and many are interested in best practices for producing and visualizing 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 on publishing location data set by the International Aid Transparency Initiative (IATI) and to share lessons on how to create, share, and use GIS data.

Our conversations covered a range of topics, but here are some of the thornier ones we discussed:

How should National Projects be accounted for?

Some projects benefit a whole country and cannot be pinned to one meaningful location; for instance, think of all the capacity development projects within national institutions that work to deliver health services or compile better statistical data. When searching a map for, “all projects in country A,” a user would expect these projects to be included. However, visualizing decentralized projects on a map — and doing so intuitively — can be challenging.

There are some basic dos and don’ts for designating national-level projects in the IATI Standard — spelled out by IATI — that most parties agree on. The country where development projects (referred to as “activities” in the 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, a question remained on whether publishers should also list the project country and its coordinates in the “Location” field.

IATI guidance clearly states that the “Location” field is intended for “the sub-national geographical identification of the target locations of an activity,” which suggests that national level information should not be added here. However, some organizations 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 national level centroid coordinates in the “Location” field.

Why does all this matter? If these complexities are not considered when tools are created to visualize IATI location data, 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 at the country’s centroid — which is inaccurate and misleading. Many suggested that when representing data on maps, national activities (whether general budget support, policy interventions, etc.), should be considered wholly separate from activities that happen in, or benefit, specific areas “on the ground.” However, this brings us back to an original concern — failing to visualize national level activities tells a story that drastically understates aid in that country.

Perhaps this challenge is best be represented by a simple 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 a 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?

1. 1

2. 2

3. 3

4. 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, and how do we mitigate all of this gray area?

1. When building a mapping tool, it is critical to take into consideration the “Activity Scope” and handle national level projects appropriately — either by not including them altogether, layering and labeling them separately on the map, or by listing each one separately.

2. Transparency indices should also take “Activity Scope” into account, ensuring that organizations with national level projects don’t lose points on their scores.

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 project latitude and longitude, along with additional information such as Geographic Class — which tells the user if the  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 refers to the activities or the beneficiaries of the project. With the addition of the GeoID, locations classified as administrative divisions, and would be 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 developers of the visualization platform must  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. Our discussion concluded that it depends on the tool’s purpose — but that no matter what, locations should be clearly labeled with the Geographic Class to which they are coded. For example, users should be able to either select between geographic classes, 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 allow results to be linked to locations, so we currently cannot disaggregate indicators geographically. This may be forgivable, or even unnecessary, for programs implemented more or less uniformly across different areas (i.e. teachers trained in every district within the project area), but becomes tricky when interventions differ by location (i.e. teachers are trained in some districts, but other districts focus on aspects like in-class technology). These distinctions are critical for those trying to identify what has taken place at each location and what the results were, and can prevent inaccurate inferences being made. However, this also may very well be an edge case, and accommodating it could just be adding further complexity IATI standard.

Is it safe to publish locations?

Security concerns were shared questioning if location data could be connected to results or other data that might be of private or sensitive nature. These concerns are valid — but  by geocoding activities at a slightly higher level, we can mitigate and avoid this.. 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 respondent locations while continuing to maintain detailed, granular geographic information.

What tools for producing and publishing location data exist?

Some organizations, such as the World Bank and UNDP, shared how their internal project management systems allow project managers to enter location information, and are typically linked to Geonames (a 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 the user to upload documents that contain location information. The tool reads the documents, suggesting 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 a standalone geocoding tool will soon be launched — which integrates autogeocoding with an existing manual geocoding platform. The tool is open source and will be available for organizations to plug into their own systems or use the standalone system within their own processes. As soon as it is live, we are eager to share this tool with you! Stay tuned for updates in the coming weeks.

This is a modified cross-post from IATI‘s original post, “Mapping Aid.” It is written by Reid Porter of InterAction on last month’s miniTAG meeting on publishing and visualizing project location data using IATI. 

Image credit: Andrea Moroni (CC BY-NC-ND 2.0)