ITOS Gold Standard COD-AB Quality Check

This is the evaluation ITOS uses when processing data for OCHA offices, and if there are no errors are left after the final acceptance by OCHA and the IM Network then a high quality COD-AB is developed. It is recommended that this report be provided as metadata with the dataset so users are aware of the impact of processing.

If the Provisional COD does not go through the ITOS process, then it is recommended that this evaluation is used to guide the processing (cleaning, standardizing, and formatting) of the dataset and the evaluation is completed and provided as proof of data quality.

Downloadable version ( English / French )

XXX Evaluation Checklist

Upon completion of each section, mark its 'Status' in the checklist with the appropriate symbol from the ones shown here:	✔	Use when there are no errors or any other issues to report
	✘	Use when there are errors found which need to be reported
	!	Use when there are no actual errors, but there is some issue you feel needs to be reported to the IMO


1) - Data Pre-processing
ITOS	OCHA	Section	Description	Status	Comments	Fixed?	Fixed by: Date	Reference Links
1.1		Admin layers downloaded	Most recent version of the Admin layer datasets has been downloaded from HDX. Add date of download and file names of the Admin layers to the 'Comments'. Date format: YYYY MM DD					HDX
1.2		Related datasets noted	The file names of any tables, files, or datasets that contain related data to the Admin layers has been recorded here in the 'Comments'. Any older versions of the Admin layers which are available from HDX but are not being evaluated here, should also be noted in the 'Comments'.
1.3		Data Source is known	The downloaded Admin layers have a data source listed on HDX. Record the full Data Source(s) in the 'Comments'.
1.4		Encoding is in UTF-8 or higher	The encoding is in at least UTF-8 to ensure that special characters will be supported.
1.5	2.1	Projection is defined, correct, and consistent	The projection is defined, correct, and consistent across each Admin layer. Instructions on how to define the projection are in the Geodata Manual. Record the projection of the layers in the 'Comments'.					Geodata Manual
1.6	1.1	Admin layers are closed polygons	All downloaded Admin layers are represented as closed polygons. Some Admin layers may be additionally represented as lines, but there should be a polygon layer for each Admin level of the country.
1.7		Data extent is correct	The current data extent for each layer should not exceed the intended geographical area of the data.
1.8	3.1	Admin layers are numbered / named consistently	The national boundary is Admin level 0. The first subdivision is Admin level 1. The second subdivision is Admin level 2, etc. (Option: the files can be named in any way that is consistent and clear concerning the administrative boundary unit levels, or the file naming convention can be used. See section 1.9)
1.9	5.2	Admin layer file names follow the OCHA Naming Convention	Each Admin layer file uses the OCHA file naming convention as follows: ISO3_Code+DataType_SubCode_[Scale]_Source_[Additional Description]. If files do not follow the convention, record in the 'Comments' what the file names should be according to the convention.					OCHA File Naming Convention
1.10	4.1	Metadata is included	Each downloaded Admin layer should have metadata associated with it. The metadata should satisfy the criteria in the Geodata Manual.					Geodata Manual

2) - Data Characteristics and Attribution
ITOS	OCHA	Section	Description		Comments	Fixed?	Fixed by: Date	Reference Links
2.1	3.2	Name and P-code fields exist for each layer	Essential fields to be included at each Administrative boundary layer are the name of the admin unit and its unique P-code. Names in non-Western scripts (such as Arabic) should be reflected in another name field which uses non-Western encoding.
2.2	3.5	Only essential fields are included	Only essential fields are included (no population, agricultural production, or other extraneous information are included). See the Geodata Manual for more information about essential, marginal, and external attribute fields.					Geodata Manual
2.3		Admin0 Name uses UN Short Name	The Admin 0 name field for all layers uses the UN Short Name found in the United Nations Multilingual Terminology Database This is not required in the COD but is preferable for cartographic purposes. When the Admin 0 name is not present and needs to be generated, the UN Short Name should be used. If the UN Short Name is not being used or needs to be generated, make a note of what the Short Name is in the 'Comments'.					UN Multilingual Terminology Database
2.4	3.6	Field names are clear	Field names should be as clear as possible. For example ‘DISTRCT’ is preferable to ‘D_NAME’. ‘PCODE’ is preferable to ‘ID’. If they are not clear, they must be documented in the metadata.
2.5	3.6	Field names used consistently across all Admin layers	Field names should be consistent for the same attributes (i.e., P-codes and Admin names) throughout the Administrative layers.
2.6	3.8	Reference name field exists if necessary	If any of the names have accented characters (é, ò, etc.), apostrophes, or are in a non-Western script, a Reference name field should be included.
2.7	3.8	Reference name field attributed correctly	Reference name field, if present, should be attributed correctly with no accented characters, apostrophes, or non-Western scripts. Reference names do not need to be unique. Spaces and hyphens are allowed. The reference name should be expressed in proper case. For example, the Administrative unit name ‘Sixt-Fer-à-Cheval’ would become ‘Sixt-Fer-a-Cheval’.
2.8	3.7	Attribute names in Proper Case, not ALL CAPS	All Western script attribute names for all layers should be in Proper Case, not ALL CAPS.
2.9	3.3	P-code uses a National system code	The P-code format must use any available National systems. Otherwise it can be generated by OCHA using the P-code guidance and must be consistent throughout the Administrative boundary unit levels. Make a note in the comments if any layer's P-codes are numeric rather than alphanumeric.					P-code Guidance
2.10		P-codes are fully constructed	The P-codes for each Admin layer should be fully constructed at each level, not partial.
2.11	3.4	Name and P-code fields of higher levels are included	Each Admin layer should include all of the Admin name and P-code fields for each Admin level above it. (i.e., the Admin 2 layer should include the following fields: Admin 0 name, Admin 0 P-code, Admin 1 name, Admin 1 P-code, Admin 2 name, Admin 2 P-code.)

3) - Spatial Relationship, Topology, and Post-Merge Procedures
ITOS	OCHA	Section	Description		Comments	Fixed?	Fixed by: Date	Reference Links
3.1		ITOS Lookup Tables created	ITOS Lookup Tables have been created and populated with the necessary information from the COD layers and schemas. Make a note of what fields will not be mapped in the 'Comments' since they will not be updated if any changes are made to the data.
3.2		COD Layers merged to ITOS schema	Downloaded COD Admin layers have been merged with their corresponding layers in the ITOS ISO_AdminBoundaries_working.gdb
3.3		Known issues / errors fixed	All issues/errors that have been reported in this checklist up to this point have been addressed and fixed if possible within the ITOS ISO_AdminBoundaries_working.gdb. (All attribution fixes should be performed on the ITOS portion of the schema only.) Provide a quick summary of all your edits/changes in the 'Comments'.
3.4	1.3	There are no missing polygons	All Admin units at a given level are represented (no missing polygons).
3.5	1.4	Multipart geometry check	A single Administrative unit that consists of multiple distinct polygons (for example a coastal area + islands) is represented as a single record with multipart geometry.
3.6		Alternate language fields analyzed	All alternate language name fields that were merged into the ITOS schema need to be analyzed. Need to verify whether there is a one to one relationship between all alternate language name fields for each Admin layer.
3.7		P-codes are unique	The P-codes for each layers' lowest Admin units should be unique.
3.8		P-code attribution is consistent	The P-codes used within each record of a given Admin layer's attribute table should be consistent across the record with no contradictions.
3.9		Admin Names checked for uniqueness	Names do not need to be unique at the lowest level but will be checked for uniqueness in order to find potential naming errors. For example: Two counties named "Jackson" in the United States is not an error unless those two counties both happen to fall inside the same state.
3.10		P-code attribution is consistent across all layers	P-codes should be used consistently across all Admin layers. For example: the Admin 2 P-codes used in the Admin 3 layer should be the same as the Admin 2 P-codes used in the Admin 2 layer.
3.11		Admin Name attribution is consistent across all layers	Admin Names should be used consistently across all Admin layers. For example: the Admin 2 names used in the Admin 3 layer should be the same as the Admin 2 names used in the Admin 2 layer.
3.12	1.5	Topology of each layer is clean	The polygons within each Admin layer are topologically clean (no overlaps, gaps, voids or superfluous lines). Gaps and Overlaps are both caused by non-coincident polygon borders. Because this test is performed on each layer it is not a nesting check (nesting is tested in section 3.13).
3.13	1.2	Admin layers are nested by geometry	The polygons of one Admin level fall into one and only one polygon at the next largest level. Boundary edges of the polygon layers are consistent. Unfixed topology errors will be repeated here, in addition to any newly found nesting errors.
3.14		Admin layers are nested by attribution	The attribution for Admin levels is consistent with geometry across all Admin layers.
3.15		Errors fixed	The errors discovered and reported in Section 3 have been fixed if possible. Some edits may be better suited to be performed on the 'AdminLine' layer after it has been created. List all fixes and edits in the 'Comments'.
3.16		Admin lines and points layers have been built	An additional 'AdminLines' and 'AdminPoints' layer should be built from the lowest level Admin layer. These new layers will be useful for editing and for recreating the Admin layers. They can also be useful for cartographic purposes.
3.17		Admin lines topology checked	Topology has been created and fixed for the 'AdminLines' layer.
3.18		Admin layers recreated from lines and points if necessary	The Admin layers have been recreated from the lines and points. This will only be necessary if errors had been found in the polygon layers that were purposely left unfixed because it was deemed easier to have them get automatically fixed by recreating the layers from an error free 'AdminLines' and 'AdminPoints' layer. If there are no errors, then the Admin layers can be used as is to create the candidate.
3.19		Additional errors fixed	Any additional errors that were designated to be addressed after the creation of the lines and points have been fixed. List all additional fixes and edits in the 'Comments'
3.20		Additional issues reported	Any additional issues with the Admin layers which were discovered during the evaluation process, and which did not fit into any of the previous sections, should be reported here.

4) - Create Candidate GDB
ITOS	OCHA	Section	Description		Comments			Reference Links
4.1		Working GDB copied and renamed	'ISO_AdminBoundaries_working.gdb' needs to be copied to the 'Candidates' folder and renamed 'ISO_AdminBoundaries_candidate.gdb'.
4.2		Candidate GDB consists of Admin layers only	The candidate GDB consists of nothing but the Admin feature classes. All extraneous layers and tables have been removed and the Admin layers have been moved out of the 'Data_Layers' feature dataset. The 'Data_Layers' feature dataset should then be removed as well. All supporting documents, layers, and tables that will be delivered with the candidate have been exported, moved, or copied into the 'Supporting_Info.gdb'.
4.3		Schemas have been cleaned	All unnecessary and redundant fields have been removed from the schema of each Admin layer and the 'validOn' date has been recorded for each layer.
4.4		Admin layers renamed	The names of all the Admin layers should follow the OCHA file naming convention as described in section 1.9					OCHA File Naming Convention
4.5	4.1	Metadata updated/created	Metadata must be included for each Admin layer. If metadata already exists, it should be updated, and if it does not exist, it needs to be created. The metadata should be full metadata and the UNGIWG subset of the ISO 19115 metadata standard is the preferred standard and can be found in the Geodata Manual. The existence of metadata should have already been determined in section 1.10					Geodata Manual
4.6	5.1	Excel spreadsheets created	An Excel version of the tabular data formatted for easy use by report officers and others is highly recommended. Each layer's attribute table should be exported to a sheet in an Excel spreadsheet.

5) - Post Candidate to IMO
ITOS	OCHA	Section	Description		Comments			Reference Links
5.1		Candidate has been packaged	The candidate GDB and the tabular data as well as any supporting documentation has been added to a ZIP file named 'ISO_AdminBoundaries_candidate.zip'.
5.2		Candidate uploaded to dropbox	Upload to Dropbox and notify IMO to review. Add Dropbox link and date of upload in 'Comments'.
		Candidate packages avaiable via WAF	Once candidate is accepted, create package ZIP files for Admin Boundaries (in 12 formats) and upload to ITOS web accessible folder; notify IMO and Geneva office. Add the link to the packages folder in the 'Comments' for this section. Add date the Admin packages were added to the WAF to the 'Comments'. Date format: YYYY MM DD