Portolan and the Quiet Reinvention of Spatial Data Infrastructure

For years, anyone who worked with geospatial data learned to live with a certain amount of pain. Publishing a dataset meant standing up servers, maintaining databases, babysitting APIs, and hoping the whole thing held together when traffic spiked. Using that data meant navigating portals, dealing with pagination limits, and wrestling with tools that never quite agreed on how spatial files should behave. It was the cost of doing business in a world where spatial data could not be queried efficiently over the network.

That world is fading. The cloud‑native geospatial community has spent the last several years proving that spatial data doesn't need to be served through heavy infrastructure. It can simply live in object storage. It can be organized with open metadata. It can be accessed directly by standard tools. It can be used by people and by generative models without a middle layer that slows everything down.

This is the context in which Portolan arrives. It's an open‑source specification and toolkit for building a serverless spatial data infrastructure (SDI). It is not a new file format or a new portal. It is a set of clear, opinionated rules for how to publish geospatial data in a way that is fast, predictable, and easy to use. It is also a validator, a CLI, and a set of skills that help publishers create catalogs that follow the specification.

Portolan is an open‑source community project supported by Radiant Earth, CARTO, Planet, Taylor Geospatial, Source Cooperative, and walkthru.earth, with contributions from PDOK, Madrid, Barcelona, and Pergamino.

The Portolan announcement makes one thing very clear. A modern SDI can be nothing more than files in S3‑compatible storage. No servers. No databases. No custom APIs. Just cloud‑optimized formats, STAC metadata, and documentation that helps people and generative models understand how to work with the data.

What Portolan actually standardizes
Portolan builds on existing standards rather than inventing new ones. GeoParquet and PMTiles handle vector data. COG handles raster. Future support is planned for Zarr and COPC. STAC provides the organizational backbone. Every catalog must include a README and an AGENTS.md file so that both humans and generative models can understand what the data contains and how it should be used.

This is not a loose suggestion. Portolan is deliberately opinionated. It tells publishers how to structure bounding boxes, how to order spatial data, how to configure CORS, and how to avoid the subtle mistakes that make cloud‑optimized formats slow or unusable. The validator, rashid, checks catalogs against the specification and produces JSON that makes it easy to identify and fix problems.

The result is a consistent experience. If you open a Portolan catalog, you know what you are getting. You know how the metadata is organized. You know how to query the data. You know that the publisher followed best practices. You know that the catalog will work with QGIS, ArcGIS, DuckDB, Python, and any other tool that understands cloud‑optimized formats.

Why this matters for publishers
The traditional SDI model forces publishers to maintain infrastructure that exists only to stand between users and the data. Portolan removes that layer. If a dataset is read‑heavy and public, there is no reason to maintain a server whose only job is to serve bytes that object storage can serve directly.

This shift changes the economics of geospatial publishing. National geoportals and planetary archives can rely on object storage rather than maintaining a serving layer sized for peak demand. That cuts recurring costs down to storage and transfer. It also makes it practical to host terabytes or even petabytes of data without running a dedicated geospatial service. The Fields of the World dataset is a good example. It is published as a Portolan catalog containing 369 TB of data and served more than 100 TB in a single month. There is no serving layer in front of it.

At the other end of the spectrum, small organizations finally get a way to publish spatial data without standing up GeoServer or Esri infrastructure. A Portolan catalog is just files in a bucket. That lowers the barrier for city governments, NGOs, researchers, and anyone who wants to share useful geospatial data without becoming a systems administrator. It also gives publishers flexibility to meet sovereignty requirements because the data can live in any S3‑compatible storage in any jurisdiction.

Why this matters for users
Portolan catalogs use formats that already work with common tools. They also include the metadata and documentation needed to understand the data. The registry provides a single place to discover public catalogs. Because the catalogs are built from existing standards, users do not need Portolan‑specific tools. They can explore the data in the Portolan browser, query it from QGIS or ArcGIS, load it into DuckDB, or hand it to a generative model.

The experience is faster and more consistent than navigating multiple portals or dealing with API pagination. It also reduces the expertise required to get started. Users can focus on asking questions rather than learning the quirks of several systems. Generative models can take on the intermediate work, which broadens access for new users and lets experienced practitioners work across far more data than they could manage manually.

A federated future
The long‑term vision is a federated network of interoperable catalogs published by national mapping agencies, cities, NGOs, researchers, and global data providers. The Portolan registry is the first step. It is nothing more than a catalog of catalogs. The underlying bytes never leave the publisher’s storage. If the registry disappeared, every catalog would keep working.

This is a quiet but profound shift. Discovery becomes easier. Interoperability becomes normal. People and generative models can begin with nothing more than the registry URL and find relevant datasets across many publishers. They can understand how the data is structured and query it directly from the source. The network has already started to take shape with catalogs spanning global datasets, national government data, and community mirrors.

Where Portolan goes next
Portolan is still early stage. The team is focused on polishing the specification, building out the core tooling, and learning from real‑world catalogs. Breaking changes are expected in the short term, so the project is best suited to early adopters. The roadmap outlines the work ahead. The registry will continue to grow. Stability in the specification and tooling will become a key milestone. Eventually, the ecosystem will expand beyond the tools built by the Portolan team.

I will be exploring parts of this framework in some of my own upcoming data pipeline work. Anyone can get involved, to publish data as Portolan catalogs, test the tooling, or contribute to the specification. Portolan has a Slack channel and a Google Group. The specification, documentation, examples, registry, and catalogs are at:

https://portolan-sdi.org
https://github.com/portolan-sdi

It is rare to see a project that simplifies geospatial publishing this much while staying grounded in open standards. Portolan does not try to replace the tools people already use. It tries to make those tools work better by giving them a consistent, cloud‑native foundation. If it succeeds, it will quietly reshape how spatial data is published, discovered, and used.