Microsoft Planetary Computer

The Microsoft Planetary Computer is less a dataset than a place to work with datasets. Where the Sentinel-2 and Landsat pages describe imagery and the STAC Catalogs page describes how such imagery is discovered, the Planetary Computer combines both and adds compute: a large hosted catalog of open environmental data, described by STAC, sitting next to cloud computing that can run against the data where it lives. 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. This page treats it as a concept, an instance of the cloud-native, catalog-plus-compute pattern, rather than as a product to be tutorialized; the reasoning here transfers to any platform built the same way, and the point is to understand the model, not to memorize one provider’s controls.

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 compute near the data: a hosted environment where analysis runs in the same cloud region the data sits in, so large jobs move code to data instead of data to code. Individually none of these is unique; together they turn “find, fetch, process” into a single integrated 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 because the compute runs beside the storage, the slow step — moving bytes across the network — largely disappears. This is what makes platform-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. Access to protected assets typically requires signing: an asset’s storage URL must be signed to become temporarily readable, and those signed links expire, so a workflow has to sign at fetch time rather than cache a URL and reuse it later — the same signing reality the STAC page flags, made operational here. There are quotas and availability limits: hosted compute is a shared, finite resource with usage boundaries and no guarantee that a given platform or dataset remains available indefinitely, which is 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 done comfortably inside the platform’s environment 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 execution venue for a portable description, not the description itself. The pragmatic stance is to treat the Planetary Computer as an excellent place to prototype and to run data-heavy discovery and processing near the data, 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-plus-compute 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, either from the platform’s own hosted compute or from an external environment that can reach the signed assets. The engineering details of paging through STAC results, signing assets, and streaming chunked data are developed further in the STAC Overview page, and the platform sits within the wider open geospatial data ecosystem it helps make usable. Whichever entry point you take, the durable reasoning is unchanged from the other sources: search a catalog, filter by space, time, and properties, select comparable items, and preserve their identifiers so the selection is reproducible — the Planetary Computer simply makes running that loop against large open data unusually convenient.