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.

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

• administrative-gazeteer

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

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.

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

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"

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

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

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

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.

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.

Moving this to the 1.04 Upgrade forum

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).

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

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.