Populated Places

The Populated places dataset is a common used dataset and will likely be identified as required by all responding to a humanitarian situation. This dataset is a spatial dataset that identifies the location and type of populated place (capitals, cities, towns, villages, settlement, etc) in a country; during humanitarian response it may also include spontaneous settlements, collective centers, planned settlements, etc . The datasets at a minimum includes the place name and P-code, but the type and other criteria are also helpful and should be decided by the IM network.

Potentials sources: 

 Government agencies Description
 SALBIt draws from a wide array of source including from the official United Nations Terminology, UNGEGN, Permanent Missions to the United Nations and National Geospatial Authorities. the maintenance of multiple forms and usage of names and the promotion of the recording of locally-used names reflecting the languages and traditions of a country for names is also paramount for the organization.
 UNDP 
 IMGO 
 Global Human Settlement dataset 
  

Former Minimum Data Quality Checklist for Populated Places COD: (required criteria have an *)

1   

Spatial relationships and topology

1.1

All Populated Places are represented as points. 

All populated places are represented as points. Option: Urban areas may additionally be represented by polygons as a separate, supporting dataset.  Names/p-codes in this dataset must match the point dataset that is the primary authority for name spelling and p-codes.

1.2*

Duplicate points have been removed 

Duplicate points (geographically close points representing the same place) are removed. Note that alternate spellings of a place must be represented as additional fields, not as additional geometry.

1.3*

Populated Places are within administrative boundaries.

Populated places point locations are within administrative boundaries. If points fall outside the administrative boundaries, it needs to be clarified whether the reason is a digitization error, a projection issue or another topic.

 

2

 Projection

2.1*

The projection is defined, correct and consistent.

The projection is defined and is correct and consistent with the Administrative boundary CODs. Instructions on how to define the projection are in the Geodata Manual.

 3

 Data characteristics and attributes

3.1

All sizes of populated places are represented in one dataset. The size is indicated by an attribute.

All sizes of populated places should be represented in one dataset, with size being indicated by an attribute. This attribute can be population, type of populated place (city or village), the indication of capitals of an administrative unit etc. More information can be found in the Geodata Manual section on Features

3.2*

Each populated place has a p-code.

The p-code of the place serves as a unique identifier and must be included. The p-code format must use any available national system. It does not need to include the p-code structure of the administrative boundaries, it can be a separate system if this is easier to maintain (especially if the data is incomplete or needs to be developed over time)  Otherwise it can be generated using the p-code guidance.

3.3*

P-codes of populated places are consistent throughout.

P-codes of populated places are complete and consistent throughout the populated places datasets.

3.4*

The name and p-codes of the administrative units into which the point falls are listed.

The names of the administrative boundary units into which the point falls must be listed in a set of fields (one field for each administrative level) for each point. These administrative boundary unit names must match exactly the names in the Administrative Boundaries CODs. P-codes of higher-level admin units should be included where available, as names sometimes are not unique.

 

3.5*

The name of the populated place must be included in a field and may not be in all caps.

The name of the populated place must be included in a field. Names of populated places should be in proper case, not all caps. Names do not need to be unique.

 

3.6

Only essential fields are included.

 

Only essential fields are included: name, p-code and ‘size’ of populated places. Other information (such as agricultural production data, or other extraneous information should not be included).  See the Geodata Manual for more information about essential, marginal, and external attribute fields. In particular, meaningless ID fields that are generated during some Shapefile processes must be removed. Option: Coordinates for the point location of the populated places can be included in two fields (one for the X and one for the Y coordinate).

 

3.7

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. If possible field names should be identical to the ones used in the Administrative Boundary CODs for p-codes and names of administrative boundary units.

 

 4

 Metadata

4.1*

Metadata is developed 

Metadata should explain terminology used in field names. Metadata options can be seen in the Geodata Manual.

 

 5

 Dataset format and name

5.1

The Populated Places datasets are at least posted as Shapefile.

The Populated Places CODs 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.

 

5.2

File names follow file naming convention.

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.

 

6

Comments

6.1

Comments included in metadata

Any comments that you would like to make a note of (methodology, caveats, update frequency etc.) can be included in the metadata under the heading abstract.