Administrative Boundary COD
Quality Checklist
Quality Checklist
cod.humanitarianresponse.info
The purpose of the QA Checklists is to support the Common Operational Datasets (COD) quality and sets
minimum standards that enable data interoperability and harmonization. The guidance is designed to be used in
conjunction with the IASC Guidelines Common Operational Datasets (CODs) in Disaster Preparedness and
Response.
Please send questions and comments to [email protected]
1
1.1
Spatial relationship and topology
The administrative boundaries All administrative boundaries are represented as closed polygons.
are closed polygons.
1.2
The administrative levels are
nested.
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.
1.3
There are no missing
polygons.
All admin units at a given level are represented (no missing polygons)
1.4
If there is a multiple distinct
polygon, it is represented as a
single record.
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.
1.5
The topology of the polygons
is clean.
The polygons of the same administrative boundary level are topologically
clean (no overlaps, gaps, voids or superfluous lines). A visual check can
give an immediate impression of errors. See the Geodata Manual for
instructions on topological cleaning in Arc Map.
2
2.1
Projection
The projection is defined,
correct and consistent.
3
3.1
Data characteristics and attributes
The national boundary is
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
Admin level 0. The
be named in any way that is consistent and clear concerning the
subsequent subdivisions are
administrative boundary unit levels, or the file naming convention can be
numbered / named
used.
consistently.
3.2
Name and p-code of
administrative boundary units
are included at each level.
Essential fields to be included at each administrative boundary unit level
are the name of the admin unit and its unique p-code. Names in nonwestern scripts (such as Arabic) should be reflected in another name field
in western encoding. The administrative boundary unit names and pcodes must be able to be considered ‘official’ for the humanitarian
response.
3.3
The p-code uses a national
system code.
The p-code format must use any available national systems. Otherwise it
can be generated using the p-code guidance and must be consistent
throughout the administrative boundary unit levels.
3.4
The name and p-code fields
of higher levels are included
The names of higher-level admin units to which a given feature belongs
should be included and must be identical to the ones in the higher-level
admin units. P-codes of higher-level admin units should be included
The projection is defined and is correct and consistent among different
administrative boundary unit layers. Instructions on how to define the
projection are in the Geodata Manual.
Quality Checklist - Administrative Boundary COD (June 2013)
Quality Checklist Administrative Boundary COD
|2
where available, as names sometimes are not unique.
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 field.
Option: an area field can be included as long as the units are calculated in
square meters or square km and the field name makes this clear.
Shapelength fields are rarely relevant for administrative boundary unit
polygons.
3.6
The 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. Field names should be
consistent for the same attributes (i.e. p-codes and administrative unit
names) throughout the administrative unit levels.
3.7
Attribute names should be in
proper case, not all caps.
Attribute names should be in proper case, not all caps. Attribute names do
not need to be unique.
3.8
A Reference name field is
included if names of
administrative units contain
apostrophes or special
characters.
If any of the names have accented characters (é, ò, etc.), apostrophes or
are in a non-western script, a Reference name field should be included
that contains a version of the name without accented characters or
apostrophes. . Reference names do not need to be unique. Spaces and
hyphens are allowed. The reference name is expressed in proper
case. For example, the administrative unit name ‘Sixt-Fer-à-Cheval’ would
become ‘Sixt-Fer-a-Cheval’.
4
4.1
Metadata
Metadata is included with the
dataset
5
5.1
Dataset format and names
The Administrative Boundary
datasets are at least posted
as Shapefiles.
5.2
File names follow the file
naming convention.
6
6.1
Comments
Comments included in
metadata
Metadata should explain terminology used in field names. Metadata
options can be seen in the Geodata Manual.
The Administrative Boundary COD should be posted at least as Shapefile
or GML. Posting them as ArcGIS geodatabases is possible. An Excel
version of the tabular data formatted for easy use by report officers and
others is highly recommended. Other formats such as KML can be
included if desired.
The file names for the datasets should be indicative of the content. File
names should be harmonized following the file naming convention in the
File and Dataset Management Manual.
Any comments relevant to the data (methodology, caveats, update
frequency, etc.) should be included in the metadata under the heading
abstract.
Quality Checklist - Administrative Boundary COD (June 2013)