High Level Summary

<aside> 📣

Natural language description of Biomass Atlas API

</aside>

Executive summary:

The Biomass Atlas API lets you request and retrieve high-resolution forest metrics for your project area.

You simply upload a boundary, request a product, and receive your results once analysis is complete.

</aside>

graph TD
    Step1["STEP 1:<br/>Upload Boundary"]
    Step1 --> Step2["STEP 2:<br/>Submit Product Request"]
    Step2 --> Step3["STEP 3:<br/>Processing"]
    Step3 --> C1{Check Status<br/>until complete}
    C1 -->|Completed| Step4["STEP 4:<br/>Retrieve Results"]
    
    style Step1 fill:#4A90E2,stroke:#2E5C8A,color:#fff
    style Step2 fill:#4A90E2,stroke:#2E5C8A,color:#fff
    style Step3 fill:#4A90E2,stroke:#2E5C8A,color:#fff
    style Step4 fill:#4A90E2,stroke:#2E5C8A,color:#fff

Upload your project boundary

Users begin by uploading their project boundary to Sylvera.

The API accepts GeoJSON sent via POST request or files in GPKG, KML, GeoJSON, or FGB formats.

Once uploaded, Sylvera confirms receipt and provides a unique boundary ID.
Request a product

With the boundary ID, users can request available data products.

Currently, the Biomass Atlas V2.1 product includes:
- Above ground biomass density
- Above ground biomass density uncertainty
- Canopy height
- Canopy height uncertainty
- Quality assurance layers
Receive confirmation and tracking

Sylvera confirms each product request with a request ID.

The system automatically updates the status of the request, which the user can check at any point using the request ID.
Access your results

Once processing is complete, users can retrieve their results through the API.
- Spatial data (arrays/rasters) can be accessed via Arraylake.

Technical Details

Product Request Workflow

Product Request Workflow Details

🚀 Quick Start: Complete Scripts for Boundary Creation and Product Requests

1. 🔐 Authentication

2. 🔶 Upload Boundary - Define an Area of Interest

3. 🌱 Submit Data Product Request

4a. ⏰ Checking Data Product Request Status

4b. 📣 Receiving Product Request Status Events

5. 🗺️ Get Raster Data

Data Schemas

Raster Data Schema

Variable	Units	Dtype	Nodata	Dims	Scale	Offset	Description
`canopy_height`	m	float16	NaN	`time_start`, `y`, `x`	-	-	Canopy height of the 95th percentile of woody vegetation. Canopy heights < 3 m are unreliable due to minimum detection limits of the GEDI instrument.
`canopy_height_residual_standard_error`	m	float16	NaN	`time_start`, `y`, `x`	-	-	Residual standard error in the `canopy_height` variable.
`above_ground_biomass_density`	Mg/ha	float16	NaN	`time_start`, `y`, `x`	-	-	Above ground biomass density of dry matter in live woody vegetation.
`above_ground_biomass_density_residual_standard_error`	Mg/ha	float16	NaN	`time_start`, `y`, `x`	-	-	Residual standard error in `above_ground_biomass_density`
`above_ground_biomass_multiscale_lidar`	%	int8	-1	`y`, `x`	-	-	The percentage contribution MSL based above-ground biomass models made to the reported `above_ground_biomass_density`. 100 being 100% contribution from MSL-based models and 0 being 0% MSL-based models (GEDI L4A or peer-reviewed ALS). Multi-scale LiDAR data is not yet available for all regions/biomes but coverage increases as new data becomes available from ongoing field campaigns.
`canopy_height_raw`	m	float16	NaN	`time_start`, `y`, `x`	-	-	Canopy height of the 95th percentile of woody vegetation, without post-processing applied. In the majority of contexts `canopy_height` should be strongly preferred, but `canopy_height_raw` can be useful when analysing early stage growth, although it may contain gaps.
`gap_type`	unitless	int8	-1	`time_start`, `y`, `x`	-	-	Indicates where gaps have been filled during canopy height post-processing. Indexes are 0 (no gap), 1 (gap-filled due to no imagery), and 2 (gap-filled due to low quality imagery).
`first_observation`	year offset	int8	-1	`y`, `x`	-	-	The date of first observation that was considered in fitting the canopy height time-series of this pixel, encoded as the number of years offset from 2000-01-01. Canopy height and AGBD values before this date for the corresponding pixel are extrapolation and should be interpreted with caution.
`last_observation`	year offset	int8	-1	`y`, `x`	-	-	The date of last observation that was considered in fitting the canopy height time-series of this pixel, encoded as the number of years offset from 2000-01-01 canopy height and AGBD values in the data variable after this date for the corresponding pixel are extrapolation and should be interpreted with caution.
`computed`	unitless	bool	False	`y`, `x`	-	-	Binary mask indicating where data has been materialised for the dataset.
`blue`	unitless	uint16	0	`time_start`, `y`, `x`	0.0000275	-0.2	Landsat green period composite band 2 (blue) surface reflectance.
`green`	unitless	uint16	0	`time_start`, `y`, `x`	0.0000275	-0.2	Landsat green period composite band 3 (green) surface reflectance.
`red`	unitless	uint16	0	`time_start`, `y`, `x`	0.0000275	-0.2	Landsat green period composite band 4 (red) surface reflectance.
`nir08`	unitless	uint16	0	`time_start`, `y`, `x`	0.0000275	-0.2	Landsat green period composite band 5 (near infrared) surface reflectance.
`swir16`	unitless	uint16	0	`time_start`, `y`, `x`	0.0000275	-0.2	Landsat green period composite band 6 (shortwave infrared 1) surface reflectance.
`swir22`	unitless	uint16	0	`time_start`, `y`, `x`	0.0000275	-0.2	Landsat green period composite band 7 (shortwave infrared 2) surface reflectance.
`start_day`	day of year	int16	-1	`y`, `x`	-	-	Day of year of the start of the green period (inclusive) which defines the temporal window of scenes which can contribute to the Landsat composites. Values range from 1 to 366. If `start_day < end_day`, the green period is `[start_day, end_day]`. If`start_day > end_day`, the green period is `[start_day, 366] U [1, end_day]`.
`end_day`	day of year	int16	-1	`y`, `x`	-	-	Day of year of the end of the green period (inclusive) which defines the temporal window of scenes which can contribute to the Landsat composites. Values range from 1 to 366. If `start_day < end_day`, the green period is `[start_day, end_day]`. If`start_day > end_day`, the green period is `[start_day, 366] U [1, end_day]`.
`number_of_observations`	count	int16	-1	`time_start`, `y`, `x`	-	-	The number of valid scenes which contributed to the Landsat green period composite.
`median_observation_doy`	day of year	int16	-1	`time_start`, `y`, `x`	-	-	The median day of year of observations which contributed to the Landsat green period composite. Where`start_day > end_day`, the median is calculated relative to the `start_day`, such that the reported value is always inside the green period.

Table of Contents