And that’s because my demo would have looked much like several of those on the screens. Many of them had a natural language interface with suggested prompts, through which a workflow was orchestrated to access data and return text, charts and maps showing the results. The underlying implementations were different, sometimes considerably so, but I recognised the experience they were trying to offer because I’d been working on much the same thing.

I could imagine getting used to a common interface across geospatial platforms, much as we have with other kinds of software. As I went through the demonstrations, I was looking for questions each system could answer that would previously have required considerable work, and trying to understand what an agent added to analyses we already knew how to run.

I kept thinking about Will Marshall’s 2018 TED talk, where he described his vision of searching the Earth’s surface the same way we search the internet: “abstracting out the imagery entirely and just having a queryable interface to the Earth”.

That was one of the first things that inspired me and helped draw me into EO. Planet and Microsoft demonstrated a version of it in their 2023 proof of concept, Queryable California, using natural-language questions to explore information derived from satellite imagery. Now, agentic systems are attempting more of the work behind those answers, including finding observations and choosing methods.

I believe the timing of the workshop was spot on! The Model Context Protocol (MCP), which provides a common interface for connecting AI systems to data and tools, had appeared in November 2024, followed in April 2025 by Agent2Agent (A2A), which supports communication between agents. People had time to build and test different approaches, while still disagreeing about fairly basic choices. How many tools should an agent have access to? How much freedom should it have to choose a methodology, and how would we evaluate the result? Those questions came up throughout the workshop, alongside implementations that gave us something concrete to discuss. ESA had also released Earth Virtual Expert (EVE) shortly before the event, with a public release focused on scientific questions and answers. The experimental integrations and open MCP registry presented at the workshop gave us a sense of what people were trying to build around it.

In the opening speeches, I kept hearing variations of “see more clearly, understand more deeply, act.” We’ve spent years trying to turn EO information into the “actionable insights” that appear in so many product descriptions, and I wasn’t sure how much of the difficulty in that final stretch — or rather, the marathon at the end of the triathlon— people expected agents to resolve. A customer usually has other information to consider and an existing process for making decisions, which the EO service will somehow have to fit into.

Is the agent the missing piece and perhaps the enabler of that integration?

What agents add to the workflow

Last December, I built a small FastMCP interface for discovering imagery through natural language in Microsoft Planetary Computer’s STAC catalogue, which follows the STAC standard for describing geospatial data. Getting it to the point where it somewhat worked wasn’t especially difficult. I’d have had considerably more work to do before trusting it with ambiguous requests or unavailable data, which made me curious about how the systems in Berlin handled cases beyond their prepared demonstrations.

One presentation used flood response to explain why agents were needed. Given a flood map, the system would identify affected schools, hospitals and roads, estimate exposure and help prioritise a response. I found the comparison with a flood map too generous to the agent, since intersecting it with infrastructure, calculating exposure and analysing a road network are established GIS operations that a conventional workflow could already carry out.

With known inputs and a recurring question, I’d prefer a tested workflow whose calculations are defined and reproducible. An agent could call perfectly deterministic GIS tools in the wrong order, or choose the wrong ones altogether, and still return a plausible map. I wasn’t convinced that having it decide on those steps each time would improve the analysis.

If I were to add something to that presentation, I’d focus on what happens when we need to integrate unfamiliar data. Suppose a local authority supplies a road network with different attributes and coordinate systems, or a new provider delivers the flood layer in a format our workflow doesn’t support. We might need to replace a source that has become unavailable. I can see an agent being useful in working through those changes and preparing compatible inputs for an analysis we’ve already developed and tested. We already have tools for routine format and coordinate conversions. More complicated schema adaptation can silently introduce mistakes in units, geometry or spatial reference systems. Still, I’d probably want those adapted inputs checked before they reached the tested workflow.

To me, that seems a more useful case than asking an agent to reconstruct the same sequence of GIS operations on every run.

There is another benefit that shouldn’t get lost in my scepticism about chat interfaces. Someone shouldn’t need to know Python, raster processing or how to access data to ask a legitimate question about their environment. Salman Khan, from Mohamed bin Zayed University of Artificial Intelligence, discussed small models, local languages and access for people with limited technical infrastructure, while Development Seed’s lightweight models and their work on Global Nature Watch reflected a similar interest in accessibility. Making an established analysis easier or cheaper to use can be valuable in itself, provided the person using it can also understand when the available data cannot support an answer.

Autonomy is a spectrum

For many of the open-ended EO and GIS questions in the demonstrations, there was broad agreement that a human in the loop is still essential. Even if an agent can run the tools, someone needs to judge whether the observations, methods and conclusions hold up.

The space-operations presentations offered an interesting comparison in terms of autonomy. CS Group described work connecting event detection with satellite tasking, while Steve Chien’s presentation of NASA/JPL’s Federated Autonomous Measurement (FAME) explored how spacecraft could coordinate follow-up observations. Chien spoke about humans-on-the-loop, supervising systems within agreed limits while systems handle acquisition windows and competing requests. With dynamic targeting, onboard analysis can change what a satellite observes during a pass, sometimes within seconds, when there may be little opportunity for human intervention. There is considerably more autonomy in these applications, although the decisions take place within defined mission objectives and operational constraints. Autonomous scheduling also predates LLM agents, and FAME’s wider federation plans extend beyond what has been demonstrated so far.

How we judge the result

If I had one euro for every mention of trust, reliability, transparency, provenance, traceability, reproducibility or uncertainty during the workshop, I could probably pay for another conference trip.

We’ve been discussing most of these things in remote sensing for years, and I remember similar conversations around explainable AI. With agentic systems, there’s more to inspect because the software may also be deciding which observations to use and which methods to apply. Most of the demonstrations I saw exposed logs and execution traces, making it possible to follow those decisions through the analysis.

After all the energy we’ve spent on “explainable AI”, I find it ironic how easily we can feel reassured by a list of tool calls, while still struggling to understand what the models have learned or what their embeddings represent.

In Salman Khan’s keynote, a rainfall calculation combined ERA5 with a vegetation mask. One agent returned 383.7 mm against a reference of 27.39 mm, about fourteen times as much, and received a higher workflow score than another agent whose answer of 27.31 mm was within the accepted tolerance. Scoring the recipe — the tool choices and execution — and scoring the output led to different conclusions about which run performed better.

Having access to the tool calls, inputs and intermediate outputs helps us identify a mistake, including one in an analysis that is perfectly reproducible but scientifically flawed. Mistral’s Jacopo Chevallard also made a useful point about preserving the data, processing environment and tool versions used in a run: if an archive has been reprocessed or a service has changed, a comparison between agents may also become a comparison between different versions of the data and services they accessed.

Axis Spatial’s EO Agent Arena reported much stronger results on guided GIS workflows than on autonomous tasks, with different task sets limiting how directly those scores can be compared. Adding image-processing tools helped some models and made others worse in the reported tests. I’d like to see tool selection evaluated as carefully as the agents themselves, especially as the registries of EO capabilities grow.

I also liked Christopher Forrest Brown’s criticism of how we benchmark these systems. We often give a model carefully prepared imagery, from an appropriate sensor and date, with the task already defined. In practice, deciding what data to use and whether the observations are suitable can take a substantial part of real EO work. Then there’s the other end of the process, where an improvement in model accuracy may be of little consequence if the analysis is too expensive, arrives too late or doesn’t satisfy the user’s actual requirements.

Brown, from Google DeepMind, illustrated another difficulty with a seemingly simple question: how much of Massachusetts consists of beaver swamp? An agent could put together a sophisticated workflow using wetland maps, satellite observations and statistical estimation, leaving us to decide whether those measurements could reliably identify wetlands created by beavers.

He also identified problems with the checks on the result. The National Wetlands Inventory (NWI) layer appeared as a reference and later as a cross-check, raising a question about the independence of that check, while visually labelling aerial-image samples brought us back to whether the imagery could establish that a wetland was created by beavers. We could validate each tool separately and still combine them into a scientifically questionable analysis. How many of our benchmarks would reward an agent for recognising that it needs more information, or that the available observations cannot support the requested conclusion?

The role of institutions

Andres Camero spoke about the trust organisations place in DLR. His comments got me thinking about the different pressures institutions and private companies face when adopting new technologies. In EO, companies are often under considerable pressure to turn new capabilities into demos, MVPs and eventually paying products. Institutions such as DLR have built their reputations over decades of scientific and operational work, and have to be careful when introducing new methods into services people already rely on.

I find ECMWF’s adoption of AI forecasting a particularly good example of this more deliberate approach. Its AI Forecasting System (AIFS) became operational in 2025 alongside the established physics-based Integrated Forecasting System (IFS), following extensive evaluation across different forecasting conditions and work with Member States and users. Both systems continue to be verified, and AIFS has been brought into ECMWF’s operational support arrangements. There’s something reassuring about that level of care when new AI capabilities can move from demonstration to commercial product so quickly.

Institutions such as ESA, DLR, ECMWF and EUMETSAT could play a much larger role in guiding the development of agentic EO. There was still a great deal of uncertainty in Berlin about which approaches were worth pursuing, and these organisations have decades of experience evaluating new methods and deciding when they are reliable enough for operational use. I’d like to see more independent comparisons, with results and failures shared openly, to help researchers and companies decide where to put their effort.

Building better scientific tools

Brown suggested that increasingly capable general-purpose agents might eventually absorb much of the orchestration we’re currently building into specialised systems. I wouldn’t take that for granted when deciding where to put our effort now. Khan’s planner-and-executor results and Mistral’s work on specialist tools and verification gave us reasons to keep investigating those approaches as general models improve.

During the discussion after Brown’s keynote, I asked where our domain expertise should enter a system whose steps we don’t want to prescribe in advance. I was thinking about how we’d help it choose appropriate observations and methods, and whether that knowledge belonged in the prompt, the tools or the verification. His answer, as I understood it, was that it should be incorporated throughout.

STAC helps us describe and discover datasets, openEO provides process graphs, and OGC API - Processes provides a standard way to describe and execute processes. An MCP server can expose those capabilities to an agent, while EVE’s registry gives developers a place to share the tool interfaces. An agent choosing a burned-area mapping tool needs to know which sensors and processing baselines it supports, what observations it requires before and after a fire, and where it has been evaluated. That includes conditions under which harvesting or seasonal changes might be mistaken for burning, and how independently the reference data were collected.

Suppose its only available post-fire image falls outside the method’s validated time window. The code could still run and produce a plausible polygon, so a check built into the tool could flag the unsupported input before processing begins. The agent could then look for another method or additional observations, explaining when a reliable estimate isn’t possible with what it has. Documentation would help it make the initial choice, while executable checks could catch specified problems during the run, leaving scientific review to address questions those checks cannot resolve.

Some of this information already exists in documentation, process metadata and testing systems, although it isn’t always easy for an agent to find and use. Common conventions could help make it available through existing standards. We could compare agents given ordinary tool descriptions with agents given evaluation results, known limitations and relevant checks, and see how often they select a suitable method or recognise a use outside its validated conditions.

In the workshop’s “Subway Takes” session, someone argued that we already have too many geospatial foundation models. Brown also questioned how far the growing number of published models had translated into operational use. A poster comparing TerraMind and THOR looked at performance and computational requirements across downstream tasks. Comparisons like that can help us understand what the existing models do well, and where they fall short.

My sympathy with the “too many foundation models” argument comes mostly from the economics of it. Training a large geospatial foundation model can run into millions of euros once compute, data preparation and engineering are included. Before making that investment, we should be able to explain what the existing models and conventional methods still fail to do, and what another model would improve.

James Zou’s presentation of Paper2Agent had me thinking about how much published EO work remains difficult to reuse. The project turns papers and code into executable tools and tests whether they reproduce the original results. Someone in the hot-take session worried that research might become less scientific as LLMs take on more of it, and I share the concern about a kind of paper-to-paper commentary, where systems consume publications and help produce new ones with little independent testing along the way. Reproduction and reanalysis can help us examine what a method actually measures and whether the results justify the conclusions. We were quite capable of publishing sloppy science before 2024. Some of that flawed literature may now be among the material agents draw on when choosing methods, so a faithful implementation can carry an old methodological weakness into new work.

Coding agents could also help with methods we’ve struggled to develop or apply. There are observations in archives beyond the familiar Sentinel-2 and Landsat workflows that remain difficult to exploit, and scientific work that takes considerable effort to implement or repeat. We could spend some of the time saved on programming working with those observations and investigating new ways of making measurements.

Operational context

Linda Sheard from Xoople spoke about agents needing access to an organisation’s operational context, and I recognised the problem from EO work. We often talk about EO services delivering “actionable insights”, but the map or statistic we produce is usually one input into somebody else’s process. A company may already combine information from several EO providers with its own records, policies and procedures. Much of what determines the next action sits in those systems, which the EO provider may have little access to.

One conversation at the workshop concerned detecting individual solar panels from high-resolution imagery. Even at around 25 cm resolution, models can struggle when moved from one country to another. Suppose an insurer wants to find installations missing from the records of properties it covers. The detections would have to be matched to the correct buildings and insurance records, then compared with what the company already knows. A suspected installation might warrant a review, but the detection alone wouldn’t tell the insurer what to do. A missed panel and a false detection have different consequences, and investigating false alarms across a large portfolio can become expensive. Whether the information is worth buying depends on what the insurer already knows, how else it could obtain that information and whether it would actually change a decision.

I don’t see a reason to put an agent in the middle of every part of that process. If the records are consistent and the business rules are known, conventional software can do much of the matching, checking and routing. An agent might be useful when records are incomplete, sources change or a case requires looking up information across several systems. But an agent could match a detection to the wrong property, too, or decide to update a record that should have gone to someone for review. We’d need to be just as careful about those choices as we are about the EO analysis itself.

That also raises the question of whose agent would do the work. An EO provider could make a tested analysis available as a tool, perhaps through MCP, for the customer’s own systems to call. If an agent is coordinating what happens next, it probably needs to sit closer to the company’s records and procedures, where the relevant context is. The customer would still have to decide what information the agent can access, what should trigger a review and which changes require approval. Making an EO service callable doesn’t settle any of that.

In the insurance example, the detections might be ready in minutes, while the insurer still has to match them to its records and decide which cases need a closer look. I’d want to know whether an agent reduces that work, including the checking and corrections it introduces.

Marcin Detyniecki’s comments about AXA’s scale brought home how different the costs can look once an analysis runs across a large portfolio and several countries. By the time we’ve paid for imagery, processing and reference data, checked the results and connected them to customer systems, the LLM bill may be one of the smaller expenses. Even a small false-positive rate can leave a large number of cases to review at that scale.

Julia Gottfriedsen from Constellr stressed instrument-specific expertise and human review before information reaches a customer. That seems especially important if the result can pass directly into the customer’s own systems. I kept thinking about the pressure to turn a demonstrator into a product that brings in revenue, and how easily a convincing interface can make the work behind it look ready. If methods haven’t been tested for the places and conditions in which they’re sold, sloppy work can end up inside the customer’s procedures, creating more work for them and consuming credibility we may struggle to rebuild.

When was the last time you wrote a line of code?

During a coffee break in Berlin, someone asked when we’d last written a line of code ourselves. For several people in the group, it had been months. Coding agents have changed my own work too; much of my time now goes into reviewing and testing code I haven’t typed. As Brown put it: “It’s simply faster to be a code reviewer than a code editor.”

I’ve used Star Trek as a comparison before. A conversation with the ship’s computer gives you access to an enormous amount of information and computing power, while Spock and Scotty understand enough about the science and instruments to question what it tells them.

We agreed that having developed our experience and expertise before LLMs has left us better equipped to work with these tools, even when their outputs are unreliable. We can review code we haven’t written because we know something about what it’s supposed to do. I wonder how people entering EO now will acquire that judgement if they rarely have to implement the methods themselves.

I still find the idea of a queryable Earth extraordinary, and Berlin gave me plenty to think about. I enjoy attending these early workshops. Last year’s ESA–NASA International Workshop on AI Foundation Models for EO was the first on that topic, and Berlin was a similar gathering for agentic AI. It’s interesting to see people presenting their work while the field is still figuring out where to go next. Some were sceptical about what agents could actually add, while others seemed to see them as a missing piece in bringing EO into wider commercial use.

I’m curious to see which EO questions become easier to explore as we spend less time writing code and connecting services. There are methods worth revisiting and observations we’ve struggled to work with, and perhaps agents will make some of that work more practical.

I’ve also been noticing the attention given to industry at ESA events. At the Living Planet Symposium, alongside the exhibition booths and panels, there were sessions on bridging the last mile with end users and connecting EO with people from insurance, energy and finance. We’ve spent years discussing how to bring EO into other industries, but we don’t always hear much about what happens to our information once it reaches them. These companies understand their own systems, procedures and costs much better than we do. I’d welcome more opportunities to hear about those processes and the difficulties of integrating EO into them

CNG is not exactly a conference. It is more organised than a meetup and, despite everyone speaking the same cloud-native dialect, apparently not a cult either. It calls itself a forum. I am not sure how much of the Roman meaning survives, but the description felt about right: a public gathering place where people presented their work and ideas, discussed their challenges and invited others to collaborate.

For anyone unfamiliar with it, the Cloud-Native Geospatial Forum is an initiative of Radiant Earth aiming to encourage the use of common cloud technologies and open data formats across the geospatial sector. The event itself was more about what happens once those ideas meet actual users, actual institutions and awkwardly large datasets.

The programme moved through GeoAI, environmental decision-making, foundation-model embeddings, Zarr, ecology, informal settlements, autonomous agents, drought monitoring, energy forecasting and humanitarian drone imagery. It sounds like a lot for one day, but much of it shared common ground around trust, scale, EO-based decision-making and what cloud-native infrastructure now makes possible.

What happens after the GeoAI demo?

Luca Budello from Innovate UK spoke about the GeoAI UK Outlook, which drew on three roundtable dinners held at the Royal Society in January 2026. Published by Innovate UK Business Connect with LunateAI and Sparkgeo, the report looks at the conditions needed for GeoAI to move from promising demonstrations into wider use.

Luca described a move from data as a service to intelligence as a service. Catalogues, APIs and cloud-optimised formats have made geospatial data much easier to find and open, but the person using them is usually trying to work out what changed, where to inspect or whether intervention is needed. The raster is only part of that process.

He compared this with open banking, where changing the rules around access to financial data allowed other organisations to build services on top of it. The UK already has strong public data institutions in Ordnance Survey, the Met Office and the Office for National Statistics, so it is easy to see the appeal of doing something similar with geospatial data. That would mean making datasets easier to use together across institutions, not simply publishing each one through a better API.

Once those datasets begin feeding recommendations or decisions, access is no longer the whole issue. The result has to make sense in the place and institution where it will be used, and someone needs to be able to trace how it was produced. A model used for agricultural monitoring does not need to meet the same standard as one used in finance, defence or public safety. Nor does validation in the UK guarantee that it will work elsewhere. Landscapes and settlement patterns change, as do administrative systems and the biases present in the available data.

Seen in that context, “human in the loop” sounded too simple. It brings to mind someone appearing at the end of a process, reviewing an output and clicking approve. In practice, someone has to set the limits of the system and investigate results that do not look right. They also need a record of the model and data versions, what was run, in which order and where a person intervened. A confirmation button means little if nobody can reconstruct what happened before it appeared.

One point I took from the discussion was that deterministic workflows do not always fit decisions built around uncertain or probabilistic outputs. A burned-area estimate, flood-depth calculation or vegetation-change product should still be reproducible. What may vary is how the system reaches that calculation. It might interpret the request differently, select another dataset or use the available tools in a different order.

Validating a model or documenting one processing chain does not explain a result if the route through the system can change between runs. Someone reviewing the recommendation needs to be able to see how that particular result was produced.

The UK’s Sovereign AI initiative could help projects move beyond demonstrations by funding compute and infrastructure. Adoption still means paying for deployment, fitting the system into an organisation, maintaining it and deciding who takes responsibility for its use.

Jed remarked that the main use of geospatial information by government is land use. Planning, housing, transport, agriculture, conservation and energy all involve decisions about what can happen in a particular place. For all the discussion of national AI infrastructure, many of its eventual uses may still come down to a piece of land.

Working backwards from the outcome

Noelia Jiménez Martínez and Glen Low from Earth Genome presented Earth Index, a tool for searching satellite imagery through Earth-observation embeddings.

Earth Genome is a nonprofit, but its way of working sounded closer to a small technology company than to a conventional research organisation. Paid projects support some of the work, while philanthropic funding gives it room to develop tools and test new applications. Most people in the room seemed to know the organisation already.

They demonstrated the use of foundation-model embeddings for applications including seagrass mapping, although I was more interested in how they decided what to build in the first place.

Much EO development follows a familiar sequence:

data → tools → decisions → outcomes

Earth Genome works backwards:

outcomes → decisions → tools → data

The starting point is a particular user and the outcome they are trying to achieve. From there, the team works back through the decision that might lead to it, the tool needed to support that decision and, finally, the data required.

In practice, EO projects often start with a dataset, a model someone wants to test or the requirements of a funding call. Work may already be well advanced before anyone asks who is expected to use the result.

They used personas and user stories to make the intended user more specific. A conservation officer and a municipal planner may look at the same landscape, but they are unlikely to ask the same question or use the answer in the same way. They may also have different tolerances for uncertainty and very different consequences if the product is wrong. Some can act on the result directly; others can only use it to support a recommendation.

Outcomes, they argued, should be measurable. The decision should become better, faster or cheaper, and the improvement should be visible beyond the technical performance of the model. That makes cost and value part of the design from the beginning, including what the product costs to produce, how much interpretation it saves and whether it allows the user to do something that was previously too slow, difficult or expensive.

Freshwater products came up as an example of the limits of global coverage. A product may cover the whole world and still be too coarse, poorly calibrated or too detached from local practice to support a decision in a particular place.

Earth Genome’s approach was to begin with well-understood local examples and then test how far they could be generalised. Embeddings can help locate similar conditions elsewhere and reduce the amount of labelled data needed in a new region, but that still does not remove the need to understand the geography and the conditions under which the original examples were collected.

In the seagrass work, AlphaEarth Foundations embeddings performed better than the other foundation-model embeddings they tested. Their interpretation was that its pretraining data included benthic environments, making the embeddings a better fit for the task.

Satellite embeddings and ground observations

Anil Madhavapeddy presented TESSERA, a global set of 10-metre, pixel-wise Earth-observation embeddings with open weights and cloud-native access through Zarr v3 and STAC.

Instead of returning to the source imagery for every task, users can work with a reusable numerical representation of each location. That can reduce the data and computation needed for searches, classification and other analyses. What can be learned from those embeddings still depends on the information retained from the original satellite observations.

Molly Blank’s talk on bringing ground-level ecological data into the cloud added another side to this. Expert surveys can provide reliable observations, although they are expensive and rarely cover large areas consistently. They may also produce only a modest number of records and, as Molly pointed out, do not necessarily need a cloud platform. Sometimes a CSV is fine.

Citizen-science programmes produce many more records, though the observations reflect where people go, what they recognise and what they find interesting enough to record. GeoParquet can make those data easier to store and query without changing the way they were collected.

Camera traps, acoustic devices, environmental DNA systems and other sensors add another kind of data. They can generate observations continuously and at much larger volumes, often faster than the recordings can be processed, labelled or interpreted. Larger volumes do not necessarily make it easier to tell whether an ecosystem has changed or why.

Molly introduced the idea of an ecosystem state vector as a way of bringing some of these observations together. She asked whether embeddings derived from ground data could help calibrate remote sensing, and whether combining different modalities could reveal meaningful ecological change. Possible applications included detecting invasive species sooner and observing changes in the biotic elements of soil, which may be invisible to satellites but could complement remote sensing.

Zarr chunks, building footprints and browser maps

Sol Cotton from Open Climate Fix used the problem of Zarr chunking to show how the structure of a dataset shapes the way it can be used. He compared it with transport to a World Cup stadium. If access is designed mainly for people arriving by car, congestion and expensive taxis follow, while anyone travelling another way has to work around a system that was not designed for them.

A dataset can sit in object storage and still be painfully slow if its chunks do not match the way people query it. A layout that works well for time series may perform badly when someone requests a spatial slice, and at large scale the cost of that decision is repeated across every request.

Icechunk adds versioning and safer concurrent updates to Zarr, which is useful when several processes update the same data cube and the dataset is maintained over time.

Nissim Lebovits then presented Barrios Visibles, which combines Argentina’s official register of informal settlements with global building footprints. The buildings are used to estimate population and examine flood exposure.

ReNaBaP records an estimated 4.15 million people living in informal settlements, while the building-based method produced an estimate of about 7.59 million. The difference is around 3.4 million people not represented in the official figure.

In this case, the global building data revealed a gap in the national register that would otherwise have been difficult to quantify. Nissim described it as an example of a global dataset outperforming the local record available for a specific task, which is not the same as outperforming local knowledge.

The project joined cloud-hosted datasets without first downloading and rebuilding them locally, then served the results in the browser through PMTiles.

Nissim joked that people cluster, like most geospatial things. Much demographic analysis still assumes that populations are distributed evenly within administrative boundaries.

He also pointed to poor internet connectivity in Argentina. Even so, with the building footprints hosted on Source Cooperative, he could access building-footprint coverage for the whole country within seconds.

When the developer is an agent

Stefan Amberger from Tilebox spoke about lessons from rebuilding an EO compute platform for machine-driven workflows.

The platform is organised around tasks and executions, with task status, logs, traces and runner context available throughout the workflow. These details become especially important when the system is being used by an agent, since the agent needs to inspect what is running and what happened during an execution.

One of Stefan’s messages was to “iterate fast, not perfect”. The emphasis was on making the platform usable by agents and improving it through actual workflows, with enough logging and execution context to follow what the system was doing.

Lightning talks

The lightning talks covered supply-chain analytics, drought mapping, Antarctic ice dynamics and open drone imagery for disaster response.

Jake Wilkins from Epoch presented a pipeline for plot-level supply-chain analytics, where global arrays are populated incrementally as requests arrive instead of being fully computed in advance. The approach seemed well suited to supply-chain work, where requests are often specific to a commodity, location or client. Computing every possible result globally would be wasteful. The arrays are instead filled as requests arrive and can support later requests for the same area or commodity.

Alper Dincer followed with a global drought map built using H3, GeoParquet and DuckDB. DuckDB can read the GeoParquet files directly from object storage and run the spatial queries in process. With H3, some spatial aggregation becomes an ordinary GROUP BY, while DuckDB-WASM allows part of the analysis to run in the browser. Very little infrastructure was needed. The analysis could read files where they were stored and run without a separate spatial database or processing cluster.

Ross Slater from the University of Leeds described the processing of around 150,000 Sentinel-1 image pairs for Antarctic ice-velocity mapping. The work ran on university HPC and produced a 53-terabyte Zarr cube. VirtualiZarr and Zarr v3 sharding allowed users to access subsets without copying or rebuilding the full dataset.

Petya Kangalova from the Humanitarian OpenStreetMap Team spoke about open drone imagery during disasters. The Drone Tasking Manager is used to coordinate flights by local drone pilots, while OpenAerialMap provides somewhere to process, publish and share the imagery. Local pilots can cover places that satellites miss because of timing, cloud or resolution, then make the imagery available to people mapping damage and organising the response.

Petya reduced the approach to a simple equation:

open standards + cloud-native infrastructure + community = humanitarian impact

Local pilots also bring the access and knowledge needed to decide where to fly and what matters during the response.

More is different

The closing panel, More is Different, brought together David Eaves, Jack Kelly, Niall Robinson and Kaja Wasik to discuss how technologies operating at very large scales are changing science and policy.

The line “quantity has a quality all its own” appeared early, attributed, with some uncertainty, to… Stalin. My notes include a laughing emoji, which probably captures the room’s response better than I can now.

The panel described 2022 as a turning point for weather forecasting, when machine-learning forecasts began matching or outperforming conventional numerical models. Five years earlier, much of the weather community had not expected this to happen.

Jack Kelly spoke about Dynamical’s work with weather data produced by organisations such as the Met Office. Using shared infrastructure built around Icechunk, a user could lazily open close to a petabyte of data with one line of Python, without downloading the full archive.

Infrastructure at that scale still needs an owner. Someone has to fund it, maintain it and decide which versions of the data are authoritative. Those responsibilities become more difficult when services built on top of it can reach several countries, or even billions of people, before any shared governance arrangements exist.

States had shown relatively little interest in the internet, Facebook and cloud infrastructure, according to the discussion. They care now. That involvement may be welcome or unwelcome depending on the state and the decision, but it is now difficult to discuss data infrastructure without considering the role of government.

Niall Robinson noted that when people use a Met Office forecast, they are also relying on the authority of the institution behind it. A private company might reproduce the technical pipeline without inheriting the same public trust.

David Eaves said that some sources of truth belong to government, at least in the UK. The claim was about institutional responsibility rather than infallibility. Public records need an organisation that defines and maintains them, corrects them when necessary and remains answerable for their use in public decisions.

Jed closed the discussion with an open question: “What are the planetary-scale data institutions?”

I did not write down whether anyone answered it, but for me the question is mostly about continuity and whether a usable archive remains. Landsat is the obvious example. Its record now stretches back more than fifty years, and those observations are still available, calibrated and documented well enough to be used today. That did not happen simply because the satellites collected the data. Institutions kept the archive, reprocessed it and made sure later users could still understand what they were looking at.

WMO coordinates weather observations, Copernicus runs long-term environmental services, and organisations such as CEOS and the Group on Earth Observations (GEO) help agencies and governments agree on standards and priorities. A mission may be operated by one agency, while its calibration, derived products and archive are maintained elsewhere.

Ten or twenty years later, can someone still find the data, understand how they were produced and use them without depending on a project or service that no longer exists?

A very 2026 set of problems

During the final discussion, I kept thinking how strange much of the day would have sounded ten years ago. We were talking about global benchmarks for energy forecasting, opening petabyte-scale archives without keeping local copies, reading EO data from object storage and putting together a dashboard in an afternoon.

Once data can move this easily, it also becomes easier to lose track of it. One version ends up in a model, another in a dashboard, and the project that produced the data may be over by the time someone asks how they were made or whether they are still maintained. Standards and governance came up throughout the day partly because the technical possibilities have moved so quickly.

Barrios Visibles and HOT showed how uneven that progress remains. Poor connectivity and limited local infrastructure made lightweight browser delivery important for Barrios Visibles. HOT’s disaster-response work relied on open imagery and tools that local pilots and mapping communities could use without much supporting infrastructure. Global datasets may help where local records are incomplete. They do not provide the missing census or the people needed to keep a system running.

Energy-forecasting papers often use different datasets, periods and metrics. Shared benchmarks would make the results easier to compare. Whoever designs the benchmark still decides which regions are represented, which timescales matter and which errors receive the most attention.

The word commoditise came up several times, especially around cloud infrastructure. Cloud providers were compared to electricity suppliers: once the plugs are the same, changing provider should become fairly routine. Object storage is starting to move in that direction. S3 began as an AWS interface, but it is now supported by storage systems far beyond AWS, so many of the same tools can work across providers with little adjustment.

Pricing, data-transfer costs and implementation details still vary between providers. S3 has become something close to a standard because so much of the ecosystem supports its interface.

Leaving the forum

Many people in the room had been riding the AI wave, keeping up with new capabilities and trying to work out what was worth building. Practitioners, builders, doers. The room also included people maintaining the open-source software much of this work depends on, and others working on standards, governance and adoption as the sector changes so quickly.

HOT gave that energy a clear purpose. Open imagery, local pilots and lightweight tools came together to support disaster response.

I am less certain about where all the other technical energy will end up. We can build very quickly, but we can also produce overlapping tools, temporary platforms and data products that nobody has agreed to maintain. At some point, more activity can simply make the sector harder to navigate.

Talking to people about what they are working on always leaves me with new ideas and more motivation. I still enjoy the details of building things, but I find myself paying more attention to the sector around them: what people are adopting, what is missing and what will still be here a few years from now.

References

• The GeoAI UK Outlook: As part of the Innovate UK GeoAI Festival [link]

• Codex Planetarius Pilot Study: Palm in Paradise - A Supply Shed Analysis of Indonesian Palm Oil [link]

• Awesome DuckDB Spatial [link]

• A Serverless Approach to Building Planetary-Scale EO Datacubes in Zarr [link]

• Designing a data pipeline for our highest-resolution dataset yet [link]

It was amazing attending the Living Planet Symposium last week (23–27 June 2025) in Vienna. It’s definitely a fantastic event to get inspired, meet people, have interesting discussions — and nerd out about space!

It’s been just three years since the previous LPS in Bonn (2022), and so much has changed in the meantime. The commercial sector had a much stronger presence this time. ESA's roadmap to ensure Copernicus data extends well into the 2040s, reflects a growing emphasis on long-term continuity. The research landscape has also pivoted: traditional methods are still around (thankfully, far fewer talks and posters using Random Forest), but there's clearly a strong shift toward deep learning and foundation models for EO, bringing in fresh talent from outside the EO bubble.

The Role of EO in a Changing World

“Without access to satellite imagery, we’d be attempting to serve the world blind.”

This is what Aarti Holla Maini, Director of the United Nations Office for Outer Space Affairs, said in her speech at the opening plenary session.

The world is facing challenges on many fronts: climate change, pollution, biodiversity loss, food security, not to mention geopolitical tensions. Satellites — and Earth Observation (EO) more broadly — are not just tools; they are our eyes in the sky, enabling better decisions, faster responses, and more transparent monitoring of the planet.

Or as Diana Ürge-Vorsatz, Vice-Chair of the IPCC, beautifully put it:

“Sentinel-2 is a daily witness of our planet's beauty, fragility and change.”

The Bigger Picture

The “Geopolitical Situation” & European Independence

Josef Aschbacher, ESA's Director General, made it clear: Europe needs to step up its space ambitions and invest more in space programmes to catch up with the U.S. and China.

The conversation around strategic autonomy and technological sovereignty in space is becoming increasingly central. Europe has been working to strengthen its independent access to space — Ariane 6 is one part of that — but now we’re seeing a push for replacing non-European hardware with European-built components, driven by the current geopolitical climate.

Meanwhile, across the Atlantic, NASA is going through budget cuts — and that’s not just affecting NASA’s own missions, but also joint missions with other agencies. This includes potential impacts on Sentinel-6C. [link].

The budget cuts were visible at LPS too. Several sessions that were supposed to feature NASA researchers ended up half-empty. One session had eight scheduled speakers; only three presented.

10 Years of Sentinel-2

On June 23, 2025, exactly ten years to the day since Sentinel-2 was launched, a dedicated session celebrated its anniversary. We got a glimpse behind the scenes with personal stories and photos from the original teams. It was genuinely moving — the passion, the nostalgia, and the pride filled the room.

One thing everyone seemed to agree on: Sentinel-2 is the most popular and widely used European mission to date.

Beyond Land: Methane Monitoring with Sentinel-2

Although Sentinel-2 was originally designed for land applications, it’s been interesting to see how many new and sometimes unexpected uses have emerged over the past decade.

One example came from Itziar Irakulis Loitxate (IMEO, UNEP), in her talk “From Data to Action: Reducing Methane Emissions with Sentinel-2.” She presented how Sentinel-2 is now being used to detect methane plumes.

Through the Methane Alert and Response System (MARS), IMEO processes over 500 Sentinel-2 images per day, identifying around 100 methane plumes each month. What makes this work notable is that the detections are sent directly to governments and operators — turning them into actionable alerts. One example involved a persistent leak in Algeria. After IMEO reported it and followed up, the leak was addressed. The estimated impact was comparable to removing 500,000 cars from the road for a year. [link]

Data continuity in the 2040+

One of the recurring themes throughout the week was data continuity for the Copernicus programme. ESA has laid out a solid and ambitious roadmap to ensure Copernicus data extends well into the 2040s, building on the success of the current Sentinel missions through a combination of Next Generation (NG) missions and expansion missions. [link]

The Sentinel-2 NG mission will feature increased spectral bands, higher spatial resolution, and potentially even night-time observation capabilities.

Similarly, Sentinel-1 NG is planned with higher resolution, a wider swath width, and other improvements.

This stood in stark contrast to the situation across the Atlantic. While ESA is pushing forward with a long-term vision, the future of Landsat Next — NASA’s plan for continuity of Landsat data — is under threat due to budget cuts. NASA has been asked to restructure the mission and explore more affordable alternatives, putting the long-term availability of open U.S. optical data into question. [link]

ESA, on the other hand, is preparing to make the case for Copernicus expansion funding during the upcoming ministerial council meeting in November. It’s an ambitious plan, but one backed by strong user community feedback — a key ingredient in justifying the investment.

The Commercial Sector at LPS

It’s worth remembering that ESA, NASA, and other space agencies primarily launch science missions. But this year at LPS, perhaps more than ever before, we saw a surge in commercial missions that mirror or complement agency-led ones.

Thermal missions are a good example. While ESA is preparing to launch LSTM, and ISRO/CNES are working on TRISHNA (with NASA having originally planned SBG but potentially impacted by recent budget cuts), the commercial landscape is expanding with missions from companies like OroraTech, Hydrosat, SatVu, constellr, Aistech Space and others — all bringing their own thermal offerings into orbit.

The same applies to hyperspectral missions. Alongside missions such as EnMAP, PRISMA, and ESA’s upcoming CHIME, we now see commercial alternatives emerge: Planet’s Tanager constellation, Kuva Space's Hyperfield missions, and more — each aiming to bring high-frequency, high-resolution, hyperspectral data to market.

The sessions on Fire Detection and Monitoring from Earth Observation Data for Rapid Disaster Response featured several contributions from OroraTech — so much so, it could have almost been called “The OroraTech Session.” A particular highlight was how their data — for example, from FOREST-2 — complements public satellite missions. It stood out as a strong example of how combining commercial and public EO data can support actionable applications like wildfire detection and rapid response.

Another notable theme was the growing cooperation between agencies, academia, research centers, and the commercial sector. This blending of roles signals a shift: as new science missions come online, commercial missions are increasingly orbiting alongside them, offering complementary capabilities and helping bridge the gap between research and real-world impact.

But what we need isn’t just more satellites…

Still, bridging the last mile — from raw imagery or analytics to usable, sector-specific insights — remains one of the biggest challenges. That’s where much of the pressure now lies for the commercial sector: to not just deliver data, but to translate it into insights that fit real-world applications.

AI Alone Isn’t Enough

In recent years, Earth Observation has been closely intertwined with advances in AI — sometimes even leading the way [link]. But this growing focus on machine learning has come with a downside: many studies now seem more interested in showcasing the model than in understanding the Earth.

This concern was even raised during a plenary session — that what looks like a novel finding in a model’s output may, in fact, be something long known in the EO community.

We’re often presented with a model, a few metrics, and a couple of nice-looking maps — but with little effort to validate, interpret or ground the results in domain knowledge.

EO research shouldn’t be driven by AI expertise alone. It needs domain understanding — the kind that can question the inputs and interpret the outputs.

Final Thoughts

The Living Planet Symposium 2025 offered more than just updates on missions and methods — it captured the momentum, uncertainties, and vision for the future of the Earth Observation field.

For me, LPS is a celebration of what can be achieved when we work together. It’s not just a gathering to attend one more session; it’s a testament to international cooperation: agencies, researchers, engineers, and private companies all coming together to push the boundaries of what’s possible.

The conversations at LPS reminded me that Earth Observation isn’t just about observing the planet — it’s about understanding it, protecting it, and acting on that knowledge. After all, the satellites we rely on are called Sentinels for a reason: they’re guardians, watching over the Earth to help us respond, adapt, and safeguard what matters most.

See you at the next one.

Let’s Hear Your Highlights

LPS2025 was massive — it was hard to keep track of everything happening!

I’d love to hear what stood out for you.

Feel free to fill out this super short form (it’s really just one question!) about your favourite sessions, talks, posters, or takeaways. [link]

P.S. At the next LPS, I strongly encourage all exhibitors to follow the example of VITO (and ECMWF) — more chocolate at the stands, please.

It was great attending the ESA-NASA International Workshop on AI Foundation Model for EO, the first workshop on this topic, and one clearly driven by user demand. The hands-on sessions sold out within hours of opening registration and around 300 people attended on-site — a turnout that likely surpassed the organisers’ expectations.

Back in 2017, when I was working on my thesis — Land Cover Mapping using Deep Learning Models (based on this, implemented in the now-retired deep learning library Theano, and this) — deep learning wasn’t widely adopted by the EO community. Traditional ML approaches such as SVMs still dominated. It’s not that more powerful DL models didn’t exist — they did — but they hadn’t yet made their way into the EO workflows. ML was a tool, and at the time, most EO experts didn’t know how to use it effectively.

It’s no surprise that it took a couple of years for U-Net to reach EO applications. I believe a key turning point was the DSTL satellite imagery competition on Kaggle.

That competition sparked a mindset shift.
Several of the top-performing solutions featured U-Net-based architectures, reflecting how Kaggle participants, many with experience in other computer vision segmentation challenges, applied those tools to satellite imagery for the first time. It demonstrated that effective deep learning architectures already existed; the challenge was adapting them to the EO domain.

I even found the blog post I read at the time by the deepsense.ai team who placed 4th in that competition, and outlined their approach.

The original U-Net paper was published in 2015; It took two years for a robust, SOTA model in computer vision to make its way to the hands of EO experts.
For a while, it felt as though the EO community was just waiting for the next CVPR paper to drop, looking to other fields to innovate, and then adapt those ideas to EO.

The EO community was following, not leading.

But the pace of adoption began to accelerate.

When Meta AI released the Segment Anything Model (SAM) in 2023, the EO community responded instantly. Within days there were Python wrappers and integration with ArcGIS. Within weeks people were exploring SAM as a labeling tool and creating QGIS plugins.

Today, the EO community is no longer just a consumer of AI; it's helping shape its future.
Major climate and weather institutions like ECMWF and NOAA have helped lead the way, playing a critical role in this shift by pioneering the integration of AI into climate and weather forecasting systems. Today, we’re seeing foundation models designed with EO at the core.
I often say that weather is the success story of EO, and ECMWF’s AIFS (AI/Integrated Forecasting System) is a prime example. It shows how — once again — the weather and climate domain is not just adopting AI ; it’s actively driving its development.

It’s also worth noting that leading tech companies like IBM, NVIDIA, and Google have increasingly become involved in the EO and climate AI space over the past few years. From IBM's Prithvi WxC and Terramind, to NVIDIA’s Earth-2 (and FourCastNet), and Google’s flood forecasting systems and geospatial reasoning, these initiatives signal that AI4EO is no longer a niche domain; it’s a key area in AI development.

Earth Observation is rapidly becoming a proving ground for frontier AI applications, where models are tested at scale on complex, real-world challenges.

For me, this workshop was a milestone. It marked a shift:

from adapting AI to EO, to driving AI forward because of EO.

EO experts aren’t just users anymore; they’re contributors, architects, and collaborators helping shape the AI domain.

The workshop spanned three days, covering various aspects of thermal remote sensing, followed by the LST CCI User Workshop, which focused on land surface temperature (LST) data products, user requirements, and applications.

At times, it felt like I was attending a graduate-level course (check out this Introduction to Thermal Remote Sensing)—the depth and structure of some talks could have easily been part of an MSc in TRS. So, it was surprising to learn that no dedicated MSc program in Thermal Remote Sensing exists!

Talks that stood out

Several talks caught my attention, but Martin Wooster’s sessions were definite highlights - his talks on Aerial Surveys with Callum Middleton (unfortunately, I don’t think a recording is available) and Fire applications!

Dave Smith's talk “How does a thermal camera work? Calibration” was also an absolute gem!

Another presentation I found interesting was presented at the LST CCI User Workshop and demonstrated how LST data from MODIS (1km resolution) was downscaled to 100m using land cover classification derived solely from emissivity values.

The Critical Role of Atmospheric Effects

One of the biggest surprises was just how critical atmospheric correction is in TRS—far more than in optical remote sensing. The "thermal folk" go to extreme lengths when it comes to atmospheric effects on temperature retrieval. Several talks explored different correction approaches, surface temperature retrieval algorithms, and their impact on final data products.

To put things into perspective: errors due to atmospheric effects and emissivity variability can cause temperature discrepancies of up to 12K! Yet, LST products manage to achieve <1K accuracy, which is an incredible feat considering the number of uncertainties at various processing stages.

“Cloud is a dirty word in Thermal Remote Sensing”

In the same sense, TRS scientists hate clouds - it’s hard to mask them and it’s often hard to separate them from aerosols.

Uncertainty Estimates in LST products

One standout practice in TRS is that LST products provide per pixel uncertainty estimates; a QA product that assigns a ±K uncertainty to each pixel, tracing its origin across the processing workflow.

Commercial Companies and the future of TRS

Over the past decade, several commercial companies have entered the thermal remote sensing market. Representatives from Aistech, Constellr, OroraTech and SatVu attended the workshop, highlighting the growing interest and investment in this field.

In the next 3–5 years, we’ll see the launch of major agency-led missions like SBG (NASA), TRISHNA (CNES & ISRO), and LSTM (ESA), bringing higher-resolution thermal data and better global coverage. At the same time, a wave of commercial satellites is set to fill gaps with faster revisit times and new applications.

It really is an exciting time for Thermal Remote Sensing.

Special Interest Group on Thermal Remote Sensing

Dr. Agnieszka Soszynska and Dr. Jennifer Adams organised this workshop. In 2023, Agnieszka and Jennifer revived the Special Interest Group (SIG) on Thermal Remote Sensing, after a few years of inactivity.

Check out the SIG page, and the resources posted there. Also, be sure to listen to Thermal Lens; a podcast series on thermal remote sensing!

Recordings and slides from the workshop are available here.