Location element: which elements are most useful to data users?

(SJohns) #1

Does anyone have information (beyond anecdotal) on which location sub-elements are most useful to data users? I’ve seen different combinations, but most usually just the point (coordinates) and name being given in the data. Here’s a list of the sub-elements.


Look forward to hearing back! Also, has anyone written or seen user-friendly guidance on how to use the location element? So this would be supplementary to the IATI element page, and any donor guidance. If it’s for Aidstream, even better!

(Taryn Davis) #2

Responding to the question of what is most useful, if we were to import the data into an AMP, at the very least would need Name and Administrative, if specific locations lower than an admin level is wanted, then we would also need Point and Location Class.

(SJohns) #3

Thanks Taryn @tdavis - that’s good info. Do you remember whether there was anything that came out of the Open Ag initiative? I seem to remember that location was one of the things that Reid looked at?

(James Coe) #4

Hi Sarah. We identified the location-reach element being important, in part because it helped defined what the location actually referred to. For example, if a project trains a number of teachers from across the country in the capital city, what is the location?

Using the location-reach element helped resolve this as they could, for example, put the location as the capital city but then define it as the physical place where the activity took place.

(SJohns) #5

Thanks @james.coe, useful to know. Would you also expect to see additional location element/s used to show where the teachers came from (ie location-reach = beneficiaries location)? Or is that getting unnecessarily complicated?

(James Coe) #6

Based on my personal thoughts – i’d say that would be helpful. (1) understanding where the beneficiaries are is an important aspect of understanding where the aid is going while (2) including this element would help counter the narrative that “most aid is going to the capital city / regional capital” when it might just be that the aid is being implemented there but the impact will be spread across several areas.

(1) = good for the users.
(2) = good for the publishers.

In my opinion, the issue we need to address is when publishers just say “whole of country”.

Here’s a blog I wrote on it a few years ago.

1 Like
(Taryn Davis) #7

In addition to James’s comments, we had feedback on what location level was important for people. We learned from those we talked to that it should be geocoded at least to Admin 2, while some also wanted the exact location, such as village.

1 Like
(Yohanna Loucheur) #8

Would echo James’ comments. This is exactly the perspective we’re trying to take for Canada, though it’s challenging.

(Matt Geddes) #9

On coordinates vs names - unless you have a fancy system (and access to computerised boundary maps etc) you are working with ADMs and names - and as mentioned above, at least ADM2 is what is in use by most government budget systems.

Working against this - the data quickly becomes junk with bad spellings, use of outdated ADM names etc - and this is where coordinates matter.

In my experience most users are satisfied with the activity level description - if they need more, they should really be talking to the programme manager anyway as they would take hours and hours to type out.

RE - point of spend vs point of impact - I think this needs to be a field in the location element - there isn’t really a way to solve it within one location - so if you know them, then report both - or at least mark what you are reporting as to which it is.

(Matt Geddes) #10

I always found this guidance helpful: http://docs.aiddata.org/ad4/files/geocoding-methodology-updated-2017-06.pdf - if useful I could fish through old emails for the aiddata people who I met when they came to Sierra Leone and trained 16 students to geocode the AIMS, hence they have good training materials.

1 Like
(SJohns) #11

Thanks for the information everyone - so it looks like information on administrative level 2 location ie. city or district rather than level 1 (region/division) is the most useful. Location-reach is also useful, as is including location information in the activity level description. Coordinates are better than just names.

I have an additional question: On the coordinates, IATI captures point data (ie one town in a district) rather than shape data (ie the boundaries of a district). Where the beneficiaries are located within a district, perhaps in small settlements that may not be on a map, rather than a particular town, how would you like to see this recorded in IATI? Are there other sub-elements that could help clarify this?

(SJohns) #12

Thanks Matt for finding the link. I’ll have a look through and let you know if I need more info.

(Andy Lulham) #13

I don’t know if this is already well-known… But IATI allows you to specify district boundaries via the location/location-id and/or the location/administrative elements. This is a cool feature, but unfortunately I don’t know if the resulting info is exposed anywhere, possibly because it’s a bit tricky to do (because of the many different vocabularies).

So e.g. I can do something like:

    <location-id vocabulary="G1" code="1142263" />
    <name>Farāh, Afghanistan</name>

…and that location-id (1142263) would refer to the Farāh region of Afghanistan in the GeoNames vocabulary (G1): https://www.geonames.org/1142263/farah.html

(Yohanna Loucheur) #14

Indeed, using a shape (with a gazeteer’s ID) makes much better sense than using coordinates when trying to geolocate beneficiaries.

It is indeed one of the key gaps in the open data infrastructure that there is not API to retrieve info from eg Geonames, making them the IDs almost useless (indeed, is GAC alone in using geonames IDs in its IATI data?)

1 Like