sits: an R and Python package for classifying satellite image time series

What sits is for and the shape of its workflow

sits is an open source R and Python package for satellite image time series analysis. It is developed in R and provides full access to its functions through a Python API, and it exists to let users apply machine learning techniques to image time series obtained from earth observation data cubes.

The workflow it documents is long, and reading it tells you what the package is really for. You select an image collection from cloud providers, build a regular data cube from analysis-ready collections, merge a cube from multisource analysis such as Sentinel-1 with Sentinel-2, extract labelled time series as training samples, run quality control on those samples using self-organised maps, train machine learning and deep learning models, tune the deep learning models for accuracy, classify data cubes with GPU support where available, run spatial-temporal segmentation for object-based classification, post-process the classified images with Bayesian smoothing to remove outliers, estimate uncertainty values, evaluate accuracy using best practices, and improve results with active learning and self-supervised learning methods.

Two features in that list are unusual for a remote sensing package. The self-organised map step for sample quality control addresses a real problem in this field, where a handful of mislabelled pixels in a training set can dominate the error. The uncertainty estimation step, which comes after classification and smoothing rather than being folded into the model, gives you a per-pixel confidence to reason about rather than a single accuracy figure for the whole map.

The package is developed by the e-sensing group, and the documentation is an e-book titled Satellite Image Time Series Analysis on Earth Observation Data Cubes, with function reference in pkgdown format. The project is GPL-2.0 licensed, carries a stable lifecycle badge, and has passed rOpenSci software peer review. The last push was on 2026-10-16, and the recent releases are v1.5.3-1 from 2025-09-08, v1.5.3-2 from 2025-12-18 and v1.5.4 from 2026-01-14.

Installing the R package and the Python wrapper

The R package is the core, and the Python interface is a wrapper around it, so the R version has to exist first.

From CRAN, after installing the latest version of R:

install.packages("sits", dependencies = TRUE)

The latest supported version is also on GitHub, and the documentation notes it may have additional fixes over the CRAN version:

devtools::install_github("e-sensing/sits", dependencies = TRUE)

Loading the library prints the banner that tells you which version you actually have:

# load the sits library
library(sits)
#> SITS - satellite image time series analysis.
#> Loaded sits v1.5.4.
#>         See ?sits for help, citation("sits") for use in publication.
#>         Documentation avaliable in https://e-sensing.github.io/sitsbook/

That banner is worth reading rather than scrolling past, because the version line tells you which collection list applies. The catalogue of accessible collections is versioned, and the one documented for sits 1.5.4 is the list you will see if you install from CRAN at that release.

The Python side is a separate install on PyPi, and it needs Python 3.10 or higher:

pip install pysits

One extra step is required on the R side for the Python path to work. After installing the R version of sits, the documentation says to also install the arrow R package. That is the columnar data bridge that the wrapper uses to move arrays between the R process and Python, and it is the reason the wrapper is described as a wrapper rather than a rewrite. The trade is worth naming: you get the full feature set from one implementation, at the cost of running two runtimes and paying a process boundary on data transfer.

For deep learning work the torch package is already a dependency, and it detects available GPUs and uses them where present, with no extra configuration in most cases.

The ten image collections sits can read

sits builds cubes from analysis-ready data, and the catalogue of providers is the practical constraint on what you can do with it.

The list in the documentation for version 1.5.4 covers Brazil Data Cube, with open collections of Sentinel-2, Landsat-8 and CBERS-4. Copernicus Data Space Environment, with open collections from the EU Copernicus programme. Earth on AWS, with Sentinel-2 and 2A level 2A collections. Digital Earth Africa, with Sentinel-2 and 2A and Landsat-8 for Africa. Digital Earth Australia, with open collections for the Australian subcontinent. Microsoft Planetary Computer, with Sentinel-2 and 2A and Landsat-8. NASA Harmonized Landsat/Sentinel Collection. The Open Geo Hub Harmonized Landsat-5/7/8 collection. Swiss Data Cube, with Sentinel-2 and 2A and Landsat-8. And USGS, with Landsat-4, 5, 7 and 8 collections, which the documentation notes are not open data.

That last point is the one to plan around. Every other entry is open, and the documentation states that open data collections do not require payment of access fees, with the Brazil Data Cube collections also carrying that property, while the USGS Landsat collections sit outside it. The topics attached to the project name the data sources too, with landsat, sentinel-2, cbers and stac-catalog, so the package is built around STAC-style access to already-processed imagery.

The consequence is that sits does not do radiometric processing. It is not a tool for turning raw scene downloads into surface reflectance. It starts from analysis-ready data, which means the collection definitions, cloud masking and resampling have already been decided by whichever provider published them. That is a real saving of effort, and it is also a real constraint: two providers will not produce identical inputs for the same area, and the documentation says to follow the SITS book examples for how the Python interface is used rather than assuming the R and Python call patterns are interchangeable.

The demo scripts that show what the package actually does

The repository ships four demo scripts in the demo/ directory, and they are a better guide to the API than the function list, because each one is a complete analysis rather than a fragment.

There is classify_cbers_bdc.R, which works with the CBERS imagery in the Brazil Data Cube, and classify_deeplearning.R, which covers the deep learning path. Then there are two comparison scripts, dl_comparison.R and ml_comparison.R, which sit side by side and are the most interesting of the set for anyone deciding how to spend their compute.

A deep learning versus machine learning comparison is the decision every practitioner with a labelled time series has to make, because the two approaches fail differently. A conventional classifier on a time series typically works well with limited labels and gives you a model you can inspect. A sequence model over the same data wants more labels and buys you the ability to use the temporal shape of the signal rather than treating each pixel independently. The demos exist to let you run both on your own data and compare, which is the only way to find out which side of that trade your label budget puts you on.

There is also an inst/ directory and a data/ directory in the package layout, along with the standard R package structure of R/, src/, man/, tests/ and a NAMESPACE file. The presence of src/ means there is compiled code in the package rather than pure R, and the demo/00Index file is the index that the R console lists when you call demo() on the package, so the demos are reachable from inside R without opening the files yourself.

For a package with this much surface area, that the demos and the e-book exist is the difference between a research codebase and something a second lab can pick up.

Where sits is the wrong choice

The first limit is that it starts from analysis-ready data. If your research question involves raw radiometry, atmospheric correction, cloud masking choices, or a specific resampling method, that work is not in sits. It is in whatever pipeline produced the collections, and sits inherits their decisions without letting you revisit them. For a study that needs one specific atmospheric correction across a long archive, that is a problem the package does not solve.

The second is the cost of the cube. A regular data cube over a region and a date range is large, and sits is designed to hold and process it in memory with GPU help for the deep learning steps. The documentation does not describe a distributed or out-of-core mode, so the practical unit of work is a cube that fits on one machine. A continental or multi-year analysis is a planning problem, not just a compute one.

The third is the Python API's nature. pysits wraps the R implementation, which means the R runtime is a hard dependency and the arrow package is the transport between the two. That is a reasonable design for one implementation of a complex pipeline, and it also means the two APIs are not identical, which the documentation implicitly acknowledges by pointing Python users at the SITS book examples. If your team would rather have a native Python implementation, this is not that.

The fourth is data cost. Most of the collections are open, but the documentation flags the USGS Landsat collections as not open, and network egress and request volume against cloud catalogs are not free in time even when the data is.

Compare that with the general-purpose earth observation stacks. A cloud-native pipeline built directly on STAC and a deep learning framework gives you full control over preprocessing and scaling, and you carry the burden of building the time series handling, the sample extraction, the smoothing and the accuracy assessment yourself. sits trades that control for a coherent, reviewed and documented workflow with a stable lifecycle badge, which is the right trade when the goal is a reproducible classification map and the wrong one when the goal is a new preprocessing method.

Licence, releases and what to check before you build your first cube

sits is released under GPL-2.0, with the licence file in the repository root, which is the same copyleft family the other geospatial R packages tend to use. For an academic or government analysis team this is usually unproblematic, but if you intend to embed sits in a commercial product or a hosted service, the copyleft terms need to be settled before you build on it, and that is a question for whoever handles licensing where you work rather than for this page.

The project is a proper R package with a DESCRIPTION file, a NAMESPACE, man pages, a NEWS.md, tests, a codemeta.json and a pkgdown site, and it has a CRAN status badge, an R-CMD-check workflow, a Codecov badge and a documented rOpenSci peer review status. The lifecycle badge reads stable, which is the maintainers' own signal that the API is not going to move under you.

The release cadence is quarterly rather than weekly. The tags are v1.5.3-1 from 2025-09-08, v1.5.3-2 from 2025-12-18 and v1.5.4 from 2026-01-14, and the last push was on 2026-10-16, so the tree is ahead of the newest tag. The two-part version numbers in that sequence are the usual R convention for a patch release that has a dependency change, which is worth noticing if you pin versions in a reproducible environment.

What to check before you build your first cube is short. Confirm that one of the ten collections covers your study area with the time range you need, because a region served only by an African or Australian provider will not work for a European transect. Decide whether you want the CRAN release or the GitHub version, since the documentation says the GitHub version may carry additional fixes, and your reproducible environment should name one of them explicitly rather than whichever you happened to install.

Then set up GPU support before you reach the deep learning steps, since torch detects the hardware without configuration and the difference in training time is large. And if you plan to drive the package from Python, install the arrow R package alongside sits and work through the e-book examples, so that the wrapper's data transfer behaviour is something you have seen rather than something you have assumed.

Editorial conclusion

sits fits a remote sensing analyst who already works with analysis-ready imagery and wants a single package that covers cube construction, sample extraction, model training and accuracy assessment, and it fits a Python team that needs the same pipeline through the pysits wrapper. It does not fit someone who needs raw satellite processing, since the collections it reads are analysis-ready products from existing catalogs, and it does not fit a workstation with no GPU if you plan to train deep learning models, since the torch dependency is where the speed comes from. Before you start, pick the collection whose coverage matches your study area from the list of ten providers, install the arrow R package alongside the R version of sits, and read the e-book examples for the Python interface rather than assuming the two APIs are identical.

Frequently asked questions

Official sources

1. e-sensing/sits on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases