Awesome

exactextract

[

exactextract provides a fast and accurate algorithm for summarizing values in the portion of a raster dataset that is covered by a polygon, often referred to as zonal statistics. Unlike other zonal statistics implementations, it takes into account raster cells that are partially covered by the polygon.

Background

Accurate zonal statistics calculation requires determining the fraction of each raster cell that is covered by the polygon. In a naive solution to the problem, each raster cell can be expressed as a polygon whose intersection with the input polygon is computed using polygon clipping routines such as those offered in JTS, GEOS, CGAL, or other libraries. However, polygon clipping algorithms are relatively expensive, and the performance of this approach is typically unacceptable unless raster resolution and polygon complexity are low.

To achieve better performance, most zonal statistics implementations sacrifice accuracy by assuming that each cell of the raster is either wholly inside or outside of the polygon. This inside/outside determination can take various forms, for example:

• ArcGIS rasterizes the input polygon, then extracts the raster values from cells within the input polygon. Cells are interpreted to be either wholly within or outside of the polygon, depending on how the polygon is rasterized.
• QGIS compares the centroid of each raster cell to the polygon boundary, initially considering cells to be wholly within or outside of the polygon based on the centroid. However, if fewer than two cell centroids fall within the polygon, an exact vector-based calculation is performed instead (source).
• Python's rasterstats also considers cells to be wholly within or outside of the polygon, but allows the user to decide to include cells only if their centroid is within the polygon, or if any portion of the cell touches the polygon (docs).
• R's raster package also uses a centroid test to determine if cells are inside or outside of the polygon. It includes a convenient method of disaggregating the raster by a factor of 10 before performing the analysis, which reduces the error incurred by ignoring partially covered cells but reduces performance substantially (source). The velox package provides a faster implementation of the centroid test but does not provide a method for disaggregation.

Method used in exactextract

exactextract computes the portion of each cell that is covered by a polygon using an algorithm that proceeds as follows:

1. Each ring of a polygon is traversed a single time, making note of when it enters or exits a raster cell.
2. For each raster cell that was touched by a ring, the fraction of the cell covered by the polygon is computed. This is done by identifying all counter-clockwise-bounded areas within the cell.
3. Any cell that was not touched by the ring is known to be either entirely inside or outside of the polygon (i.e., its covered fraction is either 0 or 1). A point-in-polygon test is used to determine which, and the 0 or 1 value is then propagated outward using a flood fill algorithm. Depending on the structure of the polygon, a handful of point-in-polygon tests may be necessary.

Additional Features

exactextract can compute statistics against two rasters simultaneously, with a second raster containing weighting values. The weighting raster does not need to have the same resolution and extent as the value raster, but the resolutions of the two rasters must be integer multiples of each other, and any difference between the grid origin points must be an integer multiple of the smallest cell size.

Compiling

exactextract requires the following:

• A C++17 compiler (e.g., gcc 7+)
• CMake 3.8+
• GEOS version 3.5+
• GDAL version 2.0+ (For CLI binary)

It can be built as follows on Linux as follows:

git clone https://github.com/isciences/exactextract
cd exactextract
mkdir cmake-build-release
cd cmake-build-release
cmake -DCMAKE_BUILD_TYPE=Release ..
make
sudo make install

There are three options available to control what gets compiled. They are each ON by default.

• BUILD_BENCHMARKS will build performance tests
• BUILD_CLI will build a command-line interface (requires GDAL)
• BUILD_DOC will build the doxygen documentation if doxygen is available
• BUILD_PYTHON will build Python bindings (requires pybind11)
• BUILD_TEST will build the catch_test suite

To build just the library and test suite, you can use these options as follows to turn off the CLI (which means GDAL isn't required) and disable the documentation build. The tests and library are built, the tests run, and the library installed if the tests were run successfully:

git clone https://github.com/isciences/exactextract
cd exactextract
mkdir cmake-build-release
cd cmake-build-release
cmake -DBUILD_CLI:=OFF -DBUILD_DOC:=OFF -DCMAKE_BUILD_TYPE=Release ..
make
./test/catch_tests && sudo make install

Using exactextract

exactextract provides a simple command-line interface that uses GDAL to read a vector data source and one or more raster files, perform zonal statistics, and write output to a CSV, netCDF, or other tabular formats supported by GDAL.

In addition to the command-line executable, an R package (exactextractr) and python bindings allow the functionality of exactextract to be used with R sf and raster objects.

Command line documentation can be accessed by exactextract -h.

A minimal usage is as follows, in which we want to compute a mean temperature for each country:

exactextract \
  -r "temperature_2018.tif" \
  -p countries.shp \
  -s "mean" \
  -o mean_temperature.csv \
  --include-col country_name

In this example, exactextract will summarize temperatures stored in temperature_2018.tif over the country boundaries stored in countries.shp.

• The -r argument provides the location for of the raster input. The location may be specified as a filename or any other location understood by GDAL. For example, a single variable within a netCDF file can be accessed using -r temp:NETCDF:outputs.nc:tmp2m. In files with more than one band, the band number (1-indexed) can be specified using square brackets, e.g., -r temperature.tif[4]. If the band number is not specified, statistics will be output for all bands.
• The -p argument provides the location for the polygon input. As with the -r argument, this can be a file name or some other location understood by GDAL, such as a PostGIS vector source (-p "PG:dbname=basins[public.basins_lev05]").
• The -s argument instructs exactextract to compute the mean for each polygon. These values will be stored as a field called mean in the output file.
• The -o argument indicates the location of the output file. The format of the output file is inferred using the file extension.
• The --include-col argument indicates that we'd like the field country_name from the shapefile to be included as a field in the output file.

With reasonable real-world inputs, the processing time of exactextract is roughly divided evenly between (a) I/O (reading raster cells, which may require decompression) and (b) computing the area of each raster cell that is covered by each polygon. In common usage, we might want to perform many calculations in which one or both of these steps can be reused, such as:

• Computing the mean, min, and max temperatures in each country
• Computing the mean temperature for several different years, each of which is stored in a separate but congruent raster files (having the same extent and resolution)

The following more advanced usage shows how exactextract might be called to perform multiple calculations at once, reusing work where possible:

exactextract \
  -r "temperature_2016.tif" \
  -r "temperature_2017.tif" \
  -r "temperature_2018.tif" \
  -p countries.shp \
  -include-col country_name \
  -s "min" \
  -s "mean" \
  -s "max" \
  -o temp_summary.csv

In this case, the output temp_summary.csv file would contain the fields temperature_2016_min, temperature_2016_mean, etc. Each raster would be read only a single time, and each polygon/raster overlay would be performed a single time, because the three input rasters have the same extent and resolution.

Another more advanced usage of exactextract involves calculations in which the values of one raster are weighted by the values of a second raster. For example, we may wish to calculate both a standard and population-weighted mean temperature for each country:

exactextract \
  -r "temperature_2018.tif" \
  -w "world_population.tif" \
  -p countries.shp \
  -f country_name \
  -s "mean" \
  -s "pop_weighted_mean=weighted_mean" \
  -o mean_temperature.csv

This also demonstrates the ability to control the name of a stat's output column by prefixing the stat name with an output column name.

Further details on weighted statistics are provided in the section below.

Alternate syntax

exactextract 0.1 required a somewhat more verbose syntax in which each raster was required to have a name that could be provided as an argument to a stat function, e.g.:

exactextract \
  -r "temp:temperature_2018.tif" \
  -r "pop:world_population.tif" \
  -p countries.shp \
  -f country_name \
  -s "mean(temp)" \
  -s "pop_weighted_mean=weighted_mean(temp,pop)" \
  -o mean_temperature.csv

This syntax is still supported.

Supported Statistics

The statistics supported by exactextract are summarized in the table below. A formula is provided for each statistic, in which x_i represents the value of the ith raster cell, c_i represents the fraction of the ith raster cell that is covered by the polygon, and w_i represents the weight of the ith raster cell. Values in the "example result" column refer to the value and weighting rasters shown below. In these images, values of the "value raster" range from 1 to 4, and values of the "weighting raster" range from 5 to 8. The area covered by the polygon is shaded purple.

The behavior of these statistics may be modified by the following arguments:

• coverage_weight - specifies the value to use for ci in the above formulas. The following methods are available:
  • fraction - the default method, with ci ranging from 0 to 1
  • none - ci is always equal to 1; all pixels are given the same weight in the above calculations regardless of their coverage fraction
  • area_cartesian - ci is the fraction of the pixel multiplied by it x and y resolutions
  • area_spherical_m2 - ci is the fraction of the pixel that is covered multiplied by a spherical approximation of the cell's area in square meters
  • area_spherical_km2 - ci is the fraction of the pixel that is covered multiplied by a spherical approximation of the cell's area in square kilometers
• default_value - specifies a value to be used in place of NODATA
• default_weight - specifies a weighing value to be used in place of NODATA
• min_coverage_frac - specifies the minimum fraction of the pixel (0 to 1) that must be covered in order for a pixel to be considered in calculations. Defaults to 0.