Verde: gridding spatial data with a scikit-learn style API

What Verde is for, and who should reach for it

Verde targets a narrow but common problem in the earth sciences: you have scattered measurements at irregular locations and you want them on a regular 2D grid. The README lists topography, point clouds, bathymetry and geophysics surveys as the kind of data it handles. The output is a grid, and the library also covers the steps that usually surround gridding, such as trend removal, blocked and windowed operations, and cross-validation.

The intended user is someone writing Python who already has numpy, pandas or xarray in their workflow. Verde is described as part of the Fatiando a Terra project, and the README states that integration with the SciPy stack is one of the project goals. It is not a desktop application and it does not ship a viewer. If you want to click on a map and export a raster, this is the wrong layer of the stack.

Two design choices narrow the audience further. Verde supports both scalar and vector data, which matters for things like wind speed or GPS velocities where each location carries more than one value. It also supports Cartesian and geographic coordinates, so a dataset in longitude and latitude does not have to be reprojected before it reaches the gridder.

The scikit-learn shape of the API, and what it buys you

The mechanism is the interface. Verde's core interpolation methods are, in the README's phrasing, inspired by machine learning, and the library implements an interface similar to scikit-learn. In practice that means a gridder is an object you construct with parameters, then call fit on with your coordinates and data values, then call predict or grid on to produce output. Because the objects follow the same convention as scikit-learn estimators, cross-validation utilities and parameter search code that expect that convention can operate on them.

This is a real architectural decision rather than a cosmetic one. The usual alternative in geoscience tooling is a function that takes arrays and returns a grid, with no object to hold fitted state. Verde keeps the fitted state on the estimator, which is what lets the same object be handed to a validation routine and re-fitted on different folds. It also means the parameters you tune are attributes of an object, so you can construct several gridders with different settings and compare them in a loop.

The cost of that choice is indirection. A single call to a function that grids your data becomes three or four lines of object construction and method calls. For a one-off script that is overhead you may not want. For a repeatable analysis where you are comparing interpolation methods, the structure pays for itself.

Installing Verde and gridding a first dataset

Verde is distributed on PyPI and on conda-forge, and the README carries badges for both. The repository's Makefile shows the editable install path used in development, which is `python -m pip install --no-deps -e .` run from the repository root. For normal use, install from PyPI or conda-forge rather than from a checkout.

python -m pip install verde

After the install completes, importing the package should print a version string. The project uses setuptools_scm to generate that version at build time, so an editable install from a git checkout gets a version derived from the commit rather than a clean release number. That is expected behaviour, not a broken install.

import verde
print(verde.__version__)

The README does not include a worked gridding example, so the exact method names for a first grid come from the API documentation rather than from this page. What the README does establish is the shape: you build an estimator, fit it to coordinates and values, and ask it for a grid. The documentation site at fatiando.org/verde is where the concrete class names and their parameters live, and it is worth reading the API reference for whichever gridder you pick before writing the script.

One practical note on the development workflow. The Makefile defines a `test` target that runs pytest with doctests enabled and coverage reporting, and a `check` target that runs black, isort, burocrata and flake8. If you plan to send a patch, those are the commands the maintainers expect to pass.

Where Verde stops: memory, scale and scope

The most concrete limitation is stated by the project itself. The README's project status section says that later releases will focus on expanding the range of gridders, optimizing the code, and improving algorithms so that larger-than-memory datasets can also be supported. That phrasing places large datasets in the future tense. If your survey does not fit in RAM, Verde as documented is not the tool that solves it, and you should look for something built around chunked or out-of-core execution.

There is a second boundary in the scope of the library. Verde processes and grids spatial data; it is not a geospatial file format toolkit and it is not a plotting library. The README's goal list is about gridding, processing tasks and data preparation, with integration into numpy, pandas, scikit-learn and xarray. Anything about reading shapefiles, reprojecting coordinate reference systems or rendering maps sits outside that list.

A third point is the release cadence visible in the version history. v1.8.0 arrived in May 2023, v1.8.1 in June 2024, and v1.9.0 in March 2026. The last push to the repository was on 2026-08-04. The README describes the project as stable and says that upgrading minor versions should not require code changes, which is consistent with a library that prioritises API stability over frequent feature drops. If you need a feature that only exists in an unreleased commit, you are on your own until it ships.

How Verde differs from generic interpolation in SciPy

The obvious alternative is the interpolation code already in the SciPy stack, such as the griddata family of routines. The difference is not the underlying mathematics so much as the surrounding machinery. A SciPy interpolation call takes points and values and returns interpolated values at new points. It has no concept of a fitted estimator, no cross-validation hook, and no built-in handling of geographic coordinates.

Verde adds the estimator layer, which is what makes model selection practical. You can fit several gridders, score them with the same cross-validation code, and pick a winner without writing your own loop around each one. The README also lists blocked and windowed operations and 2D trend removal as included functionality, which are the preprocessing steps you would otherwise write by hand before calling an interpolator.

The trade-off is dependency weight and abstraction. If you need one interpolation of one small array and nothing else, pulling in an estimator framework is more machinery than the task requires. If you are comparing methods across several datasets, or you need to remove a regional trend before gridding, the framework is doing work you would otherwise duplicate.

Licence, upgrades and the cost of staying current

Verde is released under the BSD 3-clause License, and the repository carries the full text in LICENSE.txt. The pyproject.toml sets the SPDX identifier to BSD-3-Clause in the header notice applied to Python source files. This is a permissive licence, which in practice means you can use the library in commercial and closed-source work without the copyleft obligations that a GPL-style licence would impose. That is a description of what the licence text says, not legal advice; if the licence terms matter to your organisation, have counsel read LICENSE.txt.

The upgrade cost is low by design. The README states that the project is careful about backwards incompatible changes and will provide ample warning when introducing them, and that upgrading minor versions should not require code changes. The version history is consistent with that claim: three releases across roughly three years, with a patch release between two minor versions.

What you are paying for instead is the possibility that a feature you want has not landed. The README's roadmap points at more gridders, performance work, and large-dataset support as future items. If your workflow depends on one of those, you are waiting on the maintainers or contributing the change yourself. The CONTRIBUTING.md and the Fatiando a Terra contact page are the documented routes for both.

Editorial conclusion

Adopt Verde if your team already works in Python with numpy, pandas or xarray and needs gridding, trend removal, blocked means or cross-validation in the same script as the rest of the analysis. Do not adopt it if you need out-of-core processing for datasets larger than memory, because the README says support for that is a goal for later releases rather than something already in place. Before committing, check the API reference for the specific gridder you intend to use, confirm the version on PyPI or conda-forge, and read the citing page if the output will appear in a publication.

Frequently asked questions

Official sources

1. fatiando/verde on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases