I recently finished implementing a network analysis through PostGIS and pgRouting, exposed through an MCP interface so it can be called by AI. I have done versions of this as a Lambda and as a Google Cloud Function. Before that, I did it in Node. Before that, in ASP.NET with a different routing library. Before that, it was ArcObjects, which followed MapObjects, which followed Avenue, which followed AML.
Part of me hopes I never need to do this again. I say that not because routing is unimportant, or because the newer approaches lack value, but because I would like to stop re-implementing the same basic use case in the paradigm du jour and spend more time solving problems with it.
Looking back over the last twenty years, it is hard to argue that geospatial technology failed to advance. We gained capability at nearly every layer. We could collect more data, store more of it, process it faster, publish it more easily, and push it into systems that once treated geography as a specialized concern. Web maps are ordinary and spatial databases are passe. Open-source tools underpin every production platform we use. Cloud platforms brought scale and, more recently, AI has started to change how we search, summarize, classify, and assemble workflows. That’s all undeniable progress.
For most of that time, we kept returning to familiar problems. Where is it? What is nearby? What changed? What is exposed? Who owns it? How do we publish it? How do we scale it? How do we get it into the hands of people who need it?
Those questions are the daily vocabulary of GIS, and we have to keep asking them. They have survived every stack we have layered on top of them: desktop, server, web services, rich clients, JavaScript, mobile, cloud, cloud-native data, APIs, and now AI.
Each iteration arguably gave us better machinery, removed some constraints, and introduced others. Each promised to make old work easier, faster, or more accessible, and sometimes it did. But churn also carries opportunity costs. Re-solving old problems in new systems leaves less time to explore the next problems, whatever they are.
The lingering question for me, after working in this field for over thirty years and writing about it for twenty, is what is all of this capacity for?
Mid-2000’s enterprise web GIS is a useful example. It moved spatial information out of specialist desktops and into browsers, intranets, public sites, and adjacent business systems. More people could see and use the results of geospatial work. Geography could travel farther inside an organization. Today, looking up your own land records in the web map of your county planning department is taken for granted. Twenty years ago, that often required a trip to the planning office itself. That is clear progress.
That transition also exposed how much of desktop GIS had been taken for granted. Desktop GIS was stateful while web was stateless. That difference alone was a significant hurdle. Early web technology did not handle vectors well, so many systems rendered full maps dynamically as images on every round trip. Map tiles were later “side-loaded” into the consciousness of the geospatial world by Google. Editing raised another set of questions. Did updates even belong in the browser? Who owned the data once more people could touch it? What counted as authoritative? How should permissions, lineage, and trust work when the map was no longer sitting on one analyst’s machine?
Early attempts at GIS on the web were painful, but that’s okay. Sometimes the shift has to happen before the implications are fully visible. You build the thing, watch where it bends, fix what breaks, and keep going.
That is usually where the cost shows up. The old work doesn’t disappear when a new architecture arrives. Each subsequent stack solved a real problem, but none eliminated the work around the problem. We didn’t simply replace old tools with better ones. We carried forward unfinished work from each cycle, often while starting the next one.
When I say cost, it’s not only technical debt, though there was plenty of that. It was also unfinished absorption. A new stack can be implemented much faster than it can be metabolized into an organization. Software can be installed, services published, APIs exposed, data migrated, portals launched. Those can be intricate tasks, but they are just the first part of a transition. The work after that tends to be much slower.
I have written in the past that organizations, if they want to make the most of a technology investment, eventually lock themselves into that technology. This is true regardless of provenance. They align around the tech with new governance, skills, customizations, and processes. It can extend to adjacent concepts like procurement. Are we licensing seats or are we buying support for an open-source stack? Institutional memory has to adjust to expel the old and embrace the new. Workflows have to incorporate the new capability rather than merely admire it from across the room.
That is where value can be left on the table. A lift-and-shift to a new architecture can simply automate the same old workflow in a new place, but that misses the opportunity to revisit it and optimize it for the system now available. If an organization moves its central data store to PostGIS but still begins every task by pulling local shapefiles, it may have changed the architecture without changing the practice. At that point, the database looks less like analytical infrastructure and more like a shared folder with better branding.
The opportunity cost is not just another round of migration fatigue. It is delayed inquiry. We keep spending time on how to publish, move, visualize, and scale data. We spend cycles rebuilding the same application in the next framework. Those are problems, but they are not the real problems.
Meanwhile, harder questions remain underdeveloped. What decision is this improving? Who benefits from lower friction? What consequence, not output, should define success? What questions can we answer now that were previously out of reach?
Those questions, and others, are not downstream from implementation. They are the actual work. But they are easier to postpone when the next stack arrives with a fresh vocabulary and a new set of urgent tasks.
That is the opportunity cost of asking the same questions with new stacks. We keep postponing the questions that can only become visible after the stack is no longer the center of attention.
This is where the question becomes harder than a technology assessment. We have built capacity to collect, store, process, visualize, publish, integrate, monitor, predict, and automate. Those are significant capabilities and they are also intermediate verbs. They describe what a system can do, not what it is for.
Capacity can become a substitute for purpose. If we can process more data, publish more services, support more users, update more frequently, and render more smoothly, it is tempting to assume we are moving forward. That may even be true, but forward is a direction, not a destination. More capability does not tell us anything about benefits, accountability, or responsibility.
The real question is not whether the system can do more because most new systems can in a raw sense. The question is whether additional capacity helps people govern land more fairly, maintain infrastructure more intelligently, reduce exposure to risk, improve emergency response, allocate resources with better evidence, understand societal change, or make decisions that can be defended.
That is a higher bar than the successful completion of a system install. It can’t be measured with regression and integration testing. Beyond maps, services, dashboards, or APIs, the question asks whether the organization becomes better at noticing what matters, acting on what it knows, and remembering why a decision was made.
This is also where the current AI cycle should make us take a beat. AI will increase the amount of spatially relevant work that can be performed. Much of that will be useful and some will simply accelerate weak assumptions. If surrounding systems cannot govern provenance, uncertainty, and domain judgment, then more capacity may only serve to move the same problems faster.
That doesn’t make technology advancement pointless. It elevates the importance of the surrounding organizational environment. As geospatial systems can do more, are we disciplined enough to ask what doing more is supposed to accomplish?
So what actually got better? The answer is not “nothing.” That would be too easy, and wrong. More people can do spatial work in more places with less specialized infrastructure. Smaller teams can build useful systems without waiting for a large enterprise program to bless every moving part. Spatial data can move through applications, databases, services, files, and APIs in ways that would have been much harder to sustain twenty years ago.
That is meaningful change. Spatial capability is no longer trapped inside a small number of specialist tools. A database can perform spatial analysis, a web application can use location without pretending to be a full GIS, a field worker can collect useful data with a phone, and open-source tools are foundational to the geospatial field. More organizations can put geography into their production systems rather than treating it as a separate step at the end.
But wider access doesn’t guarantee better questions. Faster processing does not guarantee better assumptions. Better visualization does not guarantee better understanding. More automation does not guarantee more accountability. The fact that spatial work can now move more easily through modern systems does not mean those systems know what the work is supposed to do.
That may be the uncomfortable lesson of the last twenty years. Newer tools lowered many barriers, but those that remain are less technical and harder to buy or build our way through.
In that sense, the technology made geospatial work easier to perform and harder to excuse. When geospatial was brittle, expensive, and specialized, it was easier to blame the tools. That excuse has less force now. If the work still fails to improve decisions, the problem may not be the absence of capability. It may be the absence of clarity around what that capability is for. Demonstrable, undeniable improvement in the technology leaves us with more responsibility for the outcomes.
