Calibration

Calibration is meant here as the process of fitting a statistical model that best describes the likelihood that a grid cell is built upon. The results of calibration are used to describe the locational suitability of a grid cell for urban development. The calibration process has been performed by means of a logit model using the AutoGLM package. This model describes the presence of at least 2.5% built-up land in a grid cell, so that any grid cells with 2.5% built-up land have the value one, and all grid cells with less than 2.5% built-up land have the value zero. An elaborate discussion of the calibration process and choices can be found here. And further alternative calibration methods here.

All data are collected in CSV files internally within the modelling framework (through study-area-specific files that can be generated via /Analysis/Calibration/Export_DataForCalibration/Result). A considerable number of factors were tested during the model fitting process. These include

  • static calibration factors, which are generally provided by other institutes or researchers, and loaded as exogenous data sources; and
  • dynamic calibration factors, which are calculated on-the-fly in the modelling framework.

Some variables require pre-processing; these are described in the subsection on Prior variable preparation. Other variables depend on iterative model results and are therefore computed on-the-fly. These are treated in the section on Dynamic variable computation.

Static calibration factors

  • BU_RES_2000: Built-up area per cell in the year 2000
  • BU_RES_2020: Built-up area per cell in the year 2020
  • Pop_2000: Population per cell in the year 2000
  • Pop_2020: Population per cell in the year 2020
  • Elevation: Elevation in a cell in meters.
  • Slope: Slope in degrees based on EROS 30 arc-second digital elevation model (EROS Centre, 2018) using ArcGIS.
  • Mean Terrain Roughness Index: (Riley, DeGloria, & Elliot, 1999) using ArcGIS on EROS 30 arc-second digital elevation model (EROS Centre, 2018).
  • IsProtectedArea: indicates whether a grid cell is within a protected area according to the World Database on Protected Areas (WDPA).
  • IsFloodProneArea: indicates whether a grid cell is prone to being flooded, as indicated by an OECD inundation map with a return period of 100 years.
  • Earthquakes Modified Mercalli Intensity Index: MMI index by UNEP/DEWA/GRID-Europe for the Global Assessment Report on Risk Reduction (GAR). Based on the Shakemap Atlas from USGS. Unit is the expected number of events per 1000 years.
  • Landslide_risk: indicates how likely a grid cell is affected by landslides, according to a recent ARUP study. The values range from 1 to 4, with 1 being the least likely subject to landslides, and 4 being the most likely. Distance to coastline: This is a coastline data set obtained from Katarzyna Goch (JRC), and the distance is calculated in GeoDMS.
  • Distance to rivers: data from Hydro Rivers v10 by Hydro Sheds, distance calculation in GeoDMS. Distance to lakes: data from the Global Lakes and Wetlands Database (GLWD) at grid level 3, distance calculated in GeoDMS. Distance to major roads: roads from the GRIP4 database. Road classes 1, 2, and 3 are major. The distance calculation is done in GeoDMS.
  • Distance to secondary roads: roads from the GRIP4 database. Road classes 4 and 5 are secondary. The distance calculation is done in GeoDMS.

Dynamic calibration factors

  • Pop_Density_2020_8dir: Average population density in directly surrounding cells.
  • Travel costs to villages, towns, and cities: indicate the relative difficulty to reach the closest village (or town, or city), town (or city), and city, respectively. These variables are based on physical geography, country borders and the degrees of urbanisation definition of settlement types.

For the composition of suitability factors related to accessibility to existing and future settlements, it has been decided not to depend too much on data describing existing transport infrastructure. Instead, we rely on abstract travel costs that are computed as the weighted cost-distance to a specific destination. In the case of a flat domestic plane, these costs are roughly equivalent to Euclidean distance. Weights are applied to overcome slopes, waterbodies, high elevations and national boundaries, with the value of weights inspired by the JRC’s global accessibility map.

Pointers for calibration file generation

Calibration is typically based on separate files with observed data for a specific geography. In these files, every row represents a grid cell in the CompactedDomain. Every column represents a variable. These calibration files can be generated as .csv files with dedicated operations available within the model configuration. The procedures to do so are available in: /Analysis/Calibration

Most variables included in the calibration are hardcoded in /Analysis/Calibration/Create_DataForCalibration. A limited number of variables is generated by metascripting. These are variables (or, rather, attributes) that are based on a priori set calculation rules, but the exact number of variables, their names and their value distributions are only known after GeoDMS has updated preceding units or attributes.

The variables described in the Creata_DataForCalibration container are only available there as attributes within the GeoDMS framework. Exporting to files on a drive needs to be done explicitly. This is done in /Analysis/Calibration/Export_DataForCalibration. Exports are available as:

  • a CSV file. To export all variables, simply update (double-click) /Analysis/Calibration/Export_DataForCalibration/Result'. Files will be stored in the localdata folder, with the filename reflecting the geography defined in ModelParameters/StudyArea_manually`.
  • TIFF files describing integer values of single variables. To export any variable as a tiff, simply update (double-click) an attribute in /Analysis/Calibration/Export_DataForCalibration/Export_Tiffs_ForCalibration, for instance /Analysis/Calibration/Export_DataForCalibration/Export_Tiffs_ForCalibration/Pop_2020. The resulting file will be stored as a TIFF file with the variable name as the file name, in a folder named after the geography defined in ModelParameters/StudyArea_manually.

Note that, through metascripting functions, all attributes that are hardcoded in /Analysis/Calibration/Create_DataForCalibration are automatically added to the list of columns exported in the CSV file, and to the list of variables that can be exported as a TIFF.

Pointers for calibration result ingestion

The calibration exercise is typically done in an external software, for instance, in R. The current model repository already contains a set of R scripts that manage the reading of output calibration files, preparation and fitting of tailored models. These scripts were kindly provided by VU University Amsterdam. The fitting exercise ultimately yields a set of coefficients that describe the effect of a variable on the likelihood that a grid cell is built-up. The model now runs with the results from a calibration exercise executed and described by VU University Amsterdam in December 2024. Using these results does not require any modifications to the model. If a user decides to redo the calibration exercise or simply change the coefficients, this is needed:

  • Create a new Excel file (.xlsx) with variable names in the first column, and coefficient values per continent in the other columns. Add it to the configuration folder as ‘%ProjDir%/Data/Calibration/Calibration_continents_[date or other characteristic].xlsx’. Then change ModelParameters/Calibration_filedate so that it reflects the date or other characteristic placeholder.
  • Alternatively, a user could simply replace the coefficient values in an existing file and store it under its current name. This is easier but intrinsically problematic, as this change is not easily traceable in the repository.
  • The correct reading of the new coefficients can be verified in e.g. /Analysis/Calibration/ReadCoefficients/PerContinent.
  • If variables are added or removed from calibration, this also needs to be adapted in the suitability definitions. As of now, the references to specific variables are hardcoded in the suitability definitions in the model. Thus, the user will have to manually adapt the references to variables in /Analysis/Future/Allocate_Builtup_T/Suitability/Calc and in /Analysis/Future/Allocate_Population_T/Suitability/Calc.

Table of contents