Over the past several months, we have had a series of conversations with CIOs, Chief Data Officers, and enterprise architects that all converged on the same question. Why do large organizations still maintain two completely different ways of organizing information?
Geospatial data is becoming more important as organizations try to understand assets, infrastructure, supply chains, customers, facilities, risk, and operations in the context of the physical world. The problem is that we have treated geospatial information as though it belongs in a separate architecture from the rest of the enterprise. That distinction made sense when GIS was primarily a specialist tool used by planners, cartographers, engineers, and analysts. It makes much less sense when AI is expected to reason across every piece of information an organization possesses. We have spent years connecting the two environments through APIs, synchronization jobs, and data pipelines. The more fundamental answer may be that there should not be two environments in the first place.
The geospatial industry deserves enormous credit for getting us here. Companies such as ESRI, Hexagon, Trimble, Planet, Maxar, and Safe Software transformed how organizations collect, process, and visualize information about the physical world. They built extraordinary systems for mapping, imagery, measurement, and spatial analysis. The architecture they created reflected the needs of the time. The map sat at the center of the system, and data was added to it as layers. Roads became one layer, parcels another, utilities another, satellite imagery another, followed by weather, vegetation, demographics, and infrastructure. Eventually, the organization built what we think of as the GIS layer cake.
The layer cake can be useful. A skilled analyst can switch layers on and off, compare them visually, and develop a much richer view of a problem. But adding more layers does not necessarily create more understanding. Sometimes it simply creates a taller cake.
The real world is not organized into layers. A refinery is not a layer. Neither is a pipeline, warehouse, transformer, customer, shipment, or insurance policy. These are entities with histories, relationships, documents, sensor observations, ownership, financial implications, and changing operational states. A map can display parts of that reality beautifully, but it does not inherently explain how those parts relate. The map was never the model. It was the interface through which people accessed the model, and often the model itself never really existed.
The deeper problem is the assumption that spatial data is a specialized category of enterprise data. It is not. All data is spatiotemporal because everything exists somewhere and everything happens at some point in time.
A maintenance record belongs to an asset at a location. A shipment moves through a sequence of places. A customer interacts with a store, service territory, facility, or network. A financial transaction is connected to people, companies, offices, assets, and markets that all exist within the real world. Even data that appears abstract becomes spatial and temporal once it is connected to the entity or event it describes.
This does not mean every dataset needs a latitude and longitude field. It means the enterprise architecture should understand how data relates to place, time, entities, and events. Traditional data systems tend to flatten those relationships into tables and transactions. Traditional GIS systems tend to express them as geometries and layers. AI needs the complete picture.
Space and time should therefore be native parts of the enterprise data foundation, not optional metadata or specialty functions. Spatial formats should move naturally through the same pipelines, notebooks, and AI workflows as conventional enterprise data.