Remote Sensing Labs
Browse all docs

Microsoft Planetary Computer

The Microsoft Planetary Computer is less a dataset than a place to find and read datasets. The Sentinel-2 and Landsat pages cover imagery and the STAC Catalogs page describes how such imagery is discovered; the Planetary Computer combines both: a large, free catalog of open environmental data, described by STAC, over cloud-hosted files you can read in place. It is one prominent example of a broader shift in how geospatial analysis is done — from downloading files to a local machine, to bringing code to data that stays in the cloud. Its history also illustrates a caveat of that shift: the platform once paired the catalog with a free hosted notebook environment, the Planetary Computer Hub, which was retired on 6 June 2024, while the data and APIs continued unchanged. Today you bring your own compute. (Microsoft Planetary Computer Pro is a separate, paid Azure service for building private catalogs, not this open one.) The page treats the platform as an instance of the cloud-native, catalog-over-object-storage pattern rather than as a product to be tutorialized; the reasoning transfers to any platform built the same way.

What the platform provides

Three things come together in a platform like this, and it is their combination that matters. The first is a catalog: a large collection of open datasets — optical and radar imagery, elevation, land cover, climate and environmental layers — described with consistent STAC metadata so they can be discovered with one search pattern rather than a dozen provider-specific ones. The second is hosted, analysis-ready assets: the data is stored in cloud object storage in cloud-native formats, so it can be read directly and in part rather than downloaded whole. The third is access services around them: token-based signing for reading the stored files, and data APIs that render imagery on request. What the platform no longer supplies is general-purpose compute; to get the benefit of computing near the data you run your own machines or cluster in the region where the data is stored. Individually none of these is unique; together they make “find, fetch, process” a short loop, which is what makes the platform useful for prototyping and for work that would be impractical to pull down locally.

Why cloud-native access matters

The reason this model is more than a convenience lies in how the data is stored and read. Cloud-native formats — cloud-optimized rasters and chunked array formats — are organized so a client can request just the region, bands, and resolution it needs without reading the entire file, which the Digital Imagery concept’s notion of pixels-and-bands makes concrete: you fetch the pixels the analysis touches and skip the rest. Paired with lazy loading, where data is read only at the moment it is actually needed, this lets a workflow operate over an area far larger than any one machine’s memory, because it never holds more than the current piece. And when your compute runs in the same region as the storage, the slow step — moving bytes across the network — largely disappears. This is what makes cloud-hosted access attractive for a dense Time Series or a wide-area composite: the same masking-and-compositing logic you would run locally executes against hundreds of scenes without ever downloading them. The assets themselves are still ordinary rasters and vectors — the Raster vs Vector distinction is unchanged — but the way you reach them removes the download bottleneck.

Real constraints

A hosted platform trades some independence for that power, and the constraints are worth naming plainly. Reading most assets requires signing, the mechanism the STAC Catalogs page explains; here it takes the form of short-lived shared access signature (SAS) tokens appended to storage URLs, requested anonymously or, with higher rate limits, with a subscription key. There are rate limits and availability limits: the free services are shared, finite resources, and nothing guarantees that a given service or dataset remains available indefinitely — the Hub’s retirement is the concrete example, and a real consideration for anything meant to run durably for years. Datasets carry their own dataset-specific constraints — coverage, licensing, update cadence — that the platform surfaces but does not erase. And there are tooling expectations: the cloud-native pattern assumes particular client libraries and formats, so work built around the platform’s signing, data APIs, and client libraries takes deliberate effort to reproduce elsewhere. None of these make the platform a poor choice; they are the terms of using someone else’s hosted infrastructure, and the healthy response is to keep the logic of a workflow portable even when its execution is convenient in one place.

Fitting it into reproducible workflows

Used well, a platform like this strengthens reproducibility rather than trapping you. Because discovery goes through STAC, a workflow can record the exact collections, area, time window, and filters it used, and because those identifiers are standard, the same specification can be re-run here or against another STAC provider — the platform is one source of data for a portable description, not the description itself. The pragmatic stance is to treat the Planetary Computer as an excellent place to discover and read large open datasets, with processing run on compute you control (ideally in the same region), while keeping the parts that define the analysis — the search parameters, the masking rules, the reflectance and compositing choices — written down independently of any one environment. That way the platform accelerates the work without becoming a single point of failure, which is exactly the platform-aware posture the rest of this section takes toward Earth Engine and other hosted options: powerful access tracks to understand and use, none of them the only serious way to work.

Accessing the platform

Access follows the catalog-over-storage model directly. Discovery is through a STAC API, queried the same way any STAC endpoint is, returning items whose assets point at cloud storage; those asset links are signed on demand to be read; and the reading is typically done with Python tooling designed for cloud-native formats, running in whatever environment you provide. Operating concerns on the catalog side — paging, validation, and change over time — are developed in the STAC Overview page, and the platform sits within the wider open geospatial data ecosystem it helps make usable.

Sources