Sean Gillies (Posts about work)

Kyle Kingsbury's bullshit about bullshit machines

Sean Gillies — Sun, 03 May 2026 17:22:43 GMT

You've probably seen links to "The Future of Everything is Lies, I Guess" already. I've just finished the last installment. This is an excellent series of posts with many references. If we meet to talk about the industry, I'm almost certainly going to ask if you've read it.

This is bullshit about bullshit machines, and I mean it. It is neither balanced nor complete: others have covered ecological and intellectual property issues better than I could, and there is no shortage of boosterism online. Instead, I am trying to fill in the negative spaces in the discourse. “AI” is also a fractal territory; there are many places where I flatten complex stories in service of pithy polemic. I am not trying to make nuanced, accurate predictions, but to trace the potential risks and benefits at play.

I've already come to some of the same conclusions, so I admit to confirmation bias.

Laid off

Sean Gillies — Sat, 25 Apr 2026 00:39:42 GMT

Welp, I'm joining the ranks of the unemployed tech workers again.

As before, I'm in a good situation. I don't depend on my former employer for health insurance. I've got some severance and savings, my family is in good health, we have a roof over our heads, and I have good connections. I don't feel afraid.

But maybe I should? The job market is worse than last time this happened to me. I've seen experienced and talented people go for weeks and months without offers, and read some harrowing stories about what under-employment looks like for older tech workers these days.

After a little detour into the biomedical field, I'm looking to get back into helping to solve important geospatial problems. If you've got them, please let me know.

Station identification

Sean Gillies — Fri, 24 Apr 2026 02:10:30 GMT

Email me with questions or comments on any of my posts: sean.gillies@gmail.com.

Update: I'm currently looking for work in the geospatial field, remote or in Colorado. Please check out my CV.

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!

Station Identification

Sean Gillies — Mon, 12 Jan 2026 02:40:49 GMT

Hello, my name is Sean Gillies, and this is my blog. I write about running, cooking and eating, gardening, travel, family, programming, Python, API design, geography, geographic data formats and protocols, open source, and internet standards. Mostly running and local geography. Fort Collins, Colorado, is my home. I work at TileDB, which sells a multimodal data platform for genomics and precision medicine. I appreciate emailed comments on my posts. You can find my address in the "about" page linked at the top of this page. Happy New Year!

Snow-covered cones, craters, and lava flows of Craters of the Moon National Monument in Idaho, viewed from an airliner traveling between Denver and Seattle on February 21, 2025.

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.

Leaving the GDAL Project Steering Commitee

Sean Gillies — Thu, 18 Sep 2025 02:19:59 GMT

I've been on the Project Steering Committee (PSC) of the GDAL project for a few years now. It's a hugely significant software project, one that I'm very fond of, and I like to think that I've had an impact in my time on the committee.

Recently, though, the steering part has become less rewarding. By granting Amazon S3 and its imitators special, featured storage protocols, GDAL is stuck carrying water for big and lucrative cloud service providers and a few hyper-scaling customers that don't adequately support the project. It's a crappy situation, not unique to GDAL. A lot of open source projects find themselves ruthlessly exploited these days. This is my personal view. I don't speak for GDAL.

More importantly, I'm doing less geospatial work these days, and thus I'm increasingly uncertain about the rapidly-changing currents in which the PSC is steering the project. Do things like "GeoParquet" and "GeoArrow" really matter to practitioners who aren't working for a handful of hyper-scaling organizations? Is "GeoAI" for real or is it bullshit? Do we steer the project towards these interests or away from them? I truly don't know. I wish I did.

Can I fully engage with the problems that GDAL faces over the next year? That's my criteria for participating in the PSC. I can't, and so it's time to go. The project is in good shape, I believe, and I hope that I'm making room for someone with a great vision to join it.

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

A new CLI for GDAL

Sean Gillies — Sat, 09 Nov 2024 16:54:35 GMT

Even Rouault has proposed a new, modern, and more coherent command line interface (CLI) for the GDAL/OGR project. I think it's a good idea and a good time to do it. I've wanted a better one for about 15 years. Even credits Rasterio for inspiration, and that's gratifying to see. I started writing Rasterio 10 years ago in part because I wanted a better CLI for GDAL.

What I wanted in a GDAL CLI were the following features:

A root command and a few subcommands, one namespace for everything.
Uniform arguments and options with predictable ordering and naming.
Good documentation of arguments and options.
More subcommands with fewer options each. Making gdal_translate into 3-4 commands, for example.
Input and output that favor stdin/stdout and JSON.
Ease of installation. For example, with pip instead of an OS package manager.

I estimated in 2013-2014 that it was not feasible for me to achieve those goals within the GDAL project itself. GDAL and its community had no funding for this kind of work at the time. I found the GDAL project's tests somewhat inscrutable and frustrating. A hefty legacy of documentation and folk wisdom about the old ways would have to be updated. Mostly by me, certainly. And the GDAL user community largely did not care. Free software that was fast and effective (and, most of all, free!) was already more than most people had dreamed of. A GIS analyst had so many business and organizational problems to deal with already that the rough edges of gdalinfo and gdal_translate didn't even crack her top 20. Software polish wasn't a big concern in the second decade of FOSS4G. I think it's still a hard thing to sell. Individual consumers will pay money for slick, well-designed software that makes them feel good. Organizations value polish less. And neither GDAL nor Rasterio sell anything to individual consumers.

Overhauling gdal_translate, ogr2ogr, and friends within the GDAL project looked like a non-starter to me. Pushing a herd of boulders up a hill, by myself, for free, for a community that was largely content with working around and stepping over these boulders. I think I made the right choice for myself. I got to start from scratch, move fast, and use a modern CLI framework. I made a command line interface for Rasterio that, while not perfect, met most of my goals. And I didn't go broke or burn out while doing it.

Today, thanks to years of fundraising work by Howard Butler, Paul Ramsey, Kristian Evers, and Even, the GDAL project does have funding to overhaul its command line interface as an aspect of overall project health and maintenance. Multiple developers can be paid to work on it. They won't have to donate their time to it as I would have. Rasterio's command line interface can't be adopted by GDAL, or be forked to become GDAL's because it doesn't have all the features of existing GDAL programs (or even of gdal_translate and ogr2ogr for that matter), and my decision to have more subcommands with fewer options is kind of against the grain of GDAL. But the new GDAL CLI can adopt the demonstrably useful features and design of Rasterio's. JSON output, for example, is something that GDAL has already picked up from Rasterio.

Rasterio will certainly fade a little if the new GDAL CLI is designed and executed well. But that's in the nature of software and software communities. Rasterio has always depended on GDAL and benefited from being built on a technically solid and well loved foundation. And I didn't invent CLI subcommands and JSON output, not at all. It's not unfair. If you succeed in open source, if you move the needle, you will be emulated. In this case, I think we can call it progress. I'm content.

In the long run, I stand to get half of what I originally wanted from a GDAL CLI, the first three of the six features I listed above. And there's probably still room for a suite of Unix style programs with different opinions and design decisions, especially if it and GDAL agree on basic concepts, arguments, options, and flags.