Google Earth: The World We Were Given, the World We Are Losing, and the One We Could Still Build

Oct 19

How a virtual globe transformed geospatial intelligence, challenged the economics of professional GIS, and revealed an opportunity the industry has yet to fully realize.

In 2005, an ordinary computer user could download a program, type a location into a search bar, and watch the Earth move beneath them. The camera descended from space, passing continents, coastlines, mountains, cities, and neighborhoods before arriving at a familiar building or an unfamiliar corner of the planet. The experience was remarkably intuitive, even though the technology behind it was anything but simple. What previously required specialized geographic systems, access to imagery archives, and some understanding of cartography could suddenly begin with a mouse, an internet connection, and a question about a place.

For millions of people, Google Earth was their first meaningful encounter with satellite imagery as an interactive medium. It transformed something that had traditionally belonged to scientists, military analysts, cartographers, and government agencies into a form of geographic exploration available to almost anyone. Students could explore distant landscapes, journalists could illustrate international conflicts, and communities could better understand the environments around them. Geography became something people could navigate rather than merely read about, and satellite imagery became a familiar visual language instead of an exotic technical product.

Yet the most important aspect of Google Earth was never simply the ability to look at the planet. The application allowed people to place their own information onto that shared geographic environment, interact with it, organize it, and communicate it to others. Through placemarks, image overlays, KML files, KMZ archives, network links, and virtual tours, users discovered that a powerful geospatial visualization environment did not necessarily require years of training or expensive enterprise software. The person looking at the map could also become its author, analyst, and distributor.

That accessibility had consequences extending well beyond the consumer technology market. It challenged assumptions about the cost and complexity of professional GIS, introduced new expectations into defense and intelligence workflows, influenced the development of competing software, and inspired a generation of users who occupied the expanding space between casual geographic curiosity and specialized geospatial engineering. Google Earth demonstrated that the technical sophistication of a platform did not have to determine the complexity of its user experience.

More than two decades after its launch, Google Earth remains an important and evolving product. Google has expanded browser and mobile access, introduced collaborative projects, improved historical imagery and environmental exploration, and begun incorporating artificial intelligence into geographic workflows. These developments deserve recognition, particularly as cloud technologies and modern web applications make capabilities available to audiences that would previously have needed desktop software.

At the same time, Google's decision to stop offering new downloads of Google Earth Pro beginning June 25, 2027, raises questions about what happens to the workflows and communities that grew around the original desktop application. Existing installations are not being switched off on that date, but the decision marks a significant change in how new users will encounter the product. It also invites a broader examination of Google's geospatial history, including the retirement of Fusion Tables, the separation between Google Earth and the powerful analytical capabilities of Earth Engine, and the emergence of alternative applications attempting to preserve or extend the original experience.

The story is therefore not simply one of a beloved desktop application being overtaken by the browser. It is about how an extraordinarily successful model of geographic accessibility evolved into a collection of increasingly capable but sometimes disconnected technologies. It is also about what remains possible if the industry can reconnect powerful analysis, approachable data management, intuitive visualization, and effortless distribution into a common geographic environment.

Before the World Was at Your Fingertips

From Specialized Geographic Systems to a Global Visual Experience

Before Google Earth, the ability to explore geographic information digitally was already well established, but the experience was far from universal. Professional GIS systems enabled sophisticated analysis, mapping, and database management, while remote-sensing applications supported increasingly complex imagery exploitation. The Internet was also introducing public mapping services and online atlases. Nevertheless, these capabilities often existed in separate environments, each with its own technical requirements, datasets, commercial arrangements, and intended audience.

Obtaining satellite imagery could be particularly cumbersome. Users might need to identify a provider, locate the appropriate imagery, understand geographic coordinates and coverage, and acquire files that required specialized tools to display correctly. The cost and effort of this process could be justified for detailed analysis, but it created substantial barriers for people asking simpler geographic questions. Even when imagery was publicly available, turning it into an accessible visualization could require considerable technical preparation.

Traditional GIS software was designed to solve complex geographic problems, and that complexity was often essential to its purpose. Coordinate reference systems, projections, databases, spatial relationships, metadata, and analytical operations all mattered. Yet those same capabilities could make ordinary exploration feel unnecessarily difficult. Someone who wanted to understand the geography surrounding a potential construction site or compare the locations of several facilities might spend more time preparing the software environment than examining the landscape.

The technology that would change these expectations emerged from outside the traditional GIS industry. Keyhole, Inc., originating from the computer graphics technology associated with Intrinsic Graphics, developed EarthViewer 3D as an interactive way to navigate imagery across a three-dimensional planet. Among the important figures in its development were John Hanke and Brian McClendon, who helped establish a product that treated geographic visualization as a continuous experience rather than a sequence of separately opened maps.

EarthViewer's technical achievement was significant because it hid much of the machinery required to navigate enormous collections of geographic imagery. Users could transition from a planetary view toward increasingly detailed imagery while the application managed much of the rendering and geographic positioning behind the scenes. The interface made geography feel fluid and immediate, borrowing more from interactive computer graphics than the conventional GIS workstation.

The business environment surrounding Keyhole was considerably less stable than the technical demonstration suggested. The company emerged during the difficult period following the collapse of the dot-com boom, when venture financing had tightened and many promising software businesses struggled to find sustainable commercial markets. Keyhole's visibility expanded substantially when CNN used EarthViewer technology during its coverage of the 2003 invasion of Iraq. The animated geographic perspectives exposed a much wider public audience to the possibility of exploring real-world places through a three-dimensional interface.

Google acquired Keyhole in 2004 and launched Google Earth in 2005, bringing the technology into a distribution ecosystem capable of reaching millions of users. Google's infrastructure, access to imagery, consumer recognition, and ability to integrate geographic information with search helped turn what had been a specialized visualization product into a global phenomenon.

The significance of that transformation should not be understated. Google made geographic imagery and an advanced virtual globe accessible to people who had never considered purchasing GIS software. The initial attraction was visual, but it created an important new expectation: understanding a place should not require a professional workflow unless the question itself demands one.

That expectation would become even more disruptive as users discovered that Google Earth could display more than Google's own geographic information.

The Globe That Changed the Rules

KML, KMZ, and the Democratization of Geographic Authorship

Google Earth's familiar globe provided a shared geographic reference, but Keyhole Markup Language gave users a way to contribute their own information to it. KML, built on XML, allowed geographic content to be described in a comparatively approachable format. Placemark locations, geometric features, image overlays, descriptions, styling, camera positions, and time-dependent information could be organized into files that the application understood. Compressed KMZ archives could package KML and supporting resources together, making geographic projects easier to move between people and organizations.

The resulting workflow was unusually powerful because it reduced the technical assumptions made about the recipient. An analyst could create a collection of locations, attach contextual information, save the result, and send it to a colleague who needed only a compatible application to explore it. An educator could build a geographic lesson with placemarks and imagery, while a researcher could distribute a map of field observations without requiring every collaborator to operate the same enterprise database or specialist GIS environment.

The ability to share interactive geographic information was fundamentally different from sending a conventional map image. A static image preserved the author's chosen perspective, but a KML or KMZ project allowed the recipient to explore the information, change the geographic viewpoint, activate or deactivate layers, and examine individual features. The data could remain accessible rather than being permanently flattened into a presentation.

KML was in many respects a precursor to the lightweight geographic information exchange that later became closely associated with formats such as GeoJSON. The two formats serve different purposes, and KML was especially expressive about geographic presentation, camera behavior, tours, and overlays. Nevertheless, both reflected an important principle: geographic information could be represented in a reasonably portable format that did not require the recipient to possess the original author's software project or database environment. The Open Geospatial Consortium's adoption of KML as an open standard in 2008 further reinforced its importance beyond Google's own products.

Network Links and the Early Distribution of Dynamic Geographic Information

Among KML's most consequential capabilities were network links. A conventional geographic file might contain a fixed collection of observations, but a KML network link could point toward information maintained on an external server. Depending on how the link was configured, a Google Earth project could retrieve updated geographic content rather than requiring users to receive and reopen a newly distributed file each time the underlying information changed.

For analysts and organizations responsible for maintaining geographic situational awareness, this created an accessible method of distributing updated information. A central source could maintain current locations, boundaries, or other observations, while multiple users viewed that information through the same familiar application. The underlying infrastructure could remain relatively simple, particularly when compared with a custom-built enterprise visualization environment.

These capabilities were not a substitute for a comprehensive operational data architecture. Network reliability, server maintenance, data quality, and refresh configuration still mattered. Nevertheless, the combination of KML and network links enabled workflows that were surprisingly advanced for a consumer-facing application. In some circumstances, the difference between receiving a static spreadsheet and opening a geographic layer that retrieved its latest information could dramatically improve how quickly a user understood a changing situation.

Google Earth's approach also influenced how geographic information could be distributed beyond professional circles. A user could share a KMZ with a local community organization, publish a network link for outside users, attach geographic observations to a report, or create a virtual tour that guided an audience through an important location. The same underlying information could support analysis, education, public communication, and informal collaboration without requiring the audience to acquire a professional GIS license.

The Rise of the Geospatial Middle Market

This accessibility helped create a substantial community of users whose needs fell between casual map browsing and full-scale GIS engineering. Environmental consultants, small businesses, investigative journalists, educators, nonprofit organizations, urban planners, field researchers, and independent analysts all had reasons to work with geographic information. Many understood their subject matter in considerable depth but had limited interest in managing complex GIS software environments.

The distinction is important because this audience did not necessarily need less capable software. It needed software that made sophisticated capabilities easier to reach. A consultant evaluating a possible development site might need to combine terrain, imagery, infrastructure data, and historical observations, but not necessarily perform advanced spatial modeling. An investigative journalist might need to organize evidence geographically and communicate relationships to a public audience. A disaster-response organization might need to combine available information quickly before investing in more elaborate analysis.

These users required the ability to move between different levels of complexity without being forced into an environment designed exclusively for specialists. Google Earth succeeded because it allowed geographic understanding to begin almost immediately and become more sophisticated as the situation required.

For many of these users, the benefits were primarily practical. Inside military and intelligence organizations, however, the same simplicity could challenge established software procurement and contracting assumptions.

The Disruption Inside Defense and Intelligence

Military and intelligence agencies had long invested in specialized geospatial technologies, including proprietary visualization environments, imagery exploitation tools, enterprise databases, and applications developed or integrated by defense contractors. Many of these systems fulfilled essential requirements involving classification, precision, security, mission-specific analysis, and controlled dissemination. Those requirements could not simply be replaced by a consumer application.

However, not every question required the most sophisticated system available. An analyst examining a military installation, planning an initial collection requirement, assessing geographic access routes, or preparing a situational briefing might need to visualize information rapidly rather than conduct an extensive analytical process. In these circumstances, Google Earth's familiar globe, high-resolution imagery, intuitive drawing tools, and KML support could be extraordinarily effective.

My own experience in the United States Air Force illustrates the extent of this divide. Between 2005 and 2012, I worked as an imagery analyst with experience involving systems such as Global Hawk, U-2, and Predator. During that period, our missions frequently presented relatively straightforward geographic questions, yet the tools available to answer them could be considerably more complex than the tasks themselves. Applications such as ArcMap and SOCET GXP provided sophisticated imagery exploitation and geospatial analysis capabilities, but many routine operational questions did not require the full range of functions those applications were designed to support.

As analysts, we sometimes found ourselves spending more time navigating specialized software, preparing data, or developing formal products than the immediate question warranted. A mission partner might need a quick visual assessment, geographic orientation, or confirmation of a feature in imagery. Producing a finished intelligence product through an established exploitation workflow could provide substantial analytical rigor, but it was not always the most efficient response to a time-sensitive request.

Google Earth offered a remarkably different approach. Analysts began installing and adapting the application within their working environments, finding ways to bring geographic information into the familiar globe without relying on a contractor-developed interface for every visualization requirement. In workflows where imagery from airborne collection platforms could be made available in a compatible form, we sometimes used Google Earth to examine collected images against the surrounding geographic context. Rather than viewing imagery as an isolated scene, we could immediately relate it to the roads, terrain, facilities, and other features visible in the basemap.

The benefit was often the speed with which a geographic observation could become useful to another person. After examining imagery in its surrounding context, we could communicate a finding through mission chat or create a quick visual product using a captured Google Earth view. In some cases, a screenshot placed into PowerPoint provided exactly the geographic explanation a mission partner needed. The result was not necessarily a substitute for a fully exploited intelligence product, nor was it intended to replace precision mensuration or other specialized analytical processes. It was a faster way to deliver geographic understanding when the operational question did not justify the complexity of a larger production workflow.

This experience contributed to a broader effort to incorporate Google Earth into military geospatial practices. I co-founded the Joint Intelligence Google Earth Working Group with community colleague, Brian Morrision. The JIGEWG operated from approximately 2008 to 2015 as a grass roots endeavor by users within the federal government for Google Earth educational resources, community best practices, and a repo for sharing favorite KML/KMZ files. The working group's purpose was connected to the practical challenge of integrating Google Earth into an established military intelligence ecosystem. Its existence reflected the extent to which analysts and other practitioners saw potential in a tool that had originated outside traditional defense software acquisition.

One of the most revealing aspects of this experience was how quickly ordinary analysts could adapt the application. Google Earth was comparatively easy to install, learn, teach, and operate. Data could be brought into the application through familiar file formats, geographic annotations could be created with relatively little training, and results could be distributed through screenshots, presentations, or KML and KMZ files. These characteristics allowed analysts to solve certain visualization and communication problems themselves rather than depending on a contractor to develop or modify a specialized application.

The implications were larger than the convenience of one piece of software. Defense contracting frequently involves substantial investment in application development, integration, maintenance, and specialized user interfaces. Google Earth demonstrated that some geographic visualization requirements could be met through a low-cost, widely available application adapted by the analysts who understood the mission. In the workflows I encountered, the ability to move directly from imagery to geographic context and then to a usable response could be more valuable than the additional capabilities of an elaborate system that took longer to operate.

This created an uncomfortable comparison for expensive proprietary visualization tools. If an analyst could accomplish a basic task quickly using Google Earth, a specialized application needed to demonstrate the added value of its analytical methods, security architecture, data integration, or mission-specific capabilities. The fact that Google Earth could provide a practical solution did not mean defense contractors were unnecessary. It meant that geographic visualization alone was no longer sufficient justification for software complexity or cost.

There was also an important organizational lesson. The people closest to the mission often understood which tools were necessary and which obstacles were imposed by established technical processes. When analysts could adapt a relatively simple application to answer a real operational question, they sometimes produced useful improvements faster than a formal development cycle could deliver them. That flexibility was not without limits, including software authorization, cybersecurity, data classification, and integration requirements. Nevertheless, it demonstrated the value of allowing users to influence how technology supports their work.

The experience reinforced a distinction that remains relevant across the geospatial industry. Highly sophisticated analytical systems are essential for certain tasks, but their sophistication should not become an obstacle to simple geographic understanding. Sometimes the most useful tool is the one that allows an analyst to look at the data, understand the context, and communicate the answer before the operational value of the information has diminished.

Esri and the Struggle Over the User Experience

Google Earth's success created a similar challenge for Esri, whose ArcGIS products represented a far more comprehensive environment for spatial analysis, authoritative data management, and enterprise GIS operations. The two companies did not offer interchangeable products, and reducing their competition to a contest between an attractive globe and a complicated analytical system would misrepresent the strengths of both.

Esri's products were designed to manage complex spatial information across organizations, support controlled editing and database administration, conduct sophisticated analysis, and provide repeatable professional workflows. Google Earth was not a replacement for those capabilities. Instead, its disruptive influence came from making spatial visualization so intuitive that users began questioning why comparable experiences were often more difficult in professional software.

Esri responded through products and approaches that emphasized easier geographic exploration. ArcGIS Explorer provided an approachable desktop mapping environment, while ArcGIS Earth later introduced a free desktop globe supporting KML, familiar geographic navigation, measurements, and access to Esri's broader data and services ecosystem. ArcGIS Earth was particularly relevant to organizations already using ArcGIS infrastructure because it combined an intuitive viewing experience with existing enterprise services and institutional workflows.

Yet matching individual capabilities was not equivalent to recreating Google's enormous cultural reach. Google Earth benefited from broad consumer familiarity, a recognizable imagery environment, simple geographic search, and an established community of people exchanging geographic files. Its adoption extended well beyond organizations that considered themselves customers of the GIS industry. Esri could offer powerful globe capabilities without automatically replicating the same scale of recognition among general computer users.

The longer-term result was a change in the industry's understanding of software accessibility. Professional GIS vendors increasingly had to account for intuitive visualization, rapid geographic exploration, web-based sharing, and the expectations of audiences who were not trained GIS specialists. Google Earth demonstrated that the experience of interacting with geographic data could be a competitive advantage in its own right, even when the underlying analytical capabilities were comparatively limited.

The same realization also pointed toward a larger possibility. If ordinary users could visualize geographic information so easily, why couldn't they manage, update, analyze, and collaborate around that information with similar simplicity?

A Digital Twin Before We Had a Name for It

Long before digital twins became a recurring theme in technology marketing, Google Earth demonstrated the appeal of representing the physical world through a common digital geographic environment. Users could navigate terrain, examine imagery, view three-dimensional buildings, place observations in geographic context, and explore changes across time. Geographic information from different sources could be combined visually around the same recognizable landscape.

Google Earth was not a complete digital twin in the modern engineering sense. It did not inherently reproduce the live operational state of infrastructure, integrate every asset with sensors, or simulate the physical behavior of a city or industrial facility. Nevertheless, it introduced a remarkably broad audience to the foundational idea that complex information becomes easier to interpret when organized around a navigable representation of the real world.

The value of this approach extended across industries. Urban planners could consider proposed development within an existing landscape, environmental researchers could place observations into geographic context, and military analysts could assess how facilities related to roads, terrain, and surrounding infrastructure. The underlying principle was consistent: geographic information became more meaningful when people could interact with it dynamically rather than interpret isolated coordinates, tables, or static illustrations.

KML and network links reinforced this early digital-twin-like environment by allowing independently maintained information to appear within the same geographic view. The globe could become a common visual reference for many different subjects without requiring each dataset to originate within Google's own systems.

Yet the appearance of a unified world did not guarantee that the information displayed on it was consistently managed. A user might maintain several KMZ files, subscribe to multiple network links, import data from different organizations, and create elaborate projects without possessing a dependable way to document versions, reconcile changes, or manage collaboration across an expanding collection of geographic information.

The limitations of that approach revealed a missing part of the original vision: if Google Earth could make geographic information so easy to visualize, perhaps the information behind the globe could become equally approachable to maintain.

Fusion Tables and the Data-Management Opportunity

Google Earth had made geographic visualization extraordinarily accessible, but maintaining the information behind a map remained more difficult. Users needed ways to organize observations, update attributes, combine datasets, document sources, and publish reised information without recreating their geographic projects every time a spreadsheet changed.

Google Fusion Tables briefly provided a promising answer to part of this problem. Originally developed as an experimental Google Labs service, Fusion Tables allowed people to upload structured information, combine tables, visualize records, and share results through comparatively approachable interfaces. Its geographic visualization capabilities were especially valuable to users who needed to maintain datasets without operating a professional database environment.

Fusion Tables was not a replacement for an enterprise geodatabase, nor was it designed to handle every form of spatial analysis. Its importance was that it occupied a valuable middle ground. A journalist or nonprofit organization could work with a collection of locations, maintain related attributes, create geographic visualizations, and publish information without first commissioning a database application or employing a dedicated GIS administrator.

The implications for the Google Earth ecosystem were substantial. A platform combining Earth's intuitive globe with straightforward data management could have offered a continuous path from collecting observations to maintaining a geographic project and communicating the result. Community contributors might have developed durable datasets, preserved source information, and shared updates without treating every file exchange as a separate technical problem.

Instead, Google retired Fusion Tables and its API on December 3, 2019, directing users toward a growing collection of more specialized alternatives. Services such as BigQuery offered substantially greater capacity for many analytical applications, but the transition also reflected a change in the expected technical abilities of the user.

For a developer or data engineer, a sophisticated cloud data platform can be an extraordinary resource. For an environmental consultant maintaining a few thousand geographic observations or a journalist combining public datasets, it can introduce additional considerations involving billing, permissions, database structures, queries, and application development. Greater computational sophistication does not automatically produce greater accessibility.

Google continued offering important mapping, analytics, and collaboration tools, including My Maps, Sheets, Earth projects, Maps Platform, and BigQuery. The problem was not the total absence of alternatives. It was the lack of a consistently straightforward experience connecting geographic exploration, dataset management, and distribution for people who did not want to become software developers.

The disappearance of Fusion Tables thus represented more than the retirement of a single product. It illustrated how a technology ecosystem could become more capable while losing an approachable intermediate layer that had enabled non-specialists to participate meaningfully.

The Earth Engine Paradox: Extraordinary Intelligence, an Uneven Path to Accessibility

The gap becomes even more pronounced when considering Google Earth Engine, one of Google's most important contributions to modern geospatial analysis. Earth Engine provides access to extensive collections of satellite imagery and environmental datasets, supported by computational infrastructure capable of processing geographic information at scales far beyond an ordinary personal computer. Its capabilities have enabled significant work in land-cover monitoring, deforestation, agriculture, disaster research, climate science, and environmental analysis.

For researchers and technically proficient analysts, the platform represents an extraordinary achievement. It reduces the need to maintain enormous local imagery collections and provides ways to process extensive geographic datasets through powerful cloud infrastructure. Its catalog includes imagery and products from important sources such as Landsat, Sentinel, MODIS, and numerous environmental and scientific datasets.

However, Earth Engine also demonstrates a different philosophy of accessibility from the one that made Google Earth successful. Its primary analytical workflows are built around JavaScript, Python, APIs, and cloud projects. Although Google provides a dataset catalog and allows developers to publish Earth Engine Apps that non-programmers can use, gaining independent access to the full analytical environment still commonly requires programming knowledge or reliance on someone who possesses it.

This creates an unusual divide. The geospatial industry has more accessible imagery, computational capacity, and analytical techniques than at almost any previous point in its history, but a substantial audience still encounters technical obstacles when trying to answer relatively straightforward questions.

An urban planner might want to examine vegetation changes around a development corridor over the past decade. A journalist might want to explore surface-water changes or historical patterns of land disturbance. An agricultural consultant might need to compare imagery from several dates, inspect the provenance of a dataset, and share observations with a client. Each may possess substantial knowledge of the subject being investigated without needing to understand the programming constructs required to filter and process an Earth Engine image collection.

These users are not asking for intelligence to be removed from the platform. They are asking for the underlying complexity to be organized around the questions they are trying to answer.

The broader community has already demonstrated demand for this kind of accessibility. Libraries such as geemap make Earth Engine easier to visualize and use within interactive Python environments, while Earth Engine Apps allow technical specialists to publish simplified applications for wider audiences. Community-maintained data catalogs and other open geospatial initiatives help users discover resources beyond Google's own curated collections.

These projects are important, but they also illustrate the fragmentation of the experience. An analyst may need one tool to discover a dataset, another to process it, a third to visualize it, and additional services to preserve and distribute the result. That arrangement can be perfectly reasonable for specialized workflows, but it imposes unnecessary effort on the large population of users seeking a geographic answer rather than a software development project.

A more accessible model would allow a user to explore a region, discover relevant datasets through a community-supported catalog, evaluate coverage and source quality, and select common analytical operations through an intuitive interface. The resulting geographic information could then be saved, organized, shared, or exported without forcing the user to abandon the environment in which the investigation began.

Such a platform would not eliminate scripting or advanced analytical workflows. Developers, scientists, and experienced GIS professionals would continue to benefit from direct access to sophisticated processing capabilities. Instead, the system would provide a gradual progression from basic exploration to increasingly complex analysis, allowing technical depth to emerge when required rather than presenting it as an entrance requirement.

The opportunity is especially compelling because Google already possesses many of the necessary components. Google Earth offers an internationally familiar geographic interface, Earth Engine provides extensive data and computational capacity, and Google's broader software ecosystem includes collaborative and data-management infrastructure. Connecting those strengths through a more approachable analytical and geographic workspace could extend the original Google Earth philosophy into an entirely new generation of geospatial intelligence.

The irony is that the company that helped remove the complexity from geographic visualization now operates one of the world's most sophisticated geographic analytical platforms, while the experience connecting these two achievements remains incomplete.

Google Earth Grows Up: The Platform Still Evolving

It would be misleading to interpret Google's changing approach to Earth as evidence that the company has stopped investing in geospatial accessibility. In many respects, the modern Google Earth platform is more capable, more widely available, and better connected to contemporary data services than the application that first captivated users in 2005. The transition to browser and mobile environments has enabled new forms of collaboration, improved access across devices, and a more consistent experience for people who cannot install specialized desktop software.

Modern Google Earth continues to build on the original appeal of intuitive geographic exploration. Three-dimensional cities, terrain, Street View integration, historical imagery, and environmental datasets provide ways to examine locations in considerable depth. Users can organize geographic projects, collaborate with colleagues, and distribute information through browser-accessible experiences. For schools, public agencies, community organizations, and casual researchers, reducing the installation barrier can be an important improvement.

Historical imagery is one of the clearest examples of how Google's continuing investment expands the usefulness of the platform. Understanding a location is not simply a matter of knowing what it looks like today. Historical imagery allows users to examine changes in development, infrastructure, vegetation, and land use over time. Google Earth Timelapse further demonstrates how a geographic visualization can communicate large environmental and human transformations to audiences that might never interact directly with a satellite imagery processing environment.

Google has also continued expanding the analytical capabilities available through modern Earth experiences. Improvements to data imports, measurements, environmental exploration, and project management indicate that the web version is not intended to remain merely a simplified visual demonstration. The company has increasingly emphasized useful geographic insights alongside the familiar experience of exploring the globe.

These developments reflect substantial advantages of modern web technologies. Browser-based applications can offer accessible collaboration, platform-independent interfaces, regular feature updates, and the ability to share projects without requiring every participant to maintain an identical software installation. New generations of GPU acceleration, WebAssembly, client-side processing, and cloud-native geospatial data formats are also reducing the technical limitations that once made browsers poorly suited to sophisticated geographic work.

The distinction matters because the debate should not be reduced to the assumption that desktop applications are powerful while browsers are inherently constrained. A well-designed web application can perform substantial analytical and visualization tasks, and a poorly designed desktop application can become just as cumbersome as any enterprise system. The more important question is whether the modern environment preserves the particular capabilities and workflows that users need, especially when those workflows fall outside the most common consumer use cases.

Artificial Intelligence and the Next Accessibility Breakthrough

Google Earth's growing emphasis on artificial intelligence introduces another important dimension. AI has the potential to simplify interaction with complex geographic information in ways that conventional user-interface design alone cannot easily achieve. Natural-language interaction, automated data discovery, suggested analytical workflows, and assistance with interpreting source metadata could reduce the number of technical steps separating a user's question from a useful geographic answer.

This possibility is particularly relevant to the middle-market users who benefited from Google Earth's original design. The challenge for these users is often not a lack of intelligence, curiosity, or subject-matter expertise. It is that conventional software requires users to translate their questions into a sequence of specialized technical operations. A planner may know precisely what geographic relationships need to be examined but not which processing tool produces the required output. A journalist may understand the investigative significance of a dataset but lack the programming experience needed to combine it with imagery. An analyst may know which geographic comparison matters but waste time navigating several applications to prepare the result.

An AI-assisted geographic interface could allow users to express these questions directly, receive guidance about relevant datasets and analytical approaches, and perform common operations without manually constructing every intermediate step. A request to compare infrastructure growth around an installation, identify land-cover changes near a proposed development, or assemble the available public datasets for a specific region could initiate a workflow that previously required considerable familiarity with multiple software environments.

The value would come from using AI to expose the capabilities of sophisticated geospatial systems rather than disguising or removing them. Users should be able to inspect the selected datasets, understand the processing performed, evaluate assumptions, review geographic accuracy, and modify the result. A trustworthy AI assistant would provide a transparent route into analytical depth, allowing users to move between simple interactions and advanced controls whenever the task demands it.

This is a different proposition from using generative AI merely to create attractive geographic illustrations. Synthetic visualizations can be useful for hypothetical planning, education, and scenario communication, but they must remain clearly distinguishable from observed satellite imagery or authoritative geographic evidence. A system that generates plausible-looking landscapes without appropriately identifying their synthetic origin risks undermining the credibility that made Google Earth useful for journalism, science, and intelligence.

The ideal application of AI would therefore be grounded in verified geographic information and transparent analytical operations. AI should make it easier to find, question, compare, process, and communicate real data, while preserving the ability to distinguish measured facts from interpretation and speculation. It should also make it possible to reproduce the analytical workflow, inspect uncertainty, and correct mistakes rather than simply accepting an apparently convincing answer.

If implemented carefully, this could become the next major advance in geospatial democratization. Google Earth originally hid much of the technical complexity of navigating global imagery. AI-assisted interaction could extend that achievement by simplifying access to geographic datasets and analytical methods that presently require extensive training or programming experience.

Why Interaction Matters More Than a Longer Feature List

One of Google Earth's defining strengths was the directness of its interaction model. Users could move the globe, examine a landscape, activate layers, change perspectives, measure distances, and share their observations without feeling that the application itself had become the primary object of attention.

That quality can be difficult to preserve as software grows more sophisticated. Advanced geospatial applications often accumulate extensive menus, toolbars, panels, processing dialogs, and configuration options. Many of these features are necessary, but their presence can impose cognitive costs on users who need only a particular subset of the platform's capabilities.

The middle market does not necessarily want fewer capabilities. It wants capabilities that can be reached quickly and understood in context. Simple tasks should remain simple, while sophisticated processes should be available without forcing every user to become an expert in the software's internal organization.

This distinction becomes particularly important as geospatial software incorporates AI, cloud processing, massive imagery catalogs, and increasingly detailed three-dimensional environments. Adding more tools does not automatically make a system more useful. The real achievement will be integrating those tools into an experience where geographic information remains the center of attention and the software responds naturally to the user's intent.

Google Earth succeeded because it made interacting with the world feel easier than interacting with the application. The next generation of geospatial software will need to retain that quality while supporting analytical capabilities far beyond those available in 2005.

The Great Migration: What the Browser Gains and the Desktop Leaves Behind

The evolution of Google Earth toward browser and mobile environments reflects a broader technological shift. Software companies increasingly favor applications that can be distributed and maintained through the web, allowing users to access services across devices while developers update the platform centrally. For many audiences, this approach offers clear advantages in convenience, collaboration, security maintenance, and accessibility.

Yet Google Earth Pro's desktop history created a distinctive collection of workflows that cannot be evaluated solely by whether the modern web application offers an equivalent-looking interface. Users accumulated geographic libraries, developed procedures for importing and distributing data, maintained external network-linked layers, and incorporated local project files into organizational processes. These activities often relied on the ability to treat Google Earth as a flexible geographic workspace rather than a centrally managed service.

The classic desktop application gave users considerable control over how they organized their geographic information. KML and KMZ projects could be stored as files, copied between computers, preserved in archives, exchanged through familiar communication channels, or connected to external information sources. For users handling large collections of geographic observations, these workflows provided a straightforward degree of portability and independence.

The desktop application was never entirely disconnected from Google's infrastructure. Global imagery and many other services required network access, and the presence of a locally installed application did not guarantee complete offline functionality. Nevertheless, local project management remained an important part of the product's appeal. Users could distinguish between the geographic information they maintained themselves and the background services supplied by Google or other organizations.

Browser-based Earth introduces a different combination of capabilities. Web projects can simplify collaboration, reduce installation barriers, and provide more consistent access for users working across multiple devices. Google can also introduce improvements without requiring every user to manually install a new version of the software. These advantages are especially meaningful for classrooms, public communication, and organizations that need to share geographic projects with large audiences.

The tradeoffs become more apparent when users attempt to reproduce workflows involving specialized KML features, network-linked sources, complex imported information, locally organized archives, or precise control over the handling of sensitive data. Not all of these capabilities are absent from modern Earth, and feature support continues to evolve. Nevertheless, the distinction between a familiar project interface and a complete replacement for an established workflow remains important.

What the Missing Middle Actually Needs

The challenge is best understood by examining the tasks that made Google Earth indispensable to intermediate users. Many were not performing the most advanced spatial analysis available, but neither were they merely looking at their homes. They were working with geographic information in practical, sometimes sophisticated ways, and the success of their workflow depended on the ability to move quickly between visualization, organization, analysis, and communication.

The following comparison focuses on those activities rather than treating desktop and browser applications as inherently superior or inferior architectures.

      
        
            Capability or workflow
            Google Earth Pro desktop
            Modern Google Earth web/mobile
            Why it matters to the middle market
          

        
            KML and KMZ project management
            Established local file workflows, folders, placemarks, styles, overlays, and import/export
            KML/KMZ imports and saved projects, with different organization and compatibility details
            Allows users to maintain, reuse, and distribute geographic information without building a dedicated data system
          

            Network links and external feeds
            Established KML NetworkLink support, including refresh-oriented workflows
            KML support continues, but specialized link behaviors require individual compatibility testing
            Enables independently maintained geographic information to appear in a common visual environment
          

            Image overlays
            Local image and ground-overlay workflows, transparency, and geographic positioning
            Evolving imagery and data-import options
            Useful for historical maps, site plans, independent imagery, and quick geographic comparisons
          

            Historical imagery
            Mature historical imagery tools integrated into the desktop globe
            Expanded historical imagery access and historical Street View capabilities
            Provides accessible temporal context for site assessments, investigations, planning, and education
          

            Tours and guided visualization
            Camera-based KML tours, saved views, and presentation workflows
            Collaborative projects and geographic storytelling, with different tour functionality
            Allows users to explain spatial relationships to audiences without GIS training
          

            Snapshots and visual exports
            Familiar capture and presentation workflows
            Browser-oriented imagery and project-sharing workflows
            Supports fast communication through reports, presentations, newsletters, and social media
          

            External GIS formats
            Established import/export support for supported GIS formats
            Expanded imports, including KML/KMZ, GeoJSON, and shapefiles
            Reduces the effort required to bring public and client datasets into a usable geographic view
          

            Local data ownership
            Project files can remain under user control, although imagery services often require connectivity
            Different local and hosted workflows depending on feature and project type
            Relevant for client confidentiality, archival continuity, and control over independently collected observations
          

            Complex geographic projects
            Familiar workflows for large or layered local collections, subject to hardware and application limits
            Modern browser acceleration and improved import handling, with application-specific limits
            Existing collections must remain usable without excessive reconstruction or loss of functionality
          

            Collaboration
            Commonly relies on exchanged project files, shared storage, and independently hosted sources
            Built-in shared projects and cross-device access
            Modern collaboration is a genuine advantage, especially for distributed teams and public-facing work
          

            Custom geographic information sources
            Long-established use of KML files, network links, and supporting desktop workflows
            Growing connections to hosted information and Google-managed project services
            Allows small organizations to combine information from multiple institutions without commissioning custom software
          

            Distribution beyond GIS professionals
            KMZ files, network links, tours, screen captures, and recordings
            Shareable browser projects, links, and collaborative presentations
            Ensures geographic findings can reach the decision-makers and public audiences who actually need them
          

      
    

    Table 1. A workflow-oriented comparison of Google Earth Pro desktop and modern Google Earth experiences. Specific feature support and performance vary by version, platform, project configuration, and dataset.
  

The significance of these features becomes clearer when considered as parts of an entire workflow. A researcher might receive a collection of observations, organize them into geographic folders, connect outside information, examine historical imagery, create several viewpoints, and export a project that colleagues can inspect. The value lies not in any one feature but in how little infrastructure and preparation are necessary to move from an initial question to a shareable geographic result.

The desktop-to-web transition should therefore be evaluated by its ability to preserve this continuity. A browser application may provide better collaboration and accessibility while still requiring changes to long-established practices involving files, external data sources, or specialized features. Conversely, users should not assume that every workflow must remain tied to a desktop application merely because it originated there. The objective is not to freeze Google Earth in its original form, but to preserve the activities that made it useful while taking advantage of newer technologies.

The Importance of Communicating Geography to Everyone Else

A particularly important aspect of Google Earth's legacy is often overlooked in discussions focused on technical feature parity: the application made geographic information easy to communicate beyond the geospatial industry.

Google Earth users could create a virtual tour, capture a geographic viewpoint, record a flyover, publish a KML file, or share a link to a geographic location. These activities made spatial information understandable to audiences who did not need to know how the underlying data was collected, processed, or managed. The same geographic work could appear in a government briefing, television report, classroom presentation, community meeting, or online discussion.

This communication layer helped geographic information move across industries. A journalist, engineer, real-estate developer, emergency manager, military officer, educator, or local policymaker could understand a geographic argument without first learning how to operate the software used to prepare it. The interface became a common medium through which highly specialized information could reach people whose primary expertise lay elsewhere.

The ability to distribute geographic understanding was therefore at least as important as the ability to produce it. A platform that provides powerful analytical features but makes results difficult to communicate cannot fully reproduce the original Google Earth experience. Its value remains concentrated among people already comfortable with specialized geographic software.

The next generation should build on the simplicity of KML sharing, recorded tours, quick image captures, direct location links, and geographic presentations while extending those capabilities through modern browser applications, collaborative projects, embeddable viewers, and video-based storytelling. These are not superficial conveniences. They are essential mechanisms for transforming geographic analysis into information that others can understand and act upon.

The Significance of the 2027 Desktop Download Decision

On July 7, 2026, Google announced that Google Earth Pro desktop would no longer be available for new downloads beginning June 25, 2027. Google clarified that existing installations could continue to be used, meaning the announcement did not establish a universal shutdown of the software. Nevertheless, the change represents an important milestone because it restricts future access to an application around which many organizations developed long-standing geographic workflows.

The decision also follows earlier changes in Google's geospatial portfolio, including the transition of Google Earth Enterprise away from its former commercial product model and the release of components through an open-source project. These developments differ in their details, but they demonstrate the challenges organizations face when their geographic operations depend on products whose strategic direction remains under the control of a single vendor.

For users, continuity matters. A geographic project may need to remain accessible years after its creation, when the original analyst has moved to another organization, the supporting data service has changed, or the software used to construct it is no longer widely distributed. The ability to preserve geographic information through open formats and dependable workflows is therefore not merely a technical preference. It is part of maintaining institutional knowledge.

Google's continued development of Earth on the web and mobile devices may eventually provide satisfactory alternatives for many of these workflows. The open question is whether the broader ecosystem will preserve the same flexibility that allowed Google Earth to become useful in so many unexpected professional and public settings.

The answer increasingly depends not only on Google's product decisions, but on how a new generation of geospatial technologies approaches the relationship between sophisticated capabilities and practical accessibility.

The Search for a Successor: Rebuilding the Accessible Globe

The gradual shift in Google's approach to Earth has encouraged renewed attention toward alternative geographic visualization platforms. Yet the search for a successor is more complicated than identifying another application capable of displaying a three-dimensional globe. Google Earth's influence emerged from an unusual combination of accessibility, visual continuity, geographic information exchange, recognizable imagery, and straightforward communication. An application may exceed Google Earth's analytical capabilities or offer more advanced rendering technology while still failing to reproduce the experience that made the original so widely adopted.

This distinction is particularly important when evaluating professional GIS applications against products designed around geographic visualization. QGIS, for example, provides substantial analytical and data-management capabilities, supported by an extensive open-source ecosystem. Felt addresses a different problem by making collaborative map creation and sharing more accessible. Both are valuable, but neither should be considered a direct successor simply because they support geographic information. Their design priorities differ from those that made Google Earth a universal point of entry into geospatial exploration.

Esri's ArcGIS Earth is a closer functional alternative, particularly for organizations already operating within the ArcGIS environment. It provides a recognizable desktop globe, geographic data integration, and familiar tools for exploration and measurement. However, the broader market opportunity extends beyond recreating desktop visualization inside an established enterprise ecosystem.

More revealing are technologies attempting to combine modern globe rendering, flexible data processing, and accessibility across desktop and browser environments. Cesium, GeoLibre, and RustGIS approach this opportunity from different directions. Their capabilities demonstrate the extraordinary progress of contemporary geospatial software, while their differing architectures also reveal how difficult it remains to deliver a complete geographic workspace for users who are neither casual consumers nor full-time GIS engineers.

The Emerging Ecosystem

      
            Platform
            Primary role
            What it brings to the table
            What remains unresolved for the middle market
          
            CesiumJS
            Extensible 3D globe and visualization engine
            Global terrain, imagery, 3D Tiles, KML/GeoJSON support, dynamic objects, and advanced 3D applications
            Requires an accessible application and data-management workflow built around the engine
          
            GeoLibre
            Integrated, cross-platform geospatial workspace
            Browser/desktop applications, local processing, multiple renderers, broad data-source support, plugins, and analysis tools
            Must demonstrate sustained usability, reliability, and workflow coherence for general intermediate users
          
            RustGIS
            Open-source desktop/browser GIS with AI-assisted operations
            Native Rust architecture, geographic data handling, 3D globe, editing, analysis, cartography, CLI, and AI command interface
            Must show that its expanding toolset can remain approachable rather than reproducing complex GIS interface burdens
          
            ArcGIS Earth
            Established globe application within the Esri ecosystem
            Familiar geographic exploration, enterprise integration, KML support, measurements, and 3D information
            Closely tied to enterprise-oriented workflows and the broader Esri platform
          
            QGIS
            Complementary professional GIS environment
            Deep analysis, editing, extensive data interoperability, local processing, and plugins
            Its breadth and workflow complexity do not reproduce Google's consumer-oriented globe experience
          
            Felt
            Collaborative web mapping and geographic communication
            Accessible map design, shared editing, presentation, and team-oriented workflows
            Concentrates on collaborative mapping rather than the complete virtual globe experience
          
    Table 2. The emerging geospatial ecosystem includes globe-rendering technologies, integrated GIS applications, established enterprise tools, and collaborative mapping services. These platforms should not be understood as equivalent competitors.

The distinction between these platforms is not a simple ranking of technical sophistication. Cesium and the newer cross-platform applications are particularly relevant to the Google Earth succession story because they explore ways to preserve the combination of geographic visualization, external data integration, and accessible interaction. QGIS and Felt contribute important capabilities to the broader ecosystem, but their primary roles are complementary.

The question is whether these technologies can eventually converge into a platform that offers more than a collection of impressive features. The middle demographic needs a coherent experience in which users can investigate geographic questions, invoke sophisticated capabilities when necessary, and communicate results without assembling their own software infrastructure.

Cesium: The Virtual Globe Becomes an Open Building Block

Cesium occupies a particularly important place in the evolution of three-dimensional geospatial visualization. Its open-source CesiumJS engine supports interactive globe-based applications, geographic imagery, terrain, dynamic features, and complex three-dimensional datasets. The development of 3D Tiles further expanded the industry's ability to stream large collections of buildings, photogrammetry, point clouds, and other spatial information into detailed virtual environments.

These technologies have become increasingly relevant to digital twins, infrastructure visualization, simulation, defense applications, and other fields requiring more sophisticated geographic representations than traditional maps can provide. Cesium demonstrates how a high-performance virtual globe can serve as the foundation for an extensive range of commercial, government, and open-source applications.

The significance of Cesium in the Google Earth story is that the core globe experience no longer has to be delivered exclusively through a single consumer product. Organizations can develop their own applications, connect independent sources of imagery and geographic information, and create interfaces designed around particular industries or workflows. The underlying rendering technology becomes a reusable component rather than an inseparable part of one company's mapping service.

This is an important architectural evolution, particularly for organizations seeking more control over their geographic visualization infrastructure. A municipality can build an interactive urban environment, a defense contractor can develop a mission-specific viewer, and a research institution can create a geographic interface connected to its own information systems. Such applications can preserve the visual strengths of a globe while extending them through modern spatial data services.

Yet Cesium's flexibility also reveals the limitation of treating a rendering engine as a complete Google Earth replacement. CesiumJS provides the underlying technology but does not automatically deliver the entire user experience surrounding it. A developer may still need to integrate geographic data services, design an interface, implement project storage, establish sharing mechanisms, and maintain the application.

For a well-resourced organization, this flexibility can be liberating. For an independent analyst or small business that wants to open geographic information and begin working immediately, the requirement to assemble an application creates precisely the kind of barrier Google Earth originally removed.

Cesium therefore represents an essential part of the next generation, but not necessarily the complete answer. It provides much of the technical foundation needed to build sophisticated virtual globes. The opportunity lies in transforming that foundation into accessible applications that reduce the need for custom development while preserving the flexibility that makes the technology valuable.

GeoLibre: Reassembling the Accessible Geospatial Workspace

GeoLibre approaches the problem from a different direction by attempting to provide a more integrated geospatial application across browsers, desktop computers, mobile devices, and notebook environments. Developed within the opengeos community and associated with researcher Qiusheng Wu, the project brings together several modern geospatial technologies to support data exploration, visualization, processing, and interaction.

The platform's documented capabilities include support for multiple data formats and services, local geographic processing, analytical tools, and different rendering engines. Its use of technologies such as WebAssembly and client-side spatial processing allows certain operations to run directly on a user's device rather than always requiring a remote processing service. The inclusion of CesiumJS as a rendering option also demonstrates how the wider open-source ecosystem can combine specialized technologies inside a common workspace.

This approach is particularly relevant to the distinction between browser and desktop applications explored earlier. GeoLibre demonstrates that modern web software can support substantial local processing while a native desktop application can expose additional filesystem capabilities and other functions. The two environments need not be separate products with entirely different workflows, and the browser does not inherently require every dataset to be uploaded to a commercial cloud service.

GeoLibre's potential contribution to the middle market is its emphasis on making a broad collection of geographic capabilities available through an integrated application. Users can work with geographic layers, connect external data sources, perform analysis, and select the appropriate visualization environment without necessarily assembling all those components themselves.

Nevertheless, a comprehensive feature list does not guarantee that an application has solved the problem of accessibility. As a project expands to support more formats, analytical operations, rendering engines, and deployment options, its interface must remain understandable. The ability to perform sophisticated geoprocessing is valuable, but users also need to discover the appropriate operation, understand its purpose, evaluate the result, and communicate it without becoming overwhelmed by technical choices.

GeoLibre is therefore a promising example of how the original Google Earth philosophy might evolve, but it should not yet be treated as a demonstrated universal replacement. Its long-term importance will depend on how effectively it balances breadth of functionality, reliability, intuitive navigation, data stewardship, and the ability to move between simple and advanced geographic work.

RustGIS: Bringing Analytical Power and AI Into the Same Workspace

RustGIS adds another noteworthy direction to the search for an accessible geospatial environment. Built in Rust and designed to operate natively on major desktop operating systems as well as in a web browser, the project emphasizes geographic visualization, analysis, editing, cartography, and automation within a common application.

Its published capabilities include support for common geographic formats such as GeoJSON, CSV, shapefiles, GeoPackage, GeoParquet, GeoTIFF, and cloud-optimized imagery. It also describes tools for spatial analysis, feature editing, cartographic production, 3D globe visualization, and integration with additional geoprocessing capabilities. These features place RustGIS within the broader category of applications attempting to provide substantial geographic functionality without requiring users to build their own software environment.

Of particular relevance is its approach to artificial intelligence and automation. RustGIS describes an architecture in which application functions are accessible as commands that can be called through conventional interfaces, command-line workflows, or an AI assistant. Rather than treating AI as a separate visualization novelty, this approach makes it possible for an assistant to invoke actual application functions and perform operations on geographic data.

That distinction is important because one of the most promising uses of AI in geospatial technology is the simplification of complex workflows rather than the generation of convincing-looking maps. An AI assistant that can identify an appropriate operation, run it against geographic data, and allow the user to inspect and reverse the result could reduce the amount of technical preparation required for routine analytical tasks.

For example, a user might want to identify features within a certain distance of a transportation corridor, style locations according to a particular attribute, or prepare a map illustrating the geographic relationship between several datasets. These are established GIS operations, but executing them can require familiarity with particular software tools, menus, and analytical conventions. An effective AI interface could help translate the user's intent into a sequence of operations while retaining access to the underlying parameters and results.

RustGIS's command-oriented design suggests a potential bridge between conventional graphical software and more conversational interaction with geographic information. Advanced users could continue scripting or configuring complex processes directly, while others might access the same operations through guided workflows and natural-language requests.

The approach also raises important questions about transparency and control. An AI assistant should not simply perform geographic operations without explaining what data it used, which tools were called, what assumptions were made, and whether the result has been validated. Reversibility and inspectable commands are useful architectural features, but trustworthy geospatial analysis also requires source provenance, reproducibility, geographic accuracy, and appropriate handling of sensitive information.

As with GeoLibre, RustGIS's actual capabilities and usability should be distinguished from the ambitions described by its developers. The project is interesting because of its combination of modern implementation technology, native and browser accessibility, extensive geographic functionality, and AI-assisted commands. Whether that combination can become a cohesive experience for the broader middle market requires practical testing and sustained development.

Why None Has Yet Fully Captured the Missing Middle

The emergence of Cesium, GeoLibre, RustGIS, and other geospatial applications demonstrates that the technical ingredients for a new generation of geographic software are increasingly available. High-performance rendering, cloud-native data formats, local processing, modern application frameworks, and increasingly sophisticated AI systems provide possibilities that were largely unavailable when Google Earth first appeared.

Yet the central challenge remains unresolved. A system can be technically capable without being broadly accessible. It can offer hundreds of analytical operations while making it difficult for users to identify the few that matter to their question. It can present a remarkably detailed virtual globe while requiring significant software development to connect external information. It can automate complex workflows while providing inadequate explanations of how results were produced.

The missing-middle audience occupies precisely this difficult space. These users require more functionality than a conventional consumer mapping product but often have little justification for investing in the infrastructure and training associated with enterprise GIS. Their work may involve meaningful analysis, complex geographic observations, or professional decision-making, yet their immediate needs frequently remain straightforward: inspect a place, add information, compare datasets, perform a targeted operation, and communicate the result.

Providing that experience does not mean removing technical depth. It means exposing complexity progressively, allowing users to start with understandable operations while accessing increasingly sophisticated capabilities as needed. A user should be able to add a geographic dataset and begin exploring it without configuring an entire project environment. When advanced analysis is required, the application should provide an intelligible path toward it rather than forcing the user to navigate an unfamiliar collection of processing tools.

Google Earth's original advantage came from the fact that the underlying geographic technology could remain sophisticated while the interface remained immediately understandable. Recreating that balance, while incorporating modern analytical and collaborative capabilities, is the standard by which these successors should ultimately be evaluated.

Beyond the GIS Community: Why Distribution Matters as Much as Analysis

An accessible geospatial platform also needs to account for the audience receiving the final information. A substantial portion of geographic work is ultimately intended for people who will never operate the analytical software used to produce it. Government officials, emergency managers, journalists, business executives, students, community organizations, and members of the public may all need to understand a geographic finding without becoming GIS practitioners.

Google Earth was unusually effective at bridging this divide. Its tours, exported imagery, placemarks, KMZ files, network links, and recognizable visual environment made geographic information comparatively easy to distribute. A user could create a guided tour of an area, capture an image for a report, demonstrate a location during a meeting, or share a geographic file that others could explore independently.

This ability to communicate geographic information through familiar media gave Google Earth influence far beyond the geospatial industry. Its imagery and flyover experience became recognizable in journalism, documentary production, education, public presentations, and government briefings. Complex spatial relationships could be communicated visually without requiring an audience to understand the underlying coordinate systems, databases, or analytical methods.

The successor to Google Earth must therefore consider not only the person creating or analyzing geographic information but also the much larger audience that needs to consume it. Geographic intelligence becomes more valuable when it can move easily between professional analysis and common forms of communication.

Video tours, quick screenshots, shareable KML and KMZ projects, embeddable viewers, direct geographic links, interactive presentations, and simple publishing workflows should not be treated as secondary features. They are mechanisms through which geographic information becomes useful across industries.

Modern web technology creates opportunities to improve these workflows even further. Interactive maps can be embedded in reports, projects can be shared across devices, geographic presentations can combine imagery with other media, and lightweight viewers can allow audiences to explore results without installing specialized software. AI could assist with generating geographic narratives, selecting relevant viewpoints, organizing multimedia presentations, and translating technical findings into language appropriate for different audiences.

The objective should not be to replace analytical rigor with simplified storytelling. It should be to preserve the integrity of the underlying geographic information while making its meaning accessible to the people who need it.

The Emerging Formula for the Next Generation

The strongest successor may ultimately combine technologies and capabilities that currently exist across several different platforms. Cesium offers a sophisticated foundation for global 3D visualization. GeoLibre and RustGIS explore integrated geographic workspaces, modern processing techniques, and flexible deployment models. QGIS provides a mature open-source analytical ecosystem, while collaborative services such as Felt demonstrate how easily geographic projects can be shared and discussed. Google Earth and Earth Engine continue to provide extraordinary global visualization and analytical capabilities.

The missing achievement is the integration of these ideas into a coherent environment designed around the user rather than the technical architecture.

However, any effort to create that environment must begin with an important practical consideration: how people already work with data. The geospatial industry has developed increasingly sophisticated methods for storing, processing, and distributing geographic information, but much of the information entering those systems continues to originate in a far more familiar form.

The Spreadsheet: The Universal Language Geospatial Cannot Ignore

For all the advancements in geographic information technology, one of the most persistent realities of working with data is that the humble spreadsheet remains nearly unavoidable. Across government, defense, business, journalism, scientific research, and everyday organizational operations, information continues to be collected, maintained, and exchanged through Excel workbooks, Google Sheets, CSV files, and conventional data tables. These formats may lack the sophistication of spatial databases or cloud-native analytical systems, but their familiarity gives them an advantage that the geospatial industry frequently underestimates. They represent a common language of information that transcends professional specialties and software ecosystems.

Much of the world's geographic information begins as ordinary tabular data. A spreadsheet containing facility names, street addresses, geographic coordinates, infrastructure attributes, observation dates, or organizational records may hold substantial geographic intelligence even when its creator has never used GIS software. The challenge is turning those records into meaningful geographic information without forcing the user to abandon a familiar workflow. Google Earth was remarkably effective at the visualization side of that equation, while Fusion Tables briefly demonstrated how structured datasets could be managed, combined, and shared through a more approachable interface. Together, they suggested a model in which geographic analysis could emerge naturally from the same data-management practices already used throughout other industries.

The next generation of accessible geospatial software must go beyond simply accepting CSV files as an import format. Users need the ability to inspect, edit, clean, filter, join, reconcile, and update tabular records directly alongside their geographic representations. They should be able to correct coordinates, geocode addresses, manage attributes, combine datasets using common identifiers, and identify inconsistencies without repeatedly exporting information into separate spreadsheet or database applications. These operations should also remain practical at scale, allowing users to progress from a few dozen observations to hundreds of thousands or millions of records through appropriate processing infrastructure without requiring a complete change in working methods.

Artificial intelligence could make this integration particularly powerful. An analyst should be able to ask an application to identify duplicate facilities, standardize inconsistent attributes, join two tables by a shared identifier, flag questionable coordinates, or visualize changes between successive data releases. The system could translate these requests into transparent data operations while preserving the original records, documenting modifications, and allowing users to inspect or reverse the results. Such capabilities would not eliminate the need for structured databases or professional data engineering; they would provide a more accessible pathway into those capabilities for people whose expertise lies in understanding the information rather than managing the software.

This is why the disappearance of Fusion Tables remains relevant to the Google Earth story. Google had begun to bridge the gap between everyday data management and geographic visualization, but the resulting workflow was never fully developed into a durable, integrated environment. A modern successor should recognize that spreadsheet interoperability is not merely a convenience for importing legacy information. It is a fundamental requirement for connecting geospatial technology to the everyday data practices of the much larger world beyond GIS.

A Practical Framework for the Next Geospatial Workspace

The requirements for a successful successor extend across several interconnected capabilities. Some involve the underlying technology, while others concern the accessibility of the workflows built around it. Their importance is most apparent when considered from the perspective of users who need to complete geographic tasks efficiently without sacrificing the ability to inspect data, apply professional judgment, or communicate their findings.

      
            Requirement
            What the next generation should deliver
            Value to the middle-market user
          
            Immediate geographic access
            Familiar interactive globe, global imagery, terrain, geographic search, and intuitive navigation
            Begin exploring a location or answering a geographic question immediately, without extensive setup or training
          
            Flexible geographic inputs
            Native support for KML/KMZ, GeoJSON, shapefiles, GeoPackage, cloud-native imagery, APIs, network links, and external geographic services
            Easily combine information from multiple organizations, providers, and formats within one geographic workspace
          
            Spreadsheet and tabular integration
            Native Excel, Google Sheets, CSV, and structured table support, including bidirectional synchronization where available
            Continue working with familiar data formats across industries while making them geographically intelligent
          
            Accessible data editing and preparation
            Spreadsheet-like attribute editing, filtering, sorting, geocoding, joins, duplicate detection, coordinate corrections, validation, and bulk updates
            Clean, organize, and improve underlying information while immediately seeing its geographic representation change
          
            Scalable data management
            Seamless progression from small local spreadsheets to millions of records through spatial databases, cloud processing, and query engines, with transparent operations and preserved provenance
            Work with increasingly complex datasets without requiring every user to become a database administrator or developer
          
            Community-driven data discovery
            Searchable catalogs of geographic datasets, imagery, live feeds, and analytical resources, with metadata, licensing, provenance, coverage, and temporal filters
            Discover trustworthy information relevant to a question without hunting through disconnected repositories or writing API queries
          
            Accessible analytical tools
            Common geoprocessing functions exposed through guided workflows, intuitive controls, and natural-language assistance
            Perform meaningful geographic analysis without requiring advanced programming knowledge for routine operations
          
            Advanced analytical depth
            Optional access to scripting, spatial SQL, custom models, analytical parameters, scientific workflows, and reproducible processing
            Preserve professional rigor and allow users to increase analytical sophistication as their needs evolve
          
            Local and hosted processing
            Flexible execution on the user's device, organizational infrastructure, or cloud services according to data sensitivity, performance, and collaboration requirements
            Maintain control over sensitive information while accessing greater computational capacity when needed
          
            Project and data stewardship
            Organized workspaces, version histories, editable datasets, reusable collections, source tracking, permissions, and collaborative management
            Preserve geographic work as a durable organizational asset rather than an assortment of disconnected files
          
            Dynamic geographic visualization
            Interactive layers, 3D terrain, imagery overlays, temporal exploration, camera views, network-linked datasets, and responsive rendering
            Examine geographic relationships dynamically rather than relying on static maps or exported screenshots
          
            AI-assisted interaction
            Explainable natural-language commands for data discovery, table cleaning, joins, transformations, spatial analysis, visualization, and presentation
            Reduce time spent navigating software while maintaining analytical depth, transparency, and control over results
          
            Easy public distribution
            Video tours, snapshots, KML/KMZ sharing, direct project links, embedded viewers, interactive presentations, and straightforward publishing
            Communicate geographic discoveries to decision-makers, journalists, educators, businesses, and the wider public—not only GIS professionals
          
    Table 3. An editorial framework for the capabilities needed to serve the geospatial middle market. The requirements describe a proposed future environment rather than the current functionality of any single platform.

The defining opportunity is not to create another application with an ever-expanding collection of GIS functions. It is to connect the familiar ways people already work with data to the increasingly sophisticated capabilities available throughout the geospatial industry. Spreadsheets, CSV files, and ordinary data tables remain a common language across professions, while modern spatial databases, satellite imagery services, analytical engines, and AI systems provide capabilities that would have been extraordinary when Google Earth first appeared.

A successful next-generation platform should allow users to move naturally between those worlds, whether they are correcting a handful of facility coordinates, reconciling thousands of records, comparing historical imagery, or assembling a geographic presentation for a nontechnical audience. The objective is to make advanced geographic intelligence more accessible without stripping away the technical depth that makes it valuable. Google Earth established the importance of intuitive visualization; its successor must extend that principle to data management, analysis, collaboration, and distribution.

The technology needed to accomplish much of this already exists. What is missing is a sustained commitment to delivering it as an accessible, dependable, and coherent experience for the audience that Google Earth first demonstrated was waiting to be served.

The World Google Earth Could Still Help Build

The story of Google Earth ultimately reveals something more significant than the evolution of a single software application. It demonstrates how profoundly technology can influence an industry when sophisticated capabilities become accessible to people who were previously excluded by cost, complexity, or institutional requirements. Google Earth changed expectations not because it performed every geographic task better than professional GIS software, but because it made a substantial category of geographic work understandable and immediately useful.

That distinction remains relevant as the geospatial industry develops increasingly advanced analytical systems, cloud infrastructure, digital twins, and AI-assisted applications. The technological foundations are more sophisticated than those available in 2005, but the challenge of making those capabilities approachable has not disappeared. In some respects, the abundance of available data, services, formats, and processing options has created additional complexity for people whose primary objective is to understand a location or communicate a geographic finding.

My own experience integrating Google Earth into military intelligence workflows illustrates the practical significance of that challenge. Analysts did not always need another specialized application or a more elaborate production process. Sometimes they needed an intuitive way to examine imagery in context, combine information, and communicate an observation quickly. Google Earth allowed us to adapt existing technology around those needs, often without waiting for a contractor or formal software development effort to deliver a new capability.

The underlying lesson is not that professional systems are unnecessary. Sophisticated geospatial analysis, secure infrastructure, authoritative data management, and precision exploitation remain essential. The lesson is that their capabilities should be accessible through workflows proportionate to the question being asked. A system designed to solve the most demanding analytical problems should not make routine geographic exploration unnecessarily difficult.

Google deserves considerable credit for demonstrating that principle and for continuing to develop new ways to interact with geographic information. Modern browser and mobile experiences, collaborative projects, historical imagery, environmental datasets, and emerging AI capabilities represent meaningful advances. The transition away from new desktop downloads may create legitimate concerns about continuity, but it should not obscure the substantial progress made through modern web technologies.

The unfinished opportunity lies in bringing these advancements together with the other elements that made Google Earth so useful. The ability to maintain geographic information through ordinary tables, discover relevant datasets without extensive programming, connect independently maintained sources, perform straightforward analytical operations, and communicate results through familiar media should not require assembling a collection of disconnected applications.

Artificial intelligence makes this vision increasingly plausible. An intelligent geographic interface could help users find datasets, organize information, select appropriate analytical methods, perform routine operations, and communicate results without forcing them to learn every underlying technical process. The value would come not from removing analytical sophistication, but from exposing it through interactions that reflect the questions people naturally ask.

The spreadsheet provides an equally important reminder of what accessibility actually means. For all the industry's investment in cloud-native databases, spatial computing, and specialized analytical environments, ordinary tables remain a widely understood means of collecting and managing information. Connecting those familiar workflows directly to geographic visualization and analysis could expand the practical audience for geospatial technology far more than adding another collection of specialist functions.

The next generation must also preserve the extraordinary ability of geographic information to move beyond the profession that produces it. Google Earth's recognizable globe, interactive tours, shareable files, and quick visual exports helped make geography understandable across education, government, journalism, defense, business, and public life. These capabilities were central to the platform's influence because they made geographic understanding accessible to people whose expertise lay elsewhere.

There is no certainty that Google will deliver the next complete version of this experience, nor that any emerging open-source project will become its definitive successor. Cesium, GeoLibre, RustGIS, and other technologies demonstrate different parts of the opportunity, but their long-term success will depend on how effectively they translate technical capabilities into useful experiences for ordinary and intermediate users.

The opportunity is ultimately larger than replacing Google Earth Pro or recreating a familiar interface. It is to establish a geographic workspace in which people can discover relevant information, interact with it dynamically, perform meaningful analysis, maintain their data, and distribute what they learn without unnecessary technical barriers. Such a system would extend the original ambition of Google Earth into an era defined by increasingly abundant geographic data and increasingly sophisticated computational tools.

Google Earth taught millions of people how to explore the planet. Its most enduring contribution may be the demonstration that the complexity of the technology behind geographic intelligence does not have to become the complexity experienced by the person using it. The next great advance will come from preserving that accessibility while extending it to the data management, analytical depth, collaboration, and communication capabilities that the original platform only began to make possible.

The future of geospatial technology should not require people to choose between intuitive tools and sophisticated intelligence. Google Earth showed the industry what happens when that distinction begins to disappear. The task now is to finish building the environment that its success made imaginable.

1. Acacia Magazine. (n.d.). The sky as witness. https://www.acaciamag.com/issue-05/the-sky-as-witness
2. Central Intelligence Agency. (n.d.). Important CIA contributions to modern technology over the last 75 years. https://www.cia.gov/stories/story/cia-contributions-to-modern-technology-75-years/
3. Cesium. (n.d.). CesiumJS: Open-source JavaScript library for 3D geospatial visualization. https://cesium.com/platform/cesiumjs/
4. Encyclopaedia Britannica. (n.d.). Google Earth. https://www.britannica.com/topic/Google-Earth
5. Esri. (n.d.). Esri unveils ArcGIS Earth to the world. https://www.esri.com/about/newsroom/announcements/esri-unveils-arcgis-earth-to-the-world
6. Geoawesome. (2017). Google Earth Enterprise is now open source. https://geoawesome.com/google-earth-enterprise-now-open-source/
7. Geography Realm. (n.d.). A look at KML, an open standard to represent and visualize spatial information. https://www.geographyrealm.com/look-kml-open-standard-represent-visualize-spatial-information/
8. Google. (2018, December). Google Fusion Tables to be shut down on December 3, 2019. Google Workspace Updates. https://workspaceupdates.googleblog.com/2018/12/google-fusion-tables-to-be-shut-down-on.html
9. Google. (2026, July 7). Update on Google Earth Pro desktop app downloads. Google Earth Community. https://support.google.com/earth/thread/448773864?hl=en
10. Google for Developers. (n.d.). Earth Engine Apps. https://developers.google.com/earth-engine/guides/apps
11. Google for Developers. (n.d.). Earth Engine Code Editor. https://developers.google.com/earth-engine/guides/playground
12. Google for Developers. (n.d.). Earth Engine data catalog. https://developers.google.com/earth-engine/datasets/catalog/
13. Google for Developers. (n.d.). Get started with Google Earth Engine. https://developers.google.com/earth-engine/guides/getstarted
14. Google for Developers. (n.d.). Google Earth Engine: A planetary-scale platform for Earth science data and analysis. https://developers.google.com/earth-engine/
15. Google for Developers. (n.d.). JavaScript quickstart. https://developers.google.com/earth-engine/guides/quickstart_javascript
16. Library of Congress. (n.d.). KML, version 2.2. Sustainability of Digital Formats. https://www.loc.gov/preservation/digital/formats/fdd/fdd000340.shtml
17. Natural Resources Canada. (n.d.). Keyhole Markup Language (KML). https://natural-resources.canada.ca/science-data/data-analysis/geospatial-data-tools-services/keyhole-markup-language-kml
18. Open Geospatial Consortium. (n.d.). Keyhole Markup Language (KML). https://www.ogc.org/standards/kml/
19. OpenGeos. (n.d.). GeoLibre: A lightweight, cloud-native GIS platform [Computer software]. GitHub. https://github.com/opengeos/GeoLibre
20. OpenGeos. (n.d.). RustGIS: A fast, free and open-source GIS in pure Rust [Computer software]. GitHub. https://github.com/opengeos/RustGIS
21. RustGIS. (n.d.). RustGIS: Open-source geographic information system. https://rustgis.app/
22. The Guardian. (2018, December 20). Google's Earth: How the tech giant is helping the state spy on us. https://www.theguardian.com/news/2018/dec/20/googles-earth-how-the-tech-giant-is-helping-the-state-spy-on-us
23. Trajectory Magazine. (n.d.). The genesis of Google Earth. Medium. https://medium.com/trajectory-magazine/the-genesis-of-google-earth-7357204ecfb5
24. Transnational Institute. (n.d.). Militarising big tech. https://www.tni.org/en/article/militarising-big-tech

Google EarthCommercial ImageryImagery AnalysisElectronic Light TableDigital TwinsGoogleVirtual GlobeGlobeGIS SoftwareGIS Tools

Adam Simmons

Geospatial Industry Consultant | Founder, Project Geospatial

Adam Simmons is a geospatial technology liaison and strategic advisor with over 20 years of experience across the defense and commercial sectors. A veteran of the U.S. Air Force, he specialized in imagery analysis and order of battle before transitioning to executive leadership as the CEO of Midgard Raven, LLC and the founder of Project Geospatial, a 501(c)(3) dedicated to highlighting innovation within the geospatial ecosystem. Adam bridges the gap between technical development and market storytelling, leveraging his extensive background as a journalist and industry consultant to help companies navigate complex technology landscapes.

https://www.linkedin.com/in/adamsimmonsgeo