GSTools generates random fields and kriging estimates from one covariance model

Fields are generated by randomisation, not by solving a field equation

The core mechanism of GSTools is stated plainly in the project documentation: spatial random fields are generated using the randomisation method described by Heße et al. 2014. That choice matters for how the library feels in practice. A randomisation approach produces a field that satisfies the covariance structure by construction rather than by iterative approximation, so a Gaussian model gives you a Gaussian field and a different covariance model gives you a different family of realisation, not a tweak to the same solver. Everything else in the library hangs off that object. The random field generation is the first tutorial in the documentation, and the example scripts live in numbered folders under examples/, including 01_random_field, which tells you where the library considers its centre of gravity to be.

One covariance model object carries the parameters through every operation

A covariance model in GSTools is an object with named parameters rather than a set of loose arguments. The README example constructs gs.Gaussian(dim=2, var=1, len_scale=10), where dim is the dimensionality, var the variance and len_scale the correlation length, and that single object is then handed to the random field generator. The same model type appears throughout the tutorial list: there is a dedicated tutorial on the covariance model itself, alongside variogram estimation, field transformations, normalising data, spatio-temporal modelling and plurigaussian field simulation. GSTools provides a long list of ready made covariance models and allows user defined ones. From a maintenance point of view this is the right shape, because a model that can be reused and reparameterised avoids the duplicated class hierarchies that plague older geostatistical code.

Variogram estimation is automated, and directional variants are supported

The purpose list in the project documentation names automated variogram estimation and fitting as a first class feature, and it lists directional variogram estimation and modelling separately. That distinction reflects the practical difficulty in geostatistics: an omnidirectional variogram is a summary that hides anisotropy, and a field with directional structure will not be fitted well by one. The estimator itself draws on the scientific Python stack. pyproject.toml lists emcee at version 3.0.0 or later, which is an ensemble sampler used for inference rather than least squares, plus hankel for numerical transforms, numpy and scipy for the numeric core, meshio for mesh input and output and pyevtk for VTK export. The library also ships an examples/03_variogram folder with runnable scripts, so the estimator can be inspected rather than trusted blindly.

Kriging covers four estimator families plus collocated cokriging

Four kriging variants appear in the README purpose list: simple, ordinary, universal and external drift. The difference between them is the mean assumption, and the library keeps them as separate entry points rather than hiding the choice behind a default, which is the behaviour you want when the drift term is a physical quantity such as elevation. Collocated cokriging is offered as well, and the tutorial list has a dedicated entry for kriging including collocated cokriging with scripts in examples/05_kriging. Alongside interpolation, the documentation lists conditioned field generation, which is the operation that produces a realisation consistent with measured data points, and examples/06_conditioned_fields holds the corresponding scripts.

Installing is a one-liner, and the first field is seven lines of Python

Three installation paths are documented, and all three work on Linux, Mac and Windows. The conda route is the plainest.

    conda install gstools

The pip route is equivalent.

    pip install gstools

And uv is supported as a third option.

    uv add gstools

Once installed, the worked example generates a 100 by 100 structured field on a grid of size 1 by 1 with a Gaussian covariance model, and plots it.

import gstools as gs
# structured field with a size 100x100 and a grid-size of 1x1
x = y = range(100)
model = gs.Gaussian(dim=2, var=1, len_scale=10)
srf = gs.SRF(model)
srf((x, y), mesh_type='structured')
srf.plot()

The SRF object is the random field, the call on the next line evaluates it on the grid and the plot helper renders it. The package requires Python 3.8 or later, and the classifiers cover 3.8 through 3.14.

Geographic coordinates are a model flag, and cartopy does the drawing

Handling coordinates on a sphere rather than a plane is a separate path in GSTools, not a plotting detail. The README example sets latlon=True on the model and passes a geo_scale, with the constant gs.KM_SCALE used to express the length scale in kilometres, and the field is built with the seed argument so the realisation is reproducible. The plotting side is delegated to cartopy, which the README says the library works perfectly well with, and the example imports both matplotlib.pyplot and cartopy.crs alongside gstools. Because the geography enters through model parameters and structured field construction, a distance error here silently changes every length scale downstream, which is worth checking before trusting a regional result.

The compiled core and the LGPL licence are the two things to check before adopting

The dependency list opens with gstools_core at version 1.3.0 or later, a separate compiled component, and that is where the packaging friction lives on platforms without a matching wheel. The remaining dependencies are scientific Python packages, so the packaging risk is concentrated on the compiled core. Licensing is LGPL-3.0-or-later, which means a project that links GSTools as a library has obligations to consider, and any code copied into your own source is treated differently from simply importing it. The classifier Development Status:: 5 - Production/Stable is the project's own assessment of that balance. Beyond the core library, the repository includes benchmarks and two airspeed velocity configuration files, which is a sign that performance regressions get tracked rather than left to chance.

Version 1.7.0 is the last tag, but the repository has moved since

The release history is short and dated: v1.7.0 'Morphic Mint' on 2025-04-28, v1.6.1 'Periodic Peach' on 2025-01-30 and v1.6.0 'Periodic Peach' on 2024-07-18. The last push was on 2026-10-13, so commits have landed well after the newest tag, which means the documentation for the latest release and the documentation on the main branch can disagree. The version in pyproject.toml is dynamic and filled from the version control system through hatch-vcs, so a checkout of main will not match the released version number. If you are citing GSTools in a paper, the project points to a Geosci. Model Dev. paper for the library and to a Zenodo DOI for version specific citations, which is the mechanism to use when reproducibility matters.

Editorial conclusion

Adopt GSTools when your work needs a complete geostatistical chain in Python, from variogram fitting through kriging to conditioned field simulation, and you want one covariance model object driving every step. Do not reach for it if you only need a variogram estimate on a small grid, since the setup cost of the model and estimator objects exceeds a one-off script, and treat the compiled backend as a packaging concern on unusual platforms. Verify first that your Python version sits inside the supported range, that the geo_coordinates path works with the cartopy version you already have, and that the release you install matches the documentation you are reading, because the latest tag is v1.7.0 while the repository has moved on since.

Frequently asked questions

Official sources

1. GeoStat-Framework/GSTools on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases