IATI Consultations Archive

Live discussions and consultations can be found at discuss.iatistandard.org.

Proposal: Add additional ADM1 Precision Codes for element.

For country-level spending, two different precision codes exist within the UCDP-AidData Codebook:

  • Precision 6:“The location can only be related to an independent political entity, meaning the pair of coordinates that represent a country. This includes aid that is intended for country-wide projects as well as larger areas that cannot be geo-referenced at a more precise level.”
  • Precision 7:“Unclear. The country coordinates are entered to reflect that sub-country information is unavailable.”[1]
For ADM1 level spending (sub-national regional spending) no equivalent set of precision codes exists. This is difficult for some of programs which work entirely within one specific sub-national region but which may not be able to provide sub-ADM1 geocoding information. For instance, under the existing UCDP-AidData code list an activity spending 100% of its money on technical support to the regional government of the Northern Region of Ghana and a field-level program working in many districts in the Northern Region of Ghana but without the capacity to georeference its activities at the ADM2 level would both be geocoded identically. However, the actual precision of the geographic specificity would be quite different.


[1] UCDP-AidData Codebook Version 1.1, pp 12-13

 

Have more questions? Submit a request

15 Comments

  • 0
    Avatar
    David Carpenter

    Moving this to the 1.04 Upgrade forum

  • 0
    Avatar
    Reinier Battenberg

    To show the source of the admin unit, could we re-use the list of Gazeteers in a field with the name:

    • administrative-gazeteer

     

     

  • 0
    Avatar
    Mark Brough

    We support the new location proposal as part of the 1.04 upgrade, which provides several good updates to the Standard. Also agree that we should work much more to support a fully multi-lingual standard. The next upgrade should work through the whole standard and ensure that this is the case for every element (as an integer upgrade, if not possible beforehand).

  • 0
    Avatar
    jubal harpster

    This is a great suggestion.  I would suggest also adding

    • administrative-name 

    A textual name of the admin unit should appear along with the information of where that name came from. I completely support the ability to identify the admin units within OSM but that will likely involve a separate conversation with the OSM community.  Until that happens its likely  we'll all be stuck with some combination of SALB,GAUL,GADM, etc.

  • 0
    Avatar
    Yohanna Loucheur

    Sorry for the late comment into the process, but we've just realized that a key element of the "Ottawa standard" seems to be missing from the proposed standard.  Among the changes agreed in Ottawa was the inclusion of a "Type of Location" marker to allow coding either 1) Activity or 2) Intended Beneficiaries. We believe it's important to be able to distinguish whether what is being coded is the beneficiaries of an intervention (especially relevant when doing e.g. capacity-building work) or a specific activity (e.g. building an infrastructure). 

    Colleagues from Development Gateway may be able to weigh in with a specific suggestion on how to capture this information, if "Type of Location" is no longer deemed appropriate.

    Cheers

  • 0
    Avatar
    Owen Scott

    Dear All,

    Thank you very much for raising the issue of geocoding as part of the 1.03 standard upgrade. As several readers will know, in August, 2012, discussions were held in Ottawa between the Open Aid Partnership (represented by staff from the World Bank Institute, CIDA, DFID, and Development Gateway), AidInfo, and USAID to discuss changes to the IATI geocoding standard. The resulting document (attached) was shared with the IATI community and the IATI Steering Committee, for consideration as part of the next decimal standard upgrade. These suggestions have the support of a significant number of IATI publishers and the suggestions are already being tested by major development agencies. We believe that the attached document should thus be the starting point for any discussions around changes to the IATI geocoding standard as part of the 1.03 decimal upgrade.

    Specific to the recommendation above, we also believe that deprecating the @adm1 and @adm2 attributes would severely complicate data aggregation and analysis. The existing ecosystem of vocabularies for sub-national areas is complex and constantly shifting, and clear mappings between the different vocabularies are difficult to maintain. Eliminating the requirement that publishers specify ADM1 and ADM2 areas according to a common vocabulary would indeed increase flexibility for publishers, but at the expense of a greatly increasing the challenge for those looking to aggregate, analyze, and use IATI data. We believe that a better solution, though perhaps still not ideal, is to require publishers to use a common vocabulary - thus making the resulting data much easier to aggregate and use.

    Regardless of what changes the IATI community ultimately chooses to make to the geocoding standard, we believe the starting point for the discussion should be the set of proposals put together in Ottawa last August. We look forward to further discussion.

    Best regards,

    Owen Scott
    Development Gateway




    Ottawa_Meeting Summary and Methodology.docx
  • 0
    Avatar
    Bill Anderson

    This thread is closed. Please go to http://support.iatistandard.org/entries/30343967-Summary-of-Geocoding-Changes for guidance on how to participate in this consultation.

  • 0
    Avatar
    Joshua Powell

    Hi Bill,

    Just to quickly clarify - we agree that there is not a single "one-size-fits-all" source for ADM boundary layers/names/ids. However, we feel strongly that for each individual country, there should be only one vocabulary (at least for ADM1/ADM2). In other words, perhaps in country x GADM has the most up-to-date boundaries, but in country y FAO GAUL is best and in country z it is UNSALB. For each of those countries, the respective "best of breed" should be used as the accepted vocabulary to allow for standardization and aggregation across donors and datasets. Thus, at the global level there would be multiple vocabularies, but at the country level there should be only one.

    Regarding expanding precisions to accommodate levels 3-10, I see no problem in doing this, but I feel that it should be in addition to ADM1/ADM2 rather than at the expense of. For the majority of donors/countries, aggregation and analysis will take place at the ADM1/ADM2 level so I would oppose altering the precision 3 (ADM2)/4 (ADM1) codes that currently exist (though adding an additional precision code for ADM3+ does not seem like a bad idea).

    Josh

  • 0
    Avatar
    Joshua Powell

    Bill,

    Understood and agreed that it is a tricky undertaking to have the standard prescribe a boundary for each country. This would remain our strong preference, but you describe a reasonable fall-back if it cannot be achieved. It will likely lead, however, to quite a few datasets that look comparable but cannot truly be compared due to different ADM definitions. For example, using the wrong shapefile for DRC would lead to a different number (and names) of ADM1s, ADM2s so that no crosswalk would be possible. Again, though, your point is well taken.

    Re: the ADM element - yes a more elegant solution would be good. I understand and appreciate Reinier's point that many NGOs want to track their work to more granular ADM levels. However, in terms of IATI reporting and comparison of datasets, I believe that 95%+ of users (and IATI data providers) will want to track to ADM1/ADM2 so maintaining those elements as-is has value. The element could be normalized to something like <adm level=1-n> with <adm level=1> and <adm level=2> as mandatory (for certain precisions where the location is sufficiently specific) and <adm level=3-n> as optional, but that would complicate things further if we are recommending a specific vocabulary for each country for <adm level=1-2> and allowing multiple vocabularies for <adm level=3-n>. Ultimately, I would suggest that the savings in structural elegance probably aren't worth the confusion and room for error - better to keep ADM1 and ADM2 as mandatory attributes of the <administrative> element, with a strongly recommended ADM1/ADM2 vocabulary for each country, and then add a flexible element for ADM3-n.

    Josh

  • 0
    Avatar
    Bill Anderson

    I'm a little confused here. Our proposal to include a vocabulary is based on Development Gateway experience that different vocabularies work best for different countries. The Ottawa Methodology suggests that the Admin 1/2 Id should be "most likely gathered from a boundary shapefile database". We want to be more specific and name the database. (i.e. - the vocabulary).

    It would be great if we could insist on one authoritative database, but Development Gateway's work has proven this not to be a good idea at the moment - see Josh's thoughts  here. This should not, in my opinion, stop us proactively advocating for a single authoritative source - as part of the movement towards inter-operable global data standards. But we need something that works now.

    Reinier also makes the very important point that restricting the standard to two administrative levels is unnecessarily restrictive, hence our proposal to normalise the structure to allow for more levels to be specified. 

    We'll hopefully get a properly worked proposal ready in the next week so that we can start discussing specifics.

    Best

    Bill

  • 0
    Avatar
    Bill Anderson

    Reinier, regarding your suggestion

    "To show the source of the admin unit, could we re-use the list of Gazeteers in a field with the name: administrative-gazeteer"


    The advice from our resident xml expert (David are you following this thread?) is that it would generally be good practice for all values in a codelist to be applicable wherever that list is used. So while Geonames and OSM are applicable for both gazetteers and admin areas, UN-SALB isn't.

    As I understand it this is guidance and not set in stone, but it makes sense to me.

    And Jubal, yes: the name is important and will, I think, be included as the value for the element.

    Bill
  • 0
    Avatar
    Bill Anderson

    Josh

    Your proposal makes sense, but I think it is going to be difficult for the standard itself to enforce which vocabulary should be used for which country:

    • while the choice might be straightforward in some circumstances it may be political in others
    • some publishers might have systems slotted into a particular vocabulary
    • reporting on an activity covering multiple countries with different vocabularies could cause confusion
    I suggest that we draw up guidelines on best practice that we can link to from the standard, and which could be accessed by IATI compliance tests (a full set of these is still under development) but which can be maintained beyond the standard's formal regime. 
    What do you think?
    Also take the point on keeping ADM 1/2 as is. My worry is that we end up with a slightly inelegant, half-normalised solution. Could we normalise the element, but keep your precision logic? 
    Bill
  • 0
    Avatar
    Yohanna Loucheur

    We support Owen's comment above. We share Development Gateway's concern about the proposal to deprecate adm1 and adm2 attributes and allow the use of various vocabularies.  

    We also believe that the methodology agreed in Ottawa last August should be the starting point for the discussion on the geo-coding standard. Developed through consultations between bilateral and multilateral donors, it builds on the method used by the World Bank (thus minimizing changes for those already using this standard) while addressing bilateral donors' needs. We are in the process of testing the standard and will be happy to share what we learn through this process to inform the final standard.

  • 0
    Avatar
    Bill Anderson

    i am working with our colleagues at Development Gateway to finalise proposals on a range of issues falling beneath the location element. We should have this ready by Wednesday 6th March.

  • 0
    Avatar
    Bill Anderson

    Apologies for the long delay on this, but some substantial changes to the <location> section have now been proposed and are included in the latest version of the table of proposed changes. Two documents motivating these changes are attached here.




    2013 03 01 Detailed Proposal for LOCATION Element Under IATI Schema v1 03 (draft 2).docx
    2013.03.01 Proposal for Refactoring of LOCATION Element Precision Codes Under IATI Schema v1.03 (draft 2).docx
Article is closed for comments.