Sean Gillies (Posts about python)

Rasterio 1.5.0

Sean Gillies — Wed, 14 Jan 2026 02:59:08 GMT

Version 1.5.0 of your favorite Python library for reading and writing classic GIS raster data is on PyPI now. Since Jan 5, in fact.

Among other new features, this version adds support for 16-bit floating point raster data, and HTTP cache control. Please See the release notes for a full list of bug fixes, new features, and other changes.

Once again, major credit goes to Alan Snow for managing this release. Thanks, Alan!

Rasterio 1.4.4

Sean Gillies — Sat, 13 Dec 2025 03:13:52 GMT

Rasterio 1.4.4 is on PyPI now. The first release in a year and ten days. If you're using Rasterio in 2025, shoot some thanks to Alan Snow, aka @snowman2 on Github. He's leading the effort to get Rasterio caught up to recent GDAL and Python changes, and it's not a cakewalk!

Release notes are here: https://github.com/rasterio/rasterio/releases/tag/1.4.4. That's a lot of bug fixes.

Rasterio 1.4.4rc0

Sean Gillies — Sun, 07 Dec 2025 01:38:37 GMT

I've got good news for people who love news about Rasterio, the Python package for reading and writing classic GIS raster data. Alan Snow is the release manager for 1.4.4 and 1.5.0 and has shepherded a release candidate with 40 wheels and one source distribution onto the Python Package Index: https://pypi.org/project/rasterio/1.4.4rc0/. The release notes are here.

Please try these out and let us know if they work as expected.

Python typing mulligan

Sean Gillies — Mon, 18 Nov 2024 02:16:36 GMT

This is why I've been hesitant to add type hints to Fiona, Rasterio, and Shapely. David Lord on missteps and misgivings:

I want a "start over" tool for type annotating a Python library. I started with Flask as untyped code, then added annotations until mypy stopped complaining. But this didn't mean the annotations were _correct_. Over time I've fixed various reported issues. I feel like if I could start from scratch again, I'd probably get closer to correct with the experience I've gained. But removing all existing annotations and ignores is too time consuming on its own. #python

Use pytest's tmp_path fixture

Sean Gillies — Tue, 05 Nov 2024 23:56:14 GMT

If you're not already using pytest's tmp_path fixture, you really should. The fixture provides a temporary directory for testing use. A directory that you can't reference from other test runs or from other test functions in the same run, but that isn't immediately deleted when your tests finish. The directory is created in your account temporary location and is eventually cleaned up by your computer's operating system. Until then, you can open the directories and their files in other applications.

I've been making assertions on datasets in Rasterio's tests and also dragging them into QGIS for a closer look after the tests finish.

Fiona 1.10.0

Sean Gillies — Wed, 11 Sep 2024 01:16:41 GMT

I made a software release last Tuesday. One with new features, deprecations, major refactoring, and packaging and dependency changes, not just bug fixes. Fiona 1.10.0 has three main changes: Python openers, CLI filter commands, and new data classes.

Python openers can connect filesystems implemented in Python, like fsspec or tiledb.vfs, to GDAL's own virtual filesystem machinery. In most cases, you should reply on GDAL's built-in virtual filesystem handlers. On the other hand, if you have unique or proprietary data access protocols, then Fiona's new openers may be useful. As far as I know, Fiona (and Rasterio) have the only open source implementations of GDAL's virtual filesystem plugin system. David Hoese had the initial idea, Even Rouault helped a lot, and I got it over the finish line. I think this is right up there with MemoryFile for my favorite feature that didn't exist in Python-GIS software before.

Fiona's CLI has three new commands, filter (strictly speaking, a new mode of this command), map, and reduce. These provide some great features for Unix-style data processing pipelines and are designed to work well with jq and programs of that nature. Think of them as the data processing part of ogr2ogr, split into 3 simpler commands, reading and writing to stdin/stdout by default, with no SQL and no need to know about different SQL dialects. The documentation contains a new tutorial about using filter, map, and reduce. This work began in planetlabs/fio-planet and now lives in the Fiona CLI core. Thank you, Tim Schaub, for stewarding the transition.

Lastly, Fiona now longer represents GIS features (and their geometries and properties) as Python dicts, but as Python classes: fiona.model.Feature, fiona.model.Geometry, and fiona.model.Properties. These classes provide dict-like access for backwards compatibility, but raise warnings when mutated. These data classes will be immutable in version 2.0.

A lot of GIS-Python attention has moved on to columnar data and massive amounts of time series, trajectories, telemetry, etc, using Parquet and Arrow. But, there's still a need to reason about persistent spatial things in our world and their relationships to each other. Classic GIS features, in other words. Watersheds, counties, neighborhoods. That's what Fiona remains concerned about.

New home for Rasterio

Sean Gillies — Tue, 26 Oct 2021 16:02:10 GMT

I've announced the move elsewhere, but have been late to mention it here. Rasterio has been transferred from https://github.com/mapbox to https://github.com/rasterio. Today I transferred the affine project, which rasterio depends on, from my own personal repos to the same rasterio org.

Before I left Mapbox, about 45% of the project's commits were authored by folks outside the company. Now, that number is closer to 90%. Moving the project keeps the code open and accessible to its developers and makes it easier to maintain. Making the case for the move at work was pretty easy. Teams at Mapbox that use rasterio want bug fixes and new releases. The Platform team has one less oddball CI configuration to support. I'm grateful for the attention and help of Mapbox's Legal and IT teams during a busy, busy time. It was fun to work with these folks on one last project.

I'm planning to stay very involved in these projects. Go and try the new 1.3 pre-release and report back if you find any new bugs.

Shapely 1.8.0

Sean Gillies — Tue, 26 Oct 2021 14:29:27 GMT

From the 1.8.0 release notes:

Shapely 1.8.0 is a transitional version. There are a few bug fixes and new features, but it largely exists to warn about the upcoming changes in 2.0.0. See the new migration guide for more details on how to update your code from Shapely 1.8 to 2.0.

One of the upcoming changes: the geometry objects of 2.0 will be immutable, simplifying their implementation, and making it possible to hash them. Here's an example of the warning you'll see when you set a new attribute on a version 1.8 geometry object.

>>> from shapely.geometry import Point
>>> pt = Point(0, 0)
>>> pt.id = 1
<stdin>:1: ShapelyDeprecationWarning: Setting custom attributes on geometry objects is deprecated, and will raise an AttributeError in Shapely 2.0

Shapely 2.0 roadmap

Sean Gillies — Sat, 02 May 2020 22:25:34 GMT

There's going to be a 2.0 version of shapely. Joris Van den Bossche has written an RFC for a roadmap.

Joris is a Pandas and GeoPandas developer. The GeoPandas team has identified some enhancements to shapely that would allow GeoPandas and shapely to reach new levels of performance, and we're going to implement them. A NumFOCUS grant will support some of this work.

I'm super late in blogging about this and commenting on the RFC, which has lead to a little confusion about whether I'm in favor of this. I am, 100 percent. Rewrites aren't easy, but this effort has a lot going for it: serious use cases, committed stakeholders, clever and pragmatic programmers, funding, and lots of goodwill. We're going to have a 2.0 version that removes cruft, adds killer new features, and isn't super difficult to migrate to.

Please read the RFC pull request and comment if you're into helping shape the future of Python's #1 open source GIS geometry package.

pytest.raises excinfo subtlety

Sean Gillies — Tue, 31 Mar 2020 01:45:36 GMT

In the past few weeks I've seen multiple stumbles related to a subtlety of pytest. I'm going to explain how to recognize the issue and what to do about it.

Exceptions are an aspect of a Python package's API, just like the names of the functions, their parameters, and their return types. They also require testing. Pytest provides a handy context manager for this: pytest.raises.

def accept_numbers_lt_3(num):
    if not num < 3:
        raise ValueError("Number is not less than 3")


def test_unaccepted_error():
    with pytest.raises(ValueError):
        accept_numbers_lt_3(3)

That test will pass. The function does raise a ValueError when called with the argument 3.

To make assertions about details of the exception you might try the following.

def test_unaccepted_error_msg():
    with pytest.raises(ValueError) as excinfo:
        accept_numbers_lt_3(3)
        assert str(excinfo.value) == "Number is not less than three"

This test passes too. But wait, we mistyped the expected string. We're asserting that the message ends with "three" and that can't be true, can it? How did this test pass?

Here's the important thing: pytest "magically" changes the interpretation of assert statements, but it doesn't change the behavior of Python's "with" statements. That final assert statement in test_unaccepted_error_msg is never reached. Execution exits from the block when the ValueError (or any other exception) is raised.

The excinfo object has recorded the captured exception so that we can inspect it. We only need to move that assert statement to after the with block.

def test_unaccepted_error_msg():
    with pytest.raises(ValueError) as excinfo:
        accept_numbers_lt_3(3)

    assert str(excinfo.value) == "Number is not less than three"

Now this test will fail, properly. And we can change "three" to "3" and have a passing test of an exception message.

This issue is documented in a note in the pytest.raises docs, but is easy to overlook.