Data Catalog & Data Usage

One of the benefits in using EE is the marriage between the data source and the analysis software. Unlike the traditional desktop software model, EE allows the user to focus on the analysis and not on acquiring data since the data has been precomputed by Google for use on EE platform. A quick search of “Night lights” will immediately show data from NOAA’s DMSP. Moreover, some data have been further computed for basic information. For example, a quick search on “Landsat” will provide composites (8 days, 32 days, etc.), indices (NDVI, NDSI, EVI, etc.). It is additionally useful that EE combines several temporal data into one set–that is, a search for “Landsat 8 NDWI” will allow the user to scrub through all available years that data is available for.

However, although EE makes a venerable attempt to simplify the process of acquiring data, there are quirks that make the process limiting. For example, some data sets are searchable through the data catalog, but at the same time cannot be added to the workspace (e.g. Landsat Global Land Survey 1975). It is unclear why this is, and there is no way to filter results. Moreover, while it’s good that EE combines temporal data together, its lack of filtering makes finding the right set difficult. For example: there is no way to only look for data between a date range, which must be possible since EE does know which years as available.

Uploading Imagery

One of biggest problems encountered while using EE was attempting to upload our own imagery. In contrast to other platforms EE is largely designed to be stand alone. Adding an image is extremely cumbersome, and the current documentation can be misleading. For instance you might find contradictory information in the google tutorials about uploading images, as stated, “You may wonder about uploading your own imagery to Google Earth Engine for analysis.  This feature is not yet completed, but we plan to offer the ability to upload and analyze your own imagery in the future [2].” However, if one takes a deeper look they will find that you can infact upload external imagery, with a few caveats.

Primarily, you are required to upload the imagery into Google Maps Engine, another google platform, not into EE directly (Step 1). Second, you can only upload one image at time, resulting in a very tedious process if you want to examine multiple bands in a given satellite. Once the image has uploaded into Maps Engine you have to process the image, which can take quite some time (Step 1.5). After the image is processed you can can obtain an access link, where you copy the the EE ID (Step 2), and paste it into the search bar of your EE workspace (Step 3). In theory this should prompt the “Custom Assets” option as captured in step 3. In our experience this has only worked intermittently. Assuming it has worked, you may then manipulate the image you have uploaded.

The pictures below below demonstrates the process of uploading a satellite image into Maps Engine, where it is processed and then available to search In EE.

Step 1
Step 1.5 (Wait for processing)
Step 2- Copy Access Link
Step 3- Paste Access Link in EE Workspace
Step 4- Finally the image in EE!


Beyond the issues encountered with uploading imagery, were classification discrepancies. This becomes problematic since, as shown previously in the results, some data sources are not available. Somehow google has managed to thwart their search functionality within the EE workspace either intentionally or unintentionally. Moreover, real time/continuous data, such as NOAA’s GOES, is unavailable for quick retrieval. Thus EE is largely limited by what the team deems to be important; although they provide a ton of data already, and is often convenient, processing is ultimately limited due to the inextensibility of the platform.

Additionally, unlike most data repository for remote sensing, it is not possible to search availability by region of interest. It is to note, that the availability of data may be a result of the platform’s centralized computation paradigm–that is, since EE stores all its data on Google’s servers than the individual users, it may be prohibitive to have a copy of all possible data.

Another data source that we wished EE would have employed is NASA and USGS’ Web-enabled landsat Data projects (WELD), which provides preprocessed Landsat data which has spectral calibration coefficients, solar information, reflectance, brightness and temperature, as well as temporal alignment is another example of data we wished. [7] Such data set would fit perfectly into EE since EE deals with similar data. Utilization of this resource may provide boonful to researchers, having access to quicker data updates, as well as EE developers themselves since they no longer need to do the processing.

It is interesting to compare EE with other remote sensing analysis solution which encourages integration of other platforms. As mentioned before, Exelis’ Service Engine prides itself in its ability to integrate different platforms. In fact, it provides no data of its own and depends on the user contributing the data into its repository. Even better, with Jagwire, users are able to upload data live, on site. Moreover, Service Engine’s capability to connect via OGC and ESRI rest specifications, allows Service Engine to be used as part of a greater workflow.

It is possible, however, that such capability highlights the fundamental difference between EE and other remote sensing softwares. Whereas Service Engine seems to be focused on on-demand analysis, e.g. UAV and military application, EE is aimed for large data crunching for research, which precludes time insensitivity, e.g. Forest deforestation, Global roadless Areas, etc..

It behooves the writer to note some issues that may have compromise the data catalog summary and capability. Although we did our best to find data, EE’s search platform is limited to some degree. Although VIIRS data may not seem to be available if we search “VIIRS,” it may be possible that it has been combined with another data set. We hope that the EE team provides a solution and a more robust search solution that searches more than the title, but includes the meta-data. To note: EE demonstrates how to calculate Tree Height via LIDAR data. Despite this, searching for “LIDAR” in the data catalog will provide nothing. Looking at the programming layer for this demonstration, we noticed a data set named “Simard_Pinto_3DGlobalVeg_JGR”. Searching for this,results in nothing as well [8].

EE Workspace and Remote Sensing Analysis


Currently EE provides several preprocessing of images such as simple indices (see results). Given that EE seems to attempt to provide public access to remote sensing analysis (e.g. the examples), it may be beneficial to provide additional algorithms to demonstrate the power of the platform to those new to the field or EE. We propose some general algorithm that has been demonstrated in the field as starting points. Since EE already has the ability to change band combination, it may be useful to create presets that can highlight different water bodies, soil, vegetation, man-made materials, and snow and ice as per common band combinations such as the one given by Portland State University. In addition, other classification system can be integrated beside band combination, such as the Maximum Likelihood classification [9]. Another great example of analysis that Google can develop based on existing academic research is Whale Counting [9] [10] and building types [11]. Additionally, it may be interesting to compare Service Engine’s default preprocessing: find white planes, find red roofs, line of sight, and relative water depth, and look for avenues of possible improvements.

Continual computation

One of the biggest selling point for EE is its computation capability. Recent advancement in remote sensing has allowed near real time imagery of the earth through different sensors. “Today, commercial Earth observation satellites collect more than 4 million square kilometers of imagery daily, totaling petabytes every year “  [12]. Given that these data are public, EE should allow for utilization of these continuous data feed, allowing near real time algorithmic analysis at the global level. Example data feed could be NOAA satellites: Suomi NPP (VIIRS) for weather, climate, ocean dynamic, volcanic eruption, forest fire, and global vegetation analysis, GOES for severe weather, storm and hurricane warning, DMSP for snow and ice cover, climate change and sea-level rise, cloud type, ocean surface temperatures and currents, Jason-2 for oceanic depth and temperature, and DSCOVR for sun-lit face of the earth  (not yet launched) (NOAA). Such capability will be novel and could be groundbreaking for the industry at large.

Change detection

EE currently has some advanced methods dealing with time series data such as trend analysis (using covariate), and cross correlation analysis (resulting in delta x, y and euclidean distance difference [8]. We suggest that a basic change detection tool in the GUI can improve user experience. Their documentation currently suggests that change detection can be done by toggling layer visibility. Although layer capabilities is novel and other remote sensing application should look to this feature, such feature is not a replacement for change detection in comparing raster values. A simple implementation of a tool that takes in two maps from the data catalog and outputs a new map that calculate the difference in each pixel value may prove to be boonful to newcomers and the general public not used to remote sensing analysis. Such tool would take advantage of the fact that EE already groups common data sets as well as aligning them together.


Currently EE allows user to perform statistical analysis through their programming layer, such as covariance, standard deviation, min, max and so forth. However, such a tool is absent from the GUI layer, limiting its capability. It may be important to view data generated from EE in another format, such as a graph. For example, in Exelis’ ENVI, users may use a tool called “cursor location/values” which provide a graph of how values change within a map [9]. such graphical tool may provide information to the user.


One of the primary benefit of cloud computing is that computation is offloaded from the user’s device and thus a thin client can be used for access. EE should exploit this capability, allowing users to remote analysis in rural areas via mobile devices. Service Engine’s main feature points to its ability to be accessible on the ground to provide real time information [5]. Since EE runs on the expansive Google network, EE should have no problem in creating a thin client version of EE. In doing so, EE will once again push the field by giving information to those traditionally without access to remote sensing, a goal which they seem to aim for and people applaud for in Global Forest Fire.

3D capability and Topography

Although EE can calculate elevation related operations, such as hillshadow and hillshade, it currently only has one way to view the data–top down. The capability of viewing data within the three-dimensional scope is absent from the current EE GUI.  For example: this function is referred to as “3D SurfaceView function” within the Exelis ENVI Classic software user interface. Furthermore, although EE has the ability to employ layers, because there is no 3D function within it, it is impossible to view two layers simultaneously beside color layering. For example, when using the DEM, the user can not overlay data on top of it without obscuring DEM.

ASTER DEM ( ASTGDEMV2_0N37W123) + Landsat 5
(LT50440342011117PAC01) using ENVI’s 3D surface view.

Survey of Google Earth Engine for academia and in comparison with existing platforms and publicly available data.