THE INSIDE STORY: Google Earth Enterprise Goes Open Source

BY MATTEO LUCCIO / CONTRIBUTOR / PALE BLUE DOT LLC

WWW.PALEBLUEDOTLLC.COM

On March 20, 2015, Google deprecated Google Earth Enterprise (GEE), which had contributed greatly to the market for geospatial “Digital Earth” products for large organizations, and announced that it would stop supporting it on March 22, 2017. The company had previously announced that it would discontinue support for the Google Earth API and the Google Maps Engine, while it continued to support and promote Google Earth Engine. GEE allows organizations to store and process terabytes of imagery, terrain, and vector data on their own servers, and publish maps securely for their users to view using Google Earth desktop or mobile apps, or through their own applications using the Google Maps API.

Some thought that GEE would quickly fade away after Google stopped supporting it and its users would switch to alternative platforms that are already on the market, or build new ones. However, GEE had become essential for many of its users, including U.S. and foreign military and intelligence agencies, which did not see many viable alternatives, given their investments into the product, and the amount of work it would take to make the change. Therefore, at the beginning of 2017, Google began to prepare to open source GEE and to turn over maintenance and support of the product to three of its partner companies: NT Concepts, Thermopylae Sciences + Technology, and Navagis. See www.opengee.org.

On March 23, Google published to a GitHub repository, under the Apache 2 license, three independent components within the Earth Enterprise baseline, for a total of 470,000 lines of code:

Google did not open source its GEE client, which enables users to consume the globe data in 3D, its Google Maps JavaScript API V3, which enables them to do so in 2D, nor its Google Earth API.

I discussed this decision and the process of open sourcing GEE with:

FIGURE 1.
Google Earth Enterprise architecture, provided by Google

“There’s a tremendous user community around Google Earth and GEE, and Google wanted to make sure that those users had the opportunity to continue using the capabilities with which they were familiar and that they really liked to use,” says Clark. “Google also saw an opportunity to put its investment in cloud offerings to good use and open up the door for some of its imagery.”

“I think it’s an interesting move,” says Batty. “There is a strong trend towards open source software being very capable in the geospatial space. We’ve built these very large industrial-strength implementations really using all open source software as a base, so I think this is another interesting example of a tool in the open source space that people can use.” He also thinks that GEE has some competition, as we have been sharing in the series in this publication for the past two years. He cites Cesium as an example of a product with a lot of comparable functionality, such as the fact that it can run in a browser and is very customizable. “I’ve seen people doing some quite interesting things with that. So I think it will be interesting to see how much traction it gets. We definitely have a trend toward a wide range of capabilities available in the open source arena.”

THE DECISION TO DEPRECATE GEE

For about seven years, Bhatnagar has been supporting both the Maps API and Google Earth, specifically GEE. Part of his core job is to support Google’s enterprise customers in implementing those products. Around 2014, he recalls, Google’s leadership decided that the company should focus more on delivering rich location content via its APIs, while also enabling its customers to take full advantage of the Google Cloud platform.

“GEE has always been a very niche product, focused on a very important user base, but percentage-wise, a very small one,” says Bhatnagar. GEE’s adoption rate was much, much lower than what Google likes to see for its products. “So, they looked at this core business and decided that it was time to deprecate it.”

Bhatnagar proposed open sourcing GEE. Initially, there were some internal concerns about how this might affect patents and benefit competitors. However, he says, the more the product teams, engineers, and everyone else involved discussed the proposal, the more they thought that it was the right thing to do for Google’s customers.

FIGURE 2.
Data overlaid on Google Earth displayed in 3D in iSpatial shows comparative crime rates across Mexico for the U.S. Southern Command, courtesy of Thermopylae Sciences & Technology

In particular, Google recognized that GEE’s customers were not its ordinary customers. “We are talking about the three-letter agencies within the U.S. government, as well as the Japanese Ministry of Defense, the Israeli Prime Minister’s office, the British GCHQ, and so on,” says Bhatnagar. “It’s almost an invisible user base.

Most of the time, we have full visibility of who is using our products, because they reach out to Google, so we can collect all kinds of data and logs and we know who is doing what, but with GEE we never had a good finger on how big our user base was. Hearing from our partners, it is a lot bigger than we ever expected it to be.”

This recognition strengthened the argument to open source GEE. So, after final approval from Jen Fitzpatrick, Google’s VP for Product & Engineering, the company began the open sourcing process. “We went through the code, sanitizing it, cleaning things up, repackaging, taking out any Google dependencies and things like that,” Bhatnagar explains. “We looped our partners into this process and they have been instrumental in helping us clean up the code and prepare it for open source release. Meanwhile, our engineers were able to continue to focus on certain bugs that needed to be fixed first.” In late March, Google released version 5.1.3 of GEE, its final version.

FIGURE 3.
Emergency response and evacuation in Washington, D.C., modeled over Google Earth in iSpatial, where zones, geofences, and routes can be merged with live incident data for staging, planning, or live operations

THE PARTNERS BECOME CUSTODIANS

NT Concepts was Google’s first partner focusing on geospatial solutions, starting in 2006, says Powell. “We have a long history of helping Google install and set up GEE in more than 100 customer locations around the world.”

NT Concepts will be one of GEE’s custodians, Powell explains, helping to manage the GitHub repository. “We’ll be responsible for helping to contribute updates as people provide them to the GitHub repository and make open source improvements along with the work that we’re doing. We’ll be one of the groups helping to monitor that and then promote those new capabilities into the software baseline.”

Google will probably stay peripherally involved and support some of the client end pieces, but it will not actively manage this process nor support the back-end server pieces, according to Powell. Large enterprise customers, in the public and private sectors, will be able to adopt the open source baseline. To make any enhancements to the GEE baseline, these users will have to download the software code and work either internally or through a firm like NT Concepts, Powell explains. “We have engineers that Google trained over the last month on the software baseline, so we have a very good understanding of what the software does. But they will have to compile that against whatever operating system that is supported in their organization—such as Ubuntu or Red Hat Enterprise Linux—that would also be compliant with the Google Earth products.”

The GitHub repository, he points out, will not have an installable version of the software available for download. It will, however, contain the source code that would allow users to download it, compile it against their operating system, and then create an executable version of the software that they could then install.

TST initially reached out to Google shortly after it started, in 2007, recalls Clark. “We were trying to bring in more capability for U.S. embassies. Our organization had a lot of spatial engineers and other software developers, so, over time, we were able to extend on top of the GEE capability with a few products. We were also able to start providing some engineering input to Google teams as they looked to evolve GEE. Eventually, it just became a very close relationship. When GEE was set for deprecation, we decided to continue to support customers that had it.” TST invested in keeping an engineering team dedicated to Google’s mapping products and began to do a lot of work around the Maps API for its private sector customers.

FIGURE 4.
TST’s graphic showing how GEE is portable, and available offline

FIGURE 5.
TST’s iSpatial showing a heat map of customer density in the San Francisco Bay area, where data can be toggled from points to heat map to clusters at the click of a button

Because GEE has been in deprecation for two years, Clark points out, it requires a lot of feature enhancements, maintenance, bug fixes, and security updates. “We want to ensure that the open source community knows that there’s an entire product team on our end that’s going to be handling support for a lot of day-to-day kind of things,” he says. “Once this gets out there, there’s going to be a lot of participation from the open source community, but I think it’s going to take some time and some commitment to fully get them engaged.”

“I have been involved with GEE since the beginning,” says Moore. “I used to work for the U.S. Army Corps of Engineers and that is how I initially got involved. We ended up purchasing one of the largest instances of GEE. We had more than 900TB of imagery, serving up all of the Army. After that, I started Navagis with the sole purpose of supporting and helping out with GEE. Google contacted us, as well as NT Concepts and Thermopylae, to help with the open sourcing process. We were able to place one of our staff full-time at Google to help with it, doing some of the programming and cleaning up the code and other things like that.”

“We have a lot of GEE expertise,” Moore adds, “from over the last ten years. We hope to give that to the community, continue building, continue the momentum of GEE, and help modernize it to GIS standards, so that it can continue to be relevant. We are working hand-in-hand with NT Concepts and Thermopylae so that, once it is out there, hopefully it will be used and continue to be useful.” The greatest challenge in open sourcing GEE was making sure that nothing proprietary was left in the code, he added.

“One of the great things… is that it can handle very large datasets, including 3D terrain and 3D globes. We want to extend that, so that we are able to handle very large 3D models as well, such as data coming from self-driving cars, UAVs, and LiDAR. We want to keep extending it so that it works on every device out there, such as mobile devices, and in the cloud.”

–DAVID MOORE

THE FUTURE OF GEE, ACCORDING TO GOOGLE

Going forward, Google will have “very little” relationship with GEE, says Bhatnagar. “Part of the understanding for this open sourcing was that we really want the partners and the community as a whole to take the reins on this effort,” he says. “Our engineers may continue to review code changes and merges and that kind of thing, more as a side project, but Google is definitely not committing any resources to maintaining GEE.” This, he points out, is unlike other Google projects, such as TensorFlow, Android, and Chromium, which the company still very much supports and maintains.

The GEE client “will definitely remain in use for quite some time,” says Bhatnagar. “From what I’ve heard from our users and the partners, people love the GEE client.” Google’s client team will continue to maintain it. “I can’t say for exactly how long, but it is not going away any time soon.” The GEE client, he explains, is 99 percent the same as the Google Earth Pro client. “The key difference is that when you launch the GEE client, you get a dialog box asking you for the URL of the Earth server to which you want to connect.” In the future, whenever Google releases a new version of Google Earth Pro, it will also release a new version of the GEE client.

FIGURE 6.
InciWeb showing fire instances in the U.S., uses GEE to deliver scalable, on-demand solutions leveraging cloud-based infrastructures, mobile support, and of ine/air gapped mapping for a complete operational picture. Courtesy of NT Concepts.

By contrast, Bhatnagar hopes that users migrate away from the Google Maps API toward something like Leaflet, an open source implementation. The Maps API, he explains, will remain closed. The version bundled with GEE “is a rather crippled version of the Maps API, because it never reaches out to Google.com, so you don’t get the geocoder or the street view or directions API, things that rely on Google backend services.” So, Google plans to maintain it for perhaps a year or so. “After that, either customers switch to Leaflet or, if they really want the Maps API, they can load the JavaScript libraries from Google.com, just like all the other developers do.”

“One of the great things that GEE does that many other products don’t do,” says Moore, “is that it can handle very large datasets, including 3D datasets. It can handle 3D terrain and 3D globes. We want to extend that, so that we are able to handle, say, very large 3D models as well, such as data coming from self-driving cars, UAVs, and LiDAR. We want to keep extending it so that it works on every device out there, such as mobile devices. We also want to extend it so that it will work in the cloud.”

Open sourcing, Clark says, will provide an opportunity to start bringing into GEE many new features that users have requested over the last three to five years. He thinks the product will benefit many industrial users, such as utilities. “Anybody who goes offline or needs some kind of imagery, terrain, maps, or content solution that works directly with the Google Earth client is now going to have that option. That’s really big when you’re talking about that client because of the billion downloads over the years. There is such a tremendous number of regular users who depend on Google Earth to do things in their day-to-day work. Ultimately, this opens up the opportunity for them to take something light and portable, add some imagery, add some terrain, and maybe weave it into their business operations.”

“This is something that I have been hoping would happen for a long time now and I am very happy that Google’s done it,” Moore adds. “GEE has been critical to the success of our company, so I am really happy that we are able to continue using it, extend it, and use it for our customers.”

CONCLUSION

“We are really hoping that customers and users continue to evolve GEE in ways that we never expected,” says Bhatnagar. “It was developed almost ten years ago and so much has changed since then that we love to see it going in new directions, such as being scaled to much larger grids, especially if they are in the cloud—preferably, of course, Google’s cloud—to increase its processing potential. Now that it is open source, there are so many opportunities!

The open sourcing of GEE “will greatly change things,” Powell predicts, “because there are many features that have been desired and requested by users over time that now organizations will be able to incorporate into their own work flows and tool sets. They’ll be able to create robust portable solutions that will allow them to take data and use it on a mobile device that doesn’t connect to the Internet.” The decision affects many users, companies and organizations in positive ways. Users now have many choices for managing and analyzing geospatial data, including the open source version of GEE, all the products that we have profiled in the last two years in our series about the deprecation of GEE, and many more, as well.

FIGURE 7.
Current and former Google staff and partners who contributed to GEE over the past decade and who helped to open- source it, at a farewell party in late March 2017. From left to right: Kevin Guerra, Asmita Wankhede, David Moore, AJ Clark, Preston McAllister, Mark Wheeler, Jordon Mears, Avnish Bhatnagar, Bret Peterson, Datta Maddikunta, Andrei Selikhanovich, and Mark Aubin.