Anyone following me on Strava or LinkedIn will know I’ve been travelling a lot in the last few months1; in all honesty, it’s been ridiculous. However, I’ve been excited to get on a lot of stages to share what Sparkgeo has been up to recently (primarily Prescient). In doing so, I’ve formed an increasingly strong opinion on what the new shape of geospatial will be. The main themes are access, control, and decentralization.
First, an anecdote from Dubai:
“My boss wants to be able to ask questions about a land bank our family office is investing in. He doesn’t want to hear the word ‘data’, but he wants to quickly ask a question, and for the answer to be available at all hours. He understands the business, and he doesn’t want to bother anyone. Ha! He really just wants a conversation with the proposed location.”
Not an everyday example, but a compelling use case: a non-geospatial Subject Matter Expert (SME) wanting to ask questions of a discrete data set that describes a piece of geography. If we extrapolate this, we can see exactly the same pattern across so many GIS use cases, from municipal asset management to resource analysis to defence and intelligence.
The future is a text prompt in the hands of SMEs, accessing a variety of well-documented cloud-native geospatial products, combined with proprietary enterprise data, built into ephemeral interfaces by AI that last only as long as it takes to make a decision.
I’m exhausted already; we have so much work to do…
GIS starts with the question
It’s no surprise to anyone that the text prompt is clearly the de facto interface of computing. To some extent, it always has been: from Emacs to search, and now to AI, we type commands, expecting outcomes. I think it is reasonable to assume that typing at some point will give way to speech, so perhaps we can just lump these together as “language-based interfaces”. But asking a question of a system should be considered the primary interface.

If we consider the dominant designs of GIS over the last 30 years, I don’t think losing the blank map, the legend and the menu bar is any real loss. In fact, the only innovation this design has seen was Google giving us a globe with pre-populated imagery. And that was a revolution.




The dominant geographic interface moving from the stark emptiness of a blank canvas to a text prompt may not seem like much of an improvement. Callously, I wonder if this is just cutting out the middleman. On reflection, GIS teams are also typically interacted with via a text prompt, otherwise known as an email. Has the GIS team been rolled into a text prompt? That is worth ruminating on, over a stiff drink. Back to my point, though, geospatial capabilities will be more available to more people. The barrier of the blank UI has been overcome. This reminds me of the Venn of geospatial people.
So, if the de facto interface becomes a prompt, how does one interact with the data? Well, consider the output of a geospatial activity: traditionally, it has been a report, a chart, or a map; more recently, a dashboard. Well, we can create those very easily within an AI-powered environment. In fact, it might look a little like this…
I concede the most beautiful maps will still be created by artists with an eye for shape and colour. I hope that is true for a long time. But for more functional applications, a series of components that consistently present data and analysis is a very practical capability. Again, this is another lesson from Google Earth: though I was never a fan of the Google marker icon, it certainly made the zeitgeist.

So, using AI to build ad-hoc, disposable interfaces from repeatable UI components seems like a credible pattern. These should probably be wrapped up into skills, but that’s a detail. Components assembled in this way allow for a consistent look and feel, and some branding.
Before you push back on this, consider: hasn’t GIS always been an ad-hoc interface for one-off analysis? Then once the process is shaken out, automation and dashboarding can happen. What has changed? The personnel? The workflow? The outcome?
But the data!
I hear you yelling at me about hallucinations and data quality. Quite reasonable. But why is data bad now? Mainly because we don’t manage it correctly, or we refuse to document honestly what the appropriate uses are. (Im)famously, there is a data product used in the BC forestry sector that we could argue is the wrong scale for strategic planning and also the wrong scale for operational activities. Yet, this obvious fiscal compromise is absent from the metadata. It just is. People know. People accept. These data products exist across the geospatial ecosystem as part of the lore.
So, the documented fitness for purpose of a dataset should become standard*. An example I was using yesterday was Landsat being used for car counting; I have a strong suspicion that Claude would have a crack at it, but clearly it would be a poor outcome. Yet we cannot document all the ways an image can be used; that would be an infinite list. Instead, we need a data product with a skill or extension alongside that states, for example, that “features of xyz size” could be discerned in this image.
An expression of fitness for purpose: data should be self-describing
If data is self-describing, then the AI can decide if the feature they want is discernible or an algorithm is appropriate. Luckily, STAC offers the opportunity for extensions, and our friends at the OGC are pushing hard on building blocks. Yes, people, metadata has become even more important, perhaps more important than the data itself. That lore that we geospatial people keep in our heads must be shared.
But access too. Data needs to be available. How much data sits on the shelves of surveyors, locked up, wasted? Now, not every data product should be open-sourced, but data should be accessible to those who have authorization. Investing in data is like buying a house while investing in technology is like buying a car. Cloud-native data distribution is an investment in data accessibility. Because if data is inaccessible to those who need it, it may as well not exist. I’ve been lucky enough to see Katie Baynes’ “Boring at scale” talk twice in the last few weeks; she makes this point far more eloquently and using big letters.
As part of this journey, decoupling data from sitting inside technology is increasingly making sense. By that I mean data held in proprietary data systems reduces access (think Oracle Spatial- sorry, Oracle). Yet, storing that data close to compute is critical. For instance, being able to run a Python notebook on the Earth Observation Data Hub allows me to derive insights where the data is, without me having to move it. The combination of compute and storage accessed via authenticated APIs is therefore a sovereign solution. If this seems like a shot over almost every software company’s bow. It is. But it’s also true: if a system wants you to stay within its ecosystem to access a particular tool, be aware. Authorized access to your own data with your own choice of tools should be a basic requirement. Your data, your way.
If there is a critical place where Geospatial people will remain employed for a long time, it’s in the acquisition, management, and distribution of data products.
The end of the flat map
This is a long post, and I expect I have hurt enough people’s feelings already. But I will tease one more concept. Why do we need spatial reference systems? I mean, the basic idea is to transform data captured on our lumpy planet to a flat space: a map or a screen. But we have more than enough compute to model globes on virtually any computing device now. This, again, is a dominant design; we do this because we have done it this way forever. Instead, we should get really good at discrete global grid systems and commit to our knowledge of our geoid. Oh, and that geoid should move, because ours does. Time is a first-class citizen in geography.
Geography is marvellous; it’s time we let more people marvel.
I have one more trip lined up: see you at SatSummit in STL, next week!




