RS4OSINT/docs/search.json

[
  {
    "objectID": "index.html",
    "href": "index.html",
    "title": "Google Earth Engine for OSINT",
    "section": "",
    "text": "Introduction\nThe analysis of satellite imagery is a foundational element of open source investigations. In the past decade, the quantity, quality, and availability thereof has increased dramatically. Capabilities and insights that were once only available to governments are now accessible to the general public. Satellite imagery is being used to collect evidence of genocide and other war crimes in Ukraine, Nigeria, Burundi, Cameroon, the DRC, South Sudan, Papua, and Venezuela. It has been used to monitor environmental degradation and hold extractive industries to account from Iraq to Guatemala. The ability to analyze satellite imagery is a critical skill for anyone interested in open source investigations.\nThough no-code platforms such as Sentinelhub have been invaluable in allowing the OSINT community to access and process satellite imagery, the analytical capabilities of these platforms are limited. Google Earth Engine (GEE) is a cloud-based platform that stores petabytes of satellite imagery from a variety of sources and allows users to perform advanced analyses on Google servers for free using a browser-based interface. This textbook is designed for investigators who want to perform more sophisticated analysis using geospatial data, and assumes no prior knowledge of coding or remote sensing (satellite imagery analysis). It is organized into two parts: an introduction to remote sensing and GEE, and a series of case studies that demonstrate how to use GEE for open source investigations."
  },
  {
    "objectID": "index.html#table-of-contents",
    "href": "index.html#table-of-contents",
    "title": "Google Earth Engine for OSINT",
    "section": "Table of Contents",
    "text": "Table of Contents\n\nLearning\n\nRemote Sensing\nData Acquisition\nApplication Development\n\nCase Studies\n\nWar at Night\nRefinery Detection\nDeforestation\nShip Detection\n\n\nRecently, a team of over 100 scientists came together to write a book called “Cloud-Based Remote Sensing with Google Earth Engine: Fundamentals and Applications”. It’s a great resource for learning about remote sensing and Earth Engine. The material in this chapter is a subset of the book, edited to fit the scope of this guide. If you’re interested in learning more, check out the full book."
  },
  {
    "objectID": "index.html#what-is-google-earth-engine",
    "href": "index.html#what-is-google-earth-engine",
    "title": "Google Earth Engine for OSINT",
    "section": "What is Google Earth Engine?",
    "text": "What is Google Earth Engine?\nAs geospatial datasets—particularly satellite imagery collections—increase in size, researchers are increasingly relying on cloud computing platforms such as Google Earth Engine (GEE) to analyze vast quantities of data.\nGEE is free and allows users to write open-source code that can be run by others in one click, thereby yielding fully reproducible results. These features have put GEE on the cutting edge of scientific research. The following plot visualizes the number of journal articles conducted using different geospatial analysis software platforms:\n\nDespite only being released in 2015, the number of geospatial journal articles using Google Earth Engine (shown in red above) has outpaced every other major geospatial analysis software, including ArcGIS, Python, and R in just five years. GEE applications have been developed and used to present interactive geospatial data visualizations by NGOs, Universities, the United Nations, and the European Commission. By storing and running computations on google servers, GEE is far more accessible to those who don’t have significant local computational resources; all you need is an internet connection."
  },
  {
    "objectID": "F1.html",
    "href": "F1.html",
    "title": "3  Getting Started",
    "section": "",
    "text": "4 Programming Basics\nThe previous chapter introduced you to images, one of the core building blocks of remotely sensed imagery in Earth Engine. In this chapter, we will expand on this concept of images by introducing image collections. Image collections in Earth Engine organize many different images into one larger data storage structure. Image collections include information about the location, date collected, and other properties of each image, allowing you to sift through the ImageCollection for the exact image characteristics needed for your analysis."
  },
  {
    "objectID": "F1.html#author",
    "href": "F1.html#author",
    "title": "3  Getting Started",
    "section": "Author",
    "text": "Author\nUjaval Gandhi"
  },
  {
    "objectID": "F1.html#overview",
    "href": "F1.html#overview",
    "title": "3  Getting Started",
    "section": "Overview",
    "text": "Overview\nThis chapter introduces the Google Earth Engine application programming interface (API) and the JavaScript syntax needed to use it. You will learn about the Code Editor environment and get comfortable typing, running, and saving scripts. You will also learn the basics of JavaScript language, such as variables, data structures, and functions."
  },
  {
    "objectID": "F1.html#learning-outcomes",
    "href": "F1.html#learning-outcomes",
    "title": "3  Getting Started",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nFamiliarity with the Earth Engine Code Editor.\nFamiliarity with the JavaScript syntax.\nAbility to use the Earth Engine API functions from the Code Editor."
  },
  {
    "objectID": "F1.html#assumes-you-know-how-to",
    "href": "F1.html#assumes-you-know-how-to",
    "title": "3  Getting Started",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nSign up for an Earth Engine account (See the Google documentation for details).\nAccess the Earth Engine Code Editor (See the Google documentation for details)."
  },
  {
    "objectID": "F1.html#introduction",
    "href": "F1.html#introduction",
    "title": "3  Getting Started",
    "section": "Introduction",
    "text": "Introduction\nIn order to use Earth Engine well, you will need to develop basic skills in remote sensing and programming. The language of this book is JavaScript, and you will begin by learning how to manipulate variables using it. With that base, you’ll learn about viewing individual satellite images, viewing collections of images in Earth Engine, and how common remote sensing terms are referenced and used in Earth Engine.\nGoogle Earth Engine is a cloud-based platform for scientific data analysis. It provides ready-to-use, cloud-hosted datasets and a large pool of servers. One feature that makes Earth Engine particularly attractive is the ability to run large computations very fast by distributing them across a large pool of servers. The ability to efficiently use cloud-hosted datasets and computation is enabled by the Earth Engine API.\nAn API is a way to communicate with Earth Engine servers. It allows you to specify what computation you would like to do, and then to receive the results. The API is designed so that users do not need to worry about how the computation is distributed across a cluster of machines and the results are assembled. Users of the API simply specify what needs to be done. This greatly simplifies the code by hiding the implementation detail from the users. It also makes Earth Engine very approachable for users who are not familiar with writing code.\nThe Earth Engine platform comes with a web-based Code Editor that allows you to start using the Earth Engine JavaScript API without any installation. It also provides additional functionality to display your results on a map, save your scripts, access documentation, manage tasks, and more. It has a one-click mechanism to share your code with other users—allowing for easy reproducibility and collaboration. In addition, the JavaScript API comes with a user interface library, which allows you to create charts and web-based applications with little effort."
  },
  {
    "objectID": "F1.html#getting-started-in-the-code-editor",
    "href": "F1.html#getting-started-in-the-code-editor",
    "title": "3  Getting Started",
    "section": "4.1 Getting Started in the Code Editor",
    "text": "4.1 Getting Started in the Code Editor\nIf you have not already done so, be sure to add the book’s code repository to the Code Editor by entering https://code.earthengine.google.com/?accept_repo=projects/gee-edu/book into your browser. The book’s scripts will then be available in the script manager panel. If you have trouble finding the repo, you can visit this link for help.\nThe Code Editor is an integrated development environment for the Earth Engine JavaScript API. It offers an easy way to type, debug, run, and manage code. Once you have followed Google’s documentation on registering for an Earth Engine account, you should follow the documentation to open the Code Editor. When you first visit the Code Editor, you will see a screen such as the one shown in Fig. F1.0.1.\n\n\n\nFig. F1.0.1 The Earth Engine Code Editor\n\n\nThe Code Editor (Fig. F1.0.1) allows you to type JavaScript code and execute it. When you are first learning a new language and getting used to a new programming environment, it is customary to make a program to display the words “Hello World.” This is a fun way to start coding that shows you how to give input to the program and how to execute it. It also shows where the program displays the output. Doing this in JavaScript is quite simple. Copy the following code into the center panel.\nprint('Hello World');\nThe line of code above uses the JavaScript print function to print the text “Hello World” to the screen. Once you enter the code, click the Run button. The output will be displayed on the upper right-hand panel under the Console tab (Fig. F1.0.2.).\n\n\n\nFig. F1.0.2 Typing and running code\n\n\nYou now know where to type your code, how to run it, and where to look for the output. You just wrote your first Earth Engine script and may want to save it. Click the Save button (Fig. F1.0.3).\n\n\n\nFig. F1.0.3 Saving a script\n\n\nIf this is your first time using the Code Editor, you will be prompted to create a home folder. This is a folder in the cloud where all your code will be saved. You can pick a name of your choice, but remember that it cannot be changed and will forever be associated with your account. A good choice for the name would be your Google Account username (Fig. F1.0.4).\n\n\n\nFig. F1.0.4 Creating a home folder\n\n\nOnce your home folder is created, you will be prompted to enter a new repository. A repository can help you organize and share code. Your account can have multiple repositories and each repository can have multiple scripts inside it. To get started, you can create a repository named “default” (Fig. F1.0.5).\n\n\n\nFig. F1.0.5 Creating a new repository\n\n\nFinally, you will be able to save your script inside the newly created repository. Enter the name “hello_world” and click OK (Fig. F1.0.6).\n\n\n\nFig. F1.0.6 Saving a file\n\n\nOnce the script is saved, it will appear in the script manager panel (Fig. F1.0.7). The scripts are saved in the cloud and will always be available to you when you open the Code Editor.\n\n\n\nFig. F1.0.7 The script manager\n\n\nNow you should be familiar with how to create, run, and save your scripts in the Code Editor. You are ready to start learning the basics of JavaScript."
  },
  {
    "objectID": "F1.html#javascript-basics",
    "href": "F1.html#javascript-basics",
    "title": "3  Getting Started",
    "section": "4.2 JavaScript Basics",
    "text": "4.2 JavaScript Basics\nTo be able to construct a script for your analysis, you will need to use JavaScript. This section covers the JavaScript syntax and basic data structures. In the sections that follow, you will see more JavaScript code, noted in a distinct font and with shaded background. As you encounter code, paste it into the Code Editor and run the script.\n\nVariables\nIn a programming language, variables are used to store data values. In JavaScript, a variable is defined using the var keyword followed by the name of the variable. The code below assigns the text “San Francisco” to the variable named city. Note that the text string in the code should be surrounded by quotes. You are free to use either ’ (single quotes) or “ (double quotes), and they must match at the beginning and end of each string. In your programs, it is advisable to be consistent—use either single quotes or double quotes throughout a given script (the code in this book generally uses single quotes for code). Each statement of your script should typically end with a semicolon, although Earth Engine’s code editor does not require it. \nvar city = 'San Francisco';\nIf you print the variable city, you will get the value stored in the variable (San Francisco) printed in the Console. \nprint(city);\nWhen you assign a text value, the variable is automatically assigned the type string. You can also assign numbers to variables and create variables of type number. The following code creates a new variable called population and assigns a number as its value.\nvar population = 873965;  \nprint(population);\n\n\nLists\nIt is helpful to be able to store multiple values in a single variable. JavaScript provides a data structure called a list that can hold multiple values. We can create a new list using the square brackets [] and adding multiple values separated by a comma.\nvar cities = ['San Francisco', 'Los Angeles', 'New York', 'Atlanta']; \nprint(cities);\nIf you look at the output in the Console, you will see “List” with an expander arrow (▹) next to it. Clicking on the arrow will expand the list and show you its content. You will notice that along with the four items in the list, there is a number next to each value. This is the index of each item. It allows you to refer to each item in the list using a numeric value that indicates its position in the list.\n\n\n\nFig. F1.0.8 A JavaScript list\n\n\n\n\nObjects\nLists allow you to store multiple values in a single container variable. While useful, it is not appropriate to store structured data. It is helpful to be able to refer to each item with its name rather than its position. Objects in JavaScript allow you to store key-value pairs, where each value can be referred to by its key. You can create a dictionary using the curly braces {}. The code below creates an object called cityData with some information about San Francisco.\nvar cityData = {   \n    'city': 'San Francisco',   \n    'coordinates': [-122.4194, 37.7749],   \n    'population': 873965 \n    };  \n\nprint(cityData);\nWe can use multiple lines to define the object. Only when we put in the semicolon (;) is the command considered complete. The object will be printed in the Console. You can see that instead of a numeric index, each item has a label. This is known as the key and can be used to retrieve the value of an item.\n\n\n\nFig. F1.0.9 A JavaScript object\n\n\n\n\nFunctions\nWhile using Earth Engine, you will need to define your own functions. Functions take user inputs, use them to carry out some computation, and send an output back. Functions allow you to group a set of operations together and repeat the same operations with different parameters without having to rewrite them every time. Functions are defined using the function keyword. The code below defines a function called greet that takes an input called name and returns a greeting with Hello prefixed to it. Note that we can call the function with different input and it generates different outputs with the same code.\nvar greet = function(name) {   \n    return 'Hello ' + name;  \n    };\n    \nprint(greet('World'));  \nprint(greet('Readers'));\n\n\n\nFig. F1.0.10 JavaScript function output\n\n\n\n\n4.2.1 Comments\nWhile writing code, it is useful to add a bit of text to explain the code or leave a note for yourself. It is a good programming practice to always add comments in the code explaining each step. In JavaScript, you can prefix any line with two forward slashes // to make it a comment. The text in the comment will be ignored by the interpreter and will not be executed.\n// This is a comment!\nCongratulations! You have learned enough JavaScript to be able to use the Earth Engine API. In the next section, you will see how to access and execute Earth Engine API functions using JavaScript.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F10a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#earth-engine-api-basics",
    "href": "F1.html#earth-engine-api-basics",
    "title": "3  Getting Started",
    "section": "4.3 Earth Engine API Basics",
    "text": "4.3 Earth Engine API Basics\nThe Earth Engine API is vast and provides objects and methods to do everything from simple math to advanced algorithms for image processing. In the Code Editor, you can switch to the Docs tab to see the API functions grouped by object types. The API functions have the prefix ee (for Earth Engine).\n\n\n\nFig. F1.0.12 Earth Engine API docs\n\n\nLet’s learn to use the API. Suppose you want to add two numbers, represented by the variables a and b, as below. Make a new script and enter the following:\nvar a = 1;  \nvar b = 2;\nIn Sect. 1, you learned how to store numbers in variables, but not how to do any computation. This is because when you use Earth Engine, you do not do addition using JavaScript operators. For example, you would not write “var c = a + b” to add the two numbers. Instead, the Earth Engine API provides you with functions to do this, and it is important that you use the API functions whenever you can. It may seem awkward at first, but using the functions, as we’ll describe below, will help you avoid timeouts and create efficient code.\nLooking at the Docs tab, you will find a group of methods that can be called on an ee.Number. Expand it to see the various functions available to work with numbers. You will see the ee.Number function that creates an Earth Engine number object from a value. In the list of functions, there is an add function for adding two numbers. That’s what you use to add a and b.\n\n\n\nFig. F1.0.13 ee.Number module\n\n\nTo add a and b, we first create an ee.Number object from variable a with ee.Number(a). And then we can use the add(b) call to add the value of b to it. The following code shows the syntax and prints the result which, of course, is the value 3. \nvar result = ee.Number(a).add(b);\nprint(result);\nBy now you may have realized that when learning to program in Earth Engine, you do not need to deeply learn JavaScript or Python—instead, they are ways to access the Earth Engine API. This API is the same whether it is called from JavaScript or Python.\nHere’s another example to drive this point home. Let’s say you are working on a task that requires you to create a list of years from 1980 to 2020 with a five-year interval. If you are faced with this task, the first step is to switch to the Docs tab and open the ee.List module. Browse through the functions and see if there are any functions that can help. You will notice a function ee.List.sequence. Clicking on it will bring up the documentation of the function.\n\n\n\nFig. F1.0.14 The ee.List.sequence function\n\n\nThe function ee.List.sequence is able to generate a sequence of numbers from a given start value to the end value. It also has an optional parameter step to indicate the increment between each number. We can create a ee.List of numbers representing years from 1980 to 2020, counting by 5, by calling this predefined function with the following values: start = 1980, end = 2020, and step = 5.\nvar yearList = ee.List.sequence(1980, 2020, 5);  \nprint(yearList);\nThe output printed in the Console will show that the variable yearList indeed contains the list of years with the correct interval.\n\n\n\nFig. F1.0.15 Output of ee.List.sequence function\n\n\nYou just accomplished a moderately complex programming task with the help of Earth Engine API.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F10b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#conclusion",
    "href": "F1.html#conclusion",
    "title": "3  Getting Started",
    "section": "Conclusion",
    "text": "Conclusion\nThis chapter introduced the Earth Engine API. You also learned the basics of JavaScript syntax to be able to use the API in the Code Editor environment. We hope you now feel a bit more comfortable starting your journey to become an Earth Engine developer. Regardless of your programming background or familiarity with JavaScript, you have the tools at your disposal to start using the Earth Engine API to build scripts for remote sensing analysis."
  },
  {
    "objectID": "F1.html#author-1",
    "href": "F1.html#author-1",
    "title": "3  Getting Started",
    "section": "Author",
    "text": "Author\nJeff Howarth"
  },
  {
    "objectID": "F1.html#overview-1",
    "href": "F1.html#overview-1",
    "title": "3  Getting Started",
    "section": "Overview",
    "text": "Overview\nSatellite images are at the heart of Google Earth Engine’s power. This chapter teaches you how to inspect and visualize data stored in image bands. We first visualize individual bands as separate map layers and then explore a method to visualize three different bands in a single composite layer. We compare different kinds of composites for satellite bands that measure electromagnetic radiation in the visible and non-visible spectrum. We then explore images that represent more abstract attributes of locations, and create a composite layer to visualize change over time."
  },
  {
    "objectID": "F1.html#learning-outcomes-1",
    "href": "F1.html#learning-outcomes-1",
    "title": "3  Getting Started",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUsing the Code Editor to load an image\nUsing code to select image bands and visualize them as map layers\nUnderstanding true- and false-color composites of images\nConstructing new multiband images.\nUnderstanding how additive color works and how to interpret RGB composites."
  },
  {
    "objectID": "F1.html#assumes-you-know-how-to-1",
    "href": "F1.html#assumes-you-know-how-to-1",
    "title": "3  Getting Started",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nSign up for an Earth Engine account, open the Code Editor, and save your script (Chap. F1.0)."
  },
  {
    "objectID": "F1.html#accessing-an-image",
    "href": "F1.html#accessing-an-image",
    "title": "3  Getting Started",
    "section": "5.1 Accessing an Image",
    "text": "5.1 Accessing an Image\nIf you have not already done so, be sure to add the book’s code repository to the Code Editor by entering https://code.earthengine.google.com/?accept_repo=projects/gee-edu/book into your browser. The book’s scripts will then be available in the script manager panel. If you have trouble finding the repo, you can visit this link for help.\nTo begin, you will construct an image with the Code Editor. In the sections that follow, you will see code in a distinct font and with shaded background. As you encounter code, paste it into the center panel of the Code Editor and click Run.\nFirst, copy and paste the following:\nvar first_image = ee.Image('LANDSAT/LT05/C02/T1_L2/LT05_118038_20000606');\nWhen you click Run, Earth Engine will load an image captured by the Landsat 5 satellite on June 6, 2000. You will not yet see any output.\nYou can explore the image in several ways. To start, you can retrieve metadata (descriptive data about the image) by printing the image to the Code Editor’s Console panel:\nprint(first_image);\nIn the Console panel, you may need to click the expander arrows to show the information. You should be able to read that this image consists of 19 different bands. For each band, the metadata lists four properties, but for now let’s simply note that the first property is a name or label for the band enclosed in quotation marks. For example, the name of the first band is “SR_B1” (Fig. F1.1.1).\n\n\n\nFig. F1.1.1 Image metadata printed to Console panel\n\n\nA satellite sensor like Landsat 5 measures the magnitude of radiation in different portions of the electromagnetic spectrum. The first six bands in our image (“SR_B1” through “SR_B7”) contain measurements for six different portions of the spectrum. The first three bands measure visible portions of the spectrum, or quantities of blue, green, and red light. The other three bands measure infrared portions of the spectrum that are not visible to the human eye.\nAn image band is an example of a raster data model, a method of storing geographic data in a two-dimensional grid of pixels, or picture elements."
  },
  {
    "objectID": "F1.html#visualizing-an-image",
    "href": "F1.html#visualizing-an-image",
    "title": "3  Getting Started",
    "section": "5.2 Visualizing an Image",
    "text": "5.2 Visualizing an Image\nNow let’s add one of the bands to the map as a layer so that we can see it.  \nMap.addLayer(first_image, //  dataset to display   \n        {bands: ['SR_B1'], //  band to display       \n        min: 8000, //  display range         \n        max: 17000},   \n        'Layer 1' //  name to show in Layer Manager  \n        );\nThe code here uses the addLayer method of the map in the Code Editor. There are four important components of the command above:\n\nfirst_image: This is the dataset to display on the map.\nbands: These are the particular bands from the dataset to display on the map. In our example, we displayed a single band named “SR_B1”.\nmin, max: These represent the lower and upper bounds of values from “SR_B1” to display on the screen. By default, the minimum value provided (8000) is mapped to black, and the maximum value provided (17000) is mapped to white. The values between the minimum and maximum are mapped linearly to grayscale between black and white. Values below 8000 are drawn as black. Values above 17000 are drawn as white. Together, the bands, min, and max parameters define visualization parameters, or instructions for data display.\n‘Layer 1’: This is a label for the map layer to display in the Layer Manager. This label appears in the dropdown menu of layers in the upper right of the map.\n\nWhen you run the code, you might not notice the image displayed unless you pan around and look for it. To do this, click and drag the map towards Shanghai, China. (You can also jump there by typing “Shanghai” into the Search panel at the top of the Code Editor, where the prompt says Search places and datasets…) Over Shanghai, you should see a small, dark, slightly angled square. Use the zoom tool (the + sign, upper left of map) to increase the zoom level and make the square appear larger.  \nCan you recognize any features in the image? By comparing it to the standard Google map that appears under the image (as the base layer), you should be able to distinguish the coastline. The water near the shore generally appears a little lighter than the land, except perhaps for a large, light-colored blob on the land in the bottom of the image.\nLet’s explore this image with the Inspector tool. When you click on the Inspector tab on the right side of the Code Editor (Fig. F1.1.2, area A), your cursor should now look like crosshairs. When you click on a location in the image, the Inspector panel will report data for that location under three categories as follows:  \n\n\n\nFig. F1.1.2 Image data reported through the Inspector panel\n\n\n\nPoint: data about the location on the map. This includes the geographic location (longitude and latitude) and some data about the map display (zoom level and scale).\nPixels: data about the pixel in the layer. If you expand this, you will see the name of the map layer, a description of the data source, and a bar chart. In our example, we see “Layer 1” is drawn from an image dataset that contains 19 bands. Under the layer name, the chart displays the pixel value at the location that you clicked for each band in the dataset. When you hover your cursor over a bar, a panel will pop up to display the band name and “band value” (pixel value). To find the pixel value for “SR_B1”, hover the cursor over the first bar on the left. Alternatively, by clicking on the little blue icon to the right of “Layer 1” (Fig. F1.1.2, area B), you will change the display from a bar chart to a dictionary that reports the pixel value for each band.    \nObjects: data about the source dataset. Here you will find metadata about the image that looks very similar to what you retrieved earlier when you directed Earth Engine to print the image to the Console.  \n\nLet’s add two more bands to the map.\nMap.addLayer(  \n   first_image,  \n   {bands: ['SR_B2'],  \n       min: 8000,  \n       max: 17000},   \n    'Layer 2',   \n    0, //  shown   \n    1 //  opacity  \n);  \n  \nMap.addLayer(  \n   first_image,  \n   {bands: ['SR_B3'],  \n       min: 8000,  \n       max: 17000},   \n    'Layer 3',   \n    1, //  shown   \n    0 //  opacity  \n);\nIn the code above, notice that we included two additional parameters to the Map.addLayer call. One parameter controls whether or not the layer is shown on the screen when the layer is drawn. It may be either 1 (shown) or 0 (not shown). The other parameter defines the opacity of the layer, or your ability to “see through” the map layer. The opacity value can range between 0 (transparent) and 1 (opaque).\n\n\n\nFig. F1.1.3 Three bands from the Landsat image, drawn as three different grayscale layers\n\n\nDo you see how these new parameters influence the map layer displays (Fig. F1.1.3)? For Layer 2, we set the shown parameter as 0. For Layer 3, we set the opacity parameter as 0. As a result, neither layer is visible to us when we first run the code. We can make each layer visible with controls in the Layers manager checklist on the map (at top right). Expand this list and you should see the names that we gave each layer when we added them to the map. Each name sits between a checkbox and an opacity slider. To make Layer 2 visible, click the checkbox (Fig. F1.1.3, area A). To make Layer 3 visible, move the opacity slider to the right (Fig. F1.1.3, area B).\nBy manipulating these controls, you should notice that these layers are displayed as a stack, meaning one on top of the other. For example, set the opacity for each layer to be 1 by pushing the opacity sliders all the way to the right. Then make sure each box is checked next to each layer so that all the layers are shown. Now you can identify which layer is on top of the stack by checking and unchecking each layer. If a layer is on top of another, unchecking the top layer will reveal the layer underneath. If a layer is under another layer in the stack, then unchecking the bottom layer will not alter the display (because the top layer will remain visible). If you try this on our stack, you should see that the list order reflects the stack order, meaning that the layer at the top of the layer list appears on the top of the stack. Now compare the order of the layers in the list to the sequence of operations in your script. What layer did your script add first and where does this appear in the layering order on the map?\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F11a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#true-color-composites",
    "href": "F1.html#true-color-composites",
    "title": "3  Getting Started",
    "section": "5.3 True-Color Composites",
    "text": "5.3 True-Color Composites\nUsing the controls in the Layers manager, explore these layers and examine how the pixel values in each band differ. Does Layer 2 (displaying pixel values from the “SR_B2” band) appear generally brighter than Layer 1 (the “SR_B1” band)? Compared with Layer 2, do the ocean waters in Layer 3 (the “SR_B3” band) appear a little darker in the north, but a little lighter in the south?  \nWe can use color to compare these visual differences in the pixel values of each band layer all at once as an RGB composite. This method uses the three primary colors (red, green, and blue) to display each pixel’s values across three bands.\nTo try this, add this code and run it.\nMap.addLayer(  \n   first_image,  \n   {bands: ['SR_B3', 'SR_B2', 'SR_B1'],  \n       min: 8000,  \n       max: 17000},   \n    'Natural Color');\nThe result (Fig. F1.1.4) looks like the world we see, and is referred to as a natural-color composite, because it naturally pairs the spectral ranges of the image bands to display colors. Also called a true-color composite, this image shows the red spectral band with shades of red, the green band with shades of green, and the blue band with shades of blue. We specified the pairing simply through the order of the bands in the list: B3, B2, B1. Because bands 3, 2, and 1 of Landsat 5 correspond to the real-world colors of red, green, and blue, the image resembles the world that we would see outside the window of a plane or with a low-flying drone.  \n\n\n\nFig. F1.1.4 True-color composite"
  },
  {
    "objectID": "F1.html#false-color-composites",
    "href": "F1.html#false-color-composites",
    "title": "3  Getting Started",
    "section": "5.4 False-Color Composites",
    "text": "5.4 False-Color Composites\nAs you saw when you printed the band list (Fig. F1.1.1), a Landsat image contains many more bands than just the three true-color bands. We can make RGB composites to show combinations of any of the bands—even those outside what the human eye can see. For example, band 4 represents the near-infrared band, just outside the range of human vision. Because of its value in distinguishing environmental conditions, this band was included on even the earliest 1970s Landsats. It has different values in coniferous and deciduous forests, for example, and can indicate crop health. To see an example of this, add this code to your script and run it.  \nMap.addLayer(  \n   first_image,  \n   {bands: ['SR_B4', 'SR_B3', 'SR_B2'],  \n       min: 8000,  \n       max: 17000},   \n    'False Color');\nIn this false-color composite (Fig. F1.1.5), the display colors no longer pair naturally with the bands. This particular example, which is more precisely referred to as a color-infrared composite, is a scene that we could not observe with our eyes, but that you can learn to read and interpret. Its meaning can be deciphered logically by thinking through what is passed to the red, green, and blue color channels.\n\n\n\nFig. F1.1.5 Color-infrared image (a false-color composite)\n\n\nNotice how the land on the northern peninsula appears bright red (Fig. F1.1.5, area A). This is because for that area, the pixel value of the first band (which is drawing the near-infrared brightness) is much higher relative to the pixel value of the other two bands. You can check this by using the Inspector tool. Try zooming into a part of the image with a red patch (Fig. F1.1.5, area B) and clicking on a pixel that appears red. Then expand the “False Color” layer in the Inspector panel (Fig. F1.1.6, area A), click the blue icon next to the layer name (Fig. F1.1.6, area B), and read the pixel value for the three bands of the composite (Fig. F1.1.6, area C). The pixel value for B4 should be much greater than for B3 or B2. \n\n\n\nFig. F1.1.6 Values of B4, B3, B2 bands for a pixel that appears bright red\n\n\nIn the bottom left corner of the image (Fig. F1.1.5, area C), rivers and lakes appear very dark, which means that the pixel value in all three bands is low. However, sediment plumes fanning from the river into the sea appear with blue and cyan tints (Fig. F1.1.5, area D). If they look like primary blue, then the pixel value for the second band (B3) is likely higher than the first (B4) and third (B2) bands. If they appear more like cyan, an additive color, it means that the pixel values of the second and third bands are both greater than the first.\nIn total, the false-color composite provides more contrast than the true-color image for understanding differences across the scene. This suggests that other bands might contain more useful information as well. We saw earlier that our satellite image consisted of 19 bands. Six of these represent different portions of the electromagnetic spectrum, including three beyond the visible spectrum, that can be used to make different false-color composites. Use the code below to explore a composite that shows shortwave infrared, near infrared, and visible green (Fig. F1.1.7).  \nMap.addLayer(  \n   first_image,  \n   {bands: ['SR_B5', 'SR_B4', 'SR_B2'],  \n       min: 8000,  \n       max: 17000},   'Short wave false color');\n\n\n\nFig. F1.1.7 Shortwave infrared false-color composite\n\n\nTo compare the two false-color composites, zoom into the area shown in the two pictures of Fig. F1.1.8. You should notice that bright red locations in the left composite appear bright green in the right composite. Why do you think that is? Does the image on the right show new distinctions not seen in the image on the left? If so, what do you think they are? \n\n\n\n\nFig. F1.1.8 Near-infrared versus shortwave infrared false-color composites\n\n\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F11b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#attributes-of-locations",
    "href": "F1.html#attributes-of-locations",
    "title": "3  Getting Started",
    "section": "5.5 Attributes of Locations",
    "text": "5.5 Attributes of Locations\nSo far, we have explored bands as a method for storing data about slices of the electromagnetic spectrum that can be measured by satellites. Now we will work towards applying the additive color system to bands that store non-optical and more abstract attributes of geographic locations.  \nTo begin, add this code to your script and run it.  \nvar lights93 = ee.Image('NOAA/DMSP-OLS/NIGHTTIME_LIGHTS/F101993');  \nprint('Nighttime lights', lights93);  \n  \nMap.addLayer(  \n   lights93,  \n   {  \n       bands: ['stable_lights'],  \n       min: 0,  \n       max: 63   },   'Lights');\nThis code loads an image of global nighttime lights and adds a new layer to the map. Please look at the metadata that we printed to the Console panel. You should see that the image consists of four bands. The code selects the “stable_lights” band to display as a layer to the map. The range of values for display (0–63) represent the minimum and maximum pixel values in this image. As mentioned earlier, you can find this range in the Earth Engine Data Datalog or with other Earth Engine methods. These will be described in more detail in the next few chapters.\nThe global nighttime lights image represents the average brightness of nighttime lights at each pixel for a calendar year. For those of us who have sat by a window in an airplane as it descends to a destination at night, the scene may look vaguely familiar. But the image is very much an abstraction. It provides us a view of the planet that we would never be able to see from an airplane or even from space. Night blankets the entire planet in darkness. There are no clouds. In the “stable lights” band, there are no ephemeral sources of light. Lightning strikes, wildfires, and other transient lights have been removed. It is a layer that aims to answer one question about our planet at one point in time: In 1993, how bright were Earth’s stable, artificial sources of light?\nWith the zoom controls on the map, you can zoom out to see the bright spot of Shanghai, the large blob of Seoul to the north and east, the darkness of North Korea except for the small dot of Pyongyang, and the dense strips of lights of Japan and the west coast of Taiwan (Fig. F1.1.10).  \n\n\n\nFig. F1.1.10 Stable nighttime lights in 1993"
  },
  {
    "objectID": "F1.html#abstract-rgb-composites",
    "href": "F1.html#abstract-rgb-composites",
    "title": "3  Getting Started",
    "section": "5.6 Abstract RGB Composites  ",
    "text": "5.6 Abstract RGB Composites  \nNow we can use the additive color system to make an RGB composite that compares stable nighttime lights at three different slices of time. Add the code below to your script and run it.  \nvar lights03 = ee.Image('NOAA/DMSP-OLS/NIGHTTIME_LIGHTS/F152003')  \n   .select('stable_lights').rename('2003');  \n  \nvar lights13 = ee.Image('NOAA/DMSP-OLS/NIGHTTIME_LIGHTS/F182013')  \n   .select('stable_lights').rename('2013');  \n  \nvar changeImage = lights13.addBands(lights03)  \n   .addBands(lights93.select('stable_lights').rename('1993'));  \n  \nprint('change image', changeImage);  \n  \nMap.addLayer(  \n   changeImage,  \n   {min: 0,  \n    max: 63},\n    'Change composite');\nThis code does a few things. First, it creates two new images, each representing a different slice of time. For both, we use the select method to select a band (“stable_lights”) and the rename method to change the band name to indicate the year it represents.  \nNext, the code uses the addBands method to create a new, three-band image that we name “changeImage”. It does this by taking one image (lights13) as the first band, using another image (lights03) as the second band, and the lights93 image seen earlier as the third band. The third band is given the name “1993” as it is placed into the image.\nFinally, the code prints metadata to the Console and adds the layer to the map as an RGB composite using Map.addLayer. If you look at the printed metadata, you should see under the label “change image” that our image is composed of three bands, with each band named after a year. You should also notice the order of the bands in the image: 2013, 2003, 1993. This order determines the color channels used to represent each slice of time in the composite: 2013 as red, 2003 as green, and 1993 as blue (Fig. F1.1.11).\n\n\n\nFig. F1.1.11 RGB composite of stable nighttime lights (2013, 2003, 1993)\n\n\nWe can now read the colors displayed on the layer to interpret different kinds of changes in nighttime lights across the planet over two decades. Pixels that appear white have high brightness in all three years. You can use the Inspector panel to confirm this. Click on the Inspector panel to change the cursor to a crosshair and then click on a pixel that appears white. Look under the Pixel category of the Inspector panel for the “Change composite” layer. The pixel value for each band should be high (at or near 63).  \nMany clumps of white pixels represent urban cores. If you zoom into Shanghai, you will notice that the periphery of the white-colored core appears yellowish and the terminal edges appear reddish. Yellow represents locations that were bright in 2013 and 2003 but dark in 1993. Red represents locations that appear bright in 2013 but dark in 2003 and 1993. If you zoom out, you will see this gradient of white core to yellow periphery to red edge occurs around many cities across the planet, and shows the global pattern of urban sprawl over the 20-year period. \nWhen you zoom out from Shanghai, you will likely notice that each map layer redraws every time you change the zoom level. In order to explore the change composite layer more efficiently, use the Layer manager panel to not show (uncheck) all of the layers except for “Change composite.” Now the map will respond faster when you zoom and pan because it will only refresh the single displayed shown layer.\nIn addition to urban change, the layer also shows changes in resource extraction activities that produce bright lights. Often, these activities produce lights that are stable over the span of a year (and therefore included in the “stable lights” band), but are not sustained over the span of a decade or more. For example, in the Korea Strait (between South Korea and Japan), you can see geographic shifts of fishing fleets that use bright halogen lights to attract squid and other sea creatures towards the water surface and into their nets. Bluish pixels were likely fished more heavily in 1993 and became used less frequently by 2003, while greenish pixels were likely fished more heavily in 2003 and less frequently by 2013 (Fig. F1.1.11).\n\n\n\nFig. F1.1.12 Large red blobs in North Dakota and Texas from fossil fuel extraction in specific years\n\n\nSimilarly, fossil fuel extraction produces nighttime lights through gas flaring. If you pan to North America (Fig. F1.1.12), red blobs in Alberta and North Dakota and a red swath in southeastern Texas all represent places where oil and gas extraction were absent in 1993 and 2003 but booming by 2013. Pan over to the Persian Gulf and you will see changes that look like holiday lights with dots of white, red, green, and blue appearing near each other; these distinguish stable and shifting locations of oil production. Blue lights in Syria near the border with Iraq signify the abandonment of oil fields after 1993 (Fig. F1.1.13). Pan further north and you will see another “holiday lights” display from oil and gas extraction around Surgut, Russia. In many of these places, you can check for oil and gas infrastructure by zooming in to a colored spot, making the lights layer not visible, and selecting the Satellite base layer (upper right).\n\n\n\nFig. F1.1.13 Nighttime light changes in the Middle East\n\n\nAs you explore this image, remember to check your interpretations with the Inspector panel by clicking on a pixel and reading the pixel value for each band. Refer back to the additive color figure to remember how the color system works. If you practice this, you should be able to read any RGB composite by knowing how colors relate to the relative pixel value of each band. This will empower you to employ false-color composites as a flexible and powerful method to explore and interpret geographic patterns and changes on Earth’s surface. \n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F11c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#conclusion-1",
    "href": "F1.html#conclusion-1",
    "title": "3  Getting Started",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, we looked at how an image is composed of one or more bands, where each band stores data about geographic locations as pixel values. We explored different ways of visualizing these pixel values as map layers, including a grayscale display of single bands and RGB composites of three bands. We created natural and false-color composites that use additive color to display information in visible and non-visible portions of the spectrum. We examined additive color as a general system for visualizing pixel values across multiple bands. We then explored how bands and RGB composites can be used to represent more abstract phenomena, including different kinds of change over time."
  },
  {
    "objectID": "F1.html#authors",
    "href": "F1.html#authors",
    "title": "3  Getting Started",
    "section": "Authors",
    "text": "Authors\nAndréa Puzzi Nicolau, Karen Dyson, David Saah, Nicholas Clinton"
  },
  {
    "objectID": "F1.html#overview-2",
    "href": "F1.html#overview-2",
    "title": "3  Getting Started",
    "section": "Overview",
    "text": "Overview\nThe purpose of this chapter is to introduce you to the many types of collections of images available in Google Earth Engine. These include sets of individual satellite images, pre-made composites (which merge multiple individual satellite images into one composite image), classified land use and land cover (LULC) maps, weather data, and other types of datasets. If you are new to JavaScript or programming, work through Chaps. F1.0 and F1.1 first."
  },
  {
    "objectID": "F1.html#learning-outcomes-2",
    "href": "F1.html#learning-outcomes-2",
    "title": "3  Getting Started",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nAccessing and viewing sets of images in Earth Engine.\nExtracting single scenes from collections of images.\nApplying visualization parameters in Earth Engine to visualize an image."
  },
  {
    "objectID": "F1.html#assumes-you-know-how-to-2",
    "href": "F1.html#assumes-you-know-how-to-2",
    "title": "3  Getting Started",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nSign up for an Earth Engine account, open the Code Editor, and save your script. (Chap. F1.0)\nLocate the Earth Engine Inspector and Console tabs and understand their purposes (Chap. F1.0).\nUse the Inspector tab to assess pixel values (Chap. F1.1)."
  },
  {
    "objectID": "F1.html#image-collections-an-organized-set-of-images",
    "href": "F1.html#image-collections-an-organized-set-of-images",
    "title": "3  Getting Started",
    "section": "6.1 Image Collections: An Organized Set of Images",
    "text": "6.1 Image Collections: An Organized Set of Images\nThere are many different types of image collections available in Earth Engine. These include collections of individual satellite images, pre-made composites that combine multiple images into one blended image, classified LULC maps, weather data, and other non-optical data sets. Each one of these is useful for different types of analyses. For example, one recent study examined the drivers of wildfires in Australia (Sulova and Jokar 2021). The research team used the European Center for Medium-Range Weather Forecast Reanalysis (ERA5) dataset produced by the European Center for Medium-Range Weather Forecasts (ECMWF) and is freely available in Earth Engine. We will look at this dataset later in the chapter.\nYou saw some of the basic ways to interact with an individual ee.Image in the previous chapter. However, depending on how long a remote sensing platform has been in operation, there may be thousands or millions of images collected of Earth. In Earth Engine, these are organized into an ImageCollection, a specialized data type that has specific operations available in the Earth Engine API. Like individual images, they can be viewed with Map.addLayer."
  },
  {
    "objectID": "F1.html#view-an-image-collection",
    "href": "F1.html#view-an-image-collection",
    "title": "3  Getting Started",
    "section": "6.2 View an Image Collection",
    "text": "6.2 View an Image Collection\nThe Landsat program from NASA and the United States Geological Survey (USGS) has launched a sequence of Earth observation satellites, named Landsat 1, 2, etc. Landsats have been returning images since 1972, making that collection of images the longest continuous satellite-based observation of the Earth’s surface. We will now view images and basic information about one of the image collections that is still growing: collections of scenes taken by the Operational Land Imager aboard Landsat 8, which was launched in 2013. Copy and paste the following code into the center panel and click Run. While the enormous image catalog is accessed, it could take a couple of minutes to see the result in the Map area. If it takes more than a couple of minutes to see the images, try zooming in to a specific area to speed up the process.\n/////  \n// View an Image Collection  \n/////  \n  \n// Import the Landsat 8 Raw Collection.  \nvar landsat8 = ee.ImageCollection('LANDSAT/LC08/C02/T1');  \n  \n// Print the size of the Landsat 8 dataset.  \nprint(\n    'The size of the Landsat 8 image collection is:', \n    landsat8.size()\n    );  \n  \n// Try to print the image collection.  \n// WARNING! Running the print code immediately below produces an error because  \n// the Console can not print more than 5000 elements.  \nprint(landsat8);  \n  \n// Add the Landsat 8 dataset to the map as a mosaic. The collection is  \n// already chronologically sorted, so the most recent pixel is displayed.  \nMap.addLayer(landsat8,  \n   {bands: ['B4', 'B3', 'B2'],  \n       min: 5000,  \n       max: 15000},   \n    'Landsat 8 Image Collection'\n    );\nFirst, let’s examine the map output (Fig. F1.2.1).\n\n\n\nFig. F1.2.1 USGS Landsat 8 Collection 2 Tier 1 Raw Scenes collection\n\n\nNotice the high amount of cloud cover, and the “layered” look. Zoom out if needed. This is because Earth Engine is drawing each of the images that make up the ImageCollection one on top of the other. The striped look is the result of how the satellite collects imagery. The overlaps between images and the individual nature of the images mean that these are not quite ready for analysis; we will address this issue in future chapters.\nNow examine the printed size on the Console. It will indicate that there are more than a million images in the dataset (Fig. F1.2.2). If you return to this lab in the future, the number will be even larger, since this active collection is continually growing as the satellite gathers more imagery. For the same reason, Fig. F1.2.1 might look slightly different on your map because of this.\n\n\n\nFig. F1.2.2  Size of the entire Landsat 8 collection. Note that this number is constantly growing.\n\n\nNote that printing the ImageCollection returned an error message (Fig. F1.2.3), because calling print on an ImageCollection will write the name of every image in the collection to the Console. This is the result of an intentional safeguard within Earth Engine. We don’t want to see a million image names printed to the Console!\n\n\n\nFig. F1.2.3. Error encountered when trying to print the names and information to the screen for too many elements\n\n\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F12a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nEdit your code to comment out the last two code commands you have written. This will remove the call to Map.addLayer that drew every image, and will remove the print statement that demanded more than 5000 elements. This will speed up your code in subsequent sections. Placing two forward slashes (//) at the beginning of a line will make it into a comment, and any commands on that line will not be executed."
  },
  {
    "objectID": "F1.html#filtering-image-collections",
    "href": "F1.html#filtering-image-collections",
    "title": "3  Getting Started",
    "section": "6.3 Filtering Image Collections",
    "text": "6.3 Filtering Image Collections\nThe ImageCollection data type in Earth Engine has multiple approaches to filtering, which helps to pinpoint the exact images you want to view or analyze from the larger collection.\n\n6.3.1 Filter by Date\nOne of the filters is filterDate, which allows us to narrow down the date range of the ImageCollection. Copy the following code to the center panel (paste it after the previous code you had):\n/////  \n// Filter an Image Collection  \n/////  \n  \n// Filter the collection by date.  \nvar landsatWinter = landsat8.filterDate('2020-12-01', '2021-03-01');  \n  \nMap.addLayer(landsatWinter,  \n   {bands: ['B4', 'B3', 'B2'],  \n       min: 5000,  \n       max: 15000},   \n    'Winter Landsat 8');  \n  \nprint('The size of the Winter Landsat 8 image collection is:',  \n   landsatWinter.size());\nExamine the mapped landsatWinter (Fig. F1.2.4). As described in the previous chaper, the 5000 and the 15000 values in the visualization parameters of the Map.addLayer function of the code above refer to the minimum and maximum of the range of display values.\n\n\n\nFig. F1.2.4 Landsat 8 Winter Collection\n\n\nNow look at the size of the winter Landsat 8 collection. The number is significantly lower than the number of images in the entire collection. This is the result of filtering the dates to three months in the winter of 2020–2021.\n\n\n6.3.2 Filter by Location\nA second frequently used filtering tool is filterBounds. This filter is based on a location—for example, a point, polygon, or other geometry. Copy and paste the code below to filter and add to the map the winter images from the Landsat 8 Image Collection to a point in Minneapolis, Minnesota, USA. Note below the Map.addLayer function to add the pointMN to the map with an empty dictionary {} for the visParams argument. This only means that we are not specifying visualization parameters for this element, and it is being added to the map with the default parameters.\n// Create an Earth Engine Point object.  \nvar pointMN = ee.Geometry.Point([-93.79, 45.05]);  \n  \n// Filter the collection by location using the point.  \nvar landsatMN = landsatWinter.filterBounds(pointMN);  \nMap.addLayer(\n    landsatMN,  \n   {bands: ['B4', 'B3', 'B2'],  \n       min: 5000,  \n       max: 15000},   \n    'MN Landsat 8');  \n  \n// Add the point to the map to see where it is.  \nMap.addLayer(pointMN, {}, 'Point MN');  \n  \nprint('The size of the Minneapolis Winter Landsat 8 image collection is: ',  \n   landsatMN.size());\nIf we uncheck the Winter Landsat 8 layer under Layers, we can see that only images that intersect our point have been selected (Fig. F1.2.5). Zoom in or out as needed. Note the printed size of the Minneapolis winter collection—we only have seven images.\n\n\n\nFig. F1.2.5 Minneapolis Winter Collection filtered by bounds.\n\n\nThe first still represents the map without zoom applied. The collection is shown inside the red circle. The second still represents the map after zoom was applied to the region. The red arrow indicates the point (in black) used to filter by bounds.\n\n\n6.3.3 Selecting the First Image\nThe final operation we will explore is the first function. This selects the first image in an ImageCollection. This allows us to place a single image on the screen for inspection. Copy and paste the code below to select and view the first image of the Minneapolis Winter Landsat 8 Image Collection. In this case, because the images are stored in time order in the ImageCollection, it will select the earliest image in the set.\n// Select the first image in the filtered collection.  \nvar landsatFirst = landsatMN.first();  \n  \n// Display the first image in the filtered collection.  \nMap.centerObject(landsatFirst, 7);  \nMap.addLayer(\n    landsatFirst,  \n   {bands: ['B4', 'B3', 'B2'],  \n       min: 5000,  \n       max: 15000},   \n    'First Landsat 8');\nThe first command takes our stack of location-filtered images and selects the first image. When the layer is added to the Map area, you can see that only one image is returned—remember to uncheck the other layers to be able to visualize the full image (Fig. F1.2.6). We used the Map.centerObject to center the map on the landsatFirst image with a zoom level of 7 (zoom levels go from 0 to 24).\n\n\n\nFig. F1.2.6 First Landsat image from the filtered set\n\n\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F12b. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nNow that we have the tools to examine different image collections, we will explore other datasets."
  },
  {
    "objectID": "F1.html#collections-of-single-images",
    "href": "F1.html#collections-of-single-images",
    "title": "3  Getting Started",
    "section": "6.4 Collections of Single Images",
    "text": "6.4 Collections of Single Images\nWhen learning about image collections in the previous section, you worked with the Landsat 8 raw image dataset. These raw images have some important corrections already done for you. However, the raw images are only one of several image collections produced for Landsat 8. The remote sensing community has developed additional imagery corrections that help increase the accuracy and consistency of analyses. The results of each of these different imagery processing paths is stored in a distinct ImageCollection in Earth Engine.\nAmong the most prominent of these is the ImageCollection meant to minimize the effect of the atmosphere between Earth’s surface and the satellite. The view from satellites is made imprecise by the need for light rays to pass through the atmosphere, even on the clearest day. There are two important ways the atmosphere obscures a satellite’s view: by affecting the amount of sunlight that strikes the Earth, and by altering electromagnetic energy on its trip from its reflection at Earth’s surface to the satellite’s receptors.\nUnraveling those effects is called atmospheric correction, a highly complex process whose details are beyond the scope of this book. Thankfully, in addition to the raw images from the satellite, each image for Landsat and certain other sensors is automatically treated with the most up-to-date atmospheric correction algorithms, producing a product referred to as a “surface reflectance” ImageCollection. The surface reflectance estimates the ratio of upward radiance at the Earth’s surface to downward radiance at the Earth’s surface, imitating what the sensor would have seen if it were hovering a few feet above the ground.  \nLet’s examine one of these datasets meant to minimize the effects of the atmosphere between Earth’s surface and the satellite. Copy and paste the code below to import and filter the Landsat 8 surface reflectance data (landsat8SR) by date and to a point over San Francisco, California, USA (pointSF). We use the first function to select the first image—a single image from March 18, 2014. By printing the landsat8SRimage image on the Console, and accessing its metadata (see Chap. F1.1), we see that the band names differ from those in the raw image (Fig. F1.2.7). Here, they have the form  “SR_B” as in “Surface Reflectance Band ”, where * is the band number. We can also check the date of the image by looking at the image “id” (Fig. F1.2.7). This has the value “20140318”, a string indicating that the image was from March 18, 2014.\n/////  \n// Collections of single images - Landsat 8 Surface Reflectance  \n/////  \n  \n// Create and Earth Engine Point object over San Francisco.  \nvar pointSF = ee.Geometry.Point([-122.44, 37.76]);  \n  \n// Import the Landsat 8 Surface Reflectance collection.  \nvar landsat8SR = ee.ImageCollection('LANDSAT/LC08/C02/T1_L2');  \n  \n// Filter the collection and select the first image.  \nvar landsat8SRimage = landsat8SR.filterDate('2014-03-18', '2014-03-19')  \n   .filterBounds(pointSF)  \n   .first();  \n  \nprint('Landsat 8 Surface Reflectance image', landsat8SRimage);\n\n\n\nFig. F1.2.7 Landsat 8 Surface Reflectance image bands and date\n\n\nCopy and paste the code below to add this image to the map with adjusted R,G, and B bands in the “bands” parameter for true-color display (see previous chapter).\n// Center map to the first image.  \nMap.centerObject(landsat8SRimage, 8);  \n  \n// Add first image to the map.  \nMap.addLayer(landsat8SRimage,  \n   {bands: ['SR_B4', 'SR_B3', 'SR_B2'],  \n       min: 7000,  \n       max: 13000},   \n    'Landsat 8 SR');\n\n\n\nFig. F1.2.8 Landsat 8 Surface Reflectance scene from March 18, 2014\n\n\nCompare this image (Fig. F1.2.8) with the raw Landsat 8 images from the previous section (Fig. F1.2.6). Zoom in and out and pan the screen as needed. What do you notice? Save your script but don’t start a new one—we will keep adding code to this script.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F12c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#modis-monthly-burned-areas",
    "href": "F1.html#modis-monthly-burned-areas",
    "title": "3  Getting Started",
    "section": "6.5 MODIS Monthly Burned Areas",
    "text": "6.5 MODIS Monthly Burned Areas\nWe’ll explore two examples of composites made with data from the MODIS sensors, a pair of sensors aboard the Terra and Aqua satellites. On these complex sensors, different MODIS bands produce data at different spatial resolutions. For the visible bands, the lowest common resolution is 500 m (red and NIR are 250 m).\nSome of the MODIS bands have proven useful in determining where fires are burning and what areas they have burned. A monthly composite product for burned areas is available in Earth Engine. Copy and paste the code below.\n// Import the MODIS monthly burned areas dataset.  \nvar modisMonthly = ee.ImageCollection('MODIS/006/MCD64A1');  \n  \n// Filter the dataset to a recent month during fire season.  \nvar modisMonthlyRecent = modisMonthly.filterDate('2021-08-01');  \n  \n// Add the dataset to the map.  \nMap.addLayer(modisMonthlyRecent, {}, 'MODIS Monthly Burn');\nUncheck the other layers, and then pan and zoom around the map. Areas that have burned in the past month will show up as red (Fig. F1.2.11). Can you see where fires burned areas of California, USA? In Southern and Central Africa? Northern Australia?\n\n\n\nFig. F1.2.11. MODIS Monthly Burn image over California\n\n\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F12d. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nSave your script and start a new one by refreshing the page."
  },
  {
    "objectID": "F1.html#methane",
    "href": "F1.html#methane",
    "title": "3  Getting Started",
    "section": "6.6 Methane",
    "text": "6.6 Methane\nSatellites can also collect information about the climate, weather, and various compounds present in the atmosphere. These satellites leverage portions of the electromagnetic spectrum and how different objects and compounds reflect when hit with sunlight in various wavelengths. For example, methane (CH4) reflects the 760 nm portion of the spectrum. Let’s take a closer look at a few of these datasets.\nThe European Space Agency makes available a methane dataset from Sentinel-5 in Earth Engine. Copy and paste the code below to add to the map methane data from the first time of collection on November 28, 2018. We use the select function (See Chap. F1.1) to select the methane-specific band of the dataset. We also introduce values for a new argument for the visualization parameters of Map.addLayer: We use a color palette to display a single band of an image in color. Here, we chose varying colors from black for the minimum value to red for the maximum value. Values in\nbetween will have the color in the order outlined by the palette parameter (a list of string colors: blue, purple, cyan, green, yellow, red).\n/////  \n// Other satellite products  \n/////  \n  \n// Import a Sentinel-5 methane dataset.  \nvar methane = ee.ImageCollection('COPERNICUS/S5P/OFFL/L3_CH4');  \n  \n// Filter the methane dataset.  \nvar methane2018 = methane.select(       'CH4_column_volume_mixing_ratio_dry_air')  \n   .filterDate('2018-11-28', '2018-11-29')  \n   .first();  \n  \n// Make a visualization for the methane data.  \nvar methaneVis = {  \n   palette: ['black', 'blue', 'purple', 'cyan', 'green',       'yellow', 'red'   ],  \n   min: 1770,  \n   max: 1920  \n};  \n  \n// Center the Map.  \nMap.centerObject(methane2018, 3);  \n  \n// Add the methane dataset to the map.  \nMap.addLayer(methane2018, methaneVis, 'Methane');\nNotice the different levels of methane over the African continent (Fig. F1.2.12).\n\n\n\nFig. F1.2.12. Methane levels over the African continent on November 28, 2018"
  },
  {
    "objectID": "F1.html#global-forest-change",
    "href": "F1.html#global-forest-change",
    "title": "3  Getting Started",
    "section": "6.7 Global Forest Change",
    "text": "6.7 Global Forest Change\nAnother useful land cover product that has been pre-classified for you and is available in Earth Engine is the Global Forest Change dataset. This analysis was conducted between 2000 and 2020. Unlike the WorldCover dataset, this dataset focuses on the percent of tree cover across the Earth’s surface in a base year of 2000, and how that has changed over time. Copy and paste the code below to visualize the tree cover in 2000. Note that in the code below we define the visualization parameters as a variable treeCoverViz instead of having its calculation done within the Map.addLayer function.\n// Import the Hansen Global Forest Change dataset.  \nvar globalForest = ee.Image(   'UMD/hansen/global_forest_change_2020_v1_8');  \n  \n// Create a visualization for tree cover in 2000.  \nvar treeCoverViz = {  \n   bands: ['treecover2000'],  \n   min: 0,  \n   max: 100,  \n   palette: ['black', 'green']  \n};  \n  \n// Add the 2000 tree cover image to the map.  \nMap.addLayer(globalForest, treeCoverViz, 'Hansen 2000 Tree Cover');\nNotice how areas with high tree cover (e.g., the Amazon) are greener and areas with low tree cover are darker (Fig. F1.2.15). In case you see an error on the Console such as “Cannot read properties of null,” don’t worry. Sometimes Earth Engine will show these transient errors, but they won’t affect the script in any way.\n\n\n\nFig. F1.2.15 Global Forest Change 2000 tree cover layer\n\n\nCopy and paste the code below to visualize the tree cover loss over the past 20 years.\n// Create a visualization for the year of tree loss over the past 20 years.  \nvar treeLossYearViz = {  \n   bands: ['lossyear'],  \n   min: 0,  \n   max: 20,  \n   palette: ['yellow', 'red']  \n};  \n  \n// Add the 2000-2020 tree cover loss image to the map.  \nMap.addLayer(globalForest, treeLossYearViz, '2000-2020 Year of Loss');\nLeave the previous 2000 tree cover layer checked and analyze the loss layer on top of it—yellow, orange, and red areas (Fig. F1.2.16). Pan and zoom around the map. Where has there been recent forest loss (which is shown in red)?\n\n\n\nFig. F1.2.16 Global Forest Change 2000–2020 tree cover loss (yellow-red) and 2000 tree cover (black-green)\n\n\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F12f. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nSave your script and start a new one."
  },
  {
    "objectID": "F1.html#digital-elevation-models",
    "href": "F1.html#digital-elevation-models",
    "title": "3  Getting Started",
    "section": "6.8 Digital Elevation Models",
    "text": "6.8 Digital Elevation Models\nDigital elevation models (DEMs) use airborne and satellite instruments to estimate the elevation of each location. Earth Engine has both local and global DEMs available. One of the global DEMs available is the NASADEM dataset, a DEM produced from a NASA mission. Copy and paste the code below to import the dataset and visualize the elevation band.\n// Import the NASA DEM Dataset.  \nvar nasaDEM = ee.Image('NASA/NASADEM_HGT/001');  \n  \n// Add the elevation layer to the map.  \nMap.addLayer(nasaDEM, {  \n   bands: ['elevation'],  \n   min: 0,  \n   max: 3000}, 'NASA DEM');\nUncheck the population layer and zoom in to examine the patterns of topography (Fig. F1.2.18). Can you see where a mountain range is located? Where is a river located? Try changing the minimum and maximum in order to make these features more visible. Save your script.\n\nFig. F1.2.18. NASADEM elevation\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F12g. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#conclusion-2",
    "href": "F1.html#conclusion-2",
    "title": "3  Getting Started",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, we introduced image collections in Earth Engine and learned how to apply multiple types of filters to image collections to identify multiple or a single image for use. We also explored a few of the many different image collections available in the Earth Engine Data Catalog. Understanding how to find, access, and filter image collections is an important step in learning how to perform spatial analyses in Earth Engine."
  },
  {
    "objectID": "F1.html#references",
    "href": "F1.html#references",
    "title": "3  Getting Started",
    "section": "References",
    "text": "References\nChander G, Huang C, Yang L, et al (2009) Developing consistent Landsat data sets for large area applications: The MRLC 2001 protocol. IEEE Geosci Remote Sens Lett 6:777–781. https://doi.org/10.1109/LGRS.2009.2025244\nChander G, Markham BL, Helder DL (2009) Summary of current radiometric calibration coefficients for Landsat MSS, TM, ETM+, and EO-1 ALI sensors. Remote Sens Environ 113:893–903. https://doi.org/10.1016/j.rse.2009.01.007\nHansen MC, Potapov PV, Moore R, et al (2013) High-resolution global maps of 21st-century forest cover change. Science 342:850–853. https://doi.org/10.1126/science.1244693\nSulova A, Arsanjani JJ (2021) Exploratory analysis of driving force of wildfires in Australia: An application of machine learning within Google Earth Engine. Remote Sens 13:1–23. https://doi.org/10.3390/rs13010010"
  },
  {
    "objectID": "F1.html#authors-1",
    "href": "F1.html#authors-1",
    "title": "3  Getting Started",
    "section": "Authors",
    "text": "Authors\nKaren Dyson, Andréa Puzzi Nicolau, David Saah, Nicholas Clinton"
  },
  {
    "objectID": "F1.html#overview-3",
    "href": "F1.html#overview-3",
    "title": "3  Getting Started",
    "section": "Overview",
    "text": "Overview\nThe purpose of this chapter is to introduce some of the principal characteristics of remotely sensed images and how they can be examined in Earth Engine. We discuss spatial resolution, temporal resolution, and spectral resolution, along with how to access important image metadata. You will be introduced to image data from several sensors aboard various satellite platforms. At the completion of the chapter, you will be able to understand the difference between remotely sensed datasets based on these characteristics, and how to choose an appropriate dataset for your analysis based on these concepts."
  },
  {
    "objectID": "F1.html#learning-outcomes-3",
    "href": "F1.html#learning-outcomes-3",
    "title": "3  Getting Started",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUnderstanding spatial, temporal, and spectral resolution.\nNavigating the Earth Engine Console to gather information about a digital image, including resolution and other data documentation."
  },
  {
    "objectID": "F1.html#assumes-you-know-how-to-3",
    "href": "F1.html#assumes-you-know-how-to-3",
    "title": "3  Getting Started",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nNavigate among Earth Engine result tabs (Chap. F1.0).\nVisualize images with a variety of false-color band combinations (Chap. F1.1)."
  },
  {
    "objectID": "F1.html#introduction-1",
    "href": "F1.html#introduction-1",
    "title": "3  Getting Started",
    "section": "Introduction",
    "text": "Introduction\nImages and image collections form the basis of many remote sensing analyses in Earth Engine. There are many different types of satellite imagery available to use in these analyses, but not every dataset is appropriate for every analysis. To choose the most appropriate dataset for your analysis, you should consider multiple factors. Among these are the resolution of the dataset—including the spatial, temporal, and spectral resolutions—as well as how the dataset was created and its quality."
  },
  {
    "objectID": "F1.html#searching-for-and-viewing-image-collection-information",
    "href": "F1.html#searching-for-and-viewing-image-collection-information",
    "title": "3  Getting Started",
    "section": "7.1 Searching for and Viewing Image Collection Information",
    "text": "7.1 Searching for and Viewing Image Collection Information\nEarth Engine’s search bar can be used to find imagery and to locate important information about datasets in Earth Engine. Let’s use the search bar, located above the Earth Engine code, to find out information about the Landsat 7 Collection 2 Raw Scenes. First, type “landsat 7 collection 2” into the search bar (Fig. F1.3.1). Without hitting Enter, matches to that search term will appear.\n\n\n\nFig. F1.3.1 Searching for Landsat 7 in the search bar\n\n\nNow, click on USGS Landsat 7 Collection 2 Tier 1 Raw Scenes. A new inset window will appear (Fig. F1.3.2).\n\n\n\nFig. F1.3.2 Inset window with information about the Landsat 7 dataset\n\n\nThe inset window has information about the dataset, including a description, bands that are available, image properties, and terms of use for the data across the top. Click on each of these tabs and read the information provided. While you may not understand all of the information right now, it will set you up for success in future chapters.\nOn the left-hand side of this window, you will see a range of dates when the data is available, a link to the dataset provider’s webpage, and a collection snippet. This collection snippet can be used to import the dataset by pasting it into your script, as you did in previous chapters. You can also use the large Import button to import the dataset into your current workspace. In addition, if you click on the See example link, Earth Engine will open a new code window with a snippet of code that shows code using the dataset. Code snippets like this can be very helpful when learning how to use a dataset that is new to you.\nFor now, click on the small “pop out” button in the upper right corner of the window. This will open a new window with the same information (Fig. F1.3.3); you can keep this new window open and use it as a reference as you proceed.\n\n\n\nFig. F1.3.3 The Data Catalog page for Landsat 7 with information about the dataset\n\n\nSwitch back to your code window. Your “landsat 7 collection 2” search term should still be in the search bar. This time, click the “Enter” key or click on the search magnifying glass icon. This will open a Search results inset window (Fig. F1.3.4).\n\n\n\nFig. F1.3.4 Search results matching “landsat 7 collection 2”\n\n\nThis more complete search results inset window contains short descriptions about each of the datasets matching your search, to help you choose which dataset you want to use. Click on the Open in Catalog button to view these search results in the Earth Engine Data Catalog (Fig. F1.3.5). Note that you may need to click Enter in the data catalog search bar with your phrase to bring up the results in this new window.\n\n\n\nFig. F1.3.5 Earth Engine Data Catalog results for the “landsat 7 collection 2” search term\n\n\nNow that we know how to view this information, let’s dive into some important remote sensing terminology."
  },
  {
    "objectID": "F1.html#spatial-resolution",
    "href": "F1.html#spatial-resolution",
    "title": "3  Getting Started",
    "section": "7.2 Spatial Resolution",
    "text": "7.2 Spatial Resolution\nSpatial resolution relates to the amount of Earth’s surface area covered by a single pixel. For example, we typically say that Landsat 7 has “30 m” color imagery. This means that each pixel is 30 m to a side, covering a total area of 900 square meters of the Earth’s surface. The spatial resolution of a given data set greatly affects the appearance of images, and the information in them, when you are viewing them on Earth’s surface.\nNext, we will visualize data from multiple sensors that capture data at different spatial resolutions, to compare the effect of different pixel sizes on the information and detail in an image. We’ll be selecting a single image from each ImageCollection to visualize. To view the image, we will draw them each as a color-IR image, a type of false-color image (described in detail in Chap. F1.1) that uses the infrared, red, and green bands. As you move through this portion of the course, zoom in and out to see differences in the pixel size and the image size.\n\n7.2.1 Landsat Thematic Mapper\nThematic Mapper (TM) sensors were flown aboard Landsat 4 and 5. TM data have been processed to a spatial resolution of 30m, and were active from 1982 to 2012. Search for “Landsat 5 TM” and import the result called “USGS Landsat 5 TM Collection 2 Tier 1 Raw Scenes”. In this dataset, the three bands for a color-IR image are called “B4” (infrared), “B3” (red), and “B2” (green). Let’s now visualize TM data over San Francisco airport. Note that we can either define the visualization parameters as a variable (as in the previous code snippet) or place them in curly braces in the Map.addLayer function (as in this code snippet).\nWhen you run this code, the TM image will display. Notice how many more pixels are displayed on your screen when compared to the MODIS image.\n// TM  \n// Filter TM imagery by location and date.  \nvar tmImage = tm   .filterBounds(Map.getCenter())  \n   .filterDate('1987-03-01', '1987-08-01')  \n   .first();  \n  \n// Display the TM image as a false color composite.  \nMap.addLayer(tmImage, {  \n   bands: ['B4', 'B3', 'B2'],   min: 0,  \n   max: 100}, 'TM');\n\n\n\nFig. F1.3.10 Visualizing the TM imagery from the Landsat 5 satellite\n\n\n\n\n7.2.2 Sentinel-2 MultiSpectral Instrument\nThe MultiSpectral Instrument (MSI) flies aboard the Sentinel-2 satellites, which are operated by the European Space Agency. The red, green, blue, and near-infrared bands are captured at 10m resolution, while other bands are captured at 20m and 30m. The Sentinel-2A satellite was launched in 2015 and the 2B satellite was launched in 2017.\nSearch for “Sentinel 2 MSI” in the search bar, and add the “Sentinel-2 MSI: MultiSpectral Instrument, Level-1C” dataset to your workspace. Name it msi. In this dataset, the three bands for a color-IR image are called “B8” (infrared), “B4” (red), and “B3” (green).\n// MSI  \n// Filter MSI imagery by location and date.  \nvar msiImage = msi   .filterBounds(Map.getCenter())  \n   .filterDate('2020-02-01', '2020-04-01')  \n   .first();  \n  \n// Display the MSI image as a false color composite.  \nMap.addLayer(msiImage, {  \n   bands: ['B8', 'B4', 'B3'],  \n   min: 0,  \n   max: 2000}, 'MSI');\nCompare the Sentinel imagery with the Landsat imagery, using the opacity slider. Notice how much more detail you can see on the airport terminal and surrounding landscape. The 10 m spatial resolution means that each pixel covers approximately 100 m2 of the Earth’s surface, a much smaller area than the TM imagery (900 m2).\n\n\n\nFig. F1.3.11 Visualizing the MSI imagery\n\n\n\n\n7.2.3 National Agriculture Imagery Program (NAIP)\nThe National Agriculture Imagery Program (NAIP) is a U.S. government program to acquire imagery over the continental United States using airborne sensors. Data is collected for each state approximately every three years. The imagery has a spatial resolution of 0.5–2 m, depending on the state and the date collected.  \nSearch for “naip” and import the data set for “NAIP: National Agriculture Imagery Program”.  Name the import naip. In this dataset, the three bands for a color-IR image are called “N” (infrared), “R” (red), and “G” (green).\n// NAIP  \n// Get NAIP images for the study period and region of interest.  \nvar naipImage = naip.filterBounds(Map.getCenter())  \n   .filterDate('2018-01-01', '2018-12-31')  \n   .first();  \n  \n// Display the NAIP mosaic as a color-IR composite.  \nMap.addLayer(naipImage, {  \n   bands: ['N', 'R', 'G']  \n}, 'NAIP');\nThe NAIP imagery is even more spatially detailed than the Sentinel-2 MSI imagery. However, we can see that our one NAIP image doesn’t totally cover the San Francisco airport. If you like, zoom out to see the boundaries of the NAIP image as we did for the Sentinel-2 MSI imagery.\n\n\n\nFig. F1.3.13 NAIP color-IR composite over the San Francisco airport\n\n\nEach of the datasets we’ve examined has a different spatial resolution. By comparing the different images over the same location in space, you have seen the differences between the large pixels of Landsat 5, the medium pixels of Sentinel-2, and the small pixels of the NAIP. Datasets with large-sized pixels are also called “coarse resolution,” those with medium-sized pixels are also called “moderate resolution,” and those with small-sized pixels are also called “fine resolution.”\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F13a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#temporal-resolution",
    "href": "F1.html#temporal-resolution",
    "title": "3  Getting Started",
    "section": "7.3 Temporal Resolution",
    "text": "7.3 Temporal Resolution\nTemporal resolution refers to the revisit time, or temporal cadence of a particular sensor’s image stream. Revisit time is the number of days between sequential visits of the satellite to the same location on the Earth’s surface. Think of this as the frequency of pixels in a time series at a given location.\n\n7.3.1 Landsat\nThe Landsat satellites 5 and later are able to image a given location every 16 days. Let’s use our existing tm dataset from Landsat 5. To see the time series of images at a location, you can filter an ImageCollection to an area and date range of interest and then print it. For example, to see the Landsat 5 images for three months in 1987, run the following code:\n/////  \n// Explore Temporal Resolution  \n/////  \n// Use Print to see Landsat revisit time  \nprint('Landsat-5 series:', tm   .filterBounds(Map.getCenter())  \n   .filterDate('1987-06-01', '1987-09-01'));  \n  \n// Create a chart to see Landsat 5's 16 day revisit time.  \nvar tmChart = ui.Chart.image.series({  \n   imageCollection: tm.select('B4').filterDate('1987-06-01',       '1987-09-01'),  \n   region: sfoPoint  \n}).setSeriesNames(['NIR']);\nExpand the features property of the printed ImageCollection in the Console output to see a List of all the images in the collection. Observe that the date of each image is part of the filename (e.g., LANDSAT/LT05/C02/T1/LT05_044034_19870628).\n\n\n\nFig. F1.3.14 Landsat image name and feature properties\n\n\nHowever, viewing this list doesn’t make it easy to see the temporal resolution of the dataset. We can use Earth Engine’s plotting functionality to visualize the temporal resolution of different datasets. For each of the different temporal resolutions, we will create a per-pixel chart of the NIR band that we mapped previously. To do this, we will use the ui.Chart.image.series function.\nThe ui.Chart.image.series function requires you to specify a few things in order to calculate the point to chart for each time step. First, we filter the ImageCollection (you can also do this outside the function and then specify the ImageCollection directly). We select the B4 (near infrared) band and then select three months by using filterDate on the ImageCollection. Next, we need to specify the location to chart; this is the region argument. We’ll use the sfoPoint variable we defined earlier.\n// Create a chart to see Landsat 5's 16 day revisit time.  \nvar tmChart = ui.Chart.image.series({  \n   imageCollection: tm.select('B4').filterDate('1987-06-01', '1987-09-01'),  \n   region: sfoPoint  \n}).setSeriesNames(['NIR']);\nBy default, this function creates a trend line. It’s difficult to see precisely when each image was collected, so let’s create a specialized chart style that adds points for each observation.\n// Define a chart style that will let us see the individual dates.  \nvar chartStyle = {  \n   hAxis: {  \n       title: 'Date'   },  \n   vAxis: {  \n       title: 'NIR Mean'   },  \n   series: {       0: {  \n           lineWidth: 3,  \n           pointSize: 6       }  \n   },  \n};// Apply custom style properties to the chart.  \ntmChart.setOptions(chartStyle);  \n  \n// Print the chart.  \nprint('TM Chart', tmChart);\nWhen you print the chart, it will have a point each time an image was collected by the TM instrument (Fig. F1.3.15). In the Console, you can move the mouse over the different points and see more information. Also note that you can expand the chart using the button in the upper right-hand corner. We will see many more examples of charts, particularly in the chapters in Part F4.\n\n\n\nFig. F1.3.15 A chart showing the temporal cadence, or temporal resolution of the Landsat 5 TM instrument at the San Francisco airport\n\n\n\n\n7.3.2 Sentinel-2\nThe Sentinel-2 program’s two satellites are in coordinated orbits, so that each spot on Earth gets visited about every 5 days. Within Earth Engine, images from these two sensors are pooled in the same dataset. Let’s create a chart using the MSI instrument dataset we have already imported.\n// Sentinel-2 has a 5 day revisit time.  \nvar msiChart = ui.Chart.image.series({  \n   imageCollection: msi.select('B8').filterDate('2020-06-01',       '2020-09-01'),  \n   region: sfoPoint  \n}).setSeriesNames(['NIR']);  \n  \n// Apply the previously defined custom style properties to the chart.  \nmsiChart.setOptions(chartStyle);  \n  \n// Print the chart.  \nprint('MSI Chart', msiChart);\n\n\n\nFig. F1.3.16 A chart showing the t temporal resolution of the Sentinel-2 MSI instrument at the San Francisco airport\n\n\nCompare this Sentinel-2 graph (Fig. F1.3.16) with the Landsat graph you just produced (Fig. F1.3.15). Both cover a period of six months, yet there are many more points through time for the Sentinel-2 satellite, reflecting the greater temporal resolution.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F13b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#spectral-resolution",
    "href": "F1.html#spectral-resolution",
    "title": "3  Getting Started",
    "section": "7.4 Spectral Resolution",
    "text": "7.4 Spectral Resolution\nSpectral resolution refers to the number and width of spectral bands in which the sensor takes measurements. You can think of the width of spectral bands as the wavelength intervals for each band. A sensor that measures radiance in multiple bands is called a multispectral sensor (generally 3–10 bands), while a sensor with many bands (possibly hundreds) is called a hyperspectral sensor.\nLet’s compare the multispectral MODIS instrument with the hyperspectral Hyperion sensor aboard the EO-1 satellite, which is also available in Earth Engine.\n\n7.4.1 MODIS\nThere is an easy way to check the number of bands in an image:\n/////  \n// Explore spectral resolution  \n/////  \n  \n// Get the MODIS band names as an ee.List  \nvar modisBands = modisImage.bandNames();  \n  \n// Print the list.  \nprint('MODIS bands:', modisBands);  \n  \n// Print the length of the list.  \nprint('Length of the bands list:', modisBands.length());\nNote that not all of the bands are spectral bands. As we did with the temporal resolution, let’s graph the spectral bands to examine the spectral resolution. If you ever have questions about what the different bands in the band list are, remember that you can find this information by visiting the dataset information page in Earth Engine or the data or satellite’s webpage.\n// Graph the MODIS spectral bands (bands 11-17).  \n  \n// Select only the reflectance bands of interest.  \nvar reflectanceImage = modisImage.select(   'sur_refl_b01',   'sur_refl_b02',   'sur_refl_b03',   'sur_refl_b04',   'sur_refl_b05',   'sur_refl_b06',   'sur_refl_b07'  \n);\nAs before, we’ll customize the chart to make it easier to read.\n// Define an object of customization parameters for the chart.  \nvar options = {  \n   title: 'MODIS spectrum at SFO',  \n   hAxis: {  \n       title: 'Band'   },  \n   vAxis: {  \n       title: 'Reflectance'   },  \n   legend: {  \n       position: 'none'   },  \n   pointSize: 3  \n};\nAnd create a chart using the ui.Chart.image.regions function.\n// Make the chart.  \nvar modisReflectanceChart = ui.Chart.image.regions({  \n   image: reflectanceImage,  \n   regions: sfoPoint  \n}).setOptions(options);  \n  \n// Display the chart.  \nprint(modisReflectanceChart);\nThe resulting chart is shown in Fig. F1.3.17. Use the expand button in the upper right to see a larger version of the chart than the one printed to the Console.\n\n\n\nFig. F1.3.17 Plot of TOA reflectance for MODIS\n\n\n\n\n7.4.2 EO-1\nNow let’s compare MODIS with the EO-1 satellite’s hyperspectral sensor. Search for “eo-1” and import the “EO-1 Hyperion Hyperspectral Imager” dataset. Name it eo1. We can look at the number of bands from the EO-1 sensor.\n// Get the EO-1 band names as a ee.List  \nvar eo1Image = eo1   .filterDate('2015-01-01', '2016-01-01')  \n   .first();  \n  \n// Extract the EO-1 band names.  \nvar eo1Bands = eo1Image.bandNames();  \n  \n// Print the list of band names.  \nprint('EO-1 bands:', eo1Bands);\nExamine the list of bands that are printed in the Console. Notice how many more bands the hyperspectral instrument provides.\nNow let’s create a reflectance chart as we did with the MODIS data.\n// Create an options object for our chart.  \nvar optionsEO1 = {  \n   title: 'EO1 spectrum',  \n   hAxis: {  \n       title: 'Band'   },  \n   vAxis: {  \n       title: 'Reflectance'   },  \n   legend: {  \n       position: 'none'   },  \n   pointSize: 3  \n};  \n  \n// Make the chart and set the options.  \nvar eo1Chart = ui.Chart.image.regions({  \n   image: eo1Image,  \n   regions: ee.Geometry.Point([6.10, 81.12])  \n}).setOptions(optionsEO1);  \n  \n// Display the chart.  \nprint(eo1Chart);\nThe resulting chart is seen in Fig. F1.3.18. There are so many bands that their names only appear as “…”!\n\n\n\nFig. F1.3.18 Plot of TOA reflectance for EO-1 as displayed in the Console. Note the button to expand the plot in the upper right hand corner.\n\n\nIf we click on the expand icon in the top right corner of the chart, it’s a little easier to see the band identifiers, as shown in Fig. F1.3.19. \n\n\n\nFig. F1.3.19 Expanded plot of TOA reflectance for EO-1\n\n\nCompare this hyperspectral instrument chart with the multispectral chart we plotted above for MODIS.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F13c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#per-pixel-quality",
    "href": "F1.html#per-pixel-quality",
    "title": "3  Getting Started",
    "section": "7.5 Per-Pixel Quality",
    "text": "7.5 Per-Pixel Quality\nAs you saw above, an image consists of many bands. Some of these bands contain spectral responses of Earth’s surface, including the NIR, red, and green bands we examined in the Spectral Resolution section. What about the other bands? Some of these other bands contain valuable information, like pixel-by-pixel quality-control data.\nFor example, Sentinel-2 has a QA60 band, which contains the surface reflectance quality assurance information. Let’s map it to inspect the values.\n/////  \n// Examine pixel quality  \n/////  \n  \n// Sentinel Quality Visualization.  \nvar msiCloud = msi   .filterBounds(Map.getCenter())  \n   .filterDate('2019-12-31', '2020-02-01')  \n   .first();  \n  \n// Display the MSI image as a false color composite.  \nMap.addLayer(msiCloud,  \n   {  \n       bands: ['B8', 'B4', 'B3'],  \n       min: 0,  \n       max: 2000   },   'MSI Quality Image');  \n  \nMap.addLayer(msiCloud,  \n   {  \n       bands: ['QA60'],  \n       min: 0,  \n       max: 2000   },   'Sentinel Quality Visualization');\nUse the Inspector tool to examine some of the values. You may see values of 0 (black), 1024 (gray), and 2048 (white). The QA60 band has values of 1024 for opaque clouds, and 2048 for cirrus clouds. Compare the false-color image with the QA60 band to see these values. More information about how to interpret these complex values is given in Chap. F4.3, which explains the treatment of clouds.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F13d. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#metadata",
    "href": "F1.html#metadata",
    "title": "3  Getting Started",
    "section": "7.6 Metadata",
    "text": "7.6 Metadata\nIn addition to band imagery and per-pixel quality flags, Earth Engine allows you to access substantial amounts of metadata associated with an image. This can all be easily printed to the Console for a single image.\nLet’s examine the metadata for the Sentinel-2 MSI.\n/////\n// Metadata\n/////\nprint(‘MSI Image Metadata’, msiImage);\nExamine the object you’ve created in the Console (Fig. F1.3.20). Expand the image name, then the properties object.\n\nFig. F1.3.20 Checking the “CLOUDY_PIXEL_PERCENTAGE” property in the metadata for Sentinel-2\nThe first entry is the CLOUDY_PIXEL_PERCENTAGE information. Distinct from the cloudiness flag attached to every pixel, this is an image-level summary assessment of the overall cloudiness in the image. In addition to viewing the value, you might find it useful to print it to the screen, for example, or to record a list of cloudiness values in a set of images. Metadata properties can be extracted from an image’s properties using the get function, and printed to the Console.\n// Image-level Cloud info\nvar msiCloudiness = msiImage.get(‘CLOUDY_PIXEL_PERCENTAGE’);\nprint(‘MSI CLOUDY_PIXEL_PERCENTAGE:’, msiCloudiness);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F13e. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F1.html#conclusion-3",
    "href": "F1.html#conclusion-3",
    "title": "3  Getting Started",
    "section": "Conclusion",
    "text": "Conclusion\nA good understanding of the characteristics of your images is critical to your work in Earth Engine and the chapters going forward. You now know how to observe and query a variety of remote sensing datasets, and can choose among them for your work. For example, if you are interested in change detection, you might require a dataset with spectral resolution including near-infrared imagery and a fine temporal resolution. For analyses at a continental scale, you may prefer data with a coarse spatial scale, while analyses for specific forest stands may benefit from a very fine spatial scale."
  },
  {
    "objectID": "F1.html#references-1",
    "href": "F1.html#references-1",
    "title": "3  Getting Started",
    "section": "References",
    "text": "References\nFisher JRB, Acosta EA, Dennedy-Frank PJ, et al (2018) Impact of satellite imagery spatial resolution on land use classification accuracy and modeled water quality. Remote Sens Ecol Conserv 4:137–149. https://doi.org/10.1002/rse2.61"
  },
  {
    "objectID": "F6.html",
    "href": "F6.html",
    "title": "7  Advanced Topics",
    "section": "",
    "text": "8 Advanced Raster Visualization\ndataset = ee.ImageCollection(‘USGS/NLCD_RELEASES/2019_REL/NLCD’)\nnlcd2019 = dataset.filter(ee.Filter.eq(‘system:index’, ‘2019’)).first()\nlandcover = nlcd2019.select(‘landcover’)\nMap\nNext, add the NLCD legend to the Map. The geemap package has several built-in legends, including the NLCD legend. Therefore, you can add the NLCD legend to the Map by using just one line of code (Map.add_legend).\ntitle = ‘NLCD Land Cover Classification’\nMap.add_legend(legend_title=title, builtin_legend=‘NLCD’)\nAlternatively, if you want to add a custom legend, you can define a legend dictionary with labels as keys and colors as values, then you can use Map.add_legend to add the custom legend to the Map.\nlegend_dict = {   ‘11 Open Water’: ‘466b9f’,   ‘12 Perennial Ice/Snow’: ‘d1def8’,   ‘21 Developed, Open Space’: ‘dec5c5’,   ‘22 Developed, Low Intensity’: ‘d99282’,   ‘23 Developed, Medium Intensity’: ‘eb0000’,   ‘24 Developed High Intensity’: ‘ab0000’,   ‘31 Barren Land (Rock/Sand/Clay)’: ‘b3ac9f’,   ‘41 Deciduous Forest’: ‘68ab5f’,   ‘42 Evergreen Forest’: ‘1c5f2c’,   ‘43 Mixed Forest’: ‘b5c58f’,   ‘51 Dwarf Scrub’: ‘af963c’,   ‘52 Shrub/Scrub’: ‘ccb879’,   ‘71 Grassland/Herbaceous’: ‘dfdfc2’,   ‘72 Sedge/Herbaceous’: ‘d1d182’,   ‘73 Lichens’: ‘a3cc51’,   ‘74 Moss’: ‘82ba9e’,   ‘81 Pasture/Hay’: ‘dcd939’,   ‘82 Cultivated Crops’: ‘ab6c28’,   ‘90 Woody Wetlands’: ‘b8d9eb’,   ‘95 Emergent Herbaceous Wetlands’: ‘6c9fb8’}\ntitle = ‘NLCD Land Cover Classification’\nMap.add_legend(legend_title=title, legend_dict=legend_dict)\nThe Map with the NLCD 2019 image and legend should look like Fig. F6.3.7.\nFig. F6.3.7 The NLCD 2019 image layer displayed in geemap\nThe Map above shows only the NLCD 2019 image. To create an Earth Engine App for visualizing land cover change, we need a stack of NLCD images. Let’s print the list of system IDs of all available NLCD images.\ndataset.aggregate_array(‘system:id’).getInfo()\nThe output should look like this.\n[‘USGS/NLCD_RELEASES/2019_REL/NLCD/2001’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2004’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2006’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2008’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2011’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2013’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2016’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2019’]\nSelect the eight NLCD epochs after 2000.\nyears = [‘2001’, ‘2004’, ‘2006’, ‘2008’, ‘2011’, ‘2013’, ‘2016’, ‘2019’]\nDefine a function for filtering the NLCD ImageCollection by year and select the ‘landcover’ band.\ndef getNLCD(year):   # Import the NLCD collection.   dataset = ee.ImageCollection(‘USGS/NLCD_RELEASES/2019_REL/NLCD’)   # Filter the collection by year.   nlcd = dataset.filter(ee.Filter.eq(‘system:index’, year)).first()    # Select the land cover band.   landcover = nlcd.select(‘landcover’);   return landcover\nCreate an NLCD ImageCollection to be used in the split-panel map.\ncollection = ee.ImageCollection(ee.List(years).map(lambda year: getNLCD(year)))\nPrint out the list of system IDs of the selected NLCD images covering the contiguous United States.\ncollection.aggregate_array(‘system:id’).getInfo()\nThe output should look like this.\n[‘USGS/NLCD_RELEASES/2019_REL/NLCD/2001’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2004’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2006’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2008’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2011’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2013’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2016’,\n‘USGS/NLCD_RELEASES/2019_REL/NLCD/2019’]\nNext, create a list of labels to populate the dropdown list.\nlabels = [f’NLCD {year}’ for year in years]\nlabels\nThe output should look like this.\n[‘NLCD 2001’,\n‘NLCD 2004’,\n‘NLCD 2006’,\n‘NLCD 2008’,\n‘NLCD 2011’,\n‘NLCD 2013’,\n‘NLCD 2016’,\n‘NLCD 2019’]\nThe last step is to create a split-panel map by passing the NLCD ImageCollection and list of labels to Map.ts_inspector.\nMap.ts_inspector(left_ts=collection, right_ts=collection, left_names=labels, right_names=labels)\nMap\nThe split-panel map should look like Fig. F6.3.8.\nFig. F6.3.8 A split-panel map for visualizing land cover change with geemap\nTo visualize land cover change, choose one NLCD image from the left dropdown list and another image from the right dropdown list, then use the slider to swipe through to visualize land cover change interactively. Click the close button in the bottom-right corner to close the split-panel map and return to the NLCD 2019 image shown in Fig. F6.3.7.\ninstall.packages(‘reticulate’) # Connect Python with R.\ninstall.packages(‘rayshader’) # 2D and 3D data visualizations in R.\ninstall.packages(‘remotes’) # Install R packages from remote repositories.\nremotes::install_github(‘r-earthengine/rgeeExtra’) # rgee extended.\ninstall.packages(‘rgee’) # GEE from within R.\ninstall.packages(‘sf’) # Simple features in R.\ninstall.packages(‘stars’) # Spatiotemporal Arrays and Vector Data Cubes.\ninstall.packages(‘geojsonio’) # Convert data to ‘GeoJSON’ from various R classes.\ninstall.packages(‘raster’) # Reading, writing, manipulating, analyzing and modeling of spatial data.\ninstall.packages(‘magick’) # Advanced Graphics and Image-Processing in R\ninstall.packages(‘leaflet.extras2’) # Extra Functionality for leaflet\ninstall.packages(‘cptcity’) # colour gradients from the ‘cpt-city’ web archive\nEarth Engine officially supports client libraries only for the JavaScript and Python programming languages. While the Earth Engine Code Editor offers a convenient environment for rapid prototyping in JavaScript, the lack of a mechanism for integration with local environments makes the development of complex scripts tricky. On the other hand, the Python client library offers much versatility, enabling support for third-party packages. However, not all Earth and environmental scientists code in Python. Hence, a significant number of professionals are not members of the Earth Engine community. In the R ecosystem, rgee (Aybar et al. 2020) tries to fill this gap by wrapping the Earth Engine Python API via reticulate (Kevin Ushey et al. 2021). The rgee package extends and supports all the Earth Engine classes, modules, and functions, working as fast as the other APIs.\nFig. F6.4.1 A simplified diagram of rgee functionality\nFigure F6.4.1 illustrates how rgee bridges the Earth Engine platform with the R ecosystem. When an Earth Engine request is created in R, rgee transforms this piece of code into Python. Next, the Earth Engine Python API converts the Python code into JSON. Finally, the JSON file request is received by the server through a Web REST API. Users could get the response using the getInfo method by following the same path in reverse.\nee_Initialize()\nIf the Google account is verified and the permission is granted, you will be directed to an authentication token. Copy and paste this token into your R console. Consider that the GCS API requires setting up credentials manually; look up and explore the rgee vignette for more information. The verification step is only required once; after that, rgee saves the credentials in your system.\netp <- ee\\(ImageCollection\\)Dataset\\(MODIS_NTSG_MOD16A2_105 %>%  ee\\)ImageCollection\\(select(\"ET\") %>%  ee\\)ImageCollection$filterDate(‘2014-04-01’, ‘2014-06-01’)\nmin = 0,  max = 300,\n palette = cpt(pal = “grass_bcyr”, rev = TRUE)\n)\nMap\\(setCenter(0, 0, 1) etpmap <- Map\\)addLayers(etp, visParams = viz)\netpmap\nFig. F6.4.6 MOD16A2 total evapotranspiration values (kg/m^2/8day)\nAnother useful rgee feature is the comparison operator (|), which creates a slider in the middle of the canvas, permitting quick comparison of two maps. For instance, load a Landsat 4 image:\nlandsat <- ee$Image(‘LANDSAT/LT04/C01/T1/LT04_008067_19890917’)\nCalculate the Normalized Difference Snow Index.\nndsi <- landsat$normalizedDifference(c(‘B3’, ‘B5’))\nDefine a constant value and use ee\\(Image\\)gte to return a binary image where pixels greater than or equal to that value are set as 1 and the rest are set as 0. Next, filter 0 values using ee\\(Image\\)updateMask.\nndsiMasked <- ndsi\\(updateMask(ndsi\\)gte(0.4))\nDefine the visualization parameters.\nvizParams <- list(\n bands <- c(‘B5’, ‘B4’, ‘B3’), # vector of three bands (R, G, B). min = 40,\n max = 240,\n gamma = c(0.95, 1.1, 1) # Gamma correction factor.)\nndsiViz <- list(\n min = 0.5,\n max = 1,\n palette = c(‘00FFFF’, ‘0000FF’)\n)\nCenter the map on the Huayhuash mountain range in Peru.\nMap$setCenter(lon = -77.20, lat = -9.85, zoom = 10)\nFinally, visualize both maps using the | operator (Fig. F6.4.7).\nm2 <- Map\\(addLayer(ndsiMasked, ndsiViz, 'NDSI masked') m1 <- Map\\)addLayer(landsat, vizParams, ‘false color composite’)\nm2  | m1\nFig. F6.4.7 False-color composite over the Huayhuash mountain range, Peru\n## Integrating rgee with Other Python Packages\nAs noted in Sect. 1, rgee set up a Python environment with NumPy and earthengine-api in your system. However, there is no need to limit it to just two Python packages. In this section, you will learn how to use the Python package ndvi2gif to perform a Normalized Difference Vegetation Index (NDVI) multi-seasonal analysis in the Ocoña Valley without leaving R.\nWhenever you want to install a Python package, you must run the following.\nlibrary(rgee)\nlibrary(reticulate)\nee_Initialize()\nThe ee_Initialize function not only authenticates your Earth Engine account but also helps reticulate to set up a Python environment compatible with rgee. After running ee_Initialize, use reticulate::install_python to install the desired Python package.\npy_install(“ndvi2gif”)\nThe previous procedure is needed just once for each Python environment. Once installed, we simply load the package using reticulate::import.\nngif <- import(“ndvi2gif”)\nThen, we define our study area using ee\\(Geometry\\)Rectangle (Fig. F6.4.8), and use the leaflet layers control to switch between basemaps.\ncolca <- c(-73.15315, -16.46289, -73.07465, -16.37857)\nroi <- ee\\(Geometry\\)Rectangle(colca)\nMap\\(centerObject(roi) Map\\)addLayer(roi)\nFig. F6.4.8 A rectangle drawn over the Ocoña Valley, Peru\nIn ndvi2gif, there is just one class: NdviSeasonality. It has the following four public methods.\nTo run, the NdviSeasonality constructor needs to define the following arguments.\nFor each year, the get_year_composite method generates an NDVI ee$Image with four bands, one band per season. Color combination between images and bands will allow you to interpret the vegetation phenology over the seasons and years. In ndvi2gif, the seasons are defined as follows.\nmyclass <- ngif$NdviSeasonality(\n roi = roi,\n start_year = 2016L,\n end_year = 2020L,\n sat = ‘Sentinel’, # ‘Sentinel’, ‘Landsat’, ‘MODIS’, ‘sar’ key = ‘max’ # ‘max’, ‘median’, ‘perc_90’\n)\nmedian <- myclass\\(get_year_composite()\\)median()\nwintermax <- myclass\\(get_year_composite()\\)select(‘winter’)$max()\nWe can display maps interactively using the Map$addLayer (Fig. F6.4.9), and use the leaflet layers control to switch between basemaps.\nMap\\(addLayer(wintermax, list(min = 0.1, max = 0.8), 'winterMax') | Map\\)addLayer(median, list(min = 0.1, max = 0.8), ‘median’)\nFig. F6.4.9 Comparison between the maximum historic winter NDVI and the mean historic NDVI. Colors represent the season when the maximum value occurred.\nAnd we can export the results to a GIF format.\nmyclass$get_gif()\nTo get more information about the ndvi2gif package, visit its GitHub repository.\n## Converting JavaScript Modules to R\nIn recent years, the Earth Engine community has developed a lot of valuable third-party modules. Some incredible ones are geeSharp (Zuspan 2020), ee-palettes (Donchyts et al. 2020), spectral (Montero 2021), and LandsatLST (Ermida et al. 2020). While some of these modules have been implemented in Python and JavaScript (e.g., geeSharp and spectral), most are available only for JavaScript. This is a critical drawback, because it divides the Earth Engine community by programming languages. For example, if an R user wants to use tagee (Safanelli et al. 2020), the user will have to first translate the entire module to R.\nIn order to close this breach, the ee_extra Python package has been developed to unify the Earth Engine community. The philosophy behind ee_extra is that all of its extended functions, classes, and methods must be functional for the JavaScript, Julia, R, and Python client libraries. Currently, ee_extra is the base of the rgeeExtra (Aybar et al. 2021) and eemont (Montero 2021) packages.\nTo demonstrate the potential of ee_extra, let’s study an example from the Landsat Land Surface Temperature (LST) JavaScript module. The Landsat LST module computes the land surface temperature for Landsat products (Ermida et al. 2020). First we will run it in the Earth Engine Code Editor; then we will replicate those results in R.\nFirst, JavaScript. In a new script in the Code Editor, we must require the Landsat LST module.\nvar LandsatLST = require(   ‘users/sofiaermida/landsat_smw_lst:modules/Landsat_LST.js’);\nThe Landsat LST module contains a function named collection. This function receives the following parameters.\nIn the following code block, we are going to define all required parameters.\nvar geometry = ee.Geometry.Rectangle([-8.91, 40.0, -8.3, 40.4]);\nvar satellite = ‘L8’;\nvar date_start = ‘2018-05-15’;\nvar date_end = ‘2018-05-31’;\nvar use_ndvi = true;\nNow, with all our parameters defined, we can compute the land surface temperature by using the collection method from Landsat LST.\nvar LandsatColl = LandsatLST.collection(satellite, date_start,\n   date_end, geometry, use_ndvi);\nThe result is stored as an ImageCollection in the LandsatColl variable. Now select the first element of the collection as an example by using the first method.\nvar exImage = LandsatColl.first();\nThis example image is now stored in a variable named ‘exImage’. Let’s display the LST result on the Map. For visualization purposes, we’ll define a color palette.\nvar cmap = [‘blue’, ‘cyan’, ‘green’, ‘yellow’, ‘red’];\nThen, we’ll center the map in the region of interest.\nMap.centerObject(geometry);\nFinally, let’s display the LST with the cmap color palette by using the Map.addLayer method (Fig. F6.4.10). This method receives the image to visualize, the visualization parameters, the color palette, and the name of the layer to show in the layer control. The visualization parameters will be:\nThe name of the layer in the Map layer set will be LST.\nMap.addLayer(exImage.select(‘LST’), {\n   min: 290,\n   max: 320,\n   palette: cmap\n}, ‘LST’)\nFig. F6.4.10 A map illustrating LST, obtained by following the JavaScript example\nNow, let’s use R to implement the same logic. As in the previous sections, import the R packages: rgee and rgeeExtra. Then, initialize your Earth Engine session.\nlibrary(rgee)\nlibrary(rgeeExtra)\nlibrary(reticulate)\nee_Initialize()\nInstall rgeeExtra Python dependencies.\npy_install(packages = c(“regex”, “ee_extra”, “jsbeautifier”))\nUsing the function rgeeExtra::module loads the JavaScript module.\nLandsatLST <- module(“users/sofiaermida/landsat_smw_lst:modules/Landsat_LST.js”)\nThe rest of the code is exactly the same as in JavaScript.\ngeometry <- ee\\(Geometry\\)Rectangle(c(-8.91, 40.0, -8.3, 40.4))\nsatellite <- ’L8’date_start <- ’2018-05-15’date_end <- ’2018-05-31’use_ndvi <- TRUE\nLandsatColl <- LandsatLST\\(collection(satellite, date_start, date_end, geometry, use_ndvi) exImage <- LandsatColl\\)first()\ncmap <- c(‘blue’, ‘cyan’, ‘green’, ‘yellow’, ‘red’)\nlmod <- list(min = 290, max = 320, palette = cmap)\nMap\\(centerObject(geometry) Map\\)addLayer(exImage$select(‘LST’), lmod, ‘LST’)\nFig. F6.4.11 A map illustrating LST, obtained by following the R example\nQuestion 1. When and why might users prefer to use R instead of Python to connect to Earth Engine?\nQuestion 2. What are the advantages and disadvantages of using rgee instead of the Earth Engine JavaScript Code Editor?"
  },
  {
    "objectID": "F6.html#author",
    "href": "F6.html#author",
    "title": "7  Advanced Topics",
    "section": "Author",
    "text": "Author\nGennadii Donchyts, Fedor Baart"
  },
  {
    "objectID": "F6.html#overview",
    "href": "F6.html#overview",
    "title": "7  Advanced Topics",
    "section": "Overview",
    "text": "Overview\nThis chapter should help users of Earth Engine to better understand raster data by applying visualization algorithms such as hillshading, hill shadows, and custom colormaps. We will also learn how image collection datasets can be explored by animating them as well as by annotating with text labels, using, for example, attributes of images or values queried from images."
  },
  {
    "objectID": "F6.html#learning-outcomes",
    "href": "F6.html#learning-outcomes",
    "title": "7  Advanced Topics",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUnderstanding why perceptually uniform colormaps are better to present data and using them efficiently for raster visualization.\nUsing palettes with images before and after remapping values.\nAdding text annotations when visualizing images or features.\nAnimating image collections in multiple ways (animated GIFs, exporting video clips, interactive animations with UI controls).\nAdding hillshading and shadows to help visualize raster datasets."
  },
  {
    "objectID": "F6.html#assumes-you-know-how-to",
    "href": "F6.html#assumes-you-know-how-to",
    "title": "7  Advanced Topics",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nWrite a function and map it over an ImageCollection (Chap. F4.0).\nInspect an Image and an ImageCollection, as well as their properties (Chap. F4.1)."
  },
  {
    "objectID": "F6.html#introduction-to-theory",
    "href": "F6.html#introduction-to-theory",
    "title": "7  Advanced Topics",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nVisualization is the step to transform data into a visual representation. You make a visualization as soon as you add your first layer to your map in Google Earth Engine. Sometimes you just want to have a first look at a dataset during the exploration phase. But as you move towards the dissemination phase, where you want to spread your results, it is good to think about a more structured approach to visualization. A typical workflow for creating visualization consists of the following steps:\n\nDefining the story (what is the message?)\nFinding inspiration (for example by making a moodboard)\nChoosing a canvas/medium (here, this is the Earth Engine map canvas)\nChoosing datasets (co-visualized or combined using derived indicators)\nData preparation (interpolating in time and space, filtering/mapping/reducing)\nConverting data into visual elements (shape and color)\nAdding annotations and interactivity (labels, scales, legend, zoom, time slider)\n\nA good standard work on all the choices that one can make while creating a visualization is provided by the Grammar of Graphics (GoG) by Wilkinson (1999). It was the inspiration behind many modern visualization libraries (ggplot, vega). The main concept is that you can subdivide your visualization into several aspects.\nIn this chapter, we will cover several aspects mentioned in the Grammar of Graphics to convert (raster) data into visual elements. The accurate representation of data is essential in science communication. However, color maps that visually distort data through uneven color gradients or are unreadable to those with color-vision deficiency remain prevalent in science (Crameri, 2020). You will also learn how to add annotation text and symbology, while improving your visualizations by mixing images with hillshading as you explore some of the amazing datasets that have been collected in recent years in Earth Engine."
  },
  {
    "objectID": "F6.html#palettes",
    "href": "F6.html#palettes",
    "title": "7  Advanced Topics",
    "section": "8.1 Palettes",
    "text": "8.1 Palettes\nIn this section we will explore examples of colormaps to visualize raster data. Colormaps translate values to colors for display on a map. This requires a set of colors (referred to as a “palette” in Earth Engine) and a range of values to map (specified by the min and max values in the visualization parameters).\nThere are multiple types of colormaps, each used for a different purpose. These include the following:\nSequential: These are probably the most commonly used colormaps, and are useful for ordinal, interval, and ratio data. Also referred to as a linear colormap, a sequential colormap looks like the viridis colormap (Fig. F6.0.1) from matplotlib. It is popular because it is a perceptual uniform colormap, where an equal interval in values is mapped to an equal interval in the perceptual colorspace. If you have a ratio variable where zero means nothing, you can use a sequential colormap starting at white, transparent, or, when you have a black background, at black—for example, the turku colormap from Crameri (Fig. F6.0.1). You can use this for variables like population count or gross domestic product.\nDiverging: This type of colormap is used for visualizing data where you have positive and negative values and where zero has a meaning. Later in this tutorial, we will use the balance colormap from the cmocean package (Fig. F6.0.1) to show temperature change.\nCircular: Some variables are periodic, returning to the same value after a period of time. For example, the season, angle, and time of day are typically represented as circular variables. For variables like this, a circular colormap is designed to represent the first and last values with the same color. An example is the circular cet-c2 colormap (Fig. F6.0.1) from the colorcet package.\nSemantic: Some colormaps do not map to arbitrary colors but choose colors that provide meaning. We refer to these as semantic colormaps. Later in this tutorial, we will use the ice colormap (Fig. F6.0.1) from the cmocean package for our ice example.\n\nFig. F6.0.1 Examples of colormaps from a variety of packages: viridis from matplotlib, turku from Crameri, balance from cmocean, cet-c2 from colorcet and ice from cmocean\nPopular sources of colormaps include:\n\ncmocean (semantic perceptual uniform colormaps for geophysical applications)\ncolorcet (set of perceptual colormaps with varying colors and saturation)\ncpt-city (comprehensive overview of colormaps,\ncolorbrewer (colormaps with variety of colors)\nCrameri (stylish colormaps for dark and light themes)\n\nOur first example in this section applies a diverging colormap to temperature.\n// Load the ERA5 reanalysis monthly means.\nvar era5 = ee.ImageCollection(‘ECMWF/ERA5_LAND/MONTHLY’);\n// Load the palettes package.\nvar palettes = require(‘users/gena/packages:palettes’);\n// Select temperature near ground.\nera5 = era5.select(‘temperature_2m’);\nNow we can visualize the data. Here we have a temperature difference. That means that zero has a special meaning. By using a divergent colormap we can give zero the color white, which denotes that there is no significant difference. Here we will use the colormap Balance from the cmocean package. The color red is associated with warmth, and the color blue is associated with cold. We will choose the minimum and maximum values for the palette to be symmetric around zero (-2, 2) so that white appears in the correct place.  For comparison we also visualize the data with a simple [‘blue’, ‘white’, ‘red’] palette. As you can see (Fig. F6.0.2), the Balance colormap has a more elegant and professional feel to it, because it uses a perceptual uniform palette and both saturation and value.\n// Choose a diverging colormap for anomalies.\nvar balancePalette = palettes.cmocean.Balance[7];\nvar threeColorPalette = [‘blue’, ‘white’, ‘red’];\n// Show the palette in the Inspector window.\npalettes.showPalette(‘temperature anomaly’, balancePalette);\npalettes.showPalette(‘temperature anomaly’, threeColorPalette);\n// Select 2 time windows of 10 years.\nvar era5_1980 = era5.filterDate(‘1981-01-01’, ‘1991-01-01’).mean();\nvar era5_2010 = era5.filterDate(‘2011-01-01’, ‘2020-01-01’).mean();\n// Compute the temperature change.\nvar era5_diff = era5_2010.subtract(era5_1980);\n// Show it on the map.\nMap.addLayer(era5_diff, {\n   palette: threeColorPalette,\n   min: -2,\n   max: 2}, ‘Blue White Red palette’);\nMap.addLayer(era5_diff, {\n   palette: balancePalette,\n   min: -2,\n   max: 2}, ‘Balance palette’);\n\nFig. F6.0.2 Temperature difference of ERA5 (2011–2020, 1981–1990) using the balance colormap from cmocean (right) versus a basic blue-white-red colormap (left)\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nOur second example in this section focuses on visualizing a region of the Antarctic, the Thwaites Glacier. This is one of the fast-flowing glaciers that causes concern because it loses so much mass that it causes the sea level to rise. If we want to visualize this region, we have a challenge. The Antarctic region is in the dark for four to five months each winter. That means that we can’t use optical images to see the ice flowing into the sea. We therefore will use radar images. Here we will use a semantic colormap to denote the meaning of the radar images.\nLet’s start by importing the dataset of radar images. We will use the images from the Sentinel-1 constellation of the Copernicus program. This satellite uses a C-band synthetic-aperture radar and has near-polar coverage. The radar senses images using a polarity for the sender and receiver. The collection has images of four different possible combinations of sender/receiver polarity pairs. The image that we’ll use has a band of the Horizontal/Horizontal polarity (HH).\n// An image of the Thwaites glacier.\nvar imageId =‘COPERNICUS/S1_GRD/S1B_EW_GRDM_1SSH_20211216T041925_20211216T042029_030045_03965B_AF0A’;\n// Look it up and select the HH band.\nvar img = ee.Image(imageId).select(‘HH’);\nFor the next step, we will use the palette library. We will stylize the radar images to look like optical images, so that viewers can contrast ice and sea ice from water (Lhermitte, 2020). We will use the Ice colormap from the cmocean package (Thyng, 2016).\n// Use the palette library.\nvar palettes = require(‘users/gena/packages:palettes’);\n// Access the ice palette.\nvar icePalette = palettes.cmocean.Ice[7];\n// Show it in the console.\npalettes.showPalette(‘Ice’, icePalette);\n// Use  it to visualize the radar data.\nMap.addLayer(img, {\n   palette: icePalette,\n   min: -15,\n   max: 1}, ‘Sentinel-1 radar’);\n// Zoom to the grounding line of the Thwaites Glacier.\nMap.centerObject(ee.Geometry.Point([-105.45882094907664, -   74.90419580705336]), 8);\nIf you zoom in (F6.0.3) you can see how long cracks have recently appeared near the pinning point (a peak in the bathymetry that functions as a buttress, see Wild, 2022) of the glacier.\n\nFig. F6.0.3. Ice observed in Antarctica by the Sentinel-1 satellite. The image is rendered using the ice color palette stretched to backscatter amplitude values [-15; 1].\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F6.html#remapping-and-palettes",
    "href": "F6.html#remapping-and-palettes",
    "title": "7  Advanced Topics",
    "section": "8.2 Remapping and Palettes",
    "text": "8.2 Remapping and Palettes\nClassified rasters in Earth Engine have metadata attached that can help with analysis and visualization. This includes lists of the names, values, and colors associated with class. These are used as the default color palette for drawing a classification, as seen next. The USGS National Land Cover Database (NLCD) is one such example. Let’s access the NLCD dataset, name it nlcd, and view it (Fig. F6.0.4) with its built-in palette.\n// Advanced remapping using NLCD.\n// Import NLCD.\nvar nlcd = ee.ImageCollection(‘USGS/NLCD_RELEASES/2016_REL’);\n// Use Filter to select the 2016 dataset.\nvar nlcd2016 = nlcd.filter(ee.Filter.eq(‘system:index’, ‘2016’))\n   .first();\n// Select the land cover band.\nvar landcover = nlcd2016.select(‘landcover’);\n// Map the NLCD land cover.\nMap.addLayer(landcover, null, ‘NLCD Landcover’);\n\nFig. F6.0.4 The NLCD visualized with default colors for each class\nBut suppose you want to change the display palette. For example, you might want to have multiple classes displayed using the same color, or use different colors for some classes. Let’s try having all three urban classes display as dark red (‘ab0000’).\n// Now suppose we want to change the color palette.\nvar newPalette = [‘466b9f’, ‘d1def8’, ‘dec5c5’,   ‘ab0000’, ‘ab0000’, ‘ab0000’,   ‘b3ac9f’, ‘68ab5f’, ‘1c5f2c’,   ‘b5c58f’, ‘af963c’, ‘ccb879’,   ‘dfdfc2’, ‘d1d182’, ‘a3cc51’,   ‘82ba9e’, ‘dcd939’, ‘ab6c28’,   ‘b8d9eb’, ‘6c9fb8’\n];\n// Try mapping with the new color palette.\nMap.addLayer(landcover, {\n   palette: newPalette\n}, ‘NLCD New Palette’);\nHowever, if you map this, you will see an unexpected result (Fig. F6.0.5).\n\nFig. F6.0.5 Applying a new palette to a multi-class layer has some unexpected results\nThis is because the numeric codes for the different classes are not sequential. Thus, Earth Engine stretches the given palette across the whole range of values and produces an unexpected color palette. To fix this issue, we will create a new index for the class values so that they are sequential.\n// Extract the class values and save them as a list.\nvar values = ee.List(landcover.get(‘landcover_class_values’));\n// Print the class values to console.\nprint(‘raw class values’, values);\n// Determine the maximum index value\nvar maxIndex = values.size().subtract(1);\n// Create a new index for the remap\nvar indexes = ee.List.sequence(0, maxIndex);\n// Print the updated class values to console.\nprint(‘updated class values’, indexes);\n// Remap NLCD and display it in the map.\nvar colorized = landcover.remap(values, indexes)\n   .visualize({\n       min: 0,\n       max: maxIndex,\n       palette: newPalette\n   });\nMap.addLayer(colorized, {}, ‘NLCD Remapped Colors’);\nUsing this remapping approach, we can properly visualize the new color palette (Fig. F6.0.6).\n\nFig. F6.0.6 Expected results of the new color palette. All urban areas are now correctly showing as dark red and the other land cover types remain their original color.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F6.html#annotations",
    "href": "F6.html#annotations",
    "title": "7  Advanced Topics",
    "section": "8.3 Annotations",
    "text": "8.3 Annotations\nAnnotations are the way to visualize data on maps to provide additional information about raster values or any other data relevant to the context. In this case, this additional information is usually shown as geometries, text labels, diagrams, or other visual elements. Some annotations in Earth Engine can be added by making use of the ui portion of the Earth Engine API, resulting in graphical user interface elements such as labels or charts added on top of the map. However, it is frequently useful to render annotations as a part of images, such as by visualizing various image properties or to highlight specific areas.\nIn many cases, these annotations can be mixed with output images generated outside of Earth Engine, for example, by post-processing exported images using Python libraries or by annotating using GIS applications such as QGIS or ArcGIS. However, annotations could also be also very useful to highlight and/or label specific areas directly within the Code Editor. Earth Engine provides a sufficiently rich API to turn vector features and geometries into raster images which can serve as annotations. We recommend checking the ee.FeatureCollection.style function in the Earth Engine documentation to learn how geometries can be rendered.\nFor  textual annotation, we will make use of an external package ‘users/gena/packages:text’ that provides a way to render strings into raster images directly using the Earth Engine raster API. It is beyond the scope of the current tutorials to explain the implementation of this package, but internally this package makes use of bitmap fonts which are ingested into Earth Engine as raster assets and are used to turn every character of a provided string into image glyphs, which are then translated to desired coordinates.\nThe API of the text package includes the following mandatory and optional arguments:\n/**\n* Draws a string as a raster image at a given point.\n*\n* (param?) {string} str - string to draw\n* (param?) {ee.Geometry} point - location the the string will be drawn\n* (param?) {{string, Object}} options - optional properties used to style text\n*\n* The options dictionary may include one or more of the following:\n*     fontSize       - 16|18|24|32 - the size of the font (default: 16)\n*     fontType       - Arial|Consolas - the type of the font (default: Arial)\n*     alignX         - left|center|right (default: left)\n*     alignY         - top|center|bottom (default: top)\n*     textColor      - text color string (default: ffffff - white)\n*     textOpacity    - 0-1, opacity of the text (default: 0.9)\n*     textWidth      - width of the text (default: 1)\n*     outlineColor   - text outline color string (default: 000000 - black)\n*     outlineOpacity - 0-1, opacity of the text outline (default: 0.4)\n*     outlineWidth   - width of the text outlines (default: 0)\n*/\nTo demonstrate how to use this API, let’s render a simple ‘Hello World!’ text string placed at the map center using default text parameters. The code for this will be:\n// Include the text package.\nvar text = require(‘users/gena/packages:text’);\n// Configure map (change center and map type).\nMap.setCenter(0, 0, 10);\nMap.setOptions(‘HYBRID’);\n// Draw text string and add to map.\nvar pt = Map.getCenter();\nvar scale = Map.getScale();\nvar image = text.draw(‘Hello World!’, pt, scale);\nMap.addLayer(image);\nRunning the above script will generate a new image containing the ‘Hello World!’ string placed in the map center. Notice that before calling the text.draw() function we configure the map to be centered at specific coordinates (0,0) and zoom level 10 because map parameters such as center and scale are passed as arguments to that text.draw() function. This ensures that the resulting image containing string characters is scaled properly.\nWhen exporting images containing rendered text strings, it is important to use proper scale to avoid distorted text strings that are difficult to read, depending on the selected font size, as shown in Fig. 6.0.7.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60d. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n\nFig. 6.0.7 Results of the text.draw call, scaled to 1x: var scale = Map.getScale()1; (left), 2x: var scale = Map.getScale()2; (center), and 0.5x: var scale = Map.getScale()*0.5; (right)\nThese artifacts can be avoided to some extent by specifying a larger font size (e.g., 32). However, it is better to render text at the native 1:1 scale to achieve best results. The same applies to the text color and outline: They may need to be adjusted to achieve the best result. Usually, text needs to be rendered using colors that have opposite brightness and colors when compared to the surrounding background. Notice that in the above example, the map was configured to have a dark background (‘HYBRID’) to ensure that the white text (default color) would be visible. Multiple parameters listed in the above API documentation can be used to adjust text rendering. For example, let’s switch font size, font type, text, and outline parameters to render the same string, as below. Replace the existing one-line text.draw call in your script with the following code, and then run it again to see the difference (Fig. F6.0.8):\nvar image = text.draw(‘Hello World!’, pt, scale, {\n   fontSize: 32,\n   fontType: ‘Consolas’,\n   textColor: ‘black’,\n   outlineColor: ‘white’,\n   outlineWidth: 1,\n   outlineOpacity: 0.8\n});\n// Add the text image to the map.\nMap.addLayer(image);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60e. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n\nFig. 6.0.8 Rendering text with adjusted parameters (font type: Consolas, fontSize: 32, textColor: ‘black’, outlineWidth: 1, outlineColor: ‘white’, outlineOpacity: 0.8)\nOf course, non-optional parameters such as pt and scale, as well as the text string, do not have to be hard-coded in the script; instead, they can be acquired by the code using, for example, properties coming from a FeatureCollection. Let’s demonstrate this by showing the cloudiness of Landsat 8 images as text labels rendered in the center of every image. In addition to annotating every image with a cloudiness text string, we will also draw yellow outlines to indicate image boundaries. For convenience, we can also define the code to annotate an image as a function. We will then map that function (as described in Chap. F4.0) over the filtered ImageCollection. The code is as follows:\nvar text = require(‘users/gena/packages:text’);\nvar geometry = ee.Geometry.Polygon(\n   [\n       [\n           [-109.248, 43.3913],\n           [-109.248, 33.2689],\n           [-86.5283, 33.2689],\n           [-86.5283, 43.3913]\n       ]\n   ], null, false);\nMap.centerObject(geometry, 6);\nfunction annotate(image) {   // Annotates an image by adding outline border and cloudiness   // Cloudiness is shown as a text string rendered at the image center.   // Add an edge around the image.   var edge = ee.FeatureCollection([image])\n       .style({\n           color: ‘cccc00cc’,\n           fillColor: ‘00000000’       });   // Draw cloudiness as text.   var props = {\n       textColor: ‘0000aa’,\n       outlineColor: ‘ffffff’,\n       outlineWidth: 2,\n       outlineOpacity: 0.6,\n       fontSize: 24,\n       fontType: ‘Consolas’   };   var center = image.geometry().centroid(1);   var str = ee.Number(image.get(‘CLOUD_COVER’)).format(‘%.2f’);   var scale = Map.getScale();   var textCloudiness = text.draw(str, center, scale, props);   // Shift left 25 pixels.   textCloudiness = textCloudiness\n       .translate(-scale * 25, 0, ‘meters’, ‘EPSG:3857’);   // Merge results.   return ee.ImageCollection([edge, textCloudiness]).mosaic();\n}\n// Select images.\nvar images = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_RT_TOA’)\n   .select([5, 4, 2])\n   .filterBounds(geometry)\n   .filterDate(‘2018-01-01’, ‘2018-01-7’);\n// dim background.\nMap.addLayer(ee.Image(1), {\n   palette: [‘black’]\n}, ‘black’, true, 0.5);\n// Show images.\nMap.addLayer(images, {\n   min: 0.05,\n   max: 1,\n   gamma: 1.4}, ‘images’);\n// Show annotations.\nvar labels = images.map(annotate);\nvar labelsLayer = ui.Map.Layer(labels, {}, ‘annotations’);\nMap.layers().add(labelsLayer);\nThe result of defining and mapping this function over the filtered set of images is shown in Fig. F6.0.9. Notice that by adding an outline around the text, we can ensure the text is visible for both dark and light images. Earth Engine requires casting properties to their corresponding value type, which is why we’ve used ee.Number (as described in Chap. F1.0) before generating a formatted string. Also, we have shifted the resulting text image 25 pixels to the left. This was necessary to ensure that the text is positioned properly. In more complex text rendering applications, users may be required to compute the text position in a different way using ee.Geometry calls from the Earth Engine API: for example, by positioning text labels somewhere near the corners.\n\nFig. F6.0.9 Annotating Landsat 8 images with image boundaries, border, and text strings indicating cloudiness\nBecause we render text labels using the Earth Engine raster API, they are not automatically scaled depending on map zoom size. This may cause unwanted artifacts; To avoid that, the text labels image needs to be updated every time the map zoom changes. To implement this in a script, we can make use of the Map API—in particular, the Map.onChangeZoom event handler. The following code snippet shows how the image containing text annotations can be re-rendered every time the map zoom changes. Add it to the end of your script.\n// re-render (rescale) annotations when map zoom changes.\nMap.onChangeZoom(function(zoom) {\n   labelsLayer.setEeObject(images.map(annotate));\n});\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60f. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nTry commenting that event handler and observe how annotation rendering changes when you zoom in or zoom out."
  },
  {
    "objectID": "F6.html#animations",
    "href": "F6.html#animations",
    "title": "7  Advanced Topics",
    "section": "8.4 Animations",
    "text": "8.4 Animations\nVisualizing raster images as animations is a useful technique to explore changes in time-dependent datasets, but also, to render short animations to communicate how changing various parameters affects the resulting image—for example, varying thresholds of spectral indices resulting in different binary maps or the changing geometry of vector features.\nAnimations are very useful when exploring satellite imagery, as they allow viewers to quickly comprehend dynamics of changes of earth surface or atmospheric properties. Animations can also help to decide what steps should be taken next to designing a robust algorithm to extract useful information from satellite image time series. Earth Engine provides two standard ways to generate animations: as animated GIFs, and as AVI video clips. Animation can also be rendered from a sequence of images exported from Earth Engine, using numerous tools such as ffmpeg or moviepy. However, in many cases it is useful to have a way to quickly explore image collections as animation without requiring extra steps.\nIn this section, we will generate animations in three different ways:\n\nGenerate animated GIF\nExport video as an AVI file to Google Drive\nAnimate image collection interactively using UI controls and map layers\n\nWe will use an image collection showing sea ice as an input dataset to generate animations with visualization parameters from earlier. However, instead of querying a single Sentinel-1 image, let’s generate a filtered image collection with all images intersecting with our area of interest. After importing some packages and palettes and defining a point and rectangle, we’ll build the image collection. Here we will use point geometry to define the location where the image date label will be rendered and the rectangle geometry to indicate the area of interest for the animation. To do this we will build the following logic in a new script. Open a new script and paste the following code into it:\n// Include packages.\nvar palettes = require(‘users/gena/packages:palettes’);\nvar text = require(‘users/gena/packages:text’);\nvar point = /* color: #98ff00 */ ee.Geometry.Point([-   106.15944300895228, -74.58262940096245\n]);\nvar rect = /* color: #d63000 */   ee.Geometry.Polygon(\n       [\n           [\n               [-106.19789515738981, -74.56509549360152],\n               [-106.19789515738981, -74.78071448733921],\n               [-104.98115931754606, -74.78071448733921],\n               [-104.98115931754606, -74.56509549360152]\n           ]\n       ], null, false);\n// Lookup the ice palette.\nvar palette = palettes.cmocean.Ice[7];\n// Show it in the console.\npalettes.showPalette(‘Ice’, palette);\n// Center map on geometry.\nMap.centerObject(point, 9);\n// Select S1 images for the Thwaites glacier.\nvar images = ee.ImageCollection(‘COPERNICUS/S1_GRD’)\n   .filterBounds(rect)\n   .filterDate(‘2021-01-01’, ‘2021-03-01’)\n   .select(‘HH’)   // Make sure we include only images which fully contain the region geometry.   .filter(ee.Filter.isContained({\n       leftValue: rect,\n       rightField: ‘.geo’   }))\n   .sort(‘system:time_start’);\n// Print number of images.\nprint(images.size());\nAs you see from the last last lines of the above code, it is frequently useful to print the number of images in an image collection: an example of what’s often known as a “sanity check.”\nHere we have used two custom geometries to configure animations: the green pin named point, used to filter image collection and to position text labels drawn on top of the image, and the blue rectangle rect, used to define a bounding box for the exported animations. To make sure that the point and rectangle geometries are shown under the Geometry Imports in the Code Editor, you need to click on these variables in the code and then select the Convert link.\nNotice that in addition to the bounds and date filter, we have also used a less known isContained filter to ensure that we get only images that fully cover our region. To better understand this filter, you could try commenting out the filter and compare the differences, observing images with empty (masked) pixels in the resulting image collection.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60g. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nNext, to simplify the animation API calls, we will generate a composite RGB image collection out of satellite images and draw the image’s acquisition date as a label on every image, positioned within our region geometry.\n// Render images.\nvar vis = {\n   palette: palette,\n   min: -15,\n   max: 1\n};\nvar scale = Map.getScale();\nvar textProperties = {\n   outlineColor: ‘000000’,\n   outlineWidth: 3,\n   outlineOpacity: 0.6\n};\nvar imagesRgb = images.map(function(i) {   // Use the date as the label.   var label = i.date().format(‘YYYY-MM-dd’);   var labelImage = text.draw(label, point, scale,\n       textProperties);   return i.visualize(vis)\n       .blend(labelImage) // Blend label image on top.       .set({\n           label: label\n       }); // Keep the text property.\n});\nMap.addLayer(imagesRgb.first());\nMap.addLayer(rect, {color:‘blue’}, ‘rect’, 1, 0.5);\nIn addition to printing the size of the ImageCollection, we also often begin by adding a single image to the map from a mapped collection to see that everything works as expected—another example of a sanity check. The resulting map layer will look like F6.0.10.\n\nFig. F6.0.10 The results of adding the first layer from the RGB composite image collection showing Sentinel-1 images with a label blended on top at a specified location. The blue geometry is used to define the bounds for the animation to be exported.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60h. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nAnimation 1: Animated GIF with ui.Thumbnail\nThe quickest way to generate an animation in Earth Engine is to use the animated GIF API and either print it to the Console or print the URL to download the generated GIF. The following code snippet will result in an animated GIF as well as the URL to the animated GIF printed to Console. This is as shown in Fig. F6.0.11:\n// Define GIF visualization parameters.\nvar gifParams = {\n   region: rect,\n   dimensions: 600,\n   crs: ‘EPSG:3857’,\n   framesPerSecond: 10\n};\n// Print the GIF URL to the console.\nprint(imagesRgb.getVideoThumbURL(gifParams));\n// Render the GIF animation in the console.\nprint(ui.Thumbnail(imagesRgb, gifParams));\nEarth Engine provides multiple options to specify the size of the resulting video. In this example we specify 600 as the size of the maximum dimension. We also specify the number of frames per second for the resulting animated GIF as well as the target projected coordinate system to be used (EPSG:3857 here, which is the projection used in web maps such as Google Maps and the Code Editor background).\n\nFig. F6.0.11 Console output after running the animated GIF code snippet, showing the GIF URL and an animation shown directly in the Console\nAnimation 2: Exporting an Animation with Export.video.toDrive\nAnimated GIFs can be useful to generate animations quickly. However, they have several limitations. In particular, they are limited to 256 colors, become large for larger animations, and most web players do not provide play controls when playing animated GIFs. To overcome these limitations, Earth Engine provides export of animations as video files in MP4 format. Let’s use the same RGB image collection we have used for the animated GIF to generate a short video. We can ask Earth Engine to export the video to the Google Drive using the following code snippet:\nExport.video.toDrive({\n   collection: imagesRgb,\n   description: ‘ice-animation’,\n   fileNamePrefix: ‘ice-animation’,\n   framesPerSecond: 10,\n   dimensions: 600,\n   region: rect,\n   crs: ‘EPSG:3857’\n});\nHere, many arguments to the Export.video.toDrive function resemble the ones we’ve used in the ee.Image.getVideoThumbURL code above. Additional arguments include description and fileNamePrefix, which are required to configure the name of the task and the target file of the video file to be saved to Google Drive. Running the above code will result in a new task created under the Tasks tab in the Code Editor. Starting the export video task (F6.0.12) will result in a video file saved in the Google Drive once completed.\n\nFig. F6.0.12 A new export video tasks in the Tasks panel of the Code Editor\nAnimation 3: The Custom Animation Package\nFor the last animation example, we will use the custom package ‘users/gena/packages:animation’, built using the Earth Engine User Interface API. The main difference between this package and the above examples is that it generates an interactive animation by adding Map layers individually to the layer set, and providing UI controls that allow users to play animations or interactively switch between frames. The animate function in that package generates an interactive animation of an ImageCollection, as described below. This function has a number of optional arguments allowing you to configure, for example, the number of frames to be animated, the number of frames to be preloaded, or a few others. The optional parameters to control the function are the following:\n\nmaxFrames: maximum number of frames to show (default: 30)\nvis: visualization parameters for every frame (default: {})\nLabel: text property of images to show in the animation controls (default: undefined)\nwidth: width of the animation panel (default: ‘600px’)\ncompact: show only play control and frame slider (default: false)\nposition: position of the animation panel (default: ‘top-center’)\ntimeStep: time step (ms) used when playing animation (default: 100)\npreloadCount: number of frames (map layers) to preload (default: all)\n\nLet’s call this function to add interactive animation controls to the current Map:\n// include the animation package\nvar animation = require(‘users/gena/packages:animation’);\n// show animation controls\nanimation.animate(imagesRgb, {\n label: ‘label’,\n maxFrames: 50\n});\nBefore using the interactive animation API, we need to include the corresponding package using require. Here we provide our pre-rendered image collection and two optional parameters (label and maxFrames). The first optional parameter label indicates that every image in our image collection has the ‘label’ text property. The animate function uses this property to name map layers as well as to visualize in the animation UI controls when switching between frames. This can be useful when inspecting image collections. The second optional parameter, maxFrames, indicates that the maximum number of animation frames that we would like to visualize is 50. To prevent the Code Editor from crashing, this parameter should not be too large: it is best to keep it below 100. For a much larger number of frames, it is better to use the Export video or animated GIF API. Running this code snippet will result in the animation control panel added to the map as shown in Fig. F6.0.13.\nIt is important to note that the animation API uses asynchronous UI calls to make sure that the Code Editor does not hang when running the script. The drawback of this is that for complex image collections, a large amount of processing is required. Hence, it may take some time to process all images and to visualize the interactive animation panel. The same is true for map layer names: they are updated once the animation panel is visualized. Also, map layers used to visualize individual images in the provided image collection may require some time to be rendered.\n\nFig. F6.0.13 Interactive animation controls when using custom animation API\nThe main advantage of the interactive animation API is that it provides a way to explore image collections at frame-by-frame basis, which can greatly improve our visual understanding of the changes captured in sets of images.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60i. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F6.html#terrain-visualization",
    "href": "F6.html#terrain-visualization",
    "title": "7  Advanced Topics",
    "section": "8.5 Terrain Visualization",
    "text": "8.5 Terrain Visualization\nThis section introduces several raster visualization techniques useful to visualize terrain data such as:\n\nBasic hillshading and parameters (light azimuth, elevation)\nCombining elevation data and colors using HSV transform (Wikipedia: HSL and HSV)\nAdding shadows\n\nOne special type of raster data is data that represents height. Elevation data can include topography, bathymetry, but also other forms of height, such as sea surface height can be presented as a terrain.\nHeight is often visualized using the concept of directional light with a technique called hillshading. Because height is such a common feature in our environment, we also have an expectancy of how height is visualized. If height is visualized using a simple grayscale colormap, it looks very unnatural (Fig. F6.0.14, top left). By using hillshading, data immediately looks more natural (Fig. F6.0.14, top middle).\nWe can further improve the visualization by including shadows (Fig. F6.0.14, top right).  A final step is to replace the simple grayscale colormap with a perceptual uniform topographic colormap and mix this with the hillshading and shadows (Fig. F6.0.14, bottom). This section explains how to apply these techniques.\nWe’ll focus on elevation data stored in raster form. Elevation data is not always stored in raster formats. Other data formats include Triangulated Irregular Network (TIN), which allows storing information at varying resolutions and as 3D objects. This format allows one to have overlapping geometries, such as bridges with a road below it. In raster-based digital elevation models, in contrast, there can only be one height recorded for each pixel.\nLet’s start by loading data from a digital elevation model. This loads a topographic dataset from the Netherlands (Algemeen Hoogtebestand Nederland). It is a Digital Surface Model, based on airborne LIDAR measurements regridded to 0.5 m resolution. Enter the following code in a new script.\nvar dem = ee.Image(‘AHN/AHN2_05M_RUW’);\nWe can visualize this dataset using a sequential gradient colormap from black to white. This results in Fig. F6.0.14. One can infer which areas are lower and which are higher, but the visualization does not quite “feel” like a terrain.\n// Change map style to HYBRID and center map on the Netherlands\nMap.setOptions(‘HYBRID’);\nMap.setCenter(4.4082, 52.1775, 18);\n// Visualize DEM using black-white color palette\nvar palette = [‘black’, ‘white’];\nvar demRGB = dem.visualize({\n   min: -5,\n   max: 5,\n   palette: palette\n});\nMap.addLayer(demRGB, {},‘DEM’);\nAn important step to visualize terrain is to add shadows created by a distant point source of light. This is referred to as hillshading or a shaded relief map. This type of map became popular in the 1940s through the work of Edward Imhoff, who also used grayscale colormaps (Imhoff, 2015). Here we’ll use the ‘gena/packages:utils’ library to combine the colormap image with the shadows. That Earth Engine package implements a hillshadeRGB function to simplify rendering of images enhanced with hillshading and shadow effects. One important argument this function takes is the light azimuth—an angle from the image plane upward to the light source (the Sun). This should always be set to the top left to avoid bistable perception artifacts, in which the DEM can be misperceived as inverted.\nvar utils = require(‘users/gena/packages:utils’);\nvar weight =   0.4; // Weight of Hillshade vs RGB (0 - flat, 1 - hillshaded).\nvar exaggeration = 5; // Vertical exaggeration.\nvar azimuth = 315; // Sun azimuth.\nvar zenith = 20; // Sun elevation.\nvar brightness = -0.05; // 0 - default.\nvar contrast = 0.05; // 0 - default.\nvar saturation = 0.8; // 1 - default.\nvar castShadows = false;\nvar rgb = utils.hillshadeRGB(\n   demRGB, dem, weight, exaggeration, azimuth, zenith,\n   contrast, brightness, saturation, castShadows);\nMap.addLayer(rgb, {}, ‘DEM (no shadows)’);\nStandard hillshading only determines per pixel if it will be directed to the light or not. One can also project shadows on the map. That is done using the ee.Algorithms.HillShadow algorithm. Here we’ll turn on castShadows in the hillshadeRGB function. This results in a more realistic map, as can be seen in Figure F6.0.14.\nvar castShadows = true;\nvar rgb = utils.hillshadeRGB(\n   demRGB, dem, weight, exaggeration, azimuth, zenith,\n   contrast, brightness, saturation, castShadows);\nMap.addLayer(rgb, {}, ‘DEM (with shadows)’);\nThe final step is to add a topographic colormap. To visualize topographic information, one often uses special topographic colormaps. Here we’ll use the oleron colormap from crameri. The colors get mixed with the shadows using the hillshadeRGB function. As you can see in Fig. F6.0.14, this gives a nice overview of the terrain. The area colored in blue is located below sea level.\nvar palettes = require(‘users/gena/packages:palettes’);\nvar palette = palettes.crameri.oleron[50];\nvar demRGB = dem.visualize({\n   min: -5,\n   max: 5,\n   palette: palette\n});\nvar castShadows = true;\nvar rgb = utils.hillshadeRGB(\n   demRGB, dem, weight, exaggeration, azimuth, zenith,\n   contrast, brightness, saturation, castShadows);\nMap.addLayer(rgb, {}, ‘DEM colormap’);\nSteps to further improve a terrain visualization include using light sources from multiple directions. This allows the user to render terrain to appear more natural. In the real world light is often scattered by clouds and other reflections.\nOne can also use lights to emphasize certain regions. To use even more advanced lighting techniques one can use a raytracing engine, such as the R rayshader library, as discussed earlier in this chapter. The raytracing engine in the Blender 3D program is also capable of producing stunning terrain visualizations using physical-based rendering, mist, environment lights, and camera effects such as depth of field.\n\n\nFigure F6.0.14 Hillshading with shadows\nSteps in visualizing a topographic dataset:\n\nTop left, topography with grayscale colormap\nTop middle, topography with grayscale colormap and hillshading\nTop right, topography with grayscale colormap, hillshading, and shadows\nBottom, topography with topographic colormap, hillshading, and shadows\n\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F60j. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F6.html#synthesis",
    "href": "F6.html#synthesis",
    "title": "7  Advanced Topics",
    "section": "Synthesis",
    "text": "Synthesis\nTo synthesize what you have learned in this chapter, you can do the following assignments.\nAssignment 1. Experiment with different color palettes from the palettes library. Try combining palettes with image opacity (using ee.Image.updateMask call) to visualize different physical features (for example, hot or cold areas using temperature and elevation).\nAssignment 2. Render multiple text annotations when generating animations using image collection. For example, show other image properties in addition to date or image statistics generated using regional reducers for every image.\nAssignment 3. In addition to text annotations, try blending geometry elements (lines, polygons) to highlight specific areas of rendered images."
  },
  {
    "objectID": "F6.html#conclusion",
    "href": "F6.html#conclusion",
    "title": "7  Advanced Topics",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter we have learned about several techniques that can greatly improve visualization and analysis of images and image collections. Using predefined palettes can help to better comprehend and communicate Earth observation data, and combining with other visualization techniques such as hillshading and annotations can help to better understand processes studied with Earth Engine. When working with image collections, it is often very helpful to analyze their properties through time by visualizing them as animations. Usually, this step helps to better understand dynamics of the changes that are stored in image collections and to develop a proper algorithm to study these changes."
  },
  {
    "objectID": "F6.html#references",
    "href": "F6.html#references",
    "title": "7  Advanced Topics",
    "section": "References",
    "text": "References\nBurrough PA, McDonnell RA, Lloyd CD (2015) Principles of Geographical Information Systems. Oxford University Press\nCrameri F, Shephard GE, Heron PJ (2020) The misuse of colour in science communication. Nat Commun 11:1–10. https://doi.org/10.1038/s41467-020-19160-7\nImhof E (2015) Cartographic Relief Presentation. Walter de Gruyter GmbH & Co KG\nLhermitte S, Sun S, Shuman C, et al (2020) Damage accelerates ice shelf instability and mass loss in Amundsen Sea Embayment. Proc Natl Acad Sci USA 117:24735–24741. https://doi.org/10.1073/pnas.1912890117\nThyng KM, Greene CA, Hetland RD, et al (2016) True colors of oceanography. Oceanography 29:9–13\nWikipedia (2022) Terrain cartography. https://en.wikipedia.org/wiki/Terrain_cartography#Shaded_relief. Accessed 1 Apr 2022\nWikipedia (2022) HSL and HSV. https://en.wikipedia.org/wiki/HSL_and_HSV. Accessed 1 Apr 2022\nWild CT, Alley KE, Muto A, et al (2022) Weakening of the pinning point buttressing Thwaites Glacier, West Antarctica. Cryosphere 16:397–417. https://doi.org/10.5194/tc-16-397-2022\nWilkinson L (2005) The Grammar of Graphics. Springer Verlag"
  },
  {
    "objectID": "F6.html#author-1",
    "href": "F6.html#author-1",
    "title": "7  Advanced Topics",
    "section": "Author",
    "text": "Author\nSabrina H. Szeto"
  },
  {
    "objectID": "F6.html#overview-1",
    "href": "F6.html#overview-1",
    "title": "7  Advanced Topics",
    "section": "Overview",
    "text": "Overview\nMany users find themselves needing to collaborate with others in Earth Engine at some point. Students may need to work on a group project, people from different organizations might want to collaborate on research together, or people may want to share a script or an asset they created with others. This chapter will show you how to collaborate with others and share your work."
  },
  {
    "objectID": "F6.html#learning-outcomes-1",
    "href": "F6.html#learning-outcomes-1",
    "title": "7  Advanced Topics",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUnderstanding when it is important to share a script or asset.\nUnderstanding what roles and permission options are available.\nSharing a script with others.\nSharing an asset with others.\nSharing an asset so it can be displayed in an app.\nSharing a repository with others.\nSeeing who made changes to a script and what changes were made.\nReverting to a previous version of a script.\nUsing the require function to load modules.\nCreating a script to share as a module."
  },
  {
    "objectID": "F6.html#assumes-you-know-how-to-1",
    "href": "F6.html#assumes-you-know-how-to-1",
    "title": "7  Advanced Topics",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nSign up for an Earth Engine account, open the Code Editor, and save your script (Chap. F1.0)."
  },
  {
    "objectID": "F6.html#introduction-to-theory-1",
    "href": "F6.html#introduction-to-theory-1",
    "title": "7  Advanced Topics",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nMany people find themselves needing to share a script when they encounter a problem; they wish to share the script with someone else so they can ask a question. When this occurs, sharing a link to the script often suffices. The other person can then make comments or changes before sending a new link to the modified script.\nIf you have included any assets from the Asset Manager in your script, you will also need to share these assets in order for your script to work for your colleague. The same goes for sharing assets to be displayed in an app.\nAnother common situation involves collaborating with others on a project. They may have some scripts they have written that they want to reuse or modify for the new project. Alternatively, several people might want to work on the same script together. For this situation, sharing a repository would be the best way forward; team members will be able to see who made what changes to a script and even revert to a previous version.\nIf you or your group members find yourselves repeatedly reusing certain functions for visualization or for part of your analysis, you could use the require module to call that function instead of having to copy and paste it into a new script each time. You could even make this function or module available to others to use via require.\nLet’s get started. For this lab, you will need to work in small groups or pairs."
  },
  {
    "objectID": "F6.html#using-get-link-to-share-a-script",
    "href": "F6.html#using-get-link-to-share-a-script",
    "title": "7  Advanced Topics",
    "section": "9.1 Using Get Link to Share a Script",
    "text": "9.1 Using Get Link to Share a Script\nCopy and paste the following code into the Code Editor.\nprint(‘The author of this script is MyName.’);\nReplace MyName with your name, then click on Save to save the script in your home repository. Next, click on the Get Link button and copy the link to this script onto your clipboard. Using your email program of choice, send this script to one of your group members.\nNow add the following code below the line of code that you pasted earlier.\nprint(‘I just sent this script to GroupMemberName.’);\nReplace GroupMemberName with the name of the person you sent this script to, then save the script again. Next, click on the Get Link button and copy the link to this script onto your clipboard. Using your email program of choice, send this script to the same person.\nQuestion 1. You should also have received two emails from someone in your group who is also doing this exercise. Open the first and second links in your Code Editor by clicking on them. Is the content of both scripts the same?\nAnswer: No, the scripts will be different, because Get Link sends a snapshot of the script at a particular point in time. Thus, even though the script was updated, the first link does not reflect that change.\nQuestion 2. What happens when you check the box for Hide code panel or Disable auto-run before sharing the script?\nAnswer. Hide code panel will minimize the code panel so the person you send the script to will see the Map maximized. This is useful when you want to draw the person’s attention to the results rather than to the code. To expand the code panel, they have to click on the Show code button. Disable auto-run is helpful when you do not want the script to start running when the person you sent it to opens it. Perhaps your script takes very long to run or requires particular user inputs and you just want to share the code with the person."
  },
  {
    "objectID": "F6.html#sharing-assets-from-your-asset-manager",
    "href": "F6.html#sharing-assets-from-your-asset-manager",
    "title": "7  Advanced Topics",
    "section": "9.2 Sharing Assets from Your Asset Manager",
    "text": "9.2 Sharing Assets from Your Asset Manager\nWhen you clicked the Get Link button earlier, you may have noticed a note in the popup reading: “To give others access to assets in the code snapshot, you may need to share them.” If your script uses an asset that you have uploaded into your Asset Manager, you will need to share that asset as well. If not, an error message will appear when the person you shared the script with tries to run it.\nBefore sharing an asset, think about whether you have permission to share it. Is this some data that is owned by you, or did you get it from somewhere else? Do you need permission to share this asset? Make sure you have the permission to share an asset before doing so.\nNow, let’s practice sharing assets. First, navigate to your Asset Manager by clicking on the Assets tab in the left panel. If you already have some assets uploaded, pick one that you have permission to share. If not, upload one to your Asset Manager. If you don’t have a shapefile or raster to upload, you can upload a small text file. Consult the Earth Engine documentation for how to do this; it will take only a few steps.\nHover your cursor over that asset in your Asset Manager. The asset gets highlighted in gray and three buttons appear to the right of the asset. Click on the first button from the left (outlined in red in Fig. F6.1.1). This icon means “share.”\n\nFig. F6.1.1 Three assets in the Asset Manager\nAfter you click the share button, a Share Image popup will appear (Fig. F6.1.2). This popup contains information about the path of the asset and the email address of the owner. The owner of the asset can decide who can view and edit the asset.\nClick on the dropdown menu outlined in red in Fig. F6.1.2. You will see two options for permissions: Reader and Writer. A Reader can view the asset, while a Writer can both view and make changes to it. For example, a Writer could add a new image to an ImageCollection. A Writer can also add other people to view or edit the asset, and a Writer can delete the asset. When in doubt, give someone the Reader role rather than the Writer role.\n\nFig. F6.1.2 The Share Image popup window\nTo share an asset with someone, you can type their email address into the Email or domain text field, choose Reader or Writer in the dropdown menu, and then click on Add Access. You can also share an asset with everyone with a certain email domain, which is useful if you want to share an asset with everyone in your organization, for instance.\nIf you want to share reading access publicly, then check the box that says Anyone can read. Note that you still need to share the link to the asset in order for others to access it. The only exceptions to this are when you are using the asset in a script and sharing that script using the Get Link button or when you share the asset with an Earth Engine app. To do the latter, use the Select an app dropdown menu (outlined in orange in Fig. F6.1.2) and click Add App Access.\nQuestion 3. Share an asset with a group member and give them reader access. Send them the link to that asset. You will also receive a link from someone else in your group. Open that link. What can you do with that asset? What do you need to do to import it into a script?\nAnswer: You can view details about the asset and import it for use in a script in the Code Editor. To import the asset, click on the blue Import button.\nQuestion 4. Share an asset with a group member and give them writer access. Send them the link to that asset. You will also receive a link from someone else in your group. Open that link. What can you do with that asset? Try sharing the asset with a different group member.\nAnswer: You can view details about the asset and import it for use in a script in the Code Editor. You can also share the asset with others and delete the asset."
  },
  {
    "objectID": "F6.html#working-with-shared-repositories",
    "href": "F6.html#working-with-shared-repositories",
    "title": "7  Advanced Topics",
    "section": "9.3 Working with Shared Repositories",
    "text": "9.3 Working with Shared Repositories\nNow that you know how to share assets and scripts, let’s move on to sharing repositories. In this section, you will learn about different types of repositories and how to add a repository that someone else shared with you. You will also learn how to view previous versions of a script and how to revert back to an earlier version.\nEarlier, we learned how to share a script using the Get Link button. This link shares a code snapshot from a script. This snapshot does not reflect any changes made to the script after the time the link was shared. If you want to share a script that updates to reflect the most current version when it is opened, you need to share a repository with that script instead.\nIf you look under the Scripts tab of the leftmost panel in the Code Editor, you will see that the first three categories are labeled Owner, Reader, and Writer.\n\nRepositories categorized under Owner are created and owned by you. No one else has access to view or make changes to them until you share these repositories.\nRepositories categorized under Reader are repositories to which you have reader access. You can view the scripts but not make any changes to them. If you want to make any changes, you will need to save the script as a new file in a repository that you own.\nRepositories categorized under Writer are repositories to which you have writer access. This means you can view and make changes to the scripts.\n\nLet’s practice creating and sharing repositories. We will start by making a new repository. Click on the red New button located in the left panel. Select Repository from the dropdown menu. A New repository popup window will open (Fig. F6.1.3).\n\nFig. F6.1.3 The New repository popup window\nIn the popup window’s text field, type a name for your new repository, such as “ForSharing1,” then click on the blue Create button. You will see the new repository appear under the Owner category in the Scripts tab (Fig. F6.1.4).\nNow, share this new repository with your group members: Hover your cursor over the repository you want to share. The repository gets highlighted in gray, and three buttons appear. Click on the Gear icon (outlined in red in Fig. F6.1.4).\n\nFig. F6.1.4 Three repositories under the Owner category\nA Share Repo popup window appears (Fig. F6.1.5) which is very similar to the Share Image popup window we saw in Fig. F6.1.2. The method for sharing a repository with a specific user or the general public is the same as for sharing assets.\nType the email address of a group member in the Email or domain text field and give this person a writer role by selecting Writer in the dropdown menu, then click on Add Access. \n\nFig. F6.1.5. The Share Repo popup window\nYour group member should receive an email inviting them to edit the repository. Check your email inbox for the repository that your group member has shared with you. When you open that email, you will see content similar to what is shown in Fig. F6.1.6.\n\nFig. F6.1.6 The “Invitation to edit” email\nNow, click on the blue button that says Add [repository path] to your Earth Engine Code Editor. You will find the new repository added to the Writer category in your Scripts tab. The repository path will contain the username of your group member, such as users/username/sharing.\nNow, let’s add a script to the empty repository. Click on the red New button in the Scripts tab and select File from the dropdown menu. A Create file popup will appear, as shown in Fig. F6.1.7. Click on the gray arrow beside the default path to open a dropdown menu that will allow you to choose the path of the repository that your group member shared with you. Type a new File Name in the text field, such as “exercise,” then click on the blue OK button to create the file.\n\nFig. F6.1.7 The Create file popup window\nA new file should now appear in the shared repository in the Writer category. If you don’t see it, click on the Refresh icon, which is to the right of the red New button in the Scripts tab.\nDouble-click on the new script in the shared repository to open it. Then, copy and paste the following code to your Code Editor.\nprint(‘The owner of this repository is GroupMemberName.’);\nReplace GroupMemberName with the name of your group member, then click Save to save the script in the shared repository, which is under the Writer category.\nNow, navigate to the repository under Owner which you shared with your group member. Open the new script which they just created by double-clicking it.\nAdd the following code below the line of code that you pasted earlier.\nprint(‘This script is shared with MyName.’);\nReplace MyName with your name, then save the script.\nNext, we will compare changes made to the script. Click on the Versions icon (outlined in red in Fig. F6.1.8).\n\nFig. F6.1.8 Changes made and previous versions of the script\nA popup window will appear, titled Revision history, followed by the path of the script (Fig. F6.1.9). There are three columns of information below the title.\n\nThe left column contains the dates on which changes have  been made.\nThe middle column contains the usernames of the people who made changes.\nThe right column contains information about what changes were made.  \n\nThe most recent version of the script is shown in the first row, while previous versions are listed in subsequent rows. (More advanced users may notice that this is actually a Git repository.)\n\nFig. F6.1.9 The Revision history popup window\nIf you hover your cursor over a row, the row will be highlighted in gray and a button labeled Compare will appear. Clicking on this button allows you to compare differences between the current version of the script and a previous version in a Version comparison popup window (Fig. F6.1.10).\n\nFig. F6.1.10 The Version comparison popup window\nIn the Version comparison popup, you will see text highlighted in two different colors. Text highlighted in red shows code that was present in the older version but is absent in the current version (the “latest commit”). Text highlighted in green shows code that is present in the current version but that was absent in the older version. Generally speaking, text highlighted in red has been removed in the current version and text highlighted in green has been added to the current version. Text that is not highlighted shows code that is present in both versions.\nQuestion 5. What text, if any, is highlighted in red when you click on Compare in your “exercise” script?\nAnswer: No text is highlighted in red, because none was removed between the previous and current versions of the script.\nQuestion 6. What text, if any, is highlighted in green when you click on Compare in your “exercise” script?\nAnswer: print(‘This script is shared with MyName.’);\nQuestion 7. What happens when you click on the blue Revert button?\nAnswer: The script reverts to the previous version, in which the only line of code is\nprint(‘The owner of this repository is GroupMemberName.’);"
  },
  {
    "objectID": "F6.html#using-the-require-function-to-load-a-module",
    "href": "F6.html#using-the-require-function-to-load-a-module",
    "title": "7  Advanced Topics",
    "section": "9.4 Using the Require Function to Load a Module",
    "text": "9.4 Using the Require Function to Load a Module\nIn earlier chapters, you may have noticed that the require function allows you to reuse code that has already been written without having to copy and paste it into your current script. For example, you might have written a function for cloud masking that you would like to use in multiple scripts. Saving this function as a module enables you to share the code across your own scripts and with other people. Or you might discover a new module with capabilities you need written by other authors. This section will show you how to use the require function to create and share your own module or to load a module that someone else has shared.\nThe module we will use is ee-palettes, which enables users to visualize raster data using common specialized color palettes (Donchyts et al. 2019). (If you would like to learn more about using these color palettes, the ee-palettes module is described and illustrated in detail in Chap. F6.0.) The first step is to go to this link to accept access to the repository as a reader: https://code.earthengine.google.com/?accept_repo=users/gena/packages \nNow, if you navigate to your Reader directory in the Code Editor, you should see a new repository called ‘users/gena/packages’ listed. Look for a script called ‘palettes’ and click on it to load it in your Code Editor.\nIf you scroll down, you will see that the script contains a nested series of dictionaries with lists of hexadecimal color specifications (as described in Chap. F2.1) that describe a color palette, as shown in the code block below. For example, the color palette named “Algae” stored in the cmocean variable consists of seven colors, ranging from dark green to light green (Fig. F6.1.11).\nexports.cmocean = {\n   Thermal: {       7: [‘042333’, ‘2c3395’, ‘744992’, ‘b15f82’, ‘eb7958’,           ‘fbb43d’, ‘e8fa5b’       ]\n   },\n   Haline: {       7: [‘2a186c’, ‘14439c’, ‘206e8b’, ‘3c9387’, ‘5ab978’,           ‘aad85c’, ‘fdef9a’       ]\n   },\n   Solar: {       7: [‘331418’, ‘682325’, ‘973b1c’, ‘b66413’, ‘cb921a’,           ‘dac62f’, ‘e1fd4b’       ]\n   },\n   Ice: {       7: [‘040613’, ‘292851’, ‘3f4b96’, ‘427bb7’, ‘61a8c7’,           ‘9cd4da’, ‘eafdfd’       ]\n   },\n   Gray: {       7: [‘000000’, ‘232323’, ‘4a4a49’, ‘727171’, ‘9b9a9a’,           ‘cacac9’, ‘fffffd’       ]\n   },\n   Oxy: {       7: [‘400505’, ‘850a0b’, ‘6f6f6e’, ‘9b9a9a’, ‘cbcac9’,           ‘ebf34b’, ‘ddaf19’       ]\n   },\n   Deep: {       7: [‘fdfecc’, ‘a5dfa7’, ‘5dbaa4’, ‘488e9e’, ‘3e6495’,           ‘3f396c’, ‘281a2c’       ]\n   },\n   Dense: {       7: [‘e6f1f1’, ‘a2cee2’, ‘76a4e5’, ‘7871d5’, ‘7642a5’,           ‘621d62’, ‘360e24’       ]\n   },\n   Algae: {       7: [‘d7f9d0’, ‘a2d595’, ‘64b463’, ‘129450’, ‘126e45’,           ‘1a482f’, ‘122414’       ]\n   },\n   …\n}\nNotice that the variable is named exports.cmocean. Adding exports to the name of a function or variable makes it available to other scripts to use, as it gets added to a special global variable (Chang 2017).\n\nFig. F6.1.11 Some of the color palettes from the ee-palettes GitHub repository\nTo see all the color palettes available in this module, go to https://github.com/gee-community/ee-palettes.\nNow let’s try using the ee-palettes module. Look for a script in the same repository called ‘palettes-test’ and click on it to load it in your Code Editor. When you run the script, you will see digital elevation data from the National Aeronautics and Space Administration Shuttle Radar Topography Mission satellite visualized using two palettes,  colorbrewer.Blues and cmocean.Algae. The map will have two layers that show the same data with different palettes.\nThe script first imports the digital elevation model data in the Imports section of the Code Editor.\nvar dem = ee.Image(‘USGS/SRTMGL1_003’);\nThe script then loads the ee-palettes module by using the require function. The path to the module, ‘users/gena/packages:palettes’, is passed to the function. The require function is then stored in a variable named ‘palettes’, which will be used later to obtain the palettes for data visualization.\nvar palettes = require(‘users/gena/packages:palettes’);\nAs described by Donchyts et al. (2019), “Each palette is defined by a group and a name, which are separated by a period (JS object dot notation), and a color level. To retrieve a desired palette, use JS object notation to specify the group, name, and number of color levels.” We define the color palette Algae as palettes.cmocean.Algae[7] because it is part of the group cmocean and has 7 color levels. In the next code block, you can see that the palettes (i.e., lists of hex colors) have been defined for use by setting them as the value for the palette key in the visParams object supplied to the Map.addLayer function.\n// colorbrewer\nMap.addLayer(dem, {\n   min: 0,\n   max: 3000,\n   palette: palettes.colorbrewer.Blues[9]\n}, ‘colorbrewer Blues[9]’);\n// cmocean\nMap.addLayer(dem, {\n   min: 0,\n   max: 3000,\n   palette: palettes.cmocean.Algae[7]\n}, ‘cmocean Algae[7]’);\nQuestion 8. Try adding a third layer to the Map with a different color palette from ee-palettes. How easy was it to do?\nNow that you have loaded and used a module shared by someone else, you can try your hand at creating your own module and sharing it with someone else in your group. First, go to the shared repository that you created in Sect. 3, create a new script in that repository, and name it “cloudmasking.”\nThen, go to the Examples repository at the bottom of the Scripts tab and select a function from the Cloud Masking repository. Let’s use the Landsat8 Surface Reflectance cloud masking script as an example. In that script, you will see the code shown in the block below. Copy all of it into your empty script.  \n// This example demonstrates the use of the Landsat 8 Collection 2, Level 2\n// QA_PIXEL band (CFMask) to mask unwanted pixels.\nfunction maskL8sr(image) {   // Bit 0 - Fill   // Bit 1 - Dilated Cloud   // Bit 2 - Cirrus   // Bit 3 - Cloud   // Bit 4 - Cloud Shadow   var qaMask = image.select(‘QA_PIXEL’).bitwiseAnd(parseInt(‘11111’,       2)).eq(0);   var saturationMask = image.select(‘QA_RADSAT’).eq(0);   // Apply the scaling factors to the appropriate bands.   var opticalBands = image.select(‘SR_B.’).multiply(0.0000275).add(-       0.2);   var thermalBands = image.select(’ST_B.*’).multiply(0.00341802)\n       .add(149.0);   // Replace the original bands with the scaled ones and apply the masks.   return image.addBands(opticalBands, null, true)\n       .addBands(thermalBands, null, true)\n       .updateMask(qaMask)\n       .updateMask(saturationMask);\n}\n// Map the function over one year of data.\nvar collection = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterDate(‘2020-01-01’, ‘2021-01-01’)\n   .map(maskL8sr);\nvar composite = collection.median();\n// Display the results.\nMap.setCenter(-4.52, 40.29, 7); // Iberian Peninsula\nMap.addLayer(composite, {\n   bands: [‘SR_B4’, ‘SR_B3’, ‘SR_B2’],\n   min: 0,\n   max: 0.3\n});\nNote that this code is well commented and has a header that describes what the script does. Don’t forget to comment your code and describe what you are doing each step of the way. This is a good practice for collaborative coding and for your own future reference.\nImagine that you changed this maskL8sr function slightly for some reason and want to make it available to other users and scripts. To do that, you can turn the function into a module. Copy and modify the code from the example code into the new script you created called “cloudmasking.” (Hint: Store the function in a variable starting with exports. Be careful that you don’t accidentally use Export, which is used to export datasets.)\nYour script should be similar to the following code.\nexports.maskL8sr = function(image) {   // Bit 0 - Fill   // Bit 1 - Dilated Cloud   // Bit 2 - Cirrus   // Bit 3 - Cloud   // Bit 4 - Cloud Shadow   var qaMask = image.select(‘QA_PIXEL’).bitwiseAnd(parseInt(       ‘11111’, 2)).eq(0);   var saturationMask = image.select(‘QA_RADSAT’).eq(0);   // Apply the scaling factors to the appropriate bands.   var opticalBands = image.select(‘SR_B.’).multiply(0.0000275)\n       .add(-0.2);   var thermalBands = image.select(’ST_B.*’).multiply(0.00341802)\n       .add(149.0);   // Replace the original bands with the scaled ones and apply the masks.   return image.addBands(opticalBands, null, true)\n       .addBands(thermalBands, null, true)\n       .updateMask(qaMask)\n       .updateMask(saturationMask);\n}\nNext, you will create a test script that makes use of the cloud masking module you just made. Begin by creating a new script in your shared repository called “cloudmasking-test.” You can modify the last part of the example cloud masking script to use your module.\n// Map the function over one year of data.\nvar collection = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterDate(‘2020-01-01’, ‘2021-01-01’)\n   .map(maskL8sr);\nvar composite = collection.median();\n// Display the results.\nMap.setCenter(-4.52, 40.29, 7); // Iberian Peninsula\nMap.addLayer(composite, {\n   bands: [‘SR_B4’, ‘SR_B3’, ‘SR_B2’],\n   min: 0,\n   max: 0.3\n});\nQuestion 9. How will you modify the cloud masking script to use your module? What does the script look like?\nAnswer: Your code might look something like the code block below.\n// Load the module\nvar myCloudFunctions = require(   ‘users/myusername/my-shared-repo:cloudmasking’);\n// Map the function over one year of data.\nvar collection = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterDate(‘2020-01-01’, ‘2021-01-01’)\n   .map(myCloudFunctions.maskL8sr);\nvar composite = collection.median();\n// Display the results.\nMap.setCenter(-4.52, 40.29, 7); // Iberian Peninsula\nMap.addLayer(composite, {\n   bands: [‘SR_B4’, ‘SR_B3’, ‘SR_B2’],\n   min: 0,\n   max: 0.3\n});"
  },
  {
    "objectID": "F6.html#synthesis-1",
    "href": "F6.html#synthesis-1",
    "title": "7  Advanced Topics",
    "section": "Synthesis",
    "text": "Synthesis\nApply what you learned in this chapter by setting up a shared repository for your project, lab group, or organization. What scripts would you share? What permissions should different users have? Are there any scripts that you would turn into modules?"
  },
  {
    "objectID": "F6.html#conclusion-1",
    "href": "F6.html#conclusion-1",
    "title": "7  Advanced Topics",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned how to collaborate with others in the Earth Engine Code Editor through sharing scripts, assets, and repositories. You learned about different roles and permissions available for sharing and when it is appropriate to use each. In addition, you are now able to see what changes have been made to a script and revert to a previous version. Lastly, you loaded and used a module that was shared with you and created your own module for sharing. You are now ready to start collaborating and developing scripts with others."
  },
  {
    "objectID": "F6.html#references-1",
    "href": "F6.html#references-1",
    "title": "7  Advanced Topics",
    "section": "References",
    "text": "References\nChang A (2017) Making it easier to reuse code with Earth Engine script modules. In: Google Earth and Earth Engine. https://medium.com/google-earth/making-it-easier-to-reuse-code-with-earth-engine-script-modules-2e93f49abb13. Accessed 24 Feb 2022\nDonchyts G, Baart F, Braaten J (2019) ee-palettes. https://github.com/gee-community/ee-palettes. Accessed 24 Feb 2022"
  },
  {
    "objectID": "F6.html#author-2",
    "href": "F6.html#author-2",
    "title": "7  Advanced Topics",
    "section": "Author",
    "text": "Author\nJillian M. Deines, Stefania Di Tommaso, Nicholas Clinton, Noel Gorelick"
  },
  {
    "objectID": "F6.html#overview-2",
    "href": "F6.html#overview-2",
    "title": "7  Advanced Topics",
    "section": "Overview",
    "text": "Overview\nCommonly, when Earth Engine users move from tutorials to developing their own processing scripts, they encounter the dreaded error messages, “computation timed out” or “user memory limit exceeded.” Computational resources are never unlimited, and the team at Earth Engine has designed a robust system with built-in checks to ensure server capacity is available to everyone. This chapter will introduce general tips for creating efficient Earth Engine workflows that accomplish users’ ambitious research objectives within the constraints of the Earth Engine ecosystem. We use two example case studies: 1) extracting a daily climate time series for many locations across two decades, and 2) generating a regional, cloud-free median composite from Sentinel-2 imagery."
  },
  {
    "objectID": "F6.html#learning-outcomes-2",
    "href": "F6.html#learning-outcomes-2",
    "title": "7  Advanced Topics",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUnderstanding constraints on Earth Engine resource use.\nBecoming familiar with multiple strategies to scale Earth Engine operations.\nManaging large projects and multistage workflows.\nRecognizing when using the Python API may be advantageous to execute large batches of tasks."
  },
  {
    "objectID": "F6.html#assumes-you-know-how-to-2",
    "href": "F6.html#assumes-you-know-how-to-2",
    "title": "7  Advanced Topics",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nWrite a function and map it over an ImageCollection (Chap. F4.0).\nExport and import results as Earth Engine assets (Chap. F5.0).\nUnderstand distinctions among Image, ImageCollection, Feature and FeatureCollection Earth Engine objects (Part F1, Part F2, Part F5).\nUse the require function to load code from existing modules (Chap. F6.1)."
  },
  {
    "objectID": "F6.html#introduction-to-theory-2",
    "href": "F6.html#introduction-to-theory-2",
    "title": "7  Advanced Topics",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nParts F1–F5 of this book have covered key remote sensing concepts and demonstrated how to implement them in Earth Engine. Most exercises have used local-scale examples to enhance understanding and complete tasks within a class-length time period. But Earth Engine’s power comes from its scalability—the ability to apply geospatial processing across large areas and many years.\nHow we go from small to large scales is influenced by Earth Engine’s design. Earth Engine runs on many individual computer servers, and its functions are designed to split up processing onto these servers. This chapter focuses on common approaches to implement large jobs within Earth Engine’s constraints. To do so, we first discuss Earth Engine’s underlying infrastructure to provide context for existing limits. We then cover four core concepts for scaling:\n\nUsing best coding practices.\nBreaking up jobs across time.\nBreaking up jobs across space.\nBuilding a multipart workflow and exporting intermediate assets.\n\n\n10.0.1 Earth Engine: Under the Hood\nAs you use Earth Engine, you may begin to have questions about how it works and how you can use that knowledge to optimize your workflow. In general, the inner workings are opaque to users. Typical fixes and approaches that data scientists use to manage memory constraints often don’t apply. It’s helpful to know what users can and cannot control, and how your scripts translate to Earth Engine’s server operations.\nEarth Engine is a parallel, distributed system (see Gorelick et al. 2017), which means that when you submit tasks, it breaks up pieces of your query onto different processors to complete them more efficiently. It then collects the results and returns them to you. For many users, not having to manually design this parallel, distributed processing is a huge benefit. For some advanced users, it can be frustrating to not have better control. We’d argue that leaving the details up to Earth Engine is a huge time-saver for most cases, and learning to work within a few constraints is a good time investment.\nOne core concept useful to master is the relationship between client-side and server-side operations. Client-side operations are performed within your browser (for the JavaScript API Code Editor) or local system (for the Python API). These include things such as manipulating strings or numbers in JavaScript. Server-side operations are executed on Google’s servers and include all of the ee.* functions. By using the Earth Engine APIs—JavaScript or Python—you are building a chain of commands to send to the servers and later receive the result back. As much as possible, you want to structure your code to send all the heavy lifting to Google, and keep processing off of your local resources.\nIn other words, your work in the Code Editor is making a description of a computation. All ee objects are just placeholders for server-side objects—their actual value does not exist locally on your computer. To see or use the actual value, it has to be evaluated by the server. If you print an Earth Engine object, it calls getInfo to evaluate and return the value. In contrast, you can also work with JavaScript/Python lists or numbers locally, and do basic JavaScript/Python things to them, like add numbers together or loop over items. These are client-side objects. Whenever you bring a server-side object into your local environment, there’s a computational cost.\nTable F6.2.1 describes some nuts and bolts about Earth Engine and their implications. Table F6.2.2 provides some of the existing limits on individual tasks.\nTable F6.2.1 Characterics of Google Earth Engine and implications for running large jobs \nEarth Engine characteristics\nImplications\nA parallel, distributed system\nOccasionally, doing the exact same thing in two different orders can result in different processing distributions, impacting the ability to complete the task within system limits.\nMost processing is done per tile (generally a square that is 256 x 256 pixels).\nTasks that require many tiles are the most memory intensive. Some functions have a tileScale argument that reduces tile size, allowing processing-intensive jobs to succeed (at the cost of reduced speed).\nExport mode has higher memory and time allocations than interactive mode.\nIt’s better to export large jobs. You can export to your Earth Engine assets, your Google Drive, or Google Cloud Storage.\nSome operations are cached temporarily.\nRunning the same job twice could result in different run times. Occasionally tasks may run successfully on a second try.\nUnderlying infrastructure is composed of clusters of low-end servers.\nThere’s a hard limit on data size for any individual server; large computations need to be done in parallel using Earth Engine functions.\nThe image processing domain, scale, and projection are defined by the specified output and applied backwards throughout the processing chain.\nThere are not many cases when you will need to manually reproject images, and these operations are costly. Similarly, manually “clipping” images is typically unnecessary.\nTable F6.2.2 Size limits for Earth Engine tasks\nEarth Engine Component\nLimits\nInteractive mode\nCan print up to 5000 records. Computations must finish within five minutes.\nExport mode\nJobs have no time limit as long as they continue to make reasonable progress (defined roughly as 600 seconds per feature, two hours per aggregation, and 10 minutes per tile). If any one tile, feature, or aggregation takes too long, the whole job will get canceled. Any jobs that take longer than one week to run will likely fail due to Earth Engine’s software update release cycles.\nTable assets\nMaximum of 100 million features, 1000 properties (columns), and 100,000 vertices for a geometry.\n\n\n10.0.2 The Importance of Coding Best Practices\nGood code scales better than bad code. But what is good code? Generally, for Earth Engine, good code means 1) using Earth Engine’s server-side operators; 2) avoiding multiple passes through the same image collection; 3) avoiding unnecessary conversions; and 4) setting the processing scale or sample numbers appropriate for your use case, i.e., avoid using very fine scales or large samples without reason.\nWe encourage readers to become familiar with the “Coding Best Practices” page in the online Earth Engine User Guide. This page provides examples for avoiding mixing client- and server-side functions, unnecessary conversions, costly algorithms, combining reducers, and other helpful tips. Similarly, the “Debugging Guide–Scaling Errors” page of the online Earth Engine User Guide covers some common problems and solutions.\nIn addition, some Earth Engine functions are more efficient than others. For example, Image.reduceRegions is more efficient than Image.sampleRegions, because sampleRegions regenerates the geometries under the hood. These types of best practices are trickier to enumerate and somewhat idiosyncratic. We encourage users to learn about and make use of the Profiler tab, which will track and display the resources used for each operation within your script. This can help identify areas to focus efficiency improvements. Note that the profiler itself increases resource use, so only use it when necessary to develop a script and remove it for production-level execution. Other ways to discover best practices include following/posting questions to GIS StackExchange or the Earth Engine Developer’s Discussion Group, swapping code with others, and experimentation."
  },
  {
    "objectID": "F6.html#scaling-across-time",
    "href": "F6.html#scaling-across-time",
    "title": "7  Advanced Topics",
    "section": "10.1 Scaling Across Time",
    "text": "10.1 Scaling Across Time\nIn this section we use an example of extracting climate data at features (points or polygons) to demonstrate how to scale an operation across many features (Sect. 1.1) and how to break up large jobs by time units when necessary (e.g, by years; Sect. 1.2).\n\n10.1.1 1.1. Scaling Up with Earth Engine Operators: Annual Daily Climate Data\nEarth Engine’s operators are designed to parallelize queries on the backend without user intervention. In many cases, they are sufficient to accomplish a scaling operation.\nAs an example, we will extract a daily time series of precipitation, maximum temperature, and minimum temperature for county polygons in the United States. We will use the GRIDMET Climate Reanalysis product (Abatzoglou 2013), which provides daily, 4000 m resolution gridded meteorological data from 1979 to the present across the contiguous United States. To save time for this practicum, we will focus on the states of Indiana, Illinois, and Iowa in the central United States, which together include 293 counties (Fig. F6.2.1).\n\nFig. F6.2.1 Map of study area, showing 293 county features within the states of Iowa, Illinois, and Indiana in the United States\nThis example uses the ee.Image.reduceRegions operator, which extracts statistics from an Image for each Feature (point or polygon) in a FeatureCollection. We will map the reduceRegions operator over each daily image in an ImageCollection, thus providing us with the daily climate information for each county of interest.\nNote that although our example uses a climate ImageCollection, this approach transfers to any ImageCollection, including satellite imagery, as well as image collections that you have already processed, such as cloud masking (Chap. F4.3) or time series aggregation (Chap. F4.2).\nFirst, define the FeatureCollection, ImageCollection, and time period:\n// Load county dataset.\n// Filter counties in Indiana, Illinois, and Iowa by state FIPS code.\n// Select only the unique ID column for simplicity.\nvar countiesAll = ee.FeatureCollection(‘TIGER/2018/Counties’);\nvar states = [‘17’, ‘18’, ‘19’];\nvar uniqueID = ‘GEOID’;\nvar featColl = countiesAll.filter(ee.Filter.inList(‘STATEFP’, states))\n   .select(uniqueID);\nprint(featColl.size());\nprint(featColl.limit(1));\n// Visualize target features (create Figure F6.2.1).\nMap.centerObject(featColl, 5);\nMap.addLayer(featColl);\n// specify years of interest\nvar startYear = 2020;\nvar endYear = 2020;\n// climate dataset info\nvar imageCollectionName = ‘IDAHO_EPSCOR/GRIDMET’;\nvar bandsWanted = [‘pr’, ‘tmmn’, ‘tmmx’];\nvar scale = 4000;\nPrinting the size of the FeatureCollection indicates that there are 293 counties in our subset. Since we want to pull a daily time series for one year, our final dataset will have 106,945 rows—one for each county-day.\nNote that from our county FeatureCollection, we select only the GEOID column, which represents a unique identifier for each record in this dataset. We do this here to simplify print outputs; we could also specify which properties to include in the export function (see below).\nNext, load and filter the climate data. Note we adjust the end date to January 1 of the following year, rather than December 31 of the specified year, since the filterDate function has an inclusive start date argument and an exclusive end date argument; without this modification the output would lack data for December 31.\n// Load and format climate data.\nvar startDate = startYear + ‘-01-01’;\nvar endYear_adj = endYear + 1;\nvar endDate = endYear_adj + ‘-01-01’;\nvar imageCollection = ee.ImageCollection(imageCollectionName)\n   .select(bandsWanted)\n   .filterBounds(featColl)\n   .filterDate(startDate, endDate);\nNow get the mean value for each climate attribute within each county feature. Here, we map the ee.Image.reduceRegions call over the ImageCollection, specifying an ee.Reducer.mean reducer. The reducer will apply to each band in the image, and it returns the FeatureCollection with new properties. We also add a ‘date_ymd’ time property extracted from the image to correctly associate daily values with their date. Finally, we flatten the output to reform a single FeatureCollection with one feature per county-day.\n// get values at features\nvar sampledFeatures = imageCollection.map(function(image) {   return image.reduceRegions({\n           collection: featColl,\n           reducer: ee.Reducer.mean(),\n           scale: scale\n       }).filter(ee.Filter.notNull(\n       bandsWanted)) // drop rows with no data       .map(function(f) { // add date property           var time_start = image.get(               ‘system:time_start’);           var dte = ee.Date(time_start).format(               ‘YYYYMMdd’);           return f.set(‘date_ymd’, dte);\n       });\n}).flatten();\nprint(sampledFeatures.limit(1));\nNote that we include a filter to remove feature-day rows that lacked data. While this is less common when using gridded climate products, missing data can be common when reducing satellite images. This is because satellite collections come in scene tiles, and each image tile likely does not overlap all of our features unless it has first been aggregated temporally. It can also occur if a cloud mask has been applied to an image prior to the reduction. By filtering out null values, we can reduce empty rows.\nNow explore the result. If we simply print(sampledFeatures) we get our first error message: “User memory limit exceeded.” This is because we’ve created a FeatureCollection that exceeds the size limits set for interactive mode. How many are there? We could try print(sampledFeatures.size()), but due to the larger size, we receive a “Computation timed out” message—it’s unable to tell us. Of course, we know that we expect 293 counties x 365 days = 106,945 features. We can, however, check that our reducer has worked as expected by asking Earth Engine for just one feature: print(sampledFeatures.limit(1)).\n\nFig. F6.2.2 Screenshot of the print output for one feature after the reduceRegions call\nHere, we can see the precipitation, minimum temperature, and maximum temperature for the county with GEOID = 17121 on January 1, 2020 (Fig. F6.2.2; note temperature is in Kelvin units).\nNext, export the full FeatureCollection as a CSV to a folder in your Google Drive. Specify the names of properties to include. Build part of the filename dynamically based on arguments used for year and data scale, so we don’t need to manually modify the filenames.\n// export info\nvar exportFolder = ‘GEE_scalingUp’;\nvar filename = ‘Gridmet_counties_IN_IL_IA_’ + scale + ‘m_’ +\n   startYear + ‘-’ + endYear;// prepare export: specify properties/columns to include\nvar columnsWanted = [uniqueID].concat([‘date_ymd’], bandsWanted);\nprint(columnsWanted);\nExport.table.toDrive({\n   collection: sampledFeatures,\n   description: filename,\n   folder: exportFolder,\n   fileFormat: ‘CSV’,\n   selectors: columnsWanted\n});\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F62a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nOn our first export, this job took about eight minutes to complete, producing a dataset 6.8 MB in size. The data is ready for downstream use but may need formatting to suit the user’s goals. You can see what the exported CSV looks like in Fig. F6.2.3.\n\nFig. F6.2.3 Top six rows of the exported CSV viewed in Microsoft Excel and sorted by county GEOID \nUsing the Selectors Argument\nThere are two excellent reasons to use the selectors argument in your Export.table.toDrive call. First, if the argument is not specified, Earth Engine will generate the column names for the exported CSV from the first feature in your FeatureCollection. If that feature is missing properties, those properties will be dropped from the export for all features.\nPerhaps even more important if you are seeking to scale up an analysis, including unnecessary columns can greatly increase file size and even processing time. For example, Earth Engine includes a .geo field that contains a GeoJSON description of each spatial feature. For non-simple geometries, the field can be quite large, as it lists coordinates for each polygon vertex. For many purposes, it’s not necessary to include this information for each daily record (here, 365 daily rows per feature).\nFor example, when we ran the same job as above but did not use the selectors argument, the output dataset was 5.7 GB (versus 6.8 MB!) and the runtime was slower. This is a cumbersomely large file, with no real benefit. We generally recommend dropping the .geo column and other unnecessary properties. To retain spatial information, a unique identifier for each feature can be used for downstream joins with the spatial data or other properties. If working with point data, latitude and longitude columns can be added prior to export to maintain easily accessible geographic information, although the .geo column for point data is far smaller than for irregularly shaped polygon features.\n\n\n10.1.2 1.2. Scaling Across Time by Batching: Get 20 Years of Daily Climate Data\nAbove, we extracted one year of daily data for our 293 counties. Let’s say we want to do the same thing, but for 2001–2020. We have already written our script to flexibly specify years, so it’s fairly adaptable to this new use case:\n// specify years of interest\nvar startYear = 2020;\nvar endYear = 2020;\nIf we only wanted a few years for a small number of features, we could just modify the startYear or endYear and proceed. Indeed, our current example is modest in size and number of features, and we were able to run 2001–2020 in one export job that took about two hours, with an output file size of 299 MB. However, with larger feature collections, or hourly data, we will again start to bump up against Earth Engine’s limits. Generally, jobs of this sort do not fail quickly—exports are allowed to run as long as they continue making progress (see Table F6.2.2). It’s not uncommon, however, for a large job to take well over 24 hours to run, or even to fail after more than 24 hours of run time, as it accumulates too many records or a single aggregation fails. For users, this can be frustrating.\nWe generally find it simpler to run several small jobs rather than one large job. Outputs can then be combined in external software. This avoids any frustration with long-running jobs or delayed failures, and it allows parts of the task to be run simultaneously. Earth Engine generally executes from 2–20 jobs per user at a time, depending on overall user load (although 20 is rare). As a counterpart, there is some overhead for generating separate jobs.\nImportant note: When running a batch of jobs, it may be tempting to use multiple accounts to execute subsets of your batch and thus get your shared results faster. However, doing so is a direct violation of the Earth Engine terms of service and can result in your account(s) being terminated.\nFor-Loops: They Are Sometimes OK\nBatching jobs in time is a great way to break up a task into smaller units. Other options include batching jobs by spatial regions defined by polygons (see Sect. 2), or for computationally heavy tasks, batching by both space and time.\nBecause Export functions are client-side functions, however, you can’t create an export within an Earth Engine map command. Instead, we need to loop over the variable that will define our batches and create a set of export tasks.\nBut wait! Aren’t we supposed to avoid for-loops at all costs? Yes, within a computational chain. Here, we are using a loop to send multiple computational chains to the server.\nFirst, we will start with the same script as in Sect. 1.1, but we will modify the start year. We will also modify the desired output filename to be a generic base filename, to which we will append the year for each task within the loop (in the next step).\n// Load county dataset.\nvar countiesAll = ee.FeatureCollection(‘TIGER/2018/Counties’);\nvar states = [‘17’, ‘18’, ‘19’];\nvar uniqueID = ‘GEOID’;\nvar featColl = countiesAll.filter(ee.Filter.inList(‘STATEFP’, states))\n   .select(uniqueID);\nprint(featColl.size());\nprint(featColl.limit(1));\nMap.addLayer(featColl);\n// Specify years of interest.\nvar startYear = 2001;\nvar endYear = 2020;\n// Climate dataset info.\nvar imageCollectionName = ‘IDAHO_EPSCOR/GRIDMET’;\nvar bandsWanted = [‘pr’, ‘tmmn’, ‘tmmx’];\nvar scale = 4000;\n// Export info.\nvar exportFolder = ‘GEE_scalingUp’;\nvar filenameBase = ‘Gridmet_counties_IN_IL_IA_’ + scale + ‘m_’;\nNow modify the code in Sect. 1.1 to use a looping variable, i, to represent each year. Here, we are using standard JavaScript looping syntax, where i will take on each value between our startYear (2001) and our endYear (2020) for each loop through this section of code, thus creating 20 queries to send to Earth Engine’s servers.\n// Initiate a loop, in which the variable i takes on values of each year.\nfor (var i = startYear; i <= endYear; i++) {        // for each year….  // Load climate collection for that year. var startDate = i + ‘-01-01’;\n  var endYear_adj = i + 1; var endDate = endYear_adj + ‘-01-01’; var imageCollection = ee.ImageCollection(imageCollectionName)\n     .select(bandsWanted)\n     .filterBounds(featColl)\n     .filterDate(startDate, endDate); // Get values at feature collection. var sampledFeatures = imageCollection.map(function(image) {   return image.reduceRegions({\n     collection: featColl,\n     reducer: ee.Reducer.mean(),        \n     tileScale: 1,\n     scale: scale\n   }).filter(ee.Filter.notNull(bandsWanted))  // remove rows without data     .map(function(f) {                  // add date property       var time_start = image.get(‘system:time_start’);       var dte = ee.Date(time_start).format(‘YYYYMMdd’);       return f.set(‘date_ymd’, dte);\n   });\n }).flatten(); // Prepare export: specify properties and filename. var columnsWanted = [uniqueID].concat([‘date_ymd’], bandsWanted); var filename = filenameBase + i; Export.table.toDrive({\n   collection: sampledFeatures,\n   description: filename,\n   folder: exportFolder,\n   fileFormat: ‘CSV’,\n   selectors: columnsWanted\n });\n \n}\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F62b. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nWhen we run this script, it builds our computational query for each year, creating a batch of 20 individual jobs that will show up in the Task pane (Fig. F6.2.4). Each task name includes the year, since we used our looping variable i to modify the base filename we specified.\n\nFig. F6.2.4 Creation of batch tasks for each year\nWe now encounter a downside to creating batch tasks within the JavaScript Code Editor: we need to click Run to execute each job in turn. Here, we made this easier by programmatically assigning each job the filename we want, so we can hold the Cmd/Ctrl key and click Run to avoid the export task option window and only need to click once per task. Still, one can imagine that at some number of tasks, one’s patience for clicking Run will be exceeded. We assume that number is different for everyone.\nNote: If at any time you have submitted several tasks to the server but want to cancel them all, you can do so more easily from the Earth Engine Task Manager that is linked at the top of the Task pane. You can read about that task manager in the Earth Engine User Guide.\nIn order to auto-execute jobs in batch mode, we’d need to use the Python API. Interested users can see the Earth Engine User Guide Python API tutorial for further details about the Python API."
  },
  {
    "objectID": "F6.html#scaling-across-space-via-spatial-tiling",
    "href": "F6.html#scaling-across-space-via-spatial-tiling",
    "title": "7  Advanced Topics",
    "section": "10.2 Scaling Across Space via Spatial Tiling",
    "text": "10.2 Scaling Across Space via Spatial Tiling\nBreaking up jobs in space is another key strategy for scaling operations in Earth Engine. Here, we will focus on making a cloud-free composite from the Sentinel-2 Level 2A Surface Reflectance product. The approach is similar to that in Chap. F4.3, which explores cloud-free compositing. The main difference is that Landsat scenes come with a reliable quality band for each scene, whereas the process for Sentinel-2 is a bit more complicated and computationally intense (see below).\nOur region of interest is the state of Washington in the United States for demonstration purposes, but the method will work at much larger continental scales as well.\nCloud Masking Approach\nWhile we do not intend to cover the theory behind Sentinel-2 cloud masking, we do want to include a brief description of the process to convey the computational needs of this approach.\nThe Sentinel-2 Level 2A collection does not come with a robust cloud mask. Instead, we will build one from related products that have been developed for this purpose. Following the existing Sentinel-2 cloud masking tutorials in the Earth Engine guides, this approach requires three Sentinel-2 image collections:\n\nThe Sentinel-2 Level 2A Surface Reflectance product. This is the dataset we want to use to build our final composite.\nThe Sentinel-2 Cloud Probability Dataset, an ImageCollection that contains cloud probabilities for each Sentinel-2 scene.\nThe Sentinel-2 Level 1C top-of-atmosphere product. This collection is needed to run the Cloud Displacement Index to identify cloud shadows, which is calculated using ee.Algorithms.Sentinel2.CDI (see Frantz et al. 2018 for algorithm description).\n\nThese three image collections all contain 10 m resolution data for every Sentinel-2 scene. We will join them based on their ‘system:index’ property so we can relate each Level 2A scene with the corresponding cloud probability and cloud displacement index. Furthermore, there are two ee.Image.projection steps to control the scale when calculating clouds and their shadows.\nTo sum up, the cloud masking approach is computationally costly, thus requiring some thought when applying it at scale.\n\n10.2.1 2.1. Generate a Cloud-Free Satellite Composite: Limits to On-the-Fly Computing\nNote: Our focus here is on code structure for implementing spatial tiling. Below, we import existing tested functions for cloud masking using the require command.\nFirst, define our region and time of interest; then, load the module containing the cloud functions.\n// Set the Region of Interest:Seattle, Washington, United States\nvar roi = ee.Geometry.Point([-122.33524518034544, 47.61356183942883]);\n// Dates over which to create a median composite.\nvar start = ee.Date(‘2019-03-01’);\nvar end = ee.Date(‘2019-09-01’);\n// Specify module with cloud mask functions.\nvar s2mask_tools = require(   ‘projects/gee-edu/book:Part F - Fundamentals/F6 - Advanced Topics/F6.2 Scaling Up/modules/s2cloudmask.js’\n);\nNext, load and filter our three Sentinel-2 image collections.\n// Sentinel-2 surface reflectance data for the composite.\nvar s2Sr = ee.ImageCollection(‘COPERNICUS/S2_SR’)\n   .filterDate(start, end)\n   .filterBounds(roi)\n   .select([‘B2’, ‘B3’, ‘B4’, ‘B5’]);\n// Sentinel-2 Level 1C data (top-of-atmosphere).  \n// Bands B7, B8, B8A and B10 needed for CDI and the cloud mask function.\nvar s2 = ee.ImageCollection(‘COPERNICUS/S2’)\n   .filterBounds(roi)\n   .filterDate(start, end)\n   .select([‘B7’, ‘B8’, ‘B8A’, ‘B10’]);\n// Cloud probability dataset - used in cloud mask function\nvar s2c = ee.ImageCollection(‘COPERNICUS/S2_CLOUD_PROBABILITY’)\n   .filterDate(start, end)\n   .filterBounds(roi);\nNow apply the cloud mask:\n// Join the cloud probability dataset to surface reflectance.\nvar withCloudProbability = s2mask_tools.indexJoin(s2Sr, s2c,   ‘cloud_probability’);\n// Join the L1C data to get the bands needed for CDI.\nvar withS2L1C = s2mask_tools.indexJoin(withCloudProbability, s2,   ‘l1c’);\n// Map the cloud masking function over the joined collection.\n// Cast output to ImageCollection\nvar masked = ee.ImageCollection(withS2L1C.map(s2mask_tools\n.maskImage));\nNext, generate and visualize the median composite:\n// Take the median, specifying a tileScale to avoid memory errors.\nvar median = masked.reduce(ee.Reducer.median(), 8);\n// Display the results.\nMap.centerObject(roi, 12);\nMap.addLayer(roi);\nvar viz = {\n   bands: [‘B4_median’, ‘B3_median’, ‘B2_median’],\n   min: 0,\n   max: 3000\n};\nMap.addLayer(median, viz, ‘median’);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F62c. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nAfter about 1–3 minutes, Earth Engine returns our composite to us on the fly (Fig. F6.2.5). Note that panning and zooming to a new area requires that Earth Engine must again issue the compositing request to calculate the image for new areas. Given the delay, this isn’t a very satisfying way to explore our composite.\n\nFig. F6.2.5 Map view of Seattle, Washington, USA (left) and the corresponding Sentinel-2 composite (right)\nNext, expand our view (set zoom to 9) to exceed the limits of on-the-fly computation (Fig. F6.2.6).\nMap.centerObject(roi, 9);\nMap.addLayer(roi);\nMap.addLayer(median, viz, ‘median’);\n\nFig. F6.2.6 Error message for exceeding memory limits in interactive mode\nAs you can see, this is an excellent candidate for an export task rather than running in “on-the-fly” interactive mode, as above.\n\n\n10.2.2 2.2. Generate a Regional Composite Through Spatial Tiling\nOur goal is to apply the cloud masking method in Sect. 2.1 to the state of Washington, United States. In our testing, we successfully exported one Sentinel-2 composite for this area in about nine hours, but for this tutorial, let’s presume we need to split the task up to be successful.\nEssentially, we want to split our region of interest up into a regular grid. For each grid, we will export a composite image into a new ImageCollection asset. We can then load and mosaic our composite for use in downstream scripts (see below).\nFirst, generate a spatial polygon grid (FeatureCollection) of desired size over your region of interest (see Fig. F6.2.7):\n// Specify helper functions.\nvar s2mask_tools = require(   ‘projects/gee-edu/book:Part F - Fundamentals/F6 - Advanced Topics/F6.2 Scaling Up/modules/s2cloudmask.js’\n);\n// Set the Region of Interest: Washington, USA.\nvar roi = ee.FeatureCollection(‘TIGER/2018/States’)\n   .filter(ee.Filter.equals(‘NAME’, ‘Washington’));\n// Specify grid size in projection, x and y units (based on projection).\nvar projection = ‘EPSG:4326’; // WGS84 lat lon\nvar dx = 2.5;\nvar dy = 1.5;\n// Dates over which to create a median composite.\nvar start = ee.Date(‘2019-03-01’);\nvar end = ee.Date(‘2019-09-01’);\n// Make grid and visualize.\nvar proj = ee.Projection(projection).scale(dx, dy);\nvar grid = roi.geometry().coveringGrid(proj);\nMap.addLayer(roi, {}, ‘roi’);\nMap.addLayer(grid, {}, ‘grid’);\n\nFig. F6.2.7 Visualization of the regular spatial grid generated for use in spatial batch processing\nNext, create a new, empty ImageCollection asset to use as our export destination (Assets > New > Image Collection; Fig. F6.2.8). Name the image collection ‘S2_composite_WA’ and specify the asset location in your user folder (e.g., “path/to/your/asset/s2_composite_WA”).\n\nFig. F6.2.8 The “create new image collection asset” menu in the Code Editor\nSpecify the ImageCollection to export to, along with a base name for each image (the tile number will be appended in the batch export).\n// Export info.\nvar assetCollection = ‘path/to/your/asset/s2_composite_WA’;\nvar imageBaseName = ‘S2_median_’;\nExtract grid numbers to use as looping variables. Note there is one getInfo call here, which should be used sparingly and never within a for-loop if you can help it. We use it to bring the number of grid cells we’ve generated onto the client-side to set up the for-loop over grids. Note that if your grid has too many elements, you may need a different strategy.\n// Get a list based on grid number.\nvar gridSize = grid.size().getInfo();\nvar gridList = grid.toList(gridSize);\nBatch generate a composite image task export for each grid via looping:\n// In each grid cell, export a composite\nfor (var i = 0; i < gridSize; i++) {   // Extract grid polygon and filter S2 datasets for this region.   var gridCell = ee.Feature(gridList.get(i)).geometry();   var s2Sr = ee.ImageCollection(‘COPERNICUS/S2_SR’)\n       .filterDate(start, end)\n       .filterBounds(gridCell)\n       .select([‘B2’, ‘B3’, ‘B4’, ‘B5’]);   var s2 = ee.ImageCollection(‘COPERNICUS/S2’)\n       .filterDate(start, end)\n       .filterBounds(gridCell)\n       .select([‘B7’, ‘B8’, ‘B8A’, ‘B10’]);   var s2c = ee.ImageCollection(‘COPERNICUS/S2_CLOUD_PROBABILITY’)\n       .filterDate(start, end)\n       .filterBounds(gridCell);   // Apply the cloud mask.   var withCloudProbability = s2mask_tools.indexJoin(s2Sr, s2c,       ‘cloud_probability’);   var withS2L1C = s2mask_tools.indexJoin(withCloudProbability, s2,       ‘l1c’);   var masked = ee.ImageCollection(withS2L1C.map(s2mask_tools\n       .maskImage));   // Generate a median composite and export.   var median = masked.reduce(ee.Reducer.median(), 8);   // Export.   var imagename = imageBaseName + ‘tile’ + i;   Export.image.toAsset({\n       image: median,\n       description: imagename,\n       assetId: assetCollection + ‘/’ + imagename,\n       scale: 10,\n       region: gridCell,\n       maxPixels: 1e13   });\n}\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F62d. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nSimilar to Sect. 1.2, we now have a list of tasks to execute. We can hold the Cmd/Ctrl key and click Run to execute each task (Fig. F6.2.9). Again, users with applications requiring large batches may want to explore the Earth Engine Python API, which is well-suited to batching work. The output ImageCollection is 35.3 GB, so you may not want to execute all (or any) of these tasks but can access our pre-generated image, as discussed below.\n\nFig. F6.2.9 Spatial batch tasks have been generated and are ready to run\nIn addition to being necessary for very large regions, batch processing can speed things up for moderate scales. In our tests, tiles averaged about one hour to complete. Because three jobs in our queue were running simultaneously, we covered the full state of Washington in about four hours (compared to about nine hours when tested for the full state of Washington at once). Users should note, however, that there is also an overhead to spinning up each batch task. Finding the balance between task size and task number is a challenge for most Earth Engine users that becomes easier with experience.\nIn a new script, load the exported ImageCollection and mosaic for use.\n// load image collection and mosaic into single image\nvar assetCollection = ‘projects/gee-book/assets/F6-2/s2_composite_WA’;\nvar composite = ee.ImageCollection(assetCollection).mosaic();\n// Display the results\nvar geometry = ee.Geometry.Point([-120.5873563817392,   47.39035206888694\n]);\nMap.centerObject(geometry, 6);\nvar vizParams = {\n   bands: [‘B4_median’, ‘B3_median’, ‘B2_median’],\n   min: 0,\n   max: 3000\n};\nMap.addLayer(composite, vizParams, ‘median’);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F62e. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n\nFig. F6.2.10 Sentinel-2 composite covering the state of Washington, loaded from asset. The remaining white colors are snow-capped mountains, not clouds.\nNote the ease, speed, and joy of panning and zooming to explore the pre-computed composite asset (Fig. F6.2.10) compared to the on-the-fly version discussed in Sect. 2.1."
  },
  {
    "objectID": "F6.html#multistep-workflows-and-intermediate-assets",
    "href": "F6.html#multistep-workflows-and-intermediate-assets",
    "title": "7  Advanced Topics",
    "section": "10.3 Multistep Workflows and Intermediate Assets",
    "text": "10.3 Multistep Workflows and Intermediate Assets\nOften, our goals require several processing steps that cannot be completed within one Earth Engine computational chain. In these cases, the best strategy becomes breaking down tasks into individual pieces that are created, stored in assets, and used across several scripts. Each sequential script creates an intermediate output, and this intermediate output becomes the input to the next script.\nAs an example, consider the land use classification task of identifying irrigated agricultural lands. This type of classification can benefit from several types of evidence, including satellite composites, aggregated weather information, soil information, and/or crop type locations. Individual steps for this type of work might include:\n\nGenerating satellite composites of annual or monthly vegetation indices\nProcessing climate data into monthly or seasonal values\nGenerating random point locations from a ground truth layer for use as a feature training dataset and accuracy validation, and extracting composite and weather values at these features\nTraining a classifier and applying it, possibly across multiple years; researchers will often implement multiple classifiers and compare the performance of different methods\nImplementing post-classification cleaning steps, such as removing “speckle”\nEvaluating accuracy at ground truth validation points, and against government statistics using total area per administrative boundary\nExporting your work as spatial layers, visualizations, or other formats\n\nMultipart workflows can become unwieldy to manage, particularly if there are multiple collaborators or the project has a long timeline; it can be difficult to remember why each script was developed and where it fits in the overall workflow.\nHere, we provide tips for managing multipart workflows. These are somewhat opinionated and based largely on concepts from “Good Enough Practices in Scientific Computing” (Wilson et al. 2017). Ultimately, your personal workflow practices will be a combination of what works for you, what works for your larger team and organization, and, hopefully, what works for good documentation and reproducibility.\nTip 1. Create a repository for each project\nThe repository can be considered the fundamental project unit. In Earth Engine, sharing permissions are set for each individual repository, so this allows you to share a specific project with others (see Chap. F6.1).\nBy default, Earth Engine saves new scripts in a “default” repository specific for each user (users//default). You can create new repositories on the Scripts tab of the Code Editor (Fig. F6.2.11).\n\nFig. F6.2.11 The Code Editor menu for creating new repositories\nTo adjust permissions for each repository, click on the Gear icon (Fig. F6.2.12):\n\nFig. F6.2.12 Access the sharing and permissions menu for each repository by clicking the Gear icon\nFor users familiar with version control, Earth Engine uses a git-based script manager, so each repository can also be managed, edited, and/or synced with your local copy or collaborative spaces like GitHub.\nTip 2. Make a separate script for each step, and make script file names informative and self-sorting\nDescriptive, self-sorting filenames are an excellent “good enough” way to keep your projects organized. We recommend starting script names with zero-padded numeric values to take advantage of default ordering. Because we are generating assets in early scripts that are used in later scripts, it’s important to preserve the order of your workflow. The name should also include short descriptions of what the script does (Fig. F6.2.13).\n\nFig. F6.2.13 An example project repository with multiple scripts. Using leading numbers when naming scripts allows you to order them by their position in the workflow.\nLeaving some decimal places between successive scripts gives you the ability to easily insert any additional steps you didn’t originally anticipate. And zero-padding means your self-sorting still works once you move into double-digit numbers.\nOther script organization strategies might involve including subfolders to collect scripts related to main steps. For example, one could have a subfolder “04_classifiers” to keep alternative classification scripts in one place, using a more tree-based file structure. Again, each user or group will develop a system that works for them. The important part is to have an organizational system.\nTip 3. Consider data types and file sizes when storing intermediates\nImages and image collections are common intermediate file types, since generating satellite composites or creating land use classifications tends to be computationally intensive. These assets can also be quite large, depending on the resolution and region size. Recall that our single-year, subregional Sentinel-2 composite in Sect. 2 was about 23 GB.\nImage values can be stored from 8-bit integers to 64-bit double floats (numbers with decimals). Higher bits allow for more precision, but have much larger file sizes and are not always necessary. For example, if we are generating a land use map with five classes, we can convert that to a signed or unsigned 8-bit integer using toInt8 or toUint8 prior to exporting to asset, which can accommodate 256 unique values. This results in a smaller file size. Selectively retaining only bands of interest is also helpful to reduce size.\nFor cases requiring decimals and precision, consider whether a 32-bit float will do the job instead of a 64-bit double—toFloat will convert an image to a 32-bit float. If you find you need to conserve storage, you can also scale float values and store as an integer image (image.multiply(100).toInt16(), for example). This would retain precision to the second decimal place and reduce file size by a factor of two. Note that this may require you to unscale the values in downstream use. Ultimately, the appropriate data type will be specific to your needs.\nAnd of course, as mentioned above under “The Importance of Best Coding Practices,” be aware of the scale resolution you are working at, and avoid using unnecessarily high resolution when it’s not supported by either the input imagery or your research goals.\nTip 4. Consider Google Cloud Platform for hosting larger intermediates\nIf you are working with very large or very many files, you can link Earth Engine with Cloud Projects on Google Cloud Platform. See the Earth Engine documentation on “Setting Up Earth Engine Enabled Cloud Projects” for more information."
  },
  {
    "objectID": "F6.html#synthesis-2",
    "href": "F6.html#synthesis-2",
    "title": "7  Advanced Topics",
    "section": "Synthesis",
    "text": "Synthesis\nEarth Engine is built to be scaled. Scaling up working scripts, however, can present challenges when the computations take too long or return results that are too large or numerous. We have covered some key strategies to use when you encounter memory or computational limits. Generally, they involve 1) optimizing your code based on Earth Engine’s functions and infrastructure; 2) working at scales appropriate for your data, question, and region of interest, and not at higher resolutions than necessary; and 3) breaking up tasks into discrete units."
  },
  {
    "objectID": "F6.html#references-2",
    "href": "F6.html#references-2",
    "title": "7  Advanced Topics",
    "section": "References",
    "text": "References\nAbatzoglou JT (2013) Development of gridded surface meteorological data for ecological applications and modelling. Int J Climatol 33:121–131. https://doi.org/10.1002/joc.3413\nFrantz D, Haß E, Uhl A, et al (2018) Improvement of the Fmask algorithm for Sentinel-2 images: Separating clouds from bright surfaces based on parallax effects. Remote Sens Environ 215:471–481. https://doi.org/10.1016/j.rse.2018.04.046\nGorelick N, Hancher M, Dixon M, et al (2017) Google Earth Engine: Planetary-scale geospatial analysis for everyone. Remote Sens Environ 202:18–27. https://doi.org/10.1016/j.rse.2017.06.031\nWilson G, Bryan J, Cranston K, et al (2017) Good enough practices in scientific computing. PLoS Comput Biol 13:e1005510. https://doi.org/10.1371/journal.pcbi.1005510"
  },
  {
    "objectID": "F6.html#author-3",
    "href": "F6.html#author-3",
    "title": "7  Advanced Topics",
    "section": "Author",
    "text": "Author\nQiusheng Wu"
  },
  {
    "objectID": "F6.html#overview-3",
    "href": "F6.html#overview-3",
    "title": "7  Advanced Topics",
    "section": "Overview",
    "text": "Overview\nThe purpose of this chapter is to demonstrate how to design and publish Earth Engine Apps using both JavaScript and Python. You will be introduced to the Earth Engine User Interface JavaScript API and the geemap Python package. Upon completion of this chapter, you will be able to publish an Earth Engine App with a split-panel map for visualizing land cover change."
  },
  {
    "objectID": "F6.html#learning-outcomes-3",
    "href": "F6.html#learning-outcomes-3",
    "title": "7  Advanced Topics",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nDesigning a user interface for an Earth Engine App using JavaScript.\nPublishing an Earth Engine App for visualizing land cover change.\nDeveloping an Earth Engine App using Python and geemap.\nDeploying an Earth Engine App using a local computer as a web server.\nPublishing an Earth Engine App using Python and free cloud platforms.\nCreating a conda environment using Anaconda/Miniconda.\nInstalling Python packages and using Jupyter Notebook.\nCommiting changes to a GitHub repository."
  },
  {
    "objectID": "F6.html#assumes-you-know-how-to-3",
    "href": "F6.html#assumes-you-know-how-to-3",
    "title": "7  Advanced Topics",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nUse the basic functions and logic of Python."
  },
  {
    "objectID": "F6.html#introduction-to-theory-3",
    "href": "F6.html#introduction-to-theory-3",
    "title": "7  Advanced Topics",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nEarth Engine has a user interface API that allows users to build and publish interactive web apps directly from the JavaScript Code Editor. Many readers will have encountered a call to ui.Chart in other chapters, but much more interface functionality is available. In particular, users can utilize the ui functions to construct an entire graphical user interface (GUI) for their Earth Engine script. The GUI may include simple widgets (e.g., labels, buttons, checkboxes, sliders, text boxes) as well as more complex widgets (e.g., charts, maps, panels) for controlling the GUI layout. A complete list of the ui widgets and more information about panels can be found at the links below. Once a GUI is constructed, users can publish the App from the JavaScript Code Editor by clicking the Apps button above the script panel in the Code Editor.\n\nWidgets: https://developers.google.com/earth-engine/guides/ui_widgets\nPanels: https://developers.google.com/earth-engine/guides/ui_panels \n\nUnlike the Earth Engine JavaScript API, the Earth Engine Python API does not provide functionality for building interactive user interfaces. Fortunately, the Jupyter ecosystem has ipywidgets, an architecture for creating interactive user interface controls (e.g., buttons, sliders, checkboxes, text boxes, dropdown lists) in Jupyter notebooks that communicate with Python code. The integration of graphical widgets into the Jupyter Notebook workflow allows users to configure ad hoc control panels to interactively sweep over parameters using graphical widget controls. One very powerful widget is the output widget, which can be used to display rich output generated by IPython, such as text, images, charts, and videos. A complete list of widgets and more information about the output widget can be found at the links below. By integrating ipyleaflet (for creating interactive maps) and ipywidgets (for designing interactive user interfaces), the geemap Python package (https://geemap.org) makes it much easier to explore and analyze massive Earth Engine datasets via a web browser in a Jupyter environment suitable for interactive exploration, teaching, and sharing. Users can build interactive Earth Engine Apps using geemap with minimal coding (Fig. F6.3.1).\n\nWidgets: https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20List.html \nOutput: https://ipywidgets.readthedocs.io/en/latest/examples/Output%20Widget.html \n\n\nFig. F6.3.1 The GUI of geemap in a Jupyter environment"
  },
  {
    "objectID": "F6.html#building-an-earth-engine-app-using-javascript",
    "href": "F6.html#building-an-earth-engine-app-using-javascript",
    "title": "7  Advanced Topics",
    "section": "11.1 Building an Earth Engine App Using JavaScript",
    "text": "11.1 Building an Earth Engine App Using JavaScript\nIn this section, you will learn how to design a user interface for an Earth Engine App using JavaScript and the Earth Engine User Interface API. Upon completion of this section, you will have an Earth Engine App with a split-panel map for visualizing land cover change using the Landsat-based United States Geological Survey National Land Cover Database (NLCD).\nFirst, let’s define a function for filtering the NLCD ImageCollection by year and select the landcover band. The function returns an Earth Engine ui.Map.Layer of the landcover band of the selected NLCD image. Note that as of this writing, NLCD spans nine epochs: 1992, 2001, 2004, 2006, 2008, 2011, 2013, 2016, and 2019. The 1992 data are primarily based on unsupervised classification of Landsat data, while the rest of the images rely on the imperviousness data layer for the urban classes and on a decision-tree classification for the rest. The 1992 image is not directly comparable to any later editions of NLCD (see the Earth Engine Data Catalog for more details, if needed). Therefore, we will use only the eight epochs after 2000 in this lab.  \n// Get an NLCD image by year.\nvar getNLCD = function(year) {   // Import the NLCD collection.   var dataset = ee.ImageCollection(       ‘USGS/NLCD_RELEASES/2019_REL/NLCD’);   // Filter the collection by year.   var nlcd = dataset.filter(ee.Filter.eq(‘system:index’, year))\n       .first();   // Select the land cover band.   var landcover = nlcd.select(‘landcover’);   return ui.Map.Layer(landcover, {}, year);\n};\nOur intention is to create a dropdown list so that when a particular epoch is selected, the corresponding NLCD image layer will be displayed on the map. We’ll define a dictionary with each NLCD epoch as the key and its corresponding NLCD image layer as the value. The keys of the dictionary (i.e., the eight NLCD epochs) will be used as the input to the dropdown lists (ui.Select) on the split-level map.\n// Create a dictionary with each year as the key\n// and its corresponding NLCD image layer as the value.\nvar images = {   ‘2001’: getNLCD(‘2001’),   ‘2004’: getNLCD(‘2004’),   ‘2006’: getNLCD(‘2006’),   ‘2008’: getNLCD(‘2008’),   ‘2011’: getNLCD(‘2011’),   ‘2013’: getNLCD(‘2013’),   ‘2016’: getNLCD(‘2016’),   ‘2019’: getNLCD(‘2019’),\n};\nThe split-panel map is composed of two individual maps, leftMap and rightMap. The map controls (e.g., zoomControl, scaleControl, mapTypeControl) will be shown only on rightMap. A control panel (ui.Panel) composed of a label (ui.Label) and a dropdown list (ui.Select) is added to each map. When an NLCD epoch is selected from a dropdown list, the function updateMap will be called to show the corresponding image layer of the selected epoch.\n// Create the left map, and have it display the first layer.\nvar leftMap = ui.Map();\nleftMap.setControlVisibility(false);\nvar leftSelector = addLayerSelector(leftMap, 0, ‘top-left’);\n// Create the right map, and have it display the last layer.\nvar rightMap = ui.Map();\nrightMap.setControlVisibility(true);\nvar rightSelector = addLayerSelector(rightMap, 7, ‘top-right’);\n// Adds a layer selection widget to the given map, to allow users to\n// change which image is displayed in the associated map.\nfunction addLayerSelector(mapToChange, defaultValue, position) {   var label = ui.Label(‘Select a year:’);   // This function changes the given map to show the selected image.   function updateMap(selection) {\n       mapToChange.layers().set(0, images[selection]);\n   }   // Configure a selection dropdown to allow the user to choose   // between images, and set the map to update when a user   // makes a selection.   var select = ui.Select({\n       items: Object.keys(images),\n       onChange: updateMap\n   });\n   select.setValue(Object.keys(images)[defaultValue], true);   var controlPanel =       ui.Panel({\n           widgets: [label, select],\n           style: {\n               position: position\n           }\n       });\n   mapToChange.add(controlPanel);\n}\nWhen displaying a land cover classification image on the Map, it would be useful to add a legend to make it easier for users to interpret the land cover type associated with each color. Let’s define a dictionary that will be used to construct the legend. The dictionary contains two keys: names (a list of land cover types) and colors (a list of colors associated with each land cover type). The legend will be placed in the bottom right of the Map.    \n// Set the legend title.\nvar title = ‘NLCD Land Cover Classification’;\n// Set the legend position.\nvar position = ‘bottom-right’;\n// Define a dictionary that will be used to make a legend\nvar dict = {   ‘names’: [       ‘11        Open Water’,       ‘12        Perennial Ice/Snow’,       ‘21        Developed, Open Space’,       ‘22        Developed, Low Intensity’,       ‘23        Developed, Medium Intensity’,       ‘24        Developed, High Intensity’,       ‘31        Barren Land (Rock/Sand/Clay)’,       ‘41        Deciduous Forest’,       ‘42        Evergreen Forest’,       ‘43        Mixed Forest’,       ‘51        Dwarf Scrub’,       ‘52        Shrub/Scrub’,       ‘71        Grassland/Herbaceous’,       ‘72        Sedge/Herbaceous’,       ‘73        Lichens’,       ‘74        Moss’,       ‘81        Pasture/Hay’,       ‘82        Cultivated Crops’,       ‘90        Woody Wetlands’,       ‘95        Emergent Herbaceous Wetlands’,\n   ],   ‘colors’: [       ‘#466b9f’, ‘#d1def8’, ‘#dec5c5’, ‘#d99282’, ‘#eb0000’,       ‘#ab0000’,       ‘#b3ac9f’, ‘#68ab5f’, ‘#1c5f2c’, ‘#b5c58f’, ‘#af963c’,       ‘#ccb879’,       ‘#dfdfc2’, ‘#d1d182’, ‘#a3cc51’, ‘#82ba9e’, ‘#dcd939’,       ‘#ab6c28’,       ‘#b8d9eb’, ‘#6c9fb8’,\n   ]\n};\nWith the legend dictionary defined above, we can now create a panel to hold the legend widget and add it to the Map. Each row on the legend widget is composed of a color box followed by its corresponding land cover type.\n// Create a panel to hold the legend widget.\nvar legend = ui.Panel({\n   style: {\n       position: position,\n       padding: ‘8px 15px’   }\n});// Function to generate the legend.\nfunction addCategoricalLegend(panel, dict, title) {   // Create and add the legend title.   var legendTitle = ui.Label({\n       value: title,\n       style: {\n           fontWeight: ‘bold’,\n           fontSize: ‘18px’,\n           margin: ‘0 0 4px 0’,\n           padding: ‘0’       }\n   });\n   panel.add(legendTitle);   var loading = ui.Label(‘Loading legend…’, {\n       margin: ‘2px 0 4px 0’   });\n   panel.add(loading);   // Creates and styles 1 row of the legend.   var makeRow = function(color, name) {       // Create the label that is actually the colored box.       var colorBox = ui.Label({\n           style: {\n               backgroundColor: color,               // Use padding to give the box height and width.               padding: ‘8px’,\n               margin: ‘0 0 4px 0’           }\n       });       // Create the label filled with the description text.       var description = ui.Label({\n           value: name,\n           style: {\n               margin: ‘0 0 4px 6px’           }\n       });       return ui.Panel({\n           widgets: [colorBox, description],\n           layout: ui.Panel.Layout.Flow(‘horizontal’)\n       });\n   };   // Get the list of palette colors and class names from the image.   var palette = dict.colors;   var names = dict.names;\n   loading.style().set(‘shown’, false);   for (var i = 0; i < names.length; i++) {\n       panel.add(makeRow(palette[i], names[i]));\n   }\n   rightMap.add(panel);\n}\nThe last step is to create a split-panel map to hold the linked maps (leftMap and rightMap) and tie everything together. When users pan and zoom one map, the other map will also be panned and zoomed to the same extent automatically. When users select a year from a dropdown list, the image layer will be updated accordingly. Users can use the slider to swipe through and visualize land cover change easily (Fig. F6.3.2). Please make sure you minimize the Code Editor and maximize the Map so that you can see the dropdown widget in the upper-right corner of the map.\naddCategoricalLegend(legend, dict, title);\n// Create a SplitPanel to hold the adjacent, linked maps.\nvar splitPanel = ui.SplitPanel({\n   firstPanel: leftMap,\n   secondPanel: rightMap,\n   wipe: true,\n   style: {\n       stretch: ‘both’   }\n});// Set the SplitPanel as the only thing in the UI root.\nui.root.widgets().reset([splitPanel]);\nvar linker = ui.Map.Linker([leftMap, rightMap]);\nleftMap.setCenter(-100, 40, 4);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F63a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n\nFig. F6.3.2 A split-panel map for visualizing land cover change using NLCD"
  },
  {
    "objectID": "F6.html#publishing-an-earth-engine-app-from-the-code-editor",
    "href": "F6.html#publishing-an-earth-engine-app-from-the-code-editor",
    "title": "7  Advanced Topics",
    "section": "11.2 Publishing an Earth Engine App from the Code Editor",
    "text": "11.2 Publishing an Earth Engine App from the Code Editor\nThe goal of this section is to publish the Earth Engine App that we created in Sect. 1. The look and feel of interfaces changes often; if the exact windows described below change over time, the concepts should remain stable to help you to publish your App. First, load the script (see the Code Checkpoint in Sect. 1) into the Code Editor. Then, open the Manage Apps panel by clicking the Apps button above the script panel in the Code Editor (Fig. F6.3.3).\n\nFig. F6.3.3 The Apps button in the JavaScript Code Editor\nNow click on the New App button (Fig. F6.3.4).\n\nFig. F6.3.4 The New App button\nIn the Publish New App dialog (Fig. F6.3.5), choose a name for the App (e.g., NLCD Land Cover Change), select a Google Cloud Project, provide a thumbnail to be shown in the Public Apps Gallery, and specify the location of the App’s source code. You may restrict access to the App to a particular Google Group or make it publicly accessible. Check Feature this app in your Public Apps Gallery if you would like this App to appear in your public gallery of Apps available at https://USERNAME.users.earthengine.app. When all fields are filled out and validated, the Publish button will be enabled; click it to complete publishing the App. \n\nFig. F6.3.5 The Publish New App dialog\nTo manage an App from the Code Editor, open the Manage Apps panel (Fig. F6.3.6) by clicking the Apps button above the script panel in the Code Editor (Fig. F6.3.3). There, you can update your App’s configuration or delete the App.\n\nFig. F6.3.6 The Manage Apps panel"
  },
  {
    "objectID": "F6.html#developing-an-earth-engine-app-using-geemap",
    "href": "F6.html#developing-an-earth-engine-app-using-geemap",
    "title": "7  Advanced Topics",
    "section": "11.3 Developing an Earth Engine App Using geemap",
    "text": "11.3 Developing an Earth Engine App Using geemap\nIn this section, you will learn how to develop an Earth Engine App using the geemap Python package and Jupyter Notebook. The geemap package is available on both PyPI (pip) and conda-forge. It is highly recommended that you create a fresh conda environment to install geemap.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F63b. The book’s repository contains information about setting up a conda environment and installing geemap.\n\n\nOnce you have launched a Jupyter notebook in your browser, you can continue with the next steps of the lab.\nOn the Jupyter Notebook interface, click the New button in the upper-right corner and select Python 3 to create a new notebook. Change the name of the notebook from “Untitled” to something meaningful (e.g., “nlcd_app”). With the newly created notebook, we can start writing and executing Python code.\nFirst, let’s import the Earth Engine and geemap libraries. Press Alt + Enter to execute the code and create a new cell below.\nimport eeimport geemap\nCreate an interactive map by specifying the map center (latitude, longitude) and zoom level (1–18). If this is the first time you use geemap and the Earth Engine Python API, a new tab will open in your browser asking you to authenticate Earth Engine. Follow the on-screen instructions to authenticate Earth Engine.\nMap = geemap.Map(center=[40, -100], zoom=4)\nMap\nRetrieve the NLCD 2019 image by filtering the NLCD ImageCollection and selecting the landcover band. Display the NLCD 2019 image on the interactive Map by using Map.addLayer."
  },
  {
    "objectID": "F6.html#publishing-an-earth-engine-app-using-a-local-web-server",
    "href": "F6.html#publishing-an-earth-engine-app-using-a-local-web-server",
    "title": "7  Advanced Topics",
    "section": "17.1 Publishing an Earth Engine App Using a Local Web Server",
    "text": "17.1 Publishing an Earth Engine App Using a Local Web Server\nIn this section, you will learn how to deploy an Earth Engine App using a local computer as a web server. Assume that you have completed Sect. 3 and created a Jupyter notebook named nlcd_app.ipynb. First, you need to download ngrok, a program that can turn your computer into a secure web server and connect it to the ngrok cloud service, which accepts traffic on a public address. Download ngrok from https://ngrok.com and unzip it to a directory on your computer, then copy  nlcd_app.ipynb to the same directory. Open the Anaconda Prompt (on Windows) or the Terminal (on macOS/Linux) and enter the following commands. Make sure you change /path/to/ngrok/dir to your computer directory where the ngrok executable is located, e.g., ~/Downloads.  \ncd /path/to/ngrok/dir\nconda activate gee\nvoila –no-browser nlcd_app.ipynb\nThe output of the terminal should look like this.\n\nFig. F6.3.9 The output of the terminal running Voilà\nVoilà can be used to run, convert, and serve a Jupyter notebook as a standalone app. Click the link (e.g., http://localhost:8866) shown in the terminal window to launch the interactive dashboard. Note that the port number is 8866, which is needed in the next step to launch ngrok. Open another terminal and enter the following command.\ncd /path/to/ngrok/dir\nngrok http 8866\nThe output of the terminal should look like Fig. F6.3.10. Click the link shown in the terminal window to launch the interactive dashboard. The link should look like https://random-string.ngrok.io, which is publicly accessible. Anyone with the link will be able to launch the interactive dashboard and use the split-panel map to visualize NLCD land cover change. Keep in mind that the dashboard might take several seconds to load, so please be patient.\n\nFig. F6.3.10 The output of the terminal running ngrok\nTo stop the web server, press Ctrl + C on both terminal windows. See below for some optional settings for running Voilà and ngrok.\nTo show code cells from your App, run the following from the terminal.\nvoila –no-browser –strip_sources=False nlcd_app.ipynb\nTo protect your App with a password, run the following.\nngrok http -auth=“username:password” 8866"
  },
  {
    "objectID": "F6.html#publish-an-earth-engine-app-using-cloud-platforms",
    "href": "F6.html#publish-an-earth-engine-app-using-cloud-platforms",
    "title": "7  Advanced Topics",
    "section": "17.2 Publish an Earth Engine App Using Cloud Platforms",
    "text": "17.2 Publish an Earth Engine App Using Cloud Platforms\nIn this section, you will learn how to deploy an Earth Engine App on cloud platforms, such as Heroku and Google App Engine. Heroku is a “platform as a service” that enables developers to build, run, and operate applications entirely in the cloud. It has a free tier with limited computing hours, which would be sufficient for this lab. Follow the steps below to deploy the Earth Engine App on Heroku.\nFirst, go to https://github.com/signup to sign up for a GitHub account if you don’t have one already. Once your GitHub account has been created, log into your account and navigate to the sample app repository: https://github.com/giswqs/earthengine-apps. Click the Fork button in the top-right corner to fork this repository into your account. Two important files in the repository are worth mentioning here: requirements.txt lists the required packages (e.g., geemap) to run the App, while Procfile specifies the commands that are executed by the App on startup. The content of Procfile should look like this.\nweb: voila –port=$PORT –no-browser –strip_sources=True –enable_nbextensions=True –MappingKernelManager.cull_interval=60 –MappingKernelManager.cull_idle_timeout=120 notebooks/\nThe above command instructs the server to hide the source code and periodically check for idle kernels—in this example, every 60 seconds—and cull them if they have been idle for more than 120 seconds. This can avoid idle kernels using up the server computing resources. The page served by Voilà will contain a list of any notebooks in the notebooks directory.\nNext, go to https://signup.heroku.com to sign up for a Heroku account if you don’t have one already. Log into your account and click the New button in the top-right corner, then choose Create new app from the dropdown list (Fig. F6.3.11).\n\nFig. F6.3.11 Creating a new app in Heroku\nChoose a name for your App (Fig. F6.3.12). Note that the App name must be unique; if an App name has already been taken, you won’t be able to use it.\n\nFig. F6.3.12 Choosing an App name\nOnce the Heroku App has been created, click the Deploy tab and choose GitHub as the deployment method. Connect to your GitHub account and enter earthengine-apps in the search box. The repository should be listed beneath the search box. Click the Connect button to connect the repository to Heroku (Fig. F6.3.13).\n\nFig. F6.3.13 Connecting a GitHub account to Heroku\nUnder the same Deploy tab, scroll down and click Enable Automatic Deploys (Fig. F6.3.14). This will enable Heroku to deploy a new version of the App whenever the GitHub repository gets updated.\n\nFig. F6.3.14 Enabling Automatic Deploys on Heroku\nSince using Earth Engine requires authentication, we need to set the Earth Engine token as an environment variable so that the web App can pass the Earth Engine authentication. If you have completed Sect. 3, you have successfully authenticated Earth Engine on your computer and the token can be found in the following file path, depending on the operating system you are using. Note that you might need to show the hidden directories on your computer in order to see the .config folder under the home directory.\nWindows: C:UsersUSERNAME.configearthenginecredentialsLinux: /home/USERNAME/.config/earthengine/credentials\nMacOS: /Users/USERNAME/.config/earthengine/credentials\nOpen the credentials file using a text editor. Select and copy the long string wrapped by the double quotes (Fig. F6.3.15). Do not include the double quotes in the copied string.\n\nFig. F6.3.15 The Earth Engine authentication token\nNext, navigate to your web App on Heroku. Click the Settings tab, then click Reveal Config Vars on the page. Enter EARTHENGINE_TOKEN as the key and paste the string copied above as the value. Click the Add button to set EARTHENGINE_TOKEN as an environment variable (Fig. F6.3.16) that will be used by geemap to authenticate Earth Engine.\n\nFig. F6.3.16 Setting the Earth Engine token as an environment variable on Heroku\nThe last step is to commit some changes to your forked GitHub repository to trigger Heroku to build and deploy the App. If you are familiar with Git commands, you can push changes to the repository from your local computer to GitHub. If you have not used Git before, you can navigate to your repository on GitHub and make changes directly using the browser. For example, you can navigate to README.md and click the Edit icon on the page to start editing the file. Simply place the cursor at the end of the file and press Enter to add an empty line to the file, then click the Commit changes button at the bottom of the page to save changes. This should trigger Heroku to build the App. Check the build status under the latest activities of the Overview tab. Once the App has been built and deployed successfully, you can click the Open app button in the top-right corner to launch the web App (Fig. F6.3.17). When the App is open in your browser, click nlcd_app.ipynb to launch the split-panel map for visualizing land cover change. This is the same notebook that we developed in Sect. 3. The App URL should look like this: https://APP-NAME.herokuapp.com/voila/render/nlcd_app.ipynb.\nCongratulations! You have successfully deployed the Earth Engine App on Heroku.\n\nFig. F6.3.17 Setting the Earth Engine token as an environment variable on Heroku\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F63d. The book’s repository contains information about what your code should look like at this point.\n\n\nQuestion 1. What are the pros and cons of designing Earth Engine Apps using geemap and ipywidgets, compared to the JavaScript Earth Engine User Interface API?\nQuestion 2. What are the pros and cons of deploying Earth Engine Apps on Heroku, compared to a local web server and the Earth Engine Code Editor?"
  },
  {
    "objectID": "F6.html#synthesis-3",
    "href": "F6.html#synthesis-3",
    "title": "7  Advanced Topics",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. Replace the NLCD datasets with other multitemporal land cover datasets (e.g., United States Department of Agriculture National Agricultural Statistics Service Cropland Data Layers, visible in the Earth Engine Data Catalog) and modify the web App for visualizing land cover change using the chosen land cover datasets. Deploy the web App using multiple platforms (i.e., JavaScript Code Editor, ngrok, and Heroku). More land cover datasets can be found at  https://developers.google.com/earth-engine/datasets/tags/landcover."
  },
  {
    "objectID": "F6.html#conclusion-2",
    "href": "F6.html#conclusion-2",
    "title": "7  Advanced Topics",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned how to design Earth Engine Apps using both the Earth Engine User Interface API (JavaScript) and geemap (Python). You also learned how to deploy Earth Engine Apps on multiple platforms, such as the JavaScript Code Editor, a local web server, and Heroku. The skill of designing and deploying interactive Earth Engine Apps is essential for making your research and data products more accessible to the scientific community and the general public. Anyone with the link to your web App can analyze and visualize Earth Engine datasets without needing an Earth Engine account."
  },
  {
    "objectID": "F6.html#references-3",
    "href": "F6.html#references-3",
    "title": "7  Advanced Topics",
    "section": "References",
    "text": "References\n\nEarth Engine User Interface API: https://developers.google.com/earth-engine/guides/ui \nEarth Engine Apps: https://developers.google.com/earth-engine/guides/apps \nVoilà: https://voila.readthedocs.io\ngeemap: https://geemap.org\nngrok: https://ngrok.com\nHeroku: https://heroku.com \nEarthengine-apps: https://github.com/giswqs/earthengine-apps   \n\nChapter F6.4: Combining R and Earth Engine\n\n\n\n\n\n\nChapter Information\n\n\n\n\nAuthor\n \nCesar Aybar, David Montero, Antony Barja, Fernando Herrera, Andrea Gonzales, and Wendy Espinoza\n\n\nOverview\nThe purpose of this chapter is to introduce rgee, a non-official API for Earth Engine. You will explore the main features available in rgee and how to set up an environment that integrates rgee with third-party R and Python packages. After this chapter, you will be able to combine R, Python, and JavaScript in the same workflow.\n\n\nLearning Outcomes\n\nBecoming familiar with rgee, the Earth Engine R API interface.\nIntegrating rgee with other R packages.\nDisplaying interactive maps.\nIntegrating Python and R packages using reticulate.\nCombining Earth Engine JavaScript and Python APIs with R.\n\n\n\nAssumes you know how to:\n\nInstall the Python environment (Chap. F6.3).\nUse the require function to load code from existing modules (Chap. F6.1).\nUse the basic functions and logic of Python.\nConfigure an environment variable and use .Renviron files.\nCreate Python virtual environments."
  },
  {
    "objectID": "F6.html#author-4",
    "href": "F6.html#author-4",
    "title": "7  Advanced Topics",
    "section": "Author",
    "text": "Author\n \nCesar Aybar, David Montero, Antony Barja, Fernando Herrera, Andrea Gonzales, and Wendy Espinoza"
  },
  {
    "objectID": "F6.html#overview-4",
    "href": "F6.html#overview-4",
    "title": "7  Advanced Topics",
    "section": "Overview",
    "text": "Overview\nThe purpose of this chapter is to introduce rgee, a non-official API for Earth Engine. You will explore the main features available in rgee and how to set up an environment that integrates rgee with third-party R and Python packages. After this chapter, you will be able to combine R, Python, and JavaScript in the same workflow."
  },
  {
    "objectID": "F6.html#learning-outcomes-4",
    "href": "F6.html#learning-outcomes-4",
    "title": "7  Advanced Topics",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nBecoming familiar with rgee, the Earth Engine R API interface.\nIntegrating rgee with other R packages.\nDisplaying interactive maps.\nIntegrating Python and R packages using reticulate.\nCombining Earth Engine JavaScript and Python APIs with R."
  },
  {
    "objectID": "F6.html#assumes-you-know-how-to-4",
    "href": "F6.html#assumes-you-know-how-to-4",
    "title": "7  Advanced Topics",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nInstall the Python environment (Chap. F6.3).\nUse the require function to load code from existing modules (Chap. F6.1).\nUse the basic functions and logic of Python.\nConfigure an environment variable and use .Renviron files.\nCreate Python virtual environments."
  },
  {
    "objectID": "F6.html#introduction-to-theory-4",
    "href": "F6.html#introduction-to-theory-4",
    "title": "7  Advanced Topics",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nR is a popular programming language established in statistical science with large support in reproducible research, geospatial analysis, data visualization, and much more. To get started with R, you will need to satisfy some extra software requirements. First, install an up-to-date R version (at least 4.0) in your work environment. The installation procedure will vary depending on your operating system (i.e., Windows, Mac, or Linux). Hands-On Programming with R (Garrett Grolemund 2014, Appendix A) explains step by step how to proceed. We strongly recommend that Windows users install Rtools to avoid compiling external static libraries.\nIf you are new to R, a good starting point is the book Geocomputation with R (Lovelace et al. 2019) or Spatial Data Science with Application in R (Pebesma and Bivand 2021). In addition, we recommend using an integrated development environment (e.g., Rstudio) or a code editor (e.g., Visual Studio Code) to create a suitable setting to display and interact with R objects.\nThe following R packages must be installed (find more information in the R manual) in order to go through the practicum section."
  },
  {
    "objectID": "F6.html#installing-rgee",
    "href": "F6.html#installing-rgee",
    "title": "7  Advanced Topics",
    "section": "18.1 Installing rgee ",
    "text": "18.1 Installing rgee \nTo run, rgee needs a Python environment with two packages: NumPy and earthengine-api. Because instructions change frequently, installation is explained at the following checkpoint:\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F64a. The book’s repository contains information about setting up the rgee environment.\n\n\nAfter installing both the R and Python requirements, you can now initialize your Earth Engine account from within R. Consider that R, in contrast to Javascript and Python, supports three distinct Google APIs: Earth Engine, Google Drive, and Google Cloud Storage (GCS).\nThe Google Drive and GCS APIs will allow you to transfer your Earth Engine completed task exports to a local environment automatically. In these practice sessions, we will use only the Earth Engine and Google Drive APIs. Users that are interested in GCS can look up and explore the GCS vignette. To initialize your Earth Engine account alongside Google Drive, use the following commands."
  },
  {
    "objectID": "F6.html#creating-a-3d-population-density-map-with-rgee-and-rayshader",
    "href": "F6.html#creating-a-3d-population-density-map-with-rgee-and-rayshader",
    "title": "7  Advanced Topics",
    "section": "20.1 Creating a 3D Population Density Map with rgee and rayshader",
    "text": "20.1 Creating a 3D Population Density Map with rgee and rayshader\nFirst, import the rgee, rayshader, and raster packages.\nlibrary(rayshader)\nlibrary(raster)\nlibrary(rgee)\nInitialize the Earth Engine and Google Drive APIs using ee_Initialize. Both credentials must come from the same Google account.\nee_Initialize(drive = TRUE)\nThen, we will access the WorldPop Global Project Population Data dataset. In rgee, the Earth Engine spatial classes (ee\\(Image, ee\\)ImageCollection, and ee$FeatureCollection) have a special attribute called Dataset. Users can use it along with autocompletion to quickly find the desired dataset.\ncollections <- ee\\(ImageCollection\\)Dataset\npopulation_data <- collections\\(CIESIN_GPWv411_GPW_Population_Density population_data_max <- population_data\\)max()\nIf you need more information about the Dataset, use ee_utils_dataset_display to go to the official documentation in the Earth Engine Data Catalog.\npopulation_data %>% ee_utils_dataset_display()\nThe rgee package provides various built-in functions to retrieve data from Earth Engine (Aybar et al. 2020). In this example, we use ee_as_raster, which automatically converts an ee$Image (server object) into a RasterLayer (local object).\nsa_extent <- ee\\(Geometry\\)Rectangle(\n coords = c(-100, -50, -20, 12),\n geodesic = TRUE,\n proj = “EPSG:4326”)\npopulation_data_ly_local <- ee_as_raster(\n image = population_data_max,\n region = sa_extent,\n dsn = “/home/pc-user01/population.tif”, # change for your own path. scale = 5000\n)\nNow, turn a RasterLayer into a matrix suitable for rayshader.\npop_matrix <- raster_to_matrix(population_data_ly_local)\nNext, modify the matrix population density values, adding:\n\nTexture, based on five colors (lightcolor, shadowcolor, leftcolor, rightcolor, and centercolor; see rayshader::create_texture documentation)\nColor and shadows (rayshader::sphere_shade)\n\npop_matrix %>%\n sphere_shade(\n   texture = create_texture(“#FFFFFF”, “#0800F0”, “#FFFFFF”, “#FFFFFF”, “#FFFFFF”)\n ) %>%\n plot_3d(\n   pop_matrix,\n   zoom = 0.55, theta = 0, zscale = 100, soliddepth = -24,\n   solidcolor = “#525252”, shadowdepth = -40, shadowcolor = “black”,\n   shadowwidth = 25, windowsize = c(800, 720)\n )\nLastly, define a title and subtitle for the plot. Use rayshader::render_snapshot to export the final results (Fig. F6.4.2).\ntext <- paste0( “South Americanpopulation density”,\n strrep(“n”, 27), “Source:GPWv411: Population Density (Gridded Population of the World Version 4.11)”)\nrender_snapshot(\n filename = “30_poblacionsudamerica.png”,\n title_text = text,\n title_size = 20,\n title_color = “black”,\n title_font = “Roboto bold”,\n clear = TRUE\n)\n\nFig. F6.4.2 3D population density map of South America\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F64c. The book’s repository contains information about what your code should look like at this point."
  },
  {
    "objectID": "F6.html#displaying-maps-interactively",
    "href": "F6.html#displaying-maps-interactively",
    "title": "7  Advanced Topics",
    "section": "20.2 Displaying Maps Interactively",
    "text": "20.2 Displaying Maps Interactively\nSimilar to the Code Editor, rgee supports the interactive visualization of spatial Earth Engine objects by Map$addLayer. First, let’s import the rgee and cptcity packages. The cptcity R package is a wrapper to the cpt-city color gradients web archive.\nlibrary(rgee)\nlibrary(cptcity)\nee_Initialize()\nWe’ll select an ee$Image; in this case, the Shuttle Radar Topography Mission 90 m (SRTM-90) Version 4.\ndem <- ee\\(Image\\)Dataset$CGIAR_SRTM90_V4\nThen, we’ll set the visualization parameters as a list with the following elements.\n\nmin: value(s) to map to 0\nmax: value(s) to map to 1\npalette: a list of CSS-style color strings\n\nviz <- list(\n min = 600,\n max = 6000,\n palette = cpt(pal = ‘grass_elevation’, rev = TRUE)\n)\nThen, we’ll create a simple display using Map$addLayer.\nm1 <- Map$addLayer(dem, visParams = viz, name = “SRTM”, shown = TRUE)\nOptionally, you could add a custom legend using Map$addLayer (Fig. F6.4.3).\npal <- Map$addLegend(viz)\nm1 + pal\n\nFig. F6.4.3 Interactive visualization of SRTM-90 Version 4 elevation values\nThe procedure to display ee\\(Geometry, ee\\)Feature, and ee\\(FeatureCollections objects is similar to the previous example effected on an ee\\)Image. Users just need to change the arguments: eeObject and visParams.\nFirst, Earth Engine geometries (Fig. F6.4.4).\nvector <- ee\\(Geometry\\)Point(-77.011,-11.98) %>%\n ee\\(Feature\\)buffer(50*1000)\nMap\\(centerObject(vector) Map\\)addLayer(vector) # eeObject is a ee\\(Geometry\\)Polygon.\n\nFig. F6.4.4 A polygon buffer surrounding the city of Lima, Peru\nNext, Earth Engine feature collections (Fig. F6.4.5).\nbuilding <- ee\\(FeatureCollection\\)Dataset$\n GOOGLE_Research_open-buildings_v1_polygon\nMap\\(setCenter(3.389, 6.492, 17) Map\\)addLayer(building) # eeObject is a ee$FeatureCollection\n\nFig. F6.4.5 Building footprints in Lagos, Nigeria\nThe rgee functionality also supports the display of ee\\(ImageCollection via Map\\)addLayers (note the extra “s” at the end). Map\\(addLayers will use the same visualization parameters for all the images (Fig. F6.4.6). If you need different visualization parameters per image, use a Map\\)addLayer within a for loop."
  },
  {
    "objectID": "F6.html#synthesis-4",
    "href": "F6.html#synthesis-4",
    "title": "7  Advanced Topics",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. Estimate the Gaussian curvature map from a digital elevation model using rgee and rgeeExtra. Hint: Use the module ‘users/joselucassafanelli/TAGEE:TAGEE-functions’."
  },
  {
    "objectID": "F6.html#conclusion-3",
    "href": "F6.html#conclusion-3",
    "title": "7  Advanced Topics",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned how to use Earth Engine and R in the same workflow. Since rgee uses reticulate, rgee also permits integration with third-party Earth Engine Python packages. You also learned how to use Map$addLayer, which works similarly to the Earth Engine User Interface API (Code Editor). Finally, we also introduced rgeeExtra, a new R package that extends the Earth Engine API and supports JavaScript module execution."
  },
  {
    "objectID": "F6.html#references-4",
    "href": "F6.html#references-4",
    "title": "7  Advanced Topics",
    "section": "References",
    "text": "References\nAybar C, Wu Q, Bautista L, et al (2020) rgee: An R package for interacting with Google Earth Engine. J Open Source Softw 5:2272. https://doi.org/10.21105/joss.02272\nErmida SL, Soares P, Mantas V, et al (2020) Google Earth Engine open-source code for land surface temperature estimation from the Landsat series. Remote Sens 12:1471. https://doi.org/10.3390/RS12091471\nGrolemund G (2014) Hands-On Programming with R - Write Your Own Functions and Simulations. O’Reilly Media, Inc.\nLovelace R, Nowosad J, Muenchow J (2019) Geocomputation with R. Chapman and Hall/CRC\nMontero D (2021) eemont: A Python package that extends Google Earth Engine. J Open Source Softw 6:3168. https://doi.org/10.21105/joss.03168\nPebesma E, Bivand R (2019) Spatial Data Science. https://r-spatial.org/book/"
  },
  {
    "objectID": "F5.html",
    "href": "F5.html",
    "title": "6  Vectors and Tables",
    "section": "",
    "text": "7 Exploring Vectors\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information"
  },
  {
    "objectID": "F5.html#author",
    "href": "F5.html#author",
    "title": "6  Vectors and Tables",
    "section": "Author",
    "text": "Author\nAJ Purdy, Ellen Brock, David Saah\nOverview\nIn this chapter, you will learn about features and feature collections and how to use them in conjunction with images and image collections in Earth Engine. Maps are useful for understanding spatial patterns, but scientists often need to extract statistics to answer a question. For example, you may make a false-color composite showing which areas of San Francisco are more “green”—i.e., have more healthy vegetation—than others, but you will likely not be able to directly determine which block in a neighborhood is the most green. This tutorial will demonstrate how to do just that by utilizing vectors.\nAs described in Chap. F4.0, an important way to summarize and simplify data in Earth Engine is through the use of reducers. Reducers operating across space were used in Chap. F3.0, for example, to enable image regression between bands. More generally, chapters in Part F3 and Part F4 used reducers mostly to summarize the values across bands or images on a pixel-by-pixel basis. What if you wanted to summarize information within the confines of given spatial elements- for example, within a set of polygons? In this chapter, we will illustrate and explore Earth Engine’s method for doing that, which is through a reduceRegions call.\nLearning Outcomes\n\nUploading and working with a shapefile as an asset to use in Earth Engine.\nCreating a new feature using the geometry tools.\nImporting and filtering a feature collection in Earth Engine.\nUsing a feature to clip and reduce image values within a geometry.\nUse reduceRegions to summarize an image in irregular neighborhoods.\nExporting calculated data to tables with Tasks.\n\nAssumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nCalculate and interpret vegetation indices (Chap. F2.0).\nUse drawing tools to create points, lines, and polygons (Chap. F2.1).\n\nIntroduction to Theory \nIn the world of geographic information systems (GIS), data is typically thought of in one of two basic data structures: raster and vector. In previous chapters, we have principally been focused on raster data—data using the remote sensing vocabulary of pixels, spatial resolution, images, and image collections. Working within the vector framework is also a crucial skill to master. If you don’t know much about GIS, you can find any number of online explainers of the distinctions between these data types, their strengths and limitations, and analyses using both data types. Being able to move fluidly between a raster conception and a vector conception of the world is powerful, and is facilitated with specialized functions and approaches in Earth Engine.    \nFor our purposes, you can think of vector data as information represented as points (e.g., locations of sample sites), lines (e.g., railroad tracks), or polygons (e.g., the boundary of a national park or a neighborhood). Line data and polygon data are built up from points: for example, the latitude and longitude of the sample sites, the points along the curve of the railroad tracks, and the corners of the park that form its boundary. These points each have a highly specific location on Earth’s surface, and the vector data formed from them can be used for calculations with respect to other layers. As will be seen in this chapter, for example, a polygon can be used to identify which pixels in an image are contained within its borders. Point-based data have already been used in earlier chapters for filtering image collections by location (see Part F1), and can also be used to extract values from an image at a point or a set of points (see Chap. F5.2). Lines possess the dimension of length and have similar capabilities for filtering image collections and accessing their values along a transect. In addition to using polygons to summarize values within a boundary, they can be used for other, similar purposes—for example, to clip an image.\nAs you have seen, raster features in Earth Engine are stored as an Image or as part of an ImageCollection. Using a similar conceptual model, vector data in Earth Engine is stored as a Feature or as part of a FeatureCollection. Features and feature collections provide useful data to filter images and image collections by their location, clip images to a boundary, or statistically summarize the pixel values within a region.\nIn the following example, you will use features and feature collections to identify which city block near the University of San Francisco (USF) campus is the most green."
  },
  {
    "objectID": "F5.html#using-geometry-tools-to-create-features-in-earth-engine",
    "href": "F5.html#using-geometry-tools-to-create-features-in-earth-engine",
    "title": "6  Vectors and Tables",
    "section": "7.1 Using Geometry Tools to Create Features in Earth Engine",
    "text": "7.1 Using Geometry Tools to Create Features in Earth Engine\nTo demonstrate how geometry tools in Earth Engine work, let’s start by creating a point, and two polygons to represent different elements on the USF campus.\nClick on the geometry tools in the top left of the Map pane and create a point feature. Place a new point where USF is located (see Fig. F5.0.1).\n\nFig. F5.0.1 Location of the USF campus in San Francisco, California. Your first point should be in this vicinity. The red arrow points to the geometry tools.\nUse Google Maps to search for “Harney Science Center” or “Lo Schiavo Center for Science.” Hover your mouse over the Geometry Imports to find the +new layer menu item and add a new layer to delineate the boundary of a building on campus.\nNext, create another new layer to represent the entire campus as a polygon.\nAfter you create these layers, rename the geometry imports at the top of your script. Name the layers usf_point, usf_building, and usf_campus. These names are used within the script shown in Fig. F5.0.2.\n\nFig. F5.0.2 Rename the default variable names for each layer in the Imports section of the code at the top of your script\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F50a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#loading-existing-features-and-feature-collections-in-earth-engine",
    "href": "F5.html#loading-existing-features-and-feature-collections-in-earth-engine",
    "title": "6  Vectors and Tables",
    "section": "7.2 Loading Existing Features and Feature Collections in Earth Engine",
    "text": "7.2 Loading Existing Features and Feature Collections in Earth Engine\nIf you wish to have the exact same geometry imports in this chapter for the rest of this exercise, begin this section using the code at the Code Checkpoint above.\nNext, you will load a city block dataset to determine the amount of vegetation on blocks near USF. The code below imports an existing feature dataset in Earth Engine. The Topologically Integrated Geographic Encoding and Referencing (TIGER) boundaries are census-designated boundaries that are a useful resource when comparing socioeconomic and diversity metrics with environmental datasets in the United States.\n// Import the Census Tiger Boundaries from GEE.\nvar tiger = ee.FeatureCollection(‘TIGER/2010/Blocks’);\n// Add the new feature collection to the map, but do not display.\nMap.addLayer(tiger, {   ‘color’: ‘black’}, ‘Tiger’, false);\nYou should now have the geometry for USF’s campus and a layer added to your map that is not visualized for census blocks across the United States. Next, we will use neighborhood data to spatially filter the TIGER feature collection for blocks near USF’s campus."
  },
  {
    "objectID": "F5.html#importing-features-into-earth-engine",
    "href": "F5.html#importing-features-into-earth-engine",
    "title": "6  Vectors and Tables",
    "section": "7.3 Importing Features into Earth Engine",
    "text": "7.3 Importing Features into Earth Engine\nThere are many image collections loaded in Earth Engine, and they can cover a very large area that you might want to study. Borders can be quite intricate (for example, a detailed coastline), and fortunately there is no need for you to digitize the intricate boundary of a large geographic area. Instead, we will show how to find a spatial dataset online, download the data, and load this into Earth Engine as an asset for use.\n\n7.3.1 Find a Spatial Dataset of San Francisco Neighborhoods\nUse your internet searching skills to locate the “Analysis Neighborhoods” dataset covering San Francisco. This data might be located in a number of places, including DataSF, the City of San Francisco’s public-facing data repository.\n\nFig. F5.0.3 DataSF website neighborhood shapefile to download\nAfter you find the Analysis Neighborhoods layer, click Export and select Shapefile (Fig. F5.0.3). Keep track of where you save the zipped file, as we will load this into Earth Engine. Shapefiles contain vector-based data—points, lines, polygons—and include a number of files, such as the location information, attribute information, and others.\nExtract the folder to your computer. When you open the folder, you will see that there are actually many files. The extensions (.shp, .dbf, .shx, .prj) all provide a different piece of information to display vector-based data. The .shp file provides data on the geometry. The .dbf file provides data about the attributes. The .shx file is an index file. Lastly, the .prj file describes the map projection of the coordinate information for the shapefile. You will need to load all four files to create a new feature asset in Earth Engine.\n\n\n7.3.2 Upload SF Neighborhoods File as an Asset\nNavigate to the Assets tab (near Scripts). Select New > Table Upload > Shape files (Fig. F5.0.4).\n\nFig. F5.0.4 Import an asset as a zipped folder\n\n\n7.3.3 Select Files and Name Asset\nClick the Select button and then use the file navigator to select the component files of the shapefile structure (i.e., .shp, .dbf, .shx, and .prj) (Fig. F5.0.5). Assign an Asset Name so you can recognize this asset.\n\nFig. F5.0.5 Select the four files extracted from the zipped folder. Make sure each file has the same name and that there are no spaces in the file names of the component files of the shapefile structure.\nUploading the asset may take a few minutes. The status of the upload is presented under the Tasks tab. After your asset has been successfully loaded, click on the asset in the Assets folder and find the collection ID. Copy this text and use it to import the file into your Earth Engine analysis.\nAssign the asset to the table (collection) ID using the script below. Note that you will need to replace ‘path/to/your/asset/assetname’ with the actual path copied in the previous step.\n// Assign the feature collection to the variable sfNeighborhoods.\nvar sfNeighborhoods = ee.FeatureCollection(   ‘path/to/your/asset/assetname’);\n// Print the size of the feature collection.\n// (Answers the question how many features?)\nprint(sfNeighborhoods.size());\nMap.addLayer(sfNeighborhoods, {   ‘color’: ‘blue’}, ‘sfNeighborhoods’);\nNote that if you have any trouble with loading the FeatureCollection using the technique above, you can follow directions in the Checkpoint script below to use an existing asset loaded for this exercise.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F50b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#filtering-feature-collections-by-attributes",
    "href": "F5.html#filtering-feature-collections-by-attributes",
    "title": "6  Vectors and Tables",
    "section": "7.4 Filtering Feature Collections by Attributes",
    "text": "7.4 Filtering Feature Collections by Attributes\n\n7.4.1 Filter by Geometry of Another Feature\nFirst, let’s find the neighborhood associated with USF. Use the first point you created to find the neighborhood that intersects this point; filterBounds is the tool that does that, returning a filtered feature.\n// Filter sfNeighborhoods by USF.\nvar usfNeighborhood = sfNeighborhoods.filterBounds(usf_point);\nNow, filter the blocks layer by USF’s neighborhood and visualize it on the map.\n// Filter the Census blocks by the boundary of the neighborhood layer.\nvar usfTiger = tiger.filterBounds(usfNeighborhood);\nMap.addLayer(usfTiger, {}, ‘usf_Tiger’);\n\n\n7.4.2 Filter by Feature (Attribute) Properties\nIn addition to filtering a FeatureCollection by the location of another feature, you can also filter it by its properties. First, let’s print the usfTiger variable to the Console and inspect the object.\nprint(usfTiger);\nYou can click on the feature collection name in the Console to uncover more information about the dataset. Click on the columns to learn about what attribute information is contained in this dataset. You will notice this feature collection contains information on both housing (‘housing10’) and population (‘pop10’).\nNow you will filter for blocks with just the right amount of housing units. You don’t want it too dense, nor do you want too few neighbors.\nFilter the blocks to have fewer than 250 housing units.\n// Filter for census blocks by housing units.\nvar housing10_l250 = usfTiger\n   .filter(ee.Filter.lt(‘housing10’, 250));\nNow filter the already-filtered blocks to have more than 50 housing units.\nvar housing10_g50_l250 = housing10_l250.filter(ee.Filter.gt(   ‘housing10’, 50));\nNow, let’s visualize what this looks like.\nMap.addLayer(housing10_g50_l250, {   ‘color’: ‘Magenta’}, ‘housing’);\nWe have combined spatial and attribute information to narrow the set to only those blocks that meet our criteria of having between 50 and 250 housing units.\n\n\n7.4.3 Print Feature (Attribute) Properties to Console\nWe can print out attribute information about these features. The block of code below prints out the area of the resultant geometry in square meters.\nvar housing_area = housing10_g50_l250.geometry().area();\nprint(‘housing_area:’, housing_area);\nThe next block of code reduces attribute information and prints out the mean of the housing10 column.\nvar housing10_mean = usfTiger.reduceColumns({\n   reducer: ee.Reducer.mean(),\n   selectors: [‘housing10’]\n});\nprint(‘housing10_mean’, housing10_mean);\nBoth of the above sections of code provide meaningful information about each feature, but they do not tell us which block is the most green. The next section will address that question.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F50c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#reducing-images-using-feature-geometry",
    "href": "F5.html#reducing-images-using-feature-geometry",
    "title": "6  Vectors and Tables",
    "section": "7.5 Reducing Images Using Feature Geometry",
    "text": "7.5 Reducing Images Using Feature Geometry\nNow that we have identified the blocks around USF’s campus that have the right housing density, let’s find which blocks are the greenest.\nThe Normalized Difference Vegetation Index (NDVI), presented in detail in Chap. F2.0, is often used to compare the greenness of pixels in different locations. Values on land range from 0 to 1, with values closer to 1 representing healthier and greener vegetation than values near 0.\n\n7.5.1 Create an NDVI Image\nThe code below imports the Landsat 8 ImageCollection as landsat8. Then, the code filters for images in 2021. Lastly, the code sorts the images from 2021 to find the least cloudy day.\n// Import the Landsat 8 TOA image collection.\nvar landsat8 = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_TOA’);\n// Get the least cloudy image in 2015.\nvar image = ee.Image(\n   landsat8\n   .filterBounds(usf_point)\n   .filterDate(‘2015-01-01’, ‘2015-12-31’)\n   .sort(‘CLOUD_COVER’)\n   .first());\nThe next section of code assigns the near-infrared band (B5) to variable nir and assigns the red band (B4) to red. Then the bands are combined together to compute NDVI as (nir − red)/(nir + red).\nvar nir = image.select(‘B5’);\nvar red = image.select(‘B4’);\nvar ndvi = nir.subtract(red).divide(nir.add(red)).rename(‘NDVI’);\n\n\n7.5.2 Clip the NDVI Image to the Blocks Near USF\nNext, you will clip the NDVI layer to only show NDVI over USF’s neighborhood.\nThe first section of code provides visualization settings.\nvar ndviParams = {\n   min: -1,\n   max: 1,\n   palette: [‘blue’, ‘white’, ‘green’]\n};\nThe second block of code clips the image to our filtered housing layer.\nvar ndviUSFblocks = ndvi.clip(housing10_g50_l250);\nMap.addLayer(ndviUSFblocks, ndviParams, ‘NDVI image’);\nMap.centerObject(usf_point, 14);\nThe NDVI map for all of San Francisco is interesting, and shows variability across the region. Now, let’s compute mean NDVI values for each block of the city.\n\n\n7.5.3 Compute NDVI Statistics by Block\nThe code below uses the clipped image ndviUSFblocks and computes the mean NDVI value within each boundary. The scale provides a spatial resolution for the mean values to be computed on.\n// Reduce image by feature to compute a statistic e.g. mean, max, min etc.\nvar ndviPerBlock = ndviUSFblocks.reduceRegions({\n   collection: housing10_g50_l250,\n   reducer: ee.Reducer.mean(),\n   scale: 30,\n});\nNow we’ll use Earth Engine to find out which block is greenest.  \n\n\n7.5.4 Export Table of NDVI Data by Block from Earth Engine to Google Drive\nJust as we loaded a feature into Earth Engine, we can export information from Earth Engine. Here, we will export the NDVI data, summarized by block, from Earth Engine to a Google Drive space so that we can interpret it in a program like Google Sheets or Excel.\n// Get a table of data out of Google Earth Engine.\nExport.table.toDrive({\n   collection: ndviPerBlock,\n   description: ‘NDVI_by_block_near_USF’\n});\nWhen you run this code, you will notice that you have the Tasks tab highlighted on the top right of the Earth Engine Code Editor (Fig. F5.0.6). You will be prompted to name the directory when exporting the data.\n\nFig. F5.0.6 Under the Tasks tab, select Run to initiate download\nAfter you run the task, the file will be saved to your Google Drive. You have now brought a feature into Earth Engine and also exported data from Earth Engine.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F50d. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#identifying-the-block-in-the-neighborhood-surrounding-usf-with-the-highest-ndvi",
    "href": "F5.html#identifying-the-block-in-the-neighborhood-surrounding-usf-with-the-highest-ndvi",
    "title": "6  Vectors and Tables",
    "section": "7.6 Identifying the Block in the Neighborhood Surrounding USF with the Highest NDVI",
    "text": "7.6 Identifying the Block in the Neighborhood Surrounding USF with the Highest NDVI\nYou are already familiar with filtering datasets by their attributes. Now you will sort a table and select the first element of the table.\nndviPerBlock = ndviPerBlock.select([‘blockid10’, ‘mean’]);\nprint(‘ndviPerBlock’, ndviPerBlock);\nvar ndviPerBlockSorted = ndviPerBlock.sort(‘mean’, false);\nvar ndviPerBlockSortedFirst = ee.Feature(ndviPerBlock.sort(‘mean’,       false) //Sort by NDVI mean in descending order.   .first()); //Select the block with the highest NDVI.\nprint(‘ndviPerBlockSortedFirst’, ndviPerBlockSortedFirst);\nIf you expand the feature of ndviPerBlockSortedFirst in the Console, you will be able to identify the blockid10 value of the greenest block and the mean NDVI value for that area.\nAnother way to look at the data is by exporting the data to a table. Open the table using Google Sheets or Excel. You should see a column titled “mean.” Sort the mean column in descending order from highest NDVI to lowest NDVI, then use the blockid10 attribute to filter our feature collection one last time and display the greenest block near USF.\n// Now filter by block and show on map!\nvar GreenHousing = usfTiger.filter(ee.Filter.eq(‘blockid10’,\n‘###’)); //< Put your id here prepend a 0!\nMap.addLayer(GreenHousing, {   ‘color’: ‘yellow’}, ‘Green Housing!’);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F50e. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#synthesis",
    "href": "F5.html#synthesis",
    "title": "6  Vectors and Tables",
    "section": "Synthesis",
    "text": "Synthesis\nNow it’s your turn to use both feature classes and to reduce data using a geographic boundary. Create a new script for an area of interest and accomplish the following assignments.\nAssignment 1. Create a study area map zoomed to a certain feature class that you made.\nAssignment 2. Filter one feature collection using feature properties.\nAssignment 3. Filter one feature collection based on another feature’s location in space.\nAssignment 4. Reduce one image to the geometry of a feature in some capacity; e.g., extract a mean value or a value at a point."
  },
  {
    "objectID": "F5.html#conclusion",
    "href": "F5.html#conclusion",
    "title": "6  Vectors and Tables",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned how to import features into Earth Engine. In Sect. 1, you created new features using the geometry tools and loaded a feature from Earth Engine’s Data Catalog. In Sect. 2, you loaded a shapefile to an Earth Engine asset. In Sect. 3, you filtered feature collections based on their properties and locations. Finally, in Sects. 4 and 5, you used a feature collection to reduce an image, then exported the data from Earth Engine. Now you have all the tools you need to load, filter, and apply features to extract meaningful information from images using vector features in Earth Engine."
  },
  {
    "objectID": "F5.html#author-1",
    "href": "F5.html#author-1",
    "title": "6  Vectors and Tables",
    "section": "Author",
    "text": "Author\nKeiko Nomura, Samuel Bowers"
  },
  {
    "objectID": "F5.html#overview",
    "href": "F5.html#overview",
    "title": "6  Vectors and Tables",
    "section": "Overview",
    "text": "Overview\n \nThe purpose of this chapter is to review methods of converting between raster and vector data formats, and to understand the circumstances in which this is useful. By way of example, this chapter focuses on topographic elevation and forest cover change in Colombia, but note that these are generic methods that can be applied in a wide variety of situations."
  },
  {
    "objectID": "F5.html#learning-outcomes",
    "href": "F5.html#learning-outcomes",
    "title": "6  Vectors and Tables",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUnderstanding raster and vector data in Earth Engine and their differing properties.\nKnowing how and why to convert from raster to vector.\nKnowing how and why to convert from vector to raster.\nWrite a function and map it over a FeatureCollection."
  },
  {
    "objectID": "F5.html#assumes-you-know-how-to",
    "href": "F5.html#assumes-you-know-how-to",
    "title": "6  Vectors and Tables",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nUnderstand distinctions among Image, ImageCollection, Feature and FeatureCollection Earth Engine objects (Part F1, Part F2, Part F5).\nPerform basic image analysis: select bands, compute indices, create masks (Part F2).\nPerform image morphological operations (Chap. F3.2).\nUnderstand the filter, map, reduce paradigm (Chap. F4.0).\nWrite a function and map it over an ImageCollection (Chap. F4.0).\nUse reduceRegions to summarize an image in irregular shapes (Chap. F5.0)."
  },
  {
    "objectID": "F5.html#introduction-to-theory",
    "href": "F5.html#introduction-to-theory",
    "title": "6  Vectors and Tables",
    "section": "9.1 Introduction to Theory ",
    "text": "9.1 Introduction to Theory \nAnyone working with field data collected at plots will likely need to summarize raster-based data associated with those plots. For instance, they need to know the Normalized Difference Vegetation Index (NDVI), precipitation, or elevation for each plot (or surrounding region). Calculating statistics from a raster within given regions is called zonal statistics. Zonal statistics were calculated in Chaps. F5.0 and F5.1 using ee.Image.ReduceRegions. Here, we present a more general approach to calculating zonal statistics with a custom function that works for both ee.Image and ee.ImageCollection objects. In addition to its flexibility, the reduction method used here is less prone to “Computed value is too large” errors that can occur when using ReduceRegions with very large or complex ee.FeatureCollection object inputs.\nThe zonal statistics function in this chapter works for an Image or an ImageCollection. Running the function over an ImageCollection will produce a table with values from each image in the collection per point. Image collections can be processed before extraction as needed—for example, by masking clouds from satellite imagery or by constraining the dates needed for a particular research question. In this tutorial, the data extracted from rasters are exported to a table for analysis, where each row of the table corresponds to a unique point-image combination.\nIn fieldwork, researchers often work with plots, which are commonly recorded as polygon files or as a center point with a set radius. It is rare that plots will be set directly in the center of pixels from your desired raster dataset, and many field GPS units have positioning errors. Because of these issues, it may be important to use a statistic of adjacent pixels (as described in Chap. F3.2) to estimate the central value in what’s often called a neighborhood mean or focal mean (Cansler and McKenzie 2012, Miller and Thode 2007).\nTo choose the size of your neighborhood, you will need to consider your research questions, the spatial resolution of the dataset, the size of your field plot, and the error from your GPS. For example, the raster value extracted for randomly placed 20 m diameter plots would likely merit use of a neighborhood mean when using Sentinel-2 or Landsat 8—at 10 m and 30 m spatial resolution, respectively—while using a thermal band from MODIS (Moderate Resolution Imaging Spectroradiometer) at 1000 m may not. While much of this tutorial is written with plot points and buffers in mind, a polygon asset with predefined regions will serve the same purpose."
  },
  {
    "objectID": "F5.html#raster-to-vector-conversion",
    "href": "F5.html#raster-to-vector-conversion",
    "title": "6  Vectors and Tables",
    "section": "8.1 Raster to Vector Conversion ",
    "text": "8.1 Raster to Vector Conversion \n\n8.1.1 Raster to Polygons\nIn this section we will convert an elevation image (raster) to a feature collection (vector). We will start by loading the Global Multi-Resolution Terrain Elevation Data 2010 and the Global Administrative Unit Layers 2015 dataset to focus on Colombia. The elevation image is a raster at 7.5 arc-second spatial resolution containing a continuous measure of elevation in meters in each pixel.\n// Load raster (elevation) and vector (colombia) datasets.\nvar elevation = ee.Image(‘USGS/GMTED2010’).rename(‘elevation’);\nvar colombia = ee.FeatureCollection(       ‘FAO/GAUL_SIMPLIFIED_500m/2015/level0’)\n   .filter(ee.Filter.equals(‘ADM0_NAME’, ‘Colombia’));\n// Display elevation image.\nMap.centerObject(colombia, 7);\nMap.addLayer(elevation, {\n   min: 0,\n   max: 4000}, ‘Elevation’);\nWhen converting an image to a feature collection, we will aggregate the categorical elevation values into a set of categories to create polygon shapes of connected pixels with similar elevations. For this exercise, we will create four zones of elevation by grouping the altitudes to 0-100 m = 0, 100–200 m = 1, 200–500 m = 2, and >500 m = 3.\n// Initialize image with zeros and define elevation zones.\nvar zones = ee.Image(0)\n   .where(elevation.gt(100), 1)\n   .where(elevation.gt(200), 2)\n   .where(elevation.gt(500), 3);\n// Mask pixels below sea level (<= 0 m) to retain only land areas.\n// Name the band with values 0-3 as ‘zone’.\nzones = zones.updateMask(elevation.gt(0)).rename(‘zone’);\nMap.addLayer(zones, {\n   min: 0,\n   max: 3,\n   palette: [‘white’, ‘yellow’, ‘lime’, ‘green’],\n   opacity: 0.7}, ‘Elevation zones’);\nWe will convert this zonal elevation image in Colombia to polygon shapes, which is a vector format (termed a FeatureCollection in Earth Engine), using the ee.Image.reduceToVectors method. This will create polygons delineating connected pixels with the same value. In doing so, we will use the same projection and spatial resolution as the image. Please note that loading the vectorized image in the native resolution (231.92 m) takes time to execute. For faster visualization, we set a coarse scale of 1,000 m.\nvar projection = elevation.projection();\nvar scale = elevation.projection().nominalScale();\nvar elevationVector = zones.reduceToVectors({\n   geometry: colombia.geometry(),\n   crs: projection,\n   scale: 1000, // scale   geometryType: ‘polygon’,\n   eightConnected: false,\n   labelProperty: ‘zone’,\n   bestEffort: true,\n   maxPixels: 1e13,\n   tileScale: 3 // In case of error.\n});\nprint(elevationVector.limit(10));\nvar elevationDrawn = elevationVector.draw({\n   color: ‘black’,\n   strokeWidth: 1\n});\nMap.addLayer(elevationDrawn, {}, ‘Elevation zone polygon’);\n\n\n\n\nFig. F5.1.1 Raster-based elevation (top left) and zones (top right), vectorized elevation zones overlaid on the raster (bottom-left) and vectorized elevation zones only (bottom-right)\nYou may have realized that polygons consist of complex lines, including some small polygons with just one pixel. That happens when there are no surrounding pixels of the same elevation zone. You may not need a vector map with such details—if, for instance, you want to produce a regional or global map. We can use a morphological reducer focalMode to simplify the shape by defining a neighborhood size around a pixel. In this example, we will set the kernel radius as four pixels. This operation makes the resulting polygons look much smoother, but less precise (Fig. F5.1.2).\nvar zonesSmooth = zones.focalMode(4, ‘square’);\nzonesSmooth = zonesSmooth.reproject(projection.atScale(scale));\nMap.addLayer(zonesSmooth, {\n   min: 1,\n   max: 3,\n   palette: [‘yellow’, ‘lime’, ‘green’],\n   opacity: 0.7}, ‘Elevation zones (smooth)’);\nvar elevationVectorSmooth = zonesSmooth.reduceToVectors({\n   geometry: colombia.geometry(),\n   crs: projection,\n   scale: scale,\n   geometryType: ‘polygon’,\n   eightConnected: false,\n   labelProperty: ‘zone’,\n   bestEffort: true,\n   maxPixels: 1e13,\n   tileScale: 3\n});\nvar smoothDrawn = elevationVectorSmooth.draw({\n   color: ‘black’,\n   strokeWidth: 1\n});\nMap.addLayer(smoothDrawn, {}, ‘Elevation zone polygon (smooth)’);\nWe can see now that the polygons have more distinct shapes with many fewer small polygons in the new map (Fig. F5.1.2). It is important to note that when you use methods like focalMode (or other, similar methods such as connectedComponents and connectedPixelCount), you need to reproject according to the original image in order to display properly with zoom using the interactive Code Editor.\n\n\nFig. F5.1.2 Before (left) and after (right) applying focalMode\n\n\n8.1.2 Raster to Points\nLastly, we will convert a small part of this elevation image into a point vector dataset. For this exercise, we will use the same example and build on the code from the previous subsection. This might be useful when you want to use geospatial data in a tabular format in combination with other conventional datasets such as economic indicators (Fig. F5.1.3).\n\n\nFig. F5.1.3 Elevation point values with latitude and longitude\nThe easiest way to do this is to use sample while activating the geometries parameter. This will extract the points at the centroid of the elevation pixel.\nvar geometry = ee.Geometry.Polygon([\n   [-89.553, -0.929],\n   [-89.436, -0.929],\n   [-89.436, -0.866],\n   [-89.553, -0.866],\n   [-89.553, -0.929]\n]);\n// To zoom into the area, un-comment and run below\n// Map.centerObject(geometry,12);\nMap.addLayer(geometry, {}, ‘Areas to extract points’);\nvar elevationSamples = elevation.sample({\n   region: geometry,\n   projection: projection,\n   scale: scale,\n   geometries: true,\n});\nMap.addLayer(elevationSamples, {}, ‘Points extracted’);\n// Add three properties to the output table:\n// ‘Elevation’, ‘Longitude’, and ‘Latitude’.\nelevationSamples = elevationSamples.map(function(feature) {   var geom = feature.geometry().coordinates();   return ee.Feature(null, {       ‘Elevation’: ee.Number(feature.get(           ‘elevation’)),       ‘Long’: ee.Number(geom.get(0)),       ‘Lat’: ee.Number(geom.get(1))\n   });\n});\n// Export as CSV.\nExport.table.toDrive({\n   collection: elevationSamples,\n   description: ‘extracted_points’,\n   fileFormat: ‘CSV’\n});\nWe can also extract sample points per elevation zone. Below is an example of extracting 10 randomly selected points per elevation zone (Fig. F5.1.4). You can also set different values for each zone using classValues and classPoints parameters to modify the sampling intensity in each class. This may be useful, for instance, to generate point samples for a validation effort.\nvar elevationSamplesStratified = zones.stratifiedSample({\n   numPoints: 10,\n   classBand: ‘zone’,\n   region: geometry,\n   scale: scale,\n   projection: projection,\n   geometries: true\n});\nMap.addLayer(elevationSamplesStratified, {}, ‘Stratified samples’);\n\nFig. F5.1.4 Stratified sampling over different elevation zones\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F51a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n##3. A More Complex Example\nIn this section we’ll use two global datasets, one to represent raster formats and the other vectors:\n\nThe Global Forest Change (GFC) dataset: a raster dataset describing global tree cover and change for 2001–present.\nThe World Protected Areas Database: a vector database of global protected areas.\n\nThe objective will be to combine these two datasets to quantify rates of deforestation in protected areas in the “arc of deforestation” of the Colombian Amazon. The datasets can be loaded into Earth Engine with the following code:\n// Read input data.\n// Note: these datasets are periodically updated.\n// Consider searching the Data Catalog for newer versions.\nvar gfc = ee.Image(‘UMD/hansen/global_forest_change_2020_v1_8’);\nvar wdpa = ee.FeatureCollection(‘WCMC/WDPA/current/polygons’);\n// Print assets to show available layers and properties.\nprint(gfc);\nprint(wdpa.limit(10)); // Show first 10 records.\nThe GFC dataset (first presented in detail in Chap. F1.1) is a global set of rasters that quantify tree cover and change for the period beginning in 2001. We’ll use a single image from this dataset:\n\n‘lossyear’: a categorical raster of forest loss (1–20, corresponding to deforestation for the period 2001–2020), and 0 for no change\n\nThe World Database on Protected Areas (WDPA) is a harmonized dataset of global terrestrial and marine protected area locations, along with details on the classification and management of each. In addition to protected area outlines, we’ll use two fields from this database:\n\n‘NAME’’: the name of each protected area\n‘WDPA_PID’: a unique numerical ID for each protected area\n\nTo begin with, we’ll focus on forest change dynamics in ‘La Paya’, a small protected area in the Colombian Amazon. We’ll first visualize these data using the paint command, which is discussed in more detail in Chap. F5.3:\n// Display deforestation.\nvar deforestation = gfc.select(‘lossyear’);\nMap.addLayer(deforestation, {\n   min: 1,\n   max: 20,\n   palette: [‘yellow’, ‘orange’, ‘red’]\n}, ‘Deforestation raster’);\n// Display WDPA data.\nvar protectedArea = wdpa.filter(ee.Filter.equals(‘NAME’, ‘La Paya’));\n// Display protected area as an outline (see F5.3 for paint()).\nvar protectedAreaOutline = ee.Image().byte().paint({\n   featureCollection: protectedArea,\n   color: 1,\n   width: 3\n});\nMap.addLayer(protectedAreaOutline, {\n   palette: ‘white’}, ‘Protected area’);\n// Set up map display.\nMap.centerObject(protectedArea);\nMap.setOptions(‘SATELLITE’);\nThis will display the boundary of the La Paya protected area and deforestation in the region (Fig. F5.1.5).\n\nFig. F5.1.5 View of the La Paya protected area in the Colombian Amazon (in white), and deforestation over the period 2001–2020 (in yellows and reds, with darker colors indicating more recent changes)\nWe can use Earth Engine to convert the deforestation raster to a set of polygons. The deforestation data are appropriate for this transformation as each deforestation event is labeled categorically by year, and change events are spatially contiguous. This is performed in Earth Engine using the ee.Image.reduceToVectors method, as described earlier in this section.  \n// Convert from a deforestation raster to vector.\nvar deforestationVector = deforestation.reduceToVectors({\n   scale: deforestation.projection().nominalScale(),\n   geometry: protectedArea.geometry(),\n   labelProperty: ‘lossyear’, // Label polygons with a change year.   maxPixels: 1e13\n});\n// Count the number of individual change events\nprint(‘Number of change events:’, deforestationVector.size());\n// Display deforestation polygons. Color outline by change year.\nvar deforestationVectorOutline = ee.Image().byte().paint({\n   featureCollection: deforestationVector,\n   color: ‘lossyear’,\n   width: 1\n});\nMap.addLayer(deforestationVectorOutline, {\n   palette: [‘yellow’, ‘orange’, ‘red’],\n   min: 1,\n   max: 20}, ‘Deforestation vector’);\nFig. F5.1.6 shows a comparison of the raster versus vector representations of deforestation within the protected area.\n\n\nFig. F5.1.6 Raster (left) versus vector (right) representations of deforestation data of the La Paya protected area\nHaving converted from raster to vector, a new set of operations becomes available for post-processing the deforestation data. We might, for instance, be interested in the number of individual change events each year (Fig. F5.1.7):\nvar chart = ui.Chart.feature\n   .histogram({\n       features: deforestationVector,\n       property: ‘lossyear’   })\n   .setOptions({\n       hAxis: {\n           title: ‘Year’       },\n       vAxis: {\n           title: ‘Number of deforestation events’       },\n       legend: {\n           position: ‘none’       }\n   });print(chart);\n\nFig. F5.1.7 Plot of the number of deforestation events in La Paya for the years 2001–2020\nThere might also be interest in generating point locations for individual change events (e.g., to aid a field campaign):\n// Generate deforestation point locations.\nvar deforestationCentroids = deforestationVector.map(function(feat) {   return feat.centroid();\n});\nMap.addLayer(deforestationCentroids, {\n   color: ‘darkblue’}, ‘Deforestation centroids’);\nThe vector format allows for easy filtering to only deforestation events of interest, such as only the largest deforestation events:\n// Add a new property to the deforestation FeatureCollection\n// describing the area of the change polygon.\ndeforestationVector = deforestationVector.map(function(feat) {   return feat.set(‘area’, feat.geometry().area({\n       maxError: 10   }).divide(10000)); // Convert m^2 to hectare.\n});\n// Filter the deforestation FeatureCollection for only large-scale (>10 ha) changes\nvar deforestationLarge = deforestationVector.filter(ee.Filter.gt(   ‘area’, 10));\n// Display deforestation area outline by year.\nvar deforestationLargeOutline = ee.Image().byte().paint({\n   featureCollection: deforestationLarge,\n   color: ‘lossyear’,\n   width: 1\n});\nMap.addLayer(deforestationLargeOutline, {\n   palette: [‘yellow’, ‘orange’, ‘red’],\n   min: 1,\n   max: 20}, ‘Deforestation (>10 ha)’);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F51b. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n\n\n8.1.3 Raster Properties to Vector Fields\nSometimes we want to extract information from a raster to be included in an existing vector dataset. An example might be estimating a deforestation rate for a set of protected areas. Rather than perform this task on a case-by-case basis, we can attach information generated from an image as a property of a feature.\nThe following script shows how this can be used to quantify a deforestation rate for a set of protected areas in the Colombian Amazon.\n// Load required datasets.\nvar gfc = ee.Image(‘UMD/hansen/global_forest_change_2020_v1_8’);\nvar wdpa = ee.FeatureCollection(‘WCMC/WDPA/current/polygons’);\n// Display deforestation.\nvar deforestation = gfc.select(‘lossyear’);\nMap.addLayer(deforestation, {\n   min: 1,\n   max: 20,\n   palette: [‘yellow’, ‘orange’, ‘red’]\n}, ‘Deforestation raster’);\n// Select protected areas in the Colombian Amazon.\nvar amazonianProtectedAreas = [   ‘Cordillera de los Picachos’, ‘La Paya’, ‘Nukak’,   ‘Serrania de Chiribiquete’,   ‘Sierra de la Macarena’, ‘Tinigua’\n];\nvar wdpaSubset = wdpa.filter(ee.Filter.inList(‘NAME’,\n   amazonianProtectedAreas));\n// Display protected areas as an outline.\nvar protectedAreasOutline = ee.Image().byte().paint({\n   featureCollection: wdpaSubset,\n   color: 1,\n   width: 1\n});\nMap.addLayer(protectedAreasOutline, {\n   palette: ‘white’}, ‘Amazonian protected areas’);\n// Set up map display.\nMap.centerObject(wdpaSubset);\nMap.setOptions(‘SATELLITE’);\nvar scale = deforestation.projection().nominalScale();\n// Use ‘reduceRegions’ to sum together pixel areas in each protected area.\nwdpaSubset = deforestation.gte(1)\n   .multiply(ee.Image.pixelArea().divide(10000)).reduceRegions({\n       collection: wdpaSubset,\n       reducer: ee.Reducer.sum().setOutputs([           ‘deforestation_area’]),\n       scale: scale\n   });\nprint(wdpaSubset); // Note the new ‘deforestation_area’ property.\nThe output of this script is an estimate of deforested area in hectares for each reserve. However, as reserve sizes vary substantially by area, we can normalize by the total area of each reserve to quantify rates of change.\n// Normalize by area.\nwdpaSubset = wdpaSubset.map(   function(feat) {       return feat.set(‘deforestation_rate’,           ee.Number(feat.get(‘deforestation_area’))\n           .divide(feat.area().divide(10000)) // m2 to ha           .divide(20) // number of years           .multiply(100)); // to percentage points   });// Print to identify rates of change per protected area.\n// Which has the fastest rate of loss?\nprint(wdpaSubset.reduceColumns({\n   reducer: ee.Reducer.toList().repeat(2),\n   selectors: [‘NAME’, ‘deforestation_rate’]\n}));\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F51c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#vector-to-raster-conversion",
    "href": "F5.html#vector-to-raster-conversion",
    "title": "6  Vectors and Tables",
    "section": "8.2 Vector-to-Raster Conversion",
    "text": "8.2 Vector-to-Raster Conversion\nIn Sect. 1, we used the protected area feature collection as its original vector format. In this section, we will rasterize the protected area polygons to produce a mask and use this to assess rates of forest change.\n\n8.2.1 Polygons to a Mask\nThe most common operation to convert from vector to raster is the production of binary image masks, describing whether a pixel intersects a line or falls within a polygon. To convert from vector to a raster mask, we can use the ee.FeatureCollection.reduceToImage method. Let’s continue with our example of the WDPA database and Global Forest Change data from the previous section:\n// Load required datasets.\nvar gfc = ee.Image(‘UMD/hansen/global_forest_change_2020_v1_8’);\nvar wdpa = ee.FeatureCollection(‘WCMC/WDPA/current/polygons’);\n// Get deforestation.\nvar deforestation = gfc.select(‘lossyear’);\n// Generate a new property called ‘protected’ to apply to the output mask.\nvar wdpa = wdpa.map(function(feat) {   return feat.set(‘protected’, 1);\n});\n// Rasterize using the new property.\n// unmask() sets areas outside protected area polygons to 0.\nvar wdpaMask = wdpa.reduceToImage([‘protected’], ee.Reducer.first())\n   .unmask();\n// Center on Colombia.\nMap.setCenter(-75, 3, 6);\n// Display on map.\nMap.addLayer(wdpaMask, {\n   min: 0,\n   max: 1}, ‘Protected areas (mask)’);\nWe can use this mask to, for example, highlight only deforestation that occurs within a protected area using logical operations:\n// Set the deforestation layer to 0 where outside a protected area.\nvar deforestationProtected = deforestation.where(wdpaMask.eq(0), 0);\n// Update mask to hide where deforestation layer = 0\nvar deforestationProtected = deforestationProtected\n   .updateMask(deforestationProtected.gt(0));\n// Display deforestation in protected areas\nMap.addLayer(deforestationProtected, {\n   min: 1,\n   max: 20,\n   palette: [‘yellow’, ‘orange’, ‘red’]\n}, ‘Deforestation protected’);\nIn the above example we generated a simple binary mask, but reduceToImage can also preserve a numerical property of the input polygons. For example, we might want to be able to determine which protected area each pixel represents. In this case, we can produce an image with the unique ID of each protected area:\n// Produce an image with unique ID of protected areas.\nvar wdpaId = wdpa.reduceToImage([‘WDPAID’], ee.Reducer.first());\nMap.addLayer(wdpaId, {\n   min: 1,\n   max: 100000}, ‘Protected area ID’);\nThis output can be useful when performing large-scale raster operations, such as efficiently calculating deforestation rates for multiple protected areas.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F51d. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n\n\n8.2.2 A More Complex Example\nThe reduceToImage method is not the only way to convert a feature collection to an image. We will create a distance image layer from the boundary of the protected area using distance. For this example, we return to the La Paya protected area explored in Sect. 1.\n// Load required datasets.\nvar gfc = ee.Image(‘UMD/hansen/global_forest_change_2020_v1_8’);\nvar wdpa = ee.FeatureCollection(‘WCMC/WDPA/current/polygons’);\n// Select a single protected area.\nvar protectedArea = wdpa.filter(ee.Filter.equals(‘NAME’, ‘La Paya’));\n// Maximum distance in meters is set in the brackets.\nvar distance = protectedArea.distance(1000000);\nMap.addLayer(distance, {\n   min: 0,\n   max: 20000,\n   palette: [‘white’, ‘grey’, ‘black’],\n   opacity: 0.6}, ‘Distance’);\nMap.centerObject(protectedArea);\nWe can also show the distance inside and outside of the boundary by using the rasterized protected area (Fig. F5.1.8).\n// Produce a raster of inside/outside the protected area.\nvar protectedAreaRaster = protectedArea.map(function(feat) {   return feat.set(‘protected’, 1);\n}).reduceToImage([‘protected’], ee.Reducer.first());\nMap.addLayer(distance.updateMask(protectedAreaRaster), {\n   min: 0,\n   max: 20000}, ‘Distance inside protected area’);\nMap.addLayer(distance.updateMask(protectedAreaRaster.unmask()\n.not()), {\n   min: 0,\n   max: 20000}, ‘Distance outside protected area’);\n\n\n\nFig. F5.1.8 Distance from the La Paya boundary (left), distance within the La Paya (middle), and distance outside the La Paya (right)\nSometimes it makes sense to work with objects in raster imagery. This is an unusual case of vector-like operations conducted with raster data. There is a good reason for this where the vector equivalent would be computationally burdensome.\nAn example of this is estimating deforestation rates by distance to the edge of the protected area, as it is common that rates of change will be higher at the boundary of a protected area. We will create a distance raster with three zones from the La Paya boundary (>1 km, >2 km, >3 km, and >4 km) and to estimate the deforestation by distance from the boundary (Fig. F5.1.9).\nvar distanceZones = ee.Image(0)\n   .where(distance.gt(0), 1)\n   .where(distance.gt(1000), 2)\n   .where(distance.gt(3000), 3)\n   .updateMask(distance.lte(5000));\nMap.addLayer(distanceZones, {}, ‘Distance zones’);\nvar deforestation = gfc.select(‘loss’);\nvar deforestation1km = deforestation.updateMask(distanceZones.eq(1));\nvar deforestation3km = deforestation.updateMask(distanceZones.lte(2));\nvar deforestation5km = deforestation.updateMask(distanceZones.lte(3));\nMap.addLayer(deforestation1km, {\n   min: 0,\n   max: 1}, ‘Deforestation within a 1km buffer’);\nMap.addLayer(deforestation3km, {\n   min: 0,\n   max: 1,\n   opacity: 0.5}, ‘Deforestation within a 3km buffer’);\nMap.addLayer(deforestation5km, {\n   min: 0,\n   max: 1,\n   opacity: 0.5}, ‘Deforestation within a 5km buffer’);\n\n\n\n\nFig. F5.1.9 Distance zones (top left) and deforestation by zone (<1 km, <3 km, and <5 km)\nLastly, we can estimate the deforestation area within 1 km of the protected area but only outside of the boundary.\nvar deforestation1kmOutside = deforestation1km\n   .updateMask(protectedAreaRaster.unmask().not());\n// Get the value of each pixel in square meters\n// and divide by 10000 to convert to hectares.\nvar deforestation1kmOutsideArea = deforestation1kmOutside.eq(1)\n   .multiply(ee.Image.pixelArea()).divide(10000);\n// We need to set a larger geometry than the protected area\n// for the geometry parameter in reduceRegion().\nvar deforestationEstimate = deforestation1kmOutsideArea\n   .reduceRegion({\n       reducer: ee.Reducer.sum(),\n       geometry: protectedArea.geometry().buffer(1000),\n       scale: deforestation.projection().nominalScale()\n   });\nprint(‘Deforestation within a 1km buffer outside the protected area (ha)’,\n   deforestationEstimate);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F51e. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#synthesis-1",
    "href": "F5.html#synthesis-1",
    "title": "6  Vectors and Tables",
    "section": "Synthesis",
    "text": "Synthesis\nQuestion 1. In this lab, we quantified rates of deforestation in La Paya. There is another protected area in the Colombian Amazon named Tinigua. By modifying the existing scripts, determine how the dynamics of forest change in Tinigua compare to those in La Paya with respect to:\n\nthe number of deforestation events\nthe year with the greatest number of change events\nthe mean average area of change events\nthe total area of loss\n\nQuestion 2. In Sect. 1.4, we only considered losses of tree cover, but many protected areas will also have increases in tree cover from regrowth (which is typical of shifting agriculture). Calculate growth in hectares using the Global Forest Change dataset’s gain layer for the six protected areas in Sect. 1.4 by extracting the raster properties and adding them to vector fields. Which has the greatest area of regrowth? Is this likely to be sufficient to balance out the rates of forest loss? Note: The gain layer shows locations where tree cover has increased for the period 2001–2012 (0 = no gain, 1 = tree cover increase), so for comparability use deforestation between the same time period of 2001–2012.\nQuestion 3. In Sect. 2.2, we considered rates of deforestation in a buffer zone around La Paya. Estimate the deforestation rates inside of La Paya using buffer zones. Is forest loss more common close to the boundary of the reserve?\nQuestion 4. Sometimes it’s advantageous to perform processing using raster operations, particularly at large scales. It is possible to perform many of the tasks in Sect. 1.3 and 1.4 by first converting the protected area vector to raster, and then using only raster operations. As an example, can you display only deforestation events >10 ha in La Paya using only raster data? (Hint: Consider using ee.Image.connectedPixelCount. You may also want to also look at Sect. 2.1)."
  },
  {
    "objectID": "F5.html#conclusion-1",
    "href": "F5.html#conclusion-1",
    "title": "6  Vectors and Tables",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned how to convert raster to vector and vice versa. More importantly, you now have a better understanding of why and when such conversions are useful. Our examples should give you practical applications and ideas for using these techniques."
  },
  {
    "objectID": "F5.html#author-2",
    "href": "F5.html#author-2",
    "title": "6  Vectors and Tables",
    "section": "Author",
    "text": "Author\n \nSara Winsemius and Justin Braaten"
  },
  {
    "objectID": "F5.html#overview-1",
    "href": "F5.html#overview-1",
    "title": "6  Vectors and Tables",
    "section": "Overview",
    "text": "Overview\nThe purpose of this chapter is to extract values from rasters for intersecting points or polygons. We will lay out the process and a function to calculate zonal statistics, which includes optional parameters to modify the function, and then apply the process to three examples using different raster datasets and combinations of parameters."
  },
  {
    "objectID": "F5.html#learning-outcomes-1",
    "href": "F5.html#learning-outcomes-1",
    "title": "6  Vectors and Tables",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n \n\nBuffering points as square or circular regions.\nWriting and applying functions with optional parameters.\nLearning what zonal statistics are and how to use reducers.\nExporting computation results to a table.\nCopying properties from one image to another."
  },
  {
    "objectID": "F5.html#assumes-you-know-how-to-1",
    "href": "F5.html#assumes-you-know-how-to-1",
    "title": "6  Vectors and Tables",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nRecognize similarities and differences among Landsat 5, 7, and 8 spectral bands (Part F1, Part F2, Part F3).\nUnderstand distinctions among Image, ImageCollection, Feature and FeatureCollection Earth Engine objects (Part F1, Part F2, Part F5).\nUse drawing tools to create points, lines, and polygons (Chap. F2.1).\nWrite a function and map it over an ImageCollection (Chap. F4.0).\nMask cloud, cloud shadow, snow/ice, and other undesired pixels (Chap. F4.3).\nExport calculated data to tables with Tasks (Chap. F5.0).\nUnderstand the differences between raster and vector data (Chap. F5.0, Chap. F5.1).\nWrite a function and map it over a FeatureCollection (Chap. F5.1)."
  },
  {
    "objectID": "F5.html#introduction-to-theory-1",
    "href": "F5.html#introduction-to-theory-1",
    "title": "6  Vectors and Tables",
    "section": "9.1 Introduction to Theory ",
    "text": "9.1 Introduction to Theory \nAnyone working with field data collected at plots will likely need to summarize raster-based data associated with those plots. For instance, they need to know the Normalized Difference Vegetation Index (NDVI), precipitation, or elevation for each plot (or surrounding region). Calculating statistics from a raster within given regions is called zonal statistics. Zonal statistics were calculated in Chaps. F5.0 and F5.1 using ee.Image.ReduceRegions. Here, we present a more general approach to calculating zonal statistics with a custom function that works for both ee.Image and ee.ImageCollection objects. In addition to its flexibility, the reduction method used here is less prone to “Computed value is too large” errors that can occur when using ReduceRegions with very large or complex ee.FeatureCollection object inputs.\nThe zonal statistics function in this chapter works for an Image or an ImageCollection. Running the function over an ImageCollection will produce a table with values from each image in the collection per point. Image collections can be processed before extraction as needed—for example, by masking clouds from satellite imagery or by constraining the dates needed for a particular research question. In this tutorial, the data extracted from rasters are exported to a table for analysis, where each row of the table corresponds to a unique point-image combination.\nIn fieldwork, researchers often work with plots, which are commonly recorded as polygon files or as a center point with a set radius. It is rare that plots will be set directly in the center of pixels from your desired raster dataset, and many field GPS units have positioning errors. Because of these issues, it may be important to use a statistic of adjacent pixels (as described in Chap. F3.2) to estimate the central value in what’s often called a neighborhood mean or focal mean (Cansler and McKenzie 2012, Miller and Thode 2007).\nTo choose the size of your neighborhood, you will need to consider your research questions, the spatial resolution of the dataset, the size of your field plot, and the error from your GPS. For example, the raster value extracted for randomly placed 20 m diameter plots would likely merit use of a neighborhood mean when using Sentinel-2 or Landsat 8—at 10 m and 30 m spatial resolution, respectively—while using a thermal band from MODIS (Moderate Resolution Imaging Spectroradiometer) at 1000 m may not. While much of this tutorial is written with plot points and buffers in mind, a polygon asset with predefined regions will serve the same purpose."
  },
  {
    "objectID": "F5.html#functions",
    "href": "F5.html#functions",
    "title": "6  Vectors and Tables",
    "section": "9.2 Functions",
    "text": "9.2 Functions\nTwo functions are provided; copy and paste them into your script:\n\nA function to generate circular or square regions from buffered points\nA function to extract image pixel neighborhood statistics for a given region\n\n\n9.2.1 Function: bufferPoints(radius, bounds)\nOur first function, bufferPoints, returns a function for adding a buffer to points and optionally transforming to rectangular bounds (see Table F5.2.1).\nTable F5.2.1 Parameters for bufferPoints\nParameter\nType\nDescription\nradius\nNumber\nbuffer radius (m).\n[bounds=false]\nBoolean\nAn optional flag indicating whether to transform buffered point (i.e., a circle) to square bounds.\nfunction bufferPoints(radius, bounds) {   return function(pt) {\n       pt = ee.Feature(pt);       return bounds ? pt.buffer(radius).bounds() : pt.buffer(\n           radius);\n   };\n}\n\n\n9.2.2 Function: zonalStats(fc, params)\nThe second function, zonalStats, reduces images in an ImageCollection by regions defined in a FeatureCollection. Note that reductions can return null statistics that you might want to filter out of the resulting feature collection. Null statistics occur when there are no valid pixels intersecting the region being reduced. This situation can be caused by points that are outside of an image or in regions that are masked for quality or clouds.\nThis function is written to include many optional parameters (see Table F5.2.2). Look at the function carefully and note how it is written to include defaults that make it easy to apply the basic function while allowing customization.\nTable F5.2.2 Parameters for zonalStats\nParameter\nType\nDescription\nic\nee.ImageCollection\nImage collection from which to extract values.\nfc\nee.FeatureCollection\nFeature collection that provides regions/zones by which to reduce image pixels.\n[params]\nObject\nAn optional Object that provides function arguments.\n[params.reducer=ee.Reducer.mean()]\nee.Reducer\nThe reducer to apply. Optional.\n[params.scale=null]\nNumber\nA nominal scale in meters of the projection to work in. If null, the native nominal image scale is used. Optional.\n[params.crs=null]\nString\nThe projection to work in. If null, the native image Coordinate Reference System (CRS) is used. Optional.\n[params.bands=null]\nArray\nA list of image band names for which to reduce values. If null, all bands will be reduced. Band names define column names in the resulting reduction table. Optional.\n[params.bandsRename=null]\nArray\nA list of desired image band names. The length and order must correspond to the params.bands list. If null, band names will be unchanged. Band names define column names in the resulting reduction table. Optional.\n[params.imgProps=null]\nArray\nA list of image properties to include in the table of region reduction results. If null, all image properties are included. Optional.\n[params.imgPropsRename=null]\nArray\nA list of image property names to replace those provided by params.imgProps. The length and order must match the params.imgProps entries. Optional.\n[params.datetimeName=’datetime]\nString\nThe desired name of the datetime field. The datetime refers to the ‘system:time_start’ value of the ee.Image being reduced. Optional.\n[params.datetimeFormat=’YYYY-MM-dd HH:mm:ss]\nString\nThe desired datetime format. Use ISO 8601 data string standards. The datetime string is derived from the ‘system:time_start’ value of the ee.Image being reduced. Optional.\nfunction zonalStats(ic, fc, params) {   // Initialize internal params dictionary.   var _params = {\n       reducer: ee.Reducer.mean(),\n       scale: null,\n       crs: null,\n       bands: null,\n       bandsRename: null,\n       imgProps: null,\n       imgPropsRename: null,\n       datetimeName: ‘datetime’,\n       datetimeFormat: ‘YYYY-MM-dd HH:mm:ss’   };   // Replace initialized params with provided params.   if (params) {       for (var param in params) {\n           _params[param] = params[param] || _params[param];\n       }\n   }   // Set default parameters based on an image representative.   var imgRep = ic.first();   var nonSystemImgProps = ee.Feature(null)\n       .copyProperties(imgRep).propertyNames();   if (!_params.bands) _params.bands = imgRep.bandNames();   if (!_params.bandsRename) _params.bandsRename = _params.bands;   if (!_params.imgProps) _params.imgProps = nonSystemImgProps;   if (!_params.imgPropsRename) _params.imgPropsRename = _params\n       .imgProps;   // Map the reduceRegions function over the image collection.   var results = ic.map(function(img) {       // Select bands (optionally rename), set a datetime & timestamp property.       img = ee.Image(img.select(_params.bands, _params\n               .bandsRename))           // Add datetime and timestamp features.           .set(_params.datetimeName, img.date().format(\n               _params.datetimeFormat))           .set(‘timestamp’, img.get(‘system:time_start’));       // Define final image property dictionary to set in output features.       var propsFrom = ee.List(_params.imgProps)           .cat(ee.List([_params.datetimeName,           ‘timestamp’]));       var propsTo = ee.List(_params.imgPropsRename)           .cat(ee.List([_params.datetimeName,           ‘timestamp’]));       var imgProps = img.toDictionary(propsFrom).rename(\n           propsFrom, propsTo);       // Subset points that intersect the given image.       var fcSub = fc.filterBounds(img.geometry());       // Reduce the image by regions.       return img.reduceRegions({\n               collection: fcSub,\n               reducer: _params.reducer,               scale: _params.scale,               crs: _params.crs\n           })           // Add metadata to each feature.           .map(function(f) {               return f.set(imgProps);\n           });       // Converts the feature collection of feature collections to a single       //feature collection.   }).flatten();   return results;\n}"
  },
  {
    "objectID": "F5.html#point-collection-creation",
    "href": "F5.html#point-collection-creation",
    "title": "6  Vectors and Tables",
    "section": "9.3 Point Collection Creation",
    "text": "9.3 Point Collection Creation\nBelow, we create a set of points that form the basis of the zonal statistics calculations. Note that a unique plot_id property is added to each point. A unique plot or point ID is important to include in your vector dataset for future filtering and joining.\nvar pts = ee.FeatureCollection([   ee.Feature(ee.Geometry.Point([-118.6010, 37.0777]), {\n       plot_id: 1   }),   ee.Feature(ee.Geometry.Point([-118.5896, 37.0778]), {\n       plot_id: 2   }),   ee.Feature(ee.Geometry.Point([-118.5842, 37.0805]), {\n       plot_id: 3   }),   ee.Feature(ee.Geometry.Point([-118.5994, 37.0936]), {\n       plot_id: 4   }),   ee.Feature(ee.Geometry.Point([-118.5861, 37.0567]), {\n       plot_id: 5   })\n]);print(‘Points of interest’, pts);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F52a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#neighborhood-statistic-examples",
    "href": "F5.html#neighborhood-statistic-examples",
    "title": "6  Vectors and Tables",
    "section": "9.4 Neighborhood Statistic Examples",
    "text": "9.4 Neighborhood Statistic Examples\nThe following examples demonstrate extracting raster neighborhood statistics for the following:\n\nA single raster with elevation and slope bands\nA multiband MODIS time series\nA multiband Landsat time series\n\nIn each example, the points created in the previous section will be buffered and then used as regions to extract zonal statistics for each image in the image collection.\n\n9.4.1 Topographic Variables\nThis example demonstrates how to calculate zonal statistics for a single multiband image. This Digital Elevation Model (DEM) contains a single topographic band representing elevation.\n###Buffer the Points\nNex, we will apply a 45 m radius buffer to the points defined previously by mapping the bufferPoints function over the feature collection. The radius is set to 45 m to correspond to the 90 m pixel resolution of the DEM. In this case, circles are used instead of squares (set the second argument as false, i.e., do not use bounds).\n// Buffer the points.\nvar ptsTopo = pts.map(bufferPoints(45, false));\n###Calculate Zonal Statistics\nThere are two important things to note about the zonalStats function that this example addresses:\n\nIt accepts only an ee.ImageCollection, not an ee.Image; single images must be wrapped in an ImageCollection.\nIt expects every image in the input image collection to have a timestamp property named ‘system:time_start’ with values representing milliseconds from 00:00:00 UTC on 1 January 1970. Most datasets should have this property, if not, one should be added.\n\n// Import the MERIT global elevation dataset.\nvar elev = ee.Image(‘MERIT/DEM/v1_0_3’);\n// Calculate slope from the DEM.\nvar slope = ee.Terrain.slope(elev);\n// Concatenate elevation and slope as two bands of an image.\nvar topo = ee.Image.cat(elev, slope)\n    // Computed images do not have a ‘system:time_start’ property; add one based\n    // on when the data were collected.   .set(‘system:time_start’, ee.Date(‘2000-01-01’).millis());\n// Wrap the single image in an ImageCollection for use in the\n// zonalStats function.\nvar topoCol = ee.ImageCollection([topo]);\nDefine arguments for the zonalStats function and then run it. Note that we are accepting defaults for the reducer, scale, Coordinate Reference System (CRS), and image properties to copy over to the resulting feature collection. Refer to the function definition above for defaults.\n// Define parameters for the zonalStats function.\nvar params = {\n   bands: [0, 1],\n   bandsRename: [‘elevation’, ‘slope’]\n};\n// Extract zonal statistics per point per image.\nvar ptsTopoStats = zonalStats(topoCol, ptsTopo, params);print(‘Topo zonal stats table’, ptsTopoStats);\n// Display the layers on the map.\nMap.setCenter(-118.5957, 37.0775, 13);\nMap.addLayer(topoCol.select(0), {\n   min: 2400,\n   max: 4200}, ‘Elevation’);\nMap.addLayer(topoCol.select(1), {\n   min: 0,\n   max: 60}, ‘Slope’);\nMap.addLayer(pts, {\n   color: ‘purple’}, ‘Points’);\nMap.addLayer(ptsTopo, {\n   color: ‘yellow’}, ‘Points w/ buffer’);\nThe result is a copy of the buffered point feature collection with new properties added for the region reduction of each selected image band according to the given reducer. A part of the FeatureCollection is shown in Fig. F5.2.1. The data in that FeatureCollection corresponds to a table containing the information of Table F5.2.3. See Fig. F5.2.2 for a graphical representation of the points and the topographic data being summarized.\n\nFig. F5.2.1 A part of the FeatureCollection produced by calculating the zonal statistics\n\nFig. F5.2.2 Sample points and topographic slope. Elevation and slope values for regions intersecting each buffered point are reduced and attached as properties of the points.\nTable F5.2.3 Example output from zonalStats organized as a table. Rows correspond to collection features and columns are feature properties. Note that elevation and slope values in this table are rounded to the nearest tenth for brevity.\nplot_id\ntimestamp\ndatetime\nelevation\nslope\n1\n946684800000\n2000-01-01 00:00:00\n2648.1\n29.7\n2\n946684800000\n2000-01-01 00:00:00\n2888.2\n33.9\n3\n946684800000\n2000-01-01 00:00:00\n3267.8\n35.8\n4\n946684800000\n2000-01-01 00:00:00\n2790.7\n25.1\n5\n946684800000\n2000-01-01 00:00:00\n2559.4\n29.4\n\n\n9.4.2 MODIS Time Series\nA time series of MODIS eight-day surface reflectance composites demonstrates how to calculate zonal statistics for a multiband ImageCollection that requires no preprocessing, such as cloud masking or computation. Note that there is no built-in function for performing region reductions on ImageCollection objects. The zonalStats function that we are using for reduction is mapping the reduceRegions function over an ImageCollection.\n###Buffer the Points\nIn this example, suppose the point collection represents center points for field plots that are 100 m x 100 m, and apply a 50 m radius buffer to the points to match the size of the plot. Since we want zonal statistics for square plots, set the second argument of the bufferPoints function to true, so that the bounds of the buffered points are returned.\nvar ptsModis = pts.map(bufferPoints(50, true));\n###Calculate Zonal Statistic\nImport the MODIS 500 m global eight-day surface reflectance composite collection and filter the collection to include data for July, August, and September from 2015 through 2019.\nvar modisCol = ee.ImageCollection(‘MODIS/006/MOD09A1’)\n   .filterDate(‘2015-01-01’, ‘2020-01-01’)\n   .filter(ee.Filter.calendarRange(183, 245, ‘DAY_OF_YEAR’));\nReduce each image in the collection by each plot according to the following parameters. Note that this time the reducer is defined as the neighborhood median (ee.Reducer.median) instead of the default mean, and that scale, CRS, and properties for the datetime are explicitly defined.\n// Define parameters for the zonalStats function.\nvar params = {\n   reducer: ee.Reducer.median(),\n   scale: 500,\n   crs: ‘EPSG:5070’,\n   bands: [‘sur_refl_b01’, ‘sur_refl_b02’, ‘sur_refl_b06’],\n   bandsRename: [‘modis_red’, ‘modis_nir’, ‘modis_swir’],\n   datetimeName: ‘date’,\n   datetimeFormat: ‘YYYY-MM-dd’\n};\n// Extract zonal statistics per point per image.\nvar ptsModisStats = zonalStats(modisCol, ptsModis, params);print(‘Limited MODIS zonal stats table’, ptsModisStats.limit(50));\nThe result is a feature collection with a feature for all combinations of plots and images. Interpreted as a table, the result has 200 rows (5 plots times 40 images) and as many columns as there are feature properties. Feature properties include those from the plot asset and the image, and any associated non-system image properties. Note that the printed results are limited to the first 50 features for brevity.\n\n\n9.4.3 Landsat Time Series\nThis example combines Landsat surface reflectance imagery across three instruments: Thematic Mapper (TM) from Landsat 5, Enhanced Thematic Mapper Plus (ETM+) from Landsat 7, and Operational Land Imager (OLI) from Landsat 8.\nThe following section prepares these collections so that band names are consistent and cloud masks are applied. Reflectance among corresponding bands are roughly congruent for the three sensors when using the surface reflectance product; therefore the processing steps that follow do not address inter-sensor harmonization. Review the current literature on inter-sensor harmonization practices if you’d like to apply a correction.\n###Prepare the Landsat Image Collection\nFirst, define the function to mask cloud and shadow pixels (See Chap. F4.3 for more detail on cloud masking).\n// Mask clouds from images and apply scaling factors.\nfunction maskScale(img) {   var qaMask = img.select(‘QA_PIXEL’).bitwiseAnd(parseInt(‘11111’,       2)).eq(0);   var saturationMask = img.select(‘QA_RADSAT’).eq(0);   // Apply the scaling factors to the appropriate bands.   var getFactorImg = function(factorNames) {       var factorList = img.toDictionary().select(factorNames)\n           .values();       return ee.Image.constant(factorList);\n   };   var scaleImg = getFactorImg([‘REFLECTANCE_MULT_BAND_.’]);   var offsetImg = getFactorImg([‘REFLECTANCE_ADD_BAND_.’]);   var scaled = img.select(‘SR_B.’).multiply(scaleImg).add(\n   offsetImg);   // Replace the original bands with the scaled ones and apply the masks.   return img.addBands(scaled, null, true)\n       .updateMask(qaMask)\n       .updateMask(saturationMask);\n}\nNext, define functions to select and rename the bands of interest for the Operational Land Imager (OLI) aboard Landsat 8, and for the TM/ETM+ imagers aboard earlier Landsats. This is important because the band numbers are different for OLI and TM/ETM+, and it will make future index calculations easier.\n// Selects and renames bands of interest for Landsat OLI.\nfunction renameOli(img) {   return img.select(\n       [‘SR_B2’, ‘SR_B3’, ‘SR_B4’, ‘SR_B5’, ‘SR_B6’, ‘SR_B7’],\n       [‘Blue’, ‘Green’, ‘Red’, ‘NIR’, ‘SWIR1’, ‘SWIR2’]);\n}\n// Selects and renames bands of interest for TM/ETM+.\nfunction renameEtm(img) {   return img.select(\n       [‘SR_B1’, ‘SR_B2’, ‘SR_B3’, ‘SR_B4’, ‘SR_B5’, ‘SR_B7’],\n       [‘Blue’, ‘Green’, ‘Red’, ‘NIR’, ‘SWIR1’, ‘SWIR2’]);\n}\nCombine the cloud mask and band renaming functions into preparation functions for OLI and TM/ETM+. Add any other sensor-specific preprocessing steps that you’d like to the functions below.\n// Prepares (cloud masks and renames) OLI images.\nfunction prepOli(img) {\n   img = maskScale(img);\n   img = renameOli(img);   return img;\n}// Prepares (cloud masks and renames) TM/ETM+ images.\nfunction prepEtm(img) {\n   img = maskScale(img);\n   img = renameEtm(img);   return img;\n}\nGet the Landsat surface reflectance collections for OLI, ETM+, and TM sensors. Filter them by the bounds of the point feature collection and apply the relevant image preparation function.\nvar ptsLandsat = pts.map(bufferPoints(15, true));\nvar oliCol = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterBounds(ptsLandsat)\n   .map(prepOli);\nvar etmCol = ee.ImageCollection(‘LANDSAT/LE07/C02/T1_L2’)\n   .filterBounds(ptsLandsat)\n   .map(prepEtm);\nvar tmCol = ee.ImageCollection(‘LANDSAT/LT05/C02/T1_L2’)\n   .filterBounds(ptsLandsat)\n   .map(prepEtm);\nMerge the prepared sensor collections.\nvar landsatCol = oliCol.merge(etmCol).merge(tmCol);\n###Calculate Zonal Statistics\nReduce each image in the collection by each plot according to the following parameters. Note that this example defines the imgProps and imgPropsRename parameters to copy over and rename just two selected image properties: Landsat image ID and the satellite that collected the data. It also uses the max reducer, which, as an unweighted reducer, will return the maximum value from pixels that have their centroid within the buffer (see Sect. 4.1 below for more details).\n// Define parameters for the zonalStats function.\nvar params = {\n   reducer: ee.Reducer.max(),\n   scale: 30,\n   crs: ‘EPSG:5070’,\n   bands: [‘Blue’, ‘Green’, ‘Red’, ‘NIR’, ‘SWIR1’, ‘SWIR2’],\n   bandsRename: [‘ls_blue’, ‘ls_green’, ‘ls_red’, ‘ls_nir’,       ‘ls_swir1’, ‘ls_swir2’   ],\n   imgProps: [‘SENSOR_ID’, ‘SPACECRAFT_ID’],\n   imgPropsRename: [‘img_id’, ‘satellite’],\n   datetimeName: ‘date’,\n   datetimeFormat: ‘YYYY-MM-dd’\n};\n// Extract zonal statistics per point per image.\nvar ptsLandsatStats = zonalStats(landsatCol, ptsLandsat, params)   // Filter out observations where image pixels were all masked.   .filter(ee.Filter.notNull(params.bandsRename));\nprint(‘Limited Landsat zonal stats table’, ptsLandsatStats.limit(50));\nThe result is a feature collection with a feature for all combinations of plots and images.\n###Dealing with Large Collections\nIf your browser times out, try exporting the results (as described in Chap. F6.2). It’s likely that point feature collections that cover a large area or contain many points (point-image observations) will need to be exported as a batch task by either exporting the final feature collection as an asset or as a CSV/shapefile/GeoJSON to Google Drive or GCS.\nHere is how you would export the above Landsat image-point feature collection to an asset and to Google Drive. Run the following code, activate the Code Editor Tasks tab, and then click the Run button. If you don’t specify your own existing folder in Drive, the folder “EEFA_outputs” will be created.\nExport.table.toAsset({\n   collection: ptsLandsatStats,\n   description: ‘EEFA_export_Landsat_to_points’,\n   assetId: ‘EEFA_export_values_to_points’\n});\nExport.table.toDrive({\n   collection: ptsLandsatStats,\n   folder: ‘EEFA_outputs’, // this will create a new folder if it doesn’t exist   description: ‘EEFA_export_values_to_points’,\n   fileFormat: ‘CSV’\n});\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F52b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#additional-notes",
    "href": "F5.html#additional-notes",
    "title": "6  Vectors and Tables",
    "section": "9.5 Additional Notes",
    "text": "9.5 Additional Notes\n\n9.5.1 Weighted Versus Unweighted Region Reduction\nA region used for calculation of zonal statistics often bisects multiple pixels. Should partial pixels be included in zonal statistics? Earth Engine lets you decide by allowing you to define a reducer as either weighted or unweighted (or you can provide per-pixel weight specification as an image band). A weighted reducer will include partial pixels in the zonal statistic calculation by weighting each pixel’s contribution according to the fraction of the area intersecting the region. An unweighted reducer, on the other hand, gives equal weight to all pixels whose cell center intersects the region; all other pixels are excluded from calculation of the statistic.\nFor aggregate reducers like ee.Reducer.mean and ee.Reducer.median, the default mode is weighted, while identifier reducers such as ee.Reducer.min and ee.Reducer.max are unweighted. You can adjust the behavior of weighted reducers by calling unweighted on them, as in ee.Reducer.mean.unweighted. You may also specify the weights by modifying the reducer with splitWeights; however, that is beyond the scope of this book.\n\n\n9.5.2 Copy Properties to Computed Images\nDerived, computed images do not retain the properties of their source image, so be sure to copy properties to computed images if you want them included in the region reduction table. For instance, consider the simple computation of unscaling Landsat SR data:\n// Define a Landsat image.\nvar img = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’).first();\n// Print its properties.\nprint(‘All image properties’, img.propertyNames());\n// Subset the reflectance bands and unscale them.\nvar computedImg = img.select(‘SR_B.’).multiply(0.0000275).add(-0.2);\n// Print the unscaled image’s properties.\nprint(‘Lost original image properties’, computedImg.propertyNames());\nNotice how the computed image does not have the source image’s properties and only retains the bands information. To fix this, use the copyProperties function to add desired source properties to the derived image. It is best practice to copy only the properties you really need because some properties, such as those containing geometry objects, lists, or feature collections, can significantly increase the computational burden for large collections.\n// Subset the reflectance bands and unscale them, keeping selected\n// source properties.\nvar computedImg = img.select(‘SR_B.’).multiply(0.0000275).add(-0.2)\n   .copyProperties(img, [‘system:time_start’, ‘LANDSAT_PRODUCT_ID’]);\n// Print the unscaled image’s properties.\nprint(‘Selected image properties retained’, computedImg\n.propertyNames());\nNow selected properties are included. Use this technique when returning computed, derived images in a mapped function, and in single-image operations.\n\n\n9.5.3 Understanding Which Pixels are Included in Polygon Statistics\nIf you want to visualize what pixels are included in a polygon for a region reducer, you can adapt the following code to use your own region (by replacing geometry), dataset, desired scale, and CRS parameters. The important part to note is that the image data you are adding to the map is reprojected using the same scale and CRS as that used in your region reduction (see Fig. F5.2.3).\n// Define polygon geometry.\nvar geometry = ee.Geometry.Polygon(\n   [\n       [\n           [-118.6019835717645, 37.079867782687884],\n           [-118.6019835717645, 37.07838698844939],\n           [-118.60036351751951, 37.07838698844939],\n           [-118.60036351751951, 37.079867782687884]\n       ]\n   ], null, false);\n// Import the MERIT global elevation dataset.\nvar elev = ee.Image(‘MERIT/DEM/v1_0_3’);\n// Define desired scale and crs for region reduction (for image display too).\nvar proj = {\n   scale: 90,\n   crs: ‘EPSG:5070’\n};\nThe count reducer will return how many pixel centers are overlapped by the polygon region, which would be the number of pixels included in any unweighted reducer statistic. You can also visualize which pixels will be included in the reduction by using the toCollection reducer on a latitude/longitude image and adding resulting coordinates as feature geometry. Be sure to specify CRS and scale for both the region reducers and the reprojected layer added to the map (see bullet list below for more details).\n// A count reducer will return how many pixel centers are overlapped by the\n// polygon region.\nvar count = elev.select(0).reduceRegion({\n   reducer: ee.Reducer.count(),\n   geometry: geometry,\n   scale: proj.scale,   crs: proj.crs\n});\nprint(‘n pixels in the reduction’, count.get(‘dem’));\n// Make a feature collection of pixel center points for those that are\n// included in the reduction.\nvar pixels = ee.Image.pixelLonLat().reduceRegion({\n   reducer: ee.Reducer.toCollection([‘lon’, ‘lat’]),\n   geometry: geometry,\n    scale: proj.scale,   crs: proj.crs\n});\nvar pixelsFc = ee.FeatureCollection(pixels.get(‘features’)).map(   function(f) {       return f.setGeometry(ee.Geometry.Point([f.get(‘lon’), f\n           .get(‘lat’)\n       ]));\n   });\n// Display layers on the map.\nMap.centerObject(geometry, 18);\nMap.addLayer(\n   elev.reproject({\n       crs: proj.crs,\n       scale: proj.scale   }),\n   {\n       min: 2500,\n       max: 3000,\n       palette: [‘blue’, ‘white’, ‘red’]\n   }, ‘Image’);\nMap.addLayer(geometry, {\n   color: ‘white’}, ‘Geometry’);\nMap.addLayer(pixelsFc, {\n   color: ‘purple’}, ‘Pixels in reduction’);\n\nFig. F5.2.3 Identifying pixels used in zonal statistics. By mapping the image and vector together, you can see which pixels are included in the unweighted statistic. For this example, three pixels would be included in the statistic because the polygon covers the center point of three pixels.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F52c. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nFinally, here are some notes on CRS and scale:\n\nEarth Engine runs reduceRegion using the projection of the image’s first band if the CRS is unspecified in the function. For imagery spanning multiple UTM zones, for example, this would lead to different origins. For some functions Earth Engine uses the default EPSG:4326. Therefore, when the opportunity is presented, such as by the reduceRegion function, it is important to specify the scale and CRS explicitly.\nThe Map default CRS is EPSG:3857. When looking closely at pixels on the map, the data layer scale and CRS should also be set explicitly. Note that zooming out after setting a relatively small scale when reprojecting may result in memory and/or timeout errors because optimized pyramid layers for each zoom level will not be used.\nSpecifying the CRS and scale in both the reduceRegion and addLayer functions allows the map visualization to align with the information printed in the Console.\nThe Earth Engine default, WGS 84 lat long (EPSG:4326), is a generic CRS that works worldwide. The code above reprojects to EPSG:5070, North American Equal Albers, which is a CRS that preserves area for North American locations. Use the CRS that is best for your use case when adapting this to your own project, or maintain (and specify) the CRS of the image using, for example, crs: ‘img.projection().crs()’."
  },
  {
    "objectID": "F5.html#synthesis-2",
    "href": "F5.html#synthesis-2",
    "title": "6  Vectors and Tables",
    "section": "Synthesis",
    "text": "Synthesis\nQuestion 1. Look at the MODIS example (Sect. 3.2), which uses the median reducer. Try modifying the reducer to be unweighted, either by specifying unweighted or using an identifier reducer like max. What happens, and why?\nQuestion 2. Calculate zonal statistics for your own buffered points or polygons using a raster and reducer of interest. Be sure to consider the spatial scale of the raster and whether a weighted or unweighted reducer would be more appropriate for your interests.\nIf the point or polygon file is stored in a local shapefile or CSV file, first upload the data to your Earth Engine assets. All columns in your vector file, such as the plot name, will be retained through this process. Once you have an Earth Engine table asset ready, import the asset into your script by hovering over the name of the asset and clicking the arrow at the right side, or by calling it in your script with the following code.\nvar pts = ee.FeatureCollection(‘users/yourUsername/yourAsset’);\nIf you prefer to define points or polygons dynamically rather than loading an asset, you can add them to your script using the geometry tools. See Chap. F2.1 and F5.0 for more detail on adding and creating vector data.\nQuestion 3. Try the code from Sect. 4.3 using the MODIS data and the first point from the pts variable. Among other modifications, you will need to create a buffer for the point, take a single MODIS image from the collection, and change visualization parameters.\n\nThink about the CRS in the code: The code reprojects to EPSG:5070, but MODIS is collected in the sinusoidal projection SR-ORG:6974. Try that CRS and describe how the image changes.\nIs the count reducer weighted or unweighted? Give an example of a circumstance to use a weighted reducer and an example for an unweighted reducer. Specify the buffer size you would use and the spatial resolution of your dataset.\n\nQuestion 4. In the examples above, only a single ee.Reducer is passed to the zonalStats function, which means that only a single statistic is calculated (for example, zonal mean or median or maximum). What if you want multiple statistics—can you alter the code in Sect. 3.1 to (1) make the point buffer 500 instead of 45; (2) add the reducer parameter to the params dictionary; and (3) as its argument, supply a combined ee.Reducer that will calculate minimum, maximum, standard deviation, and mean statistics?\nTo achieve this you’ll need to chain several ee.Reducer.combine functions together. Note that if you accept all the individual ee.Reducer and ee.Reducer.combine function defaults, you’ll run into two problems related to reducer weighting differences, and whether or not the image inputs are shared among the combined set of reducers. How can you manipulate the individual ee.Reducer and ee.Reducer.combine functions to achieve the goal of calculating multiple zonal statistics in one call to the zonalStats function?"
  },
  {
    "objectID": "F5.html#conclusion-2",
    "href": "F5.html#conclusion-2",
    "title": "6  Vectors and Tables",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you used functions containing optional parameters to extract raster values for collocated points. You also learned how to buffer points, and apply weighted and unweighted reducers to get different types of zonal statistics. These functions were applied to three examples that differed by raster dataset, reducer, spatial resolution, and scale. Lastly, you covered related topics like weighting of reducers and buffer visualization. Now you’re ready to apply these ideas to your own work!"
  },
  {
    "objectID": "F5.html#references",
    "href": "F5.html#references",
    "title": "6  Vectors and Tables",
    "section": "References",
    "text": "References\nCansler CA, McKenzie D (2012) How robust are burn severity indices when applied in a new region? Evaluation of alternate field-based and remote-sensing methods. Remote Sens 4:456–483. https://doi.org/10.3390/rs4020456\nMiller JD, Thode AE (2007) Quantifying burn severity in a heterogeneous landscape with a relative version of the delta Normalized Burn Ratio (dNBR). Remote Sens Environ 109:66–80. https://doi.org/10.1016/j.rse.2006.12.006"
  },
  {
    "objectID": "F5.html#author-3",
    "href": "F5.html#author-3",
    "title": "6  Vectors and Tables",
    "section": "Author",
    "text": "Author\n \nUjaval Gandhi"
  },
  {
    "objectID": "F5.html#overview-2",
    "href": "F5.html#overview-2",
    "title": "6  Vectors and Tables",
    "section": "Overview",
    "text": "Overview\n \nThis chapter covers advanced techniques for visualizing and analyzing vector data in Earth Engine. There are many ways to visualize feature collections, and you will learn how to pick the appropriate method to create visualizations, such as a choropleth map. We will also cover geoprocessing techniques involving multiple vector layers, such as selecting features in one layer by their proximity to features in another layer and performing spatial joins."
  },
  {
    "objectID": "F5.html#learning-outcomes-2",
    "href": "F5.html#learning-outcomes-2",
    "title": "6  Vectors and Tables",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nVisualizing any vector dataset and creating a thematic map.\nUnderstanding joins in Earth Engine.\nCarrying out geoprocessing tasks with vector layers in Earth Engine."
  },
  {
    "objectID": "F5.html#assumes-you-know-how-to-2",
    "href": "F5.html#assumes-you-know-how-to-2",
    "title": "6  Vectors and Tables",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nFilter a FeatureCollection to obtain a subset (Chap. F5.0, Chap. F5.1).\nWrite a function and map it over a FeatureCollection (Chap. F5.1, Chap. F5.2)."
  },
  {
    "objectID": "F5.html#visualizing-feature-collections",
    "href": "F5.html#visualizing-feature-collections",
    "title": "6  Vectors and Tables",
    "section": "10.1 Visualizing Feature Collections",
    "text": "10.1 Visualizing Feature Collections\nThere is a distinct difference between how rasters and vectors are visualized. While images are typically visualized based on pixel values, vector layers use feature properties (i.e., attributes) to create a visualization. Vector layers are rendered on the Map by assigning a value to the red, green, and blue channels for each pixel on the screen based on the geometry and attributes of the features. The functions used for vector data visualization in Earth Engine are listed below in increasing order of complexity.\n\nMap.addLayer: As with raster layers, you can add a FeatureCollection to the Map by specifying visualization parameters. This method supports only one visualization parameter: color. All features are rendered with the specified color.\ndraw: This function supports the parameters pointRadius and strokeWidth in addition to color. It renders all features of the layer with the specified parameters.\npaint: This is a more powerful function that can render each feature with a different color and width based on the values in the specified property.\nstyle: This is the most versatile function. It can apply a different style to each feature, including color, pointSize, pointShape, width, fillColor, and lineType.\n\nIn the exercises below, we will learn how to use each of these functions and see how they can generate different types of maps.\n\n10.1.1 Creating a Choropleth Map\nWe will use the TIGER: US Census Blocks layer, which stores census block boundaries and their characteristics within the United States, along with the San Francisco neighborhoods layer from Chap. F5.0 to create a population density map for the city of San Francisco.\nWe start by loading the census blocks and San Francisco neighborhoods layers. We use ee.Filter.bounds to filter the census blocks layer to the San Francisco boundary.\nvar blocks = ee.FeatureCollection(‘TIGER/2010/Blocks’);\nvar roads = ee.FeatureCollection(‘TIGER/2016/Roads’);\nvar sfNeighborhoods = ee.FeatureCollection(   ‘projects/gee-book/assets/F5-0/SFneighborhoods’);\nvar geometry = sfNeighborhoods.geometry();\nMap.centerObject(geometry);\n// Filter blocks to the San Francisco boundary.\nvar sfBlocks = blocks.filter(ee.Filter.bounds(geometry));\nThe simplest way to visualize this layer is to use Map.addLayer (Fig. F5.3.1). We can specify a color value in the visParams parameter of the function. Each census block polygon will be rendered with stroke and fill of the specified color. The fill color is the same as the stroke color but has a 66% opacity.\n// Visualize with a single color.\nMap.addLayer(sfBlocks, {\n   color: ‘#de2d26’}, ‘Census Blocks (single color)’);\n\nFig. F5.3.1 San Francisco census blocks\nThe census blocks table has a property named ‘pop10’ containing the population totals as of the 2010 census. We can use this to create a choropleth map showing population density. We first need to compute the population density for each feature and add it as a property. To add a new property to each feature, we can map a function over the FeatureCollection and calculate the new property called ‘pop_density’. Earth Engine provides the area function, which can calculate the area of a feature in square meters. We convert it to square miles and calculate the population density per square mile.\n// Add a pop_density column.\nvar sfBlocks = sfBlocks.map(function(f) {   // Get the polygon area in square miles.   var area_sqmi = f.area().divide(2.59e6);   var population = f.get(‘pop10’);   // Calculate population density.   var density = ee.Number(population).divide(area_sqmi);   return f.set({       ‘area_sqmi’: area_sqmi,       ‘pop_density’: density\n   });\n});\nNow we can use the paint function to create an image from this FeatureCollection using the pop_density property. The paint function needs an empty image that needs to be cast to the appropriate data type. Let’s use the aggregate_stats function to calculate basic statistics for the given column of a FeatureCollection.\n// Calculate the statistics of the newly computed column.\nvar stats = sfBlocks.aggregate_stats(‘pop_density’);\nprint(stats);\nYou will see that the population density values have a large range. We also have values that are greater than 100,000, so we need to make sure we select a data type that can store values of this size. We create an empty image and cast it to int32, which is able to hold large integer values.\nD\nThe result is an image with pixel values representing the population density of the polygons. We can now use the standard image visualization method to add this layer to the Map (Fig. F5.3.2). Then, we need to determine minimum and maximum values for the visualization parameters.A reliable technique to produce a good visualization is to find minimum and maximum values that are within one standard deviation. From the statistics that we calculated earlier, we can estimate good minimum and maximum values to be 0 and 50000, respectively.\nvar palette = [‘fee5d9’, ‘fcae91’, ‘fb6a4a’, ‘de2d26’, ‘a50f15’];\nvar visParams = {\n   min: 0,\n   max: 50000,\n   palette: palette\n};\nMap.addLayer(sfBlocksPaint.clip(geometry), visParams,   ‘Population Density’);\n\nFig. F5.3.2 San Francisco population density\n\n\n10.1.2 Creating a Categorical Map\nContinuing the exploration of styling methods, we will now learn about draw and style. These are the preferred methods of styling for points and line layers. Let’s see how we can visualize the TIGER: US Census Roads layer to create a categorical map.\nWe start by filtering the roads layer to the San Francisco boundary and using Map.addLayer to visualize it.\n// Filter roads to San Francisco boundary.\nvar sfRoads = roads.filter(ee.Filter.bounds(geometry));\nMap.addLayer(sfRoads, {\n   color: ‘blue’}, ‘Roads (default)’);\nThe default visualization renders each line using a width of 2 pixels. The draw function provides a way to specify a different line width. Let’s use it to render the layer with the same color as before but with a line width of 1 pixel (Fig. F5.3.3).\n// Visualize with draw().\nvar sfRoadsDraw = sfRoads.draw({\n   color: ‘blue’,\n   strokeWidth: 1\n});\nMap.addLayer(sfRoadsDraw, {}, ‘Roads (Draw)’);\n\n\nFig. F5.3.3 San Francisco roads rendered with a line width of 2 pixels (left) and and a line width of 1 pixel (right)\nThe road layer has a column called “MTFCC” (standing for the MAF/TIGER Feature Class Code). This contains the road priority codes, representing the various types of roads, such as primary and secondary. We can use this information to render each road segment according to its priority. The draw function doesn’t allow us to specify different styles for each feature. Instead, we need to make use of the style function.\nThe column contains string values indicating different road types as indicated in Table F5.3.1. This full list is available at the MAF/TIGER Feature Class Code Definitions page on the US Census Bureau website.\nTable F5.3.1 Census Bureau road priority codes\nMTFCC\nFeature Class\nS1100\nPrimary Road\nS1200\nSecondary Road\nS1400\nLocal Neighborhood Road, Rural Road, City Street\nS1500\nVehicular Trail\nS1630\nRamp\nS1640\nService Drive\nS1710\nWalkway/Pedestrian Trail\nS1720\nStairway\nS1730\nAlley\nS1740\nPrivate Road for service vehicles\nS1750\nInternal U.S. Census Bureau use\nS1780\nParking Lot Road\nS1820\nBike Path or Trail\nS1830\nBridle Path\nS2000\nRoad Median\nLet’s say we want to create a map with rules based on the MTFCC values shown in Table F5.3.2.\nTable F5.3.2 Styling Parameters for Road Priority Codes\nMTFCC\nColor\nLine Width\nS1100\nBlue\n3\nS1200\nGreen\n2\nS1400\nOrange\n1\nAll Other Classes\nGray\n1\nLet’s define a dictionary containing the styling information.\nvar styles = ee.Dictionary({   ‘S1100’: {       ‘color’: ‘blue’,       ‘width’: 3   },   ‘S1200’: {       ‘color’: ‘green’,       ‘width’: 2   },   ‘S1400’: {       ‘color’: ‘orange’,       ‘width’: 1   }\n});var defaultStyle = {\n   color: ‘gray’,   ‘width’: 1\n};\nThe style function needs a property in the FeatureCollection that contains a dictionary with the style parameters. This allows you to specify a different style for each feature. To create a new property, we map a function over the FeatureCollection and assign an appropriate style dictionary to a new property named ‘style’. Note the use of the get function, which allows us to fetch the value for a key in the dictionary. It also takes a default value in case the specified key does not exist. We make use of this to assign different styles to the three road classes specified in Table 5.3.2 and a default style to all others.\nvar sfRoads = sfRoads.map(function(f) {   var classcode = f.get(‘mtfcc’);   var style = styles.get(classcode, defaultStyle);   return f.set(‘style’, style);\n});\nOur collection is now ready to be styled. We call the style function to specify the property that contains the dictionary of style parameters. The output of the style function is an RGB image rendered from the FeatureCollection (Fig. F5.3.4).\nvar sfRoadsStyle = sfRoads.style({\n   styleProperty: ‘style’\n});\nMap.addLayer(sfRoadsStyle.clip(geometry), {}, ‘Roads (Style)’);\n\nFig. F5.3.4 San Francisco roads rendered according to road priority\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F53a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nSave your script for your own future use, as outlined in Chap. F1.0. Then, refresh the Code Editor to begin with a new script for the next section."
  },
  {
    "objectID": "F5.html#joins-with-feature-collections",
    "href": "F5.html#joins-with-feature-collections",
    "title": "6  Vectors and Tables",
    "section": "10.2 Joins with Feature Collections",
    "text": "10.2 Joins with Feature Collections\nEarth Engine was designed as a platform for processing raster data, and that is where it shines. Over the years, it has acquired advanced vector data processing capabilities, and users are now able to carry out complex geoprocessing tasks within Earth Engine. You can leverage the distributed processing power of Earth Engine to process large vector layers in parallel.\nThis section shows how you can do spatial queries and spatial joins using multiple large feature collections. This requires the use of joins. As described for Image Collections in Chap. F4.9, a join allows you to match every item in a collection with items in another collection based on certain conditions. While you can achieve similar results using map and filter, joins perform better and give you more flexibility. We need to define the following items to perform a join on two collections.\n\nFilter: A filter defines the condition used to select the features from the two collections. There is a suite of filters in the ee.Filters module that work on two collections, such as ee.Filter.equals and ee.Filter.withinDistance.\nJoin type: While the filter determines which features will be joined, the join type determines how they will be joined. There are many join types, including simple join, inner join, and save-all join.\n\nJoins are one of the harder skills to master, but doing so will help you perform many complex analysis tasks within Earth Engine. We will go through practical examples that will help you understand these concepts and the workflow better.\n\n10.2.1 Selecting by Location\nIn this section, we will learn how to select features from one layer that are within a specified distance from features in another layer. We will continue to work with the San Francisco census blocks and roads datasets from the previous section. We will implement a join to select all blocks in San Francisco that are within 1 km of an interstate highway.\nWe start by loading the census blocks and roads collections and filtering the roads layer to the San Francisco boundary.\nvar blocks = ee.FeatureCollection(‘TIGER/2010/Blocks’);\nvar roads = ee.FeatureCollection(‘TIGER/2016/Roads’);\nvar sfNeighborhoods = ee.FeatureCollection(   ‘projects/gee-book/assets/F5-0/SFneighborhoods’);\nvar geometry = sfNeighborhoods.geometry();\nMap.centerObject(geometry);\n// Filter blocks and roads to San Francisco boundary.\nvar sfBlocks = blocks.filter(ee.Filter.bounds(geometry));\nvar sfRoads = roads.filter(ee.Filter.bounds(geometry));\nAs we want to select all blocks within 1 km of an interstate highway, we first filter the sfRoads collection to select all segments with the rttyp property value of I.\nvar interstateRoads = sfRoads.filter(ee.Filter.eq(‘rttyp’, ‘I’));\nWe use the draw function to visualize the sfBlocks and interstateRoads layers (Fig. F5.3.5).\nvar sfBlocksDrawn = sfBlocks.draw({\n       color: ‘gray’,\n       strokeWidth: 1   })\n   .clip(geometry);\nMap.addLayer(sfBlocksDrawn, {}, ‘All Blocks’);\nvar interstateRoadsDrawn = interstateRoads.draw({\n       color: ‘blue’,\n       strokeWidth: 3   })\n   .clip(geometry);\nMap.addLayer(interstateRoadsDrawn, {}, ‘Interstate Roads’);\n\nFig. F5.3.5 San Francisco blocks and interstate highways\nLet’s define a join that will select all the features from the sfBlocks layer that are within 1 km of any feature from the interstateRoads layer. We start by defining a filter using the ee.Filter.withinDistance filter. We want to compare the geometries of features in both layers, so we use a special property called ‘.geo’ to compare the collections. By default, the filter will work with exact distances between the geometries. If your analysis does not require a very precise tolerance of spatial uncertainty, specifying a small non-zero maxError distance value will help speed up the spatial operations. A larger tolerance also helps when testing or debugging code so you can get the result quickly instead of waiting longer for a more precise output.\nvar joinFilter = ee.Filter.withinDistance({\n   distance: 1000,\n   leftField: ‘.geo’,\n   rightField: ‘.geo’,\n   maxError: 10\n});\nWe will use a simple join as we just want features from the first (primary) collection that match the features from the other (secondary) collection.\nvar closeBlocks = ee.Join.simple().apply({\n   primary: sfBlocks,\n   secondary: interstateRoads,\n   condition: joinFilter\n});\nWe can visualize the results in a different color and verify that the join worked as expected (Fig. F5.3.6).\nvar closeBlocksDrawn = closeBlocks.draw({\n       color: ‘orange’,\n       strokeWidth: 1   })\n   .clip(geometry);\nMap.addLayer(closeBlocksDrawn, {}, ‘Blocks within 1km’);\n\nFig. F5.3.6 Selected blocks within 1 km of an interstate highway\n\n\n10.2.2 Spatial Joins\nA spatial join allows you to query two collections based on the spatial relationship. We will now implement a spatial join to count points in polygons. We will work with a dataset of tree locations in San Francisco and polygons of neighborhoods to produce a CSV file with the total number of trees in each neighborhood.\nThe San Francisco Open Data Portal maintains a street tree map dataset that has a list of street trees with their latitude and longitude. We will also use the San Francisco neighborhood dataset from the same portal. We downloaded, processed, and uploaded these layers as Earth Engine assets for use in this exercise. We start by loading both layers and using the paint and style functions, covered in Sect. 1, to visualize them (Fig. F5.3.7).\nvar sfNeighborhoods = ee.FeatureCollection(   ‘projects/gee-book/assets/F5-0/SFneighborhoods’);\nvar sfTrees = ee.FeatureCollection(   ‘projects/gee-book/assets/F5-3/SFTrees’);\n// Use paint() to visualize the polygons with only outline\nvar sfNeighborhoodsOutline = ee.Image().byte().paint({\n   featureCollection: sfNeighborhoods,\n   color: 1,\n   width: 3\n});\nMap.addLayer(sfNeighborhoodsOutline, {\n       palette: [‘blue’]\n   },   ‘SF Neighborhoods’);\n// Use style() to visualize the points\nvar sfTreesStyled = sfTrees.style({\n   color: ‘green’,\n   pointSize: 2,\n   pointShape: ‘triangle’,\n   width: 2\n});\nMap.addLayer(sfTreesStyled, {}, ‘SF Trees’);\n\nFig. F5.3.7 San Francisco neighborhoods and trees\nTo find the tree points in each neighborhood polygon, we will use an ee.Filter.intersects filter.\nvar intersectFilter = ee.Filter.intersects({\n   leftField: ‘.geo’,\n   rightField: ‘.geo’,\n   maxError: 10\n});\nWe need a join that can give us a list of all tree features that intersect each neighborhood polygon, so we need to use a saving join. A saving join will find all the features from the secondary collection that match the filter and store them in a property in the primary collection. Once you apply this join, you will get a version of the primary collection with an additional property that has the matching features from the secondary collection. Here we use the ee.Join.saveAll join, since we want to store all matching features. We specify the matchesKey property that will be added to each feature with the results.\nvar saveAllJoin = ee.Join.saveAll({\n   matchesKey: ‘trees’,\n});\nLet’s apply the join and print the first feature of the resulting collection to verify (Fig. F5.3.8).\nvar joined = saveAllJoin\n   .apply(sfNeighborhoods, sfTrees, intersectFilter);\nprint(joined.first());\n\nFig. F5.3.8 Result of the save-all join\nYou will see that each feature of the sfNeighborhoods collection now has an additional property called trees. This contains all the features from the sfTrees collection that were matched using the intersectFilter. We can now map a function over the results and post-process the collection. As our analysis requires the computation of the total number of trees in each neighborhood, we extract the matching features and use the size function to get the count (Fig. F5.3.9).\n// Calculate total number of trees within each feature.\nvar sfNeighborhoods = joined.map(function(f) {   var treesWithin = ee.List(f.get(‘trees’));   var totalTrees = ee.FeatureCollection(treesWithin).size();   return f.set(‘total_trees’, totalTrees);\n});\nprint(sfNeighborhoods.first());\n\nFig. F5.3.9 Final FeatureCollection with the new property\nThe results now have a property called total_trees containing the count of intersecting trees in each neighborhood polygon.\nThe final step in the analysis is to export the results as a CSV file using the Export.table.toDrive function. Note that as described in detail in F6.2, you should output only the columns you need to the CSV file. Suppose we do not need all the properties to appear in the output; imagine that wedo not need the trees property, for example, in the output. In that case, we can create only those columns we want in the manner below, by specifying the other selectors parameters with the list of properties to export.\n// Export the results as a CSV.\nExport.table.toDrive({\n   collection: sfNeighborhoods,\n   description: ‘SF_Neighborhood_Tree_Count’,\n   folder: ‘earthengine’,\n   fileNamePrefix: ‘tree_count’,\n   fileFormat: ‘CSV’,\n   selectors: [‘nhood’, ‘total_trees’]\n});\nThe final result is a CSV file with the neighborhood names and total numbers of trees counted using the join (Fig. F5.3.10).\n\nFig. F5.3.10 Exported CSV file with tree counts for San Francisco neighborhoods\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F53b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F5.html#synthesis-3",
    "href": "F5.html#synthesis-3",
    "title": "6  Vectors and Tables",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. What join would you use if you wanted to know which neighborhood each tree belongs to? Modify the code above to do a join and post-process the result to add a neighborhood property to each tree point. Export the results as a shapefile."
  },
  {
    "objectID": "F5.html#conclusion-3",
    "href": "F5.html#conclusion-3",
    "title": "6  Vectors and Tables",
    "section": "Conclusion",
    "text": "Conclusion\nThis chapter covered visualization and analysis using vector data in Earth Engine. You should now understand different functions for FeatureCollection visualization and be able to create thematic maps with vector layers. You also learned techniques for doing spatial queries and spatial joins within Earth Engine. Earth Engine is capable of handling large feature collections and can be effectively used for many spatial analysis tasks."
  },
  {
    "objectID": "F2.html",
    "href": "F2.html",
    "title": "4  Interpreting Images",
    "section": "",
    "text": "5 Image Manipulation: Bands, Arithmetic, Thresholds, and Masks"
  },
  {
    "objectID": "F2.html#author",
    "href": "F2.html#author",
    "title": "4  Interpreting Images",
    "section": "Author",
    "text": "Author\nKaren Dyson, Andréa Puzzi Nicolau, David Saah, and Nicholas Clinton"
  },
  {
    "objectID": "F2.html#overview",
    "href": "F2.html#overview",
    "title": "4  Interpreting Images",
    "section": "Overview",
    "text": "Overview\nOnce images have been identified in Earth Engine, they can be viewed in a wide array of band combinations for targeted purposes. For users who are already versed in remote sensing concepts, this chapter shows how to do familiar tasks on this platform; for those who are entirely new to such concepts, it introduces the idea of band combinations."
  },
  {
    "objectID": "F2.html#learning-outcomes",
    "href": "F2.html#learning-outcomes",
    "title": "4  Interpreting Images",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUnderstanding what spectral indices are and why they are useful.\nBeing introduced to a range of example spectral indices used for a variety of purposes."
  },
  {
    "objectID": "F2.html#assumes-you-know-how-to",
    "href": "F2.html#assumes-you-know-how-to",
    "title": "4  Interpreting Images",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1)."
  },
  {
    "objectID": "F2.html#introduction-to-theory",
    "href": "F2.html#introduction-to-theory",
    "title": "4  Interpreting Images",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nSpectral indices are based on the fact that different objects and land covers on the Earth’s surface reflect different amounts of light from the Sun at different wavelengths. In the visible part of the spectrum, for example, a healthy green plant reflects a large amount of green light while absorbing blue and red light—which is why it appears green to our eyes. Light also arrives from the Sun at wavelengths outside what the human eye can see, and there are large differences in reflectances between living and nonliving land covers, and between different types of vegetation, both in the visible and outside the visible wavelengths. We visualized this earlier, in Chaps. F1.1 and F1.3 when we mapped color-infrared images (Fig. F2.0.1).\n\nFig. F2.0.1 Mapped color-IR images from multiple satellite sensors that we mapped in Chap. F1.3. The near infrared spectrum is mapped as red, showing where there are high amounts of healthy vegetation.\nIf we graph the amount of light (reflectance) at different wavelengths that an object or land cover reflects, we can visualize this more easily (Fig. F2.0.2). For example, look at the reflectance curves for soil and water in the graph below. Soil and water both have relatively low reflectance at wavelengths around 300 nm (ultraviolet and violet light). Conversely, at wavelengths above 700 nm (red and infrared light) soil has relatively high reflectance, while water has very low reflectance. Vegetation, meanwhile, generally reflects large amounts of near infrared light, relative to other land covers.\n\nFig. F2.0.2 A graph of the amount of reflectance for different objects on the Earth’s surface at different wavelengths in the visible and infrared portions of the electromagnetic spectrum. 1 micrometer (µm) = 1,000 nanometers (nm).\nSpectral indices use math to express how objects reflect light across multiple portions of the spectrum as a single number. Indices combine multiple bands, often with simple operations of subtraction and division, to create a single value across an image that is intended to help to distinguish particular land uses or land covers of interest. Using Fig. F2.0.2, you can imagine which wavelengths might be the most informative for distinguishing among a variety of land covers. We will explore a variety of calculations made from combinations of bands in the following sections.\nIndices derived from satellite imagery are used as the basis of many remote-sensing analyses. Indices have been used in thousands of applications, from detecting anthropogenic deforestation to examining crop health. For example, the growth of economically important crops such as wheat and cotton can be monitored throughout the growing season: Bare soil reflects more red wavelengths, whereas growing crops reflect more of the near-infrared (NIR) wavelengths. Thus, calculating a ratio of these two bands can help monitor how well crops are growing (Jackson and Huete 1991)."
  },
  {
    "objectID": "F2.html#band-arithmetic-in-earth-engine",
    "href": "F2.html#band-arithmetic-in-earth-engine",
    "title": "4  Interpreting Images",
    "section": "5.1 Band Arithmetic in Earth Engine",
    "text": "5.1 Band Arithmetic in Earth Engine\nIf you have not already done so, be sure to add the book’s code repository to the Code Editor by entering https://code.earthengine.google.com/?accept_repo=projects/gee-edu/book into your browser. The book’s scripts will then be available in the script manager panel. If you have trouble finding the repo, you can visit this link for help.\nMany indices can be calculated using band arithmetic in Earth Engine. Band arithmetic is the process of adding, subtracting, multiplying, or dividing two or more bands from an image. Here we’ll first do this manually, and then show you some more efficient ways to perform band arithmetic in Earth Engine.\n\n5.1.1 Arithmetic Calculation of NDVI\nThe red and near-infrared bands provide a lot of information about vegetation due to vegetation’s high reflectance in these wavelengths. Take a look at Fig. F2.0.2 and note, in particular, that vegetation curves (graphed in green) have relatively high reflectance in the NIR range (approximately 750–900 nm). Also note that vegetation has low reflectance in the red range (approximately 630–690 nm), where sunlight is absorbed by chlorophyll. This suggests that if the red and near-infrared bands could be combined, they would provide substantial information about vegetation.\nSoon after the launch of Landsat 1 in 1972, analysts worked to devise a robust single value that would convey the health of vegetation along a scale of −1 to 1. This yielded the NDVI, using the formula:\n           (F2.0.1)\nwhere NIR and red refer to the brightness of each of those two bands. As seen in Chaps. F1.1 and F1.2, this brightness might be conveyed in units of reflectance, radiance, or digital number (DN); the NDVI is intended to give nearly equivalent values across platforms that use these wavelengths. The general form of this equation is called a “normalized difference”—the numerator is the “difference” and the denominator “normalizes” the value. Outputs for NDVI vary between −1 and 1. High amounts of green vegetation have values around 0.8–0.9. Absence of green leaves gives values near 0, and water gives values near −1.\nTo compute the NDVI, we will introduce Earth Engine’s implementation of band arithmetic. Cloud-based band arithmetic is one of the most powerful aspects of Earth Engine, because the platform’s computers are optimized for this type of heavy processing. Arithmetic on bands can be done even at planetary scale very quickly—an idea that was out of reach before the advent of cloud-based remote sensing. Earth Engine automatically partitions calculations across a large number of computers as needed, and assembles the answer for display.\nAs an example, let’s examine an image of San Francisco (​​Fig. F2.0.3).\n/////\n// Band Arithmetic\n/////\n// Calculate NDVI using Sentinel 2\n// Import and filter imagery by location and date.\nvar sfoPoint = ee.Geometry.Point(-122.3774, 37.6194);\nvar sfoImage = ee.ImageCollection(‘COPERNICUS/S2’)\n   .filterBounds(sfoPoint)\n   .filterDate(‘2020-02-01’, ‘2020-04-01’)\n   .first();\n// Display the image as a false color composite.\nMap.centerObject(sfoImage, 11);\nMap.addLayer(sfoImage, {\n   bands: [‘B8’, ‘B4’, ‘B3’],\n   min: 0,\n   max: 2000}, ‘False color’);\n\nFig. F2.0.3 False color Sentinel-2 imagery of San Francisco and surroundings\nThe simplest mathematical operations in Earth Engine are the add, subtract, multiply, and divide methods. Let’s select the near-infrared and red bands and use these operations to calculate NDVI for our image.\n// Extract the near infrared and red bands.\nvar nir = sfoImage.select(‘B8’);\nvar red = sfoImage.select(‘B4’);\n// Calculate the numerator and the denominator using subtraction and addition respectively.\nvar numerator = nir.subtract(red);\nvar denominator = nir.add(red);\n// Now calculate NDVI.\nvar ndvi = numerator.divide(denominator);\n// Add the layer to our map with a palette.\nvar vegPalette = [‘red’, ‘white’, ‘green’];\nMap.addLayer(ndvi, {\n   min: -1,\n   max: 1,\n   palette: vegPalette\n}, ‘NDVI Manual’);\nExamine the resulting index, using the Inspector to pick out pixel values in areas of vegetation and non-vegetation if desired.\n\nFig. F2.0.4 NDVI calculated using Sentinel-2. Remember that outputs for NDVI vary between −1 and 1. High amounts of green vegetation have values around 0.8–0.9. Absence of green leaves gives values near 0, and water gives values near −1.\nUsing these simple arithmetic tools, you can build almost any index, or develop and visualize your own. Earth Engine allows you to quickly and easily calculate and display the index across a large area.\n\n\n5.1.2 Single-Operation Computation of Normalized Difference for NDVI\nNormalized differences like NDVI are so common in remote sensing that Earth Engine provides the ability to do that particular sequence of subtraction, addition, and division in a single step, using the normalizedDifference method. This method takes an input image, along with bands you specify, and creates a normalized difference of those two bands. The NDVI computation previously created with band arithmetic can be replaced with one line of code:\n// Now use the built-in normalizedDifference function to achieve the same outcome.\nvar ndviND = sfoImage.normalizedDifference([‘B8’, ‘B4’]);\nMap.addLayer(ndviND, {\n   min: -1,\n   max: 1,\n   palette: vegPalette\n}, ‘NDVI normalizedDiff’);\nNote that the order in which you provide the two bands to normalizedDifference is important. We use B8, the near-infrared band, as the first parameter, and the red band B4 as the second. If your two computations of NDVI do not look identical when drawn to the screen, check to make sure that the order you have for the NIR and red bands is correct.\n\n\n5.1.3 Using Normalized Difference for NDWI\nAs mentioned, the normalized difference approach is used for many different indices. Let’s apply the same normalizedDifference method to another index.\nThe Normalized Difference Water Index (NDWI) was developed by Gao (1996) as an index of vegetation water content. The index is sensitive to changes in the liquid content of vegetation canopies. This means that the index can be used, for example, to detect vegetation experiencing drought conditions or differentiate crop irrigation levels. In dry areas, crops that are irrigated can be differentiated from natural vegetation. It is also sometimes called the Normalized Difference Moisture Index (NDMI). NDWI is formulated as follows:\n                                (F2.0.2)\nwhere NIR is near-infrared, centered near 860 nm (0.86 μm), and SWIR is short-wave infrared, centered near 1,240 nm (1.24 μm).\nCompute and display NDWI in Earth Engine using the normalizedDifference method. Remember that for Sentinel-2, B8 is the NIR band and B11 is the SWIR band (refer to Chaps. F1.1 and F1.3 to find information about imagery bands).\n// Use normalizedDifference to calculate NDWI\nvar ndwi = sfoImage.normalizedDifference([‘B8’, ‘B11’]);\nvar waterPalette = [‘white’, ‘blue’];\nMap.addLayer(ndwi, {\n   min: -0.5,\n   max: 1,\n   palette: waterPalette\n}, ‘NDWI’);\nExamine the areas of the map that NDVI identified as having a lot of vegetation. Notice which are more blue. This is vegetation that has higher water content.\n\nFig. F2.0.5 NDWI displayed for Sentinel-2 over San Francisco\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F20a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F2.html#thresholding-masking-and-remapping-images",
    "href": "F2.html#thresholding-masking-and-remapping-images",
    "title": "4  Interpreting Images",
    "section": "5.2 Thresholding, Masking, and Remapping Images",
    "text": "5.2 Thresholding, Masking, and Remapping Images\nThe previous section in this chapter discussed how to use band arithmetic to manipulate images. Those methods created new continuous values by combining bands within an image. This section uses logical operators to categorize band or index values to create a categorized image.\n\n5.2.1 Implementing a Threshold\nImplementing a threshold uses a number (the threshold value) and logical operators to help us partition the variability of images into categories. For example, recall our map of NDVI. High amounts of vegetation have NDVI values near 1 and non-vegetated areas are near 0. If we want to see what areas of the map have vegetation, we can use a threshold to generalize the NDVI value in each pixel as being either “no vegetation” or “vegetation”. That is a substantial simplification, to be sure, but can help us to better comprehend the rich variation on the Earth’s surface. This type of categorization may be useful if, for example, we want to look at the proportion of a city that is vegetated. Let’s create a Sentinel-2 map of NDVI near Seattle, Washington, USA. Enter the code below in a new script.\n// Create an NDVI image using Sentinel 2.\nvar seaPoint = ee.Geometry.Point(-122.2040, 47.6221);\nvar seaImage = ee.ImageCollection(‘COPERNICUS/S2’)\n   .filterBounds(seaPoint)\n   .filterDate(‘2020-08-15’, ‘2020-10-01’)\n   .first();\nvar seaNDVI = seaImage.normalizedDifference([‘B8’, ‘B4’]);\n// And map it.\nMap.centerObject(seaPoint, 10);\nvar vegPalette = [‘red’, ‘white’, ‘green’];\nMap.addLayer(seaNDVI,\n   {\n       min: -1,\n       max: 1,\n       palette: vegPalette\n   },   ‘NDVI Seattle’);\n\nFig. F2.0.6 NDVI image of Sentinel-2 imagery over Seattle, Washington, USA\nInspect the image. We can see that vegetated areas are darker green while non-vegetated locations are white and water is pink. If we use the Inspector to query our image, we can see that parks and other forested areas have an NDVI over about 0.5. Thus, it would make sense to define areas with NDVI values greater than 0.5 as forested, and those below that threshold as not forested.\nNow let’s define that value as a threshold and use it to threshold our vegetated areas.\n// Implement a threshold.\nvar seaVeg = seaNDVI.gt(0.5);\n// Map the threshold.\nMap.addLayer(seaVeg,\n   {\n       min: 0,\n       max: 1,\n       palette: [‘white’, ‘green’]\n   },   ‘Non-forest vs. Forest’);\nThe gt method is from the family of Boolean operators—that is, gt is a function that performs a test in each pixel and returns the value 1 if the test evaluates to true, and 0 otherwise. Here, for every pixel in the image, it tests whether the NDVI value is greater than 0.5. When this condition is met, the layer seaVeg gets the value 1. When the condition is false, it receives the value 0.\n\nFig. F2.0.7 Thresholded forest and non-forest image based on NDVI for Seattle, Washington, USA\nUse the Inspector tool to explore this new layer. If you click on a green location, that NDVI should be greater than 0.5. If you click on a white pixel, the NDVI value should be equal to or less than 0.5.\nOther operators in this Boolean family include less than (lt), less than or equal to (lte), equal to (eq), not equal to (neq), and greater than or equal to (gte) and more.\n\n\n5.2.2 Building Complex Categorizations with .where\nA binary map classifying NDVI is very useful. However, there are situations where you may want to split your image into more than two bins. Earth Engine provides a tool, the where method, that conditionally evaluates to true or false within each pixel depending on the outcome of a test. This is analogous to an if statement seen commonly in other languages. However, to perform this logic when programming for Earth Engine, we avoid using the JavaScript if statement. Importantly, JavaScript if commands are not calculated on Google’s servers, and can create serious problems when running your code—in effect, the servers try to ship all of the information to be executed to your own computer’s browser, which is very underequipped for such enormous tasks. Instead, we use the where clause for conditional logic.\nSuppose instead of just splitting the forested areas from the non-forested areas in our NDVI, we want to split the image into likely water, non-forested, and forested areas. We can use where and thresholds of -0.1 and 0.5. We will start by creating an image using ee.Image. We then clip the new image so that it covers the same area as our seaNDVI layer.\n// Implement .where.\n// Create a starting image with all values = 1.\nvar seaWhere = ee.Image(1)   // Use clip to constrain the size of the new image.   .clip(seaNDVI.geometry());\n// Make all NDVI values less than -0.1 equal 0.\nseaWhere = seaWhere.where(seaNDVI.lte(-0.1), 0);\n// Make all NDVI values greater than 0.5 equal 2.\nseaWhere = seaWhere.where(seaNDVI.gte(0.5), 2);\n// Map our layer that has been divided into three classes.\nMap.addLayer(seaWhere,\n   {\n       min: 0,\n       max: 2,\n       palette: [‘blue’, ‘white’, ‘green’]\n   },   ‘Water, Non-forest, Forest’);\nThere are a few interesting things to note about this code that you may not have seen before. First, we’re not defining a new variable for each where call. As a result, we can perform many where calls without creating a new variable each time and needing to keep track of them. Second, when we created the starting image, we set the value to 1. This means that we could easily set the bottom and top values with one where clause each. Finally, while we did not do it here, we can combine multiple where clauses using and and or. For example, we could identify pixels with an intermediate level of NDVI using seaNDVI.gte(-0.1).and(seaNDVI.lt(0.5)).\n\nFig. F2.0.8 Thresholded water, forest, and non-forest image based on NDVI for Seattle, Washington, USA.\n\n\n5.2.3 Masking Specific Values in an Image\nMasking an image is a technique that removes specific areas of an image—those covered by the mask—from being displayed or analyzed. Earth Engine allows you to both view the current mask and update the mask.\n// Implement masking.\n// View the seaVeg layer’s current mask.\nMap.centerObject(seaPoint, 9);\nMap.addLayer(seaVeg.mask(), {}, ‘seaVeg Mask’);\n\nFig. F2.0.9 The existing mask for the seaVeg layer we created previously\nYou can use the Inspector to see that the black area is masked and the white area has a constant value of 1. This means that data values are mapped and available for analysis within the white area only.\nNow suppose we only want to display and conduct analyses in the forested areas. Let’s mask out the non-forested areas from our image. First, we create a binary mask using the equals (eq) method.\n// Create a binary mask of non-forest.\nvar vegMask = seaVeg.eq(1);\nIn making a mask, you set the values you want to see and analyze to be a number greater than 0. The idea is to set unwanted values to get the value of 0. Pixels that had 0 values become masked out (in practice, they do not appear on the screen at all) once we use the updateMask method to add these values to the existing mask.\n// Update the seaVeg mask with the non-forest mask.\nvar maskedVeg = seaVeg.updateMask(vegMask);\n// Map the updated Veg layer\nMap.addLayer(maskedVeg,\n   {\n       min: 0,\n       max: 1,\n       palette: [‘green’]\n   },   ‘Masked Forest Layer’);\nTurn off all of the other layers. You can see how the maskedVeg layer now has masked out all non-forested areas.\n\nFig. F2.0.10 An updated mask now displays only the forested areas. Non-forested areas are masked out and transparent.\nMap the updated mask for the layer and you can see why this is.\n// Map the updated mask\nMap.addLayer(maskedVeg.mask(), {}, ‘maskedVeg Mask’);\n\nFig. F2.0.11 The updated mask. Areas of non-forest are now masked out as well (black areas of the image).\n\n\n5.2.4 Remapping Values in an Image\nRemapping takes specific values in an image and assigns them a different value. This is particularly useful for categorical datasets, including those you read about in Chap. F1.2 and those we have created earlier in this chapter.\nLet’s use the remap method to change the values for our seaWhere layer. Note that since we’re changing the middle value to be the largest, we’ll need to adjust our palette as well.\n// Implement remapping.\n// Remap the values from the seaWhere layer.\nvar seaRemap = seaWhere.remap([0, 1, 2], // Existing values.   [9, 11, 10]); // Remapped values.\nMap.addLayer(seaRemap,\n   {\n       min: 9,\n       max: 11,\n       palette: [‘blue’, ‘green’, ‘white’]\n   },   ‘Remapped Values’);\nUse the inspector to compare values between our original seaWhere (displayed as Water, Non-Forest, Forest) and the seaRemap, marked as “Remapped Values.” Click on a forested area and you should see that the Remapped Values should be 10, instead of 2 (Fig. F2.0.12).\n\nFig. F2.0.12 For forested areas, the remapped layer has a value of 10, compared with the original layer, which has a value of 2. You may have more layers in your Inspector.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F20b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F2.html#synthesis",
    "href": "F2.html#synthesis",
    "title": "4  Interpreting Images",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. In addition to vegetation indices and other land cover indices, you can use properties of different soil types to create geological indices. The Clay Minerals Ratio (CMR) is one of these. This index highlights soils containing clay and alunite, which absorb radiation in the SWIR portion (2.0–2.3 μm) of the spectrum.\n\nSWIR 1 should be in the 1.55–1.75 µm range, and SWIR 2 should be in the 2.08–2.35 µm range. Calculate and display CMR at the following point: ee.Geometry.Point(-100.543, 33.456). Don’t forget to use Map.centerObject.\nWe’ve selected an area of Texas known for its clay soils. Compare this with an area without clay soils (for example, try an area around Seattle or Tacoma, Washington, USA). Note that this index will also pick up roads and other paved areas.\nAssignment 2. Calculate the Iron Oxide Ratio, which can be used to detect hydrothermally altered rocks (e.g., from volcanoes) that contain iron-bearing sulfides which have been oxidized (Segal, 1982).\nHere’s the formula:\n\nRed should be the 0.63–0.69 µm spectral range and Blue the 0.45–0.52 µm. Using Landsat 8, you can also find an interesting area to map by considering where these types of rocks might occur.\nAssignment 3. Calculate the Normalized Difference Built-Up Index (NDBI) for the sfoImage used in this chapter.\nThe NDBI was developed by Zha et al. (2003) to aid in differentiating urban areas (e.g., densely clustered buildings and roads) from other land cover types. The index exploits the fact that urban areas, which generally have a great deal of impervious surface cover, reflect SWIR very strongly. If you like, refer back to Fig. F2.0.2.\nThe formula is:\n\nUsing what we know about Sentinel-2 bands, compute NDBI and display it.\nBonus: Note that NDBI is the negative of NDWI computed earlier. We can prove this by using the JavaScript reverse method to reverse the palette used for NDWI in Earth Engine. This method reverses the order of items in the JavaScript list. Create a new palette for NDBI using the reverse method and display the map. As a hint, here is code to use the reverse method.\nvar barePalette = waterPalette.reverse();"
  },
  {
    "objectID": "F2.html#conclusion",
    "href": "F2.html#conclusion",
    "title": "4  Interpreting Images",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned how to select multiple bands from an image and calculate indices. You also learned about thresholding values in an image, slicing them into multiple categories using thresholds. It is also possible to work with one set of class numbers and remap them quickly to another set. Using these techniques, you have some of the basic tools of image manipulation. In subsequent chapters you will encounter more complex and specialized image manipulation techniques, including pixel-based image transformations (Chap. F3.1), neighborhood-based image transformations (Chap. F3.2), and object-based image analysis (Chap. F3.3)."
  },
  {
    "objectID": "F2.html#references",
    "href": "F2.html#references",
    "title": "4  Interpreting Images",
    "section": "References",
    "text": "References\nBaig MHA, Zhang L, Shuai T, Tong Q (2014) Derivation of a tasselled cap transformation based on Landsat 8 at-satellite reflectance. Remote Sens Lett 5:423–431. https://doi.org/10.1080/2150704X.2014.915434\nCrist EP (1985) A TM tasseled cap equivalent transformation for reflectance factor data. Remote Sens Environ 17:301–306. https://doi.org/10.1016/0034-4257(85)90102-6\nDrury SA (1987) Image interpretation in geology. Geocarto Int 2:48. https://doi.org/10.1080/10106048709354098\nGao BC (1996) NDWI - A normalized difference water index for remote sensing of vegetation liquid water from space. Remote Sens Environ 58:257–266. https://doi.org/10.1016/S0034-4257(96)00067-3\nHuang C, Wylie B, Yang L, et al (2002) Derivation of a tasselled cap transformation based on Landsat 7 at-satellite reflectance. Int J Remote Sens 23:1741–1748. https://doi.org/10.1080/01431160110106113\nJackson RD, Huete AR (1991) Interpreting vegetation indices. Prev Vet Med 11:185–200. https://doi.org/10.1016/S0167-5877(05)80004-2\nMartín MP (1998) Cartografía e inventario de incendios forestales en la Península Ibérica a partir de imágenes NOAA-AVHRR. Universidad de Alcalá\nMcFeeters SK (1996) The use of the Normalized Difference Water Index (NDWI) in the delineation of open water features. Int J Remote Sens 17:1425–1432. https://doi.org/10.1080/01431169608948714\nNath B, Niu Z, Mitra AK (2019) Observation of short-term variations in the clay minerals ratio after the 2015 Chile great earthquake (8.3 Mw) using Landsat 8 OLI data. J Earth Syst Sci 128:1–21. https://doi.org/10.1007/s12040-019-1129-2\nSchultz M, Clevers JGPW, Carter S, et al (2016) Performance of vegetation indices from Landsat time series in deforestation monitoring. Int J Appl Earth Obs Geoinf 52:318–327. https://doi.org/10.1016/j.jag.2016.06.020\nSegal D (1982) Theoretical basis for differentiation of ferric-iron bearing minerals, using Landsat MSS data. In: Proceedings of Symposium for Remote Sensing of Environment, 2nd Thematic Conference on Remote Sensing for Exploratory Geology, Fort Worth, TX. pp 949–951\nSouza Jr CM, Roberts DA, Cochrane MA (2005) Combining spectral and spatial information to map canopy damage from selective logging and forest fires. Remote Sens Environ 98:329–343. https://doi.org/10.1016/j.rse.2005.07.013\nSouza Jr CM, Siqueira JV, Sales MH, et al (2013) Ten-year Landsat classification of deforestation and forest degradation in the Brazilian Amazon. Remote Sens 5:5493–5513. https://doi.org/10.3390/rs5115493"
  },
  {
    "objectID": "F2.html#author-1",
    "href": "F2.html#author-1",
    "title": "4  Interpreting Images",
    "section": "Author",
    "text": "Author\nAndréa Puzzi Nicolau, Karen Dyson, David Saah, Nicholas Clinton"
  },
  {
    "objectID": "F2.html#overview-1",
    "href": "F2.html#overview-1",
    "title": "4  Interpreting Images",
    "section": "Overview",
    "text": "Overview\nImage classification is a fundamental goal of remote sensing. It takes the user from viewing an image to labeling its contents. This chapter introduces readers to the concept of classification and walks users through the many options for image classification in Earth Engine. You will explore the processes of training data collection, classifier selection, classifier training, and image classification."
  },
  {
    "objectID": "F2.html#learning-outcomes-1",
    "href": "F2.html#learning-outcomes-1",
    "title": "4  Interpreting Images",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nRunning a classification in Earth Engine.\nUnderstanding the difference between supervised and unsupervised classification.\nLearning how to use Earth Engine geometry drawing tools.\nLearning how to collect sample data in Earth Engine.\nLearning the basics of the hexadecimal numbering system."
  },
  {
    "objectID": "F2.html#assumes-you-know-how-to-1",
    "href": "F2.html#assumes-you-know-how-to-1",
    "title": "4  Interpreting Images",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nUnderstand bands and how to select them (Chap. F1.2, Chap. F2.0)."
  },
  {
    "objectID": "F2.html#introduction-to-theory-1",
    "href": "F2.html#introduction-to-theory-1",
    "title": "4  Interpreting Images",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nClassification is addressed in a broad range of fields, including mathematics, statistics, data mining, machine learning, and more. For a deeper treatment of classification, interested readers may see some of the following suggestions: Witten et al. (2011), Hastie et al. (2009), Goodfellow et al. (2016), Gareth et al. (2013), Géron (2019), Müller et al. (2016), or Witten et al. (2005). Unlike regression, which predicts continuous variables, classification predicts categorical, or discrete, variables—variables with a finite number of categories (e.g., age range).\nIn remote sensing, image classification is an attempt to categorize all pixels in an image into a finite number of labeled land cover and/or land use classes. The resulting classified image is a simplified thematic map derived from the original image (Fig. F2.1.1). Land cover and land use information is essential for many environmental and socioeconomic applications, including natural resource management, urban planning, biodiversity conservation, agricultural monitoring, and carbon accounting.\n\nFig. F2.1.1 Image classification concept\nImage classification techniques for generating land cover and land use information have been in use since the 1980s (Li et al. 2014). Here, we will cover the concepts of pixel-based supervised and unsupervised classifications, testing out different classifiers. Chapter F3.3 covers the concept and application of object-based classification.\nIt is important to define land use and land cover. Land cover relates to the physical characteristics of the surface: simply put, it documents whether an area of the Earth’s surface is covered by forests, water, impervious surfaces, etc. Land use refers to how this land is being used by people. For example, herbaceous vegetation is considered a land cover but can indicate different land uses: the grass in a pasture is an agricultural land use, whereas the grass in an urban area can be classified as a park."
  },
  {
    "objectID": "F2.html#supervised-classification",
    "href": "F2.html#supervised-classification",
    "title": "4  Interpreting Images",
    "section": "6.1 Supervised Classification",
    "text": "6.1 Supervised Classification\nIf you have not already done so, be sure to add the book’s code repository to the Code Editor by entering https://code.earthengine.google.com/?accept_repo=projects/gee-edu/book into your browser. The book’s scripts will then be available in the script manager panel. If you have trouble finding the repo, you can visit this link for help.\nSupervised classification uses a training dataset with known labels and representing the spectral characteristics of each land cover class of interest to “supervise” the classification. The overall approach of a supervised classification in Earth Engine is summarized as follows:\n\nGet a scene.\nCollect training data.\nSelect and train a classifier using the training data.\nClassify the image using the selected classifier.\n\nWe will begin by creating training data manually, based on a clear Landsat image (Fig. F2.1.2). Copy the code block below to define your Landsat 8 scene variable and add it to the map. We will use a point in Milan, Italy, as the center of the area for our image classification.\n// Create an Earth Engine Point object over Milan.\nvar pt = ee.Geometry.Point([9.453, 45.424]);\n// Filter the Landsat 8 collection and select the least cloudy image.\nvar landsat = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterBounds(pt)\n   .filterDate(‘2019-01-01’, ‘2020-01-01’)\n   .sort(‘CLOUD_COVER’)\n   .first();\n// Center the map on that image.\nMap.centerObject(landsat, 8);\n// Add Landsat image to the map.\nvar visParams = {\n   bands: [‘SR_B4’, ‘SR_B3’, ‘SR_B2’],\n   min: 7000,\n   max: 12000\n};\nMap.addLayer(landsat, visParams, ‘Landsat 8 image’);\n\nFig. F2.1.2 Landsat image\nUsing the Geometry Tools, we will create points on the Landsat image that represent land cover classes of interest to use as our training data. We’ll need to do two things: (1) identify where each land cover occurs on the ground, and (2) label the points with the proper class number. For this exercise, we will use the classes and codes shown in Table 2.1.1.\nTable 2.1.1 Land cover classes\nClass\nClass code\nForest\n0\nDeveloped\n1\nWater\n2\nHerbaceous\n3\nIn the Geometry Tools, click on the marker option (Fig. F2.1.3). This will create a point geometry which will show up as an import named “geometry”. Click on the gear icon to configure this import.\n\nFig. F2.1.3 Creating a new layer in the Geometry Imports\nWe will start by collecting forest points, so name the import forest. Import it as a FeatureCollection, and then click + Property. Name the new property “class” and give it a value of 0 (Fig. F2.1.4). We can also choose a color to represent this class. For a forest class, it is natural to choose a green color. You can choose the color you prefer by clicking on it, or, for more control, you can use a hexadecimal value.\nHexadecimal values are used throughout the digital world to represent specific colors across computers and operating systems. They are specified by six values arranged in three pairs, with one pair each for the red, green, and blue brightness values. If you’re unfamiliar with hexadecimal values, imagine for a moment that colors were specified in pairs of base 10 numbers instead of pairs of base 16. In that case, a bright pure red value would be “990000”; a bright pure green value would be “009900”; and a bright pure blue value would be “000099”. A value like “501263” would be a mixture of the three colors, not especially bright, having roughly equal amounts of blue and red, and much less green: a color that would be a shade of purple. To create numbers in the hexadecimal system, which might feel entirely natural if humans had evolved to have 16 fingers, sixteen “digits” are needed: a base 16 counter goes 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, then 10, 11, and so on. Given that counting framework, the number “FF” is like “99” in base 10: the largest two-digit number. The hexadecimal color used for coloring the letters of the word FeatureCollection in this book, a color with roughly equal amounts of blue and red, and much less green, is “7F1FA2”  \nReturning to the coloring of the forest points, the hexadecimal value “589400” is a little bit of red, about twice as much green, and no blue: the deep green seen in Figure F2.1.4. Enter that value, with or without the “#” in front, and click OK after finishing the configuration.\n\nFig. F2.1.4 Edit geometry layer properties\nNow, in the Geometry Imports, we will see that the import has been renamed forest. Click on it to activate the drawing mode (Fig. F2.1.5) in order to start collecting forest points.\n\nFig. F2.1.5 Activate forest layer to start collection\nNow, start collecting points over forested areas (Fig. F2.1.6). Zoom in and out as needed. You can use the satellite basemap to assist you, but the basis of your collection should be the Landsat image. Remember that the more points you collect, the more the classifier will learn from the information you provide. For now, let’s set a goal to collect 25 points per class. Click Exit next to Point drawing (Fig. F2.1.5) when finished.\n\nFig. F2.1.6 Forest points\nRepeat the same process for the other classes by creating new layers (Fig. F2.1.7). Don’t forget to import using the FeatureCollection option as mentioned above. For the developed class, collect points over urban areas. For the water class, collect points over the Ligurian Sea, and also look for other bodies of water, like rivers. For the herbaceous class, collect points over agricultural fields. Remember to set the “class” property for each class to its corresponding code (see Table 2.1.1) and click Exit once you finalize collecting points for each class as mentioned above. We will be using the following hexadecimal colors for the other classes: #FF0000 for developed, #1A11FF for water, and #D0741E for herbaceous. \n\nFig. F2.1.7 New layer option in Geometry Imports\nYou should now have four FeatureCollection imports named forest, developed, water, and herbaceous (Fig. F2.1.8).\n\nFig. F2.1.8 Example of training points\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F21a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nIf you wish to have the exact same results demonstrated in this chapter from now on, continue beginning with this Code Checkpoint. If you use the points collected yourself, the results may vary from this point forward.\nThe next step is to combine all the training feature collections into one. Copy and paste the code below to combine them into one FeatureCollection called trainingFeatures. Here, we use the flatten method to avoid having a collection of feature collections—we want individual features within our FeatureCollection.\n// Combine training feature collections.\nvar trainingFeatures = ee.FeatureCollection([\n   forest, developed, water, herbaceous\n]).flatten();\nNote: Alternatively, you could use an existing set of reference data. For example, the European Space Agency (ESA) WorldCover dataset is a global map of land use and land cover derived from ESA’s Sentinel-2 imagery at 10 m resolution. With existing datasets, we can randomly place points on pixels classified as the classes of interest (if you are curious, you can explore the Earth Engine documentation to learn about the ee.Image.stratifiedSample and the ee.FeatureCollection.randomPoints methods). The drawback is that these global datasets will not always contain the specific classes of interest for your region, or may not be entirely accurate at the local scale. Another option is to use samples that were collected in the field (e.g., GPS points). In Chap. F5.0, you will see how to upload your own data as Earth Engine assets.\nIn the combined FeatureCollection, each Feature point should have a property called “class”. The class values are consecutive integers from 0 to 3 (you could verify that this is true by printing trainingFeatures and checking the properties of the features).\nNow that we have our training points, copy and paste the code below to extract the band information for each class at each point location. First, we define the prediction bands to extract different spectral and thermal information from different bands for each class. Then, we use the sampleRegions method to sample the information from the Landsat image at each point location. This method requires information about the FeatureCollection (our reference points), the property to extract (“class”), and the pixel scale (in meters).\n// Define prediction bands.\nvar predictionBands = [   ‘SR_B1’, ‘SR_B2’, ‘SR_B3’, ‘SR_B4’, ‘SR_B5’, ‘SR_B6’, ‘SR_B7’,   ‘ST_B10’\n];\n// Sample training points.\nvar classifierTraining = landsat.select(predictionBands)\n   .sampleRegions({\n       collection: trainingFeatures,\n       properties: [‘class’],\n       scale: 30   });\nYou can check whether the classifierTraining object extracted the properties of interest by printing it and expanding the first feature. You should see the band and class information (Fig. F2.1.9).\n\nFig. F2.1.9 Example of extracted band information for one point of class 0 (forest)\nNow we can choose a classifier. The choice of classifier is not always obvious, and there are many options from which to pick—you can quickly expand the ee.Classifier object under Docs to get an idea of how many options we have for image classification. Therefore, we will be testing different classifiers and comparing their results. We will start with a Classification and Regression Tree (CART) classifier, a well-known classification algorithm (Fig. F2.1.10) that has been around for decades.\n\nFig. F2.1.10 Example of a decision tree for satellite image classification. Values and classes are hypothetical.\nCopy and paste the code below to instantiate a CART classifier (ee.Classifier.smileCart) and train it.\n//////////////// CART Classifier ///////////////////\n// Train a CART Classifier.\nvar classifier = ee.Classifier.smileCart().train({\n   features: classifierTraining,\n   classProperty: ‘class’,\n   inputProperties: predictionBands\n});\nEssentially, the classifier contains the mathematical rules that link labels to spectral information. If you print the variable classifier and expand its properties, you can confirm the basic characteristics of the object (bands, properties, and classifier being used). If you print classifier.explain, you can find a property called “tree” that contains the decision rules.\nAfter training the classifier, copy and paste the code below to classify the Landsat image and add it to the Map.\n// Classify the Landsat image.\nvar classified = landsat.select(predictionBands).classify(classifier);\n// Define classification image visualization parameters.\nvar classificationVis = {\n   min: 0,\n   max: 3,\n   palette: [‘589400’, ‘ff0000’, ‘1a11ff’, ‘d0741e’]\n};\n// Add the classified image to the map.\nMap.addLayer(classified, classificationVis, ‘CART classified’);\nNote that, in the visualization parameters, we define a palette parameter which in this case represents colors for each pixel value (0–3, our class codes). We use the same hexadecimal colors used when creating our training points for each class. This way, we can associate a color with a class when visualizing the classified image in the Map.\nInspect the result: Activate the Landsat composite layer and the satellite basemap to overlay with the classified images (Fig. F2.1.11). Change the layers’ transparency to inspect some areas. What do you notice? The result might not look very satisfactory in some areas (e.g., confusion between developed and herbaceous classes). Why do you think this is happening? There are a few options to handle misclassification errors:\n\nCollect more training data We can try incorporating more points to have a more representative sample of the classes.\nTune the model Classifiers typically have “hyperparameters,” which are set to default values. In the case of classification trees, there are ways to tune the number of leaves in the tree, for example. Tuning models is addressed in Chap. F2.2.\nTry other classifiers If a classifier’s results are unsatisfying, we can try some of the other classifiers in Earth Engine to see if the result is better or different.\nExpand the collection location It is good practice to collect points across the entire image and not just focus on one location. Also, look for pixels of the same class that show variability (e.g., for the developed class, building rooftops look different than house rooftops; for the herbaceous class, crop fields show distinctive seasonality/phenology). \nAdd more predictors We can try adding spectral indices to the input variables; this way, we are feeding the classifier new, unique information about each class. For example, there is a good chance that a vegetation index specialized for detecting vegetation health (e.g., NDVI) would improve the developed versus herbaceous classification.\n\n\nFig. F2.1.11 CART classification\nFor now, we will try another supervised learning classifier that is widely used: Random Forests (RF). The RF algorithm (Breiman 2001, Pal 2005) builds on the concept of decision trees, but adds strategies to make them more powerful. It is called a “forest” because it operates by constructing a multitude of decision trees. As mentioned previously, a decision tree creates the rules which are used to make decisions. A Random Forest will randomly choose features and make observations, build a forest of decision trees, and then use the full set of trees to estimate the class. It is a great choice when you do not have a lot of insight about the training data.\n\nFig. F2.1.12 General concept of Random Forests\nCopy and paste the code below to train the RF classifier (ee.Classifier.smileRandomForest) and apply the classifier to the image. The RF algorithm requires, as its argument, the number of trees to build. We will use 50 trees.\n/////////////// Random Forest Classifier /////////////////////\n// Train RF classifier.\nvar RFclassifier = ee.Classifier.smileRandomForest(50).train({\n   features: classifierTraining,\n   classProperty: ‘class’,\n   inputProperties: predictionBands\n});\n// Classify Landsat image.\nvar RFclassified = landsat.select(predictionBands).classify(\n   RFclassifier);\n// Add classified image to the map.\nMap.addLayer(RFclassified, classificationVis, ‘RF classified’);\nNote that in the ee.Classifier.smileRandomForest documentation (Docs tab), there is a seed (random number) parameter. Setting a seed allows you to exactly replicate your model each time you run it. Any number is acceptable as a seed.\nInspect the result (Fig. F2.1.13). How does this classified image differ from the CART one? Is the classifications better or worse? Zoom in and out and change the transparency of layers as needed. In Chap. F2.2, you will see more systematic ways to assess what is better or worse, based on accuracy metrics.\n\nFig. F2.1.13 Random Forest classified image\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F21b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F2.html#unsupervised-classification",
    "href": "F2.html#unsupervised-classification",
    "title": "4  Interpreting Images",
    "section": "6.2 Unsupervised Classification",
    "text": "6.2 Unsupervised Classification\nIn an unsupervised classification, we have the opposite process of supervised classification. Spectral classes are grouped first and then categorized into clusters. Therefore, in Earth Engine, these classifiers are ee.Clusterer objects. They are “self-taught” algorithms that do not use a set of labeled training data (i.e., they are “unsupervised”). You can think of it as performing a task that you have not experienced before, starting by gathering as much information as possible. For example, imagine learning a new language without knowing the basic grammar, learning only by watching a TV series in that language, listening to examples, and finding patterns.\nSimilar to the supervised classification, unsupervised classification in Earth Engine has this workflow:\n\nAssemble features with numeric properties in which to find clusters (training data).\nSelect and instantiate a clusterer.\nTrain the clusterer with the training data.\nApply the clusterer to the scene (classification).\nLabel the clusters.\n\nIn order to generate training data, we will use the sample method, which randomly takes samples from a region (unlike sampleRegions, which takes samples from predefined locations). We will use the image’s footprint as the region by calling the geometry method. Additionally, we will define the number of pixels (numPixels) to sample—in this case, 1000 pixels—and define a tileScale of 8 to avoid computation errors due to the size of the region. Copy and paste the code below to sample 1000 pixels from the Landsat image. You should add to the same script as before to compare supervised versus unsupervised classification results at the end.\n//////////////// Unsupervised classification ////////////////\n// Make the training dataset.\nvar training = landsat.sample({\n   region: landsat.geometry(),\n   scale: 30,\n   numPixels: 1000,\n   tileScale: 8\n});\nNow we can instantiate a clusterer and train it. As with the supervised algorithms, there are many unsupervised algorithms to choose from. We will use the k-means clustering algorithm, which is a commonly used approach in remote sensing. This algorithm identifies groups of pixels near each other in the spectral space (image x bands) by using an iterative regrouping strategy. We define a number of clusters, k, and then the method randomly distributes that number of seed points into the spectral space. A large sample of pixels is then grouped into its closest seed, and the mean spectral value of this group is calculated. That mean value is akin to a center of mass of the points, and is known as the centroid. Each iteration recalculates the class means and reclassifies pixels with respect to the new means. This process is repeated until the centroids remain relatively stable and only a few pixels change from class to class on subsequent iterations.\n\nFig. F2.1.14 K-means visual concept\nCopy and paste the code below to request four clusters, the same number as for the supervised classification, in order to directly compare them.\n// Instantiate the clusterer and train it.\nvar clusterer = ee.Clusterer.wekaKMeans(4).train(training);\nNow copy and paste the code below to apply the clusterer to the image and add the resulting classification to the Map (Fig. F2.1.15). Note that we are using a method called randomVisualizer to assign colors for the visualization. We are not associating the unsupervised classes with the color palette we defined earlier in the supervised classification. Instead, we are assigning random colors to the classes, since we do not yet know which of the unsupervised classes best corresponds to each of the named classes (e.g., forest , herbaceous). Note that the colors in Fig. F1.2.15 might not be the same as you see on your Map, since they are assigned randomly.\n// Cluster the input using the trained clusterer.\nvar Kclassified = landsat.cluster(clusterer);\n// Display the clusters with random colors.\nMap.addLayer(Kclassified.randomVisualizer(), {},   ‘K-means classified - random colors’);\n\nFig. F2.1.15 K-means classification\nInspect the results. How does this classification compare to the previous ones? If preferred, use the Inspector to check which classes were assigned to each pixel value (“cluster” band) and change the last line of your code to apply the same palette used for the supervised classification results (see Code Checkpoint below for an example).\nAnother key point of classification is the accuracy assessment of the results. This will be covered in Chap. F2.2.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F21c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F2.html#synthesis-1",
    "href": "F2.html#synthesis-1",
    "title": "4  Interpreting Images",
    "section": "Synthesis",
    "text": "Synthesis\nTest if you can improve the classifications by completing the following assignments.\nAssignment 1. For the supervised classification, try collecting more points for each class. The more points you have, the more spectrally represented the classes are. It is good practice to collect points across the entire composite and not just focus on one location. Also look for pixels of the same class that show variability. For example, for the water class, collect pixels in parts of rivers that vary in color. For the developed class, collect pixels from different rooftops.\nAssignment 2. Add more predictors. Usually, the more spectral information you feed the classifier, the easier it is to separate classes. Try calculating and incorporating a band of  NDVI or the Normalized Difference Water Index (Chap. F2.0) as a predictor band. Does this help the classification? Check for developed areas that were being classified as herbaceous or vice versa.\nAssignment 3. Use more trees in the Random Forest classifier. Do you see any improvements compared to 50 trees? Note that the more trees you have, the longer it will take to compute the results, and that more trees might not always mean better results.\nAssignment 4. Increase the number of samples that are extracted from the composite in the unsupervised classification. Does that improve the result?\nAssignment 5. Increase the number k of clusters for the k-means algorithm. What would happen if you tried 10 classes? Does the classified map result in meaningful classes?\nAssignment 6. Test other clustering algorithms. We only used k-means; try other options under the ee.Clusterer object."
  },
  {
    "objectID": "F2.html#conclusion-1",
    "href": "F2.html#conclusion-1",
    "title": "4  Interpreting Images",
    "section": "Conclusion",
    "text": "Conclusion\nClassification algorithms are key for many different applications because they allow you to predict categorical variables. You should now understand the difference between supervised and unsupervised classification and have the basic knowledge on how to handle misclassifications. By being able to map the landscape for land use and land cover, we will also be able to monitor how it changes (Part F4)."
  },
  {
    "objectID": "F2.html#references-1",
    "href": "F2.html#references-1",
    "title": "4  Interpreting Images",
    "section": "References",
    "text": "References\nBreiman L (2001) Random forests. Mach Learn 45:5–32. https://doi.org/10.1023/A:1010933404324\nGareth J, Witten D, Hastie T, Tibshirani R (2013) An Introduction to Statistical Learning. Springer\nGéron A (2019) Hands-on Machine Learning with Scikit-Learn, Keras and TensorFlow: Concepts, Tools, and Techniques to Build Intelligent Systems. O’Reilly Media, Inc.\nGoodfellow I, Bengio Y, Courville A (2016) Deep Learning. MIT Press\nHastie T, Tibshirani R, Friedman JH (2009) The Elements of Statistical Learning: Data Mining, Inference, and Prediction. Springer\nLi M, Zang S, Zhang B, et al (2014) A review of remote sensing image classification techniques: The role of spatio-contextual information. Eur J Remote Sens 47:389–411. https://doi.org/10.5721/EuJRS20144723\nMüller AC, Guido S (2016) Introduction to Machine Learning with Python: A Guide for Data Scientists. O’Reilly Media, Inc.\nPal M (2005) Random forest classifier for remote sensing classification. Int J Remote Sens 26:217–222. https://doi.org/10.1080/01431160412331269698\nWitten IH, Frank E, Hall MA, et al (2005) Practical machine learning tools and techniques. In: Data Mining. pp 4"
  },
  {
    "objectID": "F2.html#author-2",
    "href": "F2.html#author-2",
    "title": "4  Interpreting Images",
    "section": "Author",
    "text": "Author\nAndréa Puzzi Nicolau, Karen Dyson, David Saah, Nicholas Clinton"
  },
  {
    "objectID": "F2.html#overview-2",
    "href": "F2.html#overview-2",
    "title": "4  Interpreting Images",
    "section": "Overview",
    "text": "Overview\nThis chapter will enable you to assess the accuracy of an image classification. You will learn about different metrics and ways to quantify classification quality in Earth Engine. Upon completion, you should be able to evaluate whether your classification needs improvement and know how to proceed when it does."
  },
  {
    "objectID": "F2.html#learning-outcomes-2",
    "href": "F2.html#learning-outcomes-2",
    "title": "4  Interpreting Images",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nLearning how to perform accuracy assessment in Earth Engine.\nUnderstanding how to generate and read a confusion matrix.\nUnderstanding overall accuracy and the kappa coefficient.\nUnderstanding the difference between user’s and producer’s accuracy, and the difference between omission and commission errors."
  },
  {
    "objectID": "F2.html#assumes-you-know-how-to-2",
    "href": "F2.html#assumes-you-know-how-to-2",
    "title": "4  Interpreting Images",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\n​​Create a graph using ui.Chart (Chap. F1.3).\nPerform a supervised Random Forest image classification (Chap. F2.1)."
  },
  {
    "objectID": "F2.html#introduction-to-theory-2",
    "href": "F2.html#introduction-to-theory-2",
    "title": "4  Interpreting Images",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nAny map or remotely sensed product is a generalization or model that will have inherent errors. Products derived from remotely sensed data used for scientific purposes and policymaking require a quantitative measure of accuracy to strengthen the confidence in the information generated (Foody 2002, Strahler et al. 2006, Olofsson et al. 2014). Accuracy assessment is a crucial part of any classification project, as it measures the degree to which the classification agrees with another data source that is considered to be accurate, ground-truth data (i.e., “reality”).\nThe history of accuracy assessment reveals increasing detail and rigor in the analysis, moving from a basic visual appraisal of the derived map (Congalton 1994, Foody 2002) to the definition of best practices for sampling and response designs and the calculation of accuracy metrics (Foody 2002, Stehman 2013, Olofsson et al. 2014, Stehman and Foody 2019). The confusion matrix (also called the “error matrix”) (Stehman 1997) summarizes key accuracy metrics used to assess products derived from remotely sensed data.\nIn Chap. F2.1, we asked whether the classification results were satisfactory. In remote sensing, the quantification of the answer to that question is called accuracy assessment. In the classification context, accuracy measurements are often derived from a confusion matrix.\nIn a thorough accuracy assessment, we think carefully about the sampling design, the response design, and the analysis (Olofsson et al. 2014). Fundamental protocols are taken into account to produce scientifically rigorous and transparent estimates of accuracy and area, which requires robust planning and time. In a standard setting, we would calculate the number of samples needed for measuring accuracy (sampling design). Here, we will focus mainly on the last step, analysis, by examining the confusion matrix and learning how to calculate the accuracy metrics. This will be done by partitioning the existing data into training and testing sets."
  },
  {
    "objectID": "F2.html#quantifying-classification-accuracy-through-a-confusion-matrix",
    "href": "F2.html#quantifying-classification-accuracy-through-a-confusion-matrix",
    "title": "4  Interpreting Images",
    "section": "7.1 Quantifying Classification Accuracy Through a Confusion Matrix",
    "text": "7.1 Quantifying Classification Accuracy Through a Confusion Matrix\nIf you have not already done so, be sure to add the book’s code repository to the Code Editor by entering https://code.earthengine.google.com/?accept_repo=projects/gee-edu/book into your browser. The book’s scripts will then be available in the script manager panel. If you have trouble finding the repo, you can visit this link for help.\nTo illustrate some of the basic ideas about classification accuracy, we will revisit the data and location of part of Chap. F2.1, where we tested different classifiers and classified a Landsat image of the area around Milan, Italy. We will name this dataset ‘data’. This variable is a FeatureCollection with features containing the “class” values (Table F2.2.1) and spectral information of four land cover / land use classes: forest, developed, water, and herbaceous (see Fig. F2.1.8 and Fig. F2.1.9 for a refresher). We will also define a variable, predictionBands, which is a list of bands that will be used for prediction (classification)—the spectral information in the data variable.\nTable F2.2.1 Land cover classes\nClass\nClass value\nForest\n0\nDeveloped\n1\nWater\n2\nHerbaceous\n3\nThe first step is to partition the set of known values into training and testing sets in order to have something for the classifier to predict over that it has not been shown before (the testing set), mimicking unseen data that the model might see in the future. We add a column of random numbers to our FeatureCollection using the randomColumn method. Then, we filter the features into about 80% for training and 20% for testing using ee.Filter. Copy and paste the code below to partition the data and filter features based on the random number.\n// Import the reference dataset.\nvar data = ee.FeatureCollection(   ‘projects/gee-book/assets/F2-2/milan_data’);\n// Define the prediction bands.\nvar predictionBands = [   ‘SR_B1’, ‘SR_B2’, ‘SR_B3’, ‘SR_B4’, ‘SR_B5’, ‘SR_B6’, ‘SR_B7’,   ‘ST_B10’,   ‘ndvi’, ‘ndwi’\n];\n// Split the dataset into training and testing sets.\nvar trainingTesting = data.randomColumn();\nvar trainingSet = trainingTesting\n   .filter(ee.Filter.lessThan(‘random’, 0.8));\nvar testingSet = trainingTesting\n   .filter(ee.Filter.greaterThanOrEquals(‘random’, 0.8));\nNote that randomColumn creates pseudorandom numbers in a deterministic way. This makes it possible to generate a reproducible pseudorandom sequence by defining the seed parameter (Earth Engine uses a seed of 0 by default). In other words, given a starting value (i.e., the seed), randomColumn will always provide the same sequence of pseudorandom numbers.\nCopy and paste the code below to train a Random Forest classifier with 50 decision trees using the trainingSet.\n// Train the Random Forest Classifier with the trainingSet.\nvar RFclassifier = ee.Classifier.smileRandomForest(50).train({\n   features: trainingSet,\n   classProperty: ‘class’,\n   inputProperties: predictionBands\n});\nNow, let’s discuss what a confusion matrix is. A confusion matrix describes the quality of a classification by comparing the predicted values to the actual values. A simple example is a confusion matrix for a binary classification into the classes “positive” and “negative,” as shown in Table F2.2.1.\nTable F2.2.1 Confusion matrix for a binary classification where the classes are “positive” and “negative”\nActual values\nPositive\nNegative\nPredicted values\nPositive\nTP (true positive)\nFP (false positive)\nNegative\nFN (false negative)\nTN (true negative)\nIn Table F2.2.1, the columns represent the actual values (the truth), while the rows represent the predictions (the classification). “True positive” (TP) and “true negative” (TN) mean that the classification of a pixel matches the truth (e.g., a water pixel correctly classified as water). “False positive” (FP) and “false negative” (FN) mean that the classification of a pixel does not match the truth (e.g., a non-water pixel incorrectly classified as water).\n\nTP: classified as positive and the actual class is positive\nFP: classified as positive and the actual class is negative\nFN: classified as negative and the actual class is positive\nTN: classified as negative and the actual class is negative\n\nWe can extract some statistical information from a confusion matrix.. Let’s look at an example to make this clearer. Table F2.2.2 is a confusion matrix for a sample of 1,000 pixels for a classifier that identifies whether a pixel is forest (positive) or non-forest (negative), a binary classification.\nTable F2.2.2 Confusion matrix for a binary classification where the classes are “positive” (forest) and “negative” (non-forest)\nActual values\nPositive\nNegative\nPredicted values\nPositive\n307\n18\nNegative\n14\n661\nIn this case, the classifier correctly identified 307 forest pixels, wrongly classified 18 non-forest pixels as forest, correctly identified 661 non-forest pixels, and wrongly classified 14 forest pixels as non-forest. Therefore, the classifier was correct 968 times and wrong 32 times. Let’s calculate the main accuracy metrics for this example.\nThe overall accuracy tells us what proportion of the reference data was classified correctly, and is calculated as the total number of correctly identified pixels divided by the total number of pixels in the sample.\n\nIn this case, the overall accuracy is 96.8%, calculated using (.\nTwo other important accuracy metrics are the producer’s accuracy and the user’s accuracy, also referred to as the “recall” and the “precision,” respectively. Importantly, these metrics quantify aspects of per-class accuracy.\nThe producer’s accuracy is the accuracy of the map from the point of view of the map maker (the “producer”), and is calculated as the number of correctly identified pixels of a given class divided by the total number of pixels actually in that class. The producer’s accuracy for a given class tells us the proportion of the pixels in that class that were classified correctly.\n\n\nIn this case, the producer’s accuracy for the forest class is 95.6%, calculated using ). The producer’s accuracy for the non-forest class is 97.3%, calculated from ).\nThe user’s accuracy (also called the “consumer’s accuracy”) is the accuracy of the map from the point of view of a map user, and is calculated as the number of correctly identified pixels of a given class divided by the total number of pixels claimed to be in that class. The user’s accuracy for a given class tells us the proportion of the pixels identified on the map as being in that class that are actually in that class on the ground.\n\n\nIn this case, the user’s accuracy for the forest class is 94.5%, calculated using ). The user’s accuracy for the non-forest class is 97.9%, calculated from ).\nFig. F2.2.1 helps visualize the rows and columns used to calculate each accuracy.\n\nFig. F2.2.1 Confusion matrix for a binary classification where the classes are “positive” (forest) and “negative” (non-forest), with accuracy metrics\nIt is very common to talk about two types of error when addressing remote-sensing classification accuracy: omission errors and commission errors. Omission errors refer to the reference pixels that were left out of (omitted from) the correct class in the classified map. In a two-class system, an error of omission in one class will be counted as an error of commission in another class. Omission errors are complementary to the producer’s accuracy.\n \nCommission errors refer to the class pixels that were erroneously classified in the map and are complementary to the user’s accuracy.\n\nFinally, another commonly used accuracy metric is the kappa coefficient, which  evaluates how well the classification performed as compared to random. The value of the kappa coefficient can range from −1 to 1: a negative value indicates that the classification is worse than a random assignment of categories would have been; a value of 0 indicates that the classification is no better or worse than random; and a positive value indicates that the classification is better than random.\n\nThe chance agreement is calculated as the sum of the product of row and column totals for each class, and the observed accuracy is the overall accuracy. Therefore, for our example, the kappa coefficient is 0.927.\n\nNow, let’s go back to the script. In Earth Engine, there are API calls for these operations. Note that our confusion matrix will be a 4 x 4 table, since we have four different classes.\nCopy and paste the code below to classify the testingSet and get a confusion matrix using the method errorMatrix. Note that the classifier automatically adds a property called “classification,” which is compared to the “class” property of the reference dataset.\n// Now, to test the classification (verify model’s accuracy),\n// we classify the testingSet and get a confusion matrix.\nvar confusionMatrix = testingSet.classify(RFclassifier)\n   .errorMatrix({\n       actual: ‘class’,\n       predicted: ‘classification’   });\nCopy and paste the code below to print the confusion matrix and accuracy metrics. Expand the confusion matrix object to inspect it. The entries represent the number of pixels. Items on the diagonal represent correct classification. Items off the diagonal are misclassifications, where the class in row i is classified as column j (values from 0 to 3 correspond to our class codes: forest, developed, water, and herbaceous, respectively). Also expand the producer’s accuracy, user’s accuracy (consumer’s accuracy), and kappa coefficient objects to inspect them.\n// Print the results.\nprint(‘Confusion matrix:’, confusionMatrix);\nprint(‘Overall Accuracy:’, confusionMatrix.accuracy());\nprint(‘Producers Accuracy:’, confusionMatrix.producersAccuracy());\nprint(‘Consumers Accuracy:’, confusionMatrix.consumersAccuracy());\nprint(‘Kappa:’, confusionMatrix.kappa());\nHow is the classification accuracy? Which classes have higher accuracy compared to the others? Can you think of any reasons why? (Hint: Check where the errors in these classes are in the confusion matrix—i.e., being committed and omitted.)\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F22a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F2.html#hyperparameter-tuning",
    "href": "F2.html#hyperparameter-tuning",
    "title": "4  Interpreting Images",
    "section": "7.2 Hyperparameter tuning",
    "text": "7.2 Hyperparameter tuning\nWe can also assess how the number of trees in the Random Forest classifier affects the classification accuracy. Copy and paste the code below to create a function that charts the overall accuracy versus the number of trees used. The code tests from 5 to 100 trees at increments of 5, producing Fig. F2.2.2. (Do not worry too much about fully understanding each item at this stage of your learning. If you want to find out how these operations work, you can see more in Chaps. F4.0 and F4.1.)\n// Hyperparameter tuning.\nvar numTrees = ee.List.sequence(5, 100, 5);\nvar accuracies = numTrees.map(function(t) {   var classifier = ee.Classifier.smileRandomForest(t)\n       .train({\n           features: trainingSet,\n           classProperty: ‘class’,\n           inputProperties: predictionBands\n       });   return testingSet\n       .classify(classifier)\n       .errorMatrix(‘class’, ‘classification’)\n       .accuracy();\n});\nprint(ui.Chart.array.values({\n   array: ee.Array(accuracies),\n   axis: 0,\n   xLabels: numTrees\n}).setOptions({\n   hAxis: {\n       title: ‘Number of trees’   },\n   vAxis: {\n       title: ‘Accuracy’   },\n   title: ‘Accuracy per number of trees’\n}));\n\nFig. F2.2.2 Chart showing accuracy per number of Random Forest trees\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F22b. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nSection 3. Spatial autocorrelation\nWe might also want to ensure that the samples from the training set are uncorrelated with the samples from the testing set. This might result from the spatial autocorrelation of the phenomenon being predicted. One way to exclude samples that might be correlated in this manner is to remove samples that are within some distance to any other sample. In Earth Engine, this can be accomplished with a spatial join. The following Code Checkpoint replicates Sect. 1 but with a spatial join that excludes training points that are less than 1000 meters distant from testing points.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F22c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F2.html#synthesis-2",
    "href": "F2.html#synthesis-2",
    "title": "4  Interpreting Images",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. Based on Sect. 1, test other classifiers (e.g., a Classification and Regression Tree or Support Vector Machine classifier) and compare the accuracy results with the Random Forest results. Which model performs better?\nAssignment 2. Try setting a different seed in the randomColumn method and see how that affects the accuracy results. You can also change the split between the training and testing sets (e.g., 70/30 or 60/40)."
  },
  {
    "objectID": "F2.html#conclusion-2",
    "href": "F2.html#conclusion-2",
    "title": "4  Interpreting Images",
    "section": "Conclusion",
    "text": "Conclusion\nYou should now understand how to calculate how well your classifier is performing on the data used to build the model. This is a useful way to understand how a classifier is performing, because it can help indicate which classes are performing better than others. A poorly modeled class can sometimes be improved by, for example, collecting more training points for that class.\nNevertheless, a model may work well on training data but work poorly in locations randomly chosen in the study area. To understand a model’s behavior on testing data, analysts employ protocols required to produce scientifically rigorous and transparent estimates of the accuracy and area of each class in the study region. We will not explore those practices in this chapter, but if you are interested, there are tutorials and papers available online that can guide you through the process. Links to some of those tutorials can be found in the “For Further Reading” section of this book.\nReferences\nCongalton R (1994) Accuracy assessment of remotely sensed data: Future needs and directions. In: Proceedings of Pecora 12 land information from space-based systems. pp 385–388\nFoody GM (2002) Status of land cover classification accuracy assessment. Remote Sens Environ 80:185–201. https://doi.org/10.1016/S0034-4257(01)00295-4\nOlofsson P, Foody GM, Herold M, et al (2014) Good practices for estimating area and assessing accuracy of land change. Remote Sens Environ 148:42–57. https://doi.org/10.1016/j.rse.2014.02.015\nStehman SV (2013) Estimating area from an accuracy assessment error matrix. Remote Sens Environ 132:202–211. https://doi.org/10.1016/j.rse.2013.01.016\nStehman SV (1997) Selecting and interpreting measures of thematic classification accuracy. Remote Sens Environ 62:77–89. https://doi.org/10.1016/S0034-4257(97)00083-7\nStehman SV, Foody GM (2019) Key issues in rigorous accuracy assessment of land cover products. Remote Sens Environ 231:111199. https://doi.org/10.1016/j.rse.2019.05.018\nStrahler AH, Boschetti L, Foody GM, et al (2006) Global land cover validation: Recommendations for evaluation and accuracy assessment of global land cover maps. Eur Communities, Luxemb 51:1–60"
  },
  {
    "objectID": "F4.html",
    "href": "F4.html",
    "title": "5  Interpreting Image Series",
    "section": "",
    "text": "6 Filter, Map, Reduce\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information\n::: {.callout-tip} # Chapter Information\nFig. F4.8.1 BULC interface\nAfter you have run the script, BULC’s interface requires that a few parameters be set; these are specified using the left panel. Here, we describe and populate each of the required parameters, which are shown in red. As you proceed, the default red color will change to green when a parameter receives a value.\nBULC makes relatively small demands on memory since its arithmetic uses only multiplication, addition, and division, without the need for complex function fitting. The specific memory use is tied to the overlay method used. In particular, Event-by-Event comparisons (the Overlay setting) are considerably more computationally expensive than pre-defined transition tables (the Identity and Custom settings). The maximum working Event depth is also slightly lowered when intermediate probability values are returned for inspection. Our tests indicate that with pre-defined truth tables and no intermediate probability values returned, BULC can handle updating problems hundreds of Events deep across an arbitrarily large area.\nWhen you have finished setting the required parameters, the interface will look like Fig. 4.8.2.\nFig. 4.8.2 Initial settings for the key driving parameters of BULC\nBeneath the required parameters is a set of optional parameters that affect which intermediate results are stored during a run for later inspection. We are also given a choice of returning intermediate results for closer inspection. At this stage, you can leave all optional parameters out of the BULC call by leaving them blanked or unchecked.\nAfter clicking the Apply Parameters button at the bottom of the left panel, the classifications and parameters are sent to the BULC modules. The Map will move to the study area, and after a few seconds, the Console will hold new thumbnails. The uppermost thumbnail is a rapidly changing view of the input classifications. Beneath that is a thumbnail of the same area as interpreted by BULC. Beneath those is a Confidence thumbnail, which is discussed in detail later in this lab.\nThe BULC interpretation of the landscape looks roughly like the Event inputs, but it is different in two important ways. First, depending on the leveler settings, it will usually have less noise than the Event classifications. In the settings above, we used the Transition and Posterior levelers to tell BULC to trust past accumulated evidence more than a single new image. The second key difference between the BULC result and the input classifications is that even when the inputs don’t cover the whole area at each time step, BULC provides an estimate in every pixel at each time step. To create this continuous classification, if a new classification does not have data for some part of the study area (beyond the edge of a given image, for example), the last best guess from the previous iteration is carried forward. Simply put, the estimate in a given pixel is kept the same until new data arrives.\nMeanwhile, below the Console, the rest of the interface changes when BULC is run. The Map panel displays BULC’s classification for the final date: that is, after considering the evidence from each of the input classifications. We can use the Satellite background to judge whether BULC is accurately capturing the state of LULC. This can be done by unselecting the drawn layers in the map layer set and selecting Satellite from the choices in the upper-right part of the Map panel. Earth Engine’s background satellite images are often updated, so you should see something like the right side of Fig. F4.8.3, though it may differ slightly.\nFig. 4.8.3 BULC estimation of the state of LULC at the end of 2021 (left). Satellite backdrop for Earth Engine (right), which may differ from what you see due to updates.\nQuestion 1. When comparing the BULC classification for 2021 against the current Earth Engine satellite view, what are the similarities and differences? Note that in Earth Engine, the copyrighted year numbers at the bottom of the screen may not coincide with the precise date of the image shown.\nIn the rightmost panel below the Console, the interface offers you multiple options for viewing the results. These include:\nQuestion 2. Select the BULC option, then select the Movie tool to view the result, and choose a drawing speed and resolution. When viewing the full area, would you assess the additional LULC changes since 2016 as being minor, moderate, or major compared to the changes that occurred before 2016? Explain the reasoning for your assessment.\n::: {.callout-tip} # Chapter Information"
  },
  {
    "objectID": "F4.html#author",
    "href": "F4.html#author",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\nJeffrey A. Cardille"
  },
  {
    "objectID": "F4.html#overview",
    "href": "F4.html#overview",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\nThe purpose of this chapter is to teach you important programming concepts as they are applied in Earth Engine. We first illustrate how the order and type of these operations can matter with a real-world, non-programming example. We then demonstrate these concepts with an ImageCollection, a key data type that distinguishes Earth Engine from desktop image-processing implementations."
  },
  {
    "objectID": "F4.html#learning-outcomes",
    "href": "F4.html#learning-outcomes",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nVisualizing the concepts of filtering, mapping, and reducing with a hypothetical, non-programming example.\nGaining context and experience with filtering an ImageCollection.\nLearning how to efficiently map a user-written function over the images of a filtered ImageCollection.\nLearning how to summarize a set of assembled values using Earth Engine reducers."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to",
    "href": "F4.html#assumes-you-know-how-to",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nPerform basic image analysis: select bands, compute indices, create masks (Part F2)."
  },
  {
    "objectID": "F4.html#introduction-to-theory",
    "href": "F4.html#introduction-to-theory",
    "title": "5  Interpreting Image Series",
    "section": "13.1 Introduction to Theory ",
    "text": "13.1 Introduction to Theory \n“A time series is a sequence of observations taken sequentially in time. … An intrinsic feature of a time series is that, typically, adjacent observations are dependent. Time-series analysis is concerned with techniques for the analysis of this dependency.” This is the formal definition of time-series analysis by Box et al. (1994). In a remote sensing context, the observations of interest are measurements of radiation reflected from the surface of the Earth from the Sun or an instrument emitting energy toward Earth. Consecutive measurements made over a given area result in a time series of surface reflectance. By analyzing such time series, we can achieve a comprehensive characterization of ecosystem and land surface processes (Kennedy et al. 2014). The result is a shift away from traditional, retrospective change-detection approaches based on data acquired over the same area at two or a few points in time to continuous monitoring of the landscape (Woodcock et al. 2020). Previous obstacles related to data storage, preprocessing, and computing power have been largely overcome with the emergence of powerful cloud-computing platforms that provide direct access to the data (Gorelick et al. 2017). In this chapter, we will illustrate how to study landscape dynamics in the Amazon river basin by analyzing dense time series of Landsat data using the CCDC algorithm. Unlike LandTrendr (Chap. F4.5), which uses anniversary images to fit straight line segments that describe the spectral trajectory over time, CCDC uses all available clear observations. This has multiple advantages, including the ability to detect changes within a year and capture seasonal patterns, although at the expense of much higher computational demands and more complexity to manipulate the outputs, compared to LandTrendr."
  },
  {
    "objectID": "F4.html#filtering-image-collections-in-earth-engine",
    "href": "F4.html#filtering-image-collections-in-earth-engine",
    "title": "5  Interpreting Image Series",
    "section": "6.1 Filtering Image Collections in Earth Engine",
    "text": "6.1 Filtering Image Collections in Earth Engine\nThe first part of the filter, map, reduce paradigm is “filtering” to get a smaller ImageCollection from a larger one. As in the milk example, filters take a large set of items, limit it by some criterion, and return a smaller set for consideration. Here, filters take an ImageCollection, limit it by some criterion of date, location, or image characteristics, and return a smaller ImageCollection (Fig. F4.0.1).\n\nFig. 4.0.1 Filter, map, reduce as applied to image collections in Earth Engine\nAs described first in Chap. F1.2, the Earth Engine API provides a set of filters for the ImageCollection type. The filters can limit an ImageCollection based on spatial, temporal, or attribute characteristics. Filters were used in Parts F1, F2, and F3 without much context or explanation, to isolate an image from an ImageCollection for inspection or manipulation. The information below should give perspective on that work while introducing some new tools for filtering image collections.\nBelow are three examples of limiting a Landsat 5 ImageCollection by characteristics and assessing the size of the resulting set.\nFilterDate This takes an ImageCollection as input and returns an ImageCollection whose members satisfy the specified date criteria. We’ll adapt the earlier filtering logic seen in Chap. F1.2:\nvar imgCol = ee.ImageCollection(‘LANDSAT/LT05/C02/T1_L2’);\n// How many Tier 1 Landsat 5 images have ever been collected?\nprint(“All images ever:”, imgCol.size()); // A very large number\n// How many images were collected in the 2000s?\nvar startDate = ‘2000-01-01’;\nvar endDate = ‘2010-01-01’;\nvar imgColfilteredByDate = imgCol.filterDate(startDate, endDate);\nprint(“All images 2000-2010:”, imgColfilteredByDate.size());\n// A smaller (but still large) number\nAfter running the code, you should get a very large number for the full set of images. You also will likely get a very large number for the subset of images over the decade-scale interval.  \nFilterBounds It may be that—similar to the milk example—only images near to a place of interest are useful for you. As first presented in Part F1, filterBounds takes an ImageCollection as input and returns an ImageCollection whose images surround a specified location. If we take the ImageCollection that was filtered by date and then filter it by bounds, we will have filtered the collection to those images near a specified point within the specified date interval. With the code below, we’ll count the number of images in the Shanghai vicinity, first visited in Chap. F1.1, from the early 2000s:\nvar ShanghaiImage = ee.Image(   ‘LANDSAT/LT05/C02/T1_L2/LT05_118038_20000606’);\nMap.centerObject(ShanghaiImage, 9);\nvar imgColfilteredByDateHere = imgColfilteredByDate.filterBounds(Map   .getCenter());\nprint(“All images here, 2000-2010:”, imgColfilteredByDateHere\n.size()); // A smaller number\nIf you’d like, you could take a few minutes to explore the behavior of the script in different parts of the world. To do that, you would need to comment out the Map.centerObject command to keep the map from moving to that location each time you run the script.\nFilter by Other Image Metadata        As first explained in Chap. F1.3, the date and location of an image are characteristics stored with each image. Another important factor in image processing is the cloud cover, an image-level value computed for each image in many collections, including the Landsat and Sentinel-2 collections. The overall cloudiness score might be stored under different metadata tag names in different data sets. For example, for Sentinel-2, this overall cloudiness score is stored in the CLOUDY_PIXEL_PERCENTAGE metadata field. For Landsat 5, the ImageCollection we are using in this example, the image-level cloudiness score is stored using the tag CLOUD_COVER. If you are unfamiliar with how to find this information, these skills are first presented in Part F1.\nHere, we will access the ImageCollection that we just built using filterBounds and filterDate, and then further filter the images by the image-level cloud cover score, using the filterMetadata function.\nNext, let’s remove any images with 50% or more cloudiness. As will be described in subsequent chapters working with per-pixel cloudiness information, you might want to retain those images in a real-life study, if you feel some values within cloudy images might be useful. For now, to illustrate the filtering concept, let’s keep only images whose image-level cloudiness values indicate that the cloud coverage is lower than 50%. Here, we will take the set already filtered by bounds and date, and further filter it using the cloud percentage into a new ImageCollection. Add this line to the script to filter by cloudiness and print the size to the Console.\nvar L5FilteredLowCloudImages = imgColfilteredByDateHere\n   .filterMetadata(‘CLOUD_COVER’, ‘less_than’, 50);\nprint(“Less than 50% clouds in this area, 2000-2010”,\n   L5FilteredLowCloudImages.size()); // A smaller number\nFiltering in an Efficient Order As you saw earlier in the hypothetical milk example, we typically filter, then map, and then reduce, in that order. In the same way that we would not want to call every store on Earth, preferring instead to narrow down the list of potential stores first, we filter images first in our workflow in Earth Engine. In addition, you may have noticed that the ordering of the filters within the filtering stage also mattered in the milk example. This is also true in Earth Engine. For problems with a non-global spatial component in which filterBounds is to be used, it is most efficient to do that spatial filtering first.\nIn the code below, you will see that you can “chain” the filter commands, which are then executed from left to right. Below, we chain the filters in the same order as you specified above. Note that it gives an ImageCollection of the same size as when you applied the filters one at a time.\nvar chainedFilteredSet = imgCol.filterDate(startDate, endDate)\n   .filterBounds(Map.getCenter())\n   .filterMetadata(‘CLOUD_COVER’, ‘less_than’, 50);\nprint(‘Chained: Less than 50% clouds in this area, 2000-2010’,\n   chainedFilteredSet.size());\nIn the code below, we chain the filters in a more efficient order, implementing filterBounds first. This, too, gives an ImageCollection of the same size as when you applied the filters in the less efficient order, whether the filters were chained or not.\nvar efficientFilteredSet = imgCol.filterBounds(Map.getCenter())\n   .filterDate(startDate, endDate)\n   .filterMetadata(‘CLOUD_COVER’, ‘less_than’, 50);\nprint(‘Efficient filtering: Less than 50% clouds in this area, 2000-2010’,\n   efficientFilteredSet.size());\nEach of the two chained sets of operations will give the same result as before for the number of images. While the second order is more efficient, both approaches are likely to return the answer to the Code Editor at roughly the same time for this very small example. The order of operations is most important in larger problems in which you might be challenged to manage memory carefully. As in the milk example in which you narrowed geographically first, it is good practice in Earth Engine to order the filters with the filterBounds first, followed by metadata filters in order of decreasing specificity.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F40a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nNow, with an efficiently filtered collection that satisfies our chosen criteria, we will next explore the second stage: executing a function for all of the images in the set."
  },
  {
    "objectID": "F4.html#mapping-over-image-collections-in-earth-engine",
    "href": "F4.html#mapping-over-image-collections-in-earth-engine",
    "title": "5  Interpreting Image Series",
    "section": "6.2 Mapping over Image Collections in Earth Engine",
    "text": "6.2 Mapping over Image Collections in Earth Engine\nIn Chap. F3.1, we calculated the Enhanced Vegetation Index (EVI) in very small steps to illustrate band arithmetic on satellite images. In that chapter, code was called once, on a single image. What if we wanted to compute the EVI in the same way for every image of an entire ImageCollection? Here, we use the key tool for the second part of the workflow in Earth Engine, a .map command (Fig. F4.0.1). This is roughly analogous to the step of making phone calls in the milk example that began this chapter, in which you took a list of store names and transformed it through effort into a list of milk prices.\nBefore beginning to code the EVI functionality, it’s worth noting that the word “map” is encountered in multiple settings during cloud-based remote sensing, and it’s important to be able to distinguish the uses. A good way to think of it is that “map” can act as a verb or as a noun in Earth Engine. There are two uses of “map” as a noun. We might refer casually to “the map,” or more precisely to “the  Map panel”; these terms refer to the place where the images are shown in the code interface. A second way “map” is used as a noun is to refer to an Earth Engine object, which has functions that can be called on it. Examples of this are the familiar Map.addLayer and Map.setCenter. Where that use of the word is intended, it will be shown in purple text and capitalized in the Code Editor. What we are discussing here is the use of .map as a verb, representing the idea of performing a set of actions repeatedly on a set. This is typically referred to as “mapping over the set.”  \nTo map a given set of operations efficiently over an entire ImageCollection, the processing needs to be set up in a particular way. Users familiar with other programming languages might expect to see “loop” code to do this, but the processing is not done exactly that way in Earth Engine. Instead, we will create a function, and then map it over the ImageCollection. To begin, envision creating a function that takes exactly one parameter, an ee.Image. The function is then designed to perform a specified set of operations on the input ee.Image and then, importantly, returns an ee.Image as the last step of the function. When we map that function over an ImageCollection, as we’ll illustrate below, the effect is that we begin with an ImageCollection, do operations to each image, and receive a processed ImageCollection as the output.\nWhat kinds of functions could we create? For example, you could imagine a function taking an image and returning an image whose pixels have the value 1 where the value of a given band was lower than a certain threshold, and 0 otherwise. The effect of mapping this function would be an entire ImageCollection of images with zeroes and ones representing the results of that test on each image. Or you could imagine a function computing a complex self-defined index and sending back an image of that index calculated in each pixel. Here, we’ll create a function to compute the EVI for any input Landsat 5 image and return the one-band image for which the index is computed for each pixel. Copy and paste the function definition below into the Code Editor, adding it to the end of the script from the previous section.\nvar makeLandsat5EVI = function(oneL5Image) {   // compute the EVI for any Landsat 5 image. Note it’s specific to   // Landsat 5 images due to the band numbers. Don’t run this exact   // function for images from sensors other than Landsat 5.   // Extract the bands and divide by 1e4 to account for scaling done.   var nirScaled = oneL5Image.select(‘SRvide(10000);   var redScaled = oneL5Image.select(’SR_B3’).divide(10000);   var blueScaled = oneL5Image.select(‘SR_B1’).divide(10000);   // Calculate the numerator, note that order goes from left to right.   var numeratorEVI = (nirScaled.subtract(redScaled)).multiply(       2.5);   // Calculate the denominator   var denomClause1 = redScaled.multiply(6);   var denomClause2 = blueScaled.multiply(7.5);   var denominatorEVI = nirScaled.add(denomClause1).subtract(\n       denomClause2).add(1);   // Calculate EVI and name it.   var landsat5EVI = numeratorEVI.divide(denominatorEVI).rename(       ‘EVI’);   return (landsat5EVI);\n};\nIt is worth emphasizing that, in general, band names are specific to each ImageCollection. As a result, if that function were run on an image without the band ‘SR_B4’, for example, the function call would fail. Here, we have emphasized in the function’s name that it is specifically for creating EVI for Landsat 5.  \nThe function makeLandsat5EVI is built to receive a single image, select the proper bands for calculating EVI, make the calculation, and return a one-banded image. If we had the name of each image comprising our ImageCollection, we could enter the names into the Code Editor and call the function one at a time for each, assembling the images into variables, and then combining them into an ImageCollection. This would be very tedious and highly prone to mistakes: lists of items might get mistyped, an image might be missed, etc. Instead, as mentioned above, we will use .map. With the code below, let’s print the information about the cloud-filtered collection and display it, execute the .map command, and explore the resulting ImageCollection.\nvar L5EVIimages = efficientFilteredSet.map(makeLandsat5EVI);\nprint(‘Verifying that the .map gives back the same number of images:’,\n   L5EVIimages.size());\nprint(L5EVIimages);\nMap.addLayer(L5EVIimages, {}, ‘L5EVIimages’, 1, 1);\nAfter entering and executing this code, you will see a grayscale image. If you look closely at the edges of the image, you might spot other images drawn behind it in a way that looks somewhat like a stack of papers on a table. This is the drawing of the ImageCollection made from the makeLandsat5EVI function. You can select the Inspector panel and click on one of the grayscale pixels to view the values of the entire ImageCollection. After clicking on a pixel, look for the Series tag by opening and closing the list of items. When you open that tag, you will see a chart of the EVI values at that pixel, created by mapping the makeLandsat5EVI function over the filtered ImageCollection.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F40b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#reducing-an-image-collection",
    "href": "F4.html#reducing-an-image-collection",
    "title": "5  Interpreting Image Series",
    "section": "6.3 Reducing an Image Collection",
    "text": "6.3 Reducing an Image Collection\nThe third part of the filter, map, reduce paradigm is “reducing” values in an ImageCollection to extract meaningful values (Fig. F4.0.1). In the milk example, we reduced a large list of milk prices to find the minimum value. The Earth Engine API provides a large set of reducers for reducing a set of values to a summary statistic.\nHere, you can think of each location, after the calculation of EVI has been executed though the .map command, as having a list of EVI values on it. Each pixel contains a potentially very large set of EVI values; the stack might be 15 items high in one location and perhaps 200, 2000, or 200,000 items high in another location, especially if a looser set of filters had been used.\nThe code below computes the mean value, at every pixel, of the ImageCollection L5EVIimages created above. Add it at the bottom of your code.\nvar L5EVImean = L5EVIimages.reduce(ee.Reducer.mean());\nprint(L5EVImean);\nMap.addLayer(L5EVImean, {\n   min: -1,\n   max: 2,\n   palette: [‘red’, ‘white’, ‘green’]\n}, ‘Mean EVI’);\nUsing the same principle, the code below computes and draws the median value of the ImageCollection in every pixel.\nvar L5EVImedian = L5EVIimages.reduce(ee.Reducer.median());\nprint(L5EVImedian);\nMap.addLayer(L5EVImedian, {\n   min: -1,\n   max: 2,\n   palette: [‘red’, ‘white’, ‘green’]\n}, ‘Median EVI’);\n\n\nFig. 4.0.2 The effects of two reducers on mapped EVI values in a filtered ImageCollection: mean image (above), and median image (below)\nThere are many more reducers that work with an ImageCollection to produce a wide range of summary statistics. Reducers are not limited to returning only one item from the reduction. The minMax reducer, for example, returns a two-band image for each band it is given, one for the minimum and one for the maximum.\nThe reducers described here treat each pixel independently. In subsequent chapters in Part F4, you will see other kinds of reducers—for example, ones that summarize the characteristics in the neighborhood surrounding each pixel.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F40c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#synthesis",
    "href": "F4.html#synthesis",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. Compare the mean and median images produced in Sect. 3 (Fig. 4.0.2). In what ways do they look different, and in what ways do they look alike? To understand how they work, pick a pixel and inspect the EVI values computed. In your opinion, which is a better representative of the data set?\nAssignment 2. Adjust the filters to filter a different proportion of clouds, or a different date range. What effects do these changes have on the number of images and the look of the reductions made from them?\nAssignment 3. Explore the ee.Filter options in the API documentation, and select a different filter that might be of interest. Filter images using it, and comment on the number of images and the reductions made from them.\nAssignment 4. Change the EVI function so that it returns the original image with the EVI band appended by replacing the return statement with this: return (oneL5Image.addBands(landsat5EVI))\nWhat does the median reducer return in that case? Some EVI values are 0. What are the conditions in which this occurs?  \nAssignment 5. Choose a date and location that is important to you (e.g., your birthday and your place of birth). Filter Landsat imagery to get all the low-cloud imagery at your location within 6 months of the date. Then, reduce the ImageCollection to find the median EVI. Describe the image and how representative of the full range of values it is, in your opinion."
  },
  {
    "objectID": "F4.html#conclusion",
    "href": "F4.html#conclusion",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned about the paradigm of filter, map, reduce. You learned how to use these tools to sift through, operate on, and summarize a large set of images to suit your purposes. Using the Filter functionality, you learned how to take a large ImageCollection and filter away images that do not meet your criteria, retaining only those images that match a given set of characteristics. Using the Map functionality, you learned how to apply a function to each image in an ImageCollection, treating each image one at a time and executing a requested set of operations on each. Using the Reduce functionality, you learned how to summarize the elements of an ImageCollection, extracting summary values of interest. In the subsequent chapters of Part 4, you will encounter these concepts repeatedly, manipulating image collections according to your project needs using the building blocks seen here. By building on what you have done in this chapter, you will grow in your ability to do sophisticated projects in Earth Engine."
  },
  {
    "objectID": "F4.html#author-1",
    "href": "F4.html#author-1",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\nGennadii Donchyts"
  },
  {
    "objectID": "F4.html#overview-1",
    "href": "F4.html#overview-1",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\nThis chapter teaches how to explore image collections, including their spatiotemporal extent, resolution, and values stored in images and image properties. You will learn how to map and inspect image collections using maps, charts, and interactive tools, and how to compute different statistics of values stored in image collections using reducers."
  },
  {
    "objectID": "F4.html#learning-outcomes-1",
    "href": "F4.html#learning-outcomes-1",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n \n\nInspecting the spatiotemporal extent and resolution of image collections by mapping image geometry and plotting image time properties.\nExploring properties of images stored in an ImageCollection by plotting charts and deriving statistics.\nFiltering image collections by using stored or computed image properties.\nExploring the distribution of values stored in image pixels of an ImageCollection through percentile reducers."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-1",
    "href": "F4.html#assumes-you-know-how-to-1",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nPerform basic image analysis: select bands, compute indices, create masks (Part F2).\nSummarize an ImageCollection with reducers (Chap. F4.0).\n\n\nIn the previous chapter (Chap. F4.0), the filter, map, reduce paradigm was introduced. The main goal of this chapter is to demonstrate some of the ways that those concepts can be used within Earth Engine to better understand the variability of values stored in image collections. Sect. 1 demonstrates how time-dependent values stored in the images of an ImageCollection can be inspected using the Code Editor user interface after filtering them to a limited spatiotemporal range (i.e., geometry and time ranges). Sect. 2 shows how the extent of images, as well as basic statistics, such as the number of observations, can be visualized to better understand the spatiotemporal extent of image collections. Then, Sects. 3 and 4 demonstrate how simple reducers such as mean and median, and more advanced reducers such as percentiles, can be used to better understand how the values of a filtered ImageCollection are distributed."
  },
  {
    "objectID": "F4.html#filtering-and-inspecting-an-image-collection",
    "href": "F4.html#filtering-and-inspecting-an-image-collection",
    "title": "5  Interpreting Image Series",
    "section": "7.1 Filtering and Inspecting an Image Collection",
    "text": "7.1 Filtering and Inspecting an Image Collection\nWe will focus on the area in and surrounding Lisbon, Portugal. Below, we will define a point, lisbonPoint, located in the city; access the very large Landsat ImageCollection and limit it to the year 2020 and to the images that contain Lisbon; and select bands 6, 5, and 4 from each of the images in the resulting filtered ImageCollection.\n// Define a region of interest as a point in Lisbon, Portugal.\nvar lisbonPoint = ee.Geometry.Point(-9.179473, 38.763948);\n// Center the map at that point.\nMap.centerObject(lisbonPoint, 16);\n// filter the large ImageCollection to be just images from 2020\n// around Lisbon. From each image, select true-color bands to draw\nvar filteredIC = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_TOA’)\n   .filterDate(‘2020-01-01’, ‘2021-01-01’)\n   .filterBounds(lisbonPoint)\n   .select([‘B6’, ‘B5’, ‘B4’]);\n// Add the filtered ImageCollection so that we can inspect values\n// via the Inspector tool\nMap.addLayer(filteredIC, {}, ‘TOA image collection’);\nThe three selected bands (which correspond to SWIR1, NIR, and Red) display a false-color image that accentuates differences between different land covers (e.g., concrete, vegetation) in Lisbon. With the Inspector tab highlighted (Fig. F4.1.1), clicking on a point will bring up the values of bands 6, 5, and 4 from each of the images. If you open the Series option, you’ll see the values through time. For the specified point and for all other points in Lisbon (since they are all enclosed in the same Landsat scene), there are 16 images gathered in 2020. By following one of the graphed lines (in blue, yellow, or red) with your finger, you should be able to count that many distinct values. Moving the mouse along the lines will show the specific values and the image dates.\n\nFig. F4.1.1 Inspect values in an ImageCollection at a selected point by making use of the Inspector tool in the Code Editor\nWe can also show this kind of chart automatically by making use of the ui.Chart function of the Earth Engine API. The following code snippet should result in the same chart as we could observe in the Inspector tab, assuming the same pixel is clicked.\n// Construct a chart using values queried from image collection.\nvar chart = ui.Chart.image.series({\n   imageCollection: filteredIC,\n   region: lisbonPoint,\n   reducer: ee.Reducer.first(),\n   scale: 10\n});\n// Show the chart in the Console.\nprint(chart);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F41a. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n## How Many Images Are There, Everywhere on Earth?\nSuppose we are interested to find out how many valid observations we have at every map pixel on Earth for a given ImageCollection. This enormously computationally demanding task is surprisingly easy to do in Earth Engine. The API provides a set of reducer functions to summarize values to a single number in each pixel, as described in Chap. F4.0. We can apply this reducer, count, to our filtered ImageCollection with the code below. We’ll return to the same data set and filter for 2020, but without the geographic limitation. This will assemble images from all over the world, and then count the number of images in each pixel. The following code does that count, and adds the resulting image to the map with a predefined red/yellow/green color palette stretched between values 0 and 50. Continue pasting the code below into the same script.\n// compute and show the number of observations in an image collection\nvar count = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_TOA’)\n   .filterDate(‘2020-01-01’, ‘2021-01-01’)\n   .select([‘B6’])\n   .count();\n// add white background and switch to HYBRID basemap\nMap.addLayer(ee.Image(1), {\n   palette: [‘white’]\n}, ‘white’, true, 0.5);\nMap.setOptions(‘HYBRID’);\n// show image count\nMap.addLayer(count, {\n   min: 0,\n   max: 50,\n   palette: [‘d7191c’, ‘fdae61’, ‘ffffbf’, ‘a6d96a’,       ‘1a9641’]\n}, ‘landsat 8 image count (2020)’);\n// Center the map at that point.\nMap.centerObject(lisbonPoint, 5);\nRun the command and zoom out. If the count of images over the entire Earth is viewed, the resulting map should look like Fig. F4.1.2. The created map data may take a few minutes to fully load in.\n\nFig. F4.1.2 The number of Landsat 8 images acquired during 2020\nNote the checkered pattern, somewhat reminiscent of a Mondrian painting. To understand why the image looks this way, it is useful to consider the overlapping image footprints. As Landsat passes over, each image is wide enough to produce substantial “sidelap” with the images from the adjacent paths, which are collected at different dates according to the satellite’s orbit schedule. In the north-south direction, there is also some overlap to ensure that there are no gaps in the data. Because these are served as distinct images and stored distinctly in Earth Engine, you will find that there can be two images from the same day with the same value for points in these overlap areas. Depending on the purposes of a study, you might find a way to ignore the duplicate pixel values during the analysis process.\nYou might have noticed that we summarized a single band from the original ImageCollection to ensure that the resulting image would give a single count in each pixel. The count reducer operates on every band passed to it. Since every image has the same number of bands, passing an ImageCollection of all seven Landsat bands to the count reducer would have returned seven identical values of 16 for every point. To limit any confusion from seeing the same number seven times, we selected one of the bands from each image in the collection. In your own work, you might want to use a different reducer, such as a median operation, that would give different, useful answers for each band. A few of these reducers are described below.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F41b. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n## Reducing Image Collections to Understand Band Values\nAs we have seen, you could click at any point on Earth’s surface and see both the number of Landsat images recorded there in 2020 and the values of any image in any band through time. This is impressive and perhaps mind-bending, given the enormous amount of data in play. In this section and the next, we will explore two ways to summarize the numerical values of the bands—one straightforward way and one more complex but highly powerful way to see what information is contained in image collections.\nFirst, we will make a new layer that represents the mean value of each band in every pixel across every image from 2020 for the filtered set, add this layer to the layer set, and explore again with the Inspector. The previous section’s count reducer was called directly using a sort of simple shorthand; that could be done similarly here by calling mean on the assembled bands. In this example, we will use the reducer to get the mean using the more general reduce call. Continue pasting the code below into the same script.\n// Zoom to an informative scale for the code that follows.\nMap.centerObject(lisbonPoint, 10);\n// Add a mean composite image.\nvar meanFilteredIC = filteredIC.reduce(ee.Reducer.mean());\nMap.addLayer(meanFilteredIC, {},   ‘Mean values within image collection’);\nNow, let’s look at the median value for each band among all the values gathered in 2020. Using the code below, calculate the median and explore the image with the Inspector. Compare this image briefly to the mean image by eye and by clicking in a few pixels in the Inspector. They should have different values, but in most places they will look very similar.\n// Add a median composite image.\nvar medianFilteredIC = filteredIC.reduce(ee.Reducer.median());\nMap.addLayer(medianFilteredIC, {},   ‘Median values within image collection’);\nThere is a wide range of reducers available in Earth Engine. If you are curious about which reducers can be used to summarize band values across a collection of images, use the Docs tab in the Code Editor to list all reducers and look for those beginning with ee.Reducer.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F41c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#compute-multiple-percentile-images-for-an-image-collection",
    "href": "F4.html#compute-multiple-percentile-images-for-an-image-collection",
    "title": "5  Interpreting Image Series",
    "section": "7.2 Compute Multiple Percentile Images for an Image Collection",
    "text": "7.2 Compute Multiple Percentile Images for an Image Collection\nOne particularly useful reducer that can help you better understand the variability of values in image collections is ee.Reducer.percentile. The nth percentile gives the value that is the nth largest in a set. In this context, you can imagine accessing all of the values for a given band in a given ImageCollection for a given pixel and sorting them. The 30th percentile, for example, is the value 30% of the way along the list from smallest to largest. This provides an easy way to explore the variability of the values in image collections by computing a cumulative density function of values on a per-pixel basis. The following code shows how we can calculate a single 30th percentile on a per-pixel and per-band basis for our Landsat 8 ImageCollection. Continue pasting the code below into the same script.\n// compute a single 30% percentile\nvar p30 = filteredIC.reduce(ee.Reducer.percentile([30]));\nMap.addLayer(p30, {\n   min: 0.05,\n   max: 0.35}, ‘30%’);\n\nFig. F4.1.3 Landsat 8 TOA reflectance 30th percentile image computed for ImageCollection with images acquired during 2020 \nWe can see that the resulting composite image (Fig. 4.1.3) has almost no cloudy pixels present for this area. This happens because cloudy pixels usually have higher reflectance values. At the lowest end of the values, other unwanted effects like cloud or hill shadows typically have very low reflectance values. This is why this 30th percentile composite image looks so much cleaner than the mean composite image (meanFilteredIC) calculated earlier. Note that the reducers operate per pixel: adjacent pixels are drawn from different images. This means that one pixel’s value could be taken from an image from one date, and the adjacent pixel’s value drawn from an entirely different period. Although, like the mean and median images, percentile images such as that seen in Fig. F4.1.3 never existed on a single day, composite images allow us to view Earth’s surface without the noise that can make analysis difficult.\nWe can explore the range of values in an entire ImageCollection by viewing a series of increasingly bright percentile images, as shown in Fig. F4.1.4. Paste and run the following code.\nvar percentiles = [0, 10, 20, 30, 40, 50, 60, 70, 80];\n// let’s compute percentile images and add them as separate layers\npercentiles.map(function(p) {   var image = filteredIC.reduce(ee.Reducer.percentile([p]));   Map.addLayer(image, {\n       min: 0.05,\n       max: 0.35   }, p + ‘%’);\n});\nNote that the code adds every percentile image as a separate map layer, so you need to go to the Layers control and show/hide different layers to explore differences. Here, we can see that low-percentile composite images depict darker, low-reflectance land features, such as water and cloud or hill shadows, while higher-percentile composite images (>70% in our example) depict clouds and any other atmospheric or land effects corresponding to bright reflectance values.\n\nFig. F4.1.4 Landsat 8 TOA reflectance percentile composite images\nEarth Engine provides a very rich API, allowing users to explore image collections to better understand the extent and variability of data in space, time, and across bands, as well as tools to analyze values stored in image collections in a frequency domain. Exploring these values in different forms should be the first step of any study before developing data analysis algorithms.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F41d. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#synthesis-1",
    "href": "F4.html#synthesis-1",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nIn the example above, the 30th percentile composite image would be useful for typical studies that need cloud-free data for analysis. The “best” composite to use, however, will depend on the goal of a study, the characteristics of the given data set, and the location being viewed. You can imagine choosing different percentile composite values if exploring image collections over the Sahara Desert or over Congo, where cloud frequency would vary substantially (Wilson et al. 2016).\nAssignment 1. Noting that your own interpretation of what constitutes a good composite is subjective, create a series of composites of a different location, or perhaps a pair of locations, for a given set of dates.\nAssignment 2. Filter to create a relevant data set—for example, for Landsat 8 or Sentinel-2 over an agricultural growing season. Create percentile composites for a given location. Which image composite is the most satisfying, and what type of project do you have in mind when giving that response?\nAssignment 3. Do you think it is possible to generalize about the relationship between the time window of an ImageCollection and the percentile value that will be the most useful for a given project, or will every region need to be inspected separately?"
  },
  {
    "objectID": "F4.html#conclusion-1",
    "href": "F4.html#conclusion-1",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you have learned different ways to explore image collections using Earth Engine in addition to looking at individual images. You have learned that image collections in Earth Engine may have global footprints as well as images with a smaller, local footprint, and how to visualize the number of images in a given filtered ImageCollection. You have learned how to explore the temporal and spatial extent of images stored in image collections, and how to quickly examine the variability of values in these image collections by computing simple statistics like mean or median, as well as how to use a percentile reducer to better understand this variability."
  },
  {
    "objectID": "F4.html#references",
    "href": "F4.html#references",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nWilson AM, Jetz W (2016) Remotely sensed high-resolution global cloud dynamics for predicting ecosystem and biodiversity distributions. PLoS Biol 14:e1002415. https://doi.org/10.1371/journal.pbio.1002415"
  },
  {
    "objectID": "F4.html#author-2",
    "href": "F4.html#author-2",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\nUjaval Gandhi"
  },
  {
    "objectID": "F4.html#overview-2",
    "href": "F4.html#overview-2",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\n \nMany remote sensing datasets consist of repeated observations over time. The interval between observations can vary widely. The Global Precipitation Measurement dataset, for example, produces observations of rain and snow worldwide every three hours. The Climate Hazards Group InfraRed Precipitation with Station (CHIRPS) project produces a gridded global dataset at the daily level and also for each five-day period. The Landsat 8 mission produces a new scene of each location on Earth every 16 days. With its constellation of two satellites, the Sentinel-2 mission images every location every five days.\nMany applications, however, require computing aggregations of data at time intervals different from those at which the datasets were produced. For example, for determining rainfall anomalies, it is useful to compare monthly rainfall against a long-period monthly average.\nWhile individual scenes are informative, many days are cloudy, and it is useful to build a robust cloud-free time series for many applications. Producing less cloudy or even cloud-free composites can be done by aggregating data to form monthly, seasonal, or yearly composites built from individual scenes. For example, if you are interested in detecting long-term changes in an urban landscape, creating yearly median composites can enable you to detect change patterns across long time intervals with less worry about day-to-day noise.\nThis chapter will cover the techniques for aggregating individual images from a time  series at a chosen interval. We will take the CHIRPS time series of rainfall for one year and aggregate it to create a monthly rainfall time series."
  },
  {
    "objectID": "F4.html#learning-outcomes-2",
    "href": "F4.html#learning-outcomes-2",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUsing the Earth Engine API to work with dates.\nAggregating values from an ImageCollection to calculate monthly, seasonal, or yearly images.\nPlotting the aggregated time series at a given location."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-2",
    "href": "F4.html#assumes-you-know-how-to-2",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\n​​Create a graph using ui.Chart (Chap. F1.3).\nWrite a function and map it over an ImageCollection (Chap. F4.0).\nSummarize an ImageCollection with reducers (Chap. F4.0, Chap. F4.1).\nInspect an Image and an ImageCollection, as well as their properties (Chap. F4.1)."
  },
  {
    "objectID": "F4.html#introduction-to-theory-1",
    "href": "F4.html#introduction-to-theory-1",
    "title": "5  Interpreting Image Series",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nCHIRPS is a high-resolution global gridded rainfall dataset that combines satellite-measured precipitation with ground station data in a consistent, long time-series dataset. The data are provided by the University of California, Santa Barbara, and are available from 1981 to the present. This dataset is extremely useful in drought monitoring and assessing global environmental change over land. The satellite data are calibrated with ground station observations to create the final product.\nIn this exercise, we will work with the CHIRPS dataset using the pentad. A pentad represents the grouping of five days. There are six pentads in a calendar month, with five pentads of exactly five days each and one pentad with the remaining three to six days of the month. Pentads reset at the beginning of each month, and the first day of every month is the start of a new pentad. Values at a given pixel in the CHIRPS dataset represent the total precipitation in millimeters over the pentad."
  },
  {
    "objectID": "F4.html#filtering-an-image-collection",
    "href": "F4.html#filtering-an-image-collection",
    "title": "5  Interpreting Image Series",
    "section": "8.1 Filtering an Image Collection",
    "text": "8.1 Filtering an Image Collection\nWe will start by accessing the CHIRPS Pentad collection and filtering it to create a time series for a single year.\nvar chirps = ee.ImageCollection(‘UCSB-CHG/CHIRPS/PENTAD’);\nvar startDate = ‘2019-01-01’;\nvar endDate = ‘2020-01-01’;\nvar yearFiltered = chirps.filter(ee.Filter.date(startDate, endDate));\nprint(yearFiltered, ‘Date-filtered CHIRPS images’);\nThe CHIRPS collection contains one image for every pentad. The filtered collection above is filtered to contain one year, which equates to 72 global images. If you expand the printed collection in the Console, you will be able to see the metadata for individual images; note that their date stamps indicate that they are spaced evenly every five days (Fig. F4.2.1).\n\nFig. F4.2.1 CHIRPS time series for one year\nEach image’s pixel values store the total precipitation during the pentad. Without aggregation to a period that matches other datasets, these layers are not very useful. For hydrological analysis, we typically need the total precipitation for each month or for a season. Let’s aggregate this collection so that we have 12 images—one image per month, with pixel values that represent the total precipitation for that month.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F42a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#working-with-dates",
    "href": "F4.html#working-with-dates",
    "title": "5  Interpreting Image Series",
    "section": "8.2 Working with Dates",
    "text": "8.2 Working with Dates\nTo aggregate the time series, we need to learn how to create and manipulate dates programmatically. This section covers some functions from the ee.Date module that will be useful.\nThe Earth Engine API has a function called ee.Date.fromYMD that is designed to create a date object from year, month, and day values. The following code snippet shows how to define a variable containing the year value and create a date object from it. Paste the following code in a new script:\nvar chirps = ee.ImageCollection(‘UCSB-CHG/CHIRPS/PENTAD’);\nvar year = 2019;\nvar startDate = ee.Date.fromYMD(year, 1, 1);\nNow, let’s determine how to create an end date in order to be able to specify a desired time interval. The preferred way to create a date relative to another date is using the advance function. It takes two parameters—a delta value and the unit of time—and returns a new date. The code below shows how to create a date one year in the future from a given date. Paste it into your script.\nvar endDate = startDate.advance(1, ‘year’);\nNext, paste the code below to perform filtering of the CHIRPS data using these calculated dates. After running it, check that you had accurately set the dates by looking for the dates of the images inside the printed result..\nvar yearFiltered = chirps\n   .filter(ee.Filter.date(startDate, endDate));\nprint(yearFiltered, ‘Date-filtered CHIRPS images’);\nAnother date function that is very commonly used across Earth Engine is millis. This function takes a date object and returns the number of milliseconds since the arbitrary reference date of the start of the year 1970: 1970-01-01T00:00:00Z. This is known as the “Unix Timestamp”; it is a standard way to convert dates to numbers and allows for easy comparison between dates with high precision. Earth Engine objects store the timestamps for images and features in special properties called system:time_start and system:time_end. Both of these properties need to be supplied with a number instead of dates, and the millis function can help you do that. You can print the result of calling this function and check for yourself.\nprint(startDate, ‘Start date’);\nprint(endDate, ‘End date’);\nprint(‘Start date as timestamp’, startDate.millis());\nprint(‘End date as timestamp’, endDate.millis());\nWe will use the millis function in the next section when we need to set the system:time_start and system:time_end properties of the aggregated images.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F42b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#aggregating-images",
    "href": "F4.html#aggregating-images",
    "title": "5  Interpreting Image Series",
    "section": "8.3 Aggregating Images",
    "text": "8.3 Aggregating Images\nNow we can start aggregating the pentads into monthly sums. The process of aggregation has two fundamental steps. The first is to determine the beginning and ending dates of one time interval (in this case, one month), and the second is to sum up all of the values (in this case, the pentads) that fall within each interval. To begin, we can envision that the resulting series will contain 12 images. To prepare to create an image for each month, we create an ee.List of values from 1 to 12. We can use the ee.List.sequence function, as first presented in Chap. F1.0, to create the list of items of type ee.Number. Continuing with the script of the previous section, paste the following code:\n// Aggregate this time series to compute monthly images.\n// Create a list of months\nvar months = ee.List.sequence(1, 12);\nNext, we write a function that takes a single month as the input and returns an aggregated image for that month. Given beginningMonth as an input parameter, we first create a start and end date for that month based on the year and month variables. Then we filter the collection to find all images for that month. To create a monthly precipitation image, we apply ee.Reducer.sum to reduce the six pentad images for a month to a single image holding the summed value across the pentads. We also expressly set the timestamp properties system:time_start and system:time_end of the resulting summed image. We can also set year and month, which will help us filter the resulting collection later.\n// Write a function that takes a month number\n// and returns a monthly image.\nvar createMonthlyImage = function(beginningMonth) {   var startDate = ee.Date.fromYMD(year, beginningMonth, 1);   var endDate = startDate.advance(1, ‘month’);   var monthFiltered = yearFiltered\n       .filter(ee.Filter.date(startDate, endDate));   // Calculate total precipitation.   var total = monthFiltered.reduce(ee.Reducer.sum());   return total.set({       ‘system:time_start’: startDate.millis(),       ‘system:time_end’: endDate.millis(),       ‘year’: year,       ‘month’: beginningMonth   });\n};\nWe now have an ee.List containing items of type ee.Number from 1 to 12, with a function that can compute a monthly aggregated image for each month number. All that is left to do is to map the function over the list. As described in Chaps. F4.0 and F4.1, the map function passes over each image in the list and runs createMonthlyImage. The function first receives the number “1” and executes, returning an image to Earth Engine. Then it runs on the number “2”, and so on for all 12 numbers. The result is a list of monthly images for each month of the year.\n// map() the function on the list of months\n// This creates a list with images for each month in the list\nvar monthlyImages = months.map(createMonthlyImage);\nWe can create an ImageCollection from this ee.List of images using the ee.ImageCollection.fromImages function.\n// Create an ee.ImageCollection.\nvar monthlyCollection = ee.ImageCollection.fromImages(monthlyImages);\nprint(monthlyCollection);\nWe have now successfully computed an aggregated collection from the source ImageCollection by filtering, mapping, and reducing, as described in Chaps. F4.0 and F4.1. Expand the printed collection in the Console and you can verify that we now have 12 images in the newly created ImageCollection (Fig. F4.2.2).\n\nFig. F4.2.2 Aggregated time series\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F42c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#plotting-time-series",
    "href": "F4.html#plotting-time-series",
    "title": "5  Interpreting Image Series",
    "section": "8.4 Plotting Time Series",
    "text": "8.4 Plotting Time Series\nOne useful application of gridded precipitation datasets is to analyze rainfall patterns. We can plot a time-series chart for a location using the newly computed time series. We can plot the pixel value at any given point or polygon. Here we create a point geometry for a given coordinate. Continuing with the script of the previous section, paste the following code:\n// Create a point with coordinates for the city of Bengaluru, India.\nvar point = ee.Geometry.Point(77.5946, 12.9716);\nEarth Engine comes with a built-in ui.Chart.image.series function that can plot time series. In addition to the imageCollection and region parameters, we need to supply a scale value. The CHIRPS data catalog page indicates that the resolution of the data is ​​5566 meters, so we can use that as the scale. The resulting chart is printed in the Console.\nvar chart = ui.Chart.image.series({\n   imageCollection: monthlyCollection,\n   region: point,\n   reducer: ee.Reducer.mean(),\n   scale: 5566,\n});\nprint(chart);\nWe can make the chart more informative by adding axis labels and a title. The setOptions function allows us to customize the chart using parameters from Google Charts. To customize the chart, paste the code below at the bottom of your script. The effect will be to see two charts in the editor: one with the old view of the data, and one with the customized chart.\nvar chart = ui.Chart.image.series({\n   imageCollection: monthlyCollection,\n   region: point,\n   reducer: ee.Reducer.mean(),\n   scale: 5566\n}).setOptions({\n   lineWidth: 1,\n   pointSize: 3,\n   title: ‘Monthly Rainfall at Bengaluru’,\n   vAxis: {\n       title: ‘Rainfall (mm)’   },\n   hAxis: {\n       title: ‘Month’,\n       gridlines: {\n           count: 12       }\n   }\n});print(chart);\nThe customized chart (Fig. F4.2.3) shows the typical rainfall pattern in the city of Bengaluru, India. Bengaluru has a temperate climate, with pre-monsoon rains in April and May cooling down the city and a moderate monsoon season lasting from June to September.\n\nFig. F4.2.3 Monthly rainfall chart\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F42d. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#synthesis-2",
    "href": "F4.html#synthesis-2",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. The CHIRPS collection contains data for 40 years. Aggregate the same collection to yearly images and create a chart for annual precipitation from 1981 to 2021 at your chosen location.\nInstead of creating a list of months and writing a function to create monthly images, we will create a list of years and write a function to create yearly images. The code snippet below will help you get started.\nvar chirps = ee.ImageCollection(‘UCSB-CHG/CHIRPS/PENTAD’);\n// Create a list of years\nvar years = ee.List.sequence(1981, 2021);\n// Write a function that takes a year number\n// and returns a yearly image\nvar createYearlyImage = function(beginningYear) {   // Add your code\n};\nvar yearlyImages = years.map(createYearlyImage);\nvar yearlyCollection = ee.ImageCollection.fromImages(yearlyImages);\nprint(yearlyCollection);"
  },
  {
    "objectID": "F4.html#conclusion-2",
    "href": "F4.html#conclusion-2",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned how to aggregate a collection to months and plot the resulting time series for a location. This chapter also introduced useful functions for working with the dates that will be used across many different applications. You also learned how to iterate over a list using the map function. The technique of mapping a function over a list or collection is essential for processing data. Mastering this technique will allow you to scale your analysis using the parallel computing capabilities of Earth Engine."
  },
  {
    "objectID": "F4.html#references-1",
    "href": "F4.html#references-1",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nBanerjee A, Chen R, Meadows ME, et al (2020) An analysis of long-term rainfall trends and variability in the Uttarakhand Himalaya using Google Earth Engine. Remote Sens 12:709. https://doi.org/10.3390/rs12040709\nFunk C, Peterson P, Landsfeld M, et al (2015) The climate hazards infrared precipitation with stations – a new environmental record for monitoring extremes. Sci Data 2:1–21. https://doi.org/10.1038/sdata.2015.66\nOkamoto K, Ushio T, Iguchi T, et al (2005) The global satellite mapping of precipitation (GSMaP) project. In: International Geoscience and Remote Sensing Symposium (IGARSS). pp 3414–3416"
  },
  {
    "objectID": "F4.html#author-3",
    "href": "F4.html#author-3",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\n:\nTxomin Hermosilla, Saverio Francini, Andréa P. Nicolau, Michael A. Wulder, Joanne C. White, Nicholas C. Coops, Gherardo Chirici"
  },
  {
    "objectID": "F4.html#overview-3",
    "href": "F4.html#overview-3",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\nThe purpose of this chapter is to provide necessary context and demonstrate different approaches for image composite generation when using data quality flags, using an initial example of removing cloud cover. We will examine different filtering options, demonstrate an approach for cloud masking, and provide additional opportunities for image composite development. Pixel selection for composite development can exclude unwanted pixels—such as those impacted by cloud, shadow, and smoke or haze—and can also preferentially select pixels based upon proximity to a target date or a preferred sensor type."
  },
  {
    "objectID": "F4.html#learning-outcomes-3",
    "href": "F4.html#learning-outcomes-3",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUnderstanding and applying satellite-specific cloud mask functions.\nIncorporating images from different sensors.\nUsing focal functions to fill in data gaps."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-3",
    "href": "F4.html#assumes-you-know-how-to-3",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nPerform basic image analysis: select bands, compute indices, create masks (Part F2).\nUse band scaling factors (Chap. F3.1).\nPerform pixel-based transformations (Chap. F3.1).\nUse neighborhood-based image transformations (Chap. F3.2).\nWrite a function and map it over an ImageCollection (Chap. F4.0).\nSummarize an ImageCollection with reducers (Chap. F4.0, Chap. F4.1)."
  },
  {
    "objectID": "F4.html#introduction-to-theory-2",
    "href": "F4.html#introduction-to-theory-2",
    "title": "5  Interpreting Image Series",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nIn many respects, satellite remote sensing is an ideal source of data for monitoring large or remote regions. However, cloud cover is one of the most common limitations of optical sensors in providing continuous time series of data for surface mapping and monitoring. This is particularly relevant in tropical, polar, mountainous, and high-latitude areas, where clouds are often present. Many studies have addressed the extent to which cloudiness can restrict the monitoring of various regions (Zhu and Woodcock 2012, 2014; Eberhardt et al. 2016; Martins et al. 2018).\nClouds and cloud shadows reduce the view of optical sensors and completely block or obscure the spectral response from Earth’s surface (Cao et al. 2020). Working with pixels that are cloud-contaminated can significantly influence the accuracy and information content of products derived from a variety of remote sensing activities, including land cover classification, vegetation modeling, and especially change detection, where unscreened clouds might be mapped as false changes (Braaten et al. 2015, Zhu et al. 2015). Thus, the information provided by cloud detection algorithms is critical to exclude clouds and cloud shadows from subsequent processing steps.\nHistorically, cloud detection algorithms derived the cloud information by considering a single date-image and sun illumination geometry (Irish et al. 2006, Huang et al. 2010). In contrast, current, more accurate cloud detection algorithms are based on the analysis of Landsat time series (Zhu and Woodcock 2014, Zhu and Helmer 2018). Cloud detection algorithms inform on the presence of clouds, cloud shadows, and other atmospheric conditions (e.g., presence of snow). The presence and extent of cloud contamination within a pixel is currently provided with Landsat and Sentinel-2 imagery as ancillary data via quality flags at the pixel level. Additionally, quality flags also inform on other acquisition-related conditions, including radiometric saturation and terrain occlusion, which enables us to assess the usefulness and convenience of inclusion of each pixel in subsequent analyses. The quality flags are ideally suited to reduce users’ manual supervision and maximize the automatic processing approaches.\nMost automated algorithms (for classification or change detection, for example) work best on images free of clouds and cloud shadows, that cover the full area without spatial or spectral inconsistencies. Thus, the image representation over the study area should be seamless, containing as few data gaps as possible. Image compositing techniques are primarily used to reduce the impact of clouds and cloud shadows, as well as aerosol contamination, view angle effects, and data volumes (White et al. 2014). Compositing approaches typically rely on the outputs of cloud detection algorithms and quality flags to include or exclude pixels from the resulting composite products (Roy et al. 2010). Epochal image composites help overcome the limited availability of cloud-free imagery in some areas, and are constructed by considering the pixels from all images acquired in a given period (e.g., season, year).\nThe information provided by the cloud masks and pixel flags guides the establishment of rules to rank the quality of the pixels based on the presence of and distance to clouds, cloud shadows, or atmospheric haze (Griffiths et al. 2010). Higher scores are assigned to pixels with more desirable conditions, based on the presence of clouds and also other acquisition circumstances, such as acquisition date or sensor. Those pixels with the highest scores are included in the subsequent composite development. Image compositing approaches enable users to define the rules that are most appropriate for their particular information needs and study area to generate imagery covering large areas instead of being limited to the analysis of single scenes (Hermosilla et al. 2015, Loveland and Dwyer 2012). Moreover, generating image composites at regular intervals (e.g., annually) allows for the analysis of long temporal series over large areas, fulfilling a critical information need for monitoring programs.\nThe general workflow to generate a cloud-free composite involves:\n\nDefining your area of interest (AOI).\nFiltering (ee.Filter) the satellite ImageCollection to desired parameters.\nApplying a cloud mask.\nReducing (ee.Reducer) the collection to generate a composite.\nUsing the GEE-BAP application to generate annual best-available-pixel image composites by globally combining multiple Landsat sensors and images.\n\nAdditional steps may be necessary to improve the composite generated. These steps will be explained in the following sections.\n## Cloud Filter and Cloud Mask\nThe first step is to define your AOI and center the map. The goal is to create a nationwide composite for the country of Colombia. We will use the Large Scale International Boundary (2017) simplified dataset from the US Department of State (USDOS), which contains polygons for all countries of the world.\n// ———- Section 1 —————–\n// Define the AOI.\nvar country = ee.FeatureCollection(‘USDOS/LSIB_SIMPLE/2017’)\n   .filter(ee.Filter.equals(‘country_na’, ‘Colombia’));\n// Center the Map. The second parameter is zoom level.\nMap.centerObject(country, 5);\nWe will start creating a composite from the Landsat 8 collection. First, we define two time variables: startDate and endDate. Here, we will create a composite for the year 2019. Then, we will define a collection for the Landsat 8 Level 2, Collection 2, Tier 1 variable and filter it to our AOI and time period. We define and use a function to apply scaling factors to the Landsat 8 Collection 2 data.\n// Define time variables.\nvar startDate = ‘2019-01-01’;\nvar endDate = ‘2019-12-31’;\n// Load and filter the Landsat 8 collection.\nvar landsat8 = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterBounds(country)\n   .filterDate(startDate, endDate);\n// Apply scaling factors.\nfunction applyScaleFactors(image) {   var opticalBands = image.select(‘SR_B.’).multiply(0.0000275).add(-       0.2);   var thermalBands = image.select(’ST_B.*’).multiply(0.00341802)\n       .add(149.0);   return image.addBands(opticalBands, null, true)\n       .addBands(thermalBands, null, true);\n}\nlandsat8 = landsat8.map(applyScaleFactors);\nNow, we can create a composite. We will use the median function, which has the same effect as writing reduce(ee.Reducer.median()) as seen in Chap. F4.0, to reduce our ImageCollection to a median composite. Add the resulting composite to the map using visualization parameters.\n// Create composite.\nvar composite = landsat8.median().clip(country);\nvar visParams = {\n   bands: [‘SR_B4’, ‘SR_B3’, ‘SR_B2’],\n   min: 0,\n   max: 0.2\n};\nMap.addLayer(composite, visParams, ‘L8 Composite’);\n\nFig. F4.3.1 Landsat 8 surface reflectance 2019 median composite of Colombia\nThe resulting composite (Fig. F4.3.1) has lots of clouds, especially in the western, mountainous regions of Colombia. In tropical regions, it is very challenging to generate a high-quality, cloud-free composite without first filtering images for cloud cover, even if our collection is constrained to only include images acquired during the dry season. Therefore, let’s filter our collection by the CLOUD_COVER parameter to avoid cloudy images. We will start with images that have less than 50% cloud cover.\n// Filter by the CLOUD_COVER property.\nvar landsat8FiltClouds = landsat8\n   .filterBounds(country)\n   .filterDate(startDate, endDate)\n   .filter(ee.Filter.lessThan(‘CLOUD_COVER’, 50));\n// Create a composite from the filtered imagery.\nvar compositeFiltClouds = landsat8FiltClouds.median().clip(country);\nMap.addLayer(compositeFiltClouds, visParams,   ‘L8 Composite cloud filter’);\n// Print size of collections, for comparison.\nprint(‘Size landsat8 collection’, landsat8.size());\nprint(‘Size landsat8FiltClouds collection’, landsat8FiltClouds.size());\n\nFig. F4.3.2 Landsat 8 surface reflectance 2019 median composite of Colombia filtered by cloud cover less than 50%\nThis new composite (Fig. F4.3.2) looks slightly better than the previous one, but still very cloudy. Remember to turn off the first layer or adjust the transparency to visualize only this new composite. The code prints the size of these collections, using the size function) to see how many images were left out after we applied the cloud cover threshold. (There are 1201 images in the landsat8 collection, compared to 493 in the landsat8FiltClouds collection—a lot of scenes with cloud cover greater than or equal to 50%.)\nTry adjusting the CLOUD_COVER threshold in the landsat8FiltClouds variable to different percentages and checking the results. For example, with 20% set as the threshold (Fig. F4.3.3), you can see that many parts of the country have image gaps. (Remember to turn off the first layer or adjust its transparency; you can also set the shown parameter in the Map.addLayer function to false so the layer does not automatically load). So there is a trade-off between a stricter cloud cover threshold and data availability. Additionally, even with a cloud filter, some tiles still present a large area cover of clouds.\n\nFig. F4.3.3 Landsat 8 surface reflectance 2019 median composite of Colombia filtered by cloud cover less than 20%\nThis is due to persistent cloud cover in some regions of Colombia. However, a cloud mask can be applied to improve the results. The Landsat 8 Collection 2 contains a quality assessment (QA) band called QA_PIXEL that provides useful information on certain conditions within the data, and allows users to apply per-pixel filters. Each pixel in the QA band contains unsigned integers that represent bit-packed combinations of surface, atmospheric, and sensor conditions.\nWe will also make use of the QA_RADSAT band, which indicates which bands are radiometrically saturated. A pixel value of 1 means saturated, so we will be masking these pixels.\nAs described in Chap. F4.0, we will create a function to apply a cloud mask to an image, and then map this function over our collection. The mask is applied by using the updateMask function. This function “eliminates” undesired pixels from the analysis, i.e., makes them transparent, by taking the mask as the input. You will see that this cloud mask function (or similar versions) is used in other chapters of the book. Note: Remember to set the cloud cover threshold back to 50 in the landsat8FiltClouds variable.\n// Define the cloud mask function.\nfunction maskSrClouds(image) {   // Bit 0 - Fill   // Bit 1 - Dilated Cloud   // Bit 2 - Cirrus   // Bit 3 - Cloud   // Bit 4 - Cloud Shadow   var qaMask = image.select(‘QA_PIXEL’).bitwiseAnd(parseInt(‘11111’,       2)).eq(0);   var saturationMask = image.select(‘QA_RADSAT’).eq(0);   return image.updateMask(qaMask)\n       .updateMask(saturationMask);\n}\n// Apply the cloud mask to the collection.\nvar landsat8FiltMasked = landsat8FiltClouds.map(maskSrClouds);\n// Create a composite.\nvar landsat8compositeMasked = landsat8FiltMasked.median().clip(country);\nMap.addLayer(landsat8compositeMasked, visParams, ‘L8 composite masked’);\n\nFig. F4.3.4 Landsat 8 surface reflectance 2019 median composite of Colombia filtered by cloud cover less than 50% and with cloud mask applied\nBecause we are dealing with bits, in the maskSrClouds function we utilized the bitwiseAnd and parseInt functions. These are functions that serve the purpose of unpacking the bit information. A bitwise AND is a binary operation that takes two equal-length binary representations and performs the logical AND operation on each pair of corresponding bits. Thus, if both bits in the compared positions have the value 1, the bit in the resulting binary representation is 1 (1 × 1 = 1); otherwise, the result is 0 (1 × 0 = 0 and 0 × 0 = 0). The parseInt function parses a string argument (in our case, five-character string ‘11111’) and returns an integer of the specified numbering system, base 2.\nThe resulting composite (Fig. F4.3.4) shows masked clouds, and is more spatially exhaustive in coverage compared to previous composites (don’t forget to uncheck the previous layers). This is because, when compositing all the images into one, we are not taking cloudy pixels into account anymore; therefore, the resulting pixel is not cloud covered but an actual representation of the landscape. However, data gaps are still an issue due to cloud cover. If you do not specifically need an annual composite, a first approach is to create a two-year composite to try to mitigate the missing data issue, or to have a series of rules that allows for selecting pixels for that particular year (as in Sect. 3 below). Change the startDate variable to 2018-01-01 to include all images from 2018 and 2019 in the collection. How does the cloud-masked composite (Fig. F4.3.5) compare to the 2019 one?\n\nFig. F4.3.5 One-year, startDate variable set to 2019-01-01, (left) and two-year, startDate variable set to 2018-01-01, (right) median composites with 50% cloud cover threshold and cloud mask applied\nThe resulting image has substantially fewer data gaps (you can zoom in to better see them). Again, if the time period is not a constraint for the creation of your composite, you can incorporate more images from a third year, and so on.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F43a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#incorporating-data-from-other-satellites",
    "href": "F4.html#incorporating-data-from-other-satellites",
    "title": "5  Interpreting Image Series",
    "section": "9.1 Incorporating Data from Other Satellites",
    "text": "9.1 Incorporating Data from Other Satellites\nAnother option to reduce the presence of data gaps in cloudy situations is to bring in imagery from other sensors acquired during the time period of interest. The Landsat collection spans multiple missions, which have continuously acquired uninterrupted data since 1972 at different acquisition dates. Next, we will try incorporating Landsat 7 Level 2, Collection 2, Tier 1 images from 2019 to fill the gaps in the 2019 Landsat 8 composite.\nTo generate a Landsat 7 composite, we apply similar steps to the ones we did for Landsat 8, so keep adding code to the same script from Sect. 1. First, define your Landsat 7 collection variable and the scaling function. Then, filter the collection, apply the cloud mask (since we know Colombia has persistent cloud cover), and apply the scaling function. Note that we will use the same cloud mask function defined above, since the bits information for Landsat 7 is the same as for Landsat 8. Finally, create the median composite. After pasting in the code below but before executing it, change the startDate variable back to 2019-01-01 in order to create a one-year composite of 2019.\n// ———- Section 2 —————–\n// Define Landsat 7 Level 2, Collection 2, Tier 1 collection.\nvar landsat7 = ee.ImageCollection(‘LANDSAT/LE07/C02/T1_L2’);\n// Scaling factors for L7.\nfunction applyScaleFactorsL7(image) {   var opticalBands = image.select(‘SR_B.’).multiply(0.0000275).add(-       0.2);   var thermalBand = image.select(‘ST_B6’).multiply(0.00341802).add(       149.0);   return image.addBands(opticalBands, null, true)\n       .addBands(thermalBand, null, true);\n}\n// Filter collection, apply cloud mask, and scaling factors.\nvar landsat7FiltMasked = landsat7\n   .filterBounds(country)\n   .filterDate(startDate, endDate)\n   .filter(ee.Filter.lessThan(‘CLOUD_COVER’, 50))\n   .map(maskSrClouds)\n   .map(applyScaleFactorsL7);\n// Create composite.\nvar landsat7compositeMasked = landsat7FiltMasked\n   .median()\n   .clip(country);\nMap.addLayer(landsat7compositeMasked,\n   {\n       bands: [‘SR_B3’, ‘SR_B2’, ‘SR_B1’],\n       min: 0,\n       max: 0.2   },   ‘L7 composite masked’);\n\nFig. F4.3.6 One-year Landsat 7 median composite with 50% cloud cover threshold and cloud mask applied\nNote that we used bands: [‘SR_B3’, ‘SR_B2’, ‘SR_B1’] to visualize the composite because Landsat 7 has different band designations. The sensors aboard each of the Landsat satellites were designed to acquire data in different ranges of frequencies along the electromagnetic spectrum. Whereas for Landsat 8, the red, green, and blue bands are B4, B3, and B2, respectively, for Landsat 7, these same bands are B3, B2, and B1, respectively.\nYou should see an image with systematic gaps like the one shown in Fig. F4.3.6 (remember to turn off the other layers, and zoom in to better see the data gaps). Landsat 7 was launched in 1999, but since 2003, the sensor has acquired and delivered data with data gaps caused by a scan line corrector (SLC) failure. Without an operating SLC, the sensor’s line of sight traces a zig-zag pattern along the satellite ground track, and, as a result, the imaged area is duplicated and some areas are missed. When the Level 1 data are processed, the duplicated areas are removed, leaving data gaps (Fig. F4.3.7). For more information about Landsat 7 and SLC error, please refer to the USGS Landsat 7 page. However, even with the SLC error, we can still use the Landsat 7 data in our composite. Now, let’s combine the Landsat 7 and 8 collections.\n\nFig. F4.3.7 Landsat 7’s SLC-off condition. Source: USGS\nSince Landsat 7 and 8 have different band designations, first we create a function to rename the bands from Landsat 7 to match the names used for Landsat 8 and map that function over our Landsat 7 collection.\n// Since Landsat 7 and 8 have different band designations,\n// let’s create a function to rename L7 bands to match to L8.\nfunction rename(image) {   return image.select(\n       [‘SR_B1’, ‘SR_B2’, ‘SR_B3’, ‘SR_B4’, ‘SR_B5’, ‘SR_B7’],\n       [‘SR_B2’, ‘SR_B3’, ‘SR_B4’, ‘SR_B5’, ‘SR_B6’, ‘SR_B7’]);\n}\n// Apply the rename function.\nvar landsat7FiltMaskedRenamed = landsat7FiltMasked.map(rename);\nIf you print the first images of both the landsat7FiltMasked and landsat7FiltMaskedRenamed collections (Fig. F4.3.8), you will see that the bands got renamed, and not all bands got copied over (SR_ATMOS_OPACITY, SR_CLOUD_QA, SR_B6, etc.). To copy these additional bands, simply add them to the rename function. You will need to rename SR_B6 so it does not have the same name as the new band 5.\n\nFig. F4.3.8 First images of landsat7FiltMasked and landsat7FiltMaskedRenamed, respectively\nNow we merge the two collections using the merge function for ImageCollection and mapping over a function to cast the Landsat 7 input values to a 32-bit float using the toFloat function for consistency. To merge collections, the number and names of the bands must be the same in each collection. We use the select function (Chap. F1.1) to select the Landsat 8 bands to be the same as Landsat 7’s. When creating the new Landsat 7 and 8 composite, if we did not select these 6 bands, we would get an error message for trying to composite a collection that has 6 bands (Landsat 7) with a collection that has 19 bands (Landsat 8).\n// Merge Landsat collections.\nvar landsat78 = landsat7FiltMaskedRenamed\n   .merge(landsat8FiltMasked.select(\n       [‘SR_B2’, ‘SR_B3’, ‘SR_B4’, ‘SR_B5’, ‘SR_B6’, ‘SR_B7’]))\n   .map(function(img) {       return img.toFloat();\n   });\nprint(‘Merged collections’, landsat78);\nNow we have a collection with about 1000 images. Next, we will take the median of the values across the ImageCollection. \n// Create Landsat 7 and 8 image composite and add to the Map.\nvar landsat78composite = landsat78.median().clip(country);\nMap.addLayer(landsat78composite, visParams, ‘L7 and L8 composite’);\nComparing the composite generated considering both Landsat 7 and 8 to the Landsat 8-only composite, it is evident that there is a reduction in the amount of data gaps in the final result (Fig. F4.3.9). The resulting Landsat 7 and 8 image composite still has data gaps due to the presence of clouds and Landsat 7’s SLC-off data. You can try setting the center of the map to the point with latitude 3.6023 and longitude −75.0741 to see the inset example of Fig. F4.3.9.\n\nFig. F4.3.9 Landsat 8-only composite (left) and Landsat 7 and 8 composite (right) for 2019. Inset centered at latitude 3.6023, longitude −75.0741.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F43b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#best-available-pixel-compositing-earth-engine-application",
    "href": "F4.html#best-available-pixel-compositing-earth-engine-application",
    "title": "5  Interpreting Image Series",
    "section": "9.2 Best-Available-Pixel Compositing Earth Engine Application",
    "text": "9.2 Best-Available-Pixel Compositing Earth Engine Application\nThis section presents an Earth Engine application that enables the generation of annual best-available-pixel (BAP) image composites by globally combining multiple Landsat sensors and images: GEE-BAP. Annual BAP image composites are generated by choosing optimal observations for each pixel from all available Landsat 5 TM, Landsat 7 ETM+, and Landsat 8 OLI imagery within a given year and within a given day range from a specified acquisition day of year, in addition to other constraints defined by the user. The data accessible via Earth Engine are from the USGS free and open archive of Landsat data. The Landsat images used are atmospherically corrected to surface reflectance values. Following White et al. (2014), a series of scoring functions ranks each pixel observation for (1) acquisition day of year, (2) cloud cover in the scene, (3) distance to clouds and cloud shadows, (4) presence of haze, and (5) acquisition sensor. Further information on the BAP image compositing approach can be found in Griffiths et al. (2013), and detailed information on tuning parameters can be found in White et al. (2014).\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F43c. The book’s repository contains information about accessing the GEE-BAP interface and its related functions.\n\n\n\nFig. F4.3.10 GEE-BAP user interface controls\nOnce you have loaded the GEE-BAP interface (Fig. F4.3.10) using the instructions in the Code Checkpoint, you will notice that it is divided into three sections: (1) Input/Output options, (2) Pixel scoring options, and (3) Advanced parameters. Users indicate the study area, the time period for generating annual BAP composites (i.e., start and end years), and the path to store the results in the Input/Output options. Users have three options to define the study area. The Draw study area option uses the Draw a shape and Draw a rectangle tools to define the area of interest. The Upload image template option utilizes an image template uploaded by the user in TIFF format. This option is well suited to generating BAP composites that match the projection, pixel size, and extent to existing raster datasets. The Work globally option generates BAP composites for the entire globe; note that when this option is selected, complete data download is not available due to the Earth’s size. With Start year and End year, users can indicate the beginning and end of the annual time series of BAP image composites to be generated. Multiple image composites are then generated—one composite for each year—resulting in a time series of annual composites. For each year, composites are uniquely generated utilizing images acquired on the days within the specified Date range. Produced BAP composites can be saved in the indicated (Path) Google Drive folder using the Tasks tab. Results are generated in a tiled, TIFF format, accompanied by a CSV file that indicates the parameters used to construct the composite.\nAs noted, GEE-BAP implements five pixel scoring functions: (1) target acquisition day of year and day range, (2) maximum cloud coverage per scene, (3) distance to clouds and cloud shadows, (4) atmospheric opacity, and (5) a penalty for images acquired under the Landsat 7 ETM+ SLC-off malfunction. By defining the Acquisition day of year and Day range, those candidate pixels acquired closer to a defined acquisition day of year are ranked higher. Note that pixels acquired outside the day range window are excluded from subsequent composite development. For example, if the target day of year is defined as “08-01” and the day range as “31,” only those pixels acquired between July 1 and August 31 are considered, and the ones acquired closer to August 1 will receive a higher score.\nThe scoring function Max cloud cover in scene indicates the maximum percentage of cloud cover in an image that will be accepted by the user in the BAP image compositing process. Defining a value of 70% implies that only those scenes with less than or equal to 70% cloud cover will be considered as a candidate for compositing.\nThe Distance to clouds and cloud shadows scoring function enables the user to exclude those pixels identified to contain clouds and shadows by the QA mask from the generated BAP, as well as decreasing a pixel’s score if the pixel is within a specified proximity of a cloud or cloud shadow.\nThe Atmospheric opacity scoring function ranks pixels based on their atmospheric opacity values, which are indicative of hazy imagery. Pixels with opacity values that exceed a defined haze expectation (Max opacity) are excluded. Pixels with opacity values lower than a defined value (Min opacity) get the maximum score. Pixels with values in between these limits are scored following the functions defined by Griffiths et al. (2013). This scoring function is available only for Landsat 5 TM and Landsat 7 ETM+ imagery, which provides the opacity attribute in the image metadata file.\nFinally, there is a Landsat 7 ETM+ SLC-off penalty scoring function that de-emphasizes images acquired following the ETM+ SLC-off malfunction in 2003. The aim of this scoring element is to ensure that TM or OLI data, which do not have stripes, take precedence over ETM+ when using dates after the SLC failure. This allows users to avoid the inclusion of multiple discontinuous small portions of images being used to produce the BAP image composites, thus reducing the spatial variability of the spectral data. The penalty applied to SLC-off imagery is defined directly proportional to the overall score. A large score reduces the chance that SLC-off imagery will be used in the composite. A value of 1 prevents SLC-off imagery from being used.\nBy default, the GEE-BAP application produces image composites using all the visible bands. The Spectral index option enables the user to produce selected spectral indices from the resulting BAP image composites. Available spectral indices include: Normalized Difference Vegetation Index (NDVI, Fig. F4.3.11), Enhanced Vegetation Index (EVI), and Normalized Burn Ratio (NBR), as well as several indices derived from the Tasseled Cap transformation: Wetness (TCW), Greenness (TCG), Brightness (TCB), and Angle (TCA). Composited indices are able to be downloaded as well as viewed on the map.\n\nFig. F4.3.11 Example of a global BAP image composite showing NDVI values generated using the GEE-BAP user interface\nGEE-BAP functions can be accessed programmatically, including pixel scoring parameters, as well as BAP image compositing (BAP), de-spiking (despikeCollection), data-gap infilling (infill), and displaying (ShowCollection) functions. The following code sets the scoring parameter values, then generates and displays the compositing results (Fig. F4.3.12) for a BAP composite that is de-spiked, with data gaps infilled using temporal interpolation. Copy and paste the code below into a new script.\n// Define required parameters.\nvar targetDay = ‘06-01’;\nvar daysRange = 75;\nvar cloudsTh = 70;\nvar SLCoffPenalty = 0.7;\nvar opacityScoreMin = 0.2;\nvar opacityScoreMax = 0.3;\nvar cloudDistMax = 1500;\nvar despikeTh = 0.65;\nvar despikeNbands = 3;\nvar startYear = 2015;\nvar endYear = 2017;\n// Define study area.\nvar worldCountries = ee.FeatureCollection(‘USDOS/LSIB_SIMPLE/2017’);\nvar colombia = worldCountries.filter(ee.Filter.eq(‘country_na’,   ‘Colombia’));\n// Load the bap library.\nvar library = require(‘users/sfrancini/bap:library’);\n// Calculate BAP.\nvar BAPCS = library.BAP(null, targetDay, daysRange, cloudsTh,\n   SLCoffPenalty, opacityScoreMin, opacityScoreMax, cloudDistMax);\n// Despike the collection.\nBAPCS = library.despikeCollection(despikeTh, despikeNbands, BAPCS,   1984, 2021, true);\n// Infill datagaps.\nBAPCS = library.infill(BAPCS, 1984, 2021, false, true);\n// Visualize the image.\nMap.centerObject(colombia, 5);\nlibrary.ShowCollection(BAPCS, startYear, endYear, colombia, false,   null);\nlibrary.AddSLider(startYear, endYear);\n\nFig. F4.3.12 Outcome of the compositing code\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F43d. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#synthesis-3",
    "href": "F4.html#synthesis-3",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. Create composites for other cloudy regions or less cloudy regions. For example, change the country variable to ‘Cambodia’ or ‘Mozambique’. Are more gaps present in the resulting composite? Can you change the compositing rules to improve this (using Acquisition day of year and Day range)? Different regions of the Earth have different cloud seasonal patterns, so the most appropriate date windows to acquire cloud-free composites will change depending on location. Also be aware that the larger the country, the longer it will take to generate the composite.\nAssignment 2. Similarly, try creating composites for the wet and dry seasons of a region separately. Compare the two composites. Are some features brighter or darker? Is there evidence of drying of vegetation, such as related to leaf loss or reduction in herbaceous ground vegetation?\nAssignment 3. Test different cloud threshold values and see if you can find an optimal threshold that balances data gaps against area coverage for your particular target date."
  },
  {
    "objectID": "F4.html#conclusion-3",
    "href": "F4.html#conclusion-3",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nWe cannot monitor what we cannot see. Image compositing algorithms provide robust and transparent tools to address issues with clouds, cloud shadows, haze, and smoke in remotely sensed images derived from optical satellite data, and expand data availability for remote sensing applications. The tools and approaches described here should provide you with some useful strategies to aid in mitigating the presence of cloud cover in your data. Note that the quality of image outcomes is a function of the quality of cloud masking routines applied to the source data to generate the various flags that are used in the scoring functions described herein. Different compositing parameters can be used to represent a given location as a function of conditions that are present at a given point in time and the information needs of the end user. Tuning or optimization of compositing parameters is possible (and recommended) to ensure best capture of the physical conditions of interest."
  },
  {
    "objectID": "F4.html#references-2",
    "href": "F4.html#references-2",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nBraaten JD, Cohen WB, Yang Z (2015) Automated cloud and cloud shadow identification in Landsat MSS imagery for temperate ecosystems. Remote Sens Environ 169:128–138. https://doi.org/10.1016/j.rse.2015.08.006\nCao R, Chen Y, Chen J, et al (2020) Thick cloud removal in Landsat images based on autoregression of Landsat time-series data. Remote Sens Environ 249:112001. https://doi.org/10.1016/j.rse.2020.112001\nEberhardt IDR, Schultz B, Rizzi R, et al (2016) Cloud cover assessment for operational crop monitoring systems in tropical areas. Remote Sens 8:219. https://doi.org/10.3390/rs8030219\nGriffiths P, van der Linden S, Kuemmerle T, Hostert P (2013) A pixel-based Landsat compositing algorithm for large area land cover mapping. IEEE J Sel Top Appl Earth Obs Remote Sens 6:2088–2101. https://doi.org/10.1109/JSTARS.2012.2228167\nHermosilla T, Wulder MA, White JC, Coops NC (2019) Prevalence of multiple forest disturbances and impact on vegetation regrowth from interannual Landsat time series (1985–2015). Remote Sens Environ 233:111403. ​​https://doi.org/10.1016/j.rse.2019.111403\nHermosilla T, Wulder MA, White JC, et al (2015) An integrated Landsat time series protocol for change detection and generation of annual gap-free surface reflectance composites. Remote Sens Environ 158:220–234. https://doi.org/10.1016/j.rse.2014.11.005\nHermosilla T, Wulder MA, White JC, et al (2016) Mass data processing of time series Landsat imagery: Pixels to data products for forest monitoring. Int J Digit Earth 9:1035–1054. https://doi.org/10.1080/17538947.2016.1187673\nHuang C, Thomas N, Goward SN, et al (2010) Automated masking of cloud and cloud shadow for forest change analysis using Landsat images. Int J Remote Sens 31:5449–5464. https://doi.org/10.1080/01431160903369642\nIrish RR, Barker JL, Goward SN, Arvidson T (2006) Characterization of the Landsat-7 ETM+ automated cloud-cover assessment (ACCA) algorithm. Photogramm Eng Remote Sensing 72:1179–1188. https://doi.org/10.14358/PERS.72.10.1179\nKennedy RE, Yang Z, Cohen WB (2010) Detecting trends in forest disturbance and recovery using yearly Landsat time series: 1. LandTrendr - Temporal segmentation algorithms. Remote Sens Environ 114:2897–2910. https://doi.org/10.1016/j.rse.2010.07.008\nLoveland TR, Dwyer JL (2012) Landsat: Building a strong future. Remote Sens Environ 122:22–29. https://doi.org/10.1016/j.rse.2011.09.022\nMarshall GJ, Rees WG, Dowdeswell JA (1993) Limitations imposed by cloud cover on multitemporal visible band satellite data sets from polar regions. Ann Glaciol 17:113–120. https://doi.org/10.3189/S0260305500012696\nMarshall GJ, Dowdeswell JA, Rees WG (1994) The spatial and temporal effect of cloud cover on the acquisition of high quality landsat imagery in the European Arctic sector. Remote Sens Environ 50:149–160. https://doi.org/10.1016/0034-4257(94)90041-8\nMartins VS, Novo EMLM, Lyapustin A, et al (2018) Seasonal and interannual assessment of cloud cover and atmospheric constituents across the Amazon (2000–2015): Insights for remote sensing and climate analysis. ISPRS J Photogramm Remote Sens 145:309–327. https://doi.org/10.1016/j.isprsjprs.2018.05.013\nRoberts D, Mueller N, McIntyre A (2017) High-dimensional pixel composites from Earth observation time series. IEEE Trans Geosci Remote Sens 55:6254–6264. https://doi.org/10.1109/TGRS.2017.2723896\nRoy DP, Ju J, Kline K, et al (2010) Web-enabled Landsat data (WELD): Landsat ETM+ composited mosaics of the conterminous United States. Remote Sens Environ 114:35–49. https://doi.org/10.1016/j.rse.2009.08.011\nSano EE, Ferreira LG, Asner GP, Steinke ET (2007) Spatial and temporal probabilities of obtaining cloud-free Landsat images over the Brazilian tropical savanna. Int J Remote Sens 28:2739–2752. https://doi.org/10.1080/01431160600981517\nWhite JC, Wulder MA, Hobart GW, et al (2014) Pixel-based image compositing for large-area dense time series applications and science. Can J Remote Sens 40:192–212. https://doi.org/10.1080/07038992.2014.945827\nZhu X, Helmer EH (2018) An automatic method for screening clouds and cloud shadows in optical satellite image time series in cloudy regions. Remote Sens Environ 214:135–153. https://doi.org/10.1016/j.rse.2018.05.024\nZhu Z, Wang S, Woodcock CE (2015) Improvement and expansion of the Fmask algorithm: Cloud, cloud shadow, and snow detection for Landsats 4–7, 8, and Sentinel 2 images. Remote Sens Environ 159:269–277. https://doi.org/10.1016/j.rse.2014.12.014\nZhu Z, Woodcock CE (2014) Automated cloud, cloud shadow, and snow detection in multitemporal Landsat data: An algorithm designed specifically for monitoring land cover change. Remote Sens Environ 152:217–234. https://doi.org/10.1016/j.rse.2014.06.012\nZhu Z, Woodcock CE (2012) Object-based cloud and cloud shadow detection in Landsat imagery. Remote Sens Environ 118:83–94. https://doi.org/10.1016/j.rse.2011.10.028"
  },
  {
    "objectID": "F4.html#author-4",
    "href": "F4.html#author-4",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\nKaris Tenneson, John Dilger, Crystal Wespestad, Brian Zutta, Andréa P Nicolau, Karen Dyson, Paula Paz"
  },
  {
    "objectID": "F4.html#overview-4",
    "href": "F4.html#overview-4",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\nThis chapter introduces change detection mapping. It will teach you how to make a two-date land cover change map using image differencing and threshold-based classification. You will use what you have learned so far in this book to produce a map highlighting changes in the land cover between two time steps. You will first explore differences between the two images extracted from these time steps by creating a difference layer. You will then learn how to directly classify change based on the information in both of your images."
  },
  {
    "objectID": "F4.html#learning-outcomes-4",
    "href": "F4.html#learning-outcomes-4",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nCreating and exploring how to read a false-color cloud-free Landsat composite image\nCalculating the Normalized Burn Ratio (NBR) index.  \nCreating a two-image difference to help locate areas of change.\nProducing a change map and classifying changes using thresholding."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-4",
    "href": "F4.html#assumes-you-know-how-to-4",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nPerform basic image analysis: select bands, compute indices, create masks (Part F2)."
  },
  {
    "objectID": "F4.html#introduction-to-theory-3",
    "href": "F4.html#introduction-to-theory-3",
    "title": "5  Interpreting Image Series",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nChange detection is the process of assessing how landscape conditions are changing by looking at differences in images acquired at different times. This can be used to quantify changes in forest cover—such as those following a volcanic eruption, logging activity, or wildfire—or when crops are harvested (Fig. F4.4.1). For example, using time-series change detection methods, Hansen et al. (2013) quantified annual changes in forest loss and regrowth. Change detection mapping is important for observing, monitoring, and quantifying changes in landscapes over time. Key questions that can be answered using these techniques include identifying whether a change has occurred, measuring the area or the spatial extent of the region undergoing change, characterizing the nature of the change, and measuring the pattern (configuration or composition) of the change (MacLeod and Congalton 1998).\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nFig. F4.4.1 Before and after images of (a) the eruption of Mount St. Helens in Washington State, USA, in 1980 (before, July 10, 1979; after, September 5, 1980); (b) the Camp Fire in California, USA, in 2018 (before, October 7, 2018; after, March 16, 2019); (c) illegal gold mining in the Madre de Dios region of Peru (before, March 31, 2001; after, August 22, 2020); and (d) shoreline changes in Incheon, South Korea (before, May 29, 1981; after, March 11, 2020)\nMany change detection techniques use the same basic premise: that most changes on the landscape result in spectral values that differ between pre-event and post-event images. The challenge can be to separate the real changes of interest—those due to activities on the landscape—from noise in the spectral signal, which can be caused by seasonal variation and phenology, image misregistration, clouds and shadows, radiometric inconsistencies, variability in illumination (e.g., sun angle, sensor position), and atmospheric effects.\nActivities that result in pronounced changes in radiance values for a sufficiently long time period are easier to detect using remote sensing change detection techniques than are subtle or short-lived changes in landscape conditions. Mapping challenges can arise if the change event is short-lived, as these are difficult to capture using satellite instruments that only observe a location every several days. Other types of changes occur so slowly or are so vast that they are not easily detected until they are observed using satellite images gathered over a sufficiently long interval of time. Subtle changes that occur slowly on the landscape may be better suited to more computationally demanding methods, such as time-series analysis. Kennedy et al. (2009) provides a nice overview of the concepts and tradeoffs involved when designing landscape monitoring approaches. Additional summaries of change detection methods and recent advances include Singh (1989), Coppin et al. (2004), Lu et al. (2004), and Woodcock et al. (2020).\nFor land cover changes that occur abruptly over large areas on the landscape and are long-lived, a simple two-date image differencing approach is suitable. Two-date image differencing techniques are long-established methods for identifying changes that produce easily interpretable results (Singh 1989). The process typically involves four steps: (1) image selection and preprocessing; (2) data transformation, such as calculating the difference between indices of interest (e.g., the Normalized Difference Vegetation Index (NDVI)) in the pre-event and post-event images; (3) classifying the differenced image(s) using thresholding or supervised classification techniques; and (4) evaluation.\nFor the practicum, you will select pre-event and post-event image scenes and investigate the conditions in these images in a false-color composite display. Next, you will calculate the NBR index for each scene and create a difference image using the two NBR maps. Finally, you will apply a threshold to the difference image to establish categories of changed versus stable areas (Fig. F4.4.2).\n\nFig. F4.4.2 Change detection workflow for this practicum"
  },
  {
    "objectID": "F4.html#preparing-imagery",
    "href": "F4.html#preparing-imagery",
    "title": "5  Interpreting Image Series",
    "section": "10.1 Preparing Imagery",
    "text": "10.1 Preparing Imagery\nBefore beginning a change detection workflow, image preprocessing is essential. The goal is to ensure that each pixel records the same type of measurement at the same location over time. These steps include multitemporal image registration and radiometric and atmospheric corrections, which are especially important. A lot of this work has been automated and already applied to the images that are available in Earth Engine. Image selection is also important. Selection considerations include finding images with low cloud cover and representing the same phenology (e.g., leaf-on or leaf-off).\nThe code in the block below accesses the USGS Landsat 8 Level 2, Collection 2, Tier 1 dataset and assigns it to the variable landsat8. To improve readability when working with the Landsat 8 ImageCollection, the code selects bands 2–7 and renames them to band names instead of band numbers.\nvar landsat8 = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .select(\n       [‘SR_B2’, ‘SR_B3’, ‘SR_B4’, ‘SR_B5’, ‘SR_B6’, ‘SR_B7’],\n       [‘blue’, ‘green’, ‘red’, ‘nir’, ‘swir1’, ‘swir2’]\n   );\nNext, you will split the Landsat 8 ImageCollection into two collections, one for each time period, and apply some filtering and sorting to get an image for each of two time periods. In this example, we know there are few clouds for the months of the analysis; if you’re working in a different area, you may need to apply some cloud masking or mosaicing techniques (see Chap. F4.3).\nThe code below does several things. First, it creates a new geometry variable to filter the geographic bounds of the image collections. Next, it creates a new variable for the pre-event image by (1) filtering the collection by the date range of interest (e.g., June 2013), (2) filtering the collection by the geometry, (3) sorting by cloud cover so the first image will have the least cloud cover, and (4) getting the first image from the collection.\nNow repeat the previous step, but assign it to a post-event image variable and change the filter date to a period after the pre-event image’s date range (e.g., June 2020).  \nvar point = ee.Geometry.Point([-123.64, 42.96]);\nMap.centerObject(point, 11);\nvar preImage = landsat8\n   .filterBounds(point)\n   .filterDate(‘2013-06-01’, ‘2013-06-30’)\n   .sort(‘CLOUD_COVER’, true)\n   .first();   var postImage = landsat8\n   .filterBounds(point)\n   .filterDate(‘2020-06-01’, ‘2020-06-30’)\n   .sort(‘CLOUD_COVER’, true)\n   .first();"
  },
  {
    "objectID": "F4.html#creating-false-color-composites",
    "href": "F4.html#creating-false-color-composites",
    "title": "5  Interpreting Image Series",
    "section": "10.2 Creating False-Color Composites",
    "text": "10.2 Creating False-Color Composites\nBefore running any sort of change detection analysis, it is useful to first visualize your input images to get a sense of the landscape, visually inspect where changes might occur, and identify any problems in the inputs before moving further. As described in Chap. F1.1, false-color composites draw bands from multispectral sensors in the red, green, and blue channels in ways that are designed to illustrate contrast in imagery. Below, you will produce a false-color composite using SWIR-2 in the red channel, NIR in the green channel, and Red in the blue channel (Fig. F4.4.3).\nFollowing the format in the code block below, first create a variable visParam to hold the display parameters, selecting the SWIR-2, NIR, and red bands, with values drawn that are between 7750 and 22200. Next, add the pre-event and post-event images to the map and click Run. Click and drag the opacity slider on the post-event image layer back and forth to view the changes between your two images.\nvar visParam = {   ‘bands’: [‘swir2’, ‘nir’, ‘red’],   ‘min’: 7750,   ‘max’: 22200\n};\nMap.addLayer(preImage, visParam, ‘pre’);\nMap.addLayer(postImage, visParam, ‘post’);\n\nFig. F4.4.3 False-color composite using SWIR2, NIR, and red. Vegetation shows up vividly in the green channel due to vegetation being highly reflective in the NIR band. Shades of green can be indicative of vegetation density; water typically shows up as black to dark blue; and burned or barren areas show up as brown."
  },
  {
    "objectID": "F4.html#calculating-nbr",
    "href": "F4.html#calculating-nbr",
    "title": "5  Interpreting Image Series",
    "section": "10.3 Calculating NBR",
    "text": "10.3 Calculating NBR\nThe next step is data transformation, such as calculating NBR. The advantage of using these techniques is that the data, along with the noise inherent in the data, have been reduced in order to simplify a comparison between two images. Image differencing is done by subtracting the spectral value of the first-date image from that of the second-date image, pixel by pixel (Fig. F4.4.2). Two-date image differencing can be used with a single band or with spectral indices, depending on the application. Identifying the correct band or index to identify change and finding the correct thresholds to classify it are critical to producing meaningful results. Working with indices known to highlight the land cover conditions before and after a change event of interest is a good starting point. For example, the Normalized Difference Water Index would be good for mapping water level changes during flooding events; the NBR is good at detecting soil brightness; and the NDVI can be used for tracking changes in vegetation (although this index does saturate quickly). In some cases, using derived band combinations that have been customized to represent the phenomenon of interest is suggested, such as using the Normalized Difference Fraction Index to monitor forest degradation (see Chap. A3.4).\nExamine changes to the landscape caused by fires using NBR, which measures the severity of fires using the equation (NIR − SWIR) / (NIR + SWIR). These bands were chosen because they respond most strongly to the specific changes in forests caused by fire. This type of equation, a difference of variables divided by their sum, is referred to as a normalized difference equation (see Chap. F2.0). The resulting value will always fall between −1 and 1. NBR is useful for determining whether a fire recently occurred and caused damage to the vegetation, but it is not designed to detect other types of land cover changes especially well.\nFirst, calculate the NBR for each time period using the built-in normalized difference function. For Landsat 8, be sure to utilize the NIR and SWIR2 bands to calculate NBR. Then, rename each image band with the built-in rename function.\n// Calculate NBR.\nvar nbrPre = preImage.normalizedDifference([‘nir’, ‘swir2’])\n   .rename(‘nbr_pre’);\nvar nbrPost = postImage.normalizedDifference([‘nir’, ‘swir2’])\n   .rename(‘nbr_post’);\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F44a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#single-date-transformation",
    "href": "F4.html#single-date-transformation",
    "title": "5  Interpreting Image Series",
    "section": "10.4 Single Date Transformation",
    "text": "10.4 Single Date Transformation\nNext, we will examine the changes that have occurred, as seen when comparing two specific dates in time.\nSubtract the pre-event image from the post-event image using the subtract function. Add the two-date change image to the map with the specialized Fabio Crameri batlow color ramp (Crameri et al. 2020). This color ramp is an example of a color combination specifically designed to be readable by colorblind and color-deficient viewers. Being cognizant of your cartographic choices is an important part of making a good change map.\n// 2-date change.\nvar diff = nbrPost.subtract(nbrPre).rename(‘change’);\nvar palette = [   ‘011959’, ‘0E365E’, ‘1D5561’, ‘3E6C55’, ‘687B3E’,   ‘9B882E’, ‘D59448’, ‘F9A380’, ‘FDB7BD’, ‘FACCFA’\n];\nvar visParams = {\n   palette: palette,\n   min: -0.2,\n   max: 0.2\n};\nMap.addLayer(diff, visParams, ‘change’);\nQuestion 1. Try to interpret the resulting image before reading on. What patterns of change can you identify? Can you find areas that look like vegetation loss or gain?\nThe color ramp has dark blues for the lowest values, greens and oranges in the midrange, and pink for the highest values. We used nbrPre subtracted from nbrPost to identify changes in each pixel. Since NBR values are higher when vegetation is present, areas that are negative in the change image will represent pixels that were higher in the nbrPre image than in the nbrPost image. Conversely, positive differences mean that an area gained vegetation (Fig. F4.4.4). \n\n                                           b)                                           c)\n\n\nFig. F4.4.4 (a) Two-date NBR difference; (b) pre-event image (June 2013) false-color composite; (c) post-event image (June 2020) false-color composite. In the change map (a), areas on the lower range of values (blue) depict areas where vegetation has been negatively affected, and areas on the higher range of values (pink) depict areas where there has been vegetation gain; the green/orange areas have experienced little change. In the pre-event and post-event images (b and c), the green areas indicate vegetation, while the brown regions are barren ground."
  },
  {
    "objectID": "F4.html#classifying-change",
    "href": "F4.html#classifying-change",
    "title": "5  Interpreting Image Series",
    "section": "10.5 Classifying Change",
    "text": "10.5 Classifying Change\nOnce the images have been transformed and differenced to highlight areas undergoing change, the next step is image classification into a thematic map consisting of stable and change classes. This can be done rather simply by thresholding the change layer, or by using classification techniques such as machine learning algorithms. One challenge of working with simple thresholding of the difference layer is knowing how to select a suitable threshold to partition changed areas from stable classes. On the other hand, classification techniques using machine learning algorithms partition the landscape using examples of reference data that you provide to train the classifier. This may or may not yield better results, but does require additional work to collect reference data and train the classifier. In the end, resources, timing, and the patterns of the phenomenon you are trying to map will determine which approach is suitable—or perhaps the activity you are trying to track requires something more advanced, such as a time-series approach that uses more than two dates of imagery.\nFor this chapter, we will classify our image into categories using a simple, manual thresholding method, meaning we will decide the optimal values for when a pixel will be considered change or no-change in the image. Finding the ideal value is a considerable task and will be unique to each use case and set of inputs (e.g., the threshold values for a SWIR2 single-band change would be different from the thresholds for NDVI). For a look at a more advanced method of thresholding, check out the thresholding methods in Chap. A2.3.\nFirst, you will define two variables for the threshold values for gain and loss. Next, create a new image with a constant value of 0. This will be the basis of our classification. Reclassify the new image using the where function. Classify loss areas as 2 where the difference image is less than or equal to the loss threshold value. Reclassify gain areas to 1 where the difference image is greater than or equal to the gain threshold value. Finally, mask the image by itself and add the classified image to the map (Fig. F4.4.5). Note: It is not necessary to self-mask the image, and in many cases you might be just as interested in areas that did not change as you are in areas that did.\n// Classify change\nvar thresholdGain = 0.10;\nvar thresholdLoss = -0.10;\nvar diffClassified = ee.Image(0);\ndiffClassified = diffClassified.where(diff.lte(thresholdLoss), 2);\ndiffClassified = diffClassified.where(diff.gte(thresholdGain), 1);\nvar changeVis = {\n   palette: ‘fcffc8,2659eb,fa1373’,\n   min: 0,\n   max: 2\n};\nMap.addLayer(diffClassified.selfMask(),\n   changeVis,   ‘change classified by threshold’);\n\n\n\n\n\n\n\n\nFig. F4.4.5 (a) Change detection in timber forests of southern Oregon, including maps of the (left to right) pre-event false-color composite, post-event false-color composite, difference image, and classified change using NBR; (b) the same map types for an example of change caused by fire in southern Oregon. The false-color maps highlight vegetation in green and barren ground in brown. The difference images show NBR gain in pink to NBR loss in blue. The classified change images show NBR gain in blue and NBR loss in red.\nChapters F4.5 through F4.9 present more-advanced change detection algorithms that go beyond differencing and thresholding between two images, instead allowing you to analyze changes indicated across several images as a time series.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F44b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#synthesis-4",
    "href": "F4.html#synthesis-4",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nEvaluating any maps you create, including change detection maps, is essential to determining whether the method you have selected is appropriate for informing land management and decision-making (Stehman and Czaplewski 1998), or whether you need to iterate on the mapping process to improve the final results. Maps generally, and change maps specifically, will always have errors. This is due to a suite of factors, such as the geometric registration between images, the calibration between images, the data resolution (e.g., temporal, spectral, radiometric) compared to the characteristics of the activity of interest, the complexity of the landscape of the study region (topography, atmospheric conditions, etc.), and the classification techniques employed (Lu et al. 2004). This means that similar studies can present different, sometimes controversial, conclusions about landscape dynamics (e.g., Cohen et al. 2017). In order to be useful for decision-making, a change detection mapping effort should provide the user with an understanding of the strengths and weaknesses of the product, such as by presenting omission and commission error rates. The quantification of classification quality is presented in Chap. F2.2.\nAssignment 1. Try using a different index, such as NDVI or a Tasseled Cap Transformation, to run the change detection steps, and compare the results with those obtained from using NBR.\nAssignment 2. Experiment with adjusting the thresholdLoss and thresholdGain values.\nAssignment 3. Use what you have learned in the classification chapter (Chap. F2.1) to run a supervised classification on the difference layer (or layers, if you have created additional ones). Hint: To complete a supervised classification, you would need reference examples of both the stable and change classes of interest to train the classifier.\nAssignment 4. Think about how things like clouds and cloud shadows could affect the results of change detection. What do you think the two-date differencing method would pick up for images in the same year in different seasons?"
  },
  {
    "objectID": "F4.html#conclusion-4",
    "href": "F4.html#conclusion-4",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, you learned how to make a change detection map using two-image differencing. The importance of visualizing changes in this way instead of using a post-classification comparison, where two classified maps are compared instead of two satellite images, is that it avoids multiplicative errors from the classifications and is better at observing more subtle changes in the landscape. You also learned that how you visualize your images and change maps—such as what band combinations and color ramps you select, and what threshold values you use for a classification map—has an impact on how easily and what types of changes can be seen."
  },
  {
    "objectID": "F4.html#references-3",
    "href": "F4.html#references-3",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nCohen WB, Healey SP, Yang Z, et al (2017) How similar are forest disturbance maps derived from different Landsat time series algorithms? Forests 8:98. https://doi.org/10.3390/f8040098\nCoppin P, Jonckheere I, Nackaerts K, et al (2004) Digital change detection methods in ecosystem monitoring: A review. Int J Remote Sens 25:1565–1596. https://doi.org/10.1080/0143116031000101675\nCrameri F, Shephard GE, Heron PJ (2020) The misuse of colour in science communication. Nat Commun 11:1–10. https://doi.org/10.1038/s41467-020-19160-7\nFung T (1990) An assessment of TM imagery for land-cover change detection. IEEE Trans Geosci Remote Sens 28:681–684. https://doi.org/10.1109/TGRS.1990.572980\nHansen MC, Potapov PV, Moore R, et al (2013) High-resolution global maps of 21st-century forest cover change. Science 342:850–853. https://doi.org/10.1126/science.1244693\nKennedy RE, Townsend PA, Gross JE, et al (2009) Remote sensing change detection tools for natural resource managers: Understanding concepts and tradeoffs in the design of landscape monitoring projects. Remote Sens Environ 113:1382–1396. https://doi.org/10.1016/j.rse.2008.07.018\nLu D, Mausel P, Brondízio E, Moran E (2004) Change detection techniques. Int J Remote Sens 25:2365–2401. https://doi.org/10.1080/0143116031000139863\nMacleod RD, Congalton RG (1998) A quantitative comparison of change-detection algorithms for monitoring eelgrass from remotely sensed data. Photogramm Eng Remote Sensing 64:207–216\nSingh A (1989) Digital change detection techniques using remotely-sensed data. Int J  Remote Sens 10:989–1003. https://doi.org/10.1080/01431168908903939\nStehman SV, Czaplewski RL (1998) Design and analysis for thematic map accuracy assessment: Fundamental principles. Remote Sens Environ 64:331–344. https://doi.org/10.1016/S0034-4257(98)00010-8\nWoodcock CE, Loveland TR, Herold M, Bauer ME (2020) Transitioning from change detection to monitoring with remote sensing: A paradigm shift. Remote Sens Environ 238:111558. https://doi.org/10.1016/j.rse.2019.111558"
  },
  {
    "objectID": "F4.html#author-5",
    "href": "F4.html#author-5",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\nRobert Kennedy, Justin Braaten, Peter Clary"
  },
  {
    "objectID": "F4.html#overview-5",
    "href": "F4.html#overview-5",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\nTime-series analysis of change can be achieved by fitting the entire spectral trajectory using simple statistical models. These allow us to both simplify the time series and to extract useful information about the changes occurring. In this chapter, you will get an introduction to the use of LandTrendr, one of these time-series approaches used to characterize time series of spectral values."
  },
  {
    "objectID": "F4.html#learning-outcomes-5",
    "href": "F4.html#learning-outcomes-5",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nEvaluating yearly time-series spectral values to distinguish between true change and artifacts.\nRecognizing disturbance and growth signals in the time series of annual spectral values for individual pixels.\nInterpreting change segments and translating them to maps.\nApplying parameters in a graphical user interface to create disturbance maps in forests."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-5",
    "href": "F4.html#assumes-you-know-how-to-5",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nCalculate and interpret vegetation indices (Chap. F2.0)\nInterpret bands and indices in terms of land surface characteristics (Chap. F2.0)."
  },
  {
    "objectID": "F4.html#introduction-to-theory-4",
    "href": "F4.html#introduction-to-theory-4",
    "title": "5  Interpreting Image Series",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nLand surface change happens all the time, and satellite sensors witness it. If a spectral index is chosen to match the type of change being sought, surface change can be inferred from changes in spectral index values. Over time, the progression of spectral values witnessed in each pixel tells a story of the processes of change, such as growth and disturbance. Time-series algorithms are designed to leverage many observations of spectral values over time to isolate and describe changes of interest, while ignoring uninteresting change or noise.\nIn this lab, we use the LandTrendr time-series algorithms to map change. The LandTrendr algorithms apply “temporal segmentation” strategies to distill a multiyear time series into sequential straight-line segments that describe the change processes occurring in each pixel. We then isolate the segment of interest in each pixel and make maps of when, how long, and how intensely each process occurred. Similar strategies can be applied to more complicated descriptions of the time series, as is seen in some of the chapters that follow this one.\nFor this lab, we will use a graphical user interface (GUI) to teach the concepts of LandTrendr.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F45a. The book’s repository contains information about accessing the LandTrendr interface."
  },
  {
    "objectID": "F4.html#pixel-time-series",
    "href": "F4.html#pixel-time-series",
    "title": "5  Interpreting Image Series",
    "section": "11.1 Pixel Time Series",
    "text": "11.1 Pixel Time Series\nWhen working with LandTrendr for the first time in your area, there are two questions you must address.  \nFirst, is the change of interest detectable in the spectral reflectance record? If the change you are interested in does not leave a pattern in the spectral reflectance record, then an algorithm will not be able to find it.  \nSecond, can you identify fitting parameters that allow the algorithm to capture that record? Time series algorithms apply rules to a temporal sequence of spectral values in a pixel, and simplify the many observations into more digestible forms, such as the linear segments we will work with using LandTrendr. The algorithms that do the simplification are often guided by parameters that control the way the algorithm does its job.\nThe best way to begin assessing these questions is to look at the time series of individual pixels. In Earth Engine, open and run the script that generates the GUI we have developed to easily deploy the LandTrendr algorithms. Run the script, and you should see an interface that looks like the one shown in Fig. 4.5.1.\n\nFig. 4.5.1 The LandTrendr GUI interface, with the control panel on the left, the  Map panel in the center, and the reporting panel on the right\nThe LandTrendr GUI consists of three panels: a control panel on the left, a reporting panel on the right, and a Map panel in the center. The control panel is where all of the functionality of the interface resides. There are several modules,and each is accessed by clicking on the double arrow to the right of the title. The  Map panel defaults to a location in Oregon but can be manually moved anywhere in the world. The reporting panel shows messages about how to use functions, as well as providing graphical outputs.\nNext, expand the “Pixel Time Series Options” function. For now, simply use your mouse to click somewhere on the map. Wait a few seconds even though it looks like nothing is happening – be patient!! The GUI has sent information to Earth Engine to run the LandTrendr algorithms at the location you have clicked, and is waiting for the results. Eventually you should see a chart appear in the reporting panel on the right. Fig. 4.5.2 shows what one pixel looks like in an area where the forest burned and began regrowth. Your chart will probably look different.\n\nFig. 4.5.2 A typical trajectory for a single pixel. The x-axis shows the year, the y-axis the spectral index value, and the title the index chosen. The gray line represents the original spectral values observed by Landsat, and the red line the result of the LandTrendr temporal segmentation algorithms.\nThe key to success with the LandTrendr algorithm is interpreting these time series. First, let’s examine the components of the chart. The x-axis shows the year of observation. With LandTrendr, only one observation per year is used to describe the history of a pixel; later, we will cover how you control that value. The y-axis shows the spectral value of the index that is chosen. In the default mode, the Normalized Burn Ratio (as described in Chap. F4.4). Note that you also have the ability to pick more indices using the checkboxes on the control panel on the left. Note that we scale floating point (decimal) indices by 1000. Thus, an NBR value of 1.0 would be displayed as 1000.\nIn the chart area, the thick gray line represents the spectral values observed by the satellite for the period of the year selected for a single 30 m Landsat pixel at the location you have chosen. The red line is the output from the temporal segmentation that is the heart of the LandTrendr algorithms. The title of the chart shows the spectral index, as well as the root-mean-square error of the fit. \nTo interpret the time series, first know which way is “up” and “down” for the spectral index you’re interested in. For the NBR, the index goes up in value when there is more vegetation and less soil in a pixel. It goes down when there is less vegetation. For vegetation disturbance monitoring, this is useful.\nNext, translate that change into the changes of interest for the change processes you’re interested in. For conifer forest systems, the NBR is useful because it drops precipitously when a disturbance occurs, and it rises as vegetation grows.  \nIn the case of Fig. 4.5.2, we interpret the abrupt drop as a disturbance, and the subsequent rise of the index as regrowth or recovery (though not necessarily to the same type of vegetation).\n\nFig. 4.5.3 For the trajectory in Fig. 4.5.2, we can identify a segment capturing disturbance based on its abrupt drop in the NBR index, and the subsequent vegetative recovery\nTip: LandTrendr is able to accept any index, and advanced users are welcome to use indices of their own design. An important consideration is knowing which direction indicates “recovery” and “disturbance” for the topic you are interested in. The algorithms favor detection of disturbance and can be controlled to constrain how quickly recovery is assumed to occur (see parameters below).  \nFor LandTrendr to have any hope of finding the change of interest, that change must be manifested in the gray line showing the original spectral values. If you know that some process is occurring and it is not evident in the gray line, what can you do?\nOne option is to change the index. Any single index is simply one view of the larger spectral space of the Landsat Thematic Mapper sensors. The change you are interested in may cause spectral change in a different direction than that captured with some indices. Try choosing different indices from the list. If you click on different checkboxes and re-submit the pixel, the fits for all of the different indices will appear.\nAnother option is to change the date range. LandTrendr uses one value per year, but the value that is chosen can be controlled by the user. It’s possible that the change of interest is better identified in some seasons than others. We use a medoid image compositing approach, which picks the best single observation each year from a date range of images in an ImageCollection. In the GUI, you can change the date range of imagery used for compositing in the Image Collection portion of the LandTrendr Options menu (Fig. F4.5.4).  \n\nFig. 4.5.4 The LandTrendr options menu. Users control the year and date range in the Image Collection section, the index used for temporal segmentation in the middle section, and the parameters controlling the temporal segmentation in the bottom section\nChange the Start Date and End Date to find a time of year when the distinction between cover conditions before and during the change process of interest is greatest.\nThere are other considerations to keep in mind. First, seasonality of vegetation, water, or snow often can affect the signal of the change of interest. And because we use an ImageCollection that spans a range of dates, it’s best to choose a date range where there is not likely to be a substantial change in vegetative state from the beginning to the end of the date range. Clouds can be a factor too. Some seasons will have more cloudiness, which can make it difficult to find good images. Often with optical sensors, we are constrained to working with periods where clouds are less prevalent, or using wide date ranges to provide many opportunities for a pixel to be cloud-free.\nIt is possible that no combination of index or data range is sensitive to the change of interest. If that is the case, there are two options: try using a different sensor and change detection technique, or accept that the change is not discernible. This can often occur if the change of interest occupies a small portion of a given 30 m by 30 m Landsat pixel, or if the spectral manifestation of the change is so subtle that it is not spectrally separable from non-changed pixels\nEven if you as a human can identify the change of interest in the spectral trajectory of the gray line, an algorithm may not be able to similarly track it. To give the algorithm a fighting chance, you need to explore whether different fitting parameters could be used to match the red fitted line with the gray source image line.  \nThe overall fitting process includes steps to reduce noise and best identify the underlying signal. The temporal segmentation algorithms are controlled by fitting parameters that are described in detail in Kennedy et al. (2010). You adjust these parameters using the Fitting Parameters block of the LandTrendr Options menu. Below is a brief overview of what values are often useful, but these will likely change as you use different spectral indices.\nFirst, the minimum observations needed criterion is used to evaluate whether a given trajectory has enough unfiltered (i.e., clear observation) years to run the fitting. We suggest leaving this at the default of 6.\nThe segmentation begins with a noise-dampening step to remove spikes that could be caused by unfiltered clouds or shadows. The spike threshold parameter controls the degree of filtering. A value of 1.0 corresponds to no filtering, and lower values corresponding to more severe filtering. We suggest leaving this at 0.9; if changed, a range from 0.7 to 1.0 is appropriate.\nThe next step is finding vertices. This begins with the start and end year as vertex years, progressively adding candidate vertex years based on deviation from linear fits. To avoid getting an overabundance of vertex years initially found using this method, we suggest leaving the vertex count overshoot at a value of 3. A second set of algorithms uses deflection angle to cull back this overabundance to a set number of maximum candidate vertex years.\nThat number of vertex years is controlled by the max_segments parameter. As a general rule, your number of segments should be no more than one-third of the total number of likely yearly observations. The years of these vertices (X-values) are then passed to the model-building step. Assuming you are using at least 30 years of the archive, and your area has reasonable availability of images, a value of 8 is a good starting point.\nIn the model-building step, straight-line segments are built by fitting Y-values (spectral values) for the periods defined by the vertex years (X-values). The process moves from left to right—early years to late years. Regressions of each subsequent segment are connected to the end of the prior segment. Regressions are also constrained to prevent unrealistic recovery after disturbance, as controlled by the recovery threshold parameter. A lower value indicates greater constraint: a value of 1.0 means the constraint is turned off; a value of 0.25 means that segments that fully recover in faster than four years (4 = 1/0.25) are not permitted. Note: This parameter has strong control on the fitting, and is one of the first to explore when testing parameters.  Additionally, the preventOneYearRecovery will disallow fits that have one-year-duration recovery segments.  This may be useful to prevent overfitting of noisy data in environments where such quick vegetative recovery is not ecologically realistic.\nOnce a model of the maximum number of segments is found, successively simpler models are made by iteratively removing the least informative vertex. Each model is scored using a pseudo-f statistic, which penalizes models with more segments, to create a pseudo p-value for each model. The p-value threshold parameter is used to identify all fits that are deemed good enough. Start with a value of 0.05, but check to see if the fitted line appears to capture the salient shape and features of the gray source trajectory.  If you see temporal patterns in the gray line that are likely not noise (based on your understanding of the system under study), consider switching the p-value threshold to 0.10 or even 0.15. \nNote: because of temporal autocorrelation, these cannot be interpreted as true f- and p-values, but rather as relative scalars to distinguish goodness of fit among models. If no good models can be found using these criteria based on the p-value parameter set by the user, a second approach is used to solve for the Y-value of all vertex years simultaneously. If no good model is found, then a straight-line mean value model is used.\nFrom the models that pass the p-value threshold, one is chosen as the final fit. It may be the one with the lowest p-value. However, an adjustment is made to allow more complicated models (those with more segments) to be picked even if their p-value is within a defined proportion of the best-scoring model. That proportion is set by the best model proportion parameter. As an example, a best model proportion value of 0.75 would allow a more complicated model to be chosen if its score were greater than 75% that of the best model."
  },
  {
    "objectID": "F4.html#translating-pixels-to-maps",
    "href": "F4.html#translating-pixels-to-maps",
    "title": "5  Interpreting Image Series",
    "section": "11.2 Translating Pixels to Maps",
    "text": "11.2 Translating Pixels to Maps\nAlthough the full time series is the best description of each pixel’s “life history,” we typically are interested in the behavior of all of the pixels in our study area. It would be both inefficient to manually visualize all of them and ineffective to try to summarize areas and locations. Thus, we seek to make maps.\nThere are three post-processing steps to convert a segmented trajectory to a map. First, we identify segments of interest; if we are interested in disturbance, we find segments whose spectral change indicates loss. Second, we filter out segments of that type that do not meet criteria of interest. For example, very low magnitude disturbances can occur when the algorithm mistakenly finds a pattern in the random noise of the signal, and thus we do not want to include it. Third, we extract from the segment of interest something about its character to map on a pixel-by-pixel basis: its start year, duration, spectral value, or the value of the spectral change.\nTheory: We’ll start with a single pixel to learn how to Interpret a disturbance pixel time series in terms of the dominant disturbance segment. For the disturbance time series we have used in figures above, we can identify the key parameters of the segment associated with the disturbance. For the example above, we have extracted the actual NBR values of the fitted time series and noted them in a table (Fig. 4.5.5). This is not part of the GUI – it is simply used here to work through the concepts.\n\nFig. 4.5.5 Tracking actual values of fitted trajectories to learn how we focus on quantification of disturbance. Because we know that the NBR index drops when vegetation is lost and soil exposure is increased, we know that a precipitous drop suggests an abrupt loss of vegetation. Although some early segments show very subtle change, only the segment between vertex 4 and 5 shows large-magnitude vegetation loss.\nFrom the table shown in Fig. 4.5.5, we can infer several key things about this pixel:\n\nIt was likely disturbed between 2006 and 2007. This is because the NBR value drops precipitously in the segment bounded by vertices (breakpoints) in 2006 and 2007.  \nThe magnitude of spectral change was large: 1175 scaled NBR units out of a possible range of 2000 scaled units.\nThere were small drops in NBR earlier, which may indicate some subtle loss of vegetation over a long period in the pixel. These drops, however, would need to be explored in a separate analysis because of their subtle nature.\nThe main disturbance had a disturbance duration of just one year. This abruptness combined with the high magnitude suggests a major vegetative disturbance such as a harvest or a fire.\nThe disturbance was then followed by recovery of vegetation, but not to the level before the disturbance. Note: Ecologists will recognize the growth signal as one of succession, or active revegetation by human intervention.\n\nFollowing the three post-processing steps noted in the introduction to this section, to map the year of disturbance for this pixel we would first identify the potential disturbance segments as those with negative NBR. Then we would hone in on the disturbance of interest by filtering out potential disturbance segments that are not abrupt and/or of small magnitude. This would leave only the high-magnitude, short-duration segment. For that segment, the first year that we have evidence of disturbance is the first year after the start of the segment. The segment starts in 2006, which means that 2007 is the first year we have such evidence. Thus, we would assign 2007 to this pixel.\nIf we wanted to map the magnitude of the disturbance, we would follow the same first two steps, but then report for the pixel value the magnitude difference between the starting and ending segment.\nThe LandTrendr GUI provides a set of tools to easily apply the same logic rules to all pixels of interest and create maps. Click on the Change Filter Options menu. The interface shown in Fig. 4.5.6 appears.\n\nFig. 4.5.6 The menu used to post-process disturbance trajectories into maps. Select vegetation change type and sort to hone in on the segment type of interest, then check boxes to apply selective filters to eliminate uninteresting changes.  \nThe first two sections are used to identify the segments of interest.  \nSelect Vegetation Change Type offers the options of gain or loss, which refer to gain or loss of vegetation, with disturbance assumed to be related to loss of vegetation. Note: Advanced users can look in the landtrendr.js library in the “calcindex” function to add new indices with gain and loss defined as they choose. The underlying algorithm is built to find disturbance in indices that increase when disturbance occurs, so indices such as NBR or NDVI need to be multiplied by (−1) before being fed to the LandTrendr algorithm. This is handled in the calcIndex function.\nSelect Vegetation Change Sort offers various options that allow you to choose the segment of interest based on timing or duration. By default, the greatest magnitude disturbance is chosen.\nEach filter (magnitude, duration, etc.) is used to further winnow the possible segments of interest. All other filters are applied at the pixel scale, but Filter by MMU is applied to groups of pixels based on a given minimum mapping unit (MMU). Once all other filters have been defined, some pixels are flagged as being of interest and others are not. The MMU filter looks to see how many connected pixels have been flagged as occurring in the same year, and omits groups smaller in pixel count than the number indicated here (which defaults to 11 pixels, or approximately 1 hectare).  \nIf you’re following along and making changes, or if you’re just using the default location and parameters, click the Add Filtered Disturbance Imagery to add this to the map. You should see something like Fig. 4.5.7.\n\nFig. 4.5.7 The basic output from a disturbance mapping exercise  \nThere are multiple layers of disturbance added to the map. Use the map layers checkboxes to change which is shown. Magnitude of disturbance, for example, is a map of the delta change between beginning and endpoints of the segments (Fig. 4.5.8).\n\nFig. 4.5.8 Magnitude of change for the same area"
  },
  {
    "objectID": "F4.html#synthesis-5",
    "href": "F4.html#synthesis-5",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nIn this chapter, you have learned how to work with annual time series to interpret regions of interest. Looking at annual snapshots of the landscape provides three key benefits: (1) the ability to view your area of interest without the clouds and noise that typically obscure single-day views; (2) gauge the amount by which the noise-dampened signal still varies from year to year in response to large-scale forcing mechanisms; and (3) the ability to view the response of landscapes as they recover, sometimes slowly, from disturbance.\nTo learn more about LandTrendr, see the assignments below.\nAssignment 1. Find your own change processes of interest. First, navigate the map (zooming and dragging) to an area of the world where you are interested in a change process, and the spectral index that would capture it. Make sure the UI control panel is open to the Pixel Time-Series Options section. Next, click on the map in areas where you know change has occurred, and observe the spectral trajectories in the charts. Then, describe whether the change of interest is detectable in the spectral reflectance record, and what are its characteristics in different parts of the study area. .\nAssignment 2: Find a pixel in your area of interest that shows a distinctive disturbance process, as you define it for your topic of interest. Adjust date ranges, parameters, etc. using the steps outlined in Section 1 above, and then answer these questions:\n\nQuestion 1. Which index and date range did you use?\nQuestion 2. Did you need to change fitting parameters to make the algorithm find the disturbance? If so, which ones, and why?\nQuestion 3. How do you know this is a disturbance?\n\nAssignment 3. Switch the control panel in the GUI to Change Filter Options, and use the guidance in Section 2 to set parameters and make disturbance maps.  \n\nQuestion 4. Do the disturbance year and magnitude as mapped in the image match with what you would expect from the trajectory itself?\nQuestion 5. Can you change some of the filters to create a map where your disturbance process is not mapped? If so, what did you change?  \nQuestion 6. Can you change filters to create a map that includes a different disturbance process, perhaps subtler, longer duration, etc.? Find a pixel and use the “Pixel time series” plotter to look at the time series of those processes.\n\nAssignment 4:  Return to the Pixel Time-Series Options section of the control panel, and navigate to a pixel in your area of interest that you believe would show a distinctive recovery or growth process, as you define it for your topic of interest. You may want to modify the index, parameters, etc. as covered in Section 1 to adequately capture the growth process with the fitted trajectories.\n\nQuestion 7. Did you use the same spectral index? If not, why?\nQuestion 8. Were the fitting parameters the same as those for disturbance? If not, what did you change, and why?\nQuestion 9. What evidence do you have that this is a vegetative growth signal?\n\nAssignment 5. For vegetation gain mapping, switch the control panel back to Change Filter Options and use the guidance in Section 2 to set parameters, etc. to make maps of growth.\n\nQuestion 10. For the pixel or pixels you found for Assignment 3, does the year and magnitude as mapped in the “gain” image match with what you would expect from the trajectory itself?\nQuestion 11. Compare what the map looks like when you run it with and without the MMU filter. What differences do you see?\nQuestion 12. Try changing the recovery duration filter to a very high number (perhaps the full length of your archive) and to a very low number (say, one or two years). What differences do you see?"
  },
  {
    "objectID": "F4.html#conclusion-5",
    "href": "F4.html#conclusion-5",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nThis exercise provides a baseline sense of how the LandTrendr algorithm works. The key points are learning how to interpret change in spectral values in terms of the processes occurring on the ground, and then translating those into maps.\nYou can export the images you’ve made here using Download Options. Links to materials are available in the chapter checkpoints and LandTrendr documentation about both the GUI and the script-based versions of the algorithm. In particular, there are scripts that handle different components of the fitting and mapping process, and that allow you to keep track of the fitting and image selection criteria."
  },
  {
    "objectID": "F4.html#references-4",
    "href": "F4.html#references-4",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nKennedy RE, Yang Z, Cohen WB (2010) Detecting trends in forest disturbance and recovery using yearly Landsat time series: 1. LandTrendr - Temporal segmentation algorithms. Remote Sens Environ 114:2897–2910. https://doi.org/10.1016/j.rse.2010.07.008\nKennedy RE, Yang Z, Gorelick N, et al (2018) Implementation of the LandTrendr algorithm on Google Earth Engine. Remote Sens 10:691. https://doi.org/10.3390/rs10050691"
  },
  {
    "objectID": "F4.html#author-6",
    "href": "F4.html#author-6",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\nAndréa Puzzi Nicolau, Karen Dyson, Biplov Bhandari, David Saah, Nicholas Clinton"
  },
  {
    "objectID": "F4.html#overview-6",
    "href": "F4.html#overview-6",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\nThe purpose of this chapter is to establish a foundation for time-series analysis of remotely sensed data, which is typically arranged as an ordered stack of images. You will be introduced to the concepts of graphing time series, using linear modeling to detrend time series, and fitting harmonic models to time-series data. At the completion of this chapter, you will be able to perform analysis of multi-temporal data for determining trend and seasonality on a per-pixel basis."
  },
  {
    "objectID": "F4.html#learning-outcomes-6",
    "href": "F4.html#learning-outcomes-6",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nGraphing satellite imagery values across a time series.\nQuantifying and potentially removing linear trends in time series.\nFitting linear and harmonic models to individual pixels in time-series data."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-6",
    "href": "F4.html#assumes-you-know-how-to-6",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nPerform basic image analysis: select bands, compute indices, create masks (Part F2).\n​​Create a graph using ui.Chart (Chap. F1.3).\nUse normalizedDifference to calculate vegetation indices (Chap. F2.0).\nWrite a function and map it over an ImageCollection (Chap. F4.0).\nMask cloud, cloud shadow, snow/ice, and other undesired pixels (Chap. F4.3)."
  },
  {
    "objectID": "F4.html#introduction-to-theory-5",
    "href": "F4.html#introduction-to-theory-5",
    "title": "5  Interpreting Image Series",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nMany natural and man-made phenomena exhibit important annual, interannual, or longer-term trends that recur—that is, they occur at roughly regular intervals. Examples include seasonality in leaf patterns in deciduous forests and seasonal crop growth patterns. Over time, indices such as the Normalized Difference Vegetation Index (NDVI) will show regular increases (e.g., leaf-on, crop growth) and decreases (e.g., leaf-off, crop senescence), and typically have a long-term, if noisy, trend such as a gradual increase in NDVI value as an area recovers from a disturbance.\nEarth Engine supports the ability to do complex linear and non-linear regressions of values in each pixel of a study area. Simple linear regressions of indices can reveal linear trends that can span multiple years. Meanwhile, harmonic terms can be used to fit a sine-wave-like curve. Once you have the ability to fit these functions to time series, you can answer many important questions. For example, you can define vegetation dynamics over multiple time scales, identify phenology and track changes year to year, and identify deviations from the expected patterns (Bradley et al. 2007, Bullock et al. 2020). There are multiple applications for these analyses. For example, algorithms to detect deviations from the expected pattern can be used to identify disturbance events, including deforestation and forest degradation (Bullock et al. 2020).\nIf you have not already done so, be sure to add the book’s code repository to the Code Editor by entering https://code.earthengine.google.com/?accept_repo=projects/gee-edu/book into your browser. The book’s scripts will then be available in the script manager panel."
  },
  {
    "objectID": "F4.html#multi-temporal-data-in-earth-engine",
    "href": "F4.html#multi-temporal-data-in-earth-engine",
    "title": "5  Interpreting Image Series",
    "section": "12.1 Multi-Temporal Data in Earth Engine",
    "text": "12.1 Multi-Temporal Data in Earth Engine\nAs explained in Chaps. F4.0 and F4.1, a time series in Earth Engine is typically represented as an ImageCollection. Because of image overlaps, cloud treatments, and filtering choices, an ImageCollection can have any of the following complex characteristics:\n\nAt each pixel, there might be a distinct number of observations taken from a unique set of dates.\nThe size (length) of the time series can vary across pixels.\nData may be missing in any pixel at any point in the sequence (e.g., due to cloud masking).\n\nThe use of multi-temporal data in Earth Engine introduces two mind-bending concepts, which we will describe below.\nPer-pixel curve fitting. As you have likely encountered in many settings, a function can be fit through a series of values. In the most familiar example, a function of the form y = mx + b can represent a linear trend in data of all kinds. Fitting a straight “curve” with linear regression techniques involves estimating m and b for a set of x and y values. In a time series, x typically represents time, while y values represent observations at specific times. This chapter introduces how to estimate m and b for computed indices through time to model a potential linear trend in a time series. We then demonstrate how to fit a sinusoidal wave, which is useful for modeling rising and falling values, such as NDVI over a growing season. What can be particularly mind-bending in this setting is the fact that when Earth Engine is asked to estimate values across a large area, it will fit a function in every pixel of the study area. Each pixel, then, has its own m and b values, determined by the number of observations in that pixel, the observed values, and the dates for which they were observed.\nHigher-dimension band values: array images. That more complex conception of the potential information contained in a single pixel can be represented in a higher-order Earth Engine structure: the array image. As you will encounter in this lab, it is possible for a single pixel in a single band of a single image to contain more than one value. If you choose to implement an array image, a single pixel might contain a one-dimensional vector of numbers, perhaps holding the slope and intercept values resulting from a linear regression, for example. Other examples, outside the scope of this chapter but used in the next chapter, might employ a two-dimensional matrix of values for each pixel within a single band of an image. Higher-order dimensions are available, as well as array image manipulations borrowed from the world of matrix algebra. Additionally, there are functions to move between the multidimensional array image structure and the more familiar, more easily displayed, simple Image type. Some of these array image functions were encountered in Chap. F3.1, but with less explanatory context.\nFirst, we will give some very basic notation (Fig. F4.6.1). A scalar pixel at time t is given by pt, and a pixel vector by pt. A variable with a “hat” represents an estimated value: in this context, p̂t is the estimated pixel value at time t. A time series is a collection of pixel values, usually sorted chronologically: {pt; t = t0…tN}, where t might be in any units, t0 is the smallest, and tN is the largest such t in the series.\n\nFig. F4.6.1 Time series representation of pixel p"
  },
  {
    "objectID": "F4.html#data-preparation-and-preprocessing",
    "href": "F4.html#data-preparation-and-preprocessing",
    "title": "5  Interpreting Image Series",
    "section": "12.2 Data Preparation and Preprocessing",
    "text": "12.2 Data Preparation and Preprocessing\nThe first step in analysis of time-series data is to import data of interest and plot it at an interesting location. We will work with the USGS Landsat 8 Level 2, Collection 2, Tier 1 ImageCollection and a cloud-masking function (Chap. F4.3), scale the image values, and add variables of interest to the collection as bands. Copy and paste the code below to filter the Landsat 8 collection to a point of interest over California (variable roi) and specific dates, and to apply the defined function. The variables of interest added by the function are: (1) NDVI (Chap. F2.0), (2) a time variable that is the difference between the image’s current year and the year 1970 (a start point), and (3) a constant variable with value 1.\n///////////////////// Sections 1 & 2 /////////////////////////////\n// Define function to mask clouds, scale, and add variables\n// (NDVI, time and a constant) to Landsat 8 imagery.\nfunction maskScaleAndAddVariable(image) {   // Bit 0 - Fill   // Bit 1 - Dilated Cloud   // Bit 2 - Cirrus   // Bit 3 - Cloud   // Bit 4 - Cloud Shadow   var qaMask = image.select(‘QA_PIXEL’).bitwiseAnd(parseInt(‘11111’,       2)).eq(0);   var saturationMask = image.select(‘QA_RADSAT’).eq(0);   // Apply the scaling factors to the appropriate bands.   var opticalBands = image.select(‘SR_B.’).multiply(0.0000275).add(-       0.2);   var thermalBands = image.select(’ST_B.*‘).multiply(0.00341802)\n       .add(149.0);   // Replace the original bands with the scaled ones and apply the masks.   var img = image.addBands(opticalBands, null, true)\n       .addBands(thermalBands, null, true)\n       .updateMask(qaMask)\n       .updateMask(saturationMask);   var imgScaled = image.addBands(img, null, true);   // Now we start to add variables of interest.   // Compute time in fractional years since the epoch.   var date = ee.Date(image.get(’system:time_start’));   var years = date.difference(ee.Date(‘1970-01-01’), ‘year’);   // Return the image with the added bands.   return imgScaled       // Add an NDVI band.       .addBands(imgScaled.normalizedDifference([‘SR_B5’, ‘SR_B4’])\n           .rename(‘NDVI’))       // Add a time band.       .addBands(ee.Image(years).rename(‘t’))\n       .float()       // Add a constant band.       .addBands(ee.Image.constant(1));\n}\n// Import point of interest over California, USA.\nvar roi = ee.Geometry.Point([-121.059, 37.9242]);\n// Import the USGS Landsat 8 Level 2, Collection 2, Tier 1 image collection),\n// filter, mask clouds, scale, and add variables.\nvar landsat8sr = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterBounds(roi)\n   .filterDate(‘2013-01-01’, ‘2018-01-01’)\n   .map(maskScaleAndAddVariable);\n// Set map center over the ROI.\nMap.centerObject(roi, 6);\nNext, to visualize the NDVI at the point of interest over time, copy and paste the code below to print a chart of the time series (Chap. F1.3) at the location of interest (Fig. F4.6.2).\n// Plot a time series of NDVI at a single location.\nvar landsat8Chart = ui.Chart.image.series(landsat8sr.select(‘NDVI’), roi)\n   .setChartType(‘ScatterChart’)\n   .setOptions({\n       title: ‘Landsat 8 NDVI time series at ROI’,\n       lineWidth: 1,\n       pointSize: 3,\n   });\nprint(landsat8Chart);\n\nFig. F4.6.2 Time series representation of pixel p \nWe can add a linear trend line to our chart using the trendlines parameters in the setOptions function for image series charts. Copy and paste the code below to print the same chart but with a linear trend line plotted (Fig. F4.6.3). In the next section, you will learn how to estimate linear trends over time.\n// Plot a time series of NDVI with a linear trend line\n// at a single location.\nvar landsat8ChartTL = ui.Chart.image.series(landsat8sr.select(‘NDVI’), roi)\n   .setChartType(‘ScatterChart’)\n   .setOptions({\n       title: ‘Landsat 8 NDVI time series at ROI’,\n       trendlines: {           0: {\n               color: ‘CC0000’           }\n       },\n       lineWidth: 1,\n       pointSize: 3,\n   });\nprint(landsat8ChartTL);\n\nFig. F4.6.3 Time series representation of pixel p with the trend line in red\nNow that we have plotted and visualized the data, lots of interesting analyses can be done to the time series by harnessing Earth Engine tools for fitting curves through this data. We will see a couple of examples in the following sections.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F46a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#estimating-linear-trend-over-time",
    "href": "F4.html#estimating-linear-trend-over-time",
    "title": "5  Interpreting Image Series",
    "section": "12.3 Estimating Linear Trend Over Time",
    "text": "12.3 Estimating Linear Trend Over Time\nTime series datasets may contain not only trends but also seasonality, both of which may need to be removed prior to modeling. Trends and seasonality can result in a varying mean and a varying variance over time, both of which define a time series as non-stationary. Stationary datasets, on the other hand, have a stable mean and variance, and are therefore much easier to model.\nConsider the following linear model, where et is a random error:\npt = β0 + β1t + et                                                        (Eq. F4.6.1)\nThis is the model behind the trend line added to the chart created in the previous section (Fig. F4.6.3). Identifying trends at different scales is a big topic, with many approaches being used (e.g., differencing, modeling).\nRemoving unwanted to uninteresting trends for a given problem is often a first step to understanding complex patterns in time series. There are several approaches to remove trends. Here, we will remove the linear trend that is evident in the data shown in Fig. F4.6.3 using Earth Engine’s built-in tools for regression modeling. This approach is a useful, straightforward way to detrend data in time series (Shumway and Stoffer 2019). Here, the goal is to discover the values of the β’s in Eq. F4.6.1 for each pixel.\nCopy and paste code below into the Code Editor, adding it to the end of the script from the previous section. Running this code will fit this trend model to the Landsat-based NDVI series using ordinary least squares, using the linearRegression reducer (Chap. F3.0).\n///////////////////// Section 3 /////////////////////////////\n// List of the independent variable names\nvar independents = ee.List([‘constant’, ‘t’]);\n// Name of the dependent variable.\nvar dependent = ee.String(‘NDVI’);\n// Compute a linear trend.  This will have two bands: ‘residuals’ and\n// a 2x1 (Array Image) band called ‘coefficients’.\n// (Columns are for dependent variables)\nvar trend = landsat8sr.select(independents.add(dependent))\n   .reduce(ee.Reducer.linearRegression(independents.length(), 1));\nMap.addLayer(trend, {}, ‘trend array image’);\n// Flatten the coefficients into a 2-band image.\nvar coefficients = trend.select(‘coefficients’)   // Get rid of extra dimensions and convert back to a regular image   .arrayProject([0])\n   .arrayFlatten([independents]);\nMap.addLayer(coefficients, {}, ‘coefficients image’);\nIf you click over a point using the Inspector tab, you will see the pixel values for the array image (coefficients “t” and “constant”, and residuals) and two-band image (coefficients “t” and “constant”) (Fig. F4.6.4).\n\nFig. F4.6.4 Pixel values of array image and coefficients image\nNow, copy and paste the code below to use the model to detrend the original NDVI time series and plot the time series chart with the trendlines parameter (Fig. F4.6.5).\n// Compute a detrended series.\nvar detrended = landsat8sr.map(function(image) {   return image.select(dependent).subtract(\n           image.select(independents).multiply(coefficients)\n           .reduce(‘sum’))\n       .rename(dependent)\n       .copyProperties(image, [‘system:time_start’]);\n});\n// Plot the detrended results.\nvar detrendedChart = ui.Chart.image.series(detrended, roi, null, 30)\n   .setOptions({\n       title: ‘Detrended Landsat time series at ROI’,\n       lineWidth: 1,\n       pointSize: 3,\n       trendlines: {           0: {\n               color: ‘CC0000’           }\n       },\n   });print(detrendedChart);\n\nFig. F4.6.5 Detrended NDVI time series\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F46b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#estimating-seasonality-with-a-harmonic-model",
    "href": "F4.html#estimating-seasonality-with-a-harmonic-model",
    "title": "5  Interpreting Image Series",
    "section": "12.4 Estimating Seasonality with a Harmonic Model",
    "text": "12.4 Estimating Seasonality with a Harmonic Model\nA linear trend is one of several possible types of trends in time series. Time series can also present harmonic trends, in which a value goes up and down in a predictable wave pattern. These are of particular interest and usefulness in the natural world, where harmonic changes in greenness of deciduous vegetation can occur across the spring, summer, and autumn. Now we will return to the initial time series (landsat8sr) of Fig. F4.6.2 and fit a harmonic pattern through the data. Consider the following harmonic model, where A is amplitude, ω is frequency, φ is phase, and et is a random error.\npt = β0 + β1t + Acos(2πωt - φ) + et \n    = β0 + β1t + β2cos(2πωt) + β3sin(2πωt) + et                (Eq. F4.6.2)\nNote that β2 = Acos(φ) and β3 = Asin(φ), implying A = (β22 + β32)½ and φ = atan(β3/β2) (as described in Shumway and Stoffer 2019). To fit this model to an annual time series, set ω = 1 (one cycle per year) and use ordinary least squares regression.\nThe setup for fitting the model is to first add the harmonic variables (the third and fourth terms of Eq. F4.6.2) to the ImageCollection. Then, fit the model as with the linear trend, using the linearRegression reducer, which will yield a 4 x 1 array image.\n///////////////////// Section 4 /////////////////////////////\n// Use these independent variables in the harmonic regression.\nvar harmonicIndependents = ee.List([‘constant’, ‘t’, ‘cos’, ‘sin’]);\n// Add harmonic terms as new image bands.\nvar harmonicLandsat = landsat8sr.map(function(image) {   var timeRadians = image.select(‘t’).multiply(2 * Math.PI);   return image       .addBands(timeRadians.cos().rename(‘cos’))\n       .addBands(timeRadians.sin().rename(‘sin’));\n});\n// Fit the model.\nvar harmonicTrend = harmonicLandsat\n   .select(harmonicIndependents.add(dependent))   // The output of this reducer is a 4x1 array image.   .reduce(ee.Reducer.linearRegression(harmonicIndependents.length(),       1));\nNow, copy and paste the code below to plug the coefficients into Eq. F4.6.2 in order to get a time series of fitted values and plot the harmonic model time series (Fig. F4.6.6).\n// Turn the array image into a multi-band image of coefficients.\nvar harmonicTrendCoefficients = harmonicTrend.select(‘coefficients’)\n   .arrayProject([0])\n   .arrayFlatten([harmonicIndependents]);\n// Compute fitted values.\nvar fittedHarmonic = harmonicLandsat.map(function(image) {   return image.addBands(\n       image.select(harmonicIndependents)\n       .multiply(harmonicTrendCoefficients)\n       .reduce(‘sum’)\n       .rename(‘fitted’));\n});\n// Plot the fitted model and the original data at the ROI.\nprint(ui.Chart.image.series(\n       fittedHarmonic.select([‘fitted’, ‘NDVI’]), roi, ee.Reducer\n       .mean(), 30)\n   .setSeriesNames([‘NDVI’, ‘fitted’])\n   .setOptions({\n       title: ‘Harmonic model: original and fitted values’,\n       lineWidth: 1,\n       pointSize: 3,\n   }));\n\nFig. F4.6.6 Harmonic model of NDVI time series\nReturning to the mind-bending nature of curve-fitting, it is worth remembering that the harmonic waves seen in Fig. F4.6.6 are the fit of the data to a single point across the image. Next, we will map the outcomes of millions of these fits, pixel by pixel, across the entire study area.\nWe’ll compute and map the phase and amplitude of the estimated harmonic model for each pixel. Phase and amplitude (Fig. F4.6.7) can give us additional information to facilitate remote sensing applications such as agricultural mapping and land use and land cover monitoring. Agricultural crops with different phenological cycles can be distinguished with phase and amplitude information, something that perhaps would not be possible with spectral information alone.\n\nFig. F4.6.7 Example of phase and amplitude in harmonic model\nCopy and paste the code below to compute phase and amplitude from the coefficients and add this image to the map (Fig. F4.6.8).\n// Compute phase and amplitude.\nvar phase = harmonicTrendCoefficients.select(‘sin’)\n   .atan2(harmonicTrendCoefficients.select(‘cos’))   // Scale to [0, 1] from radians.   .unitScale(-Math.PI, Math.PI);\nvar amplitude = harmonicTrendCoefficients.select(‘sin’)\n   .hypot(harmonicTrendCoefficients.select(‘cos’))   // Add a scale factor for visualization.   .multiply(5);\n// Compute the mean NDVI.\nvar meanNdvi = landsat8sr.select(‘NDVI’).mean();\n// Use the HSV to RGB transformation to display phase and amplitude.\nvar rgb = ee.Image.cat([\n   phase, // hue   amplitude, // saturation (difference from white)   meanNdvi // value (difference from black)\n]).hsvToRgb();\nMap.addLayer(rgb, {}, ‘phase (hue), amplitude (sat), ndvi (val)’);\n\nFig. F4.6.8 Phase, amplitude, and NDVI concatenated image\nThe code uses the HSV to RGB transformation hsvToRgb for visualization purposes (Chap. F3.1). We use this transformation to separate color components from intensity for a better visualization. Without this transformation, we would visualize a very colorful image that would not look as intuitive as the image with the transformation. With this transformation, phase, amplitude, and mean NDVI are displayed in terms of hue (color), saturation (difference from white), and value (difference from black), respectively. Therefore, darker pixels are areas with low NDVI. For example, water bodies will appear as black, since NDVI values are zero or negative. The different colors are distinct phase values, and the saturation of the color refers to the amplitude: whiter colors mean amplitude closer to zero (e.g., forested areas), and the more vivid the colors, the higher the amplitude (e.g., croplands). Note that if you use the Inspector tool to analyze the values of a pixel, you will not get values of phase, amplitude, and NDVI, but the transformed values into values of blue, green, and red colors.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F46c. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#an-application-of-curve-fitting",
    "href": "F4.html#an-application-of-curve-fitting",
    "title": "5  Interpreting Image Series",
    "section": "12.5 An Application of Curve Fitting",
    "text": "12.5 An Application of Curve Fitting\n\n12.5.1 The rich data about the curve fits can be viewed in a multitude of different ways. Add the code below to your script to produce the view in Fig. 4.6.9. The image will be a close-up of the area around Modesto, California.\n///////////////////// Section 5 /////////////////////////////\n// Import point of interest over California, USA.\nvar roi = ee.Geometry.Point([-121.04, 37.641]);\n// Set map center over the ROI.\nMap.centerObject(roi, 14);\nvar trend0D = trend.select(‘coefficients’).arrayProject([0])\n   .arrayFlatten([independents]).select(‘t’);\nvar anotherView = ee.Image(harmonicTrendCoefficients.select(‘sin’))\n   .addBands(trend0D)\n   .addBands(harmonicTrendCoefficients.select(‘cos’));\nMap.addLayer(anotherView,\n   {\n       min: -0.03,\n       max: 0.03   },   ‘Another combination of fit characteristics’);\n\n\nFig. F4.6.9 Two views of the harmonic fits for NDVI for the Modesto, California area\nThe upper image in Fig. F4.6.9 is a closer view of Fig. F4.6.8, showing an image that transforms the sine and cosine coefficient values, and incorporates information from the mean NDVI. The lower image draws the sine and cosine in the red and blue bands, and extracts the slope of the linear trend that you calculated earlier in the chapter, placing that in the green band. The two views of the fit are similarly structured in their spatial pattern—both show fields to the west and the city to the east. But the pixel-by-pixel variability emphasizes a key point of this chapter: that a fit to the NDVI data is done independently in each pixel in the image. Using different elements of the fit, these two views, like other combinations of the data you might imagine, can reveal the rich variability of the landscape around Modesto.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F46d. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#higher-order-harmonic-models",
    "href": "F4.html#higher-order-harmonic-models",
    "title": "5  Interpreting Image Series",
    "section": "12.6 Higher-Order Harmonic Models",
    "text": "12.6 Higher-Order Harmonic Models\nHarmonic models are not limited to fitting a single wave through a set of points. In some situations, there may be more than one cycle within a given year—for example, when an agricultural field is double-cropped. Modeling multiple waves within a given year can be done by adding more harmonic terms to Eq. F4.6.2. The code at the following checkpoint allows the fitting of any number of cycles through a given point.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F46e. The book’s repository contains a script to use to begin this section. You will need to start with that script and edit the code to produce the charts in this section.\n\n\nBeginning with the repository script, changing the value of the harmonics variable will change the complexity of the harmonic curve fit by superimposing more or fewer harmonic waves on each other. While fitting higher-order functions improves the goodness-of-fit of the model to a given set of data, many of the coefficients may be close to zero at higher numbers or harmonic terms. Fig. F4.6.10 shows the fit through the example point using one, two, and three harmonic curves.\n\n\n\nFig. F4.6.10 Fit with harmonic curves of increasing complexity, fitted for data at a given point"
  },
  {
    "objectID": "F4.html#synthesis-6",
    "href": "F4.html#synthesis-6",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. Fit two NDVI harmonic models for a point close to Manaus, Brazil: one prior to a disturbance event and one after the disturbance event (Fig. F4.6.11). You can start with the code checkpoint below, which gives you the point coordinates and defines the initial functions needed. The disturbance event happened in mid-December 2014, so set filter dates for the first ImageCollection to ‘2013-01-01’,‘2014-12-12’, and set the filter dates for the second ImageCollection to ‘2014-12-13’,‘2019-01-01’. Merge both fitted collections and plot both NDVI and fitted values. The result should look like Fig. F4.6.12.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F46s1. The book’s repository contains a script that shows what your code should look like at this point.\n\n\n\nFig. F4.6.11 Landsat 8 images showing the land cover change at a point in Manaus, Brazil; (left) July, 6, 2014, (right) August 8, 2015\n\nFig. F4.6.12 Fitted harmonic models before and after disturbance events to a given point in the Brazilian Amazon\nWhat do you notice? Think about how the harmonic model would look if you tried to fit the entire period. In this example, you were given the date of the breakpoint between the two conditions of the land surface within the time series. State-of-the-art land cover change algorithms work by assessing the difference between the modeled and observed pixel values. These algorithms look for breakpoints in the model, typically flagging changes after a predefined number of consecutive observations.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F46s2. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#conclusion-6",
    "href": "F4.html#conclusion-6",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, we learned how to graph and fit both linear and harmonic functions to time series of remotely sensed data. These skills underpin important tools such as Continuous Change Detection and Classification (CCDC, Chap. F4.7) and Continuous Degradation Detection (CODED, Chap. A3.4). These approaches are used by many organizations to detect forest degradation and deforestation (e.g., Tang et al. 2019, Bullock et al. 2020). These approaches can also be used to identify crops (Chap. A1.1) with high degrees of accuracy (Ghazaryan et al. 2018)."
  },
  {
    "objectID": "F4.html#references-5",
    "href": "F4.html#references-5",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nBradley BA, Jacob RW, Hermance JF, Mustard JF (2007) A curve fitting procedure to derive inter-annual phenologies from time series of noisy satellite NDVI data. Remote Sens Environ 106:137–145. https://doi.org/10.1016/j.rse.2006.08.002\nBullock EL, Woodcock CE, Olofsson P (2020) Monitoring tropical forest degradation using spectral unmixing and Landsat time series analysis. Remote Sens Environ 238:110968. https://doi.org/10.1016/j.rse.2018.11.011\nGhazaryan G, Dubovyk O, Löw F, et al (2018) A rule-based approach for crop identification using multi-temporal and multi-sensor phenological metrics. Eur J Remote Sens 51:511–524. https://doi.org/10.1080/22797254.2018.1455540\nShumway RH, Stoffer DS (2019) Time Series: A Data Analysis Approach Using R. Chapman and Hall/CRC\nTang X, Bullock EL, Olofsson P, et al (2019) Near real-time monitoring of tropical forest disturbance: New algorithms and assessment framework. Remote Sens Environ 224:202–218. https://doi.org/10.1016/j.rse.2019.02.003"
  },
  {
    "objectID": "F4.html#author-7",
    "href": "F4.html#author-7",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\n \nPaulo Arévalo, Pontus Olofsson"
  },
  {
    "objectID": "F4.html#overview-7",
    "href": "F4.html#overview-7",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\nContinuous Change Detection and Classification (CCDC) is a land change monitoring algorithm designed to operate on time series of satellite data, particularly Landsat data. This chapter focuses on the portion that is the change detection component (CCD); you will learn how to run the algorithm, interpret its outputs, and visualize coefficients and change information."
  },
  {
    "objectID": "F4.html#learning-outcomes-7",
    "href": "F4.html#learning-outcomes-7",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nExploring pixel-level time series of Landsat observations, as well as the temporal segments that CCDC fits to the observations.\nVisualizing the coefficients of the temporal segments in space.\nVisualizing predicted images made from detected temporal segments.\nVisualizing change information.\nUsing array image functions.\nAttaching user-defined metadata to an image when exporting."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-7",
    "href": "F4.html#assumes-you-know-how-to-7",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nPerform basic image analysis: select bands, compute indices, create masks (Part F2).\nVisualize images with a variety of false-color band combinations (Chap. F1.1).\nInterpret bands and indices in terms of land surface characteristics (Chap. F2.0).\nWork with array images (Chap. F3.1, Chap. F4.6).\nInterpret fitted harmonic models (Chap. F4.6)."
  },
  {
    "objectID": "F4.html#introduction-to-theory-6",
    "href": "F4.html#introduction-to-theory-6",
    "title": "5  Interpreting Image Series",
    "section": "13.1 Introduction to Theory ",
    "text": "13.1 Introduction to Theory \n“A time series is a sequence of observations taken sequentially in time. … An intrinsic feature of a time series is that, typically, adjacent observations are dependent. Time-series analysis is concerned with techniques for the analysis of this dependency.” This is the formal definition of time-series analysis by Box et al. (1994). In a remote sensing context, the observations of interest are measurements of radiation reflected from the surface of the Earth from the Sun or an instrument emitting energy toward Earth. Consecutive measurements made over a given area result in a time series of surface reflectance. By analyzing such time series, we can achieve a comprehensive characterization of ecosystem and land surface processes (Kennedy et al. 2014). The result is a shift away from traditional, retrospective change-detection approaches based on data acquired over the same area at two or a few points in time to continuous monitoring of the landscape (Woodcock et al. 2020). Previous obstacles related to data storage, preprocessing, and computing power have been largely overcome with the emergence of powerful cloud-computing platforms that provide direct access to the data (Gorelick et al. 2017). In this chapter, we will illustrate how to study landscape dynamics in the Amazon river basin by analyzing dense time series of Landsat data using the CCDC algorithm. Unlike LandTrendr (Chap. F4.5), which uses anniversary images to fit straight line segments that describe the spectral trajectory over time, CCDC uses all available clear observations. This has multiple advantages, including the ability to detect changes within a year and capture seasonal patterns, although at the expense of much higher computational demands and more complexity to manipulate the outputs, compared to LandTrendr."
  },
  {
    "objectID": "F4.html#understanding-temporal-segmentation-with-ccdc",
    "href": "F4.html#understanding-temporal-segmentation-with-ccdc",
    "title": "5  Interpreting Image Series",
    "section": "13.2 Understanding Temporal Segmentation with CCDC",
    "text": "13.2 Understanding Temporal Segmentation with CCDC\nSpectral change is detected at the pixel level by testing for structural breaks in a time series of reflectance. In Earth Engine, this process is referred to as “temporal segmentation,” as pixel-level time series are segmented according to periods of unique reflectance. It does so by fitting harmonic regression models to all spectral bands in the time series. The model-fitting starts at the beginning of the time series and moves forward in time in an “online” approach to change detection. The coefficients are used to predict future observations, and if the residuals of future observations exceed a statistical threshold for numerous consecutive observations, then the algorithm flags that a change has occurred. After the change, a new regression model is fit and the process continues until the end of the time series. The details of the original algorithm are described in Zhu and Woodcock (2014). We have created an interface-based tool (Arévalo et al. 2020) that facilitates the exploration of time series of Landsat observations and the CCDC results.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F47a. The book’s repository contains information about accessing the CCDC interface.\n\n\nOnce you have loaded the CCDC interface (Fig. F4.7.1), you will be able to navigate to any location, pick a Landsat spectral band or index to plot, and click on the map to see the fit by CCDC at the location you clicked. For this exercise, we will study landscape dynamics in the state of Rondônia, Brazil. We can use the panel on the left-bottom corner to enter the following coordinates (latitude, longitude): -9.0002, -62.7223. A point will be added in that location and the map will zoom in to it. Once there, click on the point and wait for the chart at the bottom to load. This example shows the Landsat time series for the first shortwave infrared (SWIR1) band (as blue dots) and the time segments (as colored lines) run using CCDC default parameters. The first segment represents stable forest, which was abruptly cut in mid-2006. The algorithm detects this change event and fits a new segment afterwards, representing a new temporal pattern of agriculture. Other subsequent patterns are detected as new segments are fitted that may correspond to cycles of harvest and regrowth, or a different crop. To investigate the dynamics over time, you can click on the points in the chart, and the Landsat images they correspond to will be added to the map according to the visualization parameters selected for the RGB combination in the left panel. Currently, changes made in that panel are not immediate but must be set before clicking on the map. \nPay special attention to the characteristics of each segment. For example, look at the average surface reflectance value for each segment. The presence of a pronounced slope may be indicative of phenomena like vegetation regrowth or degradation. The number of harmonics used in each segment may represent seasonality in vegetation (either natural or due to agricultural practices) or landscape dynamics (e.g., seasonal flooding).\n\nFig. 4.7.1 Landsat time series for the SWIR1 band (blue dots) and CCDC time segments (colored lines) showing a forest loss event circa 2006 for a place in Rondônia, Brazil\nQuestion 1. While still using the SWIR1 band, click on a pixel that is forested. What do the time series and time segments look like?"
  },
  {
    "objectID": "F4.html#running-ccdc",
    "href": "F4.html#running-ccdc",
    "title": "5  Interpreting Image Series",
    "section": "13.3 Running CCDC",
    "text": "13.3 Running CCDC\nThe tool shown above is useful for understanding the temporal dynamics for a specific point. However, we can do a similar analysis for larger areas by first running the CCDC algorithm over a group of pixels. The CCDC function in Earth Engine can take any ImageCollection, ideally one with little or no noise, such as a Landsat ImageCollection where clouds and cloud shadows have been masked. CCDC contains an internal cloud masking algorithm and is rather robust against missed clouds, but the cleaner the data the better. To simplify the process, we have developed a function library that contains functions for generating input data and processing CCDC results. Paste this line of code in a new script:\nvar utils = require(   ‘users/parevalo_bu/gee-ccdc-tools:ccdcUtilities/api’);\nFor the current exercise, we will obtain an ImageCollection of Landsat 4, 5, 7, and 8 data (Collection 2 Tier 1) that has been filtered for clouds, cloud shadows, haze, and radiometrically saturated pixels. If we were to do this manually, we would retrieve each ImageCollection for each satellite, apply the corresponding filters and then merge them all into a single ImageCollection. Instead, to simplify that process, we will use the function getLandsat, included in the “Inputs” module of our utilities, and then filter the resulting ImageCollection to a small study region for the period between 2000 and 2020. The getLandsat function will retrieve all surface reflectance bands (renamed and scaled to actual surface reflectance units) as well as other vegetation indices. To simplify the exercise, we will select only the surface reflectance bands we are going to use, adding the following code to your script:\nvar studyRegion = ee.Geometry.Rectangle([\n   [-63.9533, -10.1315],\n   [-64.9118, -10.6813]\n]);\n// Define start, end dates and Landsat bands to use.\nvar startDate = ‘2000-01-01’;\nvar endDate = ‘2020-01-01’;\nvar bands = [‘BLUE’, ‘GREEN’, ‘RED’, ‘NIR’, ‘SWIR1’, ‘SWIR2’];\n// Retrieve all clear, Landsat 4, 5, 7 and 8 observations (Collection 2, Tier 1).\nvar filteredLandsat = utils.Inputs.getLandsat({\n       collection: 2   })\n   .filterBounds(studyRegion)\n   .filterDate(startDate, endDate)\n   .select(bands);\nprint(filteredLandsat.first());\nWith the ImageCollection ready, we can specify the CCDC parameters and run the algorithm. For this exercise we will use the default parameters, which tend to work reasonably well in most circumstances. The only parameters we will modify are the breakpoint bands, date format, and lambda. We will set all the parameter values in a dictionary that we will pass to the CCDC function. For the break detection process we use all bands except for the blue and surface temperature bands (‘BLUE’ and ‘TEMP’, respectively). The minObservations default value of 6 represents the number of consecutive observations required to flag a change. The chiSquareProbability and minNumOfYearsScaler default parameters of 0.99 and 1.33, respectively, control the sensitivity of the algorithm to detect change and the iterative curve fitting process required to detect change. We set the date format to 1, which corresponds to fractional years and tends to be easier to interpret. For instance, a change detected in the middle day of the year 2010 would be stored in a pixel as 2010.5. Finally, we use the default value of lambda of 20, but we scale it to match the scale of the inputs (surface reflectance units), and we specify a maxIterations value of 10000, instead of the default of 25000, which might take longer to complete. Those two parameters control the curve fitting process.\nTo complete the input parameters, we specify the ImageCollection to use, which we derived in the previous code section. Add this code below:\n// Set CCD params to use.\nvar ccdParams = {\n   breakpointBands: [‘GREEN’, ‘RED’, ‘NIR’, ‘SWIR1’, ‘SWIR2’],\n   tmaskBands: [‘GREEN’, ‘SWIR2’],\n   minObservations: 6,\n   chiSquareProbability: 0.99,\n   minNumOfYearsScaler: 1.33,\n   dateFormat: 1,\n   lambda: 0.002,\n   maxIterations: 10000,\n   collection: filteredLandsat\n};\n// Run CCD.\nvar ccdResults = ee.Algorithms.TemporalSegmentation.Ccdc(ccdParams);\nprint(ccdResults);\nNotice that the output ccdResults contains a large number of bands, with some of them corresponding to two-dimensional arrays. We will explore these bands more in the following section. The process of running the algorithm interactively for more than a handful of pixels can become very taxing to the system very quickly, resulting in memory errors. To avoid having such issues, we typically export the results to an Earth Engine asset first, and then inspect the asset. This approach ensures that CCDC completes its run successfully, and also allows us to access the results easily later. In the following sections of this chapter, we will use a precomputed asset, instead of asking you to export the asset yourself. For your reference, the code required to export CCDC results is shown below, with the flag set to false to help you remember to not export the results now, but instead to use the precomputed asset in the following sections.\nvar exportResults = false\nif (exportResults) {   // Create a metadata dictionary with the parameters and arguments used.   var metadata = ccdParams;\n   metadata[‘breakpointBands’] =\n       metadata[‘breakpointBands’].toString();\n   metadata[‘tmaskBands’] = metadata[‘tmaskBands’].toString();\n   metadata[‘startDate’] = startDate;\n   metadata[‘endDate’] = endDate;\n   metadata[‘bands’] = bands.toString();   // Export results, assigning the metadata as image properties.   //   Export.image.toAsset({\n       image: ccdResults.set(metadata),\n       region: studyRegion,\n       pyramidingPolicy: {           “.default”: ‘sample’       },\n       scale: 30   });\n}\nNote the metadata variable above. This is not strictly required for exporting the per-pixel CCDC results, but it allows us to keep a record of important properties of the run by attaching this information as metadata to the image. Additionally, some of the tools we have created to interact with CCDC outputs use this user-created metadata to facilitate using the asset. Note also that setting the value of pyramidingPolicy to ‘sample’ ensures that all the bands in the output have the proper policy.\nAs a general rule, try to use pre-existing CCDC results if possible, and if you want to try running it yourself outside of this lab exercise, start with very small areas. For instance, the study area in this exercise would take approximately 30 minutes on average to export, but larger tiles may take several hours to complete, depending on the number of images in the collection and the parameters used.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F47b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#extracting-break-information",
    "href": "F4.html#extracting-break-information",
    "title": "5  Interpreting Image Series",
    "section": "13.4 Extracting Break Information",
    "text": "13.4 Extracting Break Information\nWe will now start exploring the pre-exported CCDC results mentioned in the previous section. We will make use of the third-party module palettes, described in detail in Chap. F6.0, that simplifies the use of palettes for visualization. Paste the following code in a new script:\nvar palettes = require(‘users/gena/packages:palettes’);\nvar resultsPath =   ‘projects/gee-book/assets/F4-7/Rondonia_example_small’;\nvar ccdResults = ee.Image(resultsPath);\nMap.centerObject(ccdResults, 10);\nprint(ccdResults);\nThe first line calls a library that will facilitate visualizing the images. The second line contains the path to the precomputed results of the CCDC run shown in the previous section. The printed asset will contain the following bands:\n\ntStart: The start date of each time segment\ntEnd: The end date of each time segment\ntBreak: The time segment break date if a change is detected\nnumObs: The number of observations used in each time segment\nchangeProb: A numeric value representing the change probability for each of the bands used for change detection\n*_coefs: The regression coefficients for each of the bands in the input image collection\n*_rmse: The model root-mean-square error for each time segment and input band\n*_magnitude: For time segments with detected changes, this represents the normalized residuals during the change period\n\nNotice that next to the band name and band type, there is also the number of dimensions (i.e., 1 dimension, 2 dimensions). This is an indication that we are dealing with an array image, which typically requires a specific set of functions for proper manipulation, some of which we will use in the next steps. We will start by looking at the change bands, which are one of the key outputs of the CCDC algorithm. We will select the band containing the information on the timing of break, and find the number of breaks for a given time range. In the same script, paste the code below:\n// Select time of break and change probability array images.\nvar change = ccdResults.select(‘tBreak’);\nvar changeProb = ccdResults.select(‘changeProb’);\n// Set the time range we want to use and get as mask of\n// places that meet the condition.\nvar start = 2000;\nvar end = 2021;\nvar mask = change.gt(start).and(change.lte(end)).and(changeProb.eq(\n1));\nMap.addLayer(changeProb, {}, ‘change prob’);\n// Obtain the number of breaks for the time range.\nvar numBreaks = mask.arrayReduce(ee.Reducer.sum(), [0]);\nMap.addLayer(numBreaks, {\n   min: 0,\n   max: 5}, ‘Number of breaks’);\nWith this code, we define the time range that we want to use, and then we generate a mask that will indicate all the positions in the image array with breaks detected in that range that also meet the condition of having a change probability of 1, effectively removing some spurious breaks. For each pixel, we can count the number of times that the mask retrieved a valid result, indicating the number of breaks detected by CCDC. In the loaded layer, places that appear brighter will show a higher number of breaks, potentially indicating the conversion from forest to agriculture, followed by multiple agricultural cycles. Keep in mind that the detection of a break does not always imply a change of land cover. Natural events, small-scale disturbances and seasonal cycles, among others, can result in the detection of a break by CCDC. Similarly, changes in the condition of the land cover in a pixel can also be detected as breaks by CCDC, and some erroneous breaks can also happen due to noisy time series or other factors.\nFor places with many changes, visualizing the first or last time when a break was recorded can be helpful to understand the change dynamics happening in the landscape. Paste the code below in the same script:\n// Obtain the first change in that time period.\nvar dates = change.arrayMask(mask).arrayPad([1]);\nvar firstChange = dates\n   .arraySlice(0, 0, 1)\n   .arrayFlatten([\n       [‘firstChange’]\n   ])\n   .selfMask();\nvar timeVisParams = {\n   palette: palettes.colorbrewer.YlOrRd[9],\n   min: start,\n   max: end\n};\nMap.addLayer(firstChange, timeVisParams, ‘First change’);\n// Obtain the last change in that time period.\nvar lastChange = dates\n   .arraySlice(0, -1)\n   .arrayFlatten([\n       [‘lastChange’]\n   ])\n   .selfMask();\nMap.addLayer(lastChange, timeVisParams, ‘Last change’);\nHere we use arrayMask to keep only the change dates that meet our condition, by using the mask we created previously. We use the function arrayPad to fill or “pad” those pixels that did not experience any change and therefore have no value in the tBreak band. Then we select either the first or last values in the array, and we convert the image from a one-dimensional array to a regular image, in order to apply a visualization to it, using a custom palette. The results should look like Fig. F4.7.2.\nFinally, we can use the magnitude bands to visualize where and when the largest changes as recorded by CCDC have occurred, during our selected time period. We are going to use the magnitude of change in the SWIR1 band, masking it and padding it in the same way we did before. Paste this code in your script:\n// Get masked magnitudes.\nvar magnitudes = ccdResults\n   .select(‘SWIR1_magnitude’)\n   .arrayMask(mask)\n   .arrayPad([1]);\n// Get index of max abs magnitude of change.\nvar maxIndex = magnitudes\n   .abs()\n   .arrayArgmax()\n   .arrayFlatten([\n       [‘index’]\n   ]);\n// Select max magnitude and its timing\nvar selectedMag = magnitudes.arrayGet(maxIndex);\nvar selectedTbreak = dates.arrayGet(maxIndex).selfMask();\nvar magVisParams = {\n   palette: palettes.matplotlib.viridis[7],\n   min: -0.15,\n   max: 0.15\n};\nMap.addLayer(selectedMag, magVisParams, ‘Max mag’);\nMap.addLayer(selectedTbreak, timeVisParams, ‘Time of max mag’);\n\n\nFig. F4.7.2 First (top) and last (bottom) detected breaks for the study area. Darker colors represent more recent dates, while brighter colors represent older dates. The first change layer shows the clear patterns of original agricultural expansion closer to the year 2000. The last change layer shows the more recently detected and noisy breaks in the same areas. The thin areas in the center of the image have only one time of change, corresponding to a single deforestation event. Pixels with no detected breaks are masked and therefore show the basemap underneath, set to show satellite imagery.\nWe first take the absolute value because the magnitudes can be positive or negative, depending on the direction of the change and the band used. For example, a positive value in the SWIR1 may show a forest loss event, where surface reflectance goes from low to higher values. Brighter values in Fig. 4.7.3 represent events of that type. Conversely, a flooding event would have a negative value, due to the corresponding drop in reflectance. Once we find the maximum absolute value, we find its position on the array and then use that index to extract the original magnitude value, as well as the time when that break occurred.\n\nFig. F4.7.3 Maximum magnitude of change for the SWIR1 band for the selected study period\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F47c. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nQuestion 2. Compare the “first change” and “last change” layers with the layer showing the timing of the maximum magnitude of change. Use the Inspector to check the values for specific pixels if necessary. What does the timing of the layers tell you about the change processes happening in the area?\nQuestion 3. Looking at the “max magnitude of change” layer, find places showing the largest and the smallest values. What type of changes do you think are happening in each of those places?"
  },
  {
    "objectID": "F4.html#extracting-coefficients-manually",
    "href": "F4.html#extracting-coefficients-manually",
    "title": "5  Interpreting Image Series",
    "section": "13.5 Extracting Coefficients Manually",
    "text": "13.5 Extracting Coefficients Manually\nIn addition to the change information generated by the CCDC algorithm, we can use the coefficients of the time segments for multiple purposes, like land cover classification. Each time segment can be described as a harmonic function with an intercept, slope, and three pairs of sine and cosine terms that allow the time segments to represent seasonality occurring at different temporal scales. These coefficients, as well as the root-mean-square error (RMSE) obtained by comparing each predicted and actual Landsat value, are produced when the CCDC algorithm is run. The following example will show you how to retrieve the intercept coefficient for a segment intersecting a specific date. In a new script, paste the code below:\nvar palettes = require(‘users/gena/packages:palettes’);\nvar resultsPath =   ‘projects/gee-book/assets/F4-7/Rondonia_example_small’;\nvar ccdResults = ee.Image(resultsPath);\nMap.centerObject(ccdResults, 10);\nprint(ccdResults);\n// Display segment start and end times.\nvar start = ccdResults.select(‘tStart’);\nvar end = ccdResults.select(‘tEnd’);\nMap.addLayer(start, {\n   min: 1999,\n   max: 2001}, ‘Segment start’);\nMap.addLayer(end, {\n   min: 2010,\n   max: 2020}, ‘Segment end’);\nCheck the Console and expand the bands section in the printed image information. We will be using the tStart, tEnd, and SWIR1_coefs bands, which are array images containing the date when the time segments start, date time segments end, and the coefficients for each of those segments for the SWIR1 band. Run the code above and switch the map to Satellite mode. Using the Inspector, click anywhere on the images, noticing the number of dates printed and their values for multiple clicked pixels. You will notice that for places with stable forest cover, there is usually one value for tStart and one for tEnd. This means that for those more stable places, only one time segment was fit by CCDC. On the other hand, for places with visible transformation in the basemap, the number of dates is usually two or three, meaning that the algorithm fitted two or three time segments, respectively. To simplify the processing of the data, we can select a single segment to extract its coefficients. Paste the code below and re-run the script:\n// Find the segment that intersects a given date.\nvar targetDate = 2005.5;\nvar selectSegment = start.lte(targetDate).and(end.gt(targetDate));\nMap.addLayer(selectSegment, {}, ‘Identified segment’);\nIn the code above, we set a time of interest, in this case the middle of 2005, and then we find the segments that meet the condition of starting before and ending after that date. Using the Inspector again, click on different locations and verify the outputs. The segment that meets the condition will have a value of 1, and the other segments will have a value of 0. We can use this information to select the coefficients for that segment, using the code below:\n// Get all coefs in the SWIR1 band.\nvar SWIR1Coefs = ccdResults.select(‘SWIR1_coefs’);\nMap.addLayer(SWIR1Coefs, {}, ‘SWIR1 coefs’);\n// Select only those for the segment that we identified previously.\nvar sliceStart = selectSegment.arrayArgmax().arrayFlatten([\n   [‘index’]\n]);\nvar sliceEnd = sliceStart.add(1);\nvar selectedCoefs = SWIR1Coefs.arraySlice(0, sliceStart, sliceEnd);\nMap.addLayer(selectedCoefs, {}, ‘Selected SWIR1 coefs’);\nIn the piece of code above, we first select the array image with the coefficients for the SWIR1 band. Then, using the layer that we created before, we find the position where the condition is true, and use that to extract the coefficients only for that segment. Once again, you can verify that using the Inspector tab.\nFinally, what we have now is the full set of coefficients for the segment that intersects the midpoint of 2005. The coefficients are in the following order: intercept, slope, cosine 1, sine 1, cosine 2, sine 2, cosine 3, and sine 3. For this exercise we will extract the intercept coefficient (Fig. 4.7.4), which is the first element in the array, using the code below:\n// Retrieve only the intercept coefficient.\nvar intercept = selectedCoefs.arraySlice(1, 0, 1).arrayProject([1]);\nvar intVisParams = {\n   palette: palettes.matplotlib.viridis[7],\n   min: -6,\n   max: 6\n};\nMap.addLayer(intercept.arrayFlatten([\n   [‘INTP’]\n]), intVisParams, ‘INTP_SWIR1’);\n\nFig. F4.7.4 Values for the intercept coefficient of the segments that start before and end after the midpoint of 2005\nSince we run the CCDC algorithm on Landsat surface reflectance images, intercept values should represent the average reflectance of a segment. However, if you click on the image, you will see that the values are outside of the 0–1 range. This is because the intercept is calculated by the CCDC algorithm for the origin (e.g., time 0), and not for the year we requested. In order to retrieve the adjusted intercept, as well as other coefficients, we will use a different approach.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F47d. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nSection 5. Extracting Coefficients Using External Functions\nThe code we generated in the previous section allowed us to extract a single coefficient for a single date. However, we typically want to extract a set of multiple coefficients and bands that we can use as inputs to other workflows, such as classification. To simplify that process, we will use the same function library that we saw in Sect. 2. In this section we will extract and visualize different coefficients for a single date and produce an RGB image using the intercept coefficients for multiple spectral bands for the same date. The first step involves determining the date of interest and converting the CCDC results from array images to regular multiband images for easier manipulation and faster display. In a new script, copy the code below:\n// Load the required libraries.\nvar palettes = require(‘users/gena/packages:palettes’);\nvar utils = require(   ‘users/parevalo_bu/gee-ccdc-tools:ccdcUtilities/api’);\n// Load the results.\nvar resultsPath =   ‘projects/gee-book/assets/F4-7/Rondonia_example_small’;\nvar ccdResults = ee.Image(resultsPath);\nMap.centerObject(ccdResults, 10);\n// Convert a date into fractional years.\nvar inputDate = ‘2005-09-25’;\nvar dateParams = {\n   inputFormat: 3,\n   inputDate: inputDate,\n   outputFormat: 1\n};\nvar formattedDate = utils.Dates.convertDate(dateParams);\n// Band names originally used as inputs to the CCD algorithm.\nvar BANDS = [‘BLUE’, ‘GREEN’, ‘RED’, ‘NIR’, ‘SWIR1’, ‘SWIR2’];\n// Names for the time segments to retrieve.\nvar SEGS = [‘S1’, ‘S2’, ‘S3’, ‘S4’, ‘S5’, ‘S6’, ‘S7’, ‘S8’, ‘S9’,   ‘S10’\n];\n// Transform CCD results into a multiband image.\nvar ccdImage = utils.CCDC.buildCcdImage(ccdResults, SEGS.length,\n   BANDS);\nprint(ccdImage);\nIn the code above we define the date of interest (2005-09-25) and convert it to the date format in which we ran CCDC, which corresponds to fractional years. After that, we specify the band that we used as inputs for the CCDC algorithm. Finally, we specify the names we will assign to the time segments, with the list length indicating the maximum number of time segments to retrieve per pixel. This step is done because the results generated by CCDC are stored as variable-length arrays. For example, a pixel where there are no breaks detected will have one time segment, but another pixel where a single break was detected may have one or two segments, depending on when the break occurred. Requesting a pre-defined maximum number of segments ensures that the structure of the multi-band image is known, and greatly facilitates its manipulation and display. Once we have set these variables, we call a function that converts the result into an image with several bands representing the combination of segments requested, input bands, and coefficients. You can see the image structure in the Console.\nFinally, to extract a subset of coefficients for the desired bands, we can use a function in the imported library, called getMultiCoefs. This function expects the following ordered parameters:\n\nThe CCDC results in the multiband format we just generated in the step above.\nThe date for which we want to extract the coefficients, in the format in which the CCDC results were run (fractional years in our case).\nList of the bands to retrieve (i.e., spectral bands).\nList of coefficients to retrieve, defined as follows: INTP (intercept), SLP (slope), COS, SIN,COS32, SIN2, COS3, SIN3, and RMSE.\nA Boolean flag of true or false, indicating whether we want the intercepts to be calculated for the input date, instead of being calculated at the origin. If true, SLP must be included in the list of coefficients to retrieve.\nList of segment names, as used to create the multiband image in the prior step.\nBehavior to apply if there is no time segment for the requested date: normal will retrieve a value only if the date intersects a segment;        before or after will use the value of the segment immediately before or after the requested date, if no segment intersects the date directly.\n\n// Define bands to select.\nvar SELECT_BANDS = [‘RED’, ‘GREEN’, ‘BLUE’, ‘NIR’];\n// Define coefficients to select.\n// This list contains all possible coefficients, and the RMSE\nvar SELECT_COEFS = [‘INTP’, ‘SLP’, ‘RMSE’];\n// Obtain coefficients.\nvar coefs = utils.CCDC.getMultiCoefs(\n   ccdImage, formattedDate, SELECT_BANDS, SELECT_COEFS, true,\n   SEGS, ‘after’);\nprint(coefs);\n// Show a single coefficient.\nvar slpVisParams = {\n   palette: palettes.matplotlib.viridis[7],\n   min: -0.0005,\n   max: 0.005\n};\nMap.addLayer(coefs.select(‘RED_SLP’), slpVisParams,   ‘RED SLOPE 2005-09-25’);\nvar rmseVisParams = {\n   palette: palettes.matplotlib.viridis[7],\n   min: 0,\n   max: 0.1\n};\nMap.addLayer(coefs.select(‘NIR_RMSE’), rmseVisParams,   ‘NIR RMSE 2005-09-25’);\n// Show an RGB with three coefficients.\nvar rgbVisParams = {\n   bands: [‘RED_INTP’, ‘GREEN_INTP’, ‘BLUE_INTP’],\n   min: 0,\n   max: 0.1\n};\nMap.addLayer(coefs, rgbVisParams, ‘RGB 2005-09-25’);\nThe slope and RMSE images are shown in Fig. 4.7.5. For the slopes, high positive values are bright, while large negative values are very dark. Most of the remaining forest is stable and has a slope close to zero, while areas that have experienced transformation and show agricultural activity tend to have positive slopes in the RED band, appearing bright in the image. Similarly, for the RMSE image, stable forests present more predictable time series of surface reflectance that are captured more faithfully by the time segments, and therefore present lower RMSE values, appearing darker in the image. Agricultural areas present noisier time series that are more challenging to model, and result in higher RMSE values, appearing brighter.\n\n\nFig. F4.7.5 Image showing the slopes (top) and RMSE (bottom) of the segments that intersect the requested date\nFinally, the RGB image we created is shown in Fig. 4.7.6. The intercepts are calculated for the middle point of the time segment intercepting the date we requested, representing the average reflectance for the span of the selected segment. In that sense, when shown together as an RGB image, they are similar to a composite image for the selected date, with the advantage of always being cloud-free.\n\nFig. F4.7.6 RGB image created using the time segment intercepts for the requested date\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F47e. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#synthesis-7",
    "href": "F4.html#synthesis-7",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. Use the time series from the first section of this chapter to explore the time series and time segments produced by CCDC in many locations around the world. Compare places with different land cover types, and places with more stable dynamics (e.g., lakes, primary forests) vs. highly dynamic places (e.g., agricultural lands, construction sites). Pay attention to the variability in data density across continents and latitudes, and the effect that data density has on the appearance of the time segments. Use different spectral bands and indices and notice how they capture the temporal dynamics you are observing.\nAssignment 2. Pick three periods within the temporal study period of the CCDC results we used earlier: one near to the start, another in the middle, and the third close to the end. For each period, visualize the maximum change magnitude. Compare the spatial patterns between periods, and reflect on the types of disturbances that might be happening at each stage.\nAssignment 3. Select the intercept coefficients of the middle date of each of the periods you chose in the previous assignment. For each of those dates, load an RGB image with the band combination of your choosing (or simply use the Red, Green and Blue intercepts to obtain true-color images). Using the Inspector tab, compare the values across images in places with subtle and large differences between them, as well as in areas that do not change. What do the values tell you in terms of the benefits of using CCDC to study changes in a landscape?"
  },
  {
    "objectID": "F4.html#conclusion-7",
    "href": "F4.html#conclusion-7",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nThis chapter provided a guide for the interpretation of the results from the CCDC algorithm for studying deforestation in the Amazon. Consider the advantages of such an analysis compared to traditional approaches to change detection, which are typically based on the comparison of two or a few images collected over the same area. For example, with time-series analysis, we can study trends and subtle processes such as vegetation recovery or degradation, determine the timing of land-surface events, and move away from retrospective analyses to monitoring in near-real time. Through the use of all available clear observations, CCDC can detect intra-annual breaks and capture seasonal patterns, although at the expense of increased computational requirements and complexity, unlike faster and easier to interpret methods based on annual composites, such as LandTrendr (Chap. F4.5). We expect to see more applications that make use of multiple change detection approaches (also known as “Ensemble” approaches), and multisensor analyses in which data from different satellites are fused (radar and optical, for example) for higher data density."
  },
  {
    "objectID": "F4.html#references-6",
    "href": "F4.html#references-6",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nArévalo P, Bullock EL, Woodcock CE, Olofsson P (2020) A suite of tools for continuous land change monitoring in Google Earth Engine. Front Clim 2. https://doi.org/10.3389/fclim.2020.576740\nBox GEP, Jenkins GM, Reinsel GC (1994) Time Series Analysis: Forecasting and Control. Prentice Hall\nGorelick N, Hancher M, Dixon M, et al (2017) Google Earth Engine: Planetary-scale geospatial analysis for everyone. Remote Sens Environ 202:18–27. https://doi.org/10.1016/j.rse.2017.06.031\nKennedy RE, Andréfouët S, Cohen WB, et al (2014) Bringing an ecological view of change to Landsat-based remote sensing. Front Ecol Environ 12:339–346. https://doi.org/10.1890/130066\nWoodcock CE, Loveland TR, Herold M, Bauer ME (2020) Transitioning from change detection to monitoring with remote sensing: A paradigm shift. Remote Sens Environ 238:111558. https://doi.org/10.1016/j.rse.2019.111558\nZhu Z, Woodcock CE (2014) Continuous change detection and classification of land cover using all available Landsat data. Remote Sens Environ 144:152–171. https://doi.org/10.1016/j.rse.2014.01.011"
  },
  {
    "objectID": "F4.html#author-8",
    "href": "F4.html#author-8",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\nJeffrey A. Cardille, Rylan Boothman, Mary Villamor, Elijah Perez, Eidan Willis, Flavie Pelletier"
  },
  {
    "objectID": "F4.html#overview-8",
    "href": "F4.html#overview-8",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\n \nAs the ability to rapidly produce classifications of satellite images grows, it will be increasingly important to have algorithms that can sift through them to separate the signal from inevitable classification noise. The purpose of this chapter is to explore how to update classification time series by blending information from multiple classifications made from a wide variety of data sources. In this lab, we will explore how to update the classification time series of the Roosevelt River found in Fortin et al. (2020). That time series began with the 1972 launch of Landsat 1, blending evidence from 10 sensors and more than 140 images to show the evolution of the area until 2016. How has it changed since 2016? What new tools and data streams might we tap to understand the land surface through time?"
  },
  {
    "objectID": "F4.html#learning-outcomes-8",
    "href": "F4.html#learning-outcomes-8",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nDistinguishing between merging sensor data and merging classifications made from sensors.\nWorking with the Bayesian Updating of Land Cover (BULC) algorithm, in its basic form, to blend classifications made across multiple years and sensors.\nWorking with the BULC-D algorithm to highlight locations that changed."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-8",
    "href": "F4.html#assumes-you-know-how-to-8",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nPerform basic image analysis: select bands, compute indices, create masks, classify images (Part F2).\n​​Create a graph using ui.Chart (Chap. F1.3).\nObtain accuracy metrics from classifications (Chap. F2.2)."
  },
  {
    "objectID": "F4.html#introduction-to-theory-7",
    "href": "F4.html#introduction-to-theory-7",
    "title": "5  Interpreting Image Series",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nWhen working with multiple sensors, we are often presented with a challenge: What to do with classification noise? It’s almost impossible to remove all noise from a classification. Given the information contained in a stream of classifications, however, you should be able to use the temporal context to distinguish noise from true changes in the landscape.\nThe Bayesian Updating of Land Cover (BULC) algorithm (Cardille and Fortin 2016) is designed to extract the signal from the noise in a stream of classifications made from any number of data sources. BULC’s principal job is to estimate, at each time step, the likeliest state of land use and land cover (LULC) in a study area given the accumulated evidence to that point. It takes a stack of provisional classifications as input; in keeping with the terminology of Bayesian statistics, these are referred to as “Events,” because they provide new evidence to the system. BULC then returns a stack of classifications as output that represents the estimated LULC time series implied by the Events. \nBULC estimates, at each time step, the most likely class from a set given the evidence up to that point in time. This is done by employing an accuracy assessment matrix like that seen in Chap. F2.2. At each time step, the algorithm quantifies the agreement between two classifications adjacent in time within a time series.\nIf the Events agree strongly, they are evidence of the true condition of the landscape at that point in time. If two adjacent Events disagree, the accuracy assessment matrix limits their power to change the class of a pixel in the interpreted time series. As each new classification is processed, BULC judges the credibility of a pixel’s stated class and keeps track of a set of estimates of the probability of each class for each pixel. In this way, each pixel traces its own LULC history, reflected through BULC’s judgment of the confidence in each of the classifications. The specific mechanics and formulas of BULC are detailed in Cardille and Fortin (2016).\nBULC’s code is written in JavaScript, with modules that weigh evidence for and against change in several ways, while recording parts of the data-weighing process for you to inspect. In this lab, we will explore BULC through its graphical user interface (GUI), which allows rapid interaction with the algorithm’s main functionality."
  },
  {
    "objectID": "F4.html#imagery-and-classifications-of-the-roosevelt-river",
    "href": "F4.html#imagery-and-classifications-of-the-roosevelt-river",
    "title": "5  Interpreting Image Series",
    "section": "14.1 Imagery and Classifications of the Roosevelt River",
    "text": "14.1 Imagery and Classifications of the Roosevelt River\nHow has the Roosevelt River area changed in recent decades? One way to view the area’s recent history is to use Google Earth Timelapse, which shows selected annual clear images of every part of Earth’s terrestrial surface since the 1980s. (You can find the site quickly with a web search.) Enter “Roosevelt River, Brazil” in the search field. For centuries, this area was very remote from agricultural development. It was so little known to Westerners that when former US President Theodore Roosevelt traversed it in the early 1900s there was widespread doubt about whether his near-death experience there was exaggerated or even entirely fictional (Millard 2006). After World War II, the region saw increased agricultural development. Fortin et al. (2020) traced four decades of the history of this region with satellite imagery. Timelapse, meanwhile, indicates that land cover conversion continued after 2016. Can we track it using Earth Engine?\nIn this section, we will view the classification inputs to BULC, which were made separately from this lab exercise by identifying training points and classifying them using Earth Engine’s regression tree capability. As seen in Table 4.8.1, the classification inputs included Sentinel-2 optical data, Landsat 7, Landsat 8, and the Advanced Spaceborne Thermal Emission and Reflection Radiometer (ASTER) aboard Terra. Though each classification was made with care, they each contain noise, with each pixel likely to have been misclassified one or more times. This could lead us to draw unrealistic conclusions if the classifications themselves were considered as a time series. For example, we would judge it highly unlikely that an area represented by a pixel would really be agriculture one day and revert to intact forest later in the month, only to be converted to agriculture again soon after, and so on. With careful (though unavoidably imperfect) classifications, we would expect that an area that had truly been converted to agriculture would consistently be classified as agriculture, while an area that remained as forest would be classified as that class most of the time. BULC’s logic is to detect that persistence, extracting the true LULC change and stability from the noisy signal of the time series of classifications.\nTable F4.8.1 Images classified for updating Roosevelt River LULC with BULC\nSensor\nDate\nSpatial resolution\nSentinel-2\n2016: February 8\n2017: July 7\n2018: May 28\n2019: June 17, June 17\n2020: May 27, May 27\n2021: May 27, July 11, August 15\n10m\nLandsat 7\n2017: August 16\n30m\nLandsat 8\n2021: July 18\n30m\nASTER\n2017: July 15\n2018: August 19\n2019: June 19\n2020: August 8\n15m–30m\nAs you have seen in earlier chapters, creating classifications can be very involved and time consuming. To allow you to concentrate on BULC’s efforts to clean noise from an existing ImageCollection, we have created the classifications already and stored them as an ImageCollection asset. You can view the Event time series using the ui.Thumbnail function, which creates an animation of the elements of the collection​​​​. Paste the code below into a new script to see those classifications drawn in sequence in the Console.\nvar events = ee.ImageCollection(   ‘projects/gee-book/assets/F4-8/cleanEvents’);\nprint(events, ‘List of Events’);\nprint(‘Number of events:’, events.size());\nprint(ui.Thumbnail(events, {\n   min: 0,\n   max: 3,\n   palette: [‘black’, ‘green’, ‘blue’, ‘yellow’],\n   framesPerSecond: 1,\n   dimensions: 1000\n}));\nIn the thumbnail sequence, the color palette shows Forest (class 1) as green, Water (class 2) as blue, and Active Agriculture (class 3) as yellow. Areas with no data in a particular Event are shown in black.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F48a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#basics-of-the-bulc-interface",
    "href": "F4.html#basics-of-the-bulc-interface",
    "title": "5  Interpreting Image Series",
    "section": "14.2 Basics of the BULC Interface",
    "text": "14.2 Basics of the BULC Interface\nTo see if BULC can successfully sift through these Events, we will use BULC’s GUI (Fig. F4.8.1), which makes interacting with the functionality straightforward. ::: {.callout-note} Code Checkpoint F48b in the book’s repository contains information about accessing that interface."
  },
  {
    "objectID": "F4.html#detailed-lulc-inspection-with-bulc",
    "href": "F4.html#detailed-lulc-inspection-with-bulc",
    "title": "5  Interpreting Image Series",
    "section": "14.3 Detailed LULC Inspection with BULC",
    "text": "14.3 Detailed LULC Inspection with BULC\nBULC results can be viewed interactively, allowing you to view more detailed estimations of the LULC around the study area. We will zoom into a specific area where change did occur after 2016. To do that, turn on the Satellite view and zoom in. Watching the scale bar in the lower right of the Map panel, continue zooming until the scale bar says 5 km. Then, enter “-60.742, -9.844” in the Earth Engine search tool, located above the code. The text will be interpreted as a longitude/latitude value and will offer you a nearby coordinate, indicated with a value for the degrees West and the degrees South. Click that entry and Earth Engine will move to that location, while keeping at the specified zoom level. Let’s compare the BULC result in this sector against the image from Earth Engine’s satellite view that is underneath it (Fig. 4.8.4).\n \n\nFig. 4.8.4 Comparison of the final classification of the northern part of the study area to the satellite view\nBULC captured the changes between 2016 and 2021 with a classification series that suggests agricultural development (Fig. 4.8.4, left). Given the appearance of BULC’s 2021 classification, it suggests that the satellite backdrop at the time of this writing (Fig. 4.8.4, right) came from an earlier time period.\nNow, in the Results panel, select BULC, then Movie. Set your desired frame speed and resolution, then select Redraw Thumbnail. Then, zoom the main Map even closer to some agriculture that appears to have been established between 2016 and 2021. Redraw the thumbnail movie as needed to find an interesting set of pixels.\nWith this finer-scale access to the results of BULC, you can select individual pixels to inspect. Move the horizontal divider downward to expose the Inspector tab and Console tab. Use the Inspector to click on several pixels to learn their history as expressed in the inputted Events and in BULC’s interpretation of the noise and signal in the Event series. In a chosen pixel, you might see output that looks like Fig. 4.8.5. It indicates a possible conversion in the Event time series after a few classifications of the pixel as Forest. This decreases the confidence that the pixel is still Forest (Fig. 4.8.5, lower panel), but not enough for the Active Agriculture class (class 3) to become the dominant probability. After the subsequent Event labels the pixel as Forest, the confidence (lower panel) recovers slightly, but not to its former level. The next Event classifies the pixel as Active Agriculture, confidently, by interpreting that second Active Agriculture classification, in a setting where change was already somewhat suspected after the first non-Forest classification. BULC’s label (middle panel) changes to be Active Agriculture at that point in the sequence. Subsequent Event classifications as Active Agriculture creates a growing confidence that its proper label at the end of the sequence was indeed Active Agriculture.\n\nFig. 4.8.5 History for 2016-2020 for a pixel that appeared to have been newly cultivated during that period. (above): the input classifications, which s\nQuestion 3. Run the code again with the same data, but adjust the three levelers, then view the results presented in the Map window and the Results panel. How do each of the three parameters affect the behavior of BULC in its results? Use the thumbnail to assess your subjective satisfaction with the results, and use the Inspector to view the BULC behavior in individual pixels. Can you produce an optimal outcome for this given set of input classifications?"
  },
  {
    "objectID": "F4.html#change-detection-with-bulc-d",
    "href": "F4.html#change-detection-with-bulc-d",
    "title": "5  Interpreting Image Series",
    "section": "14.4 Change Detection with BULC-D",
    "text": "14.4 Change Detection with BULC-D\nWhat if we wanted to identify areas of likely change or stability without trying to identify the initial and final LULC class? BULC-D is an algorithm that estimates, at each time step, the probability of noteworthy change. The example below uses the Normalized Burn Ratio (NBR) as a gauge: BULC-D assesses whether the ratio has meaningfully increased, decreased, or remained the same. It is then the choice of the analyst to decide how to treat these assessed probabilities of stability and change.\nBULC-D involves determining an expectation for an index across a user-specified time period and then comparing new values against that estimation. Using Bayesian logic, BULC-D then asks which of three hypotheses is most likely, given evidence from the new values to date from that index. The hypotheses are simple: Either the value has decreased meaningfully, or it has increased meaningfully, or it has not changed substantially compared to the previously established expectation. The details of the workings of BULC-D are beyond the scope of this exercise, but we provide it as a tool for exploration. BULC-D’s basic framework is the following:\n\nEstablish: Fit a harmonic curve with a user-specified number of terms to a stream of values from an index, such as the Normalized Difference Vegetation Index (NDVI), NBR, etc.\nStandardize: For each new image, quantify the deviation of the index’s value from the expectation on that date.\nContextualize: Assess the magnitude of that deviation in one of several ordered bins.\nSynthesize: Use the BULC framework to adjust the vector of change for the three possibilities: the value went down, the value stayed the same, the value went up.\n\nIt is worth noting that BULC-D does not label the change with a LULC category; rather, it trains itself to distinguish likely LULC change from expected variability. In this way, BULC-D can be thought of as a “sieve” through which you are able to identify locations of possible change, isolated from likely background noise. In the BULC-D stage, the likeliness of change is identified across the landscape; in a separate second stage, the meaning of those changes and any changes to LULC classes are identified. We will explore the workings of BULC-D using its GUI.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F48c. The book’s repository contains information about accessing that interface.\n\n\nAfter you have run the script to initialize the interface, BULC-D’s interface requires a few parameters to be set. For this run of BULC-D, we will set the parameters to the following:\n\nExpectation years: 2020\nTarget year: 2021\nSensors: Landsat and Sentinel\nIndex: NBR\nHarmonic fit: Yes, 1 harmonic term.\n\nRun BULC-D for this area. As a reminder, you should first zoom in enough that the scale bar reads “5 km” or finer. Then, search for the location “-60.7624, -9.8542”. When you run BULC-D, a result like Fig. F4.8.6 is shown for the layer of probabilities.\n \nFig. 4.8.6 Result for BULC-D for the Roosevelt River area, depicting estimated probability of change and stability for 2021\nThe BULC-D image (Fig. F4.8.6) shows each pixel as a continuous three-value vector along a continuous range; the three values sum to 1. For example, a vector with values of [0.85, 0.10, 0.05] would represent an area estimated with high confidence according to BULC-D to have experienced a sustained drop in NBR in the target period compared to the values set by the expectation data. In that pixel, the combination of three colors would produce a value that is richly red. You can see Chap. F1.1 for more information on drawing bands of information to the screen using the red-green-blue additive color model in Earth Engine.\nEach pixel experiences its own NBR history in both the expectation period and the target year. Next, we will highlight the history of three nearby areas: one, marked with a red balloon in your interface, that BULC assessed as having experienced a persistent drop in NBR; a second in green assessed to not have changed, and a third in blue assessed to have witnessed a persistent NBR increase. \nFigure F4.8.7 shows the NBR history for the red balloon in the southern part of the study area in Fig. F4.8.4. If you click on that pixel or one like it, you can see that, whereas the values were quite stable throughout the growing season for the years used to create the pixel’s expectation, they were persistently lower in the target year. This is flagged as a likely meaningful drop in the NBR by BULC-D, for consideration by the analyst.\n                                                                                       \nFig. 4.8.7 NBR history for a pixel with an apparent drop in NBR in the target year (below) as compared to the expectation years (above). Pixel is colored a shade of red in Fig. 4.8.6.\nFigure F4.8.8 shows the NBR history for the blue balloon in the southern part of the study area in Fig. F4.8.4. For that pixel, while the values were quite stable throughout the growing season for the years used to create the pixel’s expectation, they were persistently higher in the target year. \nQuestion 4. Experiment with turning off one of the satellite sensor data sources used to create the expectation collection. For example, do you get the same results if the Sentinel-2 data stream is not used, or is the outcome different. You might make screen captures of the results to compare with Fig. 4.8.4. How strongly does each satellite stream affect the outcome of the estimate?  Do differences in the resulting estimate vary across the study area?\n\nFig. 4.8.8 NBR history for a pixel with an apparent increase in NBR in the target year (below) as compared to the expectation years (above). Pixel is colored a shade of blue in Fig. 4.8.6.\nFigure F4.8.8 also shows that, for that pixel, the fit of values for the years used to build the expectation showed a sine wave (shown in blue), but with a fit that was not very strong. When data for the target year was assembled (Fig. F4.8.8, bottom), the values were persistently above expectation throughout the growing season. Note that this pixel was identified as being different in the target year as compared to earlier years, which does not rule out the possibility that the LULC of the area was changed (for example, from Forest to Agriculture) during the years used to build the expectation collection. BULC-D is intended to be run steadily over a long period of time, with the changes marked as they occur, after which point the expectation would be recalculated.\n\nFig. 4.8.9 NBR history for a pixel with no apparent increase or decrease in NBR in the target year (below) as compared to the expectation years (above). Pixel is colored a shade of green in Fig. 4.8.6.\nFig. F4.8.9 shows the NBR history for the green balloon in the southern part of the study area in Fig. F4.8.4. For that pixel, the values in the expectation collection formed a sine wave, and the values in the target collection deviated only slightly from the expectation during the target year."
  },
  {
    "objectID": "F4.html#change-detection-with-bulc-and-dynamic-world",
    "href": "F4.html#change-detection-with-bulc-and-dynamic-world",
    "title": "5  Interpreting Image Series",
    "section": "14.5 Change Detection with BULC and Dynamic World",
    "text": "14.5 Change Detection with BULC and Dynamic World\nRecent advances in neural networks have made it easier to develop consistent models of LULC characteristics using satellite data. The Dynamic World project (Brown et al. 2022) applies a neural network, trained on a very large number of images, to each new Sentinel-2 image soon after it arrives. The result is a near-real-time classification interpreting the LULC of Earth’s surface, kept continually up to date with new imagery.\nWhat to do with the inevitable inconsistencies in a pixel’s stated LULC class through time? For a given pixel on a given image, its assigned class label is chosen by the Dynamic World algorithm as the maximum class probability given the band values on that day. Individual class probabilities are given as part of the dataset and could be used to better interpret a pixel’s condition and perhaps its history. Future work with BULC will involve incorporating these probabilities into BULC’s probability-based structure. For this tutorial, we will explore the consistency of the assigned labels in this same Roosevelt River area as a way to illustrate BULC’s potential for minimizing noise in this vast and growing dataset.\n\n14.5.1 5.1. Using BULC To Explore and Refine Dynamic World Classifications\nCode Checkpoint A48d. The book’s repository contains a script to use to begin this section. You will need to load the linked script and run it to begin.\nAfter running the linked script, the BULC interface will initialize. Select Dynamic World from the dropdown menu where you earlier selected Image Collection. When you do, the interface opens several new fields to complete. BULC will need to know where you are interested in working with Dynamic World, since it could be anywhere on Earth. To specify the location, the interface field expects a nested list of lists of lists, which is modeled after the structure used inside the constructor ee.Geometry.Polygon. (When using drawing tools or specifying study areas using coordinates, you may have noticed this structure.) Enter the following nested list in the text field near the Dynamic World option, without enclosing it in quotes:\n[[[-61.155, -10.559], [-60.285, -10.559], [-60.285, -9.436], [-61.155, -9.436]]]\nNext, BULC will need to know which years of Dynamic World you are interested in. For this exercise, select 2021. Then, BULC will ask for the Julian days of the year that you are interested in. For this exercise, enter 150 for the start day and 300 for the end day. Because you selected Dynamic World for analysis in BULC, the interface defaults to offering the number 9 for the number of classes in Events and for the number of classes to track. This number represents the full set of classes in the Dynamic World classification scheme. You can leave other required settings shown in green with their default values. For the Color Output Palette, enter the following palette without quotes. This will render results in the Dynamic World default colors.\n[‘419BDF’, ‘397D49’, ‘88B053’, ‘7A87C6’, ‘E49635’, ‘DFC35A’, ‘C4281B’, ‘A59B8F’, ‘B39FE1’]\nWhen you have finished, select Apply Parameters at the bottom of the input panel. When it runs, BULC subsets the Dynamic World dataset to clip out according to the dates and location, identifying images from more than 40 distinct dates. The area covers two of the tiles in which Dynamic World classifications are partitioned to be served, so BULC receives more than 90 classifications. When BULC finishes its run, the Map panel will look like Fig. F4.8.10, BULC’s estimate of the final state of the landscape at the end of the classification sequence.\n\nFig. F4.8.10 BULC classification using default settings for Roosevelt River area for late 2021\nLet’s explore the suite of information returned by BULC about this time period in Dynamic World. Enter “Muiraquitã” in the search bar and view the results around that area to be able to see the changing LULC classifications within farm fields. Then, begin to inspect the results by viewing a Movie of the Events, with a data frame rate of 6 frames per second. Because the study area spans multiple Dynamic World tiles, you will find that many Event frames are black, meaning that there was no data in your sector on that particular image. Because of this, and also perhaps because of the very aggressive cloud masking built into Dynamic World, viewing Events (which, as a reminder, are the individual classified images directly from Dynamic World) can be a very challenging way to look for change and stability. BULC’s goal is to sift through those classifications to produce a time series that reflects, according to its estimation, the most likely LULC value at each time step. View the Movie of the BULC results and ask yourself whether each class is equally well replicated across the set of classifications. A still from midway through the Movie sequence of the BULC results can be seen in Fig. F4.8.11.\n\nFig. F4.8.11 Still frame (right image) from the animation of BULC’s adjusted estimate of LULC through time near Muiraquitã\nAs BULC uses the classification inputs to estimate the state of the LULC at each time step, it also tracks its confidence in those estimates. This is shown in several ways in the interface.\n\nYou can view a Movie of BULC’s confidence through time as it reacts to the consistency or variability of the class identified in each pixel by Dynamic World. View that movie now over this area to see the evolution of BULC’s confidence through time of the class of each pixel. A still frame from this movie can be seen in Fig. F4.8.12. The frame and animation indicate that BULC’s confidence is lowest in pixels where the estimate flips between similar categories, such as Grass and Shrub & Scrub. It also is low at the edges of land covers, even where the covers (such as Forest and Water) are easy to discern from each other.  \nYou can inspect the final confidence estimate from BULC, which is shown as a grayscale image in the set of Map layers in the left lower panel. That single layer synthesizes how, across many Dynamic World classifications, the confidence in certain LULC classes and locations is ultimately more stable than in others. For example, generally speaking, the Forest class is classified consistently across this assemblage of Dynamic World images. Agriculture fields are less consistently classified as a single class, as evidenced by their relatively low confidence.\nAnother way of viewing BULC’s confidence is through the Inspector tab. You can click on individual pixels to view their values in the Event time series and in the BULC time series, and see BULC’s corresponding confidence value changing through time in response to the relative stability of each pixel’s classification.\nAnother way to view BULC’s confidence estimation is as a hillshade enhancement of the final BULC classification. If you select the Probability Hillshade in the set of Map layers, it shows the final BULC classification as a textured surface, in which you can see where lower-confidence pixels are classified.\n\n\nFig. F4.8.12 Still frame from the animation of changing confidence through time, near Muiraquitã.\n\n\n14.5.2 5.2. Using BULC To Visualize Uncertainty of Dynamic World in Simplified Categories\nIn the previous section, you may have noticed that there are two main types of uncertainty in BULC’s assessment of long-term classification confidence. One type is due to spatial uncertainty at the edge of two relatively distinct phenomena, like the River/Forest boundary visible in Fig. F4.8.12. These are shown in dark tones in the confidence images, and emphasized in the Probability Hillshade. The other type of uncertainty is due to some cause of labeling uncertainty, due either (1) to the similarity of the classes, or (2) to persistent difficulty in distinguishing two distinct classes that are meaningfully different but spectrally similar. An example of uncertainty due to similar labels is distinguishing flooded and non-flooded wetlands in classifications that contain both those categories. An example of difficulty distinguishing distinct but spectrally similar classes might be distinguishing a parking lot from a body of water.\nBULC allows you to remap the classifications it is given as input, compressing categories as a way to minimize uncertainty due to similarity among classes. In the setting of Dynamic World in this study area, we notice that several classes are functionally similar for the purposes of detecting new deforestation: Farm fields and pastures are variously labeled on any given Dynamic World classification as Grass, Flooded Vegetation, Crops, Shrub & Scrub, Built, or Bare Ground. What if we wanted to combine these categories to be similar to the distinctions of the classified Events from this lab’s Sect. 1? The classes in that section were Forest, Water, and Active Agriculture. To remap the Dynamic World classification, continue with the same run as in Sect. 5.1. Near where you specified the location for clipping Dynamic World, there are two fields for remapping. Select the Remap checkbox and in the “from” field, enter (without quotes):\n0,1,2,3,4,5,6,7,8\nIn the “to” field, enter (without quotes):\n1,0,2,2,2,2,2,2,0\nThis directs BULC to create a three-class remap of each Dynamic World image. Next, in the area of the interface where you specify the palette, enter the same palette used earlier:\n[‘green’, ‘blue’, ‘yellow’]\nBefore continuing, think for a moment about how many classes you have now. From BULC’s perspective, the Dynamic World events will have 3 classes and you will be tracking 3 classes. Set both the Number of Classes in Events and Number of Classes to Track to 3. Then click Apply Parameters to send this new run to BULC.\nThe confidence image shown in the main Map panel is instructive (Fig. 4.8.13). Using data from 2020, 2021, and 2022, It indicates that much of the uncertainty among the original Dynamic World classifications was in distinguishing labels within agricultural fields. When that uncertainty is removed by combining classes, the BULC result indicates that a substantial part of the remaining uncertainty is at the edges of distinct covers. For example, in the south-central and southern part of the frame, much of the uncertainty among classifications in the original Dynamic World classifications was due to distinction among the highly similar, easily confused classes. Much of what remained (right) after remapping (right) formed outlines of the river and the edges between farmland and forest: a graphic depiction of the “spatial uncertainty” discussed earlier. Yet not all of the uncertainty was spatial; the thicker, darker areas of uncertainty even after remapping (right, at the extreme eastern edge for example) indicates a more fundamental disagreement in the classifications. In those pixels, even when the Agriculture-like classes were compressed, there was still considerable uncertainty (likely between Forest and Active Agriculture) in the true state of these areas. These might be of further interest: were they places newly deforested in 2020-2022? Were they abandoned fields regrowing?  Were they degraded at some point? The mapping of uncertainty may hold promise for a better understanding of uncertainty as it is encountered in real classifications, thanks to Dynamic World.\n\nFig. F4.8.13 Final confidence layer from the run with (left) and without (right) remapping to combine similar LULC classes to distinguish Forest, Water, and Active Agriculture near -60.696W, -9.826S\nGiven the tools and approaches presented in this lab, you should now be able to import your own classifications for BULC (Sects. 1–3), detect changes in sets of raw imagery (Sect. 4), or use Dynamic World’s pre-created classifications (Sect. 5). The following exercises explore this potential."
  },
  {
    "objectID": "F4.html#synthesis-8",
    "href": "F4.html#synthesis-8",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. For a given set of classifications as inputs, BULC uses three parameters that specify how strongly to trust the initial classification, how heavily to weigh the evidence of each classification, and how to adjust the confidence at the end of each time step. For this exercise, adjust the values of these three parameters to explore the strength of the effect they can have on the BULC results.\nAssignment 2. The BULC-D framework produces a continuous three-value vector of the probability of change at each pixel. This variability accounts for the mottled look of the figures when those probabilities are viewed across space. Use the Inspector tool or the interface to explore the final estimated probabilities, both numerically and as represented by different colors of pixels in the given example. Compare and contrast the mean NBR values from the earlier and later years, which are drawn in the Layer list. Then answer the following questions:\n\nIn general, how well does BULC-D appear to be identifying locations of likely change?\nDoes one type of change (decrease, increase, no change) appear to be mapped better than the others? If so, why do you think this is?\n\nAssignment 3. The BULC-D example used here was for 2021. Run it for 2022 or later at this location. How well do results from adjacent years complement each other?\nAssignment 4. Run BULC-D in a different area for a year of interest of your choosing. How do you like the results?\nAssignment 5. Describe how you might use BULC-D as a filter for distinguishing meaningful change from noise. In your answer, you can consider using BULC-D before or after BULC or some other time-series algorithm, like CCDC or LandTrendr.\nAssignment 6. Analyze stability and change with Dynamic World for other parts of the world and for other years. For example, you might consider:\n\nQuebec, Canada, days 150–300 for 2019 and 2020:\n\n[[[-71.578, 49.755], [-71.578, 49.445], [-70.483, 49.445], [-70.483, 49.755]]]\nLocation of a summer 2020 fire\n\nAddis Ababa, Ethiopia:  [[[38.79, 9.00], [38.79, 8.99], [38.81, 8.99], [38.81, 9.00]]]\nCalacalí, Ecuador: [[[-78.537, 0.017], [-78.537, -0.047], [-78.463, -0.047], [-78.463, 0.017]]]\nIrpin, Ukraine: [[[30.22, 50.58], [30.22, 50.525], [30.346, 50.525], [30.346, 50.58]]]\nA different location of your own choosing. To do this, use the Earth Engine drawing tools to draw a rectangle somewhere on Earth. Then, at the top of the Import section, you will see an icon that looks like a sheet of paper. Click that icon and look for the polygon specification for the rectangle you drew. Paste that into the location field for the Dynamic World interface."
  },
  {
    "objectID": "F4.html#conclusion-8",
    "href": "F4.html#conclusion-8",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nIn this lab, you have viewed several related but distinct ways to use Bayesian statistics to identify locations of LULC change in complex landscapes. While they are standalone algorithms, they are each intended to provide a perspective either on the likelihood of change (BULC-D) or of extracting signal from noisy classifications (BULC). You can consider using them especially when you have pixels that, despite your best efforts, periodically flip back and forth between similar but different classes. BULC can help ignore noise, and BULC-D can help reveal whether this year’s signal has precedent in past years.\nTo learn more about the BULC algorithm, you can view this interactive probability illustration tool by a link found in script F48s1 - Supplemental in the book’s repository. In the future, after you have learned how to use the logic of BULC, you might prefer to work with the JavaScript code version. To do that, you can find a tutorial at the website of the authors."
  },
  {
    "objectID": "F4.html#references-7",
    "href": "F4.html#references-7",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nBrown CF, Brumby SP, Guzder-Williams B, et al (2022) Dynamic World, Near real-time global 10 m land use land cover mapping. Sci Data 9:1–17. https://doi.org/10.1038/s41597-022-01307-4\nCardille JA, Fortin JA (2016) Bayesian updating of land-cover estimates in a data-rich environment. Remote Sens Environ 186:234–249. https://doi.org/10.1016/j.rse.2016.08.021\nFortin JA, Cardille JA, Perez E (2020) Multi-sensor detection of forest-cover change across 45 years in Mato Grosso, Brazil. Remote Sens Environ 238. https://doi.org/10.1016/j.rse.2019.111266\nLee J, Cardille JA, Coe MT (2020) Agricultural expansion in Mato Grosso from 1986-2000: A Bayesian time series approach to tracking past land cover change. Remote Sens 12. https://doi.org/10.3390/rs12040688\nLee J, Cardille JA, Coe MT (2018) BULC-U: Sharpening resolution and improving accuracy of land-use/land-cover classifications in Google Earth Engine. Remote Sens 10. https://doi.org/10.3390/rs10091455\nMillard C (2006) The River of Doubt: Theodore Roosevelt’s Darkest Journey. Anchor"
  },
  {
    "objectID": "F4.html#author-9",
    "href": "F4.html#author-9",
    "title": "5  Interpreting Image Series",
    "section": "Author",
    "text": "Author\nAndréa Puzzi Nicolau, Karen Dyson, David Saah, Nicholas Clinton"
  },
  {
    "objectID": "F4.html#overview-9",
    "href": "F4.html#overview-9",
    "title": "5  Interpreting Image Series",
    "section": "Overview",
    "text": "Overview\nIn this chapter, we will introduce lagged effects to build on previous work in modeling time-series data. Time-lagged effects occur when an event at one point in time impacts dependent variables at a later point in time. You will be introduced to concepts of autocovariance and autocorrelation, cross-covariance and cross-correlation, and auto-regressive models. At the end of this chapter, you will be able to examine how variables relate to one another across time, and to fit time series models that take into account lagged events."
  },
  {
    "objectID": "F4.html#learning-outcomes-9",
    "href": "F4.html#learning-outcomes-9",
    "title": "5  Interpreting Image Series",
    "section": "Learning Outcomes",
    "text": "Learning Outcomes\n\nUsing the ee.Join function to create time-lagged collections.\nCalculating autocovariance and autocorrelation.\nCalculating cross-covariance and cross-correlation.\nFitting auto-regressive models."
  },
  {
    "objectID": "F4.html#assumes-you-know-how-to-9",
    "href": "F4.html#assumes-you-know-how-to-9",
    "title": "5  Interpreting Image Series",
    "section": "Assumes you know how to:",
    "text": "Assumes you know how to:\n\nImport images and image collections, filter, and visualize (Part F1).\nPerform basic image analysis: select bands, compute indices, create masks, classify images (Part F2).\n​​Create a graph using ui.Chart (Chap. F1.3).\nWrite a function and map it over an ImageCollection (Chap. F4.0).\nMask cloud, cloud shadow, snow/ice, and other undesired pixels (Chap. F4.3).\nFit linear and nonlinear functions with regression in an ImageCollection time series (Chap. F4.6)."
  },
  {
    "objectID": "F4.html#introduction-to-theory-8",
    "href": "F4.html#introduction-to-theory-8",
    "title": "5  Interpreting Image Series",
    "section": "Introduction to Theory",
    "text": "Introduction to Theory\nWhile fitting functions to time series allows you to account for seasonality in your models, sometimes the impact of a seasonal event does not impact your dependent variable until the next month, the next year, or even multiple years later. For example, coconuts take 18–24 months to develop from flower to harvestable size. Heavy rains during the flower development stage can severely reduce the number of coconuts that can be harvested months later, with significant negative economic repercussions. These patterns—where events in one time period impact our variable of interest in later time periods—are important to be able to include in our models.\nIn this chapter, we introduce lagged effects into our previous discussions on interpreting time-series data (Chaps. F4.6 and F4.7). Being able to integrate lagged effects into our time-series models allows us to address many important questions. For example, streamflow can be accurately modeled by taking into account previous streamflow, rainfall, and soil moisture; this improved understanding helps predict and mitigate the impacts of drought and flood events made more likely by climate change (Sazib et al. 2020). As another example, time-series lag analysis was able to determine that decreased rainfall was associated with increases in livestock disease outbreaks one year later in India (Karthikeyan et al. 2021)."
  },
  {
    "objectID": "F4.html#autocovariance-and-autocorrelation",
    "href": "F4.html#autocovariance-and-autocorrelation",
    "title": "5  Interpreting Image Series",
    "section": "15.1 Autocovariance and Autocorrelation",
    "text": "15.1 Autocovariance and Autocorrelation\nBefore we dive into autocovariance and autocorrelation, let’s set up an area of interest and dataset that we can use to illustrate these concepts. We will work with a detrended time series (as seen in Chap. F4.6) based on the USGS Landsat 8 Level 2, Collection 2, Tier 1 image collection. Copy and paste the code below to filter the Landsat 8 collection to a point of interest over California and specific dates, and apply the pre-processing function—to mask clouds (as seen in Chap. F4.3) and to scale and add variables of interest (as seen in Chap. F4.6).\n// Define function to mask clouds, scale, and add variables\n// (NDVI, time and a constant) to Landsat 8 imagery.\nfunction maskScaleAndAddVariable(image) {   // Bit 0 - Fill   // Bit 1 - Dilated Cloud   // Bit 2 - Cirrus   // Bit 3 - Cloud   // Bit 4 - Cloud Shadow   var qaMask = image.select(‘QA_PIXEL’).bitwiseAnd(parseInt(‘11111’,       2)).eq(0);   var saturationMask = image.select(‘QA_RADSAT’).eq(0);   // Apply the scaling factors to the appropriate bands.   var opticalBands = image.select(‘SR_B.’).multiply(0.0000275).add(-       0.2);   var thermalBands = image.select(‘ST_B.’).multiply(0.00341802)\n       .add(149.0);   // Replace the original bands with the scaled ones and apply the masks.   var img = image.addBands(opticalBands, null, true)\n       .addBands(thermalBands, null, true)\n       .updateMask(qaMask)\n       .updateMask(saturationMask);   var imgScaled = image.addBands(img, null, true);   // Now we start to add variables of interest.   // Compute time in fractional years since the epoch.   var date = ee.Date(image.get(’system:time_start’));   var years = date.difference(ee.Date(’1970-01-01’), ’year’);   var timeRadians = ee.Image(years.multiply(2  Math.PI));\n   // Return the image with the added bands.\n   return imgScaled\n       // Add an NDVI band.\n       .addBands(imgScaled.normalizedDifference([’SR_B5’, ’SR_B4’])\n           .rename(’NDVI’))       // Add a time band.       .addBands(timeRadians.rename(‘t’))\n       .float()       // Add a constant band.       .addBands(ee.Image.constant(1));\n}\n// Import region of interest. Area over California.\nvar roi = ee.Geometry.Polygon([\n   [-119.44617458417066,35.92639730653253],\n   [-119.07675930096754,35.92639730653253],\n   [-119.07675930096754,36.201704711823844],\n   [-119.44617458417066,36.201704711823844],\n   [-119.44617458417066,35.92639730653253]\n]);\n// Import the USGS Landsat 8 Level 2, Collection 2, Tier 1 collection,\n// filter, mask clouds, scale, and add variables.\nvar landsat8sr = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterBounds(roi)\n   .filterDate(‘2013-01-01’, ‘2018-01-01’)\n   .map(maskScaleAndAddVariable);\n// Set map center.\nMap.centerObject(roi, 10);\nNext, copy and paste the code below to estimate the linear trend using the linearRegression reducer, and remove that linear trend from the time series.\n// List of the independent variable names.\nvar independents = ee.List([‘constant’, ‘t’]);\n// Name of the dependent variable.\nvar dependent = ee.String(‘NDVI’);\n// Compute a linear trend.  This will have two bands: ‘residuals’ and\n// a 2x1 band called coefficients (columns are for dependent variables).\nvar trend = landsat8sr.select(independents.add(dependent))\n   .reduce(ee.Reducer.linearRegression(independents.length(), 1));\n// Flatten the coefficients into a 2-band image\nvar coefficients = trend.select(‘coefficients’)   // Get rid of extra dimensions and convert back to a regular image   .arrayProject([0])\n   .arrayFlatten([independents]);\n// Compute a detrended series.\nvar detrended = landsat8sr.map(function(image) {   return image.select(dependent)\n       .subtract(image.select(independents).multiply(\n               coefficients)\n           .reduce(‘sum’))\n       .rename(dependent)\n       .copyProperties(image, [‘system:time_start’]);\n});\nNow let’s turn to autocovariance and autocorrelation. The autocovariance of a time series refers to the dependence of values in the time series at time t with values at time h = t − lag. The autocorrelation is the correlation between elements of a dataset at one time and elements of the same dataset at a different time. The autocorrelation is the autocovariance normalized by the standard deviations of the covariates. Specifically, we assume our time series is stationary, and define the autocovariance and autocorrelation following Shumway and Stoffer (2019). Comparing values at time t to previous values is useful not only for computing autocovariance, but also for a variety of other time series analyses as you’ll see shortly.\nTo combine image data with previous values in Earth Engine, the first step is to join the previous values to the current values. To do that, we will use a ee.Join function to create what we’ll call a lagged collection. Copy and paste the code below to define a function that creates a lagged collection.\n// Function that creates a lagged collection.\nvar lag = function(leftCollection, rightCollection, lagDays) {   var filter = ee.Filter.and(       ee.Filter.maxDifference({\n           difference: 1000 * 60 * 60 * 24 * lagDays,\n           leftField: ‘system:time_start’,\n           rightField: ‘system:time_start’       }),       ee.Filter.greaterThan({\n           leftField: ‘system:time_start’,\n           rightField: ‘system:time_start’       }));   return ee.Join.saveAll({\n       matchesKey: ‘images’,\n       measureKey: ‘delta_t’,\n       ordering: ‘system:time_start’,\n       ascending: false, // Sort reverse chronologically   }).apply({\n       primary: leftCollection,\n       secondary: rightCollection,\n       condition: filter\n   });\n};\nThis function joins a collection to itself, using a filter that gets all the images before each image’s date that are within a specified time difference (in days) of each image. That list of previous images within the lag time is stored in a property of the image called images, sorted reverse chronologically. For example, to create a lagged collection from the detrended Landsat imagery, copy and paste:\n// Create a lagged collection of the detrended imagery.\nvar lagged17 = lag(detrended, detrended, 17);\nWhy 17 days? Recall that the temporal cadence of Landsat is 16 days. Specifying 17 days in the join gets one previous image, but no more.\nNow, we will compute the autocovariance using a reducer that expects a set of one-dimensional arrays as input. So pixel values corresponding to time t need to be stacked with pixel values at time t − lag as multiple bands in the same image. Copy and paste the code below to define a function to do so, and apply it to merge the bands from the lagged collection.\n// Function to stack bands.\nvar merge = function(image) {   // Function to be passed to iterate.   var merger = function(current, previous) {       return ee.Image(previous).addBands(current);\n   };   return ee.ImageCollection.fromImages(image.get(‘images’))\n       .iterate(merger, image);\n};\n// Apply merge function to the lagged collection.\nvar merged17 = ee.ImageCollection(lagged17.map(merge));\nNow the bands from time t and h are all in the same image. Note that the band name of a pixel at time h, ph, was the same as time t, pt (band name is “NDVI” in this case). During the merging process, it gets a ’_1’ appended to it (e.g. NDVI_1).\nYou can print the image collection to check the band names of one of the images. Copy and paste the code below to map a function to convert the merged bands to arrays with bands pt and ph, and then reduce it with the covariance reducer. We use a parallelScale factor of 8 in the reduce function to avoid the computation to run out of memory (this is not always needed). Note that the output of the covariance reducer is an array image, in which each pixel stores a 2x2 variance-covariance array. The off-diagonal elements are covariance, which you can map directly using the arrayGet function.\n// Function to compute covariance.\nvar covariance = function(mergedCollection, band, lagBand) {   return mergedCollection.select([band, lagBand]).map(function(\n       image) {       return image.toArray();\n   }).reduce(ee.Reducer.covariance(), 8);\n};\n// Concatenate the suffix to the NDVI band.\nvar lagBand = dependent.cat(’_1’);\n// Compute covariance.\nvar covariance17 = ee.Image(covariance(merged17, dependent, lagBand))\n   .clip(roi);\n// The output of the covariance reducer is an array image,\n// in which each pixel stores a 2x2 variance-covariance array.\n// The off diagonal elements are covariance, which you can map\n// directly using:\nMap.addLayer(covariance17.arrayGet([0, 1]),\n   {\n       min: 0,\n       max: 0.02   },   ‘covariance (lag = 17 days)’);\nInspect the pixel values of the resulting covariance image (Fig. F4.9.1). The covariance is positive when the greater values of one variable (at time t) mainly correspond to the greater values of the other variable (at time h), and the same holds for the lesser values, therefore, the values tend to show similar behavior. In the opposite case, when the greater values of a variable correspond to the lesser values of the other variable, the covariance is negative.\n\nFig. F4.9.1 Autocovariance image\nThe diagonal elements of the variance-covariance array are variances. Copy and paste the code below to define and map a function to compute correlation (Fig. F4.9.2) from the variance-covariance array.\n// Define the correlation function.\nvar correlation = function(vcArrayImage) {   var covariance = ee.Image(vcArrayImage).arrayGet([0, 1]);   var sd0 = ee.Image(vcArrayImage).arrayGet([0, 0]).sqrt();   var sd1 = ee.Image(vcArrayImage).arrayGet([1, 1]).sqrt();   return covariance.divide(sd0).divide(sd1).rename(       ‘correlation’);\n};\n// Apply the correlation function.\nvar correlation17 = correlation(covariance17).clip(roi);\nMap.addLayer(correlation17,\n   {\n       min: -1,\n       max: 1   },   ‘correlation (lag = 17 days)’);\n\nFig. F4.9.2 Autocorrelation image\nHigher positive values indicate higher correlation between the elements of the dataset, and lower negative values indicate the opposite.\nIt’s worth noting that you can do this for longer lags as well. Of course, that images list will fill up with all the images that are within lag of t. Those other images are also useful—for example, in fitting autoregressive models as described later.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F49a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#cross-covariance-and-cross-correlation",
    "href": "F4.html#cross-covariance-and-cross-correlation",
    "title": "5  Interpreting Image Series",
    "section": "15.2 Cross-Covariance and Cross-Correlation",
    "text": "15.2 Cross-Covariance and Cross-Correlation\nCross-covariance is analogous to autocovariance, except instead of measuring the correspondence between a variable and itself at a lag, it measures the correspondence between a variable and a covariate at a lag. Specifically, we will define the cross-covariance and cross-correlation according to Shumway and Stoffer (2019). \nYou already have all the code needed to compute cross-covariance and cross-correlation. But you do need a time series of another variable. Suppose we postulate that NDVI is related in some way to the precipitation before the NDVI was observed. To estimate the strength of this relationship in every pixel, copy and paste the code below to the existing script to load precipitation, join, merge, and reduce as previously:\n// Precipitation (covariate)\nvar chirps = ee.ImageCollection(‘UCSB-CHG/CHIRPS/PENTAD’);\n// Join the t-l (l=1 pentad) precipitation images to the Landsat.\nvar lag1PrecipNDVI = lag(landsat8sr, chirps, 5);\n// Add the precipitation images as bands.\nvar merged1PrecipNDVI = ee.ImageCollection(lag1PrecipNDVI.map(merge));\n// Compute and display cross-covariance.\nvar cov1PrecipNDVI = covariance(merged1PrecipNDVI, ‘NDVI’,   ‘precipitation’).clip(roi);\nMap.addLayer(cov1PrecipNDVI.arrayGet([0, 1]), {},   ‘NDVI - PRECIP cov (lag = 5)’);\n// Compute and display cross-correlation.\nvar corr1PrecipNDVI = correlation(cov1PrecipNDVI).clip(roi);\nMap.addLayer(corr1PrecipNDVI, {\n   min: -0.5,\n   max: 0.5}, ‘NDVI - PRECIP corr (lag = 5)’);\nWhat do you observe from this result? Looking at the cross-correlation image (Fig. F4.9.3), do you observe high values where you would expect high NDVI values (vegetated areas)? One possible drawback of this computation is that it’s only based on five days of precipitation, whichever five days came right before the NDVI image.\n\nFig. F4.9.3 Cross-correlation image of NDVI and precipitation with a five-day lag.\nPerhaps precipitation in the month before the observed NDVI is relevant? Copy and paste the code below to test the 30-day lag idea.\n// Join the precipitation images from the previous month.\nvar lag30PrecipNDVI = lag(landsat8sr, chirps, 30);\nvar sum30PrecipNDVI = ee.ImageCollection(lag30PrecipNDVI.map(function(\n   image) {   var laggedImages = ee.ImageCollection.fromImages(image\n       .get(‘images’));   return ee.Image(image).addBands(laggedImages.sum()\n       .rename(‘sum’));\n}));\n// Compute covariance.\nvar cov30PrecipNDVI = covariance(sum30PrecipNDVI, ‘NDVI’, ‘sum’).clip(\n   roi);\nMap.addLayer(cov1PrecipNDVI.arrayGet([0, 1]), {},   ‘NDVI - sum cov (lag = 30)’);\n// Correlation.\nvar corr30PrecipNDVI = correlation(cov30PrecipNDVI).clip(roi);\nMap.addLayer(corr30PrecipNDVI, {\n   min: -0.5,\n   max: 0.5}, ‘NDVI - sum corr (lag = 30)’);\nObserve that the only change is to the merge method. Instead of merging the bands of the NDVI image and the covariate (precipitation), the entire list of precipitation is summed and added as a band (eliminating the need for iterate).\nWhich changes do you notice between the cross-correlation images—5 days lag vs. 30 days lag (Fig. F4.9.4)?. You can use the Inspector tool to assess if the correlation increased or not at vegetated areas.\n\nFig. F4.9.4 Cross-correlation image of NDVI and precipitation with a 30-day lag.\nAs long as there is sufficient temporal overlap between the time series, these techniques could be extended to longer lags and longer time series.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F49b. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#auto-regressive-models",
    "href": "F4.html#auto-regressive-models",
    "title": "5  Interpreting Image Series",
    "section": "15.3 Auto-Regressive Models",
    "text": "15.3 Auto-Regressive Models\nThe discussion of autocovariance preceded this section in order to introduce the concept of lag. Now that you have a way to get previous values of a variable, it’s worth considering auto-regressive models. Suppose that pixel values at time t depend in some way on previous pixel values—auto-regressive models are time series models that use observations from previous time steps as input to a regression equation to predict the value at the next time step. If you have observed significant, non-zero autocorrelations in a time series, this is a good assumption. Specifically, you may postulate a linear model such as the following, where pt is a pixel at time t, and et is a random error (Chap. F4.6):\npt = β0 + β1pt-1 + β2pt-2 + et                                        (F4.9.1)\nTo fit this model, you need a lagged collection as created previously, except with a longer lag (e.g., lag = 34 days). The next steps are to merge the bands, then reduce with the linear regression reducer.\nCopy and paste the line below to the existing script to create a lagged collection, where the images list stores the two previous images:\nvar lagged34 = ee.ImageCollection(lag(landsat8sr, landsat8sr, 34));\nCopy and paste the code below to merge the bands of the lagged collection such that each image has bands at time t and bands at times t - 1,…, t − lag. Note that it’s necessary to filter out any images that don’t have two previous temporal neighbors.\nvar merged34 = lagged34.map(merge).map(function(image) {   return image.set(‘n’, ee.List(image.get(‘images’))\n       .length());\n}).filter(ee.Filter.gt(‘n’, 1));\nNow, copy and paste the code below to fit the regression model using the linearRegression reducer.\nvar arIndependents = ee.List([‘constant’, ‘NDVI_1’, ‘NDVI_2’]);\nvar ar2 = merged34\n   .select(arIndependents.add(dependent))\n   .reduce(ee.Reducer.linearRegression(arIndependents.length(), 1));\n// Turn the array image into a multi-band image of coefficients.\nvar arCoefficients = ar2.select(‘coefficients’)\n   .arrayProject([0])\n   .arrayFlatten([arIndependents]);\nWe can compute the fitted values using the expression function in Earth Engine. Because this model is a function of previous pixel values, which may be masked, if any of the inputs to equation F4.9.1 are masked, the output of the equation will also be masked. That’s why you should use an expression here, unlike the previous linear models of time. Copy and paste the code below to compute the fitted values.\n// Compute fitted values.\nvar fittedAR = merged34.map(function(image) {   return image.addBands(\n       image.expression(           ‘beta0 + beta1 * p1 + beta2 * p2’, {\n               p1: image.select(‘NDVI_1’),\n               p2: image.select(‘NDVI_2’),\n               beta0: arCoefficients.select(‘constant’),\n               beta1: arCoefficients.select(‘NDVI_1’),\n               beta2: arCoefficients.select(‘NDVI_2’)\n           }).rename(‘fitted’));\n});\nFinally, copy and paste the code below to plot the results (Fig. F4.9.5). We will use a specific point defined as pt. Note the missing values that result from masked data. If you run into computation errors, try commenting the Map.addLayer calls from previous sections to save memory.\n// Create an Earth Engine point object to print the time series chart.\nvar pt = ee.Geometry.Point([-119.0955, 35.9909]);\nprint(ui.Chart.image.series(\n       fittedAR.select([‘fitted’, ‘NDVI’]), pt, ee.Reducer\n   .mean(), 30)\n   .setSeriesNames([‘NDVI’, ‘fitted’])\n   .setOptions({\n       title: ‘AR(2) model: original and fitted values’,\n       lineWidth: 1,\n       pointSize: 3,\n   }));\n\nFig. F4.9.5 Observed NDVI and fitted values at selected point\nAt this stage, note that the missing data has become a real problem. Any data point for which at least one of the previous points is masked or missing is also masked.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F49c. The book’s repository contains a script that shows what your code should look like at this point.\n\n\nIt may be possible to avoid this problem by substituting the output from equation F4.9.1 (the modeled value) for the missing or masked data. Unfortunately, the code to make that happen is not straightforward. You can check a solution in the following Code Checkpoint:\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F49d. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#synthesis-9",
    "href": "F4.html#synthesis-9",
    "title": "5  Interpreting Image Series",
    "section": "Synthesis",
    "text": "Synthesis\nAssignment 1. Analyze cross-correlation between NDVI and soil moisture, or precipitation and soil moisture, for example. Earth Engine contains different soil moisture datasets in its catalog (e.g., NASA-USDA SMAP, NASA-GLDAS). Try increasing the lagged time and see if it makes any difference. Alternatively, you can pick any other environmental variable/index (e.g., a different vegetation index: EVI instead of NDVI, for example) and analyze its autocorrelation."
  },
  {
    "objectID": "F4.html#conclusion-9",
    "href": "F4.html#conclusion-9",
    "title": "5  Interpreting Image Series",
    "section": "Conclusion",
    "text": "Conclusion\nIn this chapter, we learned how to use autocovariance and autocorrelation to explore the relationship between elements of a time series at multiple time steps. We also explored how to use cross-covariance and cross-correlation to examine the relationship between elements of two time series at different points in time. Finally, we used auto-regressive models to regress the elements of a time series with elements of the same time series at a different point in time. With these skills, you can now examine how events in one time period impact your variable of interest in later time periods. While we have introduced the linear approach to lagged effects, these ideas can be expanded to more complex models."
  },
  {
    "objectID": "F4.html#references-8",
    "href": "F4.html#references-8",
    "title": "5  Interpreting Image Series",
    "section": "References",
    "text": "References\nKarthikeyan R, Rupner RN, Koti SR, et al (2021) Spatio-temporal and time series analysis of bluetongue outbreaks with environmental factors extracted from Google Earth Engine (GEE) in Andhra Pradesh, India. Transbound Emerg Dis 68:3631–3642. https://doi.org/10.1111/tbed.13972\nSazib N, Bolten J, Mladenova I (2020) Exploring spatiotemporal relations between soil moisture, precipitation, and streamflow for a large set of watersheds using Google Earth Engine. Water (Switzerland) 12:1371. https://doi.org/10.3390/w12051371\nShumway RH, Stoffer DS (2019) Time Series: A Data Analysis Approach Using R. Chapman and Hall/CRC"
  },
  {
    "objectID": "F6.html#introduction",
    "href": "F6.html#introduction",
    "title": "7  Advanced Topics",
    "section": "Introduction",
    "text": "Introduction\nVisualization is the step to transform data into a visual representation. You make a visualization as soon as you add your first layer to your map in Google Earth Engine. Sometimes you just want to have a first look at a dataset during the exploration phase. But as you move towards the dissemination phase, where you want to spread your results, it is good to think about a more structured approach to visualization. A typical workflow for creating visualization consists of the following steps:\n\nDefining the story (what is the message?)\nFinding inspiration (for example by making a moodboard)\nChoosing a canvas/medium (here, this is the Earth Engine map canvas)\nChoosing datasets (co-visualized or combined using derived indicators)\nData preparation (interpolating in time and space, filtering/mapping/reducing)\nConverting data into visual elements (shape and color)\nAdding annotations and interactivity (labels, scales, legend, zoom, time slider)\n\nA good standard work on all the choices that one can make while creating a visualization is provided by the Grammar of Graphics (GoG) by Wilkinson (1999). It was the inspiration behind many modern visualization libraries (ggplot, vega). The main concept is that you can subdivide your visualization into several aspects.\nIn this chapter, we will cover several aspects mentioned in the Grammar of Graphics to convert (raster) data into visual elements. The accurate representation of data is essential in science communication. However, color maps that visually distort data through uneven color gradients or are unreadable to those with color-vision deficiency remain prevalent in science (Crameri, 2020). You will also learn how to add annotation text and symbology, while improving your visualizations by mixing images with hillshading as you explore some of the amazing datasets that have been collected in recent years in Earth Engine."
  },
  {
    "objectID": "F6.html#introduction-1",
    "href": "F6.html#introduction-1",
    "title": "7  Advanced Topics",
    "section": "Introduction",
    "text": "Introduction\nMany people find themselves needing to share a script when they encounter a problem; they wish to share the script with someone else so they can ask a question. When this occurs, sharing a link to the script often suffices. The other person can then make comments or changes before sending a new link to the modified script.\nIf you have included any assets from the Asset Manager in your script, you will also need to share these assets in order for your script to work for your colleague. The same goes for sharing assets to be displayed in an app.\nAnother common situation involves collaborating with others on a project. They may have some scripts they have written that they want to reuse or modify for the new project. Alternatively, several people might want to work on the same script together. For this situation, sharing a repository would be the best way forward; team members will be able to see who made what changes to a script and even revert to a previous version.\nIf you or your group members find yourselves repeatedly reusing certain functions for visualization or for part of your analysis, you could use the require module to call that function instead of having to copy and paste it into a new script each time. You could even make this function or module available to others to use via require.\nLet’s get started. For this lab, you will need to work in small groups or pairs."
  },
  {
    "objectID": "F6.html#introduction-2",
    "href": "F6.html#introduction-2",
    "title": "7  Advanced Topics",
    "section": "Introduction",
    "text": "Introduction\nParts F1–F5 of this book have covered key remote sensing concepts and demonstrated how to implement them in Earth Engine. Most exercises have used local-scale examples to enhance understanding and complete tasks within a class-length time period. But Earth Engine’s power comes from its scalability—the ability to apply geospatial processing across large areas and many years.\nHow we go from small to large scales is influenced by Earth Engine’s design. Earth Engine runs on many individual computer servers, and its functions are designed to split up processing onto these servers. This chapter focuses on common approaches to implement large jobs within Earth Engine’s constraints. To do so, we first discuss Earth Engine’s underlying infrastructure to provide context for existing limits. We then cover four core concepts for scaling:\n\nUsing best coding practices.\nBreaking up jobs across time.\nBreaking up jobs across space.\nBuilding a multipart workflow and exporting intermediate assets.\n\n\n10.0.1 Earth Engine: Under the Hood\nAs you use Earth Engine, you may begin to have questions about how it works and how you can use that knowledge to optimize your workflow. In general, the inner workings are opaque to users. Typical fixes and approaches that data scientists use to manage memory constraints often don’t apply. It’s helpful to know what users can and cannot control, and how your scripts translate to Earth Engine’s server operations.\nEarth Engine is a parallel, distributed system (see Gorelick et al. 2017), which means that when you submit tasks, it breaks up pieces of your query onto different processors to complete them more efficiently. It then collects the results and returns them to you. For many users, not having to manually design this parallel, distributed processing is a huge benefit. For some advanced users, it can be frustrating to not have better control. We’d argue that leaving the details up to Earth Engine is a huge time-saver for most cases, and learning to work within a few constraints is a good time investment.\nOne core concept useful to master is the relationship between client-side and server-side operations. Client-side operations are performed within your browser (for the JavaScript API Code Editor) or local system (for the Python API). These include things such as manipulating strings or numbers in JavaScript. Server-side operations are executed on Google’s servers and include all of the ee.* functions. By using the Earth Engine APIs—JavaScript or Python—you are building a chain of commands to send to the servers and later receive the result back. As much as possible, you want to structure your code to send all the heavy lifting to Google, and keep processing off of your local resources.\nIn other words, your work in the Code Editor is making a description of a computation. All ee objects are just placeholders for server-side objects—their actual value does not exist locally on your computer. To see or use the actual value, it has to be evaluated by the server. If you print an Earth Engine object, it calls getInfo to evaluate and return the value. In contrast, you can also work with JavaScript/Python lists or numbers locally, and do basic JavaScript/Python things to them, like add numbers together or loop over items. These are client-side objects. Whenever you bring a server-side object into your local environment, there’s a computational cost.\nTable F6.2.1 describes some nuts and bolts about Earth Engine and their implications. Table F6.2.2 provides some of the existing limits on individual tasks.\nTable F6.2.1 Characterics of Google Earth Engine and implications for running large jobs \nEarth Engine characteristics\nImplications\nA parallel, distributed system\nOccasionally, doing the exact same thing in two different orders can result in different processing distributions, impacting the ability to complete the task within system limits.\nMost processing is done per tile (generally a square that is 256 x 256 pixels).\nTasks that require many tiles are the most memory intensive. Some functions have a tileScale argument that reduces tile size, allowing processing-intensive jobs to succeed (at the cost of reduced speed).\nExport mode has higher memory and time allocations than interactive mode.\nIt’s better to export large jobs. You can export to your Earth Engine assets, your Google Drive, or Google Cloud Storage.\nSome operations are cached temporarily.\nRunning the same job twice could result in different run times. Occasionally tasks may run successfully on a second try.\nUnderlying infrastructure is composed of clusters of low-end servers.\nThere’s a hard limit on data size for any individual server; large computations need to be done in parallel using Earth Engine functions.\nThe image processing domain, scale, and projection are defined by the specified output and applied backwards throughout the processing chain.\nThere are not many cases when you will need to manually reproject images, and these operations are costly. Similarly, manually “clipping” images is typically unnecessary.\nTable F6.2.2 Size limits for Earth Engine tasks\nEarth Engine Component\nLimits\nInteractive mode\nCan print up to 5000 records. Computations must finish within five minutes.\nExport mode\nJobs have no time limit as long as they continue to make reasonable progress (defined roughly as 600 seconds per feature, two hours per aggregation, and 10 minutes per tile). If any one tile, feature, or aggregation takes too long, the whole job will get canceled. Any jobs that take longer than one week to run will likely fail due to Earth Engine’s software update release cycles.\nTable assets\nMaximum of 100 million features, 1000 properties (columns), and 100,000 vertices for a geometry.\n\n\n10.0.2 The Importance of Coding Best Practices\nGood code scales better than bad code. But what is good code? Generally, for Earth Engine, good code means 1) using Earth Engine’s server-side operators; 2) avoiding multiple passes through the same image collection; 3) avoiding unnecessary conversions; and 4) setting the processing scale or sample numbers appropriate for your use case, i.e., avoid using very fine scales or large samples without reason.\nWe encourage readers to become familiar with the “Coding Best Practices” page in the online Earth Engine User Guide. This page provides examples for avoiding mixing client- and server-side functions, unnecessary conversions, costly algorithms, combining reducers, and other helpful tips. Similarly, the “Debugging Guide–Scaling Errors” page of the online Earth Engine User Guide covers some common problems and solutions.\nIn addition, some Earth Engine functions are more efficient than others. For example, Image.reduceRegions is more efficient than Image.sampleRegions, because sampleRegions regenerates the geometries under the hood. These types of best practices are trickier to enumerate and somewhat idiosyncratic. We encourage users to learn about and make use of the Profiler tab, which will track and display the resources used for each operation within your script. This can help identify areas to focus efficiency improvements. Note that the profiler itself increases resource use, so only use it when necessary to develop a script and remove it for production-level execution. Other ways to discover best practices include following/posting questions to GIS StackExchange or the Earth Engine Developer’s Discussion Group, swapping code with others, and experimentation."
  },
  {
    "objectID": "F6.html#introduction-3",
    "href": "F6.html#introduction-3",
    "title": "7  Advanced Topics",
    "section": "Introduction",
    "text": "Introduction\nEarth Engine has a user interface API that allows users to build and publish interactive web apps directly from the JavaScript Code Editor. Many readers will have encountered a call to ui.Chart in other chapters, but much more interface functionality is available. In particular, users can utilize the ui functions to construct an entire graphical user interface (GUI) for their Earth Engine script. The GUI may include simple widgets (e.g., labels, buttons, checkboxes, sliders, text boxes) as well as more complex widgets (e.g., charts, maps, panels) for controlling the GUI layout. A complete list of the ui widgets and more information about panels can be found at the links below. Once a GUI is constructed, users can publish the App from the JavaScript Code Editor by clicking the Apps button above the script panel in the Code Editor.\n\nWidgets: https://developers.google.com/earth-engine/guides/ui_widgets\nPanels: https://developers.google.com/earth-engine/guides/ui_panels \n\nUnlike the Earth Engine JavaScript API, the Earth Engine Python API does not provide functionality for building interactive user interfaces. Fortunately, the Jupyter ecosystem has ipywidgets, an architecture for creating interactive user interface controls (e.g., buttons, sliders, checkboxes, text boxes, dropdown lists) in Jupyter notebooks that communicate with Python code. The integration of graphical widgets into the Jupyter Notebook workflow allows users to configure ad hoc control panels to interactively sweep over parameters using graphical widget controls. One very powerful widget is the output widget, which can be used to display rich output generated by IPython, such as text, images, charts, and videos. A complete list of widgets and more information about the output widget can be found at the links below. By integrating ipyleaflet (for creating interactive maps) and ipywidgets (for designing interactive user interfaces), the geemap Python package (https://geemap.org) makes it much easier to explore and analyze massive Earth Engine datasets via a web browser in a Jupyter environment suitable for interactive exploration, teaching, and sharing. Users can build interactive Earth Engine Apps using geemap with minimal coding (Fig. F6.3.1).\n\nWidgets: https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20List.html \nOutput: https://ipywidgets.readthedocs.io/en/latest/examples/Output%20Widget.html \n\n\nFig. F6.3.1 The GUI of geemap in a Jupyter environment"
  },
  {
    "objectID": "F6.html#introduction-4",
    "href": "F6.html#introduction-4",
    "title": "7  Advanced Topics",
    "section": "Introduction",
    "text": "Introduction\nR is a popular programming language established in statistical science with large support in reproducible research, geospatial analysis, data visualization, and much more. To get started with R, you will need to satisfy some extra software requirements. First, install an up-to-date R version (at least 4.0) in your work environment. The installation procedure will vary depending on your operating system (i.e., Windows, Mac, or Linux). Hands-On Programming with R (Garrett Grolemund 2014, Appendix A) explains step by step how to proceed. We strongly recommend that Windows users install Rtools to avoid compiling external static libraries.\nIf you are new to R, a good starting point is the book Geocomputation with R (Lovelace et al. 2019) or Spatial Data Science with Application in R (Pebesma and Bivand 2021). In addition, we recommend using an integrated development environment (e.g., Rstudio) or a code editor (e.g., Visual Studio Code) to create a suitable setting to display and interact with R objects.\nThe following R packages must be installed (find more information in the R manual) in order to go through the practicum section."
  },
  {
    "objectID": "F5.html#introduction",
    "href": "F5.html#introduction",
    "title": "6  Vectors and Tables",
    "section": "Introduction",
    "text": "Introduction\nRaster data consists of regularly spaced pixels arranged into rows and columns, familiar as the format of satellite images. Vector data contains geometry features (i.e., points, lines, and polygons) describing locations and areas. Each data format has its advantages, and both will be encountered as part of GIS operations.\nRaster and vector data are commonly combined (e.g., extracting image information for a given location or clipping an image to an area of interest); however, there are also situations in which conversion between the two formats is useful. In making such conversions, it is important to consider the key advantages of each format. Rasters can store data efficiently where each pixel has a numerical value, while vector data can more effectively represent geometric features where homogenous areas have shared properties. Each format lends itself to distinctive analytical operations, and combining them can be powerful.\nIn this exercise, we’ll use topographic elevation and forest change images in Colombia as well as a protected area feature collection to practice the conversion between raster and vector formats, and to identify situations in which this is worthwhile."
  },
  {
    "objectID": "F4.html#introduction",
    "href": "F4.html#introduction",
    "title": "5  Interpreting Image Series",
    "section": "Introduction",
    "text": "Introduction\nPrior chapters focused on exploring individual images—for example, viewing the characteristics of single satellite images by displaying different combinations of bands (Chap. F1.1), viewing single images from different datasets (Chap. F1.2, Chap. F1.3), and exploring image processing principles (Parts F2, F3) as they are implemented for cloud-based remote sensing in Earth Engine. Each image encountered in those chapters was pulled from a larger assemblage of images taken from the same sensor. The chapters used a few ways to narrow down the number of images in order to view just one for inspection (Part F1) or manipulation (Part F2, Part F3).\nIn this chapter and most of the chapters that follow, we will move from the domain of single images to the more complex and distinctive world of working with image collections, one of the fundamental data types within Earth Engine. The ability to conceptualize and manipulate entire image collections distinguishes Earth Engine and gives it considerable power for interpreting change and stability across space and time.\nWhen looking for change or seeking to understand differences in an area through time, we often proceed through three ordered stages, which we will color code in this first explanatory part of the lab:\n\nFilter: selecting subsets of images based on criteria of interest.\nMap: manipulating each image in a set in some way to suit our goals. and\nReduce: estimating characteristics of the time series.\n\nFor users of other programming languages—R, MATLAB, C, Karel, and many others—this approach might seem awkward at first. We explain it below with a non-programming example: going to the store to buy milk.\nSuppose you need to go shopping for milk, and you have two criteria for determining where you will buy your milk: location and price. The store needs to be close to your home, and as a first step in deciding whether to buy milk today, you want to identify the lowest price among those stores. You don’t know the cost of milk at any store ahead of time, so you need to efficiently contact each one and determine the minimum price to know whether it fits in your budget. If we were discussing this with a friend, we might say, “I need to find out how much milk costs at all the stores around here.” To solve that problem in a programming language, these words imply precise operations on sets of information. We can write the following “pseudocode,” which uses words that indicate logical thinking but that cannot be pasted directly into a program:\nAllStoresOnEarth.filterNearbyStores.filterStoresWithMilk.getMilkPricesFromEachStore.determineTheMinimumValue\nImagine doing these actions not on a computer but in a more old-fashioned way: calling on the telephone for milk prices, writing the milk prices on paper, and inspecting the list to find the lowest value. In this approach, we begin with AllStoresOnEarth, since there is at least some possibility that we could decide to visit any store on Earth, a set that could include millions of stores, with prices for millions or billions of items. A wise first action would be to limit ourselves to nearby stores. Asking to filterNearbyStores would reduce the number of potential stores to hundreds, depending on how far we are willing to travel for milk. Then, working with that smaller set, we further filterStoresWithMilk, limiting ourselves to stores that sell our target item. At that point in the filtering, imagine that just 10 possibilities remain. Then, by telephone, we getMilkPricesFromEachStore, making a short paper list of prices. We then scan the list to determineTheMinimumValue to decide which store to visit.\nIn that example, each color plays a different role in the workflow. The AllStoresOnEarth set, any one of which might contain inexpensive milk, is an enormous collection. The filtering actions filterNearbyStores and filterStoresWithMilk are operations that can happen on any set of stores. These actions take a set of stores, do some operation to limit that set, and return that smaller set of stores as an answer. The action to getMilkPricesFromEachStore takes a simple idea—calling a store for a milk price—and “maps” it over a given set of stores. Finally, with the list of nearby milk prices assembled, the action to determineTheMinimumValue, a general idea that could be applied to any list of numbers, identifies the cheapest one.\nThe list of steps above might seem almost too obvious, but the choice and order of operations can have a big impact on the feasibility of the problem. Imagine if we had decided to do the same operations in a slightly different order:\nAllStoresOnEarth.filterStoresWithMilk.getMilkPricesFromEachStore.filterNearbyStores.determineMinimumValue\nIn this approach, we first identify all the stores on Earth that have milk, then contact them one by one to get their current milk price. If the contact is done by phone, this could be a painfully slow process involving millions of phone calls. It would take considerable “processing” time to make each call, and careful work to record each price onto a giant list. Processing the operations in this order would demand that only after entirely finishing the process of contacting every milk proprietor on Earth, we then identify the ones on our list that are not nearby enough to visit, then scan the prices on the list of nearby stores to find the cheapest one. This should ultimately give the same answer as the more efficient first example, but only after requiring so much effort that we might want to give up.\nIn addition to the greater order of magnitude of the list size, you can see that there are also possible slow points in the process. Could you make a million phone calls yourself? Maybe, but it might be pretty appealing to hire, say, 1000 people to help. While being able to make a large number of calls in parallel would speed up the calling stage, it’s important to note that you would need to wait for all 1000 callers to return their sublists of prices. Why wait? Nearby stores could be on any caller’s sublist, so any caller might be the one to find the lowest nearby price. The identification of the lowest nearby price would need to wait for the slowest caller, even if it turned out that all of that last caller’s prices came from stores on the other side of the world.\nThis counterexample would also have other complications—such as the need to track store locations on the list of milk prices—that could present serious problems if you did those operations in that unwise order. For now, the point is to filter, then map, then reduce. Below, we’ll apply these concepts to image collections."
  },
  {
    "objectID": "F4.html#introduction-1",
    "href": "F4.html#introduction-1",
    "title": "5  Interpreting Image Series",
    "section": "Introduction",
    "text": "Introduction\nCHIRPS is a high-resolution global gridded rainfall dataset that combines satellite-measured precipitation with ground station data in a consistent, long time-series dataset. The data are provided by the University of California, Santa Barbara, and are available from 1981 to the present. This dataset is extremely useful in drought monitoring and assessing global environmental change over land. The satellite data are calibrated with ground station observations to create the final product.\nIn this exercise, we will work with the CHIRPS dataset using the pentad. A pentad represents the grouping of five days. There are six pentads in a calendar month, with five pentads of exactly five days each and one pentad with the remaining three to six days of the month. Pentads reset at the beginning of each month, and the first day of every month is the start of a new pentad. Values at a given pixel in the CHIRPS dataset represent the total precipitation in millimeters over the pentad."
  },
  {
    "objectID": "F4.html#introduction-2",
    "href": "F4.html#introduction-2",
    "title": "5  Interpreting Image Series",
    "section": "Introduction",
    "text": "Introduction\nIn many respects, satellite remote sensing is an ideal source of data for monitoring large or remote regions. However, cloud cover is one of the most common limitations of optical sensors in providing continuous time series of data for surface mapping and monitoring. This is particularly relevant in tropical, polar, mountainous, and high-latitude areas, where clouds are often present. Many studies have addressed the extent to which cloudiness can restrict the monitoring of various regions (Zhu and Woodcock 2012, 2014; Eberhardt et al. 2016; Martins et al. 2018).\nClouds and cloud shadows reduce the view of optical sensors and completely block or obscure the spectral response from Earth’s surface (Cao et al. 2020). Working with pixels that are cloud-contaminated can significantly influence the accuracy and information content of products derived from a variety of remote sensing activities, including land cover classification, vegetation modeling, and especially change detection, where unscreened clouds might be mapped as false changes (Braaten et al. 2015, Zhu et al. 2015). Thus, the information provided by cloud detection algorithms is critical to exclude clouds and cloud shadows from subsequent processing steps.\nHistorically, cloud detection algorithms derived the cloud information by considering a single date-image and sun illumination geometry (Irish et al. 2006, Huang et al. 2010). In contrast, current, more accurate cloud detection algorithms are based on the analysis of Landsat time series (Zhu and Woodcock 2014, Zhu and Helmer 2018). Cloud detection algorithms inform on the presence of clouds, cloud shadows, and other atmospheric conditions (e.g., presence of snow). The presence and extent of cloud contamination within a pixel is currently provided with Landsat and Sentinel-2 imagery as ancillary data via quality flags at the pixel level. Additionally, quality flags also inform on other acquisition-related conditions, including radiometric saturation and terrain occlusion, which enables us to assess the usefulness and convenience of inclusion of each pixel in subsequent analyses. The quality flags are ideally suited to reduce users’ manual supervision and maximize the automatic processing approaches.\nMost automated algorithms (for classification or change detection, for example) work best on images free of clouds and cloud shadows, that cover the full area without spatial or spectral inconsistencies. Thus, the image representation over the study area should be seamless, containing as few data gaps as possible. Image compositing techniques are primarily used to reduce the impact of clouds and cloud shadows, as well as aerosol contamination, view angle effects, and data volumes (White et al. 2014). Compositing approaches typically rely on the outputs of cloud detection algorithms and quality flags to include or exclude pixels from the resulting composite products (Roy et al. 2010). Epochal image composites help overcome the limited availability of cloud-free imagery in some areas, and are constructed by considering the pixels from all images acquired in a given period (e.g., season, year).\nThe information provided by the cloud masks and pixel flags guides the establishment of rules to rank the quality of the pixels based on the presence of and distance to clouds, cloud shadows, or atmospheric haze (Griffiths et al. 2010). Higher scores are assigned to pixels with more desirable conditions, based on the presence of clouds and also other acquisition circumstances, such as acquisition date or sensor. Those pixels with the highest scores are included in the subsequent composite development. Image compositing approaches enable users to define the rules that are most appropriate for their particular information needs and study area to generate imagery covering large areas instead of being limited to the analysis of single scenes (Hermosilla et al. 2015, Loveland and Dwyer 2012). Moreover, generating image composites at regular intervals (e.g., annually) allows for the analysis of long temporal series over large areas, fulfilling a critical information need for monitoring programs.\nThe general workflow to generate a cloud-free composite involves:\n\nDefining your area of interest (AOI).\nFiltering (ee.Filter) the satellite ImageCollection to desired parameters.\nApplying a cloud mask.\nReducing (ee.Reducer) the collection to generate a composite.\nUsing the GEE-BAP application to generate annual best-available-pixel image composites by globally combining multiple Landsat sensors and images.\n\nAdditional steps may be necessary to improve the composite generated. These steps will be explained in the following sections.\n## Cloud Filter and Cloud Mask\nThe first step is to define your AOI and center the map. The goal is to create a nationwide composite for the country of Colombia. We will use the Large Scale International Boundary (2017) simplified dataset from the US Department of State (USDOS), which contains polygons for all countries of the world.\n// ———- Section 1 —————–\n// Define the AOI.\nvar country = ee.FeatureCollection(‘USDOS/LSIB_SIMPLE/2017’)\n   .filter(ee.Filter.equals(‘country_na’, ‘Colombia’));\n// Center the Map. The second parameter is zoom level.\nMap.centerObject(country, 5);\nWe will start creating a composite from the Landsat 8 collection. First, we define two time variables: startDate and endDate. Here, we will create a composite for the year 2019. Then, we will define a collection for the Landsat 8 Level 2, Collection 2, Tier 1 variable and filter it to our AOI and time period. We define and use a function to apply scaling factors to the Landsat 8 Collection 2 data.\n// Define time variables.\nvar startDate = ‘2019-01-01’;\nvar endDate = ‘2019-12-31’;\n// Load and filter the Landsat 8 collection.\nvar landsat8 = ee.ImageCollection(‘LANDSAT/LC08/C02/T1_L2’)\n   .filterBounds(country)\n   .filterDate(startDate, endDate);\n// Apply scaling factors.\nfunction applyScaleFactors(image) {   var opticalBands = image.select(‘SR_B.’).multiply(0.0000275).add(-       0.2);   var thermalBands = image.select(’ST_B.*’).multiply(0.00341802)\n       .add(149.0);   return image.addBands(opticalBands, null, true)\n       .addBands(thermalBands, null, true);\n}\nlandsat8 = landsat8.map(applyScaleFactors);\nNow, we can create a composite. We will use the median function, which has the same effect as writing reduce(ee.Reducer.median()) as seen in Chap. F4.0, to reduce our ImageCollection to a median composite. Add the resulting composite to the map using visualization parameters.\n// Create composite.\nvar composite = landsat8.median().clip(country);\nvar visParams = {\n   bands: [‘SR_B4’, ‘SR_B3’, ‘SR_B2’],\n   min: 0,\n   max: 0.2\n};\nMap.addLayer(composite, visParams, ‘L8 Composite’);\n\nFig. F4.3.1 Landsat 8 surface reflectance 2019 median composite of Colombia\nThe resulting composite (Fig. F4.3.1) has lots of clouds, especially in the western, mountainous regions of Colombia. In tropical regions, it is very challenging to generate a high-quality, cloud-free composite without first filtering images for cloud cover, even if our collection is constrained to only include images acquired during the dry season. Therefore, let’s filter our collection by the CLOUD_COVER parameter to avoid cloudy images. We will start with images that have less than 50% cloud cover.\n// Filter by the CLOUD_COVER property.\nvar landsat8FiltClouds = landsat8\n   .filterBounds(country)\n   .filterDate(startDate, endDate)\n   .filter(ee.Filter.lessThan(‘CLOUD_COVER’, 50));\n// Create a composite from the filtered imagery.\nvar compositeFiltClouds = landsat8FiltClouds.median().clip(country);\nMap.addLayer(compositeFiltClouds, visParams,   ‘L8 Composite cloud filter’);\n// Print size of collections, for comparison.\nprint(‘Size landsat8 collection’, landsat8.size());\nprint(‘Size landsat8FiltClouds collection’, landsat8FiltClouds.size());\n\nFig. F4.3.2 Landsat 8 surface reflectance 2019 median composite of Colombia filtered by cloud cover less than 50%\nThis new composite (Fig. F4.3.2) looks slightly better than the previous one, but still very cloudy. Remember to turn off the first layer or adjust the transparency to visualize only this new composite. The code prints the size of these collections, using the size function) to see how many images were left out after we applied the cloud cover threshold. (There are 1201 images in the landsat8 collection, compared to 493 in the landsat8FiltClouds collection—a lot of scenes with cloud cover greater than or equal to 50%.)\nTry adjusting the CLOUD_COVER threshold in the landsat8FiltClouds variable to different percentages and checking the results. For example, with 20% set as the threshold (Fig. F4.3.3), you can see that many parts of the country have image gaps. (Remember to turn off the first layer or adjust its transparency; you can also set the shown parameter in the Map.addLayer function to false so the layer does not automatically load). So there is a trade-off between a stricter cloud cover threshold and data availability. Additionally, even with a cloud filter, some tiles still present a large area cover of clouds.\n\nFig. F4.3.3 Landsat 8 surface reflectance 2019 median composite of Colombia filtered by cloud cover less than 20%\nThis is due to persistent cloud cover in some regions of Colombia. However, a cloud mask can be applied to improve the results. The Landsat 8 Collection 2 contains a quality assessment (QA) band called QA_PIXEL that provides useful information on certain conditions within the data, and allows users to apply per-pixel filters. Each pixel in the QA band contains unsigned integers that represent bit-packed combinations of surface, atmospheric, and sensor conditions.\nWe will also make use of the QA_RADSAT band, which indicates which bands are radiometrically saturated. A pixel value of 1 means saturated, so we will be masking these pixels.\nAs described in Chap. F4.0, we will create a function to apply a cloud mask to an image, and then map this function over our collection. The mask is applied by using the updateMask function. This function “eliminates” undesired pixels from the analysis, i.e., makes them transparent, by taking the mask as the input. You will see that this cloud mask function (or similar versions) is used in other chapters of the book. Note: Remember to set the cloud cover threshold back to 50 in the landsat8FiltClouds variable.\n// Define the cloud mask function.\nfunction maskSrClouds(image) {   // Bit 0 - Fill   // Bit 1 - Dilated Cloud   // Bit 2 - Cirrus   // Bit 3 - Cloud   // Bit 4 - Cloud Shadow   var qaMask = image.select(‘QA_PIXEL’).bitwiseAnd(parseInt(‘11111’,       2)).eq(0);   var saturationMask = image.select(‘QA_RADSAT’).eq(0);   return image.updateMask(qaMask)\n       .updateMask(saturationMask);\n}\n// Apply the cloud mask to the collection.\nvar landsat8FiltMasked = landsat8FiltClouds.map(maskSrClouds);\n// Create a composite.\nvar landsat8compositeMasked = landsat8FiltMasked.median().clip(country);\nMap.addLayer(landsat8compositeMasked, visParams, ‘L8 composite masked’);\n\nFig. F4.3.4 Landsat 8 surface reflectance 2019 median composite of Colombia filtered by cloud cover less than 50% and with cloud mask applied\nBecause we are dealing with bits, in the maskSrClouds function we utilized the bitwiseAnd and parseInt functions. These are functions that serve the purpose of unpacking the bit information. A bitwise AND is a binary operation that takes two equal-length binary representations and performs the logical AND operation on each pair of corresponding bits. Thus, if both bits in the compared positions have the value 1, the bit in the resulting binary representation is 1 (1 × 1 = 1); otherwise, the result is 0 (1 × 0 = 0 and 0 × 0 = 0). The parseInt function parses a string argument (in our case, five-character string ‘11111’) and returns an integer of the specified numbering system, base 2.\nThe resulting composite (Fig. F4.3.4) shows masked clouds, and is more spatially exhaustive in coverage compared to previous composites (don’t forget to uncheck the previous layers). This is because, when compositing all the images into one, we are not taking cloudy pixels into account anymore; therefore, the resulting pixel is not cloud covered but an actual representation of the landscape. However, data gaps are still an issue due to cloud cover. If you do not specifically need an annual composite, a first approach is to create a two-year composite to try to mitigate the missing data issue, or to have a series of rules that allows for selecting pixels for that particular year (as in Sect. 3 below). Change the startDate variable to 2018-01-01 to include all images from 2018 and 2019 in the collection. How does the cloud-masked composite (Fig. F4.3.5) compare to the 2019 one?\n\nFig. F4.3.5 One-year, startDate variable set to 2019-01-01, (left) and two-year, startDate variable set to 2018-01-01, (right) median composites with 50% cloud cover threshold and cloud mask applied\nThe resulting image has substantially fewer data gaps (you can zoom in to better see them). Again, if the time period is not a constraint for the creation of your composite, you can incorporate more images from a third year, and so on.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F43a. The book’s repository contains a script that shows what your code should look like at this point."
  },
  {
    "objectID": "F4.html#introduction-3",
    "href": "F4.html#introduction-3",
    "title": "5  Interpreting Image Series",
    "section": "Introduction",
    "text": "Introduction\nChange detection is the process of assessing how landscape conditions are changing by looking at differences in images acquired at different times. This can be used to quantify changes in forest cover—such as those following a volcanic eruption, logging activity, or wildfire—or when crops are harvested (Fig. F4.4.1). For example, using time-series change detection methods, Hansen et al. (2013) quantified annual changes in forest loss and regrowth. Change detection mapping is important for observing, monitoring, and quantifying changes in landscapes over time. Key questions that can be answered using these techniques include identifying whether a change has occurred, measuring the area or the spatial extent of the region undergoing change, characterizing the nature of the change, and measuring the pattern (configuration or composition) of the change (MacLeod and Congalton 1998).\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nFig. F4.4.1 Before and after images of (a) the eruption of Mount St. Helens in Washington State, USA, in 1980 (before, July 10, 1979; after, September 5, 1980); (b) the Camp Fire in California, USA, in 2018 (before, October 7, 2018; after, March 16, 2019); (c) illegal gold mining in the Madre de Dios region of Peru (before, March 31, 2001; after, August 22, 2020); and (d) shoreline changes in Incheon, South Korea (before, May 29, 1981; after, March 11, 2020)\nMany change detection techniques use the same basic premise: that most changes on the landscape result in spectral values that differ between pre-event and post-event images. The challenge can be to separate the real changes of interest—those due to activities on the landscape—from noise in the spectral signal, which can be caused by seasonal variation and phenology, image misregistration, clouds and shadows, radiometric inconsistencies, variability in illumination (e.g., sun angle, sensor position), and atmospheric effects.\nActivities that result in pronounced changes in radiance values for a sufficiently long time period are easier to detect using remote sensing change detection techniques than are subtle or short-lived changes in landscape conditions. Mapping challenges can arise if the change event is short-lived, as these are difficult to capture using satellite instruments that only observe a location every several days. Other types of changes occur so slowly or are so vast that they are not easily detected until they are observed using satellite images gathered over a sufficiently long interval of time. Subtle changes that occur slowly on the landscape may be better suited to more computationally demanding methods, such as time-series analysis. Kennedy et al. (2009) provides a nice overview of the concepts and tradeoffs involved when designing landscape monitoring approaches. Additional summaries of change detection methods and recent advances include Singh (1989), Coppin et al. (2004), Lu et al. (2004), and Woodcock et al. (2020).\nFor land cover changes that occur abruptly over large areas on the landscape and are long-lived, a simple two-date image differencing approach is suitable. Two-date image differencing techniques are long-established methods for identifying changes that produce easily interpretable results (Singh 1989). The process typically involves four steps: (1) image selection and preprocessing; (2) data transformation, such as calculating the difference between indices of interest (e.g., the Normalized Difference Vegetation Index (NDVI)) in the pre-event and post-event images; (3) classifying the differenced image(s) using thresholding or supervised classification techniques; and (4) evaluation.\nFor the practicum, you will select pre-event and post-event image scenes and investigate the conditions in these images in a false-color composite display. Next, you will calculate the NBR index for each scene and create a difference image using the two NBR maps. Finally, you will apply a threshold to the difference image to establish categories of changed versus stable areas (Fig. F4.4.2).\n\nFig. F4.4.2 Change detection workflow for this practicum"
  },
  {
    "objectID": "F4.html#introduction-4",
    "href": "F4.html#introduction-4",
    "title": "5  Interpreting Image Series",
    "section": "Introduction",
    "text": "Introduction\nLand surface change happens all the time, and satellite sensors witness it. If a spectral index is chosen to match the type of change being sought, surface change can be inferred from changes in spectral index values. Over time, the progression of spectral values witnessed in each pixel tells a story of the processes of change, such as growth and disturbance. Time-series algorithms are designed to leverage many observations of spectral values over time to isolate and describe changes of interest, while ignoring uninteresting change or noise.\nIn this lab, we use the LandTrendr time-series algorithms to map change. The LandTrendr algorithms apply “temporal segmentation” strategies to distill a multiyear time series into sequential straight-line segments that describe the change processes occurring in each pixel. We then isolate the segment of interest in each pixel and make maps of when, how long, and how intensely each process occurred. Similar strategies can be applied to more complicated descriptions of the time series, as is seen in some of the chapters that follow this one.\nFor this lab, we will use a graphical user interface (GUI) to teach the concepts of LandTrendr.\n\n\n\n\n\n\nNote\n\n\n\nCode Checkpoint F45a. The book’s repository contains information about accessing the LandTrendr interface."
  },
  {
    "objectID": "F4.html#introduction-5",
    "href": "F4.html#introduction-5",
    "title": "5  Interpreting Image Series",
    "section": "Introduction",
    "text": "Introduction\nMany natural and man-made phenomena exhibit important annual, interannual, or longer-term trends that recur—that is, they occur at roughly regular intervals. Examples include seasonality in leaf patterns in deciduous forests and seasonal crop growth patterns. Over time, indices such as the Normalized Difference Vegetation Index (NDVI) will show regular increases (e.g., leaf-on, crop growth) and decreases (e.g., leaf-off, crop senescence), and typically have a long-term, if noisy, trend such as a gradual increase in NDVI value as an area recovers from a disturbance.\nEarth Engine supports the ability to do complex linear and non-linear regressions of values in each pixel of a study area. Simple linear regressions of indices can reveal linear trends that can span multiple years. Meanwhile, harmonic terms can be used to fit a sine-wave-like curve. Once you have the ability to fit these functions to time series, you can answer many important questions. For example, you can define vegetation dynamics over multiple time scales, identify phenology and track changes year to year, and identify deviations from the expected patterns (Bradley et al. 2007, Bullock et al. 2020). There are multiple applications for these analyses. For example, algorithms to detect deviations from the expected pattern can be used to identify disturbance events, including deforestation and forest degradation (Bullock et al. 2020).\nIf you have not already done so, be sure to add the book’s code repository to the Code Editor by entering https://code.earthengine.google.com/?accept_repo=projects/gee-edu/book into your browser. The book’s scripts will then be available in the script manager panel."
  },
  {
    "objectID": "F4.html#introduction-6",
    "href": "F4.html#introduction-6",
    "title": "5  Interpreting Image Series",
    "section": "Introduction",
    "text": "Introduction\nWhen working with multiple sensors, we are often presented with a challenge: What to do with classification noise? It’s almost impossible to remove all noise from a classification. Given the information contained in a stream of classifications, however, you should be able to use the temporal context to distinguish noise from true changes in the landscape.\nThe Bayesian Updating of Land Cover (BULC) algorithm (Cardille and Fortin 2016) is designed to extract the signal from the noise in a stream of classifications made from any number of data sources. BULC’s principal job is to estimate, at each time step, the likeliest state of land use and land cover (LULC) in a study area given the accumulated evidence to that point. It takes a stack of provisional classifications as input; in keeping with the terminology of Bayesian statistics, these are referred to as “Events,” because they provide new evidence to the system. BULC then returns a stack of classifications as output that represents the estimated LULC time series implied by the Events. \nBULC estimates, at each time step, the most likely class from a set given the evidence up to that point in time. This is done by employing an accuracy assessment matrix like that seen in Chap. F2.2. At each time step, the algorithm quantifies the agreement between two classifications adjacent in time within a time series.\nIf the Events agree strongly, they are evidence of the true condition of the landscape at that point in time. If two adjacent Events disagree, the accuracy assessment matrix limits their power to change the class of a pixel in the interpreted time series. As each new classification is processed, BULC judges the credibility of a pixel’s stated class and keeps track of a set of estimates of the probability of each class for each pixel. In this way, each pixel traces its own LULC history, reflected through BULC’s judgment of the confidence in each of the classifications. The specific mechanics and formulas of BULC are detailed in Cardille and Fortin (2016).\nBULC’s code is written in JavaScript, with modules that weigh evidence for and against change in several ways, while recording parts of the data-weighing process for you to inspect. In this lab, we will explore BULC through its graphical user interface (GUI), which allows rapid interaction with the algorithm’s main functionality."
  },
  {
    "objectID": "F4.html#introduction-7",
    "href": "F4.html#introduction-7",
    "title": "5  Interpreting Image Series",
    "section": "Introduction",
    "text": "Introduction\nWhile fitting functions to time series allows you to account for seasonality in your models, sometimes the impact of a seasonal event does not impact your dependent variable until the next month, the next year, or even multiple years later. For example, coconuts take 18–24 months to develop from flower to harvestable size. Heavy rains during the flower development stage can severely reduce the number of coconuts that can be harvested months later, with significant negative economic repercussions. These patterns—where events in one time period impact our variable of interest in later time periods—are important to be able to include in our models.\nIn this chapter, we introduce lagged effects into our previous discussions on interpreting time-series data (Chaps. F4.6 and F4.7). Being able to integrate lagged effects into our time-series models allows us to address many important questions. For example, streamflow can be accurately modeled by taking into account previous streamflow, rainfall, and soil moisture; this improved understanding helps predict and mitigate the impacts of drought and flood events made more likely by climate change (Sazib et al. 2020). As another example, time-series lag analysis was able to determine that decreased rainfall was associated with increases in livestock disease outbreaks one year later in India (Karthikeyan et al. 2021)."
  },
  {
    "objectID": "F2.html#introduction",
    "href": "F2.html#introduction",
    "title": "4  Interpreting Images",
    "section": "Introduction",
    "text": "Introduction\nSpectral indices are based on the fact that different objects and land covers on the Earth’s surface reflect different amounts of light from the Sun at different wavelengths. In the visible part of the spectrum, for example, a healthy green plant reflects a large amount of green light while absorbing blue and red light—which is why it appears green to our eyes. Light also arrives from the Sun at wavelengths outside what the human eye can see, and there are large differences in reflectances between living and nonliving land covers, and between different types of vegetation, both in the visible and outside the visible wavelengths. We visualized this earlier, in Chaps. F1.1 and F1.3 when we mapped color-infrared images (Fig. F2.0.1).\n\nFig. F2.0.1 Mapped color-IR images from multiple satellite sensors that we mapped in Chap. F1.3. The near infrared spectrum is mapped as red, showing where there are high amounts of healthy vegetation.\nIf we graph the amount of light (reflectance) at different wavelengths that an object or land cover reflects, we can visualize this more easily (Fig. F2.0.2). For example, look at the reflectance curves for soil and water in the graph below. Soil and water both have relatively low reflectance at wavelengths around 300 nm (ultraviolet and violet light). Conversely, at wavelengths above 700 nm (red and infrared light) soil has relatively high reflectance, while water has very low reflectance. Vegetation, meanwhile, generally reflects large amounts of near infrared light, relative to other land covers.\n\nFig. F2.0.2 A graph of the amount of reflectance for different objects on the Earth’s surface at different wavelengths in the visible and infrared portions of the electromagnetic spectrum. 1 micrometer (µm) = 1,000 nanometers (nm).\nSpectral indices use math to express how objects reflect light across multiple portions of the spectrum as a single number. Indices combine multiple bands, often with simple operations of subtraction and division, to create a single value across an image that is intended to help to distinguish particular land uses or land covers of interest. Using Fig. F2.0.2, you can imagine which wavelengths might be the most informative for distinguishing among a variety of land covers. We will explore a variety of calculations made from combinations of bands in the following sections.\nIndices derived from satellite imagery are used as the basis of many remote-sensing analyses. Indices have been used in thousands of applications, from detecting anthropogenic deforestation to examining crop health. For example, the growth of economically important crops such as wheat and cotton can be monitored throughout the growing season: Bare soil reflects more red wavelengths, whereas growing crops reflect more of the near-infrared (NIR) wavelengths. Thus, calculating a ratio of these two bands can help monitor how well crops are growing (Jackson and Huete 1991)."
  },
  {
    "objectID": "F2.html#introduction-1",
    "href": "F2.html#introduction-1",
    "title": "4  Interpreting Images",
    "section": "Introduction",
    "text": "Introduction\nClassification is addressed in a broad range of fields, including mathematics, statistics, data mining, machine learning, and more. For a deeper treatment of classification, interested readers may see some of the following suggestions: Witten et al. (2011), Hastie et al. (2009), Goodfellow et al. (2016), Gareth et al. (2013), Géron (2019), Müller et al. (2016), or Witten et al. (2005). Unlike regression, which predicts continuous variables, classification predicts categorical, or discrete, variables—variables with a finite number of categories (e.g., age range).\nIn remote sensing, image classification is an attempt to categorize all pixels in an image into a finite number of labeled land cover and/or land use classes. The resulting classified image is a simplified thematic map derived from the original image (Fig. F2.1.1). Land cover and land use information is essential for many environmental and socioeconomic applications, including natural resource management, urban planning, biodiversity conservation, agricultural monitoring, and carbon accounting.\n\nFig. F2.1.1 Image classification concept\nImage classification techniques for generating land cover and land use information have been in use since the 1980s (Li et al. 2014). Here, we will cover the concepts of pixel-based supervised and unsupervised classifications, testing out different classifiers. Chapter F3.3 covers the concept and application of object-based classification.\nIt is important to define land use and land cover. Land cover relates to the physical characteristics of the surface: simply put, it documents whether an area of the Earth’s surface is covered by forests, water, impervious surfaces, etc. Land use refers to how this land is being used by people. For example, herbaceous vegetation is considered a land cover but can indicate different land uses: the grass in a pasture is an agricultural land use, whereas the grass in an urban area can be classified as a park."
  },
  {
    "objectID": "F2.html#introduction-2",
    "href": "F2.html#introduction-2",
    "title": "4  Interpreting Images",
    "section": "Introduction",
    "text": "Introduction\nAny map or remotely sensed product is a generalization or model that will have inherent errors. Products derived from remotely sensed data used for scientific purposes and policymaking require a quantitative measure of accuracy to strengthen the confidence in the information generated (Foody 2002, Strahler et al. 2006, Olofsson et al. 2014). Accuracy assessment is a crucial part of any classification project, as it measures the degree to which the classification agrees with another data source that is considered to be accurate, ground-truth data (i.e., “reality”).\nThe history of accuracy assessment reveals increasing detail and rigor in the analysis, moving from a basic visual appraisal of the derived map (Congalton 1994, Foody 2002) to the definition of best practices for sampling and response designs and the calculation of accuracy metrics (Foody 2002, Stehman 2013, Olofsson et al. 2014, Stehman and Foody 2019). The confusion matrix (also called the “error matrix”) (Stehman 1997) summarizes key accuracy metrics used to assess products derived from remotely sensed data.\nIn Chap. F2.1, we asked whether the classification results were satisfactory. In remote sensing, the quantification of the answer to that question is called accuracy assessment. In the classification context, accuracy measurements are often derived from a confusion matrix.\nIn a thorough accuracy assessment, we think carefully about the sampling design, the response design, and the analysis (Olofsson et al. 2014). Fundamental protocols are taken into account to produce scientifically rigorous and transparent estimates of accuracy and area, which requires robust planning and time. In a standard setting, we would calculate the number of samples needed for measuring accuracy (sampling design). Here, we will focus mainly on the last step, analysis, by examining the confusion matrix and learning how to calculate the accuracy metrics. This will be done by partitioning the existing data into training and testing sets."
  }
]