TorchGeo: a PyTorch domain library for geospatial data
TorchGeo: datasets, samplers, transforms, and pre-trained models for geospatial data
At a glance
- What is it?
- TorchGeo packages geospatial datasets, coordinate-aware samplers, transforms and pre-trained models behind the familiar torchvision-style API. It is aimed at two groups at once: machine learning practitioners who have never touched a CRS, and remote sensing specialists who have never touched a DataLoader.
- Who is it for?
- Adopt TorchGeo if your pipeline is already PyTorch and your imagery spans more than one sensor, CRS or resolution, because the set algebra over GeoDataset is the part you would otherwise write yourself and get wrong. Do not adopt it if you need a training framework rather than a data layer, or if your data is a single already-tiled GeoTIFF with one CRS.
- Can I use it commercially?
- Yes. MIT 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 6 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 problem TorchGeo addresses: misaligned rasters and hand-written glue
Geospatial imagery does not arrive in a convenient shape. The README states that geospatial imagery is often multispectral with a different number of spectral bands and spatial resolution for every satellite, and that each file may be in a different coordinate reference system, requiring reprojection into a matching CRS. A machine learning practitioner who has only worked with JPEG folders will not have a mental model for any of this. A remote sensing specialist who has only worked with GDAL and QGIS will have the mental model but not the DataLoader plumbing. TorchGeo is explicitly positioned at the overlap: the stated goal is to make it simple for machine learning experts to work with geospatial data, and for remote sensing experts to explore machine learning solutions. The library is a PyTorch domain library, described in the README as similar to torchvision, which tells you the intended scope. It is a data and model layer, not a training framework. The four things it supplies are named in the repository description: datasets, samplers, transforms and pre-trained models.
GeoDataset set algebra and how CRS alignment is handled
The central abstraction is the GeoDataset, described in the documentation as a dataset with geographic metadata. The README example builds one by combining two Landsat collections. Landsat7 and Landsat8 are constructed with explicit band lists, and because Landsat 8 has more spectral bands than Landsat 7, the example keeps only the bands the two share. The two datasets are then merged with the | operator, which the README describes as taking the union. The result is intersected with the Cropland Data Layer using the & operator. The README explains the choice directly: the intersection is used rather than the union so that sampling only happens in regions that have both Landsat and CDL data. That is the mechanism worth understanding. You are not concatenating file lists. You are composing spatial coverage, and the library resolves the coordinate systems underneath. The README states that each dataset may contain files in different coordinate reference systems or resolutions, and that TorchGeo automatically ensures a matching CRS and resolution is used. The same example shows CDL being constructed with download=True and checksum=True, so automatic download and checksum verification are available for at least some datasets. What the README does not describe is how reprojection is implemented or what resampling kernel is used when resolutions differ. If you care about radiometric fidelity across sensors, that is a question for the API documentation, not the README.
Samplers exist because a CDL image covers the continental United States
The README makes the case for samplers with a concrete number: the CDL dataset consists of a single image covering the entire continental United States. You cannot index that like a list of 32x32 images. TorchGeo therefore defines samplers that return patches by geospatial coordinate. The example instantiates RandomPatchSampler with size=256 and length=10000, then wraps the dataset in a standard torch.utils.data.DataLoader with batch_size=128 and a custom collation function, stack_samples. Two details matter here. First, length is a sampler argument, not a dataset length, so an epoch is however many patches you declare rather than a fixed property of the data. Second, the collate_fn is not optional in this example: samples come back as dictionaries, and stack_samples is what turns a list of those dictionaries into a mini-batch. If you drop that argument and use the default collation, you will get a list of dicts instead of stacked tensors. The README mentions that TorchGeo defines a number of samplers, so RandomPatchSampler is one option among several, but the material here only documents that one. Patch size and sample count are the two knobs shown; anything about overlap, stride or spatial balancing is outside what the README covers.
Installing TorchGeo and the imports a first script needs
Installation is a single command. The README gives pip install torchgeo as the recommended route, and uv add torchgeo as the alternative for uv users. Conda and spack are supported but the README defers to the documentation page at docs.torchgeo.org under user/installation.html rather than reproducing the commands. The example script imports from four separate namespaces, which is a useful map of the library's surface. Datasets and the stack_samples collation function come from torchgeo.datasets, with CDL, Landsat7, Landsat8 and VHR10 named in the import line. Samplers come from torchgeo.samplers. Task wrappers come from torchgeo.tasks, with SemanticSegmentation shown. Data modules come from torchgeo.datamodules, with InriaAerialImageLabelingDataModule shown, and the example pairs that with lightning.pytorch.Trainer. That last import is the one to notice. PyTorch Lightning is not a TorchGeo dependency you can ignore if you want the datamodule and Trainer path; it appears in the README's own example. The dataset constructors take a paths argument, so you point them at imagery you have already downloaded unless the dataset class supports download=True. The README's Landsat example assumes the user has Landsat 7 and 8 imagery downloaded, while the CDL example enables download. That inconsistency is real and worth planning around: some datasets fetch themselves, others expect you to have the files.
Where TorchGeo stops being the right tool
The README's own framing sets the boundary. TorchGeo is a domain library in the torchvision sense, and torchvision does not train models for you. If you need experiment tracking, distributed launch configuration, checkpoint management or hyperparameter search, none of that is in the four things this library supplies. The datamodules are the closest thing to a training entry point, and they lean on PyTorch Lightning to do the work. A second limitation is dataset coverage versus dataset fit. The library provides dataset classes for named collections with known layouts, and the README shows CDL, Landsat7, Landsat8 and VHR10. If your imagery is a proprietary archive with its own tiling scheme, you are writing a GeoDataset subclass, and the value you get is the CRS and resolution reconciliation plus the samplers, not the loaders. A third boundary is the one the README does not discuss: there is no stated guidance here about what happens when a dataset's files are partially missing or when a checksum fails, beyond the fact that checksum=True is available. If your ingestion pipeline is unreliable, verify that behaviour before you build on it. Finally, if your data is already a single cloud-optimized GeoTIFF in one CRS with one resolution, the set algebra has nothing to reconcile and you are paying the abstraction cost for samplers alone.
How this differs from GDAL-based and generic PyTorch pipelines
The obvious comparison is rasterio and GDAL, the libraries most geospatial Python is built on. The difference is where the abstraction sits. GDAL gives you a dataset handle, a transform and a band array, and leaves batching, sampling, augmentation and model input shape entirely to you. TorchGeo assumes you want a torch.utils.data.DataLoader at the end and works backwards from there, which is why the samplers and the collation function exist as first-class pieces. The second comparison is plain torchvision. A torchvision pipeline assumes images are independent files with consistent channels and no coordinate system. TorchGeo's GeoDataset exists precisely because those assumptions fail on satellite imagery. The README's Landsat-plus-CDL example is the clearest statement of the gap: two sources, different band counts, different CRS, different resolution, combined with a single operator, then sampled with a coordinate-aware sampler. Rebuilding that on torchvision plus rasterio means writing the reprojection, the intersection of coverage, and the patch sampler yourself. TorchGeo does not replace GDAL so much as sit on top of the geospatial Python stack and present it through PyTorch idioms. If your team already has a mature rasterio pipeline with tested resampling behaviour, the migration cost is the part to weigh, not the feature list.
Release cadence, licence and what upgrading costs
The release history shows a steady rhythm: v0.8.1 in January 2026, v0.9.0 in February 2026, v0.10.0 in August 2026, with the last push to main in September 2026. Two minor releases and a patch inside roughly eight months, and no 1.0. Pre-1.0 versioning means the maintainers reserve the right to change APIs between minor versions, so a v0.9 to v0.10 upgrade is not guaranteed to be a drop-in. The practical cost is not the pip command, it is the surface you touch: dataset class constructor arguments, sampler signatures, and the task and datamodule wrappers. Pin the version in your environment file if you have a training run you need to reproduce, and read the release notes before moving. The licence is MIT, which is permissive and places few conditions on redistribution or modification, but the datasets TorchGeo wraps are a separate matter entirely. CDL, Landsat and VHR10 each carry their own terms from the agencies that publish them, and a permissive library licence says nothing about your right to redistribute the imagery. Check the source of each dataset you enable before shipping anything derived from it. This is not legal advice; it is a note that the MIT licence covers the code in this repository and not the data it downloads.
Editorial conclusion
Adopt TorchGeo if your pipeline is already PyTorch and your imagery spans more than one sensor, CRS or resolution, because the set algebra over GeoDataset is the part you would otherwise write yourself and get wrong. Do not adopt it if you need a training framework rather than a data layer, or if your data is a single already-tiled GeoTIFF with one CRS. Before committing, verify two things against your own files: that the specific dataset class you plan to use matches the directory layout and band names you actually have, and that the sampler you pick produces the patch size and overlap your model expects.
Community notes