Verde: scikit-learn style gridding for spatial data
Processing and gridding spatial data, machine-learning style
At a glance
- What is it?
- Verde is a Python library for processing and interpolating spatial data on a 2D surface, using an API modelled on scikit-learn. It is stable, BSD-3-Clause licensed, and aimed at geoscientists who already work inside the SciPy stack.
- Who is it for?
- Verde suits Python users in the geosciences who already work with numpy, pandas, scikit-learn or xarray and want gridding to behave like a scikit-learn estimator. It is the wrong choice if your data does not fit in memory, since the README states larger-than-memory support is still a future goal, and it is the wrong choice if you want an out-of-the-box GIS interpolation tool rather than composable Python objects.
- Can I use it commercially?
- Yes. BSD-3-Clause is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 42 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Verde fills between GIS interpolation and the SciPy stack
Spatial interpolation is a solved problem in the sense that many tools exist, but the tools tend to live apart from the rest of a scientific Python workflow. A GIS package will grid a point cloud, and then you export a raster and load it back into numpy. Verde takes the opposite position: gridding is a step inside a pipeline, not a standalone operation. The README describes it as a library for processing spatial data (topography, point clouds, bathymetry, geophysics surveys) and interpolating them on a 2D surface, with an interface similar to scikit-learn. That framing matters. If you already use scikit-learn, the shape of the API is familiar: you construct an object, call fit, then predict onto a grid. If you do not, the learning curve is mostly about learning scikit-learn conventions rather than about geostatistics. The stated audience is clearly the working geoscientist who writes Python. The project's listed goals include integration with numpy, pandas, scikit-learn and xarray, support for scalar and vector data such as wind speed or GPS velocities, and support for both Cartesian and geographic coordinates. That combination is narrower than a general-purpose interpolation library and wider than a single-algorithm package.
How the machine-learning framing changes the data flow
The core claim in the README is that the interpolation methods are inspired by machine learning, and the interface follows scikit-learn. That has a concrete consequence for how a workflow is structured. Instead of a function that takes scattered points and returns a grid in one call, you assemble a chain of objects. Trend removal is one object, a blocked or windowed operation is another, a gridded operation is another, and cross-validation wraps the whole thing. Each of those is exposed as a separate step, which is what makes the style composable. The README lists trend removal, blocked and windowed operations, and cross-validation as analysis methods often used in combination with gridding. The data flow is therefore point data in, transformations applied in sequence, grid out, with the intermediate steps available for inspection rather than buried inside a single interpolation routine. Vector data is handled as a first-class case, which is not true of every gridding library: wind speed and GPS velocities are named explicitly. The geographic coordinate support is the other architectural fork. Cartesian and geographic coordinates are not the same problem, and the README treats them as two supported modes rather than one general case. The repository layout also shows a doc directory alongside the package, which is consistent with a documentation-heavy project, though the README alone does not tell you how complete that documentation is for each gridded method.
Installing Verde and the config keys you actually touch
Verde is distributed on PyPI as verde and on conda-forge through the verde-feedstock repository, both of which are linked from the README badges. The conventional install is therefore either pip install verde or conda install -c conda-forge verde. The README does not spell out a minimum Python version in the body text; the badge reports compatible Python versions but the text itself does not commit to a number, so check the PyPI metadata before pinning. There are no configuration files, no environment variables and no config keys in the sense of a service you configure. The knobs are constructor arguments on estimator objects, which is the scikit-learn pattern. That means the thing you tune is code, not a config file, and a reviewer cannot tell you which argument names to set without reading the API documentation for the specific gridded class you intend to use. The README does not enumerate those arguments. It is worth being explicit about that limitation: this article can tell you the install commands and the shape of the API, but not the parameter names, because the supplied material does not contain them. The project is part of Fatiando a Terra, and the README points to a citation page with a DOI (10.21105/joss.00957), so if you publish results you will want to cite it.
The larger-than-memory problem is still open
The most useful sentence in the README for an adoption decision is the one about future releases: they will focus on expanding the range of gridders, optimizing the code, and improving algorithms so that larger-than-memory datasets can also be supported. Read that plainly. Larger-than-memory support is a goal, not a property. If your survey data does not fit in RAM, Verde as documented is not the tool for that job yet. This is a real boundary rather than a caveat, because gridding is exactly the operation where datasets get large. The second limitation is the flip side of the scikit-learn interface. A user who wants a single call that goes from points to a finished raster will find the estimator composition more verbose than a one-shot interpolation function. The README frames this as a feature, and for reproducible pipelines it is, but it is a cost. The third is scope. The README says later releases will expand the range of gridders, which implies the current set is not exhaustive. If your problem needs a specific interpolation method that Verde does not implement, the machine-learning style interface will not help you; you will be writing the method yourself or using a different library. None of this contradicts the project's own statement that it is stable and ready for use. Stable means the API will not break without warning. It does not mean every capability is finished.
Verde against a traditional geostatistics library
The obvious comparison is with a classical geostatistics package, where the model is variogram fitting followed by kriging. That approach makes the spatial covariance structure of the data the centre of the analysis: you estimate how correlation decays with distance, then use that fitted model to weight the interpolation. Verde's stated inspiration is machine learning instead, and the interface is scikit-learn. The practical difference is where the user's attention goes. In a variogram-first workflow you spend your time on the covariance model and its parameters. In Verde you spend it on composing estimators and validating them, which is why cross-validation is listed as a first-class part of the toolkit rather than an afterthought. Neither is strictly better. A variogram gives you an interpretable statement about spatial continuity that a scikit-learn style estimator does not hand you. Verde gives you a pipeline that slots into the rest of the SciPy stack, with pandas and xarray on the input and output sides, which a standalone geostatistics package often does not. If your deliverable is a defensible variogram and a kriged surface, the classical route is more direct. If your deliverable is a repeatable gridding step inside a larger Python analysis, Verde's composition model is the better fit. The README does not claim to replace the classical tools, and it should not be read that way.
What the BSD-3-Clause licence means for embedding Verde
Verde is released under the BSD 3-clause License, with the text in LICENSE.txt in the repository. That is a permissive licence: it allows redistribution and modification, including in proprietary software, provided the copyright notice and licence text are retained and the names of the project and its contributors are not used to endorse derived products without permission. For most engineering teams this is the least friction option available, and it is a meaningfully different position from a copyleft licence that would require you to release modifications. This is a description of the licence terms, not legal advice; if you are embedding Verde in a shipped product, have your own counsel read LICENSE.txt rather than relying on a summary. The practical implication for a pipeline is that you can vendor the library, fork it, or wrap it without asking anyone. The practical implication for the ecosystem is that improvements are not forced back upstream, so the maintenance burden sits with whoever holds the fork.
Release cadence and the cost of staying current
The release history gives a reasonable picture of maintenance cost. v1.8.0 landed in May 2023, v1.8.1 in June 2024, and v1.9.0 in March 2026. That is a slow but non-zero cadence, with roughly a year between the 1.8 line and the next minor, and a longer gap before 1.9. The README's stability statement is the relevant commitment here: the project says it is careful about introducing backwards incompatible changes and will provide ample warning when doing so, and that upgrading minor versions should not require code changes. Taken together, the expected upgrade cost is low. You should still read the release notes for each minor version rather than assuming, because the stability promise covers the API surface, not numerical results. A change in an interpolation algorithm can alter your output grid without breaking your code, and the README's own roadmap mentions optimizing the code and improving algorithms as ongoing work. That is the upgrade risk worth watching: not import errors, but different numbers. If your gridded products feed into something with a fixed reference, pin the version and re-run deliberately.
Editorial conclusion
Verde suits Python users in the geosciences who already work with numpy, pandas, scikit-learn or xarray and want gridding to behave like a scikit-learn estimator. It is the wrong choice if your data does not fit in memory, since the README states larger-than-memory support is still a future goal, and it is the wrong choice if you want an out-of-the-box GIS interpolation tool rather than composable Python objects. Before adopting, verify two things in your own environment: that your coordinate types are handled by the gridders you intend to use, and that the minor-version upgrade path does not touch the parts of the API you rely on.
Community notes