Skip to content

Non-Biomass Emissions

The /non_biomass_emissions API call implements a CO2-equivalent emissions calculation of non-biomass emissions sources, based on third party emissions calculation tools like Cool Farm Tool, as well as the implementation of emissions calculations using emissions factors from peer-reviewed sources.

The emissions sources considered in this API call are the following: - Energy: Emissions from energy use, including electricity, heating, and transportation. - Fertilizers: Emissions from the application of fertilizers, both organic and inorganic. - Pesticides: Emissions from the application of pesticides. - Soil Organic Carbon: Emissions from changes in soil organic carbon. - Water: Emissions from water use. - Waste: Emissions from waste management. - Other: Emissions from other sources.

Some of the inputs for emissions calculations are spatio-temporally derived by providing a polygon geometry and a date range, such as the land use change transitions (i.e. Tier 1 approach used to derive soil organic carbon changes) and the forest stand age (in the case of perennials).

Unlike the /biomass_emissions API call which would relies on a regionally-trained empirical biomass stock estimation model, with a protocol for local validation through field inventorying (i.e. Tier 3 approach), the /non_biomass_emissions API call relies on the use of emissions factors and a general equation for emissions estimation ( E = A * EF * (1-ER/100) with E the emissions, A being the activity level, EF the emissions factor, and ER the emission reduction factor). The activity rates are either user-provided (e.g. fertilizer volume used) or derived automatically using geospatial data (i.e. tillage or residue burning detection), the emissions factors are sourced from third party tools (e.g. CFT) or peer-reviewed literature when more recent and geographically relevant ones are available. The emissions reduction factor is either user-provided or derived from the literature, but is not always relevant in the context of agricultural emissions sources, especially if the emissions factor used is appropriate for the commodity type and the region of application. That said, the spatio-temporal relevance of the automatically derived inputs (temperature, forest age, 20+ year land use transition, tillage/burning, agroforestry density, .etc), together with user-provided inputs specific to a supply base, ensures that the emissions calculations are more accurate and representative (i.e. Tier 2 approach).

Key Datasets

The change detection algorithms implemented and datasets are the following: 1. Wrapper Cool Farm Tool and Platform: The Cool Farm Tool offers the most comprehensive third-party tool for agricultural emissions calculations based on user-provided emissions. Epoch has built a wrapper around the Cool Farm Tool to automatically derive some of the inputs that the tool requires, in order to alleviate the data collection and provision burden by the supplier. There are other third-party emissions calculations such as Agrecalc, but the choice to integrate with CFT first is due to the large active community and the collaborative nature of the tool development, as well as their interest to cater for tropical soft commodities. Epoch plans to integrate with other tools like Agrecalc in the future, as a means to provide a convergence of evidence across multiple tools. However, Epoch requires that all integrated tools have at the very least an Open Science approach to their data and methodologies, to ensure auditing of figures.

  1. Land Use Transition and Forest Age Mapping: A land cover model trained using the Glance training dataset on the same covariate stack as for the /biomass_emissions endpoint. This model is used to detect annual land cover for the last 20 years, and as a result enables the mapping of land cover transitions, which can then be mapped to the CFT's land use change categories:
1
2
3
4
5
6
7
8
9
mapping = {
    1: 'paddy', 
    2: 'set-aside', 
    3: 'cultivated', 
    4: 'native-forest', 
    5: 'native-grassland',
    6: 'cultivated', 
    7: 'perennial'
}

The ability to do this over 20 years is in line with the GHG protocol's way of determining dLUC emissions, but also provides a more comprehensive and realistic set of inputs to the Cool Farm Tool, or any other emissions calculation approach for soil carbon changes, because soil carbon changes are highly dependent on the long-term history of what happened on the land in a given location.

Leveraging the same annual land cover mapping time series, we can also derive the forest age of perennial crops and natural forests, using the approach from Heinrich et al., 2023. Forest age is a determinant for long-term soil carbon trajectories, and is important to provide this information to the CFT for as many historical years as possible.

  1. Land Management Detection Practices: The detection of land management practices such as tillage, cover cropping, fallowing, residue burning, commodity plantation cut-backs, are very important for determining agricultural emissions which are not related to the woody biomass component derived by the /biomass_emissions endpoint. For tillage detection, we leverage the HISET histogram matching approach from Heiden et al. (2022), as the theoretical basis for detecting bare soil occurence in a spatio-temporally adaptive way. An implementation and working example of the HISET algorithm identifies how bare soil in active cropping soils (i.e tillage) and in fallow fields can be detected. This approach relies on the following steps, and takes an input geometry and temporal window (typically a calendar year, or at least a growing season length) as input:
  2. Identifying whether a commodity crop phenology is present (using the small NDVI integral). If vegetated but not showing clear commodity phenology, then the field is assigned to cover crop (i.e. vegetated fallow). If bare, then the field is assigned to bare fallow.
  3. If commodity phenology is detected, and bare soil is also detected, then the field is assigned to tillage. If no bare soil is detected, then the field is assigned to no-till. If no bare soil is detected, but the Normalized Burn Ratio exceeds a locally adaptive threshold (as per the HISET approach), then the field is assigned to residue burning.

  4. For perennial crops, the above sequence is not relevant, and only plantation cut-backs are accounted for, in above and below-ground biomass through the /biomass_emission, and through the CFT's carbon_changes by providing forest age and land use transition information (see above).

  5. Emissions disaggregation from supply base to plots: Inevitably, some management practices and activity inputs will be collected at the plot level, while some others at the supply base (or other aggregation point) level. This makes the data harmonization process complex, as ultimately the emissions estimates need to be allocated to the plot level, so as to get a granular view of the emissions sources and sinks in a supply base. This disaggregation from aggregate figures to plot-level figures may seem artificial, but is necessary to ensure that the reporting unit is as close to the actual management unit as possible, and so that the emissions sources which are plot-specific and/or automatically detectable at the plot level (biomass stock changes, tillage, residue burning, etc.) can be reported alongside the less granular emissions sources (energy use, fertilizer use, etc.) which are typically reported at the supply base level.

For this disaggregation process, we use commodity production volume or plot area, depending on the emissions source. For instance, direct stationary energy use (energy from factories that process the commodity) is proportional to the volume of commodity processed through those facilities. Therefore, production volume is used to disaggregate those emissions sources to the plot level, IF plot-level production is available. Farm-specific production volumes may not always be available, in which case an area-based allocation is performed to disaggregate the emissions source. In the case of fertilizer or pesticide use information provided at supply-base level, the emissions are allocated to the plot level strictly based on the area.

This is why our APIs strictly work with geo-referenced plot geometries (at the very least point geometry and area in hectares), as the field size is a very important input to enable credible and representative emissions calculations and (dis)aggregation.

Key Considerations

See below a list of key considerations to keep in mind when using the /non_biomass_emissions endpoint:

  1. Uncertainty in Self-reported Data: In Emissions Inventorying for large and fragment supply bases, there is always a need to rely on self-reported data. Epoch ensures that the process implemented by a third-party (either the supplier or a contracted party) for collecting this data is as transparent and qualitative as possible. However, the uncertainy which comes from self-reported data remains high, and reporting data at some level of aggregation (e.g. supply base level or at some intermediate level of farm grouping) may be necessary to mitigate this uncertainty. Epoch flags unlikely self-reported data (e.g. a yield too high for a given field size), to the extent possible to mitigate large errors in self-reporting.

  2. Incompleteness in Self-reported Data: Collecting data for self-reporting of emissions sources is a continuous and complex process, and no supplier ever has ALL the data that is required to make a comprehensive emissions inventory. In that sense, the API attempts to fetch missing data using geospatial data sources and other third party systems, but there are emissions sources that cannot be derived automatically, and for which the supplier must provide the data. In the case that such data categories remain missing, we take national data as a proxy, so as to ensure that all emissions sources are represented, and that no emissions source is left out of the inventory, making the inventory look artificially low. Typically, global/national averages will be higher than supply base-specific data in many cases, so there is real incentive for the supplier to provide better self-reported data.

  3. Relevance of Emissions Factors: Emissions factors are typically derived from peer-reviewed literature, and are often specific to a region or a commodity type. Epoch ensures that the emissions factors used are as relevant as possible to the supply base, but the level of representativeness of a given emissions factor will not always be as good across all suppliers, depending on how well a certain commodity or agricultural system is studied. Epoch is ensuring that the emissions factor effectively leveraged for the calculations are provided in the API response, so that:

  4. The supplier can cross-check the emissions factors used, and provide better ones if available.
  5. Auditors can very straight-forwardly see what was used for the calculations, and can cross-check the emissions factors used.

Parameters and Headers

A request to /non_biomass_emissions/ uses standard query parameters.

Parameter Type Required Default Description
filename string No None Collection/file identifier to load existing inputs. If not provided, country + crop_type are required.
country string Cond. "" Country for which to estimate emissions.
crop_type string Cond. "" Commodity type (e.g. tea, rubber, shrimp).
processing_type string No None Processing type (depends on commodity).
system_type string No None System type (depends on commodity).
input_payload string (JSON) No "" Input payload to calculate/merge emissions inputs.
start_date string No YYYY-01-01 (current year) Monitoring start date.
date string No YYYY-12-31 (current year) Monitoring end date.

A typical example of a payload for the /non_biomass_emissions endpoint is the following:

import json 

request_data = {
    "crop_type": "tea",  # (1)!
    "country": "India",  # (2)!
    "processing_type": "black_tea",  # (3)!
    "system_type": "estate",  # (4)!
    "start_date": "2023-01-01",  # (5)!
    "date": "2023-12-31",  # (6)!
    "filename": "<collection_id>",  # (7)!
    "input_payload": json.dumps({
        "hatchery": {
            "chemicals": [],
            "materials": [],
            "energy": []
        },
        "nursery": {
            "chemicals": [],
            "materials": [],
            "energy": []
        },
        "farmgate": {
            "energy": [
                {"name": "electricity (grid)", "value": 100000, "unit": "kWh"},
                {"name": "diesel (average biofuel blend)", "value": 500, "unit": "litre"}
            ],
            "feed": [],
            "chemicals": [],
            "materials": [],
            "fertilisers": [],
            "pesticides": [],
            "biogenic_emissions": []
        },
        "processing": {
            "energy": [
                {"name": "electricity (grid)", "value": 50000, "unit": "kWh"}
            ],
            "materials": [],
            "chemicals": []
        },
        "distribution": {
            "transport": []
        },
        "land_use": {},
        "co_products": [],
        "country": "India",
        "year": 2023,
        "base_year": None,
        "commodity_type": "tea",
        "commodity_yield": {"value": 100000, "unit": "kg"},
        "product_fresh": {"value": 100000, "unit": "kg"},
        "product_finished": {"value": 80000, "unit": "kg"},
        "product_cf": 0.8,
        "production_area": {"value": 10.0, "unit": "ha"}
    }), # (8)!
}
  1. The commodity type for which the emissions are being calculated (e.g., "tea", "timber", "shrimp"). Required if filename is not provided.
  2. The country for which to estimate emissions. Required if filename is not provided.
  3. The processing type (e.g., "black_tea", "shell_off", "sawnwood"). Optional - defaults are assigned based on crop_type if not provided.
  4. The system type (e.g., "estate", "semi_intensive", "softwood"). Optional - defaults are assigned based on crop_type if not provided.
  5. Start date for the monitoring period. Defaults to January 1st of the current year if not specified.
  6. End date for the monitoring period (up until processing). Defaults to December 31st of the current year if not specified.
  7. Optional collection ID (filename). If provided, the system will retrieve stored LCA payload and metadata from the collection.
  8. The input payload in LCA (Life Cycle Assessment) payload structure. This contains detailed supply chain data for emissions calculations. If not provided and filename is provided, the stored LCA payload from the collection will be used. If neither is provided, default values from the emission factors database will be used.

With the headers being:

1
2
3
headers = {'Authorization': "Bearer <authorization_token>",
           'accept': 'application/json'
           }

The Authorization header must be replaced by your user token. Check this page for more information on how to authenticate.

Python

In python, you can submit a request in the following way:

non_biomass_emissions.py
1
2
3
4
5
6
7
8
9
import requests
import json

response = requests.get("https://epoch-sco2-api.com/non_biomass_emissions/", 
                        params=request_data, 
                        headers=headers)

json_result = json.loads(response.content)
print(json_result)

Javascript

non_biomass_emissions.js
const axios = require('axios');

axios.get('https://epoch-sco2-api.com/non_biomass_emissions/', {
    params: request_data,
    headers: headers,
})
    .then(response => {
        console.log(response.data);
    })
    .catch(error => {
        console.error(error);
    });

Curl

1
2
3
4
5
6
7
8
curl -X GET "https://epoch-sco2-api.com/non_biomass_emissions/" \
     -H "Authorization: Bearer <authorization_token>" \
     -H "Accept: application/json" \
     --data-urlencode "start_date=2023-01-01" \
     --data-urlencode "date=2023-12-31" \
     --data-urlencode "crop_type=tea" \
     --data-urlencode "country=India" \
     --data-urlencode "input_payload=<your_lca_payload_json>"

Response

The response is a dictionary with years as keys, where each year contains the calculated emissions for that year:

response = {
    2023: {  # (1)!
        "hatchery": {
            "product_fresh": {
                "emissions_tco2e": {...},
                "emissions_tco2eha": {...},
                "emissions_tco2et": {...},
                "emissions_tco2e_total": 0.0,
                "emissions_tco2eha_total": 0.0,
                "emissions_tco2et_total": 0.0
            },
            "product_finished": {...}
        },
        "nursery": {...},
        "farmgate": {
            "product_fresh": {
                "emissions_tco2e": {
                    "energy": {...},
                    "feed": {...},
                    "chemicals": {...}
                },
                "emissions_tco2eha": {...},
                "emissions_tco2et": {...},
                "emissions_tco2e_total": 1234.56,
                "emissions_tco2eha_total": 123.45,
                "emissions_tco2et_total": 0.001
            },
            "product_finished": {...}
        },
        "processing": {...},
        "distribution": {...},
        "co_products": {
            "percentage_economic_discount": 0.0
        },
        "total": {
            "product_fresh": {
                "discounted": {
                    "emissions_tco2e_total": 1234.56,
                    "emissions_tco2eha_total": 123.45,
                    "emissions_tco2et_total": 0.001
                },
                "undiscounted": {
                    "emissions_tco2e_total": 1234.56,
                    "emissions_tco2eha_total": 123.45,
                    "emissions_tco2et_total": 0.001
                }
            },
            "product_finished": {...}
        }
    },
    2024: {...}  # If multiple years in the date range
}
  1. The response is a dictionary with years as keys (e.g., 2023, 2024). Each year contains calculated emissions for that year.
  2. Each year's emissions data includes:
  3. hatchery, nursery, farmgate, processing, distribution: Emissions broken down by supply chain stage
  4. co_products: Economic value allocation for co-products
  5. total: Aggregated emissions totals for both product_fresh and product_finished, with discounted and undiscounted values
  6. Each stage contains emissions data for both product_fresh and product_finished:
  7. emissions_tco2e: Total emissions in tCO₂e
  8. emissions_tco2eha: Emissions per hectare in tCO₂e/ha
  9. emissions_tco2et: Emissions per tonne of product in tCO₂e/t
  10. emissions_tco2e_total, emissions_tco2eha_total, emissions_tco2et_total: Aggregated totals for the stage