GeoStats.jl: a Julia framework for geostatistics and geomodelling

Three concerns, not one: geometry, algorithms and visualisation

The readme describes GeoStats.jl as an extensible framework for geospatial data science and geostatistical modelling, fully written in Julia, and it says the package is comprised of several modules. Three areas are named. The first is advanced geometric processing, which is the part that lets the framework talk about geometries, locations and domains as first class objects rather than as columns in a data frame. The second is state-of-the-art geostatistical algorithms, which is the modelling core. The third is sophisticated visualisation of geospatial data, which matters more than it sounds, because a gridded estimate that cannot be looked at is hard to trust. The word extensible in the description is the load bearing one. The framework is structured so that the algorithms, the geometry handling and the visualisation are separable layers, and the topic list reinforces that reading with geomodeling, spatial-statistics, statistical-learning and gis as separate concerns rather than one blended feature list.

The package lives in the JuliaEarth organisation, not a solo repository

The repository is under the JuliaEarth organisation, and that placement is the most informative thing in the readme. JuliaEarth is a community around geospatial computing in Julia, and GeoStats.jl is one of its packages alongside a separate GeoStatsDocs documentation site. The documentation is not a wiki page with a few examples, it is a stable published site, and the readme sends all further information there rather than duplicating it in the repository. The readme itself is short by design, and what it does carry is a set of badges that describe the project's formal standing: a CI status badge for the master branch, a Zulip chat badge pointing at a dedicated geostats.jl stream on the Julia language chat, an MIT licence badge, a Journal of Open Source Software badge with its DOI, and a Zenodo DOI badge for archiving. The JOSS entry matters more than a usual badge, because a peer reviewed paper is a different kind of commitment from a README, and the paper directory in the repository tree is the source of that submission.

A 0.x version line that still moves weekly

The release history says the package is actively worked on. The recent versions are v0.91.0 published on 2026-10-19, v0.90.2 on 2026-09-27 and v0.90.1 on 2026-09-15, and the last push to the repository was on 2026-10-19, the same day as the v0.91.0 tag. Three releases in a five week window is a fast cadence for a scientific package, and it tells you two things at once. The first is that the package is under active development rather than in maintenance mode. The second is that the 0.x version line means the API is not frozen, and a minor version bump in a Julia package can carry breaking changes without a major version warning. The repository reinforces the community angle with a CITATION.bib file, which is the file you point a journal at when you use the package in a paper, and the Zenodo DOI badge gives you a citable archive for the exact version you ran. The repository itself carries no install command, so the online documentation is the only place the setup steps are written, and it is also where the first worked example lives for each module.

The tree is a Julia package with a formatter, a paper and a test suite

The repository layout is a standard Julia package with some additions. There is a Project.toml at the top level, which is the dependency and metadata file every Julia package carries, and a src directory holding the code. The test directory is there, and the CI badge points at a workflow named CI.yml, so the tests run on every push against the master branch. The docs directory holds the documentation sources, which are built and published to the separate GeoStatsDocs site rather than served from the repository. The paper directory is the JOSS submission, and a CITATION.bib file at the top level. Two style files are worth noticing: a .JuliaFormatter.toml, which pins the formatting rules so the whole codebase is formatted the same way, and a .all-contributorsrc, which is the configuration for the contributor listing that fills most of the readme. The licence is MIT, which is the permissive end and means the code can be used inside a commercial tool without copyleft obligations.

Where it sits against a general purpose GIS or a Python stack

The alternative to a package like this is a general purpose GIS, or a Python geospatial stack with a geostatistics library bolted on. The difference in approach is where the modelling lives. In a general purpose GIS, the spatial layer does geometry, reprojection and cartography, and statistical modelling of a continuous field is something you either do not do or do in a separate environment with a file format in between. In a geostatistics framework, the geometry is the substrate the estimators run on, so kriging, simulation and the visualisation of the result are one workflow over the same objects. The cost of that choice is scope. This is a modelling framework, not a data management system, and the readme does not claim format coverage, data connectors or a mapping interface. The other comparison is with a Python stack, and there the deciding factor is usually the rest of your code. If your pipeline is already Julia, pulling in a separate Python environment for the spatial statistics is a cost that a native package removes.

Who this is for, and where the boundaries are

Judging from the topic list and the framing, the intended user is a domain scientist who works with spatially continuous quantities rather than with tables of independent rows: mineral deposit estimation, reservoir characterisation, soil mapping, environmental monitoring. Those are problems where the value of a sample depends on where it was taken, which is exactly what the framework is built to express. The same design makes it a poor fit for two kinds of work. If you need software that turns shapefiles and rasters into tiles, a geostatistics framework is the wrong tool and you will spend your time fighting the abstraction. And if your project needs a frozen API with a compatibility promise, a 0.x package that ships releases every couple of weeks is a poor dependency, no matter how good the algorithms are. The documentation site is the place to check the specific estimator and workflow you need before committing, since the readme deliberately keeps the feature detail out of the repository.

Editorial conclusion

GeoStats.jl fits a Julia user whose problem is spatial rather than tabular, in particular a mineral geologist, reservoir engineer or environmental modeller who needs kriging, stochastic simulation and map output from the same codebase and the same language as the rest of their analysis. It does not fit a team that needs a general purpose GIS with a broad format support list, since the package is about statistical modelling of spatial fields rather than data engineering for vector and raster formats, and it does not fit a user who wants a stable 1.0 API, because the package is still on a 0.x version line. Before you adopt it, read the online documentation for the module layout, and check the release notes for the 0.90 to 0.91 step, since a minor version bump in this ecosystem is where breaking changes are most likely to be described.

Frequently asked questions

Official sources

1. JuliaEarth/GeoStats.jl on GitHub
2. License: MIT
3. Project website
4. README
5. Releases