Raster Vision: A Geospatial Deep Learning Pipeline You Configure, Not Rewrite
An open source library and framework for deep learning on satellite and aerial imagery.
At a glance
- What is it?
- Raster Vision wraps chip classification, object detection and semantic segmentation for satellite and aerial imagery into a configurable pipeline that handles georeferenced reads, chipping, training, prediction and packaging. The judgement: it earns its place when your bottleneck is geospatial plumbing, not model architecture.
- Who is it for?
- Adopt Raster Vision if your team has georeferenced imagery and labels but no appetite for rebuilding chipping, geospatial IO and prediction packaging around a PyTorch model, and if the three built-in tasks (chip classification, object detection, semantic segmentation) match your problem. Do not adopt it if you need a task outside those three, or if you want to hand-tune a novel architecture end to end.
- Can I use it commercially?
- Yes. Apache-2.0 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 103 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 Geospatial Plumbing Problem Raster Vision Targets
Training a segmentation model on satellite imagery is not the hard part. The hard part is everything around the model: reading GeoTIFFs and other geo-referenced rasters, aligning labels to pixels, cutting large scenes into chips at a workable resolution, running inference across a scene larger than GPU memory, and writing predictions back out with the same coordinate reference system they came in with. Most teams write that layer themselves, once, badly, and then maintain it forever.
Raster Vision's pitch is that this layer is the product. The README describes it as an open source Python library and framework for building computer vision models on satellite, aerial, and other large imagery sets, including oblique drone imagery. The library half provides utilities for reading geo-referenced data, training models, making predictions, and writing out predictions in geo-referenced formats. The framework half lets users who are not deep learning experts configure an experiment as a pipeline of stages.
The intended audience splits cleanly. Non-developers, per the README, may find it easiest to use Raster Vision as a low-code framework where the user only has to configure a few parameters. Developers get the library surface plus the option to combine Raster Vision with their own code. Both groups share the same underlying machinery, which is the point: the low-code path is not a separate, weaker product.
Chips, Scenes and Labels: The Data Model Behind the Pipeline
The pipeline stages named in the README are the clearest statement of the architecture: analyzing training data, creating training chips, training models, creating predictions, evaluating models, and bundling the model files and configuration for easy deployment.
That ordering matters. The analyze stage runs before any training and inspects the training data, which is where label statistics and class distribution get computed. Chipping then cuts scenes into fixed-size training samples. Training produces model files. Prediction runs the model over full scenes and stitches results back into geo-referenced outputs. Evaluation scores predictions against ground truth. Bundling collects model files and configuration into something deployable.
Three task types sit on top of this pipeline: chip classification, object detection and semantic segmentation, with backends using PyTorch. The README's own figure shows examples of all three. The task type is a configuration choice, not a code fork, which is what allows the same pipeline shape to serve a building-footprint segmentation problem and a vehicle-detection problem.
The design trade-off is visible here. Because chipping, prediction stitching and evaluation are framework-owned, you inherit Raster Vision's decisions about chip size, stride and how predictions are merged at chip boundaries. The documentation covers these as configuration, but the pipeline shape itself is fixed. If your method needs a training loop that interleaves scene-level and chip-level passes, you are working against the framework rather than with it.
Getting It Running: pip, Docker and the Dev Environment
The README gives three installation routes. The shortest is pip:
pip install rastervision
Pre-built Docker images are published to quay.io under the azavea/raster-vision repository. The tagging scheme is worth reading carefully because it affects reproducibility. A new tag is published per merge into master, tagged with the first 7 characters of the commit hash. Git tags are also published, using the GitHub tag name as the Docker tag suffix. The README points to the latest suffix, for example rastervision:pytorch-latest, for the most recent build.
Building from source means cloning the repo, then running docker/build, then running the container with docker/run.
For development, the README lists a different path: clone the repo, create and activate a Python virtual environment using whichever manager you prefer (it names mamba, uv and pyenv as examples), then run scripts/setup_dev_env.sh, which installs all Raster Vision plugins in editable mode along with dependencies.
That last point is easy to miss. Raster Vision ships as a set of plugins, and the dev script installs them all in editable mode. If you are working against the library rather than the framework, the plugin boundaries are where you would hook in custom behavior. The README does not enumerate the plugins, so consult the Setup documentation before assuming a single pip install gives you the same surface as a source checkout.
Cloud Execution via AWS Batch and SageMaker
Raster Vision has built-in support for running experiments in the cloud using AWS Batch and AWS SageMaker, with the README linking to the setup documentation for both. This is a real differentiator for the target workload. Training on large imagery sets means large chip datasets, and the gap between a laptop and a machine with enough GPU memory and disk throughput is where geospatial projects stall.
The README does not describe the mechanics of the AWS integration beyond the two service names and the documentation links. It does not state how credentials are supplied, how data is staged into S3, or how job configuration maps onto the pipeline stages. Treat the two names as pointers to the setup docs rather than as a description of how the integration behaves in practice.
The honest framing: the cloud support is a first-class part of the product's positioning, but the README treats it as a documentation pointer. If your deployment target is not AWS, this section of the feature set does not apply to you, and the pipeline still runs locally, just with the resource ceiling that implies.
Where Raster Vision Is the Wrong Tool
The three built-in tasks are the boundary. Chip classification, object detection and semantic segmentation cover a lot of remote sensing work, but they are a fixed set. A problem that does not reduce to one of them, such as instance-level tracking across a time series or a generative task, has no configured path through the pipeline.
The second limitation is architectural. The framework is opinionated about the pipeline shape: analyze, chip, train, predict, evaluate, bundle. That is a strength for repeatability and a constraint for research. If your contribution is a training procedure that does not fit a chip-in, prediction-out model, the framework's stages become scaffolding you fight rather than use.
The third is the low-code framing itself. The README says the framework is for users who do not need to be experts in deep learning, and that they only have to configure a few parameters. That is true up to the point where results are bad. Diagnosing why a segmentation model underperforms on a particular sensor still requires understanding the model, the chipping strategy and the label quality. Configuration removes the code, not the expertise.
Finally, note the release cadence visible in the material: the most recent tagged release is v0.31.1 from August 2024, while the last push to the repository is June 2026. Development activity and tagged releases are not the same signal, and anyone pinning a version should check the release notes rather than assume the tag reflects current master.
How This Differs from a Plain PyTorch Segmentation Pipeline
The obvious alternative is building directly on PyTorch with a geospatial IO library such as rasterio for reads and writes. That path gives you total control over the model, the loss, the augmentation and the training loop. It also means you own chipping, prediction stitching, georeferenced output writing, evaluation and packaging. For a single experiment that is a few hundred lines. For a repeatable workflow across multiple scenes and sensors, it is the layer Raster Vision already implements.
The difference in approach is where the abstraction sits. A plain PyTorch pipeline abstracts at the model. Raster Vision abstracts at the pipeline, and the model is one configurable stage inside it. That means you get less freedom over the training loop and more consistency across experiments, plus the analyze and bundle stages that a hand-rolled pipeline typically lacks.
A second comparison point is the low-code configuration surface. Tools that require you to write Python to define every experiment put the repeatability burden on your own code discipline. Raster Vision's configuration is the experiment definition, which makes runs comparable by construction. The cost is that anything not expressible in configuration requires dropping into the library, and the README does not draw a clear line between what configuration can and cannot express. That line is in the documentation, not the README.
Licence, Dependencies and the Cost of Staying Current
Raster Vision is licensed under Apache 2.0, and the README links to the licence file in the repository. Apache 2.0 is a permissive licence with an explicit patent grant, which matters for commercial geospatial deployments where patent exposure is a real consideration. The README also points to THIRD_PARTY_LICENSES.txt, which lists third party licences for all dependencies used by Raster Vision. That file is where you check whether the PyTorch stack and the geospatial dependencies pull in anything with terms you cannot accept. This is not legal advice; read the licence files yourself or have counsel do it.
On maintenance cost, the material supports a few concrete observations. The project publishes a Docker tag per merge into master, so the latest tag moves frequently. Anyone deploying from rastervision:pytorch-latest is tracking master by definition, which is convenient and not reproducible. Pinning to a Git tag suffix is the alternative the README describes, and it is the one to use for anything that needs to be rebuilt identically later.
The contributor process requires signing a Contributor License Agreement, per the README, and the maintainers ask to be contacted before larger features or design changes are started. If your team plans to fork or upstream changes, that conversation happens before the work, not after. The practical upgrade cost is the usual one for a framework with plugins: a version bump can move the plugin boundaries, and the dev setup script installs all plugins in editable mode, so a source checkout couples you to the plugin layout of the version you cloned.
Editorial conclusion
Adopt Raster Vision if your team has georeferenced imagery and labels but no appetite for rebuilding chipping, geospatial IO and prediction packaging around a PyTorch model, and if the three built-in tasks (chip classification, object detection, semantic segmentation) match your problem. Do not adopt it if you need a task outside those three, or if you want to hand-tune a novel architecture end to end. Before committing, verify two things: that you can install and run the Quickstart configuration against your own imagery, and that your label format is one the data analysis stage accepts. The repository is active (last push June 2026) but the most recent tagged release is v0.31.1 from August 2024, so check whether master is where the work is happening before pinning a version.
Community notes