Skip to content

Raster checks

Jump to bottom
Jiří Tomíček edited this page Sep 16, 2025 · 26 revisions

Raster checks

raster.unzip

Delivery can be unzipped

The check definition can be found here.

The check verifies that the delivery has been uploaded to QC tool as a valid ZIP file and the ZIP file can be successfully unzipped.

raster.naming

File names match file naming conventions

The check definition can be found here.

The check can not be skipped. The result values of the check are: ok, aborted.

This check verifies that the delivery contains all expected raster files. Depending on specific product, one delivery may contain one or more raster files. All raster files must be in valid GeoTiff (.tif) file format which can be successfully opened by GDAL software.

The naming of expected raster files is specified by the layer_names parameter. The layer_names parameter can contain one or more a regular expressions. For each item in the layer_names, vector.naming check searches for a GeoTiff file that matches the regular expression. If a matching file is found, then a symbolic layer name is assigned to the matching GeoTiff file. If there is no matching file found, then vector.naming check exits with aborted status.

In general, the raster naming expressions in layer_names have the following structure:

<product_code>_<reference_year>_<resolution>_<aoi_code>_<epsg_code>_<version>.tif

where:

  • product_code is 3-letter code of the product, e.g. FTY, GRA, WAW, IMC, IMD, TCD;
  • reference_year is 4-digit reference year, e.g. 2018;
  • resolution is raster cell size in meters, e.g. 010m, 020m or 100m;
  • aoi_code is 2-letter country code, AOI code or delivery unit code, e.g. eu; The aoi_code is also used to match the delivery with the corresponding AOI in raster.gap check;
  • epsg_code is a valid EPSG code identifying the raster coordinate reference system, e.g. 3035;
  • version is product specific version identifier, e.g. v1_0

Notes:

  • The naming expressions are case-insensitive.
  • Each GeoTiff file must contain a single band, multi-band rasters are not allowed.
  • The number of GeoTiff files in the delivery must be equal to the number items in layer_names, excessive .tif files are not allowed.
  • Inside one delivery, GeoTiff files can be located anywhere in the directory hierarchy, eg. all examples are valid: FTY_2015_020m_eu_03035_d04.tif, fty_020m/fty_2015_020m_eu_03035_d04.tif, 2015/fty/20m/fty_2015_020m_eu_03035_d04.tif.

raster.inspire

Metadata are in accord with INSPIRE specification

The check definition can be found here.

A raster product delivery must contain a valid INSPIRE compliant XML metadata file and INSPIRE mapping tables.

INSPIRE mapping tables show the evidence that the products delivered are compatible with the INSPIRE Data Specification on Land Cover. This evidence is provided as table document showing the associations between the source (product/deliverable) and the target data model (INSPIRE Data Specification on Land Cover). Mapping tables are provided together with the final products.

Reference:

raster.attribute

Attribute table is composed of prescribed attributes

The check definition can be found here.

Each HRL raster delivery must have a .tif.vat.dbf file with a raster attribute table. Only attribute names are checked. The attribute names are case insensitive. The attribute table must always have the following attributes:

  • value, corresponds to unique codes in the GeoTiff file
  • count, corresponds to the number of raster cells belonging to each code.
  • area_km2, the area in square kilometres covered by cells with the code.
  • area_perc, the area in square kilometres covered by cells with the code, expressed as percent of total mapped area.
  • class_name, a text description of the land use / landcover class corresponding to the code.

raster.epsg

Raster uses specific EPSG code

The check definition can be found here.

The EPSG authority must be part of the GeoTiff file's spatial reference system information. The only accepted EPSG code is EPSG:3035 (ETRS89 ETRS-LAEA equal-area projection). The EPSG code must be explicitly included in the CRS definition.

raster.pixel_size

Pixel has specific size

The check definition can be found here.

All cells in the raster product must have the same cell size. Required cell size is specified by the cellsize parameter in each product definition.

raster.origin

Bounding box upper left corner is positioned on grid

The check definition can be found here.

  • Upper-left X, Y coordinates of the raster must be divisible by raster cell size with no remainder;
  • Upper-left X, Y coordinates of the raster must be divisible by 1000 with no remainder.

raster.bit_depth

Raster datatype is of specific bit depth

The check definition can be found here.

The GeoTiff file in the raster delivery must conform to required data type. The required data type is Byte (values from 0 to 255) or Int16 (values from -32768 to +32767)

raster.compress

Raster uses specific compression formats

The check definition can be found here.

A raster delivery must have a compression type specified. The compression type of the GeoTiff file must be LZW.

raster.value

Pixels have specific values

The check definition can be found here.

Only values specified in the list by each Product are allowed. Other values are reported as errors. Pixels with value 255 are considered to be 'NoData' or outside mapping area. It is not required that the raster has a 'NoDataValue' property set.

raster.nodata

Raster layer has the NoData code set to the corresponding value

The check definition can be found here.

E.g. For Urban Atlas 2012 Building Heights layer the NoData code is set to 65535.

raster.gap

There is no gap in the AOI

The check definition can be found here.

The AOI is defined by the boundary package, see Boundaries. There must be no cell having the value set to NoData inside the AOI. If gaps are found, the raster.gap check creates a raster attachment file with all gaps inside the AOI set to 1. If the number of detected gaps is < 1,000,000 pixels, then an additional vector attachment file with vector boundaries of gap areas is also provided.

raster.tile

The GeoTiff raster file is stored in tiled format

The check definition can be found here.

The data inside the GeoTiff raster file must be stored in tiles. The number of rows and columns in one tile must not be greater than the max_blocksize setting. Recommended tile size is 256 x 256 or 512 x 512 pixels. For more details about tiled GeoTiff format, see the Cloud-Optimized GeoTiff specification (https://www.cogeo.org/).

raster.mmu

Minimum mapping unit

The check definition can be found here.

Raster minimum mapping unit (MMU) check identifies patches with area smaller than specified MMU. To determine if a raster cell belongs to a patch, 4-way connectivity is used (two raster cells touching only by cell corner are not considered as part of the same patch). Cells with value 255 (NoData) are excluded from the MMU check.

raster.color

Color table is in accord with specification

The check definition can be found here.

Each raster delivery GeoTiff file must have a colour table. The colour table must be embedded in the GeoTiff file and provided in form of a tif.clr text file which is part of the delivery. Values in the GeoTiff colour table and in the .tif.clr colour table must match.

  • Colours common to all products
* 254; RGB = (153, 135, 153); unclassifiable;
* 255; RGB = (  0,   0,   0); outside area;

raster.cog

Raster data complies with the OGC Cloud Optimized GeoTIFF standard

The check definition can be found here.

The Cloud Optimized GeoTIFF (COG) relies on two characteristics of the TIFF v6 format (tiles and reduced resolution subfiles), GeoTIFF keys for georeference, and the HTTP range, which allows for efficient downloading of parts of imagery and grid coverage data on the web and to make fast data visualization of TIFF or BigTIFF files and fast geospatial processing workflows possible.

The raster file structure is checked using the GDAL COG validator.

Reference:

Clone this wiki locally