Moats

Other than sovereignty, moat has got to be the most popular word in the current technology lexicon. But I do think that moats are disappearing fast. GIS and geospatial will not be immune. We are seeing people on LinkedIn suggesting they might rewrite the traditional GIS toolkits over a weekend, and then follow through. I know a number of people who have built their own GIS tools. In no uncertain terms, we are in an age of personal software. But it’s not all doom and gloom.

So, how should geospatial people think about a “no moat” strategy?

Warren Buffett first coined the phrase. He was describing the features of a business that he looks for when investing. Others might call these unfair advantages: features that give a business a competitive edge. He talked about network effects, intangible assets, cost advantages, switching costs, and operational scale. Jack (above) is primarily referring to software when he asserts there is no moat. But the point is well taken; for many knowledge businesses, and geospatial is one, the ability to build personal software has become deeply disruptive. I wonder, though, if this movement is worse for those building the more cloud-oriented, younger generation of tools than for the incumbents. This speaks to one single business advantage that Esri might now have: distribution.

But I get ahead of myself. First, I want to outline a couple of key features of our new world order.

Share Strategic Geospatial

UI for you and I

The UI for search and discovery has changed. You could argue that the UI for software development is evolving, too, though I might get yelled at for saying so. Where once we clicked buttons with mice and trackpads, then tapped touch screens, now we type. I expect we can thank Google for the simplicity of the single text box. But its sudden evolution to ubiquity is jarring. Yet there is no doubt that text is a very flexible interface. Some might say infinitely flexible (as always, insert joke about Shakespearean monkeys). I do wonder if the future will evolve further toward being speech-driven, but in reality, the differences between text and speech lie only in how the words are encoded. So, we must accept that Graphical User Interfaces are likely to be the domain of deep technical experts doing very specific work.

Ad-Hoc-ishness

I’ve recently spoken a lot about non-determinism. It bugs me that Large Language Models (LLMs) treat space and time as malleable concepts. This is because these tools treat all data as text first, and guessing the next most likely character, word, or phrase is not necessarily a useful cartographic process. That said, we all agree with Tobler and the concept of spatial autocorrelation, so we are not a million miles off. But places at a particular time are just that: places. So the non-determinism of LLMs is often jarring to those of us who feel that data can and should “be accurate”.

The advantage of non-determinism is that we can create new and novel things and processes. They may not be right, but that can be interesting, and they can be specifically designed for a user's purpose. Again, personal software.

Build components: New users, old problems

I believe this evolution provides a new opportunity alongside a very old problem. Firstly, everyone can now ask for a map. I was in Dubai this weekend, and I asked Claude for a walking tour of Old Dubai, and it did a great job. Well, I needed to use other navigational tools on the ground, but it took me from zero knowledge to a good start within seconds. The response included a map. The map gave me enough context, but lacked some critical navigational features. I have many criticisms of AI, and specifically AI in geospatial, but for generic, non-specific activities like this, AI is amazing.

Share

Note that I would not have asked a GIS professional to do this. So, in effect, this is a new use case. I expect I am not the only person doing this. Text prompts have significantly reduced the technical barriers to using geospatial or location technology. This might have been done in Google Maps before, but it would have been a real pain to achieve. So the technology that answers a human question and provides an adequate map as part of the solution is hugely valuable. I also note that this is somewhat new. Many of you will push back and say we’ve had maps and text for decades; that's true, but this wasn’t a map; it was an ad hoc interface that met a need. The map was just a logical part of the interface.

This points to three key ideas:

1. We need to consider a number of user types: Analysts, Professionals, Consumers, perhaps more? Great news: more people with access to geospatial technology!

2. Interfaces are no longer fixed. Fearsome, ad hoc interfaces introduce so much complexity.

3. Expectations and accuracy. Same old: expectation management has always been a problem when geospatial interfaces with less technical experts.

One of my personal missions has been to get “good geography” into the hands of more people, so, on one level, I am very excited about what LLMs offer. The fact that interfaces will be delivered to users based on their needs makes me think more about using components that AI can assemble into ad hoc interfaces. If we think about this, we will quickly realize that this pattern exists in both the consumer and professional spaces: componentization will result in adoption. Finally, expectations become harder. My team’s work on location accuracy within LLM environments implies that many will be misled over the next few years as data quality issues get shaken out.

Be closer to data: Make data make sense

Investing in data is like buying a house. I’m like a broken record. But that one statement rings true again. AI cannot create data. Instead, it’s an avid user of data. So, to make yourself useful to AI, create data and make it accessible. Certainly, with our Prescient product, this is what Sparkgeo is doing, so we are putting our money where my mouth is. But I feel this is logical too. Interestingly, the data accessibility aspect of this assertion is not well executed at present. To adequately integrate with AI technology, it's clear that commonly understood, ideally open, standards will be critical.

Cloud-native technology is a logical choice for distribution. The idea that data can be assembled from spatio-temporal asset catalogues (or whatever the next iteration will be), or even catalogues of catalogues, enables the creation of deep, discoverable data catalogues. Adding compute alongside data storage supports both sovereignty and the speed of insight delivery.

Provenance will also become more important. Once the domain of the nerdiest of geospatial people, metadata is now of paramount importance. I know, you will now tell me metadata was “always important”. Sure.

Well, now it's even more important; more people will be asking geo questions, so understanding how to answer them and a sense of the provenance of the data we use to do so is critical. Within a non-deterministic world, understanding why certain recommendations are being made is critical. That's data provenance.

In Moat-ion

This post is quite long enough, but “the moats of geospatial” could be an entire book. Instead, this is just a short discussion, with a couple of takeaways:

1. The UI of the internet has changed, so the UI of geospatial will have changed.

2. Forget UIs, build components and let AI be your UI.

3. Data and access to data are a moat. The data that’s easiest to access will be used.

But my message is simpler. Think deeply about what you do, and why you do it. I also think expertise and networks are moats. But be brutal in your expectations of AI. Don’t let your (or my) “spatial is special” attitude cloud your judgment. At the same time, don’t give up hope. There is still plenty of work to do!

Going back to an earlier assertion: distribution is also a moat. I don’t think Esri is going away any time soon. Large enterprise organizations are not going to vibe code their own geospatial capabilities anytime soon. Even though Starbucks committed to rewriting their own operating system, which I actually applaud, I am not convinced they will drop everything, and I am not convinced others will either. That said, given a noticeable trend, they might over time. Especially if geodata is not made available to other systems or AIs. My observation is that for large GIS providers, staying close to their customers and staying relevant will be critical. Ultimately, avoid competing with AI at all costs. They have more money and, today (October 25th, 2026), are primarily focused on building models to write software that builds better models. Not geography.

I have no doubt I will be writing more on this subject!

Subscribe now

That word again. It’s like “dual-use”, annoyingly investor-y without any real explanation. Everyone gets to define their own sovereignty, for the convenience of their own argument or product. I guess that’s the power of language. For the purposes of this discussion, sovereignty means “keeping your own stuff where you want it.” Which is interesting because sovereignty is then aligned with ownership. Therefore, the sovereignty of a data product or system is defined in its midstream engineering: where the data is and how it is accessed.

So, the punchline up front:

The Cloud-Native Geospatial movement, it turns out, does a great job of addressing the questions of sovereignty and ownership. Cloud-native is not about moving data but instead asking questions of it. If the data stays where it was originally put and its custodian gets to decide who interacts with it.

I feel the geospatial community is currently undergoing a renaissance of thought about data ownership, access, and, dare I say it, licensing. For quite some time, we have been very keen on openness, especially when it comes to data. Even the most proprietary companies support and encourage open data. But open data is again being questioned. Open to whom? Or, a better question: open to what?

Share

The previous dominant design for data use in computing was to make a copy of a piece of data and store it on an accessible machine. That expanded to storing a copy on a server; then to buying and selling ownership of pixels. Ultimately, we are now moving those pixels to different S3 buckets, often on the same cloud. So, the same pixels are stored numerous times across the internet. We laugh at people who buy and sell NFTs, yet here we are in geospatial, buying pixels with restricted licenses that only some people can look at. Yet those same pixels can be sold with a different license for a different group of people. More often than not, little provenance or lineage is provided; we just trust the pixels are representative. I should really brand geoNFTs*, and we should laugh, because it’s not at all how the cloud is supposed to work. But the joke is on us, or worse, the taxpayer, because what we are doing is really expensive.

Additionally, every copy is a loss of control.

If I allow my data to be downloaded, it is not sovereign; it is under someone else’s control. Indeed, different versions of it could be under the control of numerous people all across our planet. There might be a license attached to it indicating how desperately upset I would be with the data’s misuse. But in the end, bad people will do what they will with the data, with or without a license: the data has left my locus of control.

Subscribe now

First, I want to dispel a fallacy. Cloud-native doesn’t require a hyperscaler. The hyperscalers have wonderful tools, and all the modern conveniences of infinite compute (within a fiscal reality). But you can take cloud-native philosophies and build your own cloud; it’s just someone else’s computer, after all.

The internet is a network of computers that talk to each other. A cloud is a network of many computers that can communicate with each other quickly or with the internet a little more slowly (speed, distance, time, you get it). We obviously have clouds of clouds these days, and more compute coming online every day. So when we talk about Cloud-native, we are suggesting using that vast storage capability to store data and our networks to send much smaller requests and responses.

That’s the key. But it’s hard because this is a newer pattern.

This pattern requires orchestration and access to compute alongside stored data. That compute must be able to interpret a request, interrogate the data, and provide an answer. Go and take a look at the UK’s Earth Observation Data Hub for an example.

This activity is not novel; at Sparkgeo, we have been following this or similar patterns for decades, others even longer. But it’s still not the dominant design. At the excellent Cloud-Native Geospatial Forum in Utah a week or two ago, there must have been 200-300 keen practitioners, but I suspect that might be a large proportion of those doing this kind of work.

So how does that give you sovereignty? If I allow users to connect to a piece of data via a request, perhaps through a Python notebook, an API, or an MCP service, then I can choose to deny or satisfy them based on agreements and purchase orders. Perhaps I provide authorization to “work with” the data; if I subsequently withdraw those rights, then those users cannot touch the data. So the data’s sovereignty is managed, and where it lives (the word soil seems important here) is my choice as the custodian.

Using a cloud-native approach, access is managed through software, so the software orchestration layer, the midstream, becomes the key to access. And access is as much about authentication and authorization as anything. While not without complication, data sovereignty can be managed.

Implicit in this discussion is a reference to MCPs and APIs using cloud-native technology. Prompts are becoming the de facto interface for computing; this may evolve to speech. But it means that access to data via MCP or similar is a major enabler for the practice of digital geography. It now means that if we build appropriate systems, non-experts can start asking robust geospatial questions.

This works for middle powers, but it’s also about data trusts, corporate networks, trusted contractors, campuses, club goods, inter-agency sharing, project-level compartmentalization, and privacy.

Think about a group of countries that want to share data. Each country may have a different data set that they would all benefit from in aggregate.

Each country can store its own data on its own soil (there, you see?) whilst an orchestration layer allows access to the group as long as the agreement is in place. Upon termination of the agreement, data sovereignty is still assured. This pattern is enabled by Cloud-native technology. In fact, the idea of a virtual yet still sovereign constellation is entirely possible.

*Turns out geoNFTs actually exist

If you are interested in cloud-native technology for your enterprise, Sparkgeo has assembled a selection of cloud-native tools and practices into a convenient package called Prescient. We’ve done the packaging and wrapped it with enterprise-ready features like auth and multitenancy, making cloud-native technology more accessible for no-fail environments. Get in touch.

Subscribe now

I’m not a very metaphysical person. But if you will allow me to get a bit woo-woo for a second, I would point out that we are all sharing a common experience.

How we feel about this experience is up to ourselves, and I am willing to accept your reviews. But this experience is happening at a particular place in our universe, in this hotel. And it’s happening… right now.

As a simple creature, I tend to think that those two attributes, space and time, are somewhat fixed. They happened. Perhaps our universes diverge from this point, but now, and just then, they were common. In fact, this hotel has been here for some time, Claude told me, since 1974; Snowbird itself thinks it opened in 1973. Details. The point is, this place has existed for some time.

My name is Will Cadell, and I have been running a company called Sparkgeo since 2010. We build cloud native geospatial data pipelines. Prior to that, I worked in agricultural research and operational forestry. I moved to Canada 20 years ago to climb mountains, and I’ve not really gone home yet.

I have been writing the Strategic Geospatial Substack for the last five years. I’ve been providing advice to enterprises, startups, and venture funds for much longer.

The nature of a large language model is that answers are not always consistent. In fact, that’s often their superpower: the ability to review ideas and come up with new solutions. Annoyingly, that’s why they are good at code. Software development is also non-deterministic: there are many ways to answer a particular question with software. The same is true of prose. You or I can try to describe the same idea in writing, and we could each do it a hundred different ways.

There is something about monkeys and Shakespeare in here. If I could just find the words to articulate it.

However, if you speak to the hotel’s architect, or the HVAC guy, or indeed the concierge in this hotel, I’m quite sure they will all agree that this hotel is, in fact, here. Undisputed.

So, location is determinate. What irks me is that I can ask a probabilistic system for a determinate fact and be given a plausible answer that’s wrong. Those are Claude’s words, not mine.

I made an agent that can pass the GISP exam.

It’s based on Claude, but with a variety of additional skills, geospatial awareness and a deep knowledge of “the shapefile.” My agent is hard to communicate with, so I have to be very explicit. Often, my agent misunderstands me, asking for particular specificity about seemingly irrelevant details, and then offers me a map of the wrong subject. Given that most GIS offices communicate via email, which is essentially a text-based prompt, all this should be somewhat reminiscent and a little concerning to those who identify as GIS people.

But my bigger problem with this workflow was the moment I asked my agent to mark two points indicating local wildfires, and it enthusiastically placed them in the completely wrong places. When I called it out, the response was “good catch.” If I hadn’t known they were wrong, we would have all carried on merrily in complete ignorance.

Here is an illustration.

I ask my agent for a cloud-free image of London, UK. We’ve already created a skill for looking up both Microsoft’s Planetary Computer and the UK Space Agency’s Earth Observation Data Hub. For whatever reason, this time it went to Planetary Computer. And I am given a view of parched South East England. England’s brown and dusty land.

Feeling optimistic, I ask for a point to mark the Tower of London.

You can see that I am assured that on a different map (I guess I wasn’t explicit enough) I will be provided with a point indicating the Tower of London in crisp detail, against a crystal-clear image.

Well, here it is. It’s the same image; to be fair, it’s a beautiful Sentinel image. At first glance, the point is close, except it’s actually on Tower Bridge. And if we zoom in, most of us might push back on the word “crisp.”

This started us on a journey. How good are the Frontier Labs at location?

Firstly, a reminder about location and specifically, navigation. Partial success is not really acceptable; you either get somewhere, or you don’t. Now, humans are thinking computers, so if I’m on Tower Bridge, there is a fair chance that I will get myself the rest of the way to the Tower of London. But it’s not guaranteed. This is what I mean by:

90% right is 100% wrong.

Apple discovered this with the first release of their maps product. Since then, I would argue they have become very good at location and navigation, but it feels like they might have initially underestimated the problem’s scale. Potentially not considering that spatial is a bit special.

So, our non-deterministic robot friends face a problem: They have a per-question answer budget within a probabilistic computing framework, in which not answering is unacceptable. So, like the most enthusiastic intern in the world, they blurt out the best answer they have within their budget.

Everyone in this room knows that, while I state location is not probabilistic, points of interest do change over time. A Starbucks can become a Pete’s or a Subway.

Indeed, maps should be living data spaces that represent our thriving cities.

That said, you would be forgiven for pointing out that the Tower of London’s foundations were, in fact, laid at the direction of William the Conqueror in 1066. Potentially, over the intervening 960 years, we could have shaken out some of the intricacies of natural-language gazetteers.

Nevertheless, places do change, and these programmatic features can conspire to create horrific circumstances. While I often think the work we do is only incrementally useful. And, at the risk of being lynched at the bar later (I wasn’t), potentially a bit niche. At the same time, it is of the utmost importance.

Getting it wrong can result in tragedy. Location matters, a lot.

Today, there are benchmarks for every facet of AI, and several for geospatial activities. Some for geospatial foundation models, some for geoprocessing algorithms, some for a model’s performance in GeoGuessr. But I was surprised to find there were very few for measuring the performance of what you might call ‘consumer location questions’, questions like “Where is the Tower of London?” For instance. So, at Sparkgeo, we have been developing ideas and comparative tools to measure the performance of different models in understanding location.

We wanted to overtly solve the consumer side of the problem. So, not how well a Frontier model can buffer or intersect data. Not how well they can find data products or reproject them. Not how well a geoprocessing script created by Claude works. Instead, how well a Frontier model can resolve a real human problem using natural language and its understanding of the world. The kind of question you might ask Google or Apple Maps.

In doing so, we broke the components down into “Data Quality,” “Spatial Context,” and “Model Reasoning.”

We then bucketed different question types into nine categories for comparison. We felt these describe the most common navigational or situational-awareness use cases.

They are reasonable questions, but we can all see how these might stretch an AI, because we know there is nuance in these questions and a reliance on good location data and some context.

But critically, we also wanted to create question types against personas. Our personas represent the analyst, the professional, and the consumer. The analyst provides their questions with a great deal of operational detail, the professional provides some specificity but is more conversational, and the consumer is extremely terse in their requests, expecting a great deal of inferred context.

Each persona asks their question differently. Here is an example:

Each question is run on a fresh model in a new account on a separate Amazon Workspace. No inferred prior knowledge of any of the personas or those people running the benchmark.

We ran these questions over 6 North American cities. You will notice a commonality with places that are local to my team. This is because we wanted to know how “good” our own benchmark was. To do that, the best way is to get ground data. So yes, this is very North America-centric, and we will figure out how to make it a global solution in time. I suspect the Overture Maps Foundation might be a component.

Now, I am running out of time quickly, and the work we have done is, so far, preliminary. But I wanted to show some teasers. Our first run was over 500 questions. We expect this to grow enormously as we develop this process.

Let’s start with restaurants within a kilometre.

A kilometre is more than a foot but less than a mile for those in the audience unfamiliar. In this example, we asked the frontier models to list restaurants within a kilometre of a particular point, knowing that the correct answer was eight (lower-left pane). The answers vary widely, with Gemini returning over 30 locations and getting only 4 of the actual restaurants right. We see this as a problem of data and spatial reasoning; it largely ignores one of the key criteria: distance. ChatGPT, on the other hand, seemed more willing to provide wrong or old data. Grok and Claude seemed to do best with this question.

Then onto areas.

A park is an area; every model was confused by the concept of an area versus a point, failing to find one of two parks within a five-minute walk of a particular point. This is a failure of spatial reasoning and, indeed, the lack of a spatial model beyond points and lines.

I’m not even thinking about the nuance of where the various entrances to the park might be. Or, indeed, the concept of routing to a park’s edge.

We also found some interesting spatial reasoning challenges

This is the Classic Canadian dilemma: Where is my nearest Tim Hortons?

But this question is more about spatial nuance in the word “nearest”. The confounding factor here is a bridge that has been impassable since 2024. So, nearest becomes a question of interpretation and context.

Grok figured this out every time, and Gemini and ChatGPT in most cases. Claude chose the wrong one twice, once via a connector across the river that doesn’t exist. Gemini once sent the driver to a store “800m” away, which was, in fact, over 3km wrong.

Finally, I wanted to show our data accuracy results.

Ultimately, Gemini and Grok score the highest and are interchangeable at a city level. Claude and ChatGPT score somewhat lower.

We will be publishing these results and our full method in the coming weeks. But overall, you can see a significant opportunity for refinement in both spatial reasoning and data quality.

I think there are interesting opportunities to harness the non-determinism of frontier models for reasoning with more accurate data. I visualize this as adding deterministic control points to solidify a non-deterministic model, similar to how ground control pins a polynomial down for geographic correction.

We could consider applying a POI-based and/or spatial-reasoning MCP to pin down our robot friends. But is a consumer likely to connect to a POI MCP service before finding a place to get coffee? Seems unlikely. The real answer is to encourage our robot friend to take space and time as foundational, while constructing their ideas on those foundations.

In the end, if you are planning a high-consequence event, check your AI’s work. It might be close, but it’s probably not winning any cigars.

Share

As I grew in my career through the 2000s, this only became more obvious. The GIS role was a transactive data role, even if we were using regular expressions for some tabular pivot in Awk (because at that point ArcInfo could not do those more complex attribute manipulations) or building programmatic indices from Landsat images, we were taking raw geographic products and manipulating the data (pixels, points or polygons) into something else for consumption in another interface. That interface could have been a website, a GIS, a map, a report, a spreadsheet, or a PowerPoint. Very rarely was the data the final product. The data was the resource, and we would refine that resource into the product our customers or stakeholders were seeking.

Every step in that chain of events would be held in the analyst's head. And each step is akin to a “break in gauge.” This is a railway term indicating a change in the gauge of railway tracks, necessitating one of a variety of complex engineering operations, or passengers and freight changing trains entirely. For us, this is a point at which a data product transforms to meet another product standard.

The idea of a “break of gauge” illustrates two points. Firstly, that common standards can be a huge benefit to society at large. Changing data to meet specific but arbitrarily different data standards is a waste of bandwidth. If a geospatial or Earth observation company thinks this is clever or in some way a moat, it’s not. It’s a barrier to adoption and a needless burden on those providing analytics. However, it highlights my general point about the need for robust midstream geospatial software engineering.

Secondly, seemingly generic products, such as railways designed to be fast and efficient, can be bogged down by poor engineering practices and possibly avoidable human influences, such as professional ego.

This is all to say, there are costs when we forget to think about overtly engineering the transportation layer. This is as true with data as it is with trains.

So when I talk about the midstream, what am I talking about? In short, it’s really all those activities between data capture or acquisition and product delivery. But let’s dig a little deeper.

One of the subjects I have ranted a lot about recently is trust. In the midstream, we can undertake numerous activities that might alter the value of a pixel or data point. The tracking of those activities creates a chain of custody, or the providence of the reflectance value detected by a sensor or the measurement recorded by the SAR. That providence can be used to adequately determine the fitness for purpose of a particular data product. We can know what was captured, and then what happened to a particular pixel, point or stream. Providence is closely related to metadata, and metadata management is often the basis of a data standard. Open standards, as alluded to above, are absolutely key to a common understanding of data products, but, of course, standards are always interpreted differently (ideally, not that differently, though).

Scale is also key to the midstream discussion. Scale is a loaded term in geospatial; it can mean anything from a measure of geographic relevance of a data product to the scalability of a business to the ability of a data infrastructure to serve increasingly large loads. In this case, I am referring to the last definition: serving large amounts of data to large numbers of people in a short amount of time. This is a function of midstream engineering. Whether we are leveraging cloud or cloud-like technology, the nature of the distribution infrastructure can make or break a data product's fitness-for-purpose. Latency, for instance, is the time it takes for a product to be delivered; in effect, it measures data delivery speed. For maritime domain awareness, latency is a critical metric. In fact, there are a number of mid-resolution SAR providers for whom 90% of their imagery revenue is made within an hour of collection. For other constellations, archives are more notable, so making more data available becomes the differentiator. How data is engineeringa nd delivered, therefore, defines the product suite that a data stream can support.

Data discovery used to involve calling a salesperson. Now, data discovery is more often, but not exclusively, a catalogue or an API call. This again is the midstream. Sometimes, depending on the organization in question, a phone call might be easier than using their API, but that’s not how it’s supposed to work! APIs, these days, are giving way to MCP environments, meaning AI can have a conversation with a data catalogue. This workflow is increasingly important.

Finally, once data has been discovered, it needs to be accessed, either by streaming for those more cloud-native among us, or by download, for those who need to store the pixels themselves. This data access capability can significantly affect the latency and usefulness of a data product.

So, when I talk about midstream engineering being a business driver, this is what I mean. Scale and the ability to manipulate and deliver data fit for specific purposes create new business and greater adoption. How data is delivered can determine which market segments a data product can serve. How data is engineered can have a complementary effect on an industry. By that I mean the fractional distillation of image data into a particular analytic can suddenly convert a pixel-based product, which would typically be inaccessible to many commercial applications, into a number in a database, or an indication of the presence or absence of a landscape feature. A metric which is accessible to many more customers.

The nature of midstream geospatial engineering can literally create new products. So when I say that data is not oil, yet use the term “fractional distillation”, which seems confusing, what I am pointing to is the idea that a particular set of pixels can be distilled repeatedly to create different products. That distillation is all the midstream.

To bring this discussion back to the idea of the break in gauge, I will remind you all that, over time, countries generally agreed on the gauge of their railways because the switching costs were enormously painful. So, with the standardization of railways came greater sophistication and efficiency in their use, whether for freight or people. But today, when we overlook the value of the midstream, we are offloading this cost onto customers, reducing the likelihood that they will adopt geospatial or Earth observation products.

Again, this layer has seemed invisible, yet as AI adoption spreads like wildfire, sophisticated geospatial companies will need to refine their midstream stack to keep up and engage readily.

I don’t like the idea that “data is oil.” I think it’s a trite analogy that has been weakened by its demonstrable failure to deliver. Not that data isn’t valuable, but the idea that there is a global price for data and that everyone’s data is inherently valuable to others doesn’t make sense. This is all the more true with Earth Observation (EO) data and many sources of geospatial data. Data is valuable, but only to those who know how to use it.

I would also treat those who know how to use a particular type of data and those who know the value of a particular piece of data as two separate, often immiscible groups. Boffins can, but often don’t, mix with the business people.

However, I do believe completely that data has value. In fact, as I often repeat, investing in data is like buying a house, while investing in technology is like buying a car.

What I am saying is that User Interface (UI) technology is evolving so quickly that it's not worth spending too much extra money on, whereas data is a moat that can protect your enterprise in ways you probably don’t fully understand yet. AI, as yet, cannot create data. Well, it can make things up, but at this point, AI still relies on actual sensors to measure and monitor.

Subscribe now

But what this diagram misses, but the “data as oil” cliche points to, is the notion of a “midstream.” The oil and gas sector is very familiar with the upstream, midstream and downstream components of their market. This pattern is very analogous to what we see in the Survey, EO, and IoT sectors. In fact, in many ways, where we are with EO data is even better, albeit more complicated than that of the cruder resource.

Data as a resource

Interestingly, at least in the EO sector, we often talk about upstream and downstream components. But we rarely talk about the midstream's differentiating power. Yet I would argue that the midstream, the distribution of data, is the critical element that creates a functioning market.

The wonderful difference between data and crude oil is that data can be used more than once. This is especially true of geospatial data. Geography is a critical component of many business processes, so a single point of interest, or pixel, could be used in numerous different ways, numerous times. Obviously, once a barrel of oil is fractionally distilled, it will be consumed and not reused. It’s a famously non-renewable energy source. So data, if stored appropriately, can serve as a critical reservoir of opportunity that can be tapped without ever actually emptying. Of course, the market demand for a data product will likely grow and flow, but the opportunity remains. And as we know, new technologies can create new market opportunities by enabling the development of complementary assets. Thus, a dataset which was once inaccessible and awkward can suddenly become accessible and valuable with a complementary asset. This asset could be a handy open source library, a new algorithm, a new approach to computing, or AI.

The key here, then, is the engineering which makes data accessible. In some ways, the hyperscalers have shown a pathway to market. Additionally, standards play a role: the value of SpatioTemporal Asset Catalogues and published metadata cannot be underestimated. But so often geospatial workflows and markets are bifurcated, not trifurcated (if that’s a word?) The implicit expectation is that the midstream is being “taken care of” by either a satellite company or an analytics company, or the respective units within a single entity. That there is some kind of “interface,” ideally an API, which solves all problems. The reality is a lot messier.

The S word

It gets even messier when we start to consider sovereignty. This word is being redefined every couple of hours on various social media channels. But if one is interested in streaming data from one’s own satellite or sensor, one should probably own the midstream software and infrastructure and that infrastructure should probably be in a place that one can protect in some manner. Without owning the midstream, there is no sovereignty. But with the advent of different providers offering sovereign capabilities, what kind of SLA allows for IP ownership to a country or organization? Interestingly, as we are seeing in the AI debates, the answer lies in sovereign deployments of open-source technology.

But that is missed. In the desperation of EO companies to show value and create insight. The midstream is mishandled, the opportunity for foundation models is squandered, and ultimately, the Sovereign question becomes a series of one-off engagements which become an operational nightmare, rather than a robust market opportunity.

Share

Over the next few weeks, I will be digging into the EO and geospatial midstream markets. I will be thinking about why some companies separate out their operations (Maxar to Vantor and Lantaris, Hexagon spinning out Octave), and some want to vertically integrate (MDA pulling in CLS, ). We will be thinking about the midstream concept and what it takes to build data infrastructure. Why the idea of “Spatial Data Infrastructure” is useful, but probably getting a little stale.

For instance, my house is where it is, and it has been there since the seventies. It has changed in that time, but the bones of it are somewhat fixed. In fact, physical and political geography chart the fixture of all places through time. At a particular time, a place is generally a place.

Now, different organizations may disagree on attributes of that place, Taiwan, being an obvious example of a disputed sovereignty. Nevertheless, few people disagree on the presence of the island in question. My point is that certain things are deterministic: they existed at a particular place and time.

My question for today is how we can ensure that knowledge of space and time is properly handled by “less-deterministic” AI technologies. For those who have spent any time trying to orthorectify aerial imagery, this reminds me of adding control points to the polynomial, allowing a modelled representation of the ground to be calculated. It was possible to add incorrect control points, which would blow up your root-mean-square error. The game being to reduce that error to close to zero. That optimization problem is far better done by machines now.

But the mental image of control points is useful: places that, at times in history, hold together our human stories. The bar where you met your partner. The zoo where you first saw a penguin. The Battle of Bannockburn. The coronation of Queen Elizabeth 1st. My postbox. All these examples have location, linked to an event history, some important, some entirely peripheral, all deterministic.

When I think about places in a frontier model world, I am concerned that the deterministic nature of geography is not adequately accounted for. So, how can we help to build the deterministic control points to support a model in its desperate attempt to represent or interpret reality?

Now, you could say that event-driven determinism leaves the door open to models being misinformed about past events. And I believe you’d be right in saying so. Today, though, my concern is that a model’s understanding of geography is generally acquired implicitly, through text and images, rather than explicitly through an understanding of our geoid and human distribution. This implicity breeds a non-determinism of geography that is jarring to those of us who think of space and time as “fixed-features” of our shared human experience.

When I see the phrase:

“You were right to push back, those locations don’t exist,” I am left troubled.

So, what to do? Well, there are some geographic benchmarks to draw from:

GeoAnalystBench, looks at the quality of geographic code creation. GeoBench effectively assesses how well models perform on GeoGuessr. And then there is the other side of the geospatial coin: we have geospatial foundation models, what can be done with deep stacks of imagery, and the development of embeddings. Interestingly, because of the nature of Earth observation, these almost fall back into the non-deterministic bucket, as they typically require substantial context to derive analytics. A pixel can mean many different things depending on the context of an analysis.

My feeling is that we need to develop a series of open benchmarks to encourage frontier models to treat geography as fixed points of information around which non-deterministic interpretations can be made. When I think about this, I continually come back to the idea of SpaceTimeIDs, which aim to track boundary evolution over time (consider the Taiwan example above). But ultimately, SpaceTimeIDs fix a place at a time. I also think about the work my team at Sparkgeo has been doing for the Overture Maps Foundation on living point-of-interest (POI) data, using social signals to indicate whether a place has changed. I remember a discussion with Marc Prioleau a long time ago, where he suggested that building a POI dataset once was ‘relatively straightforward’ when compared to keeping it up to date. He’s the kind of guy who would know.

The point here is that knowing a place exists isn’t necessarily straightforward, and knowing what something was at a particular time can be even harder. But these things, in the most part, should be deterministic. They are fixed points in space and time - control points of reality.

A small intrepid team, we were very familiar with darkness and with these conditions. So we set off skiting the edge of the corrie, confident in our direction-finding skills, having been up here numerous times before. Within 20 minutes or so, we came across another set of footprints. These buoyed us further. We had not seen any other parties on the mountain, but in these conditions, they could have been immediately beside us, and we’d have missed them.

Within a further 10 minutes, we knew we were following our own tracks.

The stark realization that, in a place you thought you knew well, it was possible to walk in a complete circle was both frustrating and has stayed with me for the rest of my life. This was almost thirty years ago. We found our way back to the summit of Lochnagar, a place we could confirm, and set a bearing, committing to the long walk home.

We lost 30 minutes, and I learned a 30-year lesson. One that is becoming more true every day.

In geography, if you are 90% right, you are 100% wrong. Last-mile delivery has learned this lesson, as did Apple. The secondary lesson is to leave a trail of breadcrumbs, as it were, of confirmed locations.

GeoAI Benchmarks

I have become increasingly concerned about the lack of geographic competence in AI. There are now numerous excellent geographic technologies, such as Google, Apple, and Mapbox, offering very high-performance geocoding and routing. Yet, the more general AI Frontier models seem to rely on an implicit rather than an explicit understanding of geography. Indeed, when we consider the collision between geography and generative AI, we see a willingness to bend the laws of geography to meet the model's needs.

But attributes like “place” should not be treated with so little regard.

Being present in a location is the difference between arrival and loss, guilt and innocence, even between life and death. As we see increasing conflict across our planet, the confirmed knowledge of place is a determinant of humanity itself.

We can benchmark AI models. We also have a deep understanding of our changing Planet through Earth observation, geographic data, and geodesy. So, I believe we should start benchmarking frontier models against simple things like place names and locations, then we can add their algorithmic knowledge of geography, and finally, as we move towards a better understanding of the shape of our Planet, our knowledge of our geoid.

When I think about benchmarking, I think about questions like: ”Count all the football fields in Georgia.” Having confidence around context, and an AI’s confidence to ask clarifying questions: which kind of football leading to which field dimensions, is it a pitch or a field, and which Georgia? Modern generative tech tends to feel comfortable bending all rules evenly. Time and space are rules that should probably be harder to bend than most, as they tend to be for us humans. Yet those rules seem to be largely missing.

It’s actually not just about some fuzzy notion of accuracy, but knowledge of place is a feature of sovereignty in general. I talked about SovereignAI in this note. Knowing what things were/are called in certain places at certain times is a matter of knowing and accepting our history. This reminds me of Joshua Campbell’s work on SpaceTimeIDs, which he presented at the Free and Open Source Software for Geospatial (North America) conference in 2023. Changing geographic boundaries is more important today than it has been in the last 25 years.

History’s back, baby, and if you’re only 90% right, then your 100% wrong.

EDIT: While writing this piece, Google Earth switched off the Nano Bannana 2 functionality. That was quick.

In a previous post, I talked about the need for geospatial professionals to think more carefully about provenance. Provenance is an important subject; we need to know a pixel’s history before we can really determine its fitness for purpose.

But this week, things got crazy.

Google have pushed their Nano Banana 2 technology into Google Earth. In the blog post announcing the technology, we can see some amazing examples of bringing history to life and imagining new buildings. This is exceptional AI technology that, for a number of workflows, is exciting and disruptive, and great fun!

I made a map of a place called Barkerville, a historic gold rush town in Central British Columbia, in a “wild west cowboy style.” And it did create a nice-looking product. I then asked for it to be wintry, because it snows in BC…

And again, I was delivered a nice product. But the sharp-eyed in the audience may say that the main features are in the wrong places, and you’d be right, they are. When I asked for more accurate locations, it refused. Freelance cartographers take note: don’t refuse to make things more accurate, it’s a bad look!

This raises two important ideas.

1. Geography has to matter to the AI community

2. Provenance has to matter to the geospatial community

90% accurate is a losing grade.

Apple Maps was roasted when it first launched. If you remember, there were several errors in the mapping fabric. Within a few short years, though, Apple was as good as Google, and now they are both excellent products. At the time, I remember thinking that, in navigation, 90% good is 100% bad. If the user doesn’t reach their destination, it doesn’t matter if 90% of the route was good. In terms of geography, we are beset with very high user expectations set against a backdrop of typically dubious data. Quite simply, it’s hard and annoyingly non-linear.

In the context of AI, however, I regularly find that geographic knowledge is annoyingly implicit. What I mean is that location is learned through text and images. I do not think most AI’s have a sense of space. This leaves us in the position that AI doesn’t get upset, or even know when it places locations in the wrong place. If that is the case, then we have a bit of a problem.

I built a geospatial agent last week. I wanted to use it to find the latest satellite images of places within a chat interface. I was using it to find images of wildfires in rural BC. This was cool, but the gazetteer of places was poor and frequently wrong. If I didn’t know it was wrong, then I would have been mapping the wrong places.

In the same way, the map above is also wrong; the places are just wrong. But bad AI geography seems to have become expected. James Banting, one of Sparkgeo’s AI leaders, recently reminded me of the concept of AI benchmarking, and we have been bouncing ideas around since. Today, this idea seems more prescient than ever. Having a benchmark of places that an AI should know about would easily solve this problem, or at least let the public know which AI is better at geography. I realize that sometimes the location of a place is deterministic → a Point of Interest, and sometimes it’s not → the boundaries of a neighbourhood. But having a measurable concept of these ideas would be hugely valuable.

I wonder if the Overture Maps Foundation (OMF) could play a role here. While the Open Geospatial Consortium deals more with standards, OMF is a place for data. OpenStreetMap would also be an option, albeit with a more limited feature set and less governance, but an extremely open alternative. OMF has been building “living POIs” that change based on input from social data signals. This is an interesting model because it’s based on the concept of a place’s likelihood of existing and being what we think it is. Does that remind you of anything? It’s exactly how we’re thinking about the outcome of an AI query. Another benefit of OMF is its independence from, yet connectivity to, many large technology companies that use geographic data.

Ultimately, a geographic benchmark would provide some indication of a model’s understanding of our Planet. Better than that, we would also be more nuanced with questions like “how many football fields are there in Georgia?” Knowing that football means two different sports depending on which Georgia you are in. And if the AI had access to Earth observation imagery, it could actually count them and provide different results based on the dimensions and linework of the football in question. Indeed, what can we imply from the world field, rather than the pitch?

Geographic benchmarks start to untangle this deeply human mess.

You can’t handle the truth.

Not mentally, I’m sure you have the mind of a steel trap, but physically. Our EO data doesn’t have an agreed-upon standard for provenance. It literally can’t handle the truth. In cases where there are provisions for provenance, then we’re not using it. So, while some images may have a checksum from orbit, after that point, it’s a free-for-all of reprojects, stretches, tweaks, touchups, super-resolution, recoloured-SAR, cloud removal, area replacement, mosaicing, you name it. But the problem is, you can’t because we never wrote it down, or better, never wrote it into the image.

My problem with Nano Banana 2 colliding with Google Earth isn’t that Google did this. That would be like yelling at the tide; it was going to happen. My problem is that the geospatial community sleepwalked into this problem, knowing it would happen. Any number of good or bad actors could have done this; at least Google can manage some of the process and likely add the appropriate health warnings. Others will not, and open-source models can certainly provide a similar capability.

So today, I can place a nuclear plant in Iran, or add an angry crowd outside an embassy, neither of which happened. Even if the event is disputed, that image can still be distributed, and shared… and shared. If one were a bad actor, this is a tremendous opportunity to flood the zone with crazy images.

In terms of a reasoned response, there are enough sensors in the sky that the ultimate truth of a place or feature can be determined from the volume of imagery over a given area. That Iranian nuclear facility will clearly not appear in other images at the same location. However, events are harder to dispute. Events are a combination of time and place, and fewer corroborative sensors may be available at a given time. This is where provenance would be appropriate.

Provenance should be stamped into the image and additionally held alongside in STAC metadata. To some extent, our dominant design of moving large amounts of data around to do things to it holds some responsibility for the splatter gun of data storage, management, and documentation processes. If data is managed more systematically and, indeed, in a cloud-native manner, then provenance becomes much easier to track (see Prescient for Sparkgeo’s solution).

The combination of geographic benchmarks and data provenance goes a long way toward ensuring defensibility in our practice. In my opinion, it's time for the geospatial community to build the tools to help us return to being arbiters of truth, rather than the source of conspiracy.

I think our community can work this out. But who will step up first?

That is not new, nor terribly clever. It is, however, enduringly true. Data consistently pays dividends, while you’ll be writing new user interfaces every couple of years just to keep up. Now, when I say “data,” I also mean access to data. A big blob of information is not useful if it sits on an external hard drive, inaccessible to broader use, waiting for physical failure. Waiting for someone to retire and for the corporation to entirely forget that any data was even on the drive, or where the drive is, for that matter. I don’t want to tell you how many discussions I’ve had with organizations that have involved them recalling “that time we lost half a million dollars of survey data.” It’s almost as frequent as the founder stories that invariably involve them reflecting on “that time we spent a million bucks on AWS, by mistake.”

The point being, a data strategy goes well beyond the data. In fact, a data strategy is much more about how data can be used than it is about the data itself.

So, how do we build a data strategy? As always, it goes back to purpose.

Purpose Porpiose

Interestingly, I don’t mean the purpose of a dataset, that's useful metadata, but I’m thinking of the purpose of an organization. Different organizations will assemble data products differently depending on the purpose of that organization. A civil government organization might want to develop an open data strategy. A defence organization may be far more limited by security and compartmentalization needs. A professional services team may need to organize data by project or customer. A resources or logistics company might want data available more corporately, accessible by different user groups.

In each case, the purpose of an organization defines the foundation of their strategy. But there is another key feature, that the data is always changing. In fact, if the data are good and representative of our changing environment (physical or otherwise), then the data should be changing.

So, two key themes of a data strategy are appropriate accessibility and living data. Indeed, a strategy should answer the question: how can one leverage living datasets to meet an enterprise's evolving needs? A dynamic data strategy is the answer. Data will change over time, and the quality of that data should change as sensors, practices, and processes change. Data, while captured at a particular time, may be relevant for longer or instantly out of date. How that data is stored and then accessed becomes a question of purpose, opportunity, and cost.

What is useful?

While data captured for one organization is specifically useful, it is also possible that the same data product may be generally useful for another organization. Those organizations might exist within the same enterprise. The inability of these organizations to share data is known as a silo. This is even more relevant for geographic data. A particular pixel, which is a measurement of the reflectance of a particular surface at a particular time, could be used for impervious surface modelling, fire fuel modelling, land cover mapping, as a basemap for a web experience, or in agricultural analysis, among numerous other applications. The point being, a data point can be generally useful within a single organization. Even if it’s just old reference data, its use is demonstrable. But its use depends on its discoverability.

Discoverability should be the technical basis of a strategy. I have started using teh phase “protect at all cost, share carefully.” This embodies the idea that data should be nurtured and managed, but shared with a robust authenticationa nd authorization framework. Organizations need to explicitly choose who can access their data. This could mean being open, partially open, or selectively available within different organizational units, club goods, or other sharing models. Critically, this needs to be done with intent. With many traditional data management systems, it's easy to sleepwalk into uncomfortable situations. Being strategically intentional clarifies the situation. Mistakes can still happen, and probably will, but with strategic intent, those mistakes can be quickly identified and resolved.

A second technical note is the use of programmatic Application Programming Interface (API) access. I am a huge fan of the SpatioTemporal Asset Catalogue as a commonly understood community and now OGC standard. These days, machine access is as important as people's access. So, perhaps as important as the API is a Model Context Protocol (MCP) environment on top. This will support a more agentic, conversational experience. Again, data access is a critical theme of the Dynamic Data Strategy, so being progressive in access strategies makes good sense.

Dynamic Data Strategies

This has been a short note to encourage some thinking about dynamic data strategies. Data is changing, and captured data needs to be refreshed in line with the organization's purpose. Purpose provides an organizational intent, leading to clarity around data use, access, and its optimal refresh rate. From which fall access, storage, and cloud-optimization strategies. At all levels, appropriate data discovery enables data to be fully exploited, ensuring the highest credible return on investment.

Everything starts with purpose. But whatever your organizational purpose, the external hard drive is almost always the wrong answer!

Subscribe now

If you want help with dynamic data strategies, data distribution technology, or just want to talk about data, DM or reply to this email. At Sparkgeo, we have been advising large and small organizations on big and small data problems since the cloud was just a few specks of water vapour. We have opinions and can back those up with strategies, data, technology, and code: a data infrastructure company that can execute.

I am building an assistant. At some point, it will be a fully fledged Geospatial Analyst. Today, it's just a tool I can use to ask questions and quickly source and view our changing planet. This is something I have been wanting to do for some time. I will do this somewhat openly, so you can play along too. As we do this, I’ll be evaluating a series of tools and practices. Hopefully, we’ll be left with a sense of what is working these days and what might still be flaky.

Something that I know is flaky is how people go about these projects. There is typically minimal planning, and feature bloat tends to follow a dopamine-fueled, token-burning few hours. So, it’s worth taking a few moments to review a few goals. Of course, I think geographically, so this assistant will generally serve a few geographic purposes. Firstly, I want it to interact with open data catalogues and quickly render vector images of places at specific times. That means it needs to understand SpatioTemporal Asset Catalogues (STAC) and have a rendering capability.

I have a sense that AI will provide excellent glue, but I would like my assistant to be able to source data and then assemble components. I will try to encourage it to use the ESA APEx web components to assemble interfaces. Finally, for now, I want to wire in the strategic geospatial articles to provide specific strategic and analytical capabilities around the geospatial market.

For this project, I will start with Claude. I am comfortable with Claude and Claude Code. However, I am somewhat curious what Grok would look like with geographic data, given its purportedly more physics-based approach. That could be a tremendous value-add for geographic analysis. But perhaps in a text-based, code-driven environment, it won’t matter at all? An open question for me, something I will look into in the future.

So, today, I asked Claude to build an agent for me.

During this adventure, you will see a variety of my typos. You will also find I am unusually polite to AIs.

Claude helped me set up a Model Context Protocol (MCP) chat environment and a container (in OrbStack) so I can push this to the public later and get the basic geospatial stack ready. At this point, my agent will be local. Once I’m happy with the functionality, I'll publish it, and we can all watch it evolve. In my basic stack, I needed something to parse a STAC, something to store vectors if needed (PostGIS), and a visualization environment. For this, Claude picked Mapbox, interestingly.

Quick Note. An MCP environment provides the context for a series of chat requests, enabling a more conversational dialogue than a typical stateless Application Programming Interface (API) environment. It’s not wildly more complex, but for an agent, it does matter. Given the market, wherever you have seen an API for the last decade, you should probably now be seeing MCP.

Many geospatial data providers have had a hard time getting to an API; so, getting them MCP-ready might be a stretch. In fact, many Earth Observation providers will tell you they have an STAC implementation, but I would argue many have more of a stuck catalogue! Notably, though, Mapbox does have an MCP environment for its search and navigation services.

So, I worked on my agent.

Ultimately, I have built something that can easily request data from multiple STACs and render them in a fit-for-purpose manner. Additionally, I wired in two interesting features.

1. The ESA APEx framework provides access to a series of robust geospatial tools and components for assembling ad hoc interfaces.

2. The history of this substack. Because I wanted to ask this agent to have some market awareness and opinion.

In time, I will release the full repo. It’s not enormous, but I have a few notes on the process.

First, I ended up with four skills. Skills are handy blobs of capability which can be compartmentalized and shared:

Dashboard builder - to build ad-hoc interfaces.

Eodh-connect - to connect to the Earth Observation Data Hub.

Stac-imagery-workflow - to connect with Microsoft’s planetary computer.

Strategic-geospatial-advisor - to interpret market questions through the lens of this publication.

There is certainly room for many, many more skills, as well as some consolidation even here. But the skills are, notionally, handy. The presence of redundancy here implies significant potential for bloat in non-deterministic programming. Indeed, if I look harder, I see more than one way to call a STAC. Hold on, I suppose all programming is non-deterministic, like language is. However, having multiple methods for the same thing is just poor practice. This could become a problem in the future. So, one needs to keep a close eye on the developed code.

Second, it's hard to interrupt Claude when you know it’s pursuing an idea or a debug pathway in the wrong direction. As someone who has written a lot of code and spent a lot of time with geospatial technology and data, I could have helped debug much more quickly. There is a component of the human-ai teaming that I will work on. With a person, I could say “stop, look at this instead…” but interrupting the robot seems harder. That said, the astonishing speed of development is impossible to ignore. I will be digging into the idea of optimal teaming in future discussions.

Third, AI tends to try to please. It then ends up guessing important things like locations. I will address this in future versions. I want control over location disambiguation.

Finally, for now, it's becoming clearer to me that STAC implementations are absolutely essential for scalable data access. Those, combined with a sensible MCP, allow data to be traversed and pulled into ad hoc interfaces. To me, this is a workflow very reminiscent of the traditional GIS, seek and discover data. I expect the jury is out on whether this workflow would be conducted by an analyst and their job accelerated, or by another individual, making the analyst superfluous. In the near term, that will ultimately depend on the other contextual components of the analyst’s responsibilities, such as specific domain knowledge.

For reference, the readme for my geoaptial analyst looks like this:

# geo-agents

AI agents for satellite imagery and vector GIS workflows, built on the [Claude Agent SDK](https://code.claude.com/docs/en/agent-sdk/python).

## Stack

- **Python + uv** — dependency management (`pyproject.toml`)
- **Docker (OrbStack) + GDAL base image** — reproducible native geospatial deps
- **rasterio / rioxarray / pystac-client / planetary-computer** — raster & satellite imagery
- **geopandas / shapely / pyproj** — vector GIS
- **claude-agent-sdk** — agent runtime, custom tools via `@tool` + `create_sdk_mcp_server`

## Setup

Local (uv, using your Homebrew GDAL):

```bash
uv sync
cp .env.example .env  # fill in ANTHROPIC_API_KEY, etc.
```

Containerized (recommended once native deps get heavier):

```bash
docker compose build
docker compose run --rm app bash
```

## Run the example agent

```bash
uv run python -m agents.geo_agent
```

## Test

```bash
uv run pytest
```

## Web chat UI

```bash
uv run uvicorn ui.server:app --host 127.0.0.1 --port 8420
```

Open `http://localhost:8420`. Chat interface with inline satellite imagery previews and
interactive Mapbox GL maps rendered directly from tool results.

## Running permanently (macOS)

The chat UI, PostGIS, and Dekart can all run as always-on background services that
survive crashes and restart at login.

**Chat UI** — installed as a macOS LaunchAgent (`deploy/com.geoagents.ui.plist`):

```bash
cp deploy/com.geoagents.ui.plist ~/Library/LaunchAgents/
launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.geoagents.ui.plist
launchctl kickstart -k gui/$(id -u)/com.geoagents.ui
```

Logs: `~/Library/Logs/geo-agents-ui.log` / `.error.log`. To stop permanently:
`launchctl bootout gui/$(id -u)/com.geoagents.ui`.

**PostGIS** — `docker-compose.yml` sets `restart: unless-stopped`, so once started
(`docker compose up -d postgis`) it survives Docker/OrbStack restarts.

**Dekart** — `dekart local up` already runs with `--restart unless-stopped`.

**OrbStack itself** — enable "start at login" so the containers above have a Docker
daemon to restart into: `orb config set app.start_at_login true`.

## Layout

- `agents/` — agent entry points (Claude Agent SDK wiring)
- `tools/` — custom tool implementations (imagery search, vector ops, etc.)
- `ui/` — web chat UI (Starlette + WebSocket + Mapbox GL)
- `deploy/` — LaunchAgent plist for running the UI permanently
- `tests/` — unit tests for tools
- `notebooks/` — exploratory analysis
- `data/` — local scratch data (gitignored)

Is it me, or has corporate decision-making dried up? I see this in Sparkgeo’s business development pipeline and, between the lines, in various media articles. And over the last couple of weeks, I’ve reached out to a number of industry leaders to gauge whether this was a local or global effect. It could easily just have been me. It’s not, though; it’s global. One of the leaders joked that it felt like everything just stopped after one LinkedIn post. This pattern seems linked to commercial rather than government activity.

Let me explain.

In a commercial enterprise, it’s actually possible to do nothing. By that, I really mean “nothing new.” Because doing new things involves some risk and investment, and those things are really best done in a consistent environment. While in government, it may seem like nothing is getting done, but generally, there is a lot of busywork behind the scenes to make a new policy happen. So, governments tend to be slow, but rarely actually stop work programs, DOGE aside. In the commercial sector, however, it’s perfectly possible, even advisable, to just stop and wait out a particular storm. The corporate strategy lies in how long one chooses to pause and whether one wants to be first back to market or is happy to be a fast or even a slow follower.

I am talking primarily about innovation and modernization projects, which is the area where I have the most experience.

Today, I am seeing a slowdown in decision-making, and I will take a guess that it’s a combination of two confounding externalities:

1) AI

2) GeoPolitics

Normally, I would tackle these concepts separately, but for the purposes of this discussion, it actually doesn’t matter what the subjects are. What we have are two externalities to a corporation that each cause a freeze in activity while the firm decides how to approach the new situation.

How many LinkedIn AI-generated articles have you seen about AI strategies? If you are tasked with developing an AI strategy, then you will have a very difficult job finishing that piece of work before the next revolutionary technology is developed and deployed. This amounts to a series of crises for the organization. Any corporate AI strategy actually needs to step outside the technology cycle and focus on the corporate philosophy of AI use. Indeed, a corporate philosophy that delineates people from machines and elevates people by using those machines.

But the AI-generated posts on AI strategy might also be telling people to just use more AI, because that’s what AI would say.

The self-licking ice cream cone is always a funny joke, but in this case, it’s at once true and misleading. AI is not a binary debate; it is about nuance, efficiency, and elevating the user with phenomenal tools. Those tools still need a software development life cycle (SDLC), however. To design and manage that lifecycle, you do need some people. There is a huge opportunity for SDLC acceleration, but so often that nuance is lost, and not nearly so click-baity.

Likewise, the geopolitical landscape today is such that something new is happening every week, if not every day. Sometimes we are told what amounts to marketing spin about the start or end of wars, the opening or closure of shipping routes, or the presence or absence of tariffs. Very big, important political and business topics seem to be treated flippantly, leaving those managing a value-creation process to evaluate the contents and likelihood of a particular statement. This is a question of trust, yet I would hazard you against assuming that this is just little boys crying wolf. Some very real things are happening.

A corporation responds to change given enough time. If corporations are anything, they are generally adaptable and resourceful groups of people. As my brother once told me about the markets, eventually, people have to start buying something again. This is true of any corporation; eventually, they have to go back to work again. The innovation teams need to innovate. Well, they do that until the next crisis, and then pause once more. If the time they spend pausing is longer than the time between crises, they never get back to normal. Crisis management becomes the new normal. Now, of course, there is a meta-efficiency here. Corporations will get better at dealing with change; they will build models to efficiently assess the effects of a specific crisis on their operations. They will map 1st-, 2nd-, and 3rd-order effects.

So we have two bodies of important external activity, each somewhat distracting and each spawning regular critical events for a corporation to evaluate. Consider the corporation also as its own body, interacting with one of these bodies: a two-body problem in which equilibrium can be found. But with the addition of the second body, we now have a chaotic three-body problem. In most practical circumstances, a way will be found, as I said, corporations are adaptable. But enterprises will be partially paralyzed from doing new things until one of those bodies diminishes.

I think for the last year (maybe two), corporate North America has been in constant crisis mode. As a result, in terms of innovation, we have seen half-hearted efforts in AI, largely involving vast layoffs followed by rehiring. This feels more reactionary than strategic, more performative than thoughtful.

Those small companies winning right now are those with robust relationships with governments that still want to move forward and are even encouraged by the need to build sovereign capabilities. Increasing sovereign capability without fixing broken procurement processes ensures that those already serving governments will continue to do so. Not necessarily a guarantee of innovation.

From a strategic perspective:

1. It's time to reconsider organizational structures. AI strategies are necessary, though, perhaps don’t let AI write your strategy. It's absolutely no use being King Canute yelling at the tide coming in. Instead of drowning, it’s far better to apply your nuanced thinking and start to consider an accelerated view of your increasingly complex world.

2. Keeping your supply chains flexible, diversified and sometimes Sovereign is probably also smart.

3. In geospatial, having feet in both government and commercial activities seems prudent.

4. Build as much decentralization and agility as possible.

Companies built for last year’s success are not necessarily well designed for success this year. This is a time to reimagine whatever you are doing; if you don’t think it has changed, then perhaps you're not paying close enough attention.

Share

You know, the new stuff: foundation models, world models, non-GPS navigation, swarms of satellites. Literally anything Sean Gorman is doing (whether I understand it or not).

I know, it’s a problem I have. I have built a team around building very practical, yet innovative technology. We do this crazy thing where we deliver cutting edge technology to schedule and within budget. The idea was to bring geospatial technology to those who were missing it, and bring it at scale. In general, the geospatial industry is both siloed and somewhat proud of it. So being a technology bridge makes some (niche) sense.

Subscribe now

But, the problem is. When you are always trying to be innovative, you are always kinda early. Early is a complicated term, and it sits on a scale for everybody. I’ve talked about S-curves before, and that is a great way to visualize the growing efficiency or effectiveness of a particular technology or process. The idea is that a new technology starts being low efficiency, a few end up buying-in, early adopters you might call them. As the technology is worked on, it gains efficiencies to reaching a linear efficiency growth by this point a bigger customer base creates a bigger market. Eventually, the technology’s efficiency will taper off as physical or practical limits are reached, resulting in the top right of the curve.

Ok, it’s not really an “S”, but you get it.

When you are always trying to do something new, you end up sitting somewhere early on the s-curve. Often this is when the technology isn’t that good yet. So, a major component of my and my team’s time is spent trying to figure out “what’s good.” What is worth pursing more, what effort we can leans a little weight to, and what might fit a particular need. Or, when something is good enough for a particular customer profile.

Because, the other critical component is that idea of needs. The needs of a customer or customer vertical is also a moving target. In fact, I think of customers as sitting on their own s-curves. By that, I mean that customers, corporations, or people, for that matter, are all ready for new innovations at their own particular time. This timing is harder to measure, because it can be as much about the personality of a particular corporate champion, or the industrial ecosystem than anything. It’s also important to think about timing in terms of presenting new ideas in sequence.

For instance, AI projects these days are lighting up numerous boardrooms, but the technology is still a touch early for most major enterprises. I reflect on how long it took for most major institutions to adopt cloud technology (decades), and how quickly AI has become a critical entry in every earnings report (months). In terms of timing however, cloud approaches (not necessarily just the Hyper-Scalers, but the use of cloud-native methods) have opened the door to meaningful AI activity, that’s the sequence. Again, think about complementary assets providing direction for the sequence.

The problem is a matter the precise coordination of two timelines against the inconsistent backdrops of corporate performatism and geopolitics.

In many ways it’s an art.

Being is early is a puzzle. Today, it seems to be even more confusing, yet even more important to be early. More important for more people. So today, it’s increasingly critical for grounded, experienced technologists to provide good advice on what’s worth pursing.

So, be early, before it’s too late.

So, when I talk about geography being a deep horizontal, I’m not just talking about markets, technology, maps, and licensing. I’m talking about how humans have talked about place since we started communicating. I’m talking about resource discovery, allocation, and distribution. I’m talking about indigenous stories of where the wind comes from or where people would find woolly mammoths. As we talk about AI, it’s worth remembering that the human concept of geography is as old as, if not older than, humans. Indeed, things have always been somewhere; geography as a representation of place is deeply universal.

Subscribe now

But I also do mean markets, because humans created markets, so markets are geographic. Indeed, the notions of geography and time join everything together. Additionally, as far as my experience stretches, time only goes one way. So we are where we are, and we can’t change past events (within my understanding of our reality, that is).

And today, here we are, in Canada.

Sovereignty and AI

Which brings me, conveniently, to Sovereignty. And ultimately, what I want to talk about today.

Geography and our sense of ourselves are wrapped up in the notion of Sovereignty. Of course, this is obvious. We are defined by lines on maps. Lines that both connect and divide:

Lines of logistic connection.

Lines of bordering partition.

Lines of shared elevation whose collective densities can suggest anything from a gentle meadow to a jutting crag.

Those lines define our geographic understanding of Nationhood. An illustration of history, culture and values. So when we talk about Sovereignty and SoveriegnAI. We are talking about geography, we always have been.

The infrastructure of AI is really defined by two components: connectivity and data centres. To date, the question of Sovereign AI has all been about infrastructure. By showing you these maps, it’s obvious that Infrastructure is at once critical, fragmented, and geographic.

Northern Strategy

But we should reorient our thinking around the concept of AI for Canada. While AI needs infrastructure, so too do our brains have synapses that form neural connections. Our actual characters are each defined by the content of those synaptic connections. The memories, experiences, and observations that can be linked, in practical and abstract ways, to form opinions. Then, ultimately, our characters. So when I think of Sovereign AI, I think of the memories, experiences, and observations of a Nation. Those vectors of history which have created our presence.

So, again, here we are, in Canada.

I live in Prince George. Nestled in the forests of Central Interior British Columbia. PG is a small city of 70,000 or so, about midway up the province. Often described as “the North”, better described as the gateway to the North, PG is a resource town, defined by logistics. First rivers, then highways and now railways and the longest airstrip in the region. If you include PG, there are 200,000 people in the northern half of BC. That’s an area the size of Germany which houses over double Canada’s entire population (84m vs 41m). So, when I say it’s quiet up here, I mean it. Also, the Idea of Northern BC being in some way “North” is definitely a misnomer. As a Scotsman by birth, PG is the furthest south I’ve ever lived. It’s about the latitude of Manchester in Northern England. Urban North America is clocked surprisingly far south. North of Prince George is half a province and an entire territory. This is all to say that Canada is large, and what we might think of as Northern Canada, a psychological line that varies in location depending on which individuals’ synaptic connections have mapped it, is largely empty of people.

But not Empty.

In fact, I would argue that the source of Canada’s future lies, concealed, in the North. While Russian defenders used space to defend against Napoleon’s Imperial impetuosity, they were beaten back by Russia’s geography as much as by the Russians themselves. It is the landscape that defines the opportunity of Canada’s Future. Indigenous communities have known this forever, and it is partly that knowledge which provides our competitive advantage. People must have been in Canada’s landscapes for thousands of years. Stories of changing landscapes have permeated the lives of generations of Canadians, indigenous or otherwise. These stories are critical and complement our landscapes with a rich oral history. They must be protected at all costs, yet shared carefully.

That concept is a pivotal theme: protect at all costs; share carefully. I get ahead of myself, though.

Canada’s North is the key to Canada’s future. While most of our population cowers from polar vortices, a mere 150 km from the border of our Southern neighbour. Those willing to don a coat have a conucopia of riches to explore. From the most important of economic drivers: critical minerals. To the most dramatic of landscapes, waiting to enthrall adventurers from across the planet.

But the lack of people in our North limits our ability to manage this wealth. If we apply broken windows theory, we would see that a lack of observational security leads to abuse.

Strategically, our North is also critical to the future global supply chain. The various maritime choke points are each choking…

on traffic in the Red Sea and the Strait of Malacca,

on climate change with a shallowing Panama Canal,

on Grand Strategy and geopolitical gerrymandering in the Strait of Hormuz and around Taiwan.

The Northwest Passage, as we call it, is becoming ice-free for longer each summer. Our pristine Northern border will become increasingly busy. This region has flown under the radar (as it were) for some time. For one, it’s been frozen, and historically, it was where brave but ill-informed British explorers might go to freeze. However, I also believe the global population has been tricked into thinking the North is a metaphorical “margin space” on the map. I call this Mercator’s Conceit.

As our planet warms, places that have been cold are melting. With that melt comes access, but also significant infrastructural turmoil and the potential for a “methane bomb” to detonate. None of this is anything but a dystopian doomer-cast. For which I apologize for being a harbinger of bad news.

However, this is nothing but a collection of potentialities, which might suggest to some that close monitoring might be in order.

That, my friends, is where we come in.

Geospatial & Data

But there is a problem. Data is a mess, not just yours, but everybody’s. And there is an enormous amount of it. The idea of a data lake was really an excuse not to tidy up our virtual bedrooms (as it were). Like so many implementations of agile software development, which were just excuses not to manage software at all.

This problem is exacerbated by the sheer volume of data our community manages.

I would argue that the EO community has been trying to suck an ocean of pixels through a straw.

But the solutions are at hand. The complementary assets of Modern Geospatial (complementary as in helpful, not as in adoring) have given us the tools to succeed.

Thinking about these assets in terms of AI brings us to data as a critical, value-creating tool. Over time, data accrues value. In terms of our brain, these are the memories, experiences, and observations which we need to build analytic or neural connections between.

AI

That’s the data, but where then does AI fit into this puzzle? As stated, we have far too many pixels for humans to look at. So we will need AI there. But also, AI can create maps. Not necessarily good maps, but they will get much better. To ensure quality and geographic consistency, we should probably be building componentry that AI can assemble, because AI is an incredible GLUE.

By using AI to assemble ad hoc interfaces from authoritative components, it is possible to ensure algorithmic consistency while still enabling an accelerated future. These interfaces need not last longer than the 30 minutes it takes to make a decision. Disposable UIs.

In this manner, we might even be able to serve that geospatial horizontal. Broadening the geospatial market from experts to everyone else. The Venn of geospatial people has always influenced our market, and reducing technical barriers to bring geographic thinking to more people is hugely compelling.

Canadian Economics

So we have the strategic and technology components, but how should we think about the economic view? Hobbes’s Leviathan, taken to the extreme, is a fearsome creature. As is any system in fundamentalist form.

I think it’s fair to say that innovation happens with greater urgency outside the confines of bureaucracy, and society should be allowed to choose when urgency matters. Perhaps in the last 3 decades, we saw “the demise of history,” and urgency diminished.

We have geopolitical, climate, and economic urgencies. With this in mind, my suggestion is that the private sector should engage. Likewise, we need our government partners to build relationships with the private sector, rather than empires. I have a deeply biased opinion that small businesses can save Canada. Small businesses can build technology and sell it to numerous customers, but technology developed within government institutions is built for a specific purpose and becomes a bureaucratic liability. And I mean that in the accounting sense of the word. There is a balance sheet of technology. Technology built in the private sector is an investment; technology built in government is a liability.

An investment implies that it can be used for more than one thing and sold to more than one customer. Technology built within government, whilst exciting and potentially specific, must be maintained, hence a balance sheet liability.

The European Space Agency has this all figured out; they are largely a strategy-and-contracting organization. I believe this was part of the Government of Canada’s strategy in its greater investment in ESA.

1. We achieve greater scientific and technological connectivity to Europe, which is, without a doubt, beneficial.

2. To circumvent the notoriously labyrinthine Canadian procurement processes while still reaping the benefits of the geo-return policy. Hence, investing in the Canadian space sector, but using ESA's sophisticated and simple procurement vehicles.

Seems pretty smart to be honest.

But we could also do this. Open tenders are possible. The S/TBips systems are supposed to speed things up, but I see no evidence of speed, just a notional convenience which precludes anyone but the old-boy network from engaging. It feels like my observations here align with the “Build, Partner, Buy” approach outlined by our current leaders. But I note that policy execution typically lags behind policy announcement.

So, should Governments be the responsible custodians of data, protected at all costs, carefully shared? This final statement is a central tenet of cloud-native technology. Data should not be moved; instead, access to it should be granted to an authorized user or application.

Feature-level authorization.

Then, Sovereign AI?

We have seen the strategic argument for understanding AI within the context of a Nation’s character, and in particular, Canada. We have seen the timing argument for technology. I have suggested that governments are well-positioned to be responsible custodians of data but poorly positioned to take the risk on developing and maintaining innovative technology.

In these complicated times, understanding geography is a strategic advantage that can help us succeed.

4 take-away thoughts:

1. SovereignAI must be geographic, geography beyond infrastructure.

2. Investing in data is like buying a house

3. Protect our data at all costs; share carefully.

4. Small businesses will save Canada if Canada lets them.

So, again, here we are, in Canada.

Share

This is a map of an area in North West Pakistan. Part of the Hindu Raj range with the Afghan border just to the North. This is a beautiful and rugged area, and you wouldn’t know unless you went that the map is wrong. We did, and we learned.

Since those early demonstrations, the tech sector has poured over analytics and heatmaps trying to understand how different people interact with different web experiences. This was done to build usability into web products to achieve specific business goals: buying products, clicking likes, and understanding information.

In the geospatial world, we also care about how people think about and use maps (at Sparkgeo, we even built a web maps analytics technology, with mixed success). But I would argue that again, Google “took the map UI biscuit” with the development of Google Maps and Earth. Repeating their previous success with the same strategy: applying simplicity to potentially complex interfaces.

For the past 20 years, the web community has been obsessed with user experience. We did this because we were building experiences for the masses. The power of web products lies in meeting the needs of as many users as possible. That’s the key concept of scalability. That’s both the allure and the foundational business model. So what happens when people can easily build their own software? What then happens to the interface to that software?

Personal software is one question, but agentic computing is another. I built an agent that can pass the GISP. Then I built an agent that can interpret a GIS request and parse it out to a “team” of agents designed to replicate a typical GIS office. You know, the GIS technician, the GIS Analyst, the GIS Developer. These are all archetypes I’ve encountered throughout my career. Across European, North American, and Middle Eastern cultures, I met the same archetypes in GIS offices. I have been one, am one.

There was once a deep technical barrier to using geographic data. One had to be able to diagnose problems with data (because it’s always just various forms of bad). One had to set reasonable expectations for analytic capabilities and approaches to data science questions. One had an encyclopedic knowledge of where useful datasets reside and how to access them. One had to know how to move data from one form to another and safely transform coordinates and areas across projection systems without too much accuracy loss. And then one had to be able to actually design and run a geographic process, a workflow.

Reread that paragraph, and I will let you decide if the technical moat of the digital geographer has been eroded. I find this fearsome, but also somewhat exhilarating. In the end, we should remember that GIS has always been a tool for data exploration. A tool to ensure data makes sense, to get a visual. Actual analysis or workflows would be delivered elsewhere.

I think we are at a moment of change. We have more data than we have ever had. Far too much data for any single organization to adequately parse. We’ve needed machines to help us for years; they’ve just now caught up with our needs. The Earth Observation community can begin meeting some of the expectations the general public has had of us for years.

Here are some core strategic themes to keep in mind as we navigate the next few years.

Time is a first-class citizen in geospatial.

With the torrent of data flowing out of Low Earth Orbit, from swarms of drones, and from the billions of smart devices carried by every networked human, snapshots of analysis are now somewhat meaningless. Time is a first-class citizen in geography. This means maps need to be living representations of our changing planet. Whether that’s changing storefronts, new urban development, or more catastrophic change from conflict, social unrest, or climate change, maps are not static. More importantly, users of mapping and geographic products expect technology to reflect their experiences.

Approaches: Build tools, agents, and experiences for change.

Investing in technology is like buying a car; investing in data is like buying a house.

Continuing the idea of time, we can see how a corpus of data can accrue value over time. The notion of change is really a factor of time; we can only detect anomalies or changes if we have a baseline created over an extended period. So, more data leads to a better baseline and a better understanding of landscape changes or human activity. Investing in data and access to that data is an investment that will grow in value.

Conversely, as soon as an interface is built, it’s out of date. In the mid-2010s, I would say this based on the frequency of JavaScript framework updates and changes. Now it’s because user interfaces have become virtually ephemeral. I know my team have built interfaces that are useful for only 15 minutes. So, with the idea of personal software comes the reality that interfaces depreciate faster than ever.

I remember when it was futuristic to consider an API as a user; now we need to consider agents as users. Practically speaking, an MCP environment is really not much different from an API. But they are different and should be treated as such. For instance, neither should be subject to a 2000-feature limit.

Approaches: robust and secure programmatic data access is a great investment. Care more about data, because your users will be building their own unique interfaces.

Your personal moat might be in your ability to think spatially.

As referenced originally in the GEOFESTO a couple of years ago. Even if LLMs take all our jobs, people still need to think spatially to ask robust questions about geography. So I believe there is value in thinking through the implications of spatial and geographic context. The natural extension of this thought is that, while I worry about the GIS office in general, I believe there will be a job for the GIS Analyst, or ‘spatial data scientist.’ The ability to think spatially is not an attribute everyone is blessed with, and as the technical barriers to digital geography drop, those questions could be incorporated more easily into everyday business decision-making.

Approaches: ‘Spatial’ is a way of thinking, cultivate it, share it.

Geography can (and maybe should) be componentized.

Things are going to have to shake out. There will be disastrous mistakes made by AIs, as there have been terrible stories of people blindly following GPS directions into disaster. But we can reduce these problems by componentizing data products and processes. It’s clear that AI will use convenient components when asked; those tools can ensure robust geographic processes are followed. In many ways, the open community have been using the GEOS and GDAL libraries for this very reason. The same can be true of mapping interfaces, geospatial data access, and a common understanding of time, geography and spectra. In many ways, CEOS’s ARD efforts provide directionality towards a more componentized future.

Approaches: In your organization, build and make available components to ensure that any internal AIs use your authoritative geospatial data and display it correctly. This practice should desilo geospatial activities to minimize the risk of AI misuse. An unintended consequence may be increased use of geographic data and tools, driven by the availability of componentry for broader AI use.

This is the reliability diagram associated with the map above. We were in Area B, where you can see that the map was interpolated from a sketch made by Shipton as he travelled through the area in 1947. So, perhaps not a hallucination, but an attempt by an agency to fill in logical blanks with the “most likely next feature”, does that sound familiar? Also, we should have known better.

Over the last few months, I have been writing about the need for a country, including my country, to understand itself. In The Back Forty, I suggested that Canada’s North, while vast and largely empty of people, is also our most valuable yet least monitored asset. In the past, when space was, in and of itself, a defence against prying eyes and ill intent, we could afford to let the unforgiving North be our deterrent. Now, with technological development and a warming climate, it is our turn to look after that space that has defended us for so long. And in that article, I suggest that we use space to do that, well, satellites in space, at least.

In Deep Horizontals, I point out that the geospatial sector is obscured behind the vertical of GIS. I believe that geography is part of almost every decision we make as professionals, but the GIS sector has evolved into a siloed practice, leading many non-experts to seek an alternative to the profession. And in AI ate my GIS, I suggest that many will turn to modern AI tools as their solution. Thus, the question is: will the geospatial sector engage to build the AI maps of the future, or will it let AI companies themselves dictate the quality and appearance of these interfaces?

This line of questioning brings me to the notion of SovereignAI. If Canada is to develop an AI for Canada, a Sovereign capability, then shouldn’t that capability have an understanding of Canada’s changing human and physical geography built in? Shouldn’t we know ourselves?

(Geo)AI

In a recent presentation by Natural Resources Canada on their Planaura geospatial foundation model, I heard the presenter state very plainly that:

“A good AI model is a national asset.”

This statement is prescient. In the debate on what SovereignAI is, the fact that Canada has developed a foundation model capability is something we should be proud of and talk about. Foundation models are a critical part of the AI landscape (sorry, I couldn’t resist), but not by any means the full story. That said, the advances NRCan has made in this regard are noteworthy and valuable.

While Planaura is a wonderful example, the statement that a model can be a national asset is also critical, and again hints at an alternative way to consider the sovereignty of artificial intelligence. Our ability to parse pixels and points to understand and infer relationships is a part of knowing ourselves, and therefore, sovereign.

Changing climates are having physical effects. Melting permafrost causes infrastructure to subside and, in some cases, literally dissolve. Being able to use a foundation model to look into the infrastructural future of a community under different climate scenarios is a capability that builds both municipal and defence resiliency. To use a phrase du jour, a true “dual use capability.” While Earth observation, specifically InSAR technology, has been used to measure subsidence, applying a foundation model to this technology suggests the capability to project risk under changing climatic patterns. Given less supportive ground, which buildings, runways, roads, piers, water and power plants are at most risk?

As in so many use cases, GeoAI, or even just AI, isn’t the base technology but a layer of scale and fusion that enables easier data integration: an acceleration of today’s practices.

Data storage & distribution

While I have suggested that the practice of GIS could be disrupted, I feel strongly that the value of authoritative geospatial data will only increase. In fact, the storage and distribution of geospatial data via secure and open APIs will allow both humans and machines to easily read data in commonly understood formats. The SpatioTemporal Asset Catalog is a great example of a commonly accepted standard. While Canada does seem to be taking this responsibility seriously, with effort going into the Digital Earth Canada product. It is still unclear how this product will operate, who will have access to it, and when it will launch. That said, Canada has extensive data archives that could be highly valuable to geospatial AI technologies, some of which are available on Geo.ca.

One key question is which companies, nations, or partners will be allowed access to that archive? In no uncertain terms, like good AI models, this data archive is a national asset and should be treated as such.

While Canada is developing a sovereign capability based on a national archive of geospatial data, this archive could also be used by others with less dignified values to develop the same capability. While I feel strongly that we know ourselves deeply, I am less comfortable with others developing a comparable familiarity.

I applaud and support the invaluable contributions of ESA, NASA, and others to the development of scientific-grade global data products: a global public good. But there is a strong argument, within the context of sovereign capabilities, that some critical national products should be kept secure. As one would with critical infrastructure. As we all do with our personal health data.

At Sparkgeo, we feel strongly that in an AI-centric future, authoritative data distribution will be a common theme. That’s why we built our geospatial data distribution stack called Prescient. It’s called prescient because structured cloud-like data distribution enables future-looking, AI-enabled applications. Without good data hygiene, we don’t get to access meaningful SovereignAI.

Geospatial, and owning the map

I tend to default to geospatial data because that is what I know best. But in the development of Sovereign capabilities, the same patterns will hold for other sizes and shapes of data. Finance, health, and sentiment data all inform a country's internal workings, shaping its management and policy.

That said, we should not forget the famously unreferenced cliche suggesting that 80% of data has a location attached to it. Given the proliferation of device-based data, ad-tech, connected vehicles, and satellite imagery, I would politely suggest that the number is now much higher (much, much, much higher). With that in mind, we need to return to the question of sovereignty and mapping. Who will write the maps of our country, and will these maps have access to authoritative data products?

We know that AI technology tends to adopt components of convenience to answer questions. In many ways, this is a very human behaviour. While we were shocked by OpenAI and friends seemingly stealing artistic IP from writers and artists, in the 2000s, Napster was doing the same thing to music. Perhaps we taught the machines to harvest data the way we would ourselves. Nevertheless, I would prefer to see our country benefit from the data we have acquired, which, in many ways, is about us. In this manner, creating AI-consumable componentry for responsible AI consumption would be a productive approach to the problem.

What would components look like? Well, at Sparkgeo, we have been involved in building a mapping component library for the European Space Agency called the APEx platform. This has a series of interface components that tie into data products in known, commonly understood ways. The intent here was to make scientists’ lives easier and to provide a common look and feel for ESA’s scientific output. However, this kind of structure also ensures that AIs do not make elementary geographic mistakes and that data standards are maintained.

From a geospatial community perspective, we let a web search company build the de facto consumer mapping product. Who will we let build the AI maps of the future?

ISR data fusion

If we move to the more secure discussion of surveillance platforms, we find the same problems, but on a larger scale. The US military suggests they will ultimately have a drone per infantry squad. These drones will look around corners and check over features. They are mini Intelligence, Surveillance, and Reconnaissance (ISR) platforms. But where does that data go? If the Canadian infantry is to adopt a similar approach to drones, then the sheer amount of data flow will become quite a burden. But in that data flow will be nuggets of intelligence which humans might easily miss.

This, combined with underwater vehicles, higher-altitude ISR platforms, satellites, vehicles, and people all collecting data, leads to a very confused “common operating picture.” If we throw in jamming and the fog of war, we are left with a hugely problematic software and connectivity picture. One that leaves our military in a confusing labyrinth of data sources, each with its own nuances. This is a complex mess for full-time analysts to untangle. Doing this in the field, under extreme pressure, in a mixed connectivity environment and hostile climate, is impossible. The common operating picture is one problem to solve; another is how that data is subsequently reviewed for after-action activity. Not only is the data to be visualized, but it has to be stored with extreme security.

In a similar problem set to that presented in the monitoring of vast spaces, the decentralized capture of secure data will lead to a massive intelligence-gathering nightmare. Thousands of drones will capture high-resolution, geospatial video in circumstances that will encourage review for intelligence purposes. We can solve the technical questions, but who will be able to watch all the videos? In the end, we know it will have to be machines directing algorithms to look for signs of enemy activity, IEDs, or even search-and-rescue targets.

The problem of data fusion is at the heart of the Earth observation product problem, and the dirty little secret is that not all geographic data lines up. In fact, most data does not align without some additional work; it is likely that GeoAI will play a major role in aligning georeferenced features through space and time for after-action analysis in a digital twin of an operation.

The biggest problems in Earth observation today are all in software. To access robust Geo or SovereignAI, we will need to address some of these complexities of scale.

Training data

As we think about AI and Sovereignty, we should also consider how data becomes AI. And how (and where) we build training data sets. I suppose this is somewhat back to the original case of real estate. But this basic labelling activity is still essential, and much of it is still done offshore. This potential hole in our Sovereign AI strategy can be solved by bringing back some of those technology jobs to Canada, especially around more sensitive subjects. There will be a cost, but there is also a tremendous benefit in shifting technology jobs to lower-cost environments (outside Canada’s big cities, where housing is still affordable) and even to more rural settings. Ultimately, this activity can proliferate technology jobs across the country, reducing barriers to entry and opening the door to a broader tech economy. Rural Canada, while famous for hewing wood and carrying water, could also be a decentralized network of data creators. I say this as someone who lives in Northern British Columbia, with robust, redundant connectivity data could flow faster than any natural resource.

Decentralization for resilience

The idea of distributing the capture of training data to more rural settings is predicated on having a robust connectivity strategy for Canada. At every level of economic and social development, this is absolutely paramount. Access to connectivity is access to knowledge, and it is clearly a point of equity for Canadian citizens.

The added benefit of robust national connectivity is the opportunity to decentralize computing resources, enabling the internet to function as it was designed: a network of decentralized computing hubs. With decentralization comes resilience and, by extension, independence.

Procurement as enabler, not barrier

This is a note on SovereignAI, and while applicable to any country, it’s certainly presented through a Canadian lens. With that in mind, investing in Canadian companies to build the Sovereign AI, or the Sovereign GeoAI, would be logical (if not somewhat self-serving of me to say). There has been a trend towards the Maple-washing of other nations’ technology companies, with their regional hubs in Toronto or Ottawa, trying to look and sound Canadian. I am sure wonderful people work in these establishments, but where are their owners and shareholders? Where are their executives? Whose software are they selling or reselling?

Companies like mine, Sparkgeo, have, for years (since 2010, for me), been forced to work for commercial entities or for foreign governments, beaten out of the Canadian Government market by less-qualified but better-funded competitors. While we’ve worked for ESA, UK Space, and various Saudi Arabian institutions, we found that the Canadian Government procurement system could hardly have been better designed to prevent small Canadian technology companies from engaging. I believe companies should be competitive, and working for commercial companies for fifteen years has taught us how to deliver extreme value under high pressure. So, when I see how the Canadian Government is generally treated by the traditional cadre of service providers, I am disappointed.

However, I am excited to see that teams like Sparkgeo might now have an opportunity to engage, and I look forward to demonstrating how a small team of experts (rather than contractors) can raise the expectations of a nation.

A year or two ago, I came to the conclusion that GIS, as a technology, is a convenient environment for data exploration. It’s best for data with a geographic component, and GIS provides the helpful feature of showing that data in a cartographic manner. But really, this is just a data visualization option, a map. One can also interact with aspatial data, as we call it. Or data without a spatial component. In GIS-land, we have a name of data that GIS can’t natively visualize, which, counter to popular geospatial opinion, is most things. Unironically, outside GIS-land, aspatial data is just data, and spatial data is just data. In many ways, this relationship is comparable to the “Venn of Geospatial People”. But semantics aside, GIS is useful for analyzing spatial data; it’s handy for getting a visual check of a data product's quality, scale, and “look.”

Wait, I’m already logically confused. I confused analysis with visualization. These are two different activities; as geospatial people, we can conveniently conflate them. As an analyst, I want to ensure the data I am using is fit for purpose. That trust-creation process supports the analysis but isn’t necessarily part of it. Traditional GIS excels at that trust-building process. Unfortunately, it’s actually bad at running analysis at scale. Hence, the proliferation of “accelerated geospatial” companies. My observation is that if GIS were good at scale, there wouldn’t be a market for “more scalable” technology. This is the basis for my observation of GIS as a data exploration tool: it is designed for the one-off exploration of one or more data products and for examining the results.

Share

So, GIS is an excellent tool for visualizing spatial data products, often to tweak, refine, or build trust in those products. The data, once confirmed as authoritative or indeed “good enough,” is published for use elsewhere. I agree with this workflow. Data should be taken to a point of confidence, then published for use by broader systems. This speaks to two of my regular talking points:

1) That geospatial is a deep horizontal, and

2) That, while investing in technology is like buying a car, investing in data is like buying a house*.

Unfortunately, confusion has arisen about the boundaries of GIS as a practice. An argument that I have no energy for now, suffice it to say that the siloization of GIS practitioners has not been good for the geospatial community at large (notably, but not exclusively, in terms of employee compensation and technology integration). But I also think that the GIS practitioner, who might see the map as their product, is facing a deeper problem: personal software.

Personal software

I’ve built two or three applications this month. I can’t remember the actual number because I don’t have them anymore. I built them because I needed to see something or scratch a particular technology itch. I default to Claude Code because that’s what we use at Sparkgeo. But really, it could be any AI of your choice. The point isn’t which AI; the point is that I, the CEO of a small company with a technical background who is probably now “the worst software developer in my team,” am building apps. Those apps I built might last 15 minutes or 15 years. They might be handy or just silly.

An Aside…

For the Earth Observation geeks in my readership: I built an application to recieve a dragged hyperspectral image up to 5GB, then tile appropriately for visualization, then apply a PCA analysis to the bands of the image which are typically outside the wavelengths detectable by the human eye, then run Meta’s “Segment Anything” algorithm over the result and show the original image, the PCA output, and the Segment Anything output as three layers on a slippy map for visualization. The idea being that I was building a visualization of our invisible planet. Well, invisible to us humans. A fun little art project.

This took an hour or so. There is something about the dopamine hit of building something. It’s worth reflecting on the addictive nature of this kind of accelerated building. Too much dopamine too fast is probably unhealthy.

While art projects are fun, this is also an interesting data point: this would have taken me forever to build previously. In fact, I probably wouldn’t have bothered; it would have just sat in the back of my head with a bunch of other ideas getting rusty. But with the right tools, it took me just an hour or so; I satisfied my curiosity and felt like I “built something.” And that dopamine flowed…

Tell me the time

I heard a wonderful analogy last week at the NASA Earth Science & Industry Summit in DC, credit to Christine Wallinger, who I suspect might further reference her university professor:

“We show people how to build clocks, but they just want to know the time.”

Traditionally, we have provided extremely complicated tools to build perfect clocks. And people do care that their time is correctly kept. But a barrier to the adoption of geographic tools is that business people don’t want to build clocks, or have a team that builds clocks for them every time they have a geographic question. In the last two weeks, I learnt that those clocks can be built and discarded with so little fuss that, in many ways, user interfaces have become ephemeral.

The previous week, I was having coffee with an AI researcher from a notable AI company at a lovely Chilean coffee shop near Paddington. As the crema of my coffee slowly dissipated in the cool air, he showed me a workflow his team had built in real time for a government customer. While there was nothing groundbreaking in terms of geospatial and mapping, clearly, this was an application one would describe as a GIS. The workflow had placed points on a map and used them, along with their attributes, to create a least-cost path. Those points were sourced (by the AI) from a specific open data source, and the mapping fabric was open source as well. So, in delivering a traditional GIS product, the AI had happily created a satisfactory experience for the government customer without touching any traditional GIS technology or any explicit geospatial expertise.

Bring it on, feel free to yell

You could say “lack of authoritative data!” or “AI slop!” or “cartographic incompetence!” and you could be right on all counts. That’s not my point. This was not a good map, but it was adequate. My point is about the definition of “good enough” and the disruption that occurs when an underserved market encounters a low-cost product. That underserved market could be the deep geospatial horizontal referred to above, and the low-cost product could be prompt-driven AI.

The question here, then, is whether this new geospatial market will be served by traditional geospatial technology companies or by others. If we remember, Google Maps was created by a web search company, not a mapping company.

So, if we are in the end of days for SAAS applications as the markets are suggesting (SAASmageddon!), and AI will eat the world, as various billionaires will insist (all who have a financial interest in AI eating the world, I should point out). Then where does that leave the geospatial sector? Where does “authoritative custodianship” come into this debate? Have we forgotten to care about data and maps? Who will be designing the maps of the future? Who will sweat over label positions? Who will worry about scale effects in data misrepresenting a particular feature? Who will tell me they don’t like pink on their maps (hint: apparently, middle-aged male foresters, at least they didn’t in the 2000s)? Will AI slop insist that the great circle route is not the fastest way across the Atlantic?

No. Precisely no. In fact, that is the point: we can be comfortable in the fact that our user interfaces will change, and they should, yet data still has an intrinsic and increasing value, and we can extract more and more meaningful analytics from that data. But we will have to think about geospatial service delivery differently, and that shift will come with new business models. If we are very lucky, that change in model will bring greater access to the deep geospatial horizontal market I keep talking about. Ultimately, enabling a much broader array of businesses to use geospatial technology daily at a lower cost.

If we were to summon some optimism in a time of undeniable cynicism, we could see a resurgence of geographic capability and use, because it’s easy.

Where are the geospatial experts?

This future may seem bright for the multitude of non-expert users, but what about those people who used to make maps? Well, for a long time, they still will. The future is, of course, unevenly distributed. As there are still fax machines and people who make horseshoes, mapping will remain a skill. But interfaces will change, fast for some, slow for others.

But for those looking to engage with a new market, we will need to ensure that data products are authoritative, accessible, secure, and consistent. Additionally, we should be building componentry that AI technology can assemble into convenient user interfaces. That componentry should provide the algorithmic or geographic rigour to put the minds of the most fervent geodesists at rest. The components should allow non-experts to assemble geographic experiences without worrying about the complexity of clock-building, while knowing that experts have ensured quality, and to assemble their data products to tell their time with ease.

If it doesn’t or we don’t, then we will have failed, and again, we will have let another industry eat our lunch.

Subscribe now

*I cannot believe I haven’t talked about this subject, but it’s true: data accrues value over time like a house, while technology depreciates almost instantly. We will dig into this more when I write a note about this core Modern Geospatial concept. Watch for it in future posts.

.

My journey to North51 usually takes me through the Canadian Rockies. I am privileged to drive south on one of the most beautiful highways in North America to get to Canmore, Alberta. While the winter driving can be a little touchy at times, this year was clear. Clear and absolutely beautiful. And this week’s drive started with a light show.

North51 is not a normal event; it is unique and notoriously small. We call it intimate, but that intimacy means everyone speaks to everyone, and everyone has something meaningful to say. Don’t come to make sales. Instead, come to share ideas; come to build the future.

I was lucky enough to stop for a skate ski on my way through the Rockies, taking the opportunity to stretch my legs after a long drive and assemble my thoughts for an intense few days. There is something in the work of climbing a hill, followed by the cold blast of descending, that provides a unique mental clarity. The event this year was split over Wednesday afternoon and through Thursday. Friday was left to catch up on the final missed conversations and goodbyes over breakfast, or to embark on more adventures.

We used to have keynotes sprinkled throughout the event, but now we have as many fireside chats and panels as anything else. This allows for the free flow of stories and experiences. This is a key feature of our event. We don’t want a canned presentation so much as a realistic discourse. This is embodied in our commitment to the Chatham House Rule. No sessions are recorded, no quotes are attributed; it’s designed to be a safe space. This allows real discussions.

And these discussions are absolutely critical for our industry. Every year, we seem to struggle with business models versus the humanitarian power of Earth Observation. We talk through the friction between resource defence and environmental communities. But in an age of political binanryism, N51 is a place where honest discussion can actually happen.

Because North51 isn’t normal, sponsorship is hard. With that in mind, I want to make a special shoutout to all those who did:

Tilebox, Altalis, T-Kartor, MapGuru, Alberta Data Partnerships, Motivf, Photosat, Wyvern Space.

These brands value integrity and innovation in geospatial technology. I would encourage anyone following North51 to take a second look at each of these organizations, knowing they embody the best of our community.

Subscribe now

We started on Wednesday afternoon with a fireside chat between Dr Emily Darling and me. Emily is an eminent Marine Scientist and Co-Founder of MERMAID at the Wildlife Conservation Society. MERMAID was developed to replace the Excel spreadsheets of individual Marine Scientists. Her leadership has taken MERMAID from a database schema sketched on a napkin to the leading repository of Coral health data and a global view of coral health. Though with only two columns of geospatial data, lat and lng, location is critical to MERMAID. MERMAID has provided a sense of scale to the Coral Herath community, but Emily was also able to tell us about their Bezos Earth Foundation award, which will allow her to scale up again to a crowd-sourced model, powered by AI. There is a valuable subtext here about the arc of innovation: from a single user, to a group of experts, to a crowd of enthusiasts, and how technology can serve communities.

Led by Caity Milton, “the future of collection” was a panel (Chris Robson, David Page, Clint Graumann, Stefan Amberger) that covered the practices and models of satellite collection and distribution. There were discussions about innovative financial approaches, the role of government in earth observation (hard to ignore), and how funding certain infrastructure can provide additional financial and operational benefits to unintended groups. Some thoughts on unlocking the potential of EO and how practitioners could adopt new models when government customers are less agile. Finally, determining the value of archived data is always a hot topic, particularly in light of AI-based applications.

On Thursday, Jon and I were happy to hand over North51 to Priscilla Cole from Geospatial Risk. She provided colour on her organization and introduced Louie Woodall from Climate Proof, who took us through a view on the value of geospatial data. Again, there is a schism between humanitarian value and the need for commercial satellite and aerial operators to keep paying the bills. Louie spent some time digging into the central concepts of climate adaptation, highlighting that climate change is not something that will happen; it is happening now. The insurance industry has been hurt, but won’t accept the same fiscal beating; instead will apply technology to make better bets. The insurance sector doesn’t lose, but we might lose our policies.

Priscilla then welcomed Tee Barr (Geospatial Risk’s Co-Founder) to the stage, and they took us on a discursive journey through the technical elements of measuring risk with geospatial technology. The different elements of the insurance sector, how to think about parametric insurance, the different senses of time, and risk vs catastrophe. This discussion left me feeling that our understanding of risk depends heavily on scale and accuracy. As devices advance, this can unlock more revenue opportunities (or reduce losses) for the risk sector.

After lunch, North51 returned with a panel on “Geospatial beyond the GUI” with Nate Ricklin, Veronique Nell, Ash Hoover, and Ben Tuttle. While geospatial has always been a User interface-centric activity. Increasingly, we are seeing that geospatial processes are happening “under the hood.” This, combined with modern AI technology, is a heady brew. But there is concern with unsupervised machine-created inferences. The concept of human-on-the-loop (HOTL) developed and seemed popular. In contrast to human-in-the-loop (HITL), HOTL seems more agile. Critically, inference speed can be retained while maintaining insight quality.

Not to be outdone, Bill Greer, Steve DeRoy, Ash Hoover, and Peter Rabley took us on a tour de force of the ethical topics facing our industry. “Ethics, Influence, and the Role of the Practitioner” embodied the deep paradox of the geospatial community: that there are so many hugely valuable activities which ought to have a value, but only Governments will pay for. But what happens when those activities are not in a government’s interest? This resonated particularly with Bill’s commentaries on Common Space and Steve’s deep experiences with Indigenous mapping. While we were left with much food for thought, there is a sense that more honest discourse and some empathy would go a long way. Also, there is a sense that “pay what you can” is a concept that sounds naive but could be surprisingly useful.

We rounded off our main day with another fireside chat between Jon Neufeld and Don Murray, the Co-Founder and present CEO of Safe Software. Don has been a humble geospatial luminary for the last 30 years, yet didn’t appreciate being described as a legend. The consistent success of Safe Software and its primary FME product line is undeniable, filling a repeatability gap with practical and valuable software. When described that way, it all sounds easy, and listening to Don would trick you into thinking that everything was straightforward. That’s the thing about people like Don, their humble, understated stories would make you think anyone could succeed. But the arc of success from satisfying a contract for the British Columbia Government to building a profitable company with $250m of annual revenue is not a normal thing.

With that, it was over.

Except it’s not, not really. Ideas tend to stick and grow. This year, the themes for me were:

Arcs of success, seeing examples of small incremental, practical successes building into amazing

Applications of technology, fear of technology (especially AI) is unhelpful, but people do need to be led with integrity and honesty

Risk is apolitical, and increased accuracy is usually a revenue model: this is the only time that bad news sells (apart from the actual news)

The business models of EO are still unsettled, but there is agreement that the “per square kilometre” model is unsatisfactory.

These ideas will now influence my thinking and how I see my community. And I guess, that’s the point.

Hopefully, I’ll see you at N51 next year, and if you like backcountry skiing, talk to me about the Executive Dirtbag Offsite.

Hey, perhaps you haven’t heard, but North51 is coming up in January. This is the geospatial thought leadership event. If you haven’t been before, you should take a look. If you have, you know what to expect, except this time we will be deep in the Canadian winter, and we have some great deals with the local ski hills.

Something a little bit special?

The geospatial community is full of old companies. While I don’t feel Sparkgeo is terribly old, certainly not in comparison to venerable organizations like the UK’s Ordnance Survey or Swiss Topo (Switzerland’s Federal Office of Topography), or even Esri, the leading pure commercial organization, I do feel we’ve “been around the block.” One of the reasons we’ve stayed in business is annoyingly counter to almost all the advice one might hear in the typical technology business circles. Geospatial, as a practice and at scale, is almost always a little bit custom and custom business activities usually demand a services team.

What’s wrong with services?

Services revenue isn’t scalable. That’s the oft-repeated mantra. Software is scalable, you can build once and sell many times, and services are linked to “billable hours,” so one can only scale with more FTE’s. On an exceedingly simplistic level, that’s true. Except that nothing in life is simple, and business mirrors life.

However, let’s take a quick tour through the generalities. When considering services versus product companies, products tend to attract a higher exit value, which, for lack of a better metric, is the central perceived business value: what someone would pay for that business. There is an inherent bias in this statement, as most valuations are driven (reasonably) by investors seeking a return on their investment. In contrast, most service companies don’t need investors. Interestingly, this implies that future revenue is more valuable than actual revenue.

However, the central point here is that the typical investment community views a services component in a company’s revenue stream as a dangerous path to a reduced unit economy. Their “build once, sell many times” mantra is diluted by any billable hours of services tinkering. Worse, if the company in question is publicly traded, and the market views its revenue as consulting or services, then the share pricing implication could be disastrous.

This has led to a situation where new geospatial companies are motivated to be viewed solely as products, and not as services. Yet, in almost every occurrence of the GIS or geospatial experiences I’ve had, very little is genuinely repeatable. Yes, we will use the same tool, but to do different tasks. I would argue that traditional GIS is essentially a data exploration environment. When GIS analysts discuss automation, it is usually in terms of automating an activity for multiple records, rather than supporting many users performing a repeatable activity. Perhaps this is why GIS companies have struggled in consumer-web environments?

Let’s get physical

Our world is a complex system, and when we attempt to model it, the patterns are not typically reusable. Think about car counting. We can count cars in the Port of San Diego from Earth Observation data. But that algorithm will not work well in the Port of Dalian in China. There will be differences in atmospherics, differences in parking patterns, and differences in vehicle types. So the algorithm must be tweaked. This is true of most Earth Observation practices. While we hope that geospatial foundation models will resolve this problem, it persists today for those seeking robust, production-level accuracy. So, who does the tinkering? Consider languages for user interfaces in mapping, various addressing styles and cultures, and different search styles for different types of mid-morning drinks. Who does that work?

There is something about the interface between the complexity of physical geography and the complexity of human geography that, when combined, results in most geospatial platforms being generally applicable everywhere (see the geospatial product trap) but not being easily applied anywhere.

As a community, this profound physical-human complexity has always been difficult to articulate, yet it is something that most practitioners know and have experienced viscerally. In many ways, this is the surprising art of geography, why many of us remain joyfully curious about our world and its evolving systems.

I’ve come to consider geospatial as similar in nature to Artificial Intelligence, in that it is almost always the component of an answer to a question, but rarely the entire answer. As such, I think of geospatial as a deep horizontal. However, the critical extension to this observation is how one combines geospatial technology or data into other interfaces to provide a fuller answer. It’s all about interfaces, some digital, some human. While we can always get better at APIs and open (but secure) standards, and we should, those human interfaces are usually developed by physical people in services teams.

Yet still, there is a long list of companies that tried to execute without a services strategy but failed. And another list of companies that insisted on chasing the next project, thinking they were seeking product-market fit, but should really just have committed to being a services team or a services-led product, by building margin and project management into their services business.

Services-led geospatial

The solution, as I see it, is to commit to the obvious. New geospatial product companies, whether they be data products or software tools, should be comfortable with the idea that services are necessary. That idea needs to be seeded early with any investors, so arguments against the inevitable pushback can be prepared. In many ways, the controversial yet successful company Palantir has employed the “Forward Deployed Engineers” model for almost a decade. This is just a rebrand of a services-led technology product strategy. It is also worth noting that Esri (link above) also has a very robust consulting team, and each country-level organization is, in effect, a reseller and localized services provider. This model has become contentious among some, being perceived as somewhat anti-competitive, but it remains hugely successful.

Having a geospatial tool wrapped in services means that the customization component can be executed while the product is also being sold and developed. There are now two sources of revenue allowing for lower levels of initial dilution, and potentially a more agile product-market fit process. This also benefits the services team as their revenue becomes less “lumpy.”

Finally, it would also be possible to sell this structure more easily as a managed service, ensuring that there are people more closely attuned to how a customer is using or wants to use a product. Hopefully, this model will build a better product for all.

Don’t reflect, refract: time only goes one way

This is the time of year when everyone talks about what happened in the last twelve months. While your experiences do matter, time only goes one way. So, don’t get caught reflecting too long; instead, use your experiences to build forward and through; refract your experiences.

First, don’t forget about booking tickets for North51, January 21–23, 2026. If you like this Substack, you’ll love North51! This is not a traditional conference. It is curated, ideas-driven, and built for people who want real conversations about the future of geospatial. Even better, this year we’ll have sessions especially curated by Priscilla Cole and the Geospatial Risk team.

An executive-level opportunity to talk about the pressing issues in the geospatial community of practice. And this year seems more pressing than most! See you in Canmore, Alberta.

New tools, old patterns

Sometimes, I get a sudden wave of realization. This could be while laying awake in the small hours of long night. It could be that two thirds into a long run, when coming to the crest of a raise, I just stop. It could be, like this time, when I was flitting between sleep and wakefulness on a transatlantic flight. It’s usually at a moment like that when my mind is tricked into wandering. Tricked, out of the fury of “the now”, into a different place. On reflection, there must be something in that liminal state between sleep or meditation (don’t you lose yourself in a run?) and presence. Something in that transition between mental states.

I see patterns

I’ve frequently talked about dominant designs. Why does a car have four wheels? Why are most pens the length they are? Why do glasses look the way they do? Because, through a process of iterative industrial design, we have reached a point of consensus on the way some common things look and operate. Sometimes, that consensus has come in the form of standards: shipping containers, for instance, sometimes we have just agreed that a thing should look a particular way. But it’s worth noting that dominant designs surround us and while they provide comfort and often production efficiencies, they can also be a source of limitation. By “limitation” I mean that the comfort of obviousness of a particular design can be a source of hidden opportunity for the entrepreneurial.

Another critical point is that a dominant design need not just be an article, it can also be a process. Legacy human and digital processes are a curious source of innovation. Very often people do things, because that’s the way they do things, not because that’s the best way to do things. So when we think about dominant designs, don’t forget that these can also be in the way we do things as much as the tools we use. If we are doing an old process with new tools, have we really innovated?

So, today we are discussing dominant designs; patterns of design and behaviour.

And the Cloud’s gone wild!

One dominant design I think about is how we think about data storage and use. Traditionally, we have become used to acquiring data, perhaps through survey, purchasing, or exchange. Then, we would expect to move this data to a place of ownership, and subsequently use the acquired data. This could be as simple as a work colleague sharing something via email or a thumb drive. Or it could be more complex, perhaps involving the purchase of large amounts of remote sensing imagery. While acquiring imagery via API is a step forward, in essence a download API is still adopting the traditional pattern of moving acquired data from location A to location B. Worse, we are not just moving, but copying.

The main problem with moving data from A to B in this manner is our tools have evolved but the process has not. This is a dominant design for a pre-cloud era. When we apply this simple method of exchange to the cloud, the practicalities start to break down. This dominant design becomes wildly expensive, incurring storage costs per exchange, as well as egress and ingress costs and any costs involved with the actual bandwidth consumption.

Solutions to this process might include allowing access for local compute close to the stored data product. This could allow for running algorithms or querying data, perhaps. This workflow might also open the opportunity of location-oriented subscriptions. In this scenario, the needless data movement would be replaced with increasingly complex feature level authentication/authorization needs. But this is a better, more fit for purpose pattern.

In the end a new dominant designs around networked data access will emerge. Indeed, my suggestions is just the one that springs to mind. You are welcome, and I encourage you, to innovate your own. My point is the accidental application of old patterns to new toolkits.

Unprojected augmentations

Another process for future consideration is how we think specifically about spatial data storage and projection systems. The need of a projection system is because we don’t live on a flat Earth (sorry folks, I’m firm on this one). We needed data captured during surveys of our planet (local or global) to be visualized on a flat surface. So, we built mathematical projects to help us do that. There are thousands of these systems, and they each have different levels of accuracy and appropriateness for different locations. Traditionally, that flat surface would have been a paper map. Within the last 30 years, that surface was more likely to be a screen.

But, now we have GPUs (Graphics Processing Units). These are a complementary asset developed primarily from the gaming industry, but now sit in the centre of the AI revolution. GPUs mean that we can use far higher performance user interface technology. So, yes our screen might stay flat for a while, but they need not simply render a flat map anymore. Further, when we consider that Meta’s glasses have not been as throughly rejected as Google’s initial attempts at augmented reality glasses. Perhaps, the timing for this kind of technology has come.

With glasses, the resulting data will clearly not be flat, and it certainly won’t be viewed from a planimetric perspective. So where does that leave the core GIS/Geospatial activity of “reprojecting”? Indeed, if we have semi-accurate representations of our globe, do we need to at all? Even if we do need to reproject, can higher performance computing negate the need for the storage of multiple versions of the same data?

And note the use of the phrase, planimetric mapping. When will maps start to make more sense projected from the users perspective?

Again, this note is less of a series of answers. Instead I want to trigger your reflection on the processes we do every day. Which have we taken for granted that might be completely unnecessary or limiting.

The development of complementary assets around us and their subsequent new capabilities might allow our community to move in a series of new directions or leapfrog cumbersome and aging human processes. We should let them!

Arrive-Can’t

If you’ve followed the Canadian news in the last few years, you will likely have heard about the ArriveCan app procurement debacle. In essence, the Canadian Federal Government paid a contracting organization an astronomical amount of money to build a travel management app during the COVID pandemic. It’s hard to imagine how a company of 5 could spend $54m in 6 months, but that’s what happened. I expect a few late nights burning the midnight caviar were involved.

This piqued my interest because my team has always had a hard time winning Canadian federal government contracts. We have won a couple, but we are not well-designed for them. Generally, the boilerplate in these Requests For Proposals (RFPs) asks for the resume of the actual developers on any project. As a small team of experts, we must keep our team busy, so it’s hard to guarantee that a particular team member will be available for a competitive bid we may or may not win. We’ve always felt that if we won the project but had to change the project team immediately, our customers would think of it as a bait-and-switch. Effectively a corporate lie. So we’ve avoided these projects; much bigger companies or much smaller companies are better designed for these.

Those, and contracting companies.

In fact, contracting companies are the winners in serving the Canadian federal government. This means that most of the Canadian government technology sector serving Ottawa could be described as techno-gig workers.

In many ways, contracting is fine; it’s a low commitment for all. Contractors take on what they want and can write off their expenses as a small business. The companies have minimal fixed staff on payroll while commanding an army of resumes to attach to RFPs.

But this arrangement has resulted in a dearth of major Canadian primes because, in techno-gig land, no one retains any meaningful IP. Without that IP, the contracting companies never do anything other than rent resumes to take on roles. One could argue that this simple accident of boilerplate has resulted in a structure that directly impacts Canadian productivity. Government spending is one of the major levers of fiscal policy. If that lever never creates IP, then it has no long-tail impact, and Canadian productivity is left in neutral.

I have always felt that investing in staff development is a more respectful employee-employer relationship, allowing my team at Sparkgeo to build both human and intellectual capital.

So, in Canada, we have a government procurement problem. That’s no real surprise. But for the sake of this discussion, it means we have few major defence primes. In this industry article highlighting the Canadian defence industry punching above it’s weight, all the six listed top companies are foreign. MDA is a notable exception to this pattern.

As usual, there are two perfect times to solve this problem:

1) Twenty years ago.

2) Now.

Luckily, the brand new Defence Investment Agency and the Canada Defence Procurement Readiness Program were both announced this week. Notably, these focus on defence procurement, not the Canadian Government. Hopefully, with some success, patterns will echo throughout the institution.

Mercator’s conceit

In Canada, we generally assume that our only border of concern is that with the US to the South or West (yeah, Alaska, remember?) Mercator inadvertently taught us** to think East and West. But in many ways, we also share a border with Russia, not to our far West (so far it’s almost East), but to our North. The Canadian Northern border is absolutely enormous, and it’s largely empty. There are some critical Northern First Nations and Inuit communities, but the vastness and ruggedness of this area cannot be understated. It’s also ripping cold, or at least it was.

Because of the nature of this area, one could say that our backyard is somewhat unfenced. For the last fifty years, that was largely fine. We’ve had the Dew Line in case things got really bad, but we are still here, so the gambit of mutually assured destruction seems to have paid off. But now, our political and environmental landscapes have changed. We have a belligerent Russia, we have an opening Northwest Passage, and we have a resource-rich North defrosting. Our backyard has become much more attractive.

Side Note: The Panama Canal is getting shallower as less fresh water is available from the surrounding forested mountains and lakes to keep the canal full. Less precipitation in the surrounding rainforests is having a drastic effect. This will ultimately be an economic disaster for Panama. As that route becomes less viable, the Northwest Passage will be enormously attractive as the quickest route from Europe to Asia.

While Canadian sovereignty has been of deep concern recently, border management is not the only concern in the North. A new climate situation is slowly emerging from the melting Northern permafrost. The methane bomb, which has been forecasted, may or may not cause atmospheric havoc, depending on the area's greening. The fact is, neither scientists nor politicians know what will happen with such an enormous landscape change. What we do know is that we cannot monitor this vast, rugged area using human resources alone.

To compound the above issues, the Canadian North is also a literal gold mine for resources, which could provide well-paid jobs and a secure, independent economic future for Canada. Resources have always been a question of where. A very geographic activity balancing the costs of extraction and logistics against the price of a commodity. That said, the ethical extraction of resources is a hugely contentious issue, yet a pathway to a secure future for our country. Canada is one of the few nations that can genuinely consider the ethical extraction of resources within the context of indigenous communities, environmental management, and broader macro-economic pressures. Indeed, the wealth of a nation is more often than not related directly to the availability of natural resources. This kind of inventory of resources should be considered holistically because, while the Canadian North is not an easy place to reach or operate in, it is possible, and there is a wealth of opportunity.

Finding a needle in a haystack of needles

We have thousands of sensors in various orbits around our planet—far more than ever before. The sheer sensory capability we have access to today, even commercially, is stunning. Petabytes of imagery tumble out of Low Earth Orbit every day. We also have this notion of infinite compute. Obviously, that’s hyperbolic, but in practical terms, we have more storage and compute capability available than any of us is willing to pay for.

In fact, beyond Smart Space and The Cloud, we have at least six critical complementary assets that we can put to work. These assets can be combined in various patterns to build modern geospatial applications.

In fact, given that far more pixels are flowing out of the sky than any organization has the available eyes to examine, we need to leverage as much AI and compute capability as possible to understand our dynamic Earth. If we want to find any needles in this growing haystack of needles, we need to put the machines to work.

Knotty problem

So, we have several threads which we can consider in parallel.

• We have a vast, rugged, remote area which is of increasing value.

• That increasingly valuable asset is subject to an increasingly inhospitable political environment.

• We have a procurement system which has been identified as problematic, thus creating political interest in demonstrating an alternative (sunnier?) way.

• Critically, we have a technology environment that can be used to tie these threads together.

Not discussed above, but relevant:

• Canada has been under increasing pressure to meet NATO commitments, which is hard to do without those major Canadian defence primes to buy things from.

• The Canadian Defence budget has just been bumped up.

• Defence tech is hot.

There seems to be a unique opportunity to think about AI to better understand our enormous and dynamic land. In fact a combination of Earth observation and AI is the only way to do this.

But what does a venture like this need to look like? Is this venture investable? What kind of organization could build or operate this system? Should it be a company, or built by Canadian Government staff developers?

To define these options, we should consider the mechanics of an operation like this and what organizations would be willing to pay for some kind of Northern monitoring capability. Clearly, the Canadian Government would have an interest (that could be a combination of Canadian Border Services, the Coast Guard, the Territories, and possibly the Department of National Defence). Additionally, any shipping or shipping-related organizations would have an interest. Insurance and resource companies will also be motivated to understand ice presence or absence.

But critically, each of these organizations will demand a slightly different products, sculpted from a common monitoring service. These different products could be actuary reports, alert emails, anomaly maps, ice maps, and routing information wrapped up into PDF documents, emails, web maps and Application Programming Interface (API) endpoints. Each product demands a different complexity, time horizon, market positioning, sales structure, cost, and price.

The idea of a series of products emerging from a single landscape engine makes me immediately consider a geospatial foundation model as the base technology to feed a Northern monitoring capability. Powered by modern geospatial technology, one single monitoring capability, a Northern Eye if you like, could be leveraged to address a series of common problems within a particular policy, climate and political environment. This deep horizontal is a great example of how both the Geospatial and AI communities mirror and indeed reflect each other.

Share

* I still say thank you to Siri

** euro-centric reductionists, see Transitions