Copernicus Global Land Operations · Copernicus Global Land Operations – Lot 1 Date Issued: 02.05.2017 Issue: I1.40 Copernicus Global Land Operations “Vegetation and Energy”

Copernicus Global Land Operations – Lot 1 Date Issued: 02.05.2017 Issue: I1.40

Copernicus Global Land Operations

“Vegetation and Energy” ”CGLOPS-1”

Framework Service Contract N° 199494 (JRC)

PRODUCT USER MANUAL

BURNED AREA AND SEASONALITY

COLLECTION 300M

VERSION 1

Issue 1.40

Organization name of lead contractor for this deliverable:

Book Captain: Bruno Smets (VITO)

Contributing Authors: Kevin Tansey (Univ. Leicester)

Davy Wolfs (VITO)

Tim Jacobs (VITO)


Document-No. CGLOPS1_PUM_BA300m-V1 © C-GLOPS Lot1 consortium

Issue: I1.40 Date: 02.05.2017 Page: 2 of 32

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)




Document Release Sheet

Book captain: Bruno Smets

Sign Date 02.05.2017

Approval: Roselyne Lacaze Sign Date 25.09.2017

Endorsement: Michael Cherlet Sign Date

Distribution: Public




Change Record

Issue/Rev Date Page(s) Description of Change Release

24.02.2016 All First issue I1.00

I1.00 16.03.2016

16

17

19, 20

Include Section 3.4 Roadmap

Include Table 2 Versioning

Include Table 4 and Table 5 of netCDF attributes

I1.10

I1.10 20.04.2016 18-23 Update file format and file content sections I1.20

I1.20 06.07.2016

15

17

27 29

Clarifications after external review:

- Limitations of the product

- Description of format

- Explanation of season event database file

- Add reference to quality assessment report

I1.30

I.30 02.05.2017 15,16,32

19,23

Updates for water masking

Added description of NetCDF Time Grid layer I1.40




TABLE OF CONTENTS

Executive Summary .................................................................................................................... 8

1 Background of the document ............................................................................................... 9

1.1 Scope and Objectives............................................................................................................... 9

1.2 Content of the document......................................................................................................... 9

1.3 Related documents ................................................................................................................. 9

1.3.1 Applicable documents .................................................................................................................................. 9

1.3.2 Input .............................................................................................................................................................. 9

1.3.3 External documents .................................................................................................................................... 10

2 Methodology Description .................................................................................................. 11

2.1 Overview .............................................................................................................................. 11

2.2 The retrieval Methodology .................................................................................................... 11

2.2.1 Basic underlying assumptions ..................................................................................................................... 11

2.2.2 Evolution of the method from SPOT VGT to PROBA-V Data ....................................................................... 12

2.3 Limitations of the Product ..................................................................................................... 14

2.4 Roadmap .............................................................................................................................. 14

3 Product Description ........................................................................................................... 15

3.1 File naming ........................................................................................................................... 15

3.2 File Format ............................................................................................................................ 16

3.3 Product Content .................................................................................................................... 17

3.3.1 Data File ...................................................................................................................................................... 17

3.3.2 Quicklook .................................................................................................................................................... 25

3.4 Product Characteristics .......................................................................................................... 26

3.4.1 Projection and Grid Information ................................................................................................................. 26

3.4.2 Spatial Information ..................................................................................................................................... 26

3.4.3 Temporal Information ................................................................................................................................. 26

3.4.4 Data Policies ................................................................................................................................................ 26

3.4.5 Contacts ...................................................................................................................................................... 28

4 Validation ......................................................................................................................... 29

5 References ........................................................................................................................ 30

6 Annex: Review of Users Requirements ............................................................................... 31




List of Figures

Figure 1: Quicklook color coding ................................................................................................... 26

List of Tables Table 1: Explanation in version numbering and recommendations for using efficiently the products

.............................................................................................................................................. 15

Table 2: Data file content of the Burned Area products. ................................................................ 17

Table 3: Description of netCDF file attributes ................................................................................ 18

Table 4: Description of netCDF layer attributes ............................................................................. 19

Table 5: Description of netCDF attributes for coordinate dimensions (latitudes and longitudes) .... 20

Table 6: Description of netCDF attributes for time coordinate variable .......................................... 20

Table 7: Description of netCDF attributes for the grid mapping variable ........................................ 21

Table 8: GCOS requirements for Burned Area as Essential Climate Variable (GCOS-154, 2011) 32




List of Acronyms

ATBD Algorithm Theoretical Basis Document

BA300 Burned Area 333m

CEOS Committee on Earth Observation System

CF Climate & Forecast conventions

CGLS Copernicus Global Land Service

CP Contaminated Pixel

ECV Essential Climate Variable

FDOB First Date of Burn

JRC European Commission Joint Research Centre

GCOS Global Climate Observing System

GIO GMES Initial Operations

GIF Graphic Interchange Format

GLS Global Land Survey

JRC Joint Research Centre

L3JRC Level3 Burned Area Algorithm from JRC

LPV Land Product Validation Group of CEOS

MODIS Moderate Resolution Imaging Spectrometer

MODIS MCD45A1 MODIS global monthly burned area product Level 3 gridded 500 m

NetCDF Network Common Data Form

NMOD Number of Observations

NRT Near Real Time

PROBA-V VEGETATION sensor onboard PROBA platform

PUM Product User Manual

QAR Quality Assessment Report

S1 1-Daily Synthesis

SPOT Système Pour l’Observation de la Terre

SSD Service Specifications Document

SVP Service Validation Plan

SWIR Short Wave Infrared band

TOA Top Of the Atmosphere

VGT VEGETATION sensor onboard SPOT4/5

WGS World Geodetic System

VITO Vlaamse Instelling Voor Technologisch Onderzoek (Flemish Institute for Technological Research)




EXECUTIVE SUMMARY

The Copernicus Global Land Service (CGLS) is earmarked as a component of the Land service to

operate “a multi-purpose service component” that provides a series of bio-geophysical products on

the status and evolution of land surface at global scale. Production and delivery of the parameters

take place in a timely manner and are complemented by the constitution of long term time series.

From 1st January 2013, the Copernicus Global Land Service is providing Essential Climate

Variables like the Leaf Area Index (LAI), the Fraction of Absorbed Photosynthetically Active

Radiation absorbed by the vegetation (FAPAR), the surface albedo, the Land Surface

Temperature, the soil moisture, the burnt areas, the areas of water bodies, and additional

vegetation indices, are generated every hour, every day or every 10 days on a reliable and

automatic basis from Earth Observation satellite data.

This Product User Manual (PUM) describes the Burned Area (BA) Collection 300m product

Version 1 derived from PROBA-V daily synthesis data. The product is calculated daily at 333 m

(1/336°) resolution. It is made available to the user every 10 days in near-real time i.e. within 3

days after the last acquisition of the dekad. The product has been validated according to CEOS

Land Product Validation protocols that have been published in the open-access, peer-reviewed

literature (Padilla et al. 2014, 2015, 2017).




1 BACKGROUND OF THE DOCUMENT

1.1 SCOPE AND OBJECTIVES

The Product User Manual (PUM) is the primary document that users have to read before handling

the products.

It gives an overview of the product characteristics, in terms of algorithm, technical characteristics,

and main validation results.

1.2 CONTENT OF THE DOCUMENT

This document is structured as follows:

Chapter 2 summarizes the retrieval methodology

Chapter 3 describes the technical properties of the product

Chapter 4 summarizes the results of the quality assessment

The users’ requirements, and the expected performance, are recalled in Annex.

1.3 RELATED DOCUMENTS

1.3.1 Applicable documents

AD1: Annex I – Technical Specifications JRC/IPR/2015/H.5/0026/OC to Contract Notice 2015/S

151-277962 of 7th August 2015

AD2: Appendix 1 – Copernicus Global land Component Product and Service Detailed Technical

requirements to Technical Annex to Contract Notice 2015/S 151-277962 of 7th August 2015

AD3: GIO Copernicus Global Land – Technical User Group – Service Specification and Product

Requirements Proposal – SPB-GIO-3017-TUG-SS-004 – Issue I1.0 – 26 May 2015.

1.3.2 Input

Document ID Descriptor

CGLOPS1_SSD Service Specifications of the Copernicus Global Land

Service.

CGLOPS1_SVP Service Validation Plan of the Copernicus Global

Land Service.




CGLOPS1_ATBD_BA300m-V1 Algorithm Theoretical Basis Document of the

Collection 300m BA Version1 product derived from

PROBA-V data

CGLOPS1_VR_BA300m-V1-V2 Validation report on Collection 300m Burned Area

PROBA-V Version 1 and Version 2 products

GIOGL1_QAR_BA1km-V1 Quality assessment report on Collection 1km burned

Area PROBA-V Version 1 products.

1.3.3 External documents

ED1: PROBA-V Products User Manual, version 1.3, http://www.vito-

eodata.be/PDF/image/PROBAV-Products_User_Manual.pdf

http://www.vito-eodata.be/PDF/image/PROBAV-Products_User_Manual.pdf

http://www.vito-eodata.be/PDF/image/PROBAV-Products_User_Manual.pdf




2 METHODOLOGY DESCRIPTION

2.1 OVERVIEW

The successful implementation of the L3JRC algorithm to produce operational, near-real time,

global products from SPOT VGT to PROBA-V 1km products and finally to PROBA-V 333m input

data products required a number of algorithm evolutions. This included, from SPOT-VGT to

PROBA-V 1km, 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 was introduced to provide estimates,

of the start, peak and end of the fire season within a 1-degree grid. Initial operations within the

Copernicus Global Land Service demonstrated that the algorithm could be implemented in a full

automated manner to produce a data set over 15 years in length with SPOT VGT, and then

continued with PROBA-V.

Evolution to the PROBA-V 333m input data set required fewer changes to the algorithm apart from

taking into account data sets that were effectively 9x larger than previously considered.

Quality monitoring and quality assessment activities have demonstrated the usability of the product

through a robust CEOS compliant validation exercise [CGLOPS1_VR_BA300m-V1-V2].

2.2 THE RETRIEVAL METHODOLOGY

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

algorithm, and Part 4 contains the season metric computation.

2.2.1 Basic underlying assumptions

The assumptions we made about source data and processing chain are that:

• The satellite platform (PROBA), which has a polar sun synchronous orbit with 5 days

repeat, is sufficient coverage for detecting daily (or 10 day composite) burns using the

burned area algorithm.

• S1 (daily synthesis) or atmospherically corrected top of canopy surface reflectance data is

available.

• The input data used is consistent and has been corrected for sensor drift / decay etc.

• The PROBA-V input data is radiometric and geometrical corrected based on calibration

parameters from the raw sensor data, and hence provide consistent values over time.




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 radiometric file contains detector quality indicators, inter-detector equalization

coefficients, dark currents, non-linearity coefficients;

3. the absolute calibration file contains absolute calibration coefficients, solar

equivalent irradiance, analogue gain used during corrections.

• Pre-processing has the ability to identify non contaminated pixels by extracting cloud / cloud

shadow / snow / topographic shadow and any pixels identified as not being of optimal

quality. Pre-processing also removes observations (pixels) made at viewing zenith angles

greater than 45 degrees. Topographic shadow is established with the use of a Digital

Elevation Model.

• A suitable land-sea-water mask is available that reduces the level of commission observed

around coastal areas.

• 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.

• The pixel spacing is 0.00297619047619047 degrees. This is in fact 1/3 of the pixel size of

the 1km PROBA-V products.

2.2.2 Evolution of the method from SPOT VGT to PROBA-V Data

The differences between the implementation of the Collection 1km algorithm and the Collection

300m algorithm are minimal and can be summarised as follows:

17 iterations of the land-sea mask program are required to fit an appropriate mask around

all of the major water bodies. In the PROBA-V 1km algorithm, it was 6 iterations. This is

because there is an equivalent factor of 3 between 1km and 333m products.

The cloud shadow mask programme had to be edited to take into account the new pixel

size that was different to the PROBA-V 1km algorithm.

For the sun shadow mask that is caused by topographic relief with reference to the sun’s

position, the Collection 1km algorithm used a 1km GTOPO30 elevation model. Based on

user feedback and the availability of higher resolution elevation models the following

product and process was undertaken. The method to compute the pixels affected by sun

shadow remained the same – only the underlying elevation model (from which slope and

aspect were derived) was changed. The DEM was obtained from the Global Land Survey

(GLS) DEM (http://glcf.umd.edu/data/glsdem/) at a pixel spacing of ~90m. The global

http://glcf.umd.edu/data/glsdem/




mosaic was warped into the 333m PROBA-V pixel spacing and bounding coordinates, then

the no_data values were adjusted (otherwise the aspect/slope would have created null

values). From this resampled DEM, the aspect and slope products were derived that were

used as input into the method to derive pixels affected by sun shadow.

In a revision implemented in March 2017, false commissioning of pixels of burned area that

were located at the shorelines of water bodies and large rivers were masked out. Two

masks are used to resolve this issue:

o The first is a static water mask, based on the JRC’s Global Surface Water product

(https://global-surface-water.appspot.com/) ‘Yearly Seasonality’ dataset, accessible

through the Google Earth Engine platform (asset ID: JRC/GSW1_0/YearlyHistory)

(Pekel et al., 2016). Large water bodies, which have no data in the Global Surface

Water product, are masked by overlaying the Global Administrative Unit Layers

(GAUL) coastal boundaries vector (http://www.fao.org/geonetwork). The resulting

static mask reflects the static water bodies, such as oceans, lakes and river

networks, whose borders may affect the quality of the burnt area detection.

o The second is a dynamic water mask, based on the Water Bodies dataset of the

Copernicus Global Land Water Bodies 300 m product

(http://land.copernicus.eu/global/products/wb300). This product reflects the dynamic

nature and changing shape and size of water bodies that may affect the quality of

the burnt area detection.

The burnt area algorithm considers a pixel as water if it is marked as such in either the

static or dynamic water mask.

The most critical change affects the window over which the statistical testing for burned

area detection is made. To place this modification in a historical context, the original L3JRC

algorithm (2001-2004) implemented the algorithm over a 200x200 pixel window. In the

CGLS SPOT VGT and PROBA 1km products, this was modified to a pixel window of

112x112 pixels that corresponded with a 1 degree grid cell. Due to the revised pixel

spacing, the equivalent of 9 pixels at 333m resolution covering an original 1km pixel, the

window size has been changed to 168x168 pixels. This corresponds to an area of 0.5x0.5

degrees. The implications of this modification are that fire seasonality data is now reported

at a grid cell size of 0.5 degrees (instead of 1 degree). This means that fire seasonality is

being resolved to an improved spatial detail (from 1 degree to 0.5 degree reporting). This

would appear to be a logical outcome when higher resolution data is being used as input.

Reporting fire activity at 0.5 degree resolution is similar to that of the ESA CCI-Fire grid

product. Both raster and ASCII text file output of the seasonality metric reflect these

changes.

The majority of the season metric computation section of the processing chain does not

need to be modified because the new grid cell spacing that is reported (0.5 degree grid) is

set at the beginning of the processing. It is necessary however to set the number of pixels

https://global-surface-water.appspot.com/

http://www.fao.org/geonetwork

http://land.copernicus.eu/global/products/wb




describing the threshold where a fire season starts and ends. This is 2% of the total area

within a 0.5 degree grid cell. At 333m, this equates to 565 pixels.

The following characteristics of the Collection 1km algorithm are retained:

o Optimised data pre-processing across parallel CPUs.

o Continuity with the HDF5 format of the input data.

o C scripting language has been retained.

o Quality flags from the Quality Layer in the product are utilised. Bespoke methods for

cloud and snow masking are retained.

o Masking based on time of year and latitude is retained.

o Algorithm reflectance detection thresholds are maintained.

o Season metric computation is retained.

A complete description of the algorithm for mapping burned area is described in the ATBD

[CGLOPS1_ATBD_BA300m-V1].

2.3 LIMITATIONS OF THE PRODUCT

The algorithm relies of the production and delivery of quality layers in the PROBA-V data set and

without these being available the algorithm would not work. It uses fixed thresholds that have been

developed for the SPOT VGT sensor and evolved to the PROBA 1km data set and now further

established for the 333m data set. Although imaging bands from PROBA are similar there is a

slight offset in the Middle Infrared band (SWIR). Quality assessment exercise has been undertaken

that shows the products are useable. The land/water mask that ships with the PROBA data is not

very detailed or accurate as described above.

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:

Latitudes north of 51° during the period from 1 April to 31 May

Latitudes north of 51° during the period from 1 September to 30 September.

Latitudes north of 30° during the period from 1 October to 31 March.

Latitudes south of 30° during the period from 1 April to 30 September.

2.4 ROADMAP

The Collection 300m of BA products is currently generated from the PROBA-V sensor data at

333m resolution.

The Copernicus Global Land service will continue the 300m production through the Sentinel-3

mission. The adaptation of the retrieval methodology to Sentinel-3 is planned and will be performed

in the next months. The data from both Sentinel 3A and Sentinel-3B will be merged to maintain a

daily coverage of the globe and to continue the NRT production.




3 PRODUCT DESCRIPTION

3.1 FILE NAMING

The Burned Area Collection 300m Version 1 products follow the naming standard:

c_gls_BA300_<YYYYMMDDHHmm>_<AREA>_<SENSOR>_V<VERSION>

where

<YYYYMMDDHHmm> gives the temporal location of the file. YYYY, MM, DD, HH, and mm

denote the year, the month, the day, the hour, and the minutes, respectively. The reference

date is the last day of the synthesis period, and hence presents the last day of detecting

burned areas. Note that HHmm is always 0000.

<AREA> gives the spatial coverage of the file. The Collection 300m products are by default

only available as global coverage (GLOBE). User specific regions can be obtained through

a custom order.

<SENSOR> provides the sensor used, hence PROBA-V

<VERSION> shows the processing line version used to generate these BA Collection 300m

products. The version denoted as M.m.r (e.g. 1.0.1), with ‘M’ representing the major version

(e.g. V1), ‘m’ the minor version (starting from 0) and ‘r’ the production run number (starting

from 1) (Table 1).

Table 1: Explanation in version numbering and recommendations for using efficiently the products

Versions Differences Recommendations

Major Significant change to the algorithm.

Do not mix various major versions in the

same applications, unless it is otherwise

stated.

Minor Minor changes in the algorithm Can be mixed in the same applications, but

require attention or modest modifications

Run Fixes to bugs and minor issues. Later

run automatically replaces former Consider it as a drop-in replacement




3.2 FILE FORMAT

The Burned Area 300m Version 1 products are delivered as a set of files:

a multiband Network Common Data Form version 4 (netCDF4) with metadata attributes

compliant with version 1.6 of the Climate & Forecast conventions (CF V1.6) containing the

following full-resolution bands:

o the 10-day (dekad) composite of the Contaminated Pixel mask products

[CP_DEKAD]

o the 10-day (dekad) composited burned area product [BA_DEKAD]

o the first date of burn in the dekad [FDOB_DEKAD]

o the first date of burn just after fire season reset [FDOB_SEASON]

two textual ASCII files, with tab/comma delimiter, describing the seasonality metrics:

o The season status

o The season event database

an xml file containing the metadata conform to INSPIRE2.1.

For a more user-friendly view of the XML contents in a browser, an XSL transformation file

can downloaded at

http://land.copernicus.eu/global/sites/default/files/xml/c_gls_ProductSet.xsl. This file should

be placed in the same folder as the XML file.

A quicklook in a coloured GeoTIFF format. The quicklook is derived from the

FDOB_SEASON band.

Each netCDF4 file corresponds to a global region. As due to properties of the algorithm, there is no

processing of Burned Area data above 75° North and below 56° South.

When a user specific region is requested through custom ordering on the distribution portal

website, the netCDF4 file, the two textual report files and the GeoTIFF quicklook image will only

cover the requested region of interest.

Please note that the BA Collection 1km products are not provided as netCDF4, but as hdf5 files.

Future actions are planned to migrate the 1km products to the global netCDF4 format. Once the

migration is done, users will still be able to request hdf5 files through custom ordering on the

distribution portal.

http://land.copernicus.eu/global/sites/default/files/xml/c_gls_ProductSet.xsl




3.3 PRODUCT CONTENT

3.3.1 Data File

3.3.1.1 Image Files

An overview of the image files released in the burned area products can be seen in Table 2. Each

of the products is described in the following sections.

Layer name Description Physical

Min

Physical

Max

Digital

Max Scale_factor Add_Offset

CP_DEKAD

Dekad composite of the

Contaminated Pixels mask:

Number of observation not

used in the dekad

0

Nb of

days in

the

dekad

Nb of

days in

the

dekad

1 0

BA_DEKAD Dekad composite of the

burned area detection 0 1 1 1 0

FDOB_DEKAD First date of burn in the dekad 33289 65365 65365 1 0

FDOB_SEASON First date of burn just after the

season reset 33289 65365 65365 1 0

Table 2: Data file content of the Burned Area products.

Notes:

The physical value (PV) are derived from the digital number (DN) using the relation: PV =

scale_factor * DN + Add_offset.

All layers share identical specific values (flags) such as 0 for no detection (or season reset),

254 for ocean and 255 for missing tiles.

The values of FDOB_DEKAD and FDOB_SEASON are stored as YYDDD in the range

[33289, 65365] where YY represents the Julian calendar year since 1980 and DDD is the

day of year. The value of 33289 represents October 16, 2013 which is the date of the first

nominal PROBA-V image.

The netCDF files contain a number of metadata attributes

on the file-level (Table 3);

on the layer-level (Table 4);

at the level of the standard dimension variables for latitude (‘lat’) and longitude (‘lon’),

holding one value per row or column respectively (Table 5);

at the level of standard coordinate variable for time dimension (‘time’), holding one value for

the reference or nominal date (Table 6);

at the level of the grid mapping (spatial reference system) variable (‘crs’) (see Table 7).




Attribute name Description Data

Type Example(s)

Conventions Version of the CF-Conventions used String CF-1.6

title A description of the contents of the

file String

10-daily Burnt Area 333M: GLOBE

2016-04-01T00:00:00Z

institution The name of the institution that

produced the product String VITO NV

source The method of production of the

original data String Derived from EO satellite imagery

history

A global attribute for an audit trail.

One line, including date in ISO-8601

format, for each invocation of a

program that has modified the

dataset.

String Processing line BA: 2016-04-12

references

Published or web based references

that describe the data or methods

used to produce it.

String http://land.copernicus.eu/global/produ

cts/ba

archive_facility Specifies the name of the institution

that archives the product String VITO

product_version Version of the product (VM.m.r) String V1.0.1

time_coverage_start Start date and time of the total

coverage of the data for the product. String 2016-04-01T00:00:00Z

time_coverage_end End date and time of the total

coverage of the data for the product. String 2016-04-10T23:59:59Z

platform Name(s) of the orbiting platform(s) String Proba-V

sensor Name(s) of the sensor(s) used String VEGETATION

identifier Unique identifier for the product String

urn:cgls:global:ba300_v1_333m:BA3

00_201604100000_GLOBE_PROBA

V_V1.0.1

parent_identifier

Identifier of the product collection

(time series) for the product in

Copernicus Global Land Service

metadata catalogue.

String urn:cgls:global:ba300_v1_333m

long_name Extended product name String Burnt Area

orbit_type Orbit type of the orbiting platform(s) String LEO

processing_level Product processing level String L3

processing_mode

Processing mode used when

generating the product (Near-Real

Time, Consolidated or

Reprocessing)

String Near Real Time

copyright

Text to be used by users when

referring to the data source of this

product in publications (copyright

notice)

String Copernicus Service information 2016

Table 3: Description of netCDF file attributes




Attribute Description Data Type

Examples for BA_DEKAD layer

CLASS Dataset type String DATA

standard_name

A standardized name that references a

description of a variable’s content in

CF-Convention’s standard names table.

Note that each standard_name has

corresponding unit (from Unidata’s

udunits).

String burned_area_fraction

long_name

A descriptive name that indicates a

variable’s content. This name is not

standardized. Used when a standard

name is not available.

String

units

Units of a the variable’s content, taken

from Unidata’s udunits library.

Empty or omitted for dimensionless

variables.

Fractions should be indicated by

scale_factor.

String

valid_range

Smallest and largest values for the

variable.

Missing data is to be represented by

one or several values outside of this

range.

Same as data

variable 0, 1

_FillValue

Single value used to represent missing

or undefined data and to pre-fill

memory space in case a non-written

part of data is read back.

Value must be outside of valid_range.

Same as data

variable 255

missing_value

Single value used to represent missing

or undefined data, for applications

following older versions of the

standards.

Value must be outside of valid_range.

Same as data

variable 255

grid_mapping Reference to the grid mapping variable String crs

flag_values Provides a list of the flag values. Used

in conjunction with flag_meanings.

Same as data

variable 254, 255

flag_meanings Descriptive words or phrases for each

flag value.

String (blank

separated list) Ocean Missing_data

Table 4: Description of netCDF layer attributes

Physical values are retrieved from the digital numbers by first multiplying with the scale_factor and

then adding the add_offset. For the four layers in Burned Area products, the scale_factor is 1 and

add_offset is 0 and hence omitted from the attributes.

For the two FDOB layers, a long_name is currently not available.





Example

CLASS Dataset type String DIMENSION_SCALE

DIMENSION_

LABELS Label used in netCDF4 library String lon

NAME Short name String lon

standard_name

A standardized name that references a

description of a variable’s content in

CF-Convention’s standard names table.

Note that each standard_name has

corresponding unit (from Unidata’s

udunits).

String longitude

long_name



standardized. Used when a standard

name is not available (FDOB layers).

String longitude

units Units of a the variable’s content, taken

from Unidata’s udunits library. String degrees_east

axis Identifies latitude, longitude, vertical, or

time axes. String X

_CoordinateAxis

Type Label used in GDAL library String Lon

Table 5: Description of netCDF attributes for coordinate dimensions (latitudes and longitudes)


Example

CLASS Dataset type String DIMENSION_SCALE

NAME Short name String time

long_name



standardized. Required when a

standard name is not available.

String Time

units Units of a the variable’s content, taken

from Unidata’s udunits library. String

Days since

1970-01-01 00:00:00

axis Identifies latitude, longitude, vertical, or

time axes. String T

calendar

Specific calendar assigned to the time

variable, taken from the Unidata’s

udunits library.

String standard

Table 6: Description of netCDF attributes for time coordinate variable





Example

GeoTransform

Six coefficients for the affine transformation

from pixel/line space to coordinate space,

as defined in GDAL’s GeoTransform

String

-180.0000000000

0.0029761905

0.0

80.0000000000

0.0

-0.0029761905

_CoordinateAxisTypes Label used in GDAL library String, blank

separated GeoX GeoY

_CoordinateTransform

Type Type of transformation String Projection

grid_mapping_name Name used to identify the grid mapping String latitude_longitude

inverse_flattening

Used to specify the inverse flattening (1/f)

of the ellipsoidal figure

associated with the geodetic datum and

used to approximate the

shape of the Earth

Float 298.257223563

long_name A descriptive name that indicates a

variable’s content. String coordinate reference system

longitude_of_prime_me

ridian

Specifies the longitude, with respect to

Greenwich, of the prime meridian

associated with the geodetic datum

Float 0.0

semi_major_axis

Specifies the length, in metres, of the semi-

major axis of the

ellipsoidal figure associated with the

geodetic datum and used to

approximate the shape of the Earth

Float 6378137.0

spatial_ref Spatial reference system in OGC’s Well-

Known Text (WKT) format String

GEOGCS["WGS

84",DATUM["WGS_1984",…

AUTHORITY["EPSG","4326"]]

Table 7: Description of netCDF attributes for the grid mapping variable

3.3.1.1.1 Contaminated Pixel dekad composite (CP_DEKAD)

The unsigned byte (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. So, the lower the

value, the more observations are used to detect a burn. Missing tiles do not contribute to the

contaminated pixel dekad composite.

The physical range of CP_DEKAD is [0, <number of days in the dekad>], as is the Digital Number

range. The value indicates:

http://www.gdal.org/gdal_datamodel.html




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

255 = no data present (missing tile) during entire dekad

3.3.1.1.2 Burned Area dekad composite (BA_DEKAD)

This unsigned byte (8 bits) indicates if the pixel has been detected as burned (1) at least once in

the dekad. Note that a value 0 does not necessarily mean the pixel was not burned; it might have

been filtered out by the number of contaminated observations (CP_DEKAD) mask. Missing tiles do

not contribute to the burned area dekad composite.

The value indicates:

0 = no burn scar detected in the dekad, either there has been no burn or CP_DEKAD

indicates that the pixels was contaminated each and every day in the dekad

1 = at least one burn scar detected in the dekad

254 = ocean flag


3.3.1.1.3 First Day of Burn in the dekad (FDOB_DEKAD)

This unsigned integer (16 bits) provides the First Day of Burn (FDOB) in the given dekad.

The physical range of FDOB is [0, 65356], as is the Digital Number range. The value indicates:

0 = no burn scar detected in the dekad

254 = ocean flag


YYDDD in range [33289, 65365] = 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 36055 represents a FDOB date of 2016-02-24, and is present in the

file c_gls_BA300_201602290000_GLOBE_PROBAV_V1.0.1.nc:FDOB_DEKAD. Note that this

coding value will disappear in the next dekad, hence in the file

c_gls_BA300_201603100000_GLOBE_PROBAV_V1.0.1.nc:FDOB_DEKAD.

3.3.1.1.4 First Day of Burn just after Season Reset (FDOB_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. Dates are reset by seasonal resets.

The physical range of FDOB is [0, 65356], 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 [33289, 65365] = 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 36055 represents a FDOB date of 2016-02-24, and will be present in

the file c_gls_BA300_201602290000_GLOBE_PROBAV_V1.0.1.nc:FDOB _SEASON. Note that

this coding value will re-appear in the next dekad, hence in the file

c_gls_BA300_201603100000_GLOBE_PROBAV_V1.0.1.nc:FDOB_SEASON, unless the season

has been reset during this last dekad.

3.3.1.2 Seasonality files

Both files use one line per 0.5 x 0.5 degree grid cell (168 x 168 pixels). Each line starts with its

longitude and latitude. The seasonality files use dekad numbers, where dekad 1 is the dekad

ending 19800110. Dekad counting starts in 1980. To calculate the date that is represented by a

dekad number, one could use:

Year = 1980 + ( (dekad number – 1) / 36)

Dekad_in_year = (dekad_number – (Year – 1980)*36)

3.3.1.2.1 Season Status file

This text file provides the main season metrics. For each 0.5 x 0.5 degree grid cell (168 x 168

pixels) is provided in this order:

longitude, latitude (centre of pixel)

fire season status :0 = out of season, 1 = in season (status),




start of season dekad (sos), maximum of season dekad (smax), end of season dekad

(eos),

maximum count of 333x333 m pixels (area in 1/9 square km) detected as burned in season

inside the 0.5 x 0.5 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 1234 (the dekad ending 20140410, counted from

19800101) 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

83.00000000 46.00000000 0 0 0 0 0 0 1

83.50000000 46.00000000 1 1234 1234 0 247 1 1

84.00000000 46.00000000 0 1232 1232 1234 535 2 0

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 area of 83.5°E, 46°N is in season (status = 1), since the current dekad 1234. At dekad 1234, it

had its largest number of burned 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 84°E, 46°N is not in season anymore but recently was. It had a season from

dekad 1232 to 1234, with a maximum of 535 pixels in dekad 1232. It counts 2 seasons in total.

The season reset flag indicates that seasonality data of the 0.5° x 0.5° cell is being reset.

3.3.1.2.2 Season Event database file

For each 0.5x0.5 degree grid cell (168 x 168 pixels), this file collects the seasons information. The

user can check the season_status file to learn the seasons status. For each half degree grid cell is

provided:

Longitude and Lattitude in degrees

For every ‘ended’ fire season, a triple data entry is added to the half 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 burned 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

Note this additional information is only provided when the season-end is detected. If no season-

end is detected yet, the information is left blank.

Note that multiple season-ends detections are represented by multiple triple data entries separated

by the character ‘;’.

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):

Longitude Lattitude sos pos eos ; sos pos eos ; . .

35.00000000 46.00000000

35.50000000 46.00000000

36.00000000 46.00000000

36.50000000 46.00000000

37.00000000 48.00000000 1232 , 1232 , 1233 ;

37.50000000 48.50000000 1232 , 1234 , 1234 ; 1238 , 1239 , 1242

;

The dekad file shown above is of dekad 1234 (20140410). The first few lines, representing 35°E,

46°N to 36.5°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 37°E, 48°N, a season started in dekad 1232 (20140320), had a peak in that

dekad, and lasted until dekad 1233 (20140331).

The grid cell 37.5°E, 48.5°N represents two seasons, a first one started in dekad 1232 (20140320)

and ended in dekad 1234. The second season started in dekad 1238 (20140520), with a peak at

1239 (20140601) and ended in 1242 (20140701). . Both areas are now out of season.

3.3.2 Quicklook

The quicklook geo-referenced tiff file is derived from the FDOB_SEASON band. The spatial

resolution is sub-sampled, using nearest neighbour resampling, to 5% in both directions, hence a

quicklook is 1/400th of the size of the data layer.

The quicklook is coded in 1 byte and provided with an embedded color table as presented in

Figure 1. As the original band is coded in 16 bits, a scale operation is performed to map all FDOB




values into 255: there is no distinction anymore between different FDOB dates and it becomes an

indication that a burn scar has been detected during the active fire season. As a result, the value

of ‘water’ and ‘no data’ are one digit lower in the quicklook (0: land; water: 253, no data: 254, burn

scar: 255).

0 253 254 255

Figure 1: Quicklook color coding

3.4 PRODUCT CHARACTERISTICS

3.4.1 Projection and Grid Information

The product is displayed in a regular latitude/longitude grid (plate carrée) with the ellipsoid WGS

1984 (Terrestrial radius=6378km). The resolution of the grid is 1/336°.

The reference is the centre of the pixel. It means that the longitude of the upper left corner of the

pixel is (pixel_longitude – angular_resolution/2.)

3.4.2 Spatial Information

The Burned Area Collection 300m Version 1 product is provided over the non-boreal world, hence

from longitude -180°E to +180°W and latitude +75°N to -56°S. Custom generated image files

covering latitude above +75°N and/or below -56°S will have areas without burned area data. The

corresponding pixels will be filled with no data values (255).

3.4.3 Temporal Information

The Burned Area Collection 300m Version 1 product is a 10-daily composite, updated daily with

date of new detected burn scars. The part “YYYYMMDDHHMM” of the product name gives the

date of the last day of the compositing period, hence the last day of a dekad.

The BA300 version 1.0 dataset is provided from the PROBA-V 333m input, based on detections

starting from 16/10/2013.

3.4.4 Data Policies

All users of the Copernicus Global Land service products benefit from the free and open access

policy as defined in the European Union’s Copernicus regulation (N° 377/2014 of 3 April 2014) and

Commission Delegated Regulation (N° 1159/2013), available on the Copernicus programme’s web




site, http://www.copernicus.eu/library/detail/248). Products from legacy R&D projects are also

provided with free and open action.

This includes the following use, in so far that is lawful:

a) reproduction;

b) distribution;

c) communication to the public;

d) adaptation, modification and combination with other data and information;

e) any combination of points (a) to (d).

EU law allows for specific limitations of access and use in the rare cases of security concerns, protection of third party rights or risk of service disruption. By using Service Information the user acknowledges that these conditions are applicable to

him/her and that the user renounces to any claims for damages against the European Union

and the providers of the said Data and Information. The scope of this waiver encompasses

any dispute, including contracts and torts claims that might be filed in court, in arbitration

or in any other form of dispute settlement.

Where the user communicates to the public on or distributes the original PROBA-V BA Collection

300m products, he/she is obliged to refer to the data source with (at least) the following statement

(included as the copyright attribute of the netCDF file):

Copernicus Service information [Year]

With [Year]: year of publication

Where the user has adapted or modified the products, the statement should be:

Contains modified Copernicus Service information [Year]

For complete acknowledgement and credits, the following statement can be used:

“The product was generated by the Global Land Service of Copernicus, the Earth Observation

programme of the European Commission. The research leading to the current version of the

product has received funding from various European Commission Research and Technical

Development programmes. The product is based on PROBA-V 333m data ((c) ESA and distributed

by VITO).”

The user accepts to inform Copernicus about the outcome of the use of the above-mentioned

products and to send a copy of any publications that use these products to the following address:

[email protected]

http://www.copernicus.eu/library/detail/248

mailto:[email protected]




3.4.5 Contacts

The Burnt Areas Collection 300m products are available through the Copernicus Global Land

Service website at the address: http://land.copernicus.eu/global/products with contact information

(helpdesk) on http://land.copernicus.eu/global/contactpage

Accountable contact: European Commission Directorate-General Joint Research Center

Email address: [email protected]

Scientific & technical contact:

Email address: [email protected]

http://land.copernicus.eu/global/products






4 VALIDATION

The Collection 300m burned area products have been subject to quality assessment processes

that are fully described in the document [CGLOPS1_VR_BA300m-V1-V2]. The procedures are fully

compliant with CEOS Land Product Validation protocols and the methodology to generate the

reference data has been published.

The Copernicus Near-Real Time Burned area product at 300m that is described here continues to

produce useable, meaningful and well characterised products for a range of users. In the validation

report [CGLOPS1_VR_BA300m-V1-V2], the products described here, that being Version 1.1

(CGLS_BA300_v1.1), is compared against a proposed v2 of the BA algorithm (CGLS_BA300_v2

that takes into account the information provided by an active fire product alongside the current

Collection 1km referred to as CGLS_BA_V1.5, current 300m BA Collection (CGLS_BA300_V1.0)

and MODIS-MCD64 Collection 6. Reference data used for validation is generated from pairs of

2014 Landsat images on a stratified random sampling generated.

The validation results show that all products are more accurate than the existing 1km

CGLS_BA_V1.5 product. A slight improvement in accuracy is seen between CGLS_BA300_v1.0

and CGLS_BA300_V1.1 (with the product described in this document being slightly more

accurate). The CGLS_BA300m_V1.1 has a slightly lower commission error (the intended outcome

of the edits that were made to the algorithm). It also has a slightly higher Oe compared with the

latter, so is being more conservative. Overall, a very slight increase in the Dice Coefficient (a

measure of accuracy in the burnt area class) is seen in the revised product.




5 REFERENCES

Padilla, M., Olofsson, P., Stephen V., S., Tansey, K., & Chuvieco, E. (2017). Stratification and

sample allocation for reference burned area data. submitted to Remote Sensing of

Environment

Padilla, M., Stehman, S.V., & Chuvieco, E. (2014). Validation of the 2008 MODIS-MCD45 global

burned area product using stratified random sampling. Remote Sensing of Environment, 144,

187–196

Padilla, M., Stehman, S.V., Ramo, R., Corti, D., Hantson, S., Oliva, P., Alonso, I., Bradley, A.,

Tansey, K., Mota, B., Pereira, J.M., & Chuvieco, E. (2015). Comparing the Accuracies of

Remote Sensing Global Burned Area Products using Stratified Random Sampling and

Estimation. Remote Sensing of Environment, 160, 114-121

Pekel, J.-F., Cottam, A., Gorelick, N, Belward, A., High resolution mapping of the global surface

water and its long-term changes, Nature, 540, 418-422, 2016.




6 ANNEX: REVIEW OF USERS REQUIREMENTS

According to the applicable document [AD2] and [AD3AD2], the user’s requirements relevant for

burned area are as follows.

Definition: surfaces where vegetation is damaged or destroyed by fires

Geometric properties:

o Pixel size of output data shall be defined on a per-product basis so as to facilitate

the multi-parameter analysis and exploitation.

o The baseline datasets pixel size shall be provided, depending on the final product,

at resolutions of 100m and/or 300m and/or 1km.

o The target baseline location accuracy shall be 1/3rd of the at-nadir instantaneous

field of view

o pixel co-coordinates shall be given for centre of pixel

Geographical coverage:

o Geographic projection: regular lat-long

o Geodetical datum: WGS84

o Coordinate position: centre of pixel

o Window coordinates:

Upper Left:180°W - 70°N

Bottom Right: 180°E - 50°S

Ancillary information:

o the per-pixel date of the individual measurements or the start-end dates of the

period actually covered

o quality indicators, with explicit per-pixel identification of the cause of anomalous

parameter result

Accuracy requirements:

o Baseline: wherever applicable the bio-geophysical parameters should meet the

internationally agreed accuracy standards laid down in document “Systematic

Observation Requirements for Satellite-Based Products for Climate”. Supplemental

details to the satellite based component of the “Implementation Plan for the Global

Observing System for Climate in Support of the UNFCCC”. GCOS-#154, 2011”

(Table 8).

o Target: considering data usage by that part of the user community focused on

operational monitoring at (sub-) national scale, accuracy standards may apply not

on averages at global scale, but at a finer geographic resolution and in any event at

least at biome level.




Variable Horizontal

resolution

Temporal

resolution

Accuracy Stability

Burned

area

250m Daily

detection

15% (error of omission

and commission),

compared to 30m

observations

15% (error of omission and

commission), compared to

30m observations

Table 8: GCOS requirements for Burned Area as Essential Climate Variable (GCOS-154, 2011)

Other user requirements for burned area products come from FP7 project geoland2. The

requirements were for 10-day spatial products delineating the area burned over a period of several

years. 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

provided. Frequency of observations of the land surface (cloud-free etc.) has also been included in

the product.

Documents

Copernicus Global Land Operations · Copernicus Global Land Operations – Lot 1 Date Issued: 02.05.2017 Issue: I1.40 Copernicus Global Land Operations “Vegetation and Energy”