After 2022-01-25, Sentinel-2 scenes with PROCESSING_BASELINE '04.00' or above have their DN (value) range shifted by 1000. The HARMONIZED collection shifts data in newer scenes to be in the same range as in older scenes. Sentinel-2 is a wide-swath, high-resolution, multi-spectral imaging mission supporting Copernicus Land Monitoring studies, including the monitoring of vegetation, soil and water cover, as well as observation of inland waterways and coastal areas. The Sentinel-2 data contain 13 UINT16 spectral bands representing TOA reflectance scaled by 10000. See the Sentinel-2 User Handbook for details. QA60 is a bitmask band that contained rasterized cloud mask polygons until Feb 2022, when these polygons stopped being produced. Starting in February 2024, legacy-consistent QA60 bands are constructed from the MSK_CLASSI cloud classification bands. For more details, see the full explanation of how cloud masks are computed.. Each Sentinel-2 product (zip archive) may contain multiple granules. Each granule becomes a separate Earth Engine asset. EE asset ids for Sentinel-2 assets have the following format: COPERNICUS/S2/20151128T002653_20151128T102149_T56MNN. Here the first numeric part represents the sensing date and time, the second numeric part represents the product generation date and time, and the final 6-character string is a unique granule identifier indicating its UTM grid reference (see MGRS). The Level-2 data produced by ESA can be found in the collection COPERNICUS/S2_SR. For datasets to assist with cloud and/or cloud shadow detection, see COPERNICUS/S2_CLOUD_PROBABILITY and GOOGLE/CLOUD_SCORE_PLUS/V1/S2_HARMONIZED. For more details on Sentinel-2 radiometric resolution, see this page.

Top of Atmosphere (TOA) reflectance data in bands from the USGS Landsat 5 and Landsat 8 satellites were accessed via Google Earth Engine. CANUE staff used Google Earth Engine functions to create cloud free annual composites, and mask water features, then export the resulting band data. NDVI indices were calculated as (band 4 - Band 3)/(Band 4 Band 3) for Landsat 5 data, and as (band 5 - band 4)/(band 5 Band 4) for Landsat 8 data. These composites are created from all the scenes in each annual period beginning from the first day of the year and continuing to the last day of the year. No data were available for 2012, due to decommissioning of Landsat 5 in 2011 prior to the start of Landsat 8 in 2013. No cross-calibration between the sensors was performed, please be aware there may be small bias differences between NDVI values calculated using Landsat 5 and Landsat 8. Final NDVI metrics were linked to all 6-digit DMTI Spatial single link postal code locations in Canada, and for surrounding areas within 100m, 250m, 500m, and 1km.

ERA5-Land is a reanalysis dataset providing a consistent view of the evolution of land variables over several decades at an enhanced resolution compared to ERA5. ERA5-Land has been produced by replaying the land component of the ECMWF ERA5 climate reanalysis. Reanalysis combines model data with observations from across the world into a globally complete and consistent dataset using the laws of physics. Reanalysis produces data that goes several decades back in time, providing an accurate description of the climate of the past. This dataset includes all 50 variables as available on CDS. ERA5-Land data is available from 1950 to three months from real-time. Please consult the ERA5-Land "Known Issues" section. In particular, note that three components of the total evapotranspiration have values swapped as follows: variable "Evaporation from bare soil" (mars parameter code 228101 (evabs)) has the values corresponding to the "Evaporation from vegetation transpiration" (mars parameter 228103 (evavt)), variable "Evaporation from open water surfaces excluding oceans (mars parameter code 228102 (evaow)) has the values corresponding to the "Evaporation from bare soil" (mars parameter code 228101 (evabs)), variable "Evaporation from vegetation transpiration" (mars parameter code 228103 (evavt)) has the values corresponding to the "Evaporation from open water surfaces excluding oceans" (mars parameter code 228102 (evaow)). The asset is a daily aggregate of ECMWF ERA5 Land hourly assets which includes both flow and non-flow bands. Flow bands are formed by collecting the first hour's data of the following day which holds aggregated sum of previous day and while the non-flow bands are created by averaging all hourly data of the day. The flow bands are labeled with the "_sum" identifier, which approach is different from the daily data produced by Copernicus Climate Data Store, where flow bands are averaged too. Daily aggregates have been pre-calculated to facilitate many applications requiring easy and fast access to the data. Precipitation and other flow (accumulated) bands might occasionally have negative values, which doesn't make physical sense. At other times their values might be excessively high. This problem is due to how the GRIB format saves data: it simplifies or "packs" the data into smaller, less precise numbers, which can introduce errors. These errors get worse when the data varies a lot. Because of this, when we look at the data for a whole day to compute daily totals, sometimes the highest amount of rainfall recorded at one time can seem larger than the total rainfall measured for the entire day. To learn more, Please see: "Why are there sometimes small negative precipitation accumulations"

Training Classifiers, Supervised Classification and Error Assessment • How to add raster and vector data from the catalog in Google Earth Engine; • Train a classifier; • Perform the error assessment; • Download the results.

Google Earth Engine used to compute the NDVI statistics added to Globe-LFMC. The input of the program is a point shapefile (“samplePlotsShapefile”, extensions .cpg, .dbf, .prj, .shp, .shx) representing the location of each Globe-LFMC site. This shapefile is available as additional data in figshare (see Code Availability). To run this GEE code the shapefile needs to be uploaded into the GEE Assets and, then, imported into the Code Editor with the name “plots” (without quotation marks).Google Earth Engine codeChange Notice - GEE_script_for_GlobeLFMC_ndvi_stats_v2.jsThe following acknowledgements have been added at the beginning of the code: “Portions of the following code are modifications based on work created and shared by Google in Earth Engine Data Catalog and Earth Engine Guides under the Apache 2.0 License. https://www.apache.org/licenses/LICENSE-2.0”Change Notice - samplePlotsShapefile_v2The shapefile describing the database sites has been corrected and updated with the correct coordinates.

CANUE staff developed annual estimates of maximum mean warm-season land surface temperature (LST) recorded by LandSat 8 at 30m resolution. To reduce the effect of missing data/cloud cover/shadows, the highest mean warm-season value reported over three years was retained - for example, the data for 2021 represent the maximum of the mean land surface temperature at a pixel location between April 1st and September 30th in 2019, 2020 and 2021. Land surface temperature was calculated in Google Earth Engine, using a public algorithm (see supplementary documentation). In general, annual mean LST may not reflect ambient air temperatures experienced by individuals at any given time, but does identify areas that are hotter during the day and therefore more likely to radiate excess heat at night - both factors that contribute to heat islands within urban areas.

This example is about how to use Google Earth Engine API on Jupyter Notebooks. We show the example of how to get Landsat Net Primary Production (NPP) CONUS DataSet from Google Earth Engine Data Catalog.

The National Agriculture Imagery Program (NAIP) acquires aerial imagery during the agricultural growing seasons in the continental U.S. NAIP projects are contracted each year based upon available funding and the imagery acquisition cycle. Beginning in 2003, NAIP was acquired on a 5-year cycle. 2008 was a transition year, and a …

Top of Atmosphere (TOA) reflectance data in bands from the USGS Landsat 5 and Landsat 8 satellites were accessed via Google Earth Engine. CANUE staff used Google Earth Engine functions to create cloud free mean growing season composites, and mask water features, then export the resulting band data. Growing season is defined as May 1st through August 31st. NDVI indices were then calculated as (band 4 - Band 3)/(Band 4 Band 3) for Landsat 5 data, and as (band 5 - band 4)/(band 5 Band 4) for Landsat 8 data. No data were available for 2012, due to decommissioning of Landsat 5 in 2011 prior to the start of Landsat 8 in 2013. No cross-calibration between the sensors was performed, please be aware there may be small bias differences between NDVI values calculated using Landsat 5 and Landsat 8. Final NDVI metrics were linked to all 6-digit DMTI Spatial single link postal code locations in Canada, and for surrounding areas within 100m, 250m, 500m, and 1km.

Annual maximum NDVI calculated by Google from Landsat 5 and Landsat 8 were accessed via Google Earth Engine. These composites are created from all the scenes in each annual period beginning from the first day of the year and continuing to the last day of the year. All the images from each year are included in the composite, with the greenest pixel as the composite value, where the greenest pixel is the maximum value of the Normalized Difference Vegetation Index (NDVI). No data were available for 2012, due to decommissioning of Landsat 5 in 2011 prior to the start of Landsat 8 in 2013. No cross-calibration between the sensors was performed, please be aware there may be small bias differences between NDVI values calculated using Landsat 5 and Landsat 8. Final NDVI metrics were linked to all 6-digit DMTI Spatial single link postal code locations in Canada, and for surrounding areas within 100m, 250m, 500m, and 1km.

Region of Interest (ROI) is comprised of the Belgium, the Netherlands and Luxembourg

We use the communes administrative division which is standardized across Europe by EUROSTAT at: https://ec.europa.eu/eurostat/web/gisco/geodata/reference-data/administrative-units-statistical-units This is roughly equivalent to the notion municipalities in most countries.

From the link above, communes definition are taken from COMM_RG_01M_2016_4326.shp and country borders are taken from NUTS_RG_01M_2021_3035.shp.

images: Sentinel2 RGB from 2020-01-01 to 2020-31-12 filtered out pixels with clouds during the observation period according to QA60 band following the example given in GEE dataset info page, and took the median of the resulting pixels

  see https://developers.google.com/earth-engine/datasets/catalog/COPERNICUS_S2_SR_HARMONIZED


  see also https://github.com/rramosp/geetiles/blob/main/geetiles/defs/sentinel2rgbmedian2020.py

labels: ESA WorldCover 10m V100 labels mapped to the interval [1,11] according to the following map { 0:0, 10: 1, 20:2, 30:3, 40:4, 50:5, 60:6, 70:7, 80:8, 90:9, 95:10, 100:11 } pixel value zero is reserved for invalid data. see https://developers.google.com/earth-engine/datasets/catalog/ESA_WorldCover_v100

  see also https://github.com/rramosp/geetiles/blob/main/geetiles/defs/esaworldcover.py

_aschips.geojson the image chips geometries along with label proportions for easy visualization with QGIS, GeoPandas, etc.

_communes.geojson the communes geometries with their label prortions for easy visualization with QGIS, GeoPandas, etc.

splits.csv contains two splits of image chips in train, test, val - with geographical bands at 45° angles in nw-se direction - the same as above reorganized to that all chips within the same commune fall within the same split.

data/ a pickle file for each image chip containing a dict with - the 100x100 RGB sentinel 2 chip image - the 100x100 chip level lavels - the label proportions of the chip - the aggregated label proportions of the commune the chip belongs to

The European Space Agency (ESA) WorldCover 10 m 2020 product provides a global land cover map for 2020 at 10 m resolution based on Sentinel-1 and Sentinel-2 data. The WorldCover product comes with 11 land cover classes and has been generated in the framework of the ESA WorldCover project, part …

L'outil Hakai Google Earth Engine Kelp (outil GEEK) a été développé dans le cadre d'une collaboration entre l'Institut Hakai, l'Université de Victoria et le ministère des Pêches et des Océans pour tirer parti des capacités de cloud computing pour analyser l'imagerie satellite Landsat (30 m) afin d'extraire l'étendue de la canopée et du varech. La méthodologie originale est décrite dans Nijland et al. 2019*.

Remarque : Ce jeu de données est conçu comme une « lecture seule », car nous continuons à améliorer les résultats. Il vise à démontrer l'utilité de l'archive Landsat pour cartographier le varech. Ces données sont visibles sur la carte Web GEEK disponible ici.

Ce package de données contient deux jeux de données :

Etendue annuelle maximale estivale du varech formant la canopée (1984 - 2019) en tant que rasters. Etendue maximale décennale du varech formant la canopée (1984 - 1990, 1991 - 2000, 2001 - 2010, 2011 - 2020)

Ce jeu de données a été généré à la suite de modifications apportées aux méthodologies GEEK originales. Les paramètres utilisés pour générer les rasters étaient des scènes d'images avec :

Plage de mois Imagescene = 1er mai - 30 septembre Clouds maximum dans la scène = 80% Marée maximale = 3,2 m (+0,5 MWL des marées de la côte centrale selon les méthodes KIM-1) Marée minimale = 0 m Tampon de rivage appliqué au masque de terrain = 1 pixel (30 m) NDVI* minimum (pour qu'un pixel individuel soit classé comme varech) = -0,05 Nombre minimum de fois qu'un pixel de varech individuel doit être détecté en tant que varech au cours d'une seule année = 30 % de toutes les détections d'une année donnée K moyenne minimale (moyenne du NDVI pour tous les pixels à un emplacement donné détecté comme varech) = -0,05 * NDVI = indice de végétation de différence normalisée.

Ces paramètres ont été choisis sur la base d'une évaluation de la précision à l'aide d'une étendue de varech dérivée d'images WorldView-2 (2 m) de juillet 2014 et août 2014. Ces données ont été rééchantillonnées à 30 m. Bien que de nombreuses itérations exécutées pour l'outil aient donné des résultats très similaires, des paramètres ont été sélectionnés qui ont maximisé la précision du varech pour la comparaison de 2014.

Les résultats de l'évaluation de la précision ont été les suivants : Erreur de commission de 50 % Erreur d'omission de 25 %

En termes simples, les méthodes actuelles conduisent à un niveau élevé de « faux positifs », mais elles capturent avec précision l'étendue du varech par rapport au jeu de données de validation. Cette erreur peut être attribuée à la sensibilité de l'utilisation d'un seul NDVI pour détecter le varech. Nous observons des variations des seuils NDVI à la fois au sein d'une seule scène et entre les scènes.

L'objectif du jeu de données de séries chronologiques est censé prendre en compte une partie de cette erreur, car les pixels détectés seulement un par décennie sont supprimés.

Ce jeu de données fait partie du programme de cartographie de l'habitat de Hakai. L'objectif principal du programme de cartographie de l'habitat de Hakai est de générer des inventaires spatiaux des habitats côtiers, d'étudier comment ces habitats évoluent au fil du temps et les moteurs de ce changement.

*Nijland, W., Reshitnyk, L. et Rubidge, E. (2019). Télédétection par satellite de varech formant une canopée sur un littoral complexe : une nouvelle procédure utilisant les archives d'images Landsat. Télédétection de l'environnement, 220, 41-50. doi:10.1016/j.rse.2018.10.032

Climate reanalysis and climate projection datasets offer the potential for researchers, students and instructors to access physically informed, global scale, temporally and spatially continuous climate data from the latter half of the 20th century to present, and explore different potential future climates. While these data are of significant use to research and teaching within biological, environmental and social sciences, potential users often face barriers to processing and accessing the data that cannot be overcome without specialist knowledge, facilities or assistance. Consequently, climate reanalysis and projection data are currently substantially under-utilised within research and education communities. To address this issue, we present two simple “point-and-click” graphical user interfaces: the Google Earth Engine Climate Tool (GEEClimT), providing access to climate reanalysis data products; and Google Earth Engine CMIP6 Explorer (GEECE), allowing processing and extraction of CMIP6 projection data, including the ability to create custom model ensembles. Together GEEClimT and GEECE provide easy access to over 387 terabytes of data that can be output in commonly used spreadsheet (CSV) or raster (GeoTIFF) formats to aid subsequent offline analysis. Data included in the two tools include: 20 atmospheric, terrestrial and oceanic reanalysis data products; a new dataset of annual resolution climate variables (comparable to WorldClim) calculated from ERA5-Land data for 1950-2022; and CMIP6 climate projection output for 34 model simulations for historical, SSP2-4.5 and SSP5-8.5 scenarios. New data products can also be easily added to the tools as they become available within the Google Earth Engine Data Catalog. Five case studies that use data from both tools are also provided. These show that GEEClimT and GEECE are easily expandable tools that remove multiple barriers to entry that will open use of climate reanalysis and projection data to a new and wider range of users.

Nighttime satellite imagery were accessed via Google Earth Engine). Version 4 of the DMSP-OLS Nighttime Lights Time Series consists of cloud-free composites made using all the available archived DMSP-OLS smooth resolution data for calendar years. In cases where two satellites were collecting data - two composites were produced. The products are 30 arc second grids, spanning -180 to 180 degrees longitude and -65 to 75 degrees latitude. Several attributes are included - we used stable_lights which represents lights from cities, towns, and other sites with persistent lighting, including gas flares. Ephemeral events, such as fires have been discarded. The background noise was identified and replaced with values of zero.These data were provided to Google Earth Engine by teh National Centers for Environmental Information - National Oceanic and Atmospheric Administration of the United States (see Supporting Documentation).CANUE staff exported the annual data and extracted values of annual mean nighttime brightness for all postal codes in Canada for each year from 1992 to 2013 (DMTI Spatial, 2015).

Monthly Aggregated NEX-GDDP Ensemble Climate Projections: Historical (1985–2005) and RCP 4.5 and RCP 8.5 (2006–2080) This dataset is a monthly-scale aggregation of the NEX-GDDP: NASA Earth Exchange Global Daily Downscaled Climate Projections processed using Google Earth Engine (Gorelick 2017). The native delivery on Google Earth Engine is at the daily timescale for each individual CMIP5 GCM model. This dataset was created to facilitate use of NEX-GDDP and reduce processing times for projects that seek an ensemble model with a coarser temporal resolution. The aggregated data have been made available in Google Earth Engine via 'users/cartoscience/GCM_NASA-NEX-GDDP/NEX-GDDP-PRODUCT-ID_Ensemble-Monthly_YEAR' (see code below on how to access), and all 171 GeoTIFFS have been uploaded to this dataverse entry. Relevant links: https://www.nasa.gov/nex https://www.nccs.nasa.gov/services/data-collections/land-based-products/nex-gddp https://esgf.nccs.nasa.gov/esgdoc/NEX-GDDP_Tech_Note_v0.pdf https://developers.google.com/earth-engine/datasets/catalog/NASA_NEX-GDDP https://journals.ametsoc.org/view/journals/bams/93/4/bams-d-11-00094.1.xml https://rd.springer.com/article/10.1007/s10584-011-0156-z#page-1 The dataset can be accessed within Google Earth Engine using the following code: var histYears = ee.List.sequence(1985,2005).getInfo() var rcpYears = ee.List.sequence(2006,2080).getInfo() var path1 = 'users/cartoscience/GCM_NASA-NEX-GDDP/NEX-GDDP-' var path2 = '_Ensemble-Monthly_' var product product = 'Hist' var hist = ee.ImageCollection( histYears.map(function(y) { return ee.Image(path1+product+path2+y) }) ) product = 'RCP45' var rcp45 = ee.ImageCollection( rcpYears.map(function(y) { return ee.Image(path1+product+path2+y) }) ) product = 'RCP85' var rcp85 = ee.ImageCollection( rcpYears.map(function(y) { return ee.Image(path1+product+path2+y) }) ) print( 'Hist (1985–2005)', hist, 'RCP45 (2006–2080)', rcp45, 'RCP85 (2006–2080)', rcp85 ) var first = hist.first() var tMax = first.select('tasmin_1') var tMin = first.select('tasmax_1') var tMean = first.select('tmean_1') var pSum = first.select('pr_1') Map.addLayer(tMax, {min: -10, max: 40}, 'Average min temperature Jan 1985 (Hist)', false) Map.addLayer(tMin, {min: 10, max: 40}, 'Average max temperature Jan 1985 (Hist)', false) Map.addLayer(tMean, {min: 10, max: 40}, 'Average temperature Jan 1985 (Hist)', false) Map.addLayer(pSum, {min: 10, max: 500}, 'Accumulated rainfall Jan 1985 (Hist)', true) https://code.earthengine.google.com/5bfd9741274679dded7a95d1b57ca51d Ensemble average based on the following models: ACCESS1-0,BNU-ESM,CCSM4,CESM1-BGC,CNRM-CM5, CSIRO-Mk3-6-0,CanESM2,GFDL-CM3,GFDL-ESM2G, GFDL-ESM2M,IPSL-CM5A-LR,IPSL-CM5A-MR,MIROC-ESM-CHEM, MIROC-ESM,MIROC5,MPI-ESM-LR,MPI-ESM-MR,MRI-CGCM3, NorESM1-M,bcc-csm1-1,inmcm4 Each annual GeoTIFF contains 48 bands (4 variables across 12 months)— Temperature: Monthly mean (tasmin, tasmax, tmean) Precipitation: Monthly sum (pr) Bands 1–48 correspond with: tasmin_1, tasmax_1, tmean_1, pr_1, tasmin_2, tasmax_2, tmean_2, pr_2, tasmin_3, tasmax_3, tmean_3, pr_3, tasmin_4, tasmax_4, tmean_4, pr_4, tasmin_5, tasmax_5, tmean_5, pr_5, tasmin_6, tasmax_6, tmean_6, pr_6, tasmin_7, tasmax_7, tmean_7, pr_7, tasmin_8, tasmax_8, tmean_8, pr_8, tasmin_9, tasmax_9, tmean_9, pr_9, tasmin_10, tasmax_10, tmean_10, pr_10, tasmin_11, tasmax_11, tmean_11, pr_11, tasmin_12, tasmax_12, tmean_12, pr_12 *Gorelick, N., Hancher, M., Dixon, M., Ilyushchenko, S., Thau, D. and Moore, R., 2017. Google Earth Engine: Planetary-scale geospatial analysis for everyone. Remote Sensing of Environment, 202, pp.18–27. Project information: SEAGUL: Southeast Asia Globalization, Urbanization, Land and Environment Changes http://seagul.info/ https://lcluc.umd.edu/projects/divergent-local-responses-globalization-urbanization-land-transition-and-environmental This project was made possible by the the NASA Land-Cover/Land-Use Change Program (Grant #: 80NSSC20K0740)

What is SEPAL?

SEPAL (https://sepal.io/) is a free and open source cloud computing platform for geo-spatial data access and processing. It empowers users to quickly process large amounts of data on their computer or mobile device. Users can create custom analysis ready data using freely available satellite imagery, generate and improve land use maps, analyze time series, run change detection and perform accuracy assessment and area estimation, among many other functionalities in the platform. Data can be created and analyzed for any place on Earth using SEPAL.

https://data.apps.fao.org/catalog/dataset/9c4d7c45-7620-44c4-b653-fbe13eb34b65/resource/63a3efa0-08ab-4ad6-9d4a-96af7b6a99ec/download/cambodia_mosaic_2020.png" alt="alt text" title="Figure 1: Best pixel mosaic of Landsat 8 data for 2020 over Cambodia">

Figure 1: Best pixel mosaic of Landsat 8 data for 2020 over Cambodia

SEPAL reaches over 5000 users in 180 countries for the creation of custom data products from freely available satellite data. SEPAL was developed as a part of the Open Foris suite, a set of free and open source software platforms and tools that facilitate flexible and efficient data collection, analysis and reporting. SEPAL combines and integrates modern geospatial data infrastructures and supercomputing power available through Google Earth Engine and Amazon Web Services with powerful open-source data processing software, such as R, ORFEO, GDAL, Python and Jupiter Notebooks. Users can easily access the archive of satellite imagery from NASA, the European Space Agency (ESA) as well as high spatial and temporal resolution data from Planet Labs and turn such images into data that can be used for reporting and better decision making.

National Forest Monitoring Systems in many countries have been strengthened by SEPAL, which provides technical government staff with computing resources and cutting edge technology to accurately map and monitor their forests. The platform was originally developed for monitoring forest carbon stock and stock changes for reducing emissions from deforestation and forest degradation (REDD+). The application of the tools on the platform now reach far beyond forest monitoring by providing different stakeholders access to cloud based image processing tools, remote sensing and machine learning for any application. Presently, users work on SEPAL for various applications related to land monitoring, land cover/use, land productivity, ecological zoning, ecosystem restoration monitoring, forest monitoring, near real time alerts for forest disturbances and fire, flood mapping, mapping impact of disasters, peatland rewetting status, and many others.

The Hand-in-Hand initiative enables countries that generate data through SEPAL to disseminate their data widely through the platform and to combine their data with the numerous other datasets available through Hand-in-Hand.

https://data.apps.fao.org/catalog/dataset/9c4d7c45-7620-44c4-b653-fbe13eb34b65/resource/868e59da-47b9-4736-93a9-f8d83f5731aa/download/probability_classification_over_zambia.png" alt="alt text" title="Figure 2: Image classification module for land monitoring and mapping. Probability classification over Zambia">

Figure 2: Image classification module for land monitoring and mapping. Probability classification over Zambia

The dataset comprises a Landsat-derived assessment of monthly surface water extent within the study area (California's greater Central Valley). The surface water dataset is based on the algorithm for the Dynamic Surface Water Extent (DSWE) (Jones, 2019), which was adapted to the Google Earth Engine JavaScript environment. The level of spatial aggregation is by level-8 hydrologic unit code (HUC).