The first lab in the GEE Fundamentals textbook introduces the reader to the interface and fundamental language parameters for conducting cloud-computing within the Google Earth Engine interface. Explicitly, the reader in this chapter is introduced to the different tabs and sections of the i) application programming interface (API) (e.g., code editor and the script manager panel), and ii) the definition and use of different syntax (e.g., JavaScript in code editor, and the possibility of using other coding languages (Python linked using Google Collab)). Moreover, the user is exposed to iii) the specific variables, data structures and functions that can be run using JavaScript syntax in the code editor pane.
In this exercise we learned several elements of writing code in the JavaScript syntax, and how to save files to the script manager within the GEE API. First, login to the GEE interface using a registered and approved Google Account. Find and select into the code editor panel in the GEE API (Top-middle on default configuration) and begin typing the line of code:
print('Hello World');
In this example, the "print" line indicates the API command to call from the GEE API, as located within the script manager pane (top-left). The brackets are used to delineate the argument clauses of the specific API being called. Within the script manager tab, a detailed list and explanation is given for the specific clauses of each argument being called; in this instance, the "print()" function will print whatever variable and/or phrase to the console (top-right). Phrases and argument clauses are separated using apostrophes on either end of the phrase. Terms can be separated using quotation marks as well, however the author notes how it is in "good form" to be consistent with apostrophes.
Moreover, the semi-colons are used to delineate functional lines of code within the code editor in JavaScript syntax. While mandatory for coding in most cases of JavaScript, selecting run in the code editor without the semicolons will call the function regardless. After running this script in the code editor the following message "Hello World" was printed to my console.
Figure 1: How the Print API uses syntax in the code editor to print text into the console
Then I saved the file to my scripts folder by clicking the "save button" above the code editor within the GEE API. For this course, I created a separate repository for all course materials in advance; however, if it is a users' first time with the program it will prompt them to do so.
In Exercise 2, the objective was to learn about different data types within the GEE API. These include i) variables, ii) lists, iii) objects and iv) functions. I learned variables are used to store data values, and these can range from single entries to itemized and nesting lists of corresponding information (e.g., the band information in different LANDSAT 8 image collections). The example we coded was to import the variable name city, and attach the data value of San Francisco.
var city = 'San Francisco';
When using the earlier print function, printing the variable city printed "San Francisco" to the console (right side of the screen). We then learned how lists can be attached to variables to give them several data points; in this case, these were different metropolitan areas in the Continental United States. Different data points were separated using commas, and I learned how a square bracket is used to delineate the fact there are multiple values, as opposed to singular.
var cities = ['San Francisco', 'Los Angeles', 'New York', 'Atlanta'];
print(cities);
I then learned how objects act as a container variable for multiple different values. Moreover, the variable object features were contained using curly brackets; similarly to square brackets, these were used to contain multiple different clauses or terms within a single line of code.
var cityData = {
'city': 'San Francisco',
'population': 873965,
'coordinates': [-122.4194, 37.7749]
};
print(cityData);
I then learned how functions are used to carry out user-imputed calculations, as opposed to strictly following the terms of a specific API that you can find in the script manager, under the "DOCS" tab for different API. This is not to say they are exclusive: within a user-specified function, and individual may call an API, such as done within the line of code below.
var greet = function(name) {
return 'Hello ' + name;
};
print(greet('World'));
print(greet('Readers'));
We also learned how putting double forward slashes before a line of code, or in front of a sentence turns the syntax into a commenting mode, allowing for it to be skipped when the console editor is run (i.e., //).
Figure 2. The Code Editor and The Console panes that correspond to creating a variable, list, object, and a function in the GEE API.
In this Section we learned how to call different methods from the Script Manager. In this example we begin by assigning numerical values to alphabetical variables. Storing values associated to each variable, we used the ee.Number function and the add(right) function to add the variables together. In this case, a new variable had to be created to store the result of the function.
var result = ee.Number(a).add(b)
print(result);
Subsequently, we learned the ee.List.sequence() function. This function generates a list variable with numbers ranging from a beginning and end interval, as generated by argument clauses of either a count (number of list items) or a step value (specified increment). In this section we learned about optional model parameters, which differentiate themselves from mandatory argumentation clauses in function calls in that they can be used or omitted, contingent on the context of application.
var yearList = ee.List.sequence(1980, 2020, 5)
print(yearList
As a knowledge synthesis step we then combined two variable names together using the concatenate feature, cat(). The following formula looks like this:
var result = ee.String(mission).cat(satellite)
print(result);
In this lab we learned about how to parse images to inspect, download, and visualize data in individual bands; within remote sensing, images are both visually altered and investigated through manipulation and accentuation of the data across bands. In this lab we also explored the elements of the electromagnetic spectrum as it is pertinent to the sensing of the earth's surface differentially across bands.
Within this section we used the code editor to call upon image collections stored within Google Dataset. While this is done in the code editor panel using a call function, ee.Image, we learned this can also be done through searching for the image collection directly in the search bar above the code editor pane.
var first_image = ee.Image('LANDSAT/LT05/C02/T1_L2/LT05_118038_20000606');
We then learned how when printing an image collection to the console, that we can visualize the metadata stored within lists, and binned by the object (i.e., the image collection downloaded). To the earlier point, we learned the colour ranges within the electromagnetic spectrum that the LANDSAT 5 product correlate to - blue, green and red for the first three and infrared (non-visible light) portions are captured in the other three bands.
Collectively, image bands at different geographic locations (as constrained by resolution) form digital numbers; collectively, these equidistant data points form pixels in the form of a two-dimensional grid.
Using the Map.addLayer() function, we called the image collection in, and specified visualization parameters of the band, and minimum and maximum values for the display range. Again, the curly brackets were used to limit the visualization parameters of the map visualization call function.
Map.addLayer(
first_image, {
bands: ['SR_B1'],
min: 8000,
max: 17000
},
"Layer 1"
);
We followed the same procedure for adding in two more map layers according to different bands. These included the second and third band, representing the green and red bands, respectively. Changing the opacity in these layers, and zooming to Shanghai, China (either using the Map.setCenter function or through manual zooming). The resulting map will looked like this.
Figure 3. LANDSAT 5 imagery for Bands 1, 2, and 3 for Shanghai, China.
In this section we made a image with a composite of multiple bands, as opposed to individual layers according to individual bands. Within adding the map layer we used band values were equally valued in the visualization of the map layer. The resulting image represents a near natural colour of what the earths surface would look like.
Figure 4. Landsat 5 Natural Colour composite of Bands 1,2 and 3 for Shanghai, China
Subsequently, we made a false-colour composite of bands 4, 3, and 2. The fourth band includes a frequency that detects the surface within the infrared range. As the infrared range is used for the detection of vegetation (e.g., NDVI indexes), the peninsula in the map appears with a brighter red colour than the rest of the map area. These bright red areas exhibit a higher fourth band value than the 2nd and 3rd band. This means that in the colour composite, the prevailing colour indicates a higher band value. As we learn through the lab, the use of contrast accentuates differences across the image scene (bottom panel).
Figure 5. Landsat 5 Infrared Colour composite of Bands 1,2 and 3 for Shanghai, China
In mixing bands 5, 4, and 2 we again focus on the bands within the visible spectra of the electromagnetic spectrum and compute a shortwave colour composite. These include the shortwave infrared, near infrared and visible green bands. When then compared the two colour composites both are used to emphasize the presence of vegetation. When consulting the electromagnetic spectrum, and notably the absorption within different chlorophyll pigments we see a higher absorption of light in the 400-500 range (blue-green) and the 600-700 range (red-near infrared). This would intuitively indicate the presence of vegetation in the prior infrared colour composite through the appearance of red (through the visualization of photosystem 2 Chlorophyll a pigments) and in this example the predominance of green as chlorophyll sorption is higher as the green band for vegetation is represented.
We then learned about the additive colour system, which comprises primary colors of red, blue and green, and their intersection, and how blending and hanging values corresponding to the digital number can improve representation. Adding in the National Oceanic and Atmospheric Association (NOAA) dataset for nighttime lights, loaded in the 1993, 2003 and 2013 datasets for nighttime lights, and computed the change in light intensity by adding band values for the same location. In theory, this represents higher values as representing growth >3x, and values with no to minimal change representing a 3x multiple of the values stored within each digital number. Moreover, through band visualization, this assigned different colors to the values from each time period - where red corresponded to new development (i.e., 2013) and 2003 to green, in addition to 1993 as blue. The resulting image and code reads as follows:
Figure 6: NOAA Nighttime lights change detection (1993-2013).
Overall, throughout this tutorial we learned the beginning of the JavaScript syntax, the Google Earth Engine API, and how to import and preform rudimentary visualizations on earth imagery products like Landsat 5 and a NOAA post-processing product. These included true colour, false colour, and shortwave false positive visualizations for the purpose of accentuating different landscape features.