About the Data
- Methodology, required software, raster formats, Etc.
ESRI ArcView with the Spatial Analyst extension, ESRI ArcGIS with the Spatial Analyst extension, or ArcInfo will allow you to read and analyze the database files.
The data files can also be read by any software product that allows the user to import ESRI GRID-formatted data.
The data files are also provided the data in the ESRI Raster Binary format. Almost any programming language can read this file directly.
See also “What data formats are used?” below.
ESRI grid format. The archive contains grids for the world and each of the six continents, excluding Antarctica. Each of the archive files contains two folders, an ArcInfo GRID folder and an INFO folder. Both folders must be extracted from the archive file into one new folder.
ESRI binary format. The archive contains contains raster binary data for the world and a rich text formatted file that describes the binary format. The binary raster file format is a simple format that can be used to transfer raster data among various applications. Almost any programming language can read this file directly.
For both formats, downloaded files need to be uncompressed using a standard Zip utility (e.g., WinZip, PKZIP, etc.) before they can be imported to GIS or other software. Users should expect a substantial increase in the size of downloaded data after uncompression. For additional information see the ReadMe file for 2010.
The dataset values are people per cell.
The LandScan datasets represent population count.
The data should not be used as a change detection or migration tool.
The reason we caution against a cell by cell comparison between LandScan database releases is that our input data sets are constantly improving which in turn cause changes in the population distribution. For instance, we often receive higher-resolution data depicting populated places (towns or villages) that did not exist in the digital representation of the area at a coarser scale. Of course the people were there all along, but may just “show up” in the latest version of our distribution. In other cases we may receive a more refined administrative boundary file which we use as a population control total boundary. These new boundaries may cause the population distribution within them to shift from an earlier version with a coarser boundary. In some cases we have found that the actual census counts associated with an administrative area may have been transposed with a nearby administrative area somewhere in the process before reaching us. Correcting these types of errors also cause the population distribution to shift. For these reasons we do not want our users to think that “migrations” are taking place where they are not.
We are unable to distribute the datasets we use in the development of the LandScan Global Population dataset. During the development of the population databases we use datasets that are provided by many sources and for which we have no redistribution rights.
The “Value” field in the database table contains the number of people per cell. This is a population count per cell, not a population density.
The “Count” field in the database table contains the number of cells that have the same population count as the cell of interest.
The LandScan Global grid cannot be projected into another coordinate system without a resampling of the data taking place (e.g. resulting in extra cells or data loss). It is possible that the user may not even be aware that they are changing the data if they bring the LandScan data into a projected view in the ESRI ArcMap environment. The data is reprojected and resampled “on the fly”. In addition, special care must be taken to ensure that analysis cell size is set to match the LandScan data (e.g.0.008333333 degrees) and the analysis window is snapped to a cell interval extent. If using ArcMap, the user needs to bring in the LandScan data first (to set the projection) and then other data can be brought into this view for mensuration.
- Symbology (layer file), ArcGIS Pro issues, Etc.
The issue could be the result of where you are storing the dataset. Users of the most recent versions of ArcGIS (ArcGIS 10.7+ and ArcGIS Pro) have experienced permissions issues when storing the files on an external device (e.g. hard drive, thumb drive, secondary drive (D:/)), as opposed to local storage. We suggest saving to the C:/ drive, or to your desktop, if possible.
Another issue could be spaces within the file path. If the LandScan data is stored at a location with spaces in the directory name, ArcGIS is unable to read the data. For example, ‘C:\Users\Me\My Data\lspop2019’ would need to be converted to ‘C:\Users\Me\My_Data\lspop2019’ or ‘C:\Users\Me\MyData\lspop2019’.
- Conversion to vector, projecting the data, Etc.
The LandScan dataset is not projected, but can be used as a “Geographic” projection with various GIS software packages (e.g., ERDAS and ESRI). The data are referenced by latitude/longitude (WGS84) coordinates.
Projecting the LandScan grid into another coordinate system will result in re-sampling the data (population loss will result). However, there is a work-around this problem.
1. Convert the LandScan data for your area of interest to points.
2. Project the points to your desired coordinate system.
3. Sum the points by your desired output grid cell size (e.g. 1km) -this can be a little tricky and can be accomplished a couple of ways:
a. Create an indexed matrix of polygons that mimic the grid extent and resolution you desire and sum the points values inside each polygon; then convert the summed value to a grid
b. Convert the projected points to a grid using your final output extent, but at a finer resolution(e.g. .25km or .5km). This will ensure that all population counts will be used. Aggregate this finer resolution grid to your desired output cell size (e.g. aggregate factor of 2 or 4 depending on the cell size used). It is important to keep extents and cell size on divisible multiples to prevent data loss or spatial "grid creep".
**Note - take care to change the spatial analyst cell size accordingly for these steps (smaller cell size for conversion of projected points to grid and for the aggregation step - then your desired cell size for any further analysis).
It is advisable to first test this on a small area to validate your procedures.
We do not recommend converting the GRID data into a shapefile containing polygons because “people” are lost during the conversion. If users must convert the data from grid format to feature format, we recommend converting to a point file. This way each point represents the cell total as maintained in the GRID format.
Gridded data requires addressing the size of each grid(s) in a designated density area. For example, if your area of interest includes 10 LandScan Global cells, you will need to:
-convert the cells to polygons,
-project the polygons to your desired projection,
-sum the area of those 10 polygons,
-divide that area number to the total population sum (total pop / area sum = density sq).
Some things to keep in mind:
Because the data is originally in a geographic coordinate system, the cells become smaller (more narrow) the closer they get to the Poles. This holds true even after the polygons are projected. Therefore, remember to treat every area of interest with unique area calculations (i.e. you cannot assume another area of interest with 10 cells will have the same area sum).
Additionally, if some polygons appear to have merged, this is because two adjacent cells shared an identical population count. This is acceptable since the only concern is to calculate the total area sum.
The links below provide useful information for calculating population density: