Gio Global Land Component - Lot I Operation of the Global Land Component

Transcription

1 Gio Global Land Component - Lot I Operation of the Global Land Component Framework Service Contract N (JRC) ALGORITHM THEORETHICAL BASIS DOCUMENT BURNED AREA VERSION 1 Issue I1.01 Organization name of lead contractor for this deliverable: University of Leicester Book Captain: Dr. Kevin Tansey Contributing Authors:

2 Dissemination Level PU Public X PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services) Date: Page: 2 of 103

3 Document Release Sheet Book captain: Kevin Tansey Sign Date: Approval: Roselyne Lacaze Sign Date: Endorsement: M. Cherlet Sign Date Distribution: Date: Page: 3 of 103

4 Change Record Issue/Rev Date Page(s) Description of Change Release All I All Geoland2 document, Issue I1.10, Description of the Burnt Areas (BA) algorithm based upon SPOT.VGT (Version 1) Move geoland2 document into Global Land document I1.00 I1.01 Date: Page: 4 of 103

5 TABLE OF CONTENTS 1 Background of the document Executive Summary Scope and Objectives Content of the document Related documents Applicable documents Input Output Review of Users Requirements Methodology Description Overview The retrieval Algorithm Outline Basic underlying assumptions Alternative methodologies currently in use Related and previous applications Input data Output product Seasonality files Methodology Limitations Quality Assessment Risk of failure and Mitigation measures References ANNEX ANNEX A g2_bae_v1_1_degree.csh Makefile used to compile the c program source code Input_dates.txt Julian_day_list.txt Dekad_list.txt ANNEX B Date: Page: 5 of 103

6 6.2.1 g2_ burnt_area_read_hdf.csh g2_ burnt_area_snip.c g2_ burnt_area_make_envi_header.c g2_ burnt_area_resample.c g2_ burnt_area_short2.c ANNEX C g2_ burnt_area_cloud_snow_mask.c g2_ burnt_area_erode_mask.c g2_ burnt_area_make_raster.c g2_ burnt_area_vza_mask.c g2_ burnt_area_cloud_shadow_mask.c g2_ burnt_area_mir_saturation_mask.c g2_ burnt_area_sun_shadow_mask.c g2_ burnt_area_apply_mask.c g2_ burnt_area_add_rasters.c ANNEX D g2_ burnt_area_algorithm.c ANNEX E g2_ burnt_area_season_metric_aggregation_count.c g2_ burnt_area_season_metric_runing_average.c g2_ burnt_area_season_metric_calculator.c g2_ burnt_area_season_metric_dis-aggregation.c g2_ burnt_area_season_metric_reporting.c g2_ burnt_area_float2.c report_fire_season_status_for_dekad_90_ending_ txt report_fire_event_database_to_dekad_90_ending_ txt Date: Page: 6 of 103

7 List of Figures Figure 1: Workflow of the GIO_GL burned area algorithm (v1) for use with SPOT VGT data Figure 2: Comparison between L3JRC (red) and Global Land (green) fire pixel counts for the period 1 April 2000 to 31 December Figure 3: Comparison between Global Land 2008 (red) and Global Land 2000 (green) fire pixel counts for the period 1 April to 31 December for each year Date: Page: 7 of 103

8 List of Tables Date: Page: 8 of 103

9 List of Acronyms GMES VITO BA GL FDOB BRDF SPOT MODIS SMAC SAA SZA VAA VZA MIR NIR Global Monitoring for Environment and Security Vision on Technology Burned Area Global Land First Date of Burn (Detection) Bidirectional reflectance distribution function Satellite Pour l'observation de la Terre Moderate Resolution Imaging Spectroradiometer Simplified Method for Atmospheric Correction Sun azimuth angle Sun zenith angle. Viewing azimuth angle Viewing zenith angle. Middle Infrared Near Infrared Date: Page: 9 of 103

10 1 BACKGROUND OF THE DOCUMENT 1.1 EXECUTIVE SUMMARY The Global Land (GL) Component in the framework of GMES Initial Operations (GIO) is earmarked as a component of the Land service to operate a multi-purpose service component that will provide a series of bio-geophysical products on the status and evolution of land surface at global scale. Production and delivery of the parameters are to take place in a timely manner and are complemented by the constitution of long term time series. The GL burned area algorithm was originally described by Tansey et al., 2008 for the region of continental Africa. The algorithm was adapted from its initial form as developed by D. Ershov and colleagues under contract to the Joint Research Centre of the European Commission in the Global Burned Area (GBA) 2000 project (Tansey et al., 2004 a and b). This particular algorithm was used successfully over a wide geographical area on a number of different vegetation types for northern Asia, parts of Europe and South America as a processing module in the GBA2000 product. Subsequent research showed that this single algorithm could be adapted for application at the global scale and was used in the L3JRC product. The algorithm was built to process SPOT VGT data A modified version was implemented within the context of the geoland2 project and implemented into the Copernicus Global Land service (v1 was applied global and v0 over Africa). V1 was implemented and subsequently modified with aggregation into a 10-day product with near-real time dissemination. V1 features seasonality and improved algorithm processing time and cloud masking. Daily synthesis of SPOT VGT data (S1) was processed in Near-Real-Time (NRT) and historical (HIST). V1 extends the time scale of processing providing additional years than what is available for the L3JRC product. Over 13 years of burned area data have been processed. This document describes the method used to produce the Version 1 of the burned area product in the Copernicus Global Land service. 1.2 SCOPE AND OBJECTIVES The scope of this document is to describe the necessary theoretical basis that underpins the implementation of Version 1 of the Copernicus Global Land burned area product. Furthermore, pseudo-code is provided to support the operational processing. 1.3 CONTENT OF THE DOCUMENT This document is structured as follows: Chapter 2 provides the users requirements Date: Page: 10 of 103

11 Chapter 3 describes the algorithm Chapter 4 identifies the risks and the mitigation measures Chapter 5 contains the bibliography Programme code is provided in Annex. 1.4 RELATED DOCUMENTS Applicable documents AD1: Annex II Tender Specifications to Contract Notice 2012/S of 7 th July 2012 AD2: Appendix 1 Product and Service Detailed Technical requirements to Annex II to Contract Notice 2012/S of 7 th July Input Document ID GIOGL1-ServiceSpecifications Descriptor Service Specifications of the Global Component of the Copernicus Land Service Output Document ID GIOGL1-PUM_BAV1 GIOGL1-VR_BAV1 Descriptor Product User Manuals summarizing all information about BA Version 1 product Validation Report describing the results of the scientific quality assessment of the BA V1 product Date: Page: 11 of 103

12 2 REVIEW OF USERS REQUIREMENTS According to the applicable document [AD2], the user s requirements relevant for the Burned areas product are: Definition: The user requirements for burned area products are for 10-day spatial products delineating the area burned over a period since These maps should be robustly validated where possible, given the constraints of high resolution image availability. A seasonality metric, requested by users has been specified and includes reference to a 10-day time period within each year when a fire season started, peaked and ended. Furthermore, the occurrence of these fire seasons is recorded in a text format database. Geometric properties: The product shall be provided in a geographic lat-lon coordinate system with a pixel spacing of 1/112 of a degree. The product covers an area below 70 degrees N to 55 degrees south. Geographical coverage: Global coverage is requested. Accuracy requirements: None Date: Page: 12 of 103

13 3 METHODOLOGY DESCRIPTION 3.1 OVERVIEW There are 2 versions of the burned area product as follows: V0: An implementation of the L3JRC burned area algorithm (Tansey et al., 2008) for the region of continental Africa. SPOT VGT S1 data will be processed in NRT and the product is aggregated into 10-day periods. The validation of the product has already been undertaken and reported. There are no Quality or BA-OBS products in this release. V1: A modification of the L3JRC algorithm, taking into account user feedback received over the past three years. This includes removing the need to use global land cover products in the processing, improvement in the processing time, improvement in the cloud masking process and modification for near-real time production. In addition, a seasonality metric will be introduced to provide estimates, of the start, peak and end of the fire season within a 1- degree grid. This product will be validated using methods reported in this document. A quality flag products includes data on the number of clear (not cloud, cloud shadow, swath gap, topographic shadow, water, snow, saturated) pixels made of each pixel over a 10 day period. For the v1 product a single algorithm applicable to the whole globe is used to classify burnt areas from SPOT VEGETATION reflectance data. The original burnt area algorithm (BAE) was developed by D. Ershov and colleagues under contract to the Joint Research Centre of the European Commission in the Global Burned Area (GBA) 2000 project (Tansey et al., 2004 a and b). This particular algorithm was used successfully over a wide geographical area on a number of different vegetation types for northern Asia, parts of Europe and South America as a processing module in the GBA2000 product. Subsequent research showed that this single algorithm could be adapted for application at the global scale and was used in the L3JRC product. V1 has been subsequently modified with aggregation into a 10-day product with near-real time dissemination. The implementation in the Copernicus Global Land service extends the time scale of processing providing additional years than what is available for the L3JRC product. 3.2 THE RETRIEVAL ALGORITHM Outline The retrieval algorithm comprises 4 main parts. Part 1 contains the extraction of the input data from its native format. Part 2 contains the pre-processing of the data. Part 3 contains the burned area Date: Page: 13 of 103

14 algorithm, and Part 4 contains the season metric computation. The workflow scheme of the algorithm is shown in Figure 1. SPOT VGT S1 Global Data Data extraction and formatting module Data pre-processing module to remove pixels contaminated by cloud, shadow etc. Data processing module to estimate the burned area from input SPOT VGT data Burned area seasonality processing module Figure 1: Workflow of the GIO_GL burned area algorithm (v1) for use with SPOT VGT data Basic underlying assumptions The assumptions we made about source data and processing chain are that: Date: Page: 14 of 103

15 The satellite platform, which has a polar sun synchronous orbit with 5 day repeat, is sufficient coverage for detecting daily (or 10 day composite) burns using the burned area algorithm The input data used is consistent and has been corrected for sensor drift / decay etc. The SPOT-VEGETATION input data is radiometric and geometrical corrected based on calibration parameters from the raw sensor data, and hence provide consistent values over time for both sensors VGT-1 and VGT-2. These parameters are stored in so called PCI files:(1) the geometrical file contains the viewing directions for one or several spectral bands at different latitudes, and the translations at different latitudes between the other spectral bands and the spectral band for which viewing directions are delivered; (2) the radiometrical file contains detector quality indicators, interdetector equalization coefficients, dark currents, non-linearity coefficients; (3) the absolute calibration file contains absolute calibration coefficients, solar equivalent irradiance, analog gain; and used during corrections. Pre-processing has the ability to identify non contaminated pixels by extracting cloud / cloud shadow / snow / topographic shadow and saturated pixels within the image. Preprocessing also removes observations (pixels) made at viewing zenith angles greater than 45 degrees. The burned area algorithm is consistent at picking up the drop in reflectance in the near infrared wavelengths which forms the main component of the detection algorithm. The processing is applied to the full year over the majority of the Earth s surface. However, during the winter period in northern latitudes, there are times when the algorithm is switched off. Information on how to use the product is described in the associated Product User Manual (GIOGL1-PUM_BAV1) for v1 of the product Alternative methodologies currently in use A list of burned area data sets available to the community area available at the following web site: The most common products in use are the L3JRC and the MODIS product (Roy et al., 2005; 2008). There is a lot of uncertainty about accuracy in all available products and a more complete validation and intercomparison will shed more light on the situation. It may be the case that users in the future might need to use a combination of products. Date: Page: 15 of 103

16 3.2.2 Related and previous applications The differences between v1 of the BAE product and the original L3JRC algorithms are as follows: Removal of the need to use a land cover product as part of the pre-processing steps. V0 of the algorithm used the University of Maryland land cover product in the cloud and snow masking algorithms. Work has been undertaken to use combined thresholds. Because of this the cloud and snow mask algorithms have been modified. The viewing zenith angle mask has been set to 45 degrees (previously 50.5 degrees). This is to further reduce the BRDF impact. It should be noted that a 45 degree threshold existed anyway in the main burnt area detection algorithm, so we are now being consistent. The cloud height is set to 6km and not 10km for calculating cloud shadow affected pixels, as the majority of clouds are below this height. Previously, cloud free pixels were being masked. The thin cloud and fire smoke mask step has been removed. After review, it was felt that this mask was removing good quality data. The modified cloud mask should capture all types of cloud. The burnt area algorithm looked at regions of 200x200km in size on a regional window basis. To allow us to report statistics and season metrics of a basis that is more meaningful, the algorithm has been modified to work on a 1 x 1 degree basis (approximately 112x112 pixels). Tests revealed that there was little difference between applying the algorithm over a 200 and 112 sized window. A season metric descriptor is provided. This is described in more detail in following sections. The season metric aims to provide estimates of the 10-day period in which fire activity exceeded a pixel (area) count threshold, the maximum pixel count and when the pixel (area) count dropped below a determined threshold. This is estimated over a 1 x 1 degree window. The season metric measure feeds into performing a season reset over a 1 x 1 degree area. More details are available in following sections. As a result of this step, there is no need to reset the global burned area product on the 1 st April every year. It furthermore allows for land surfaces to be detected as being burned twice in any one year, which may be the case in many regions of the world. Thresholds of pixel value used in the algorithm are based on the fraction of reflectance (indicated as a floating point number between 0 and 1). This change was undertaken so that any re-calibration of the instrument will not mean that new pixel values (originally scaled 0 to 2000) will not have to be computed. The region of interest covered by the product is from 70 degrees North to 50 degrees South, and covers all degrees of longitude. Date: Page: 16 of 103

17 In the absence of a global land cover map, a land/water mask derived from the S1 products is used. However, because the data/no data boundary in the S1 product occurs approximately 6 pixels out into the sea, it was necessary to trim this buffer back to the coastline. A quality flag indicator stating the the number of clear land surface observations made over a 10 day period. A pixel determined as being of good quality is passed into the main burned area detection algorithm module. This product can help determine if sufficient observations of the land surface have been made in a 10-day period or whether there has been persistent cloud cover for example. There is a temporal switch in the algorithm that observes the following criteria: o 1 October to 31 March inclusive: Process regions from 50 degree S to <= 45 degrees N. o 1 April to 30 April: Process regions from 50 degree S to <= 51 degrees N (note 51 and not 50) o o o o 1 May to 31 May: Process regions from 50 degree S to <= 55 degrees N 1 June to 30 June: Process regions from 50 degree S to <= 60 degrees N 1 July to 31 July: Process regions from 50 degree S to <= 65 degrees N 1 August to 30 September Process all regions Input data Global, daily, atmospheric corrected (using Simplified Method for Atmospheric Correction (SMAC) code (see Rahman and Dedieu, 1994)) S1 data were used as input. VGT-S1 products (daily synthesis) are composed of the 'best' ground reflectance measurements of all segments received during one day for the entire surface of the Earth. This is done for each of the images covering the same geographical area. The areas distant from the equator have more overlapping parts so the choice for the best pixel will be out of more data. These products provide data from all spectral bands, the NDVI and auxiliary data on image acquisition parameters. The system uses the radiometric corrected products, as defined in Henry and Meygret (2001) Output product Contaminated Pixel dekad composite (obs_passed_dekad) The unsigned (8 bits) shows the Number of Observations not used to detect burns within a given dekad, hence filtered out due to artefacts found in the pre-processing step. As such it should be read as the inverse of the Number Of Clear Observations (NMOD); so the lower the value, the more observations are used to detect a burn. Date: Page: 17 of 103

18 The physical range of obs_passed_dekad is [0, <number of days in the dekad>], as is the Digital Number range. The value indicates: 0 = all days in the dekad provided data (CP mask = 0 for all days) 1 = one day in the dekad does not provide data... <number of days in the dekad> = no days in the dekad provided data, so the burn could not be detected 254 = ocean flag Burnt Area dekad composite (ba_product_dekad) This unsigned (8 bits) provides the number of burn detections in the given dekad. The physical range of ba_product_dekad is [0, <number of days in the dekad>], as is the Digital Number range. Note that a value 0 does not necessarily mean the pixel was not burnt; it might have been filtered out by the Number of Clear Observation (obs_passed_dekad) mask. The value indicates: 0 = the pixel was not burnt in the dekad (BA = 0 for all days) 1 = for at least one day in the dekad the pixel was burnt 254 = ocean flag First Day of Burn in the dekad (fdob_product_dekad) This unsigned integer (16 bits) provides the First Day of Burn (FDOB) in the given dekad. The physical range of FDOB is [0, 65535], as is the Digital Number range. The value indicates: 0 = no burn scar detected in the dekad 254 = ocean flag YYDDD in range [18000, 65535] = the burn scar was detected at day YYDDD; where YY represents the Julian calendar year since 1980 and DDD is day of year; YYDDD is a date in the dekad E.g. a coding value of represents a FDOB date of , and will be present in the file g2_biopar_ba_ _<area>_vgt_v1.3.h5:fdob_product_dekad. Note that this coding value will disappear in the next dekad, hence in the file g2_biopar_ba_ _<area>_vgt_v1.3.h5:fdob_product_dekad. Date: Page: 18 of 103

19 First Day of Burn just after Season Reset (fdob_product_fire_season) This unsigned integer (16 bits) provides the First Day of Burn (FDOB) over one or (typical) more dekads within the season, hence a cumulated FDOB value, comparable to V0. Dates are reset by seasonal resets. The physical range of FDOB is [0, 65535], as is the Digital Number range. The value indicates: 0 = no burn scar detected, or the burn was reset 254 = ocean flag YYDDD in range [18000, 65535] = the burn scar was detected at day YYDDD; where YY represents the Julian calendar year since 1980 and DDD is day of year E.g. a coding value of represents a FDOB date of , and will be present in the file g2_biopar_ba_ _<area>_vgt_v1.3.h5:fdob_product_fire_season. Note that this coding value will re-appear in the next dekad, hence in the file g2_biopar_ba_ _<area>_vgt_v1.3.h5:fdob_product_fire_season, unless the season has been reset during this last dekad Seasonality files As explained in Section Erreur! Source du renvoi introuvable., the Seasonality algorithm only activates at the fifth dekad. This means that in the first four dekads of a run, the seasonality files are not available. Both files use one line per 1 x 1 degree grid cell (112 x 112 pixels). Each line starts with its longitude and latitude. Of course only the longitude and latitude ranges within the represented continent are stored in the file. Every line represents a longitude one degree more to the east, or one degree more to the south if the previous line is at the eastern border of the continent. The seasonality files use dekad numbers, where dekad 1 is the dekad ending Dekad counting starts in To calculate the date that is represented by a dekad number, one could use: Year = (dekad number / 36) Dekad_in_year = (dekad_number (Year 1980)*36) Season Status file This text file provides the main season metrics. For each 1 x 1 degree grid cell (112x112 pixels) is provided in this order: longitude, latitude (centre of pixel) fire season status :0 = out of season, 1 = in season (status), Date: Page: 19 of 103

20 start of season dekad (sos), maximum of season dekad (smax), end of season dekad (eos), maximum count of 1x1 km pixels (area in square km) detected as burnt in season inside the 1x1 degree grid cell (smax_no), number of seasons since processing began (scount) season reset mask : 0=reset; 1=no reset (sreset). Note that the information is provided as detected, e.g. if a season-start was detected but not the max or end yet, the sos number is provided while the smax and eos numbers are set to zero. An example part of a season status file of dekad 766 (the dekad ending , counted from ) is shown below: longitude, latitude, status, dekad of start of season, dekad of max of season, dekad of end of season, max count of season, number of seasons, reset flag. Longitude Latitude status sos smax eos smax_no scount sreset It shows that the area of 83 E, 46 N is not in a season (first column = status = 0) and will not reset the FDOB of its area (reset = 1). The tile of 84 E, 46 N is in season (status = 1), since the current dekad 766. At dekad 766 it had its largest number of burnt pixels, 247. Its end dekad is 0 as it has not ended yet. It counts a single season (the second last column = 1). Also, as the season is still running, it will not reset the FDOB. The next area of 85 E, 46 N is not in season anymore but recently was. It had a season from dekad 764 to 766, with a maximum of 535 pixels in dekad 764. It counts 2 seasons in total. Also, it resets the FDOB of its area this dekad as its reset flag is 0. Season Event database file For each 1x1 degree grid cell (112x112 pixels), this file collects the seasons information. The user can check the season_status file to learn the seasons status. For each degree grid cell is provided: Longitude and Lattitude in degrees For every ended fire season, a triple data entry is added to the degree grid cell: Start_of_season dekad (sos) : the dekad that triggered the fire season start Peak_of_season dekad (pos): the dekad that shows the maximum count of pixels detected as burnt in the season, hence the dekad that corresponds to the smax_no of the season_status file. End_of_season dekad (eos) : the dekad that ended the fire season Date: Page: 20 of 103

21 Note this additional information is only provided when the season-end is detected. If no seasonend is detected yet, the information is left blank. Note that multiple season-ends detections are represented by multiple triple data entries separated by the acter ;. An example part of a season_event_database file is described below: longitude, latitude, start of season dekad (sos), peak of season dekad (pos), end of season dekad (eos) 1 : Longitude Lattitude sos pos eos ; sos pos eos ; , 765, 767 ; , 658, 667 ; 766, 766, 767 ; The dekad file shown above is of dekad 767 ( ). The first few lines, representing 35 E, 46 N to 38 E, 46 N, do not show a finished season. The user should check the season_status file to see if the degree tile is in or out of a season. In the area around 39 E, 46 N, a season started in dekad 765 ( ), had a peak in that dekad, and lasted until dekad 767 ( ). The grid cell 40 E, 46 N represents two seasons, a first one started in dekad 654 and ended in 667, and a second season started in dekad 766 ( ) and ended in dekad 767. Both tiles are now out of season Methodology The methodology is divided into a number of sections, data extraction, pre-processing, burned area algorithm implementation and season metric calculation. Each step is described in more detail below. Source code (written in the c language and controlled by a c shell script) is provided in Annexes. There are a number of programs, directories and data sets that must be located within the working directory for these programs to work. The files needed are shown in Annex A. This includes the controlling c shell script is available in Annex A. The makefile use to compile the c programs is also available in Annex A. 1 The headers in the demonstration dataset for the season_event_database text file will be improved for the full production. Date: Page: 21 of 103

22 Data Extraction The native SPOT-VGT data are shipped in HDF format. The data extraction step extracts the necessary image files from the HDF file. The necessary files include the spectral data from bands B0, B2, B3 and MIR and the angular data SAA (sun azimuth angle), SZA (sun zenith angle), VAA (viewing azimuth angle) and VZA (view zenith angle). From the larger global data set a sub-region window covering (360 degrees) pixels by (120 degrees) lines starting at 70 degrees North is extracted. Image file headers are created. Quicklooks are generated so that the user can visually interpret the data to ensure that the data is consistent. Relevant source code programs are as follows (see Annex B): g2_burnt_area_read_hdf.csh interprets the HDF file and extracts the image data as generic binary. g2_burnt_area_snip.c Extracts a sub-region. g2_burnt_area_make_envi_header.c generates an ENVI (commercial image processing software) header. g2_burnt_area_resample.c Resamples the spectral image data to a user specified ratio for quicklook generation. g2_burnt_area_short2.c - Resamples the spectral image data from integers to byte for quicklook generation. Standard linux binaries: convert, sed, awk, dd (byte swap) as well as others Data pre-processing The aim of the pre-processing module is to remove any data (pixels) that might impact on the successful detection of burned areas. Source code are presented in Annex C (if not already in Annex B). The following steps are undertaken: Cloud and snow masks are generated based on thresholds at 0.45 μm (B0) and 1.66 μm (MIR) wavelengths. Cloud free pixels are detected if the B0 band pixel reflectance is less than OR the MIR band pixel reflectance is less than Snow free pixels are detected if the B0 band pixel reflectance is less than OR the MIR band pixel reflectance is greater than The cloud and snow masks are further eroded by 1 pixel in all directions to ensure that pixels that might contain cloud or snow be removed from further analysis. This step is undertaken by the g2_burnt_area_cloud_snow_mask.c and g2_burnt_area_erode_mask.c programs (Annex C). As explained in Section above in earlier versions of the algorithm, problems were encountered in coastal regions, especially given that the SPOT VGT data land-water mask was never flush against the coastline, but in many cases up to 6 pixels offshore. It is therefore necessary to ensure that water is effectively masked out. The VZA product is Date: Page: 22 of 103

23 used as a baseline which illustrates on any day where observations of the surface have been made. 6 iterations of an erosion tool that erodes water pixels are implemented. This step is undertaken by the g2_burnt_area_erode_mask.c and g2_burnt_area_make_raster.c programs (Annex C). Observations of the ground surface are restricted to viewing zenith angles of 45 degrees of less. This was implemented as a pre-processing step to limit the impacts of the Bidirectional reflectance distribution function (BRDF) on pixel reflectance values. This step is undertaken by the g2_burnt_area_vza_mask.c program (Annex C). A cloud shadow mask is derived, using the eroded cloud mask produced in a previous step. In this step, we also use solar (SAA, SZA) and viewing (VAA, VZA) angles. To reduce the amount of processing time, we assume a constant cloud height of 6 km. This value has been reduced from 10km in previous versions. This decision was undertaken after examining evidence for the average height of clouds that cast shadows and the need to preserve shadow-free pixels. This step is undertaken by the g2_burnt_area_cloud_shadow_mask.c program (Annex C). A binary mask is then derived of all pixels that appear saturated in the 1.66 μm channel, with a reflectance value of 0.5 or above. This step was considered necessary as the data quality flag for this layer in the SMA product shipped with the S1 data was deemed not fit for purpose (over commissioned pixels). This step is undertaken by the g2_burnt_area_mir_saturation_mask.c program (Annex C). A sun shadow mask is produced from the GTOPO 30 global DEM. The use of SRTM was considered by the data volumes would be massive with little perceived improvement. We compute aspect and slope and use a threshold that assumes a pixel will be in the shade if the sun incidence angle is above 75 degrees. An evaluation of this mask shows that only very mountainous regions of the world are masked. This step is undertaken by the g2_burnt_area_sun_shadow_mask.c program (Annex C). The various masks are combined to create a masked pixel product (1=good data; 0=poor data) that is computed on a daily basis. The file name has the extension *obs_passed_preprocessing_step. Header files are created and a quicklook product is generated for visual inspection if necessary. This step is undertaken by the g2_burnt_area_apply_mask.c program (Annex C). 10-day (dekad) composites of the mask products are generated so that users are able to derive the number of cloud free observations made of each pixel over this time period. This data is useful to understand that the number of observations of a surface may be limited and that this may result in a low burned area pixel count. This step is undertaken by the g2_burnt_area_add_rasters.c program and others already mentioned (Annex C). Date: Page: 23 of 103

24 Algorithm implementation The main processing algorithm makes use of a temporal index in the 0.83 μm (near infrared, NIR) channel. This index I is computed using the following method: where S1 NIR is the pixel value of the S1 daily product and IC NIR an intermediate composite product. The intermediate composite consists of averaged NIR reflectances derived from all observations prior to observation, from the date when the algorithm started to process the data to the image date under consideration. No calculation or detection is performed where S1 NIR or IC NIR equals zero. Mean and standard deviation values are computed for the index I over a window of 112 by 112 pixels (1 degree) ignoring all pixels with a value of zero or identified as being contaminated. A pixel is flagged as burnt if the pixel value in the 112 by 112 pixel array, I, is lower than the mean value minus two standard deviations. Two further checks are made on reflectance values in the 0.83 μm (B3) layer where the pixel reflectance must be less than 0.13 and 1.66 μm (MIR) layer where the pixel reflectance value must be greater than To compute the updated intermediate composite in the near infrared channel (IC NIR ), we first calculate the phase angle value that uses sun and viewing angles (both zenith and azimuth) to evaluate the suitability of a pixel to be used in future composites. If this test is passed, based on a threshold value, then the average between the existing composite value and the pixel value of the S1 product being analyzed is used to create the new value of the intermediate composite. If the test is not passed, then the output composite value is identical to the input composite value. Two dekad products are created and updated in this processing step. One contains the pixels that have been flagged as being burned (ba) during the 10-day period under consideration (file name containing *ba_product_dekad_*). The second contains a file value indicating the date of detection (dod) expressed as a Julian date for those pixels that were detected as being burned in the 10-day period under consideration (file name containing *dod_product_dekad_*). Various programs are utilised in this processing step, including g2_burnt_area_make_raster.c, g2_burnt_area_make_envi_header.c, g2_burnt_area_algorithm.c, g2_burnt_area_apply_mask.c, g2_burnt_area_add_rasters.c. These are available in Annex D unless previously described in Annexes B or C Season metric calculation The season metric calculation is performed at the end of a 10-day period. To perform the season metric calculation it is necessary to have 4 successive dekads (10-days) of processed burned area data available. This will enable the calculation of the moving average to be made. Furthermore, two consecutive moving average values must be available. Without these data sets, sections of this processing step will not execute and will move onto the next dates. In summary, we need 5 full Date: Page: 24 of 103

25 10-day periods for season metric data to be produced. As a consequence of this requirement, if there are significant gaps, for example where there is not likely to be any observations of the land surface over a 10-day period, then work around solutions might be necessary. One solution would be to re-start the processing after the data gap. The season metric is computed using a number of steps described below, source code is provided in Annex E if not reproduced elsewhere. The file dekad_list.txt allows the user to relate the dekad number to a calendar date (see Annex A for a sample). Taking the 10-day (dekad) composited burned area product at full resolution (documenting those pixels detected as a burned area over a dekad), we aggregate and count the number of pixels burned over a 1 degree grid cell (112 x 112 pixels), with the sum count taking the output pixel value. This step is undertaken by the g2_burnt_area_season_metric_aggregation_count.c program (Annex E). Calculate the moving average for the aggregated sum count products for the current dekad and the three previous dekad periods. The output product contains averaged fire count values over a 1 degree grid cell. This step is undertaken by the g2_burnt_area_season_metric_running_average.c program (Annex E). The season metric computation requires moving average products for the dekad under consideration and the previous dekad. A fire season is deemed to have started once 3% of the total number of pixels within a 1 degree grid cell has been detected as being burned based on the moving average value of four 10-day periods. Other threshold values were tested and this value deemed to provide a balance between not moving into a fire season and always being in a fire season based on a few residual detections. The season metric calculation aims to determine whether a fire season has been initiated, whether the region of the interest is still in (or not in) a fire season, or whether during the dekad of interest, the fire season has come to an end. Furthermore, if a fire season has been determined for a region of interest, then the algorithm determines the dekad in which the peak of the fire season occurred and the number of pixels (area) burned during that dekad period. In addition to the output products containing dekad values, a season flag product (0=not in fire season; 1=in fire season), the number of fire seasons that the region of interest has experienced and also a fire season reset product (described below). As well as binary outputs described under this bullet point, a text file is written to file that provides the fire season status at the point of time of the dekad period that is being processed. Furthermore, it presents the dekads that have triggered fire season start, maxima and end. The file name is report_fire_event_database_to_dekad_*_ending_yearmonthday.txt and is produced at the end of every dekad. An example is shown in Annex E. This step is undertaken by the g2_burnt_area_season_metric_calculator.c program (Annex E). The next step involves the dis-aggregation to full resolution, from the 1 degree grid, of the season reset mask that was derived from the previous step. A season reset means that the end of the fire season has taken place, confirmed by 1 degree grid region coming out of a fire season and staying out of season for 2 consecutive dekad periods. The consequence Date: Page: 25 of 103

26 of this step is that once the region has been reset then any pixel in the region can burn again. This step was necessary to ensure that repeat fires in a time period less than a year can be detected. The season reset mask is then applied to the full resolution burnt area products for input into the data processing and burned area algorithm. This step is undertaken by the g2_burnt_area_season_metric_dis-aggregation.c program (Annex E). After the reset mask has been created it is applied to the input_dod file that then allows the processing of the next 10-days of data to begin. This is a critical step as any degree grid cells that have been in a fire season but have not reported significant burn levels in the previous 20 days will now be reset and available for detection as being burnt again. A summary file is created at this point and written to the ba_products directory. It is date of detection file, but contains a summary of all of those pixels that have been detected as being burned within the currently active seasons across the globe. The dod values reported as not just for the dekad being processed. This file is also critical if any operational resetting is needed after a major error. The file name is _dod_season_product_dekad_90 for example, located in the ba_product directory. The season metric output products are available as binary products. However, tabulated text output is more easily interpretable across systems. Therefore a text file that reports season metrics every 10-days is generated. Fire season status, start of season (dekad), maximum of season (dekad), end of season (dekad), maximum count pixels (area) of season, season count since processing began and season reset mask (0=reset; 1=no reset) is provided for each 1 x 1 degree grid cell. The file name is report_fire_season_status_for_dekad_*_ending_yearmonthday.txt. This processing step is undertaken by the g2_burnt_area_season_metric_reporting.c, g2_burnt_area_apply_mask.c and g2_burnt_area_float2.c programs (Annex E) Directory structure of BA algorithm In this section the directory structures and critical start files are explained../input_dates.txt this file needs to be present in the working directory and edited to reflect the dates that need to to be processed (see Annex A)../julian_date_list.txt this file needs to be present in the working directory (see Annex A)../dekad_list.txt this file needs to be present in the working directory (see Annex A)../g2_bae_v1_1_degree.csh this file needs to be present in the working directory and must be executable. A user can run the full program by using the following command (see Annex A):./g2_bae_v1_1_degree.csh /$year$month$day/ - a temporary directory where daily S1 input data and stored and processed. If the date of the image does not exist on the archive, this directory will not be created. Date: Page: 26 of 103

27 ./quick_looks/ - directory containing jpeg quicklooks of the raw image data and also the obs_passed_preprocessing_step images../quality_flag/ - this directory contains quality flag products: $year$month$day_obs_passed_preprocessing_step daily pre-processing data mask of good/not good data. $year$month$day_obs_passed_preprocessing_step_for_dekad* - 10-day composites of pre-processed masks of good/not good data../intermediate_composites/ - this directory contains daily updated intermediate composite products, in the B2, B3 and MIR reflectance bands as required by the burned area algorithm. In case of failure, it is probably necessary to keep the products created at the end of each dekad, e.g _B2 etc../ba_products/ - this directory contains a variety of burned area products. In addition there are a number of temporary files that are used whilst the 10-day period is being processed: input_dod is a binary product that contains where pixel values represent the Julian date of the day of burn detection or a value of 0 if no detections have been made. This file is updated on a daily basis and at the end of a dekad after the season metric has been computed. Once a pixel has been detected as being burned, the pixel cannot be overwritten unless it is reset through the end of season metric calculation. Reference must be made to the year of processing so that the calendar date can be identified. yearmonthday_ba_product_dekad_* - is a binary product of the burned pixels detected within a 10-day time period, with values = 1 if burned and 0 if not burned. This product should be made available to the users. yearmonthday_dod_product_dekad_* - is a binary product of the burned pixels detected within a 10-day period and where the pixel value represents the Julian Date of detection. This product should be made available to the users. ba_product_agg_dekad_* - is the dis-aggregated (to 1 degree grid cell) version of the ba_product_dekad product that is used within the season metric calculation. The pixel value represents the sum count of burned pixels within a grid cell. yearmonthday_dod_season_product_dekad_* - is a binary product that is produced after the implementation of the season reset. Therefore, this file will not be present in the first 5 dekad periods that are processed. The burned pixels detected in the current fire season are indicated by the Julian Date of detection. This product should be made available to the users../dem_products/ - this directory contains slope and aspect products derived from the GTOPO30 global DEM and which are used for the computation of the sun shadow mask outlined in Section The files needed are g2_dem_slope and g2_dem_aspect. This directory and the files need to be in place before the algorithm is started. Date: Page: 27 of 103

28 ./season_metric/ - this directory contains a variety of season metric products. The two text files are described in Section and also in Annex E. In addition there are a number of binary files that are produced at the end of each 10 days of processing. They can all be made available to the user. ba_product_running_average_agg_dekad* - is a binary file with pixel values representing the moving average value of the past 4 dekad periods over a 1 degree grid cell. fire_season_count_dekad* - is a binary file with pixel values representing the number of fire seasons detected from the beginning of processing to the current date. fire_season_status* - is a binary file with pixel values representing the status of the fire season (1=in season; 0=not in season). fire_season_start_dekad* - is a binary file with pixel values representing a value that indicates the dekad period when the most current fire season started (see file dekad_list.txt for the look-up table). fire_season_max_burn_pixel_dekad* - is a binary file with pixel values representing a value that indicates the dekad period when the greatest number of burned pixels were detected (see file dekad_list.txt for the look-up table). fire_season_end_dekad* - is a binary file with pixel values representing a value that indicates the dekad period when the most recent fire season ended (see file dekad_list.txt for the look-up table). fire_season_max_burn_pixel_count* - is a binary file with pixel values representing a value that indicates the maximum number of pixels during the peak in the burned area detection period when the greatest number of burned pixels were detected (see file dekad_list.txt for the look-up table). fire_season_reset_mask_agg_dekad* and fire_season_reset_mask_dekad* - are two binary products that contain the season reset mask at 1 degree grid cell and full resolution respectively Limitations The approach has a number of limitations: 1. It uses fixed thresholds of reflectance to make decisions about candidate burned areas. Any changes in calibration or performance of the SPOT/VGT sensor may impact on the detection capacbility. 2. The user requirements may evolve in future iterations of the service and the product may not meet these user requirements. 3. The algorithm needs to be adaptable enough to evolve to input data from PROBA-V sensor and still deliverd burned are products. Date: Page: 28 of 103

29 4. The algorithm relies on the internal detection of snow, haze, cloud and cloud shadow. Ideally, these would be provided as quality layers in the SPOT VGT product with traceable methods of derivation 5. The product relies on a global digital elevation model. Hopefully updates in elevation modelling can be utilised. 3.3 QUALITY ASSESSMENT It is important to differentiate between validation of the operations during the development and production of the product and the scientific quality of the product. The former is of interest for systems development and efficient processing of data and the second is of interest to the users of the product. The results of the scientific validation of the product are described in the Validation Report [GIOGL1_VR-BAV1]. In this section, we analyse the results of an operational validation exercise. At this point it is worth reviewing the product development history. The GBA2000 was developed between 2001 and 2003 and was the development of multiple algorithms applied to 1 year of SPOT VGT data. The product was not scientifically validated. Publications describing this product were: Tansey, K., Grégoire, J-M., Binaghi, E., Boschetti, L., Brivio, P.A., Ershov, D., Flasse, S., Fraser, R., Graetz, D., Maggi, M., Peduzzi, P., Pereira, J.M.C., Silva, J., Sousa, A., and Stroppiana, D., 2004, A Global Inventory of Burned Areas at 1 Km Resolution for the Year 2000 Derived from Spot Vegetation Data. Climatic Change, 67, , doi: /s Tansey, K., Grégoire, J-M., Stroppiana, D., Sousa, A., Silva, J.M.N., Pereira, J.M.C., Boschetti, L., Maggi, M., Brivio, P.A., Fraser, R., Flasse, S., Ershov, D., Binaghi, E., Graetz, D. and Peduzzi, P., 2004, Vegetation burning in the year 2000: Global burned area estimates from SPOT VEGETATION data. Journal of Geophysical Research - Atmospheres, 109, D14S03, doi: /2003jd Stroppiana, D., Tansey, K., Grégoire, J-M., and Pereira, J.M.C., 2003, An algorithm for mapping burnt areas in Australia using SPOT-VEGETATION data. IEEE Transactions on Geoscience and Remote Sensing, 41, , doi: /TGRS Grégoire, J-M., Tansey, K., and Silva, J.M.N., 2003, The GBA2000 initiative: Developing a global burned area database from SPOT-VEGETATION imagery. International Journal of Remote Sensing, 24, , doi: / The L3JRC product was the subsequent implementation of a modified version of one of the GBA2000 algortihms to a 7-year SPOT VGT S1 data set. Modifications reflected user feedback and adaptation to global processing. Critically, it was necessary to transfer the algorithm code to a Date: Page: 29 of 103