Microsoft’s Planetary Computer now hosts NASA’s Harmonized Landsat and Sentinel‑2 (HLS) archive on Azure, bringing a multi‑petabyte, harmonized, cloud‑native time series of 30‑meter surface reflectance imagery into a production‑grade environment where researchers and enterprises can run near‑real‑time analytics, train large models, and prototype natural‑language data discovery with Azure AI tools. This move collapses a major piece of friction for Earth‑observation science — the need to manage terabytes of imagery, reconcile sensor differences, and provision the compute to process it — while raising practical questions about governance, reproducibility, costs, and the environmental trade‑offs of running large AI/analytics workloads in hyperscaler datacenters.
Background / Overview
The Harmonized Landsat and Sentinel‑2 (HLS) project was developed to fuse observations from NASA’s Landsat 8 and 9 sensors with ESA’s Sentinel‑2 multispectral imagery into a single, harmonized surface reflectance product at a common 30‑meter grid. That harmonization — which performs atmospheric correction, bandpass normalization, view‑angle adjustments, cloud/cloud‑shadow masking and reprojection — makes it possible to treat Landsat and Sentinel‑2 observations as a single time series, increasing effective revisit frequency to roughly every two to three days for many locations. HLS products are delivered as Cloud‑Optimized GeoTIFFs (COGs) and include QA and vegetation index layers. Microsoft’s Planetary Computer now exposes that HLS archive inside Azure storage and via the Planetary Computer APIs and sample notebooks. The dataset is organized by product family (L30 for Landsat‑derived, S30 for Sentinel‑derived), MGRS tile, acquisition day and collection version, with per‑band COGs and STAC‑style metadata to support cloud‑native workflows. Microsoft’s published guidance recommends performing large‑scale processing in the same Azure region where the blobs live to avoid egress charges and improve performance.
What HLS on Azure actually gives you
A cloud‑native, harmonized archive
- Multi‑petabyte footprint: HLS is an archive that extends back to 2013 for Landsat inputs and to 2015 for Sentinel‑2 inputs, and Microsoft’s hosting brings the archive into Azure blobs as COGs so it can be streamed directly into cloud compute.
- Harmonized 30‑m surface reflectance: The HLS pipeline produces two principal product families (HLSL30 and HLSS30) that share a common 30‑m grid so analysts can compute time series and indices without per‑sensor radiometric reconciliation. This is the key technical payoff: higher temporal density and reduced sensor bias for vegetation and land‑cover analytics.
- Cloud‑friendly formats and discovery: Data are delivered as COGs with embedded metadata and external STAC/metadata manifests. That enables lazy, windowed reads (rasterio/xarray/Dask), serverless ingestion patterns and direct use by Azure services (Databricks, Azure ML, Fabric). Microsoft supplies sample notebooks and STAC‑style discovery endpoints to help reproduce analyses.
Latency and cadence
- Operational cadence: By fusing multiple sensors, HLS reaches an effective revisit of roughly 2–3 days for many parts of the globe; low‑latency product variants aim for delivery within a couple of days from overpass when auxiliary inputs arrive on schedule. Users should confirm latency and collection versions for operational use cases.
Programmatic access and integration with Azure AI
- APIs and storage access: Microsoft exposes read‑only container listings, SAS token endpoints, and example mounting recipes. The recommended pattern for heavy processing is to co‑locate compute in the same Azure region to minimize network egress and maximize throughput.
- AI integration: Microsoft highlights opportunities to combine HLS with Azure OpenAI, Azure Machine Learning, and prototypes such as NASA’s Earth Copilot to build natural‑language query workflows, automated land classification pipelines, and prompt‑driven exploration layers. These integrations accelerate prototyping, but they also require strict provenance and validation for scientific and operational decisions.
Why this matters: practical use cases unlocked
HLS on Azure isn’t just a convenience — it changes what’s feasible for teams that need scale, reproducibility, or operational timeliness.
- Agriculture and precision farming: Frequent, harmonized reflectance supports field‑scale phenology monitoring, automated NDVI/EVI pipelines, and crop‑stress early‑warning systems that run across thousands of fields in parallel. Because HLS reduces sensor switching bias, automated irrigation and yield‑forecast models become more consistent over time.
- Disaster response and emergency mapping: Fire burn mapping, flood inundation analysis and storm damage assessments benefit from denser temporal coverage and harmonized preprocessing. Hosting HLS on Azure supports automated pre/post event mosaics and near‑real‑time ingestion pipelines feeding emergency dashboards.
- Long‑term monitoring and carbon accounting: The decade‑plus record at a consistent 30‑m grid makes HLS attractive for regional carbon monitoring, forest‑loss analytics, and land‑cover transition studies, improving continuity when sensors change.
- Model training at scale: Putting petabytes of COGs next to GPU/CPU fleets removes an enormous friction point for training deep models on time‑series or semantic segmentation tasks. Teams can iterate faster and trial agentic systems that combine retrieval (COGs/STAC), modeling (Azure ML), and synthesis (Azure OpenAI).
Technical caveats and scientific limits
HLS is powerful, but it’s not a universal panacea. Practitioners must be mindful of documented caveats.
- Residual spectral differences: While harmonization reduces between‑sensor differences substantially for many bands, blue and green bands can retain larger residuals due to atmospheric correction challenges. Radiometrically sensitive coastal or aquatic work should validate HLS outputs against in‑situ or sensor‑specific products.
- Cloud and shadow masking: Automated cloud/cloud‑shadow masks exist in the HLS products, but masking quality varies by region and season. Persistently cloudy regions and edge cases can introduce false alarms in index‑based detectors; temporal compositing and robust QA filtering remain essential.
- Product latency variability: Low‑latency HLS targets exist, but the delivery timing depends on upstream Level‑1 ingests and auxiliary data availability; operational decisioning requires teams to record and monitor product latency for their tiles.
- Platform reliability and completeness: Independent community reports have shown intermittent gaps in some platform‑hosted datasets. Organizations using Planetary Computer for critical production tasks should verify completeness for their AOI and keep local caches or fallback access to original archives as an insurance policy.
Governance, cost and operational risk
Putting a government‑funded dataset into a commercial hyperscaler brings trade‑offs that teams must manage deliberately.
Platform dependency and vendor lock‑in
Hosting HLS on Microsoft’s Planetary Computer adds convenience but also increases operational dependency on Microsoft’s tooling, region availability, API stability, and product decisions. Teams should plan exit strategies: local snapshotting of essential tiles, versioned provenance records, and contractual protections where mission continuity is required.
Cost management
Cloud compute, storage and egress are real costs. Co‑locating compute with the data reduces egress, but large‑scale, multi‑tile analysis still incurs significant bills. Practical cost controls include:
- Prototype with limited tiles and dates.
- Use spot/low‑priority VMs for non‑critical batch runs.
- Use lazy evaluation (Dask/xarray) and streaming reads.
- Keep intermediate outputs in Azure storage to avoid repeated egress.
Data licensing and attribution
HLS aggregates USGS/NASA and ESA source data under their respective licenses. Microsoft provides the dataset “as‑is”; commercial users should confirm licensing and attribution requirements for downstream products and services.
Reproducibility and provenance
HLS uses explicit collection versions (for example, v2.0) and tile IDs. Scientific reproducibility demands recording exact collection versions, tile IDs, QA flags and the code used to generate results. When using AI or Copilot‑style flows, ensure that any natural‑language‑derived steps map back to deterministic pipeline calls and recorded artifacts.
AI and Earth Copilot: opportunity and caution
Microsoft and NASA are experimenting with
Earth Copilot and Copilot‑style experiences that layer natural‑language queries on top of Planetary Computer datasets. These prototypes demonstrate how conversational interfaces can lower the barrier to entry for non‑specialists, turning complex requests into discovery, filtering and visualization actions. However, caution is warranted:
- Speed vs. scientific rigor: AI assistants accelerate discovery, but outputs can hallucinate or omit provenance. For scientific or policy decisions, every AI‑derived insight must be traceable to specific tiles, dates and QA settings.
- Model governance: Combining HLS with Azure OpenAI or other large models requires strict controls on model inputs, prompts, and output validation; teams should instrument human‑in‑the‑loop checks and unit tests that validate detection thresholds and false‑positive behavior.
- Commercial framing vs. public data ethos: NASA’s datasets are public‑interest data, but the commercial convenience of hosted datasets introduces questions about access parity, long‑term availability and whether paid tiers or marketplace packaging could fragment the ecosystem. Teams and funders should evaluate procurement channels and long‑term availability guarantees.
Funding uncertainty and the NASA shutdown context
NASA funds and operates the HLS processing pipeline and the LP DAAC distribution channels. At the time of Microsoft’s Planetary Computer hosting announcement, the U.S. federal government was experiencing a lapse in appropriations that affected NASA’s operations, and NASA had placed guidance and shutdown notices on agency pages indicating limited operations during funding gaps. That fiscal uncertainty introduces two practical questions for users:
- Will NASA’s ongoing funding and data production cadence be affected by a prolonged lapse in appropriations? Public NASA guidance during a funding lapse indicates that many programs are curtailed or operate with significantly reduced staff, even while critical mission operations continue. Organizations should track NASA’s published continuity guidance for concrete impacts on HLS processing or updates.
- Could a commercial partner step in to continue data hosting or processing if government provisioning is disrupted? There is no public evidence that Microsoft or any other private cloud provider has committed to underwriting NASA’s science funding or the operational costs of data production; any such arrangement would require explicit, contractual announcements. Treat such scenarios as speculative until verified. Caution: this claim is not confirmed by public statements.
Practical checklist for researchers and teams (quick start on Azure)
- Identify AOI, tiles and date range using the Sentinel‑2 MGRS tiling grid and HLS tile lookup scripts. Record MGRS tile IDs and collection versions for reproducibility.
- Validate completeness: perform a quick list‑and‑count of COGs for your tiles and compare with NASA/LP DAAC indexes to ensure no gaps for your critical periods.
- Prototype with sample COGs and the provided notebooks (rasterio/xarray) to validate QA filtering and index calculations locally before scaling.
- Move heavy processing to co‑located Azure compute in the same region (the published configuration often uses East US/East US 2) to minimize egress and latency; use spot instances for non‑critical batch jobs.
- Codify provenance: store tile IDs, collection versions, QA thresholds, SAS token snapshots and the exact notebook/commit used for processing outputs.
- Implement cost controls and monitoring: cap parallel workers, track egress, and instrument alerts when spend thresholds are exceeded.
Environmental and ethical considerations
It is notable — and often under‑discussed — that large‑scale AI and geospatial analytics have non‑trivial environmental footprints. Running petabyte‑scale I/O, GPU training and persistent storage consumes significant energy and cooling resources in hyperscaler datacenters. While cloud providers invest in renewable energy and efficiency, teams should measure and minimize carbon‑intensive operations:
- Prefer streaming reads and on‑node processing to avoid copies.
- Use region‑specific sustainability metrics where available and prefer regions with cleaner energy mixes.
- Batch non‑urgent model training during low‑carbon grid periods where feasible.
Finally, ethical governance of Earth observation data is critical where imagery is used for surveillance, insurance decisions, or regulated activity. Ensure privacy, fairness and explainability checks are part of production pipelines.
Final assessment: strengths, trade‑offs and recommended next steps
Microsoft hosting NASA’s HLS on Planetary Computer is a major enabler for scalable geospatial analytics. The principal strengths are:
- Accessibility at scale: Researchers can run petabyte‑scale workflows without manually managing massive archives.
- Interoperability: COG + STAC manifests fit modern geospatial stacks and accelerate tooling adoption.
- Prototype‑to‑production pathway: Proximity to Azure AI and compute services lets teams prototype Copilot‑style interactions and scale models into production.
Key trade‑offs and risks:
- Operational dependency on a commercial provider: Plan for exit/fallback strategies and verify regional availability for mission‑critical work.
- Cost and governance: Budget for compute, storage and potential egress; confirm licensing for downstream commercial use.
- Scientific caveats: Validate radiometric performance for sensitive bands and confirm cloud‑masking quality in your AOI.
Recommended immediate steps:
- Run a focused pilot on a handful of tiles across the seasons you care about. Capture performance, completeness and cost data.
- Codify provenance and versioning in automated pipelines.
- Use AI assistants like Earth Copilot for discovery, but require deterministic pipelines and human validation for final outputs.
Microsoft’s move to host HLS on Azure is a pragmatic and powerful improvement for the Earth‑observation community: it removes infrastructure friction, accelerates experimentation, and enables new classes of AI‑driven analytics. At the same time, the promise brings new responsibilities — to validate scientific accuracy, manage cloud costs and dependencies, and account for environmental impacts. For teams that adopt Planetary Computer for operational use, the sensible path is a small, measurable pilot; rigorous provenance; and explicit governance that balances speed with scientific integrity.
Source: theregister.com
Microsoft uploads NASA's Landsat and Sentinel data to Azure