We are excited to announce the release of our 2026 Geospatial Tech Radar! This is our fourth iteration of the radar (view past editions here from 2023, 2024, and 2025), and each year we look forward to collaborating across teams and disciplines to put together our reflections about shifting trends in geospatial tools, data, standards, and techniques. 

Community perspectives are crucial when it comes to rapidly evolving technologies, and we’ve put together a few highlights in the blog to summarize our thoughts about this year’s developments in geospatial tech. This year’s radar discusses the importance of provenance, as well as tooling advancements both AI chats & agents and in the cloud native geospatial sphere.  

Our Core 2026 Geospatial Tech Radar Findings

Although we’ve summarized our findings and thoughts below, we encourage you to form your own opinions and reflections about the full radar before reading. Let us know what you think! 

Improvements in AI Tooling: Chats & Agents 

Geospatial chat interfaces

We’ve seen geospatial chat interfaces improve a lot over the past year. There have been plenty of prototypes, and there still are, that don’t do much beyond a demo. But we’re now seeing them get to the point where they solve real problems, which is why we moved Chat interfaces for geospatial data from Trial to Adopt this year.

A few things came together to make that happen. The latest models are much better at planning, so they can take a question like “how much solar capacity did this region add over the last five years?” and break it into steps, investigate options, and recover from errors or ideas that don’t work out. MCP (the Model Context Protocol, a standard way for an AI model to call outside tools and data) has made it much easier to connect those models to geospatial data. The software around the model (the harness) has improved too. The harness handles things like where the agent keeps intermediate results, how it runs the code it writes, and what it remembers between steps. In our experience, the harness matters about as much as the choice of model.

We’ve been building this ourselves in Limner (previously called Agentic Queryable Earth), a geospatial analysis agent built on the open source LibreChat platform. When you ask it about solar growth in a region, it searches satellite imagery, writes and runs Python to do the analysis, and returns an answer you can trace back to the source data. It runs in a web browser, which matters for the analysts and decision-makers we’re building it for, since most of them aren’t going to install a developer tool to get an answer.

Limner isn’t the only way to build one of these. On our Knowledge Mesh NLP (KM NLP) project for NOAA, built with TechTraverse, users ask climate and weather questions in plain language, such as the average sea surface temperature in the Chesapeake Bay on a given day. The answers are computed from 176 variables across 36 NOAA datasets and come back as plots, maps, animations and GeoTIFFs. Instead of letting the agent write any Python it wants, we gave it a curated library of about 30 tested functions for slicing, computing, and plotting data, and it builds each analysis by combining them. That gave up some flexibility, but it made the agent more predictable and much easier to check. We think both approaches have a place, though for most use cases letting the agent write its own code is now reliable enough. Models still make mistakes, but they usually notice an error and recover from it, and because the code runs in a sandbox (an isolated environment with its own security controls), a bad piece of code can do much less damage.

Tools for running agents

Putting an agent in front of real users takes more than a model and a chat window, and many of the supporting tools have matured this year.

We use LiteLLM as a gateway between applications and model providers. It gives one place to manage access to models from Anthropic, OpenAI and Google, set spending limits, and connect to an organization’s login, and we’ve run it for systems with thousands of users. Langfuse records each model call and tool call an agent makes so you can look at them afterward. We’ve used it to track down why an agent was slow and why it gave a wrong answer during user testing, and we now turn it on at the start of any agent project.

Agents that write code also need a safe place to run it. LibreChat open sourced its Code Interpreter this year, and we run it with Lambda MicroVMs, an AWS service launched in June that gives each session its own small virtual machine. It has worked well for us so far. One thing we learned along the way is that Python’s scientific libraries read many files when they load and MicroVMs lazily load disk sectors over the network, so our first import pandas took more than 30 seconds. After we configured the image to preload those files, it took about two and a half seconds.

The tools developers use to write code with AI have also improved quickly. In earlier years we listed individual products on the radar. There are now enough good options (Claude Code, Codex, Cursor, Aider, Pi, OpenCode and others) that we combined them into a single Agentic Coding Harnesses blip in Adopt. Each has tradeoffs, and which one fits depends on the models you want to use, your organization’s security requirements, and personal preference. One side effect we’ve noticed is that these tools make it easier to use libraries that have rough edges or thin documentation, because the AI can help write the code that connects things together.

The Importance of Provenance

Our Agentic Data Storage blip describes how we approached this in Limner. Large results the agent produces are saved along with a record of the API calls and code that produced them, so you can trace a final answer back through each step to the source data.

Provenance was also one of the stated goals of our KM NLP work for NOAA, and that project taught us a lot about what users actually want. The app shows the datasets, granules and citations behind each answer, the plan the agent followed, and a readable version of the analysis steps. In user testing, several participants asked which dataset the app was drawing from before they would trust any result. We also looked at giving answers a confidence score, but the options we tried were either hard to interpret or unreliable, and showing how an answer was reached turned out to be more useful.

We’ve seen the same idea elsewhere on the radar. STAC Workflows pass metadata between processing steps that records how each output was made, and the new embedding conventions link each embedding to the model and imagery it came from.

Provenance is different from observability. Tools like Langfuse help engineers see what an agent did so they can fix problems. Provenance is for the people using the answers, and we haven’t found much tooling for it yet. There are standards like W3C PROV and the STAC processing extension, but they weren’t designed with agents in mind, so most teams, including us, are building their own. We’d like to see more of this built into agent frameworks and shared across the community, and we’d like to hear how others are approaching it.

Refined Tooling for Cloud Native Geospatial Adoption 

Due to this discrepancy, the community recognizes the need for better, more user-friendly tools that take into account many of the lessons learned over the last decade of CNG and apply them in opinionated ways, instead of leaving users to figure complex things out on their own. Some of the tool blips in this year’s radar in this vein include async-tiff, portolan, and lazycogs, all of which are new to the radar in 2026.

In addition to improved tooling, CNG-related formats and standards are also adapting to become easier, more efficient, and capable. We’ve captured several blips in this theme: GeoArrow, GeoParquet, and Virtual Zarr stores, for example.

We’re excited about where this push for usability is heading. As tooling in this space improves, users are able to envision what it might look like for them to transition their work into the CNG ecosystem. It feels like the last few years have represented slower progress on the tooling front, but that is rapidly changing. Are we seeing the effects of AI in this recent momentum? Likely yes, but that’s not the only driver.

Community sentiment recently reflects the feeling that we need to make another big push forward, and that maybe we slowed down a bit and didn’t mean to. At the STAC Japan meeting this August, these ideas surfaced heavily, with participants recognizing that there’s still a big gap between where the standards have been and where we feel they need to be today, and how improvements to both the specifications and the tools can better meet users where they are today. 

Bonus “Big Picture” Tech Radar Themes 

Open source

Most of the AI tools we’ve mentioned here are open source, including LibreChat, its Code Interpreter, LiteLLM, Langfuse, Pydantic AI and FastMCP. MCP itself moved to the Linux Foundation in December 2025, so it’s now governed by a neutral organization. Open source matters a lot in our work because it lets us run these systems inside our customers’ own cloud accounts and change them when they don’t quite fit.

EO Embeddings

EO vector embeddings continue to be one of the most active areas on the radar. An embedding is a list of numbers, generated by an ML model, that summarizes what’s in a patch of satellite imagery, so places that look alike end up with similar numbers. That makes it possible to search large amounts of imagery for similar places, and with the right models, to search it with text. Six of the eight embedding blips this year are new.

Some of those are techniques we’ve been working on. Embeddings trained alongside text let you search imagery with a phrase, and we’ve been using them to look for change over time with queries like “houses with new swimming pools” or “forests cleared for housing.” Finding change takes more than finding similar images, and we think there’s a lot of room for new ideas here. We also tried having a large language model caption imagery and then embedding the captions. With Claude Opus the results were comparable to a model trained specifically for satellite imagery, but smaller models didn’t do nearly as well, so for now it’s expensive to do at scale.

Others reflect wider adoption. Google’s AlphaEarth embeddings cover the Earth’s land surface at 10-meter resolution for every year since 2017. The public mirror of the data on Source Cooperative has served 178 terabytes as of October 2026, and Google has committed to producing a new year of data annually.

Standards are still taking shape. In March, a group of companies and researchers, including Element 84, met in Worcester, Massachusetts, and produced geoembeddings.org, a set of conventions for storing and describing embeddings so that data from different providers can be used with the same tools. It’s an early version (0.0.1), and a second sprint in Zurich in late October will likely change it. That’s a big part of why most of the embedding blips are in Assess. They’re worth experimenting with now, but we expect the formats to change over the next year

What we’re watching for next year’s Geospatial Tech Radar 

A couple of trends aren’t on the radar this year but have our attention.

The first is smaller models. Open-weight models that can run on a single server have gotten much more capable, and there’s a lot of interest in them as a way to spend less on AI. One challenge for our work is that several of the strongest come from Chinese labs, and federal rules increasingly restrict those models in government systems and defense contracts. For agency work, that narrows the options to models like Gemma, Llama and Mistral.

The second is AI running on satellites. In April, a Loft Orbital satellite ran Google’s Gemma 3 model in orbit, using software from NASA’s Jet Propulsion Laboratory to answer natural-language questions about imagery it had just captured without first sending the images to the ground. Planet ran object detection onboard one of its Pelican satellites the month before. It’s early, but this may be where smaller models matter most for geospatial work, because a satellite can only send so much data to the ground on each pass.

With the publication of our 2026 Geospatial Tech Radar we are looking forward to hearing feedback from the broader community! Do you agree with our findings? Is there anything that we’ve missed, or that you would have removed in this edition? Although the tech radar reflects our team’s experiences, we always love to discuss how it aligns with the opinions of other folks working in similar areas. Get in touch if you’d like to talk about it more!