Sharing
To maximize the impact and reproducibility of the results, it is essential to provide a robust infrastructure for data sharing that addresses two distinct user requirements: large-scale batch downloads for researchers who need to integrate spatial predictions into their own analytical pipelines, and interactive visualization interfaces for stakeholders who want to explore results and perform targeted downloads of specific areas.
Compression
Data accessibility is inextricably linked to storage efficiency: large datasets can be a deterrent to researchers with limited storage resources. To facilitate the dissemination of high-resolution maps, compression provides a practical framework for reducing storage overhead. In scenarios where high numerical precision is not the primary requirement, lossy compression can be employed by rounding \(32\)-bit floating-point values to the nearest integer and storing them as \(8\)-bit unsigned integers. Where finer detail is necessary, fixed-point scaling offers a viable alternative: for instance, biomass values in the range of \([0, 500]\) can be multiplied by a factor of \(100\) to preserve two decimal places within a \([0, 50000]\) range, enabling the use of \(16\)-bit unsigned integers. Furthermore, for applications demanding bit-for-bit accuracy, modern lossless compression methods (e.g., [1]) ensure data integrity while minimizing the digital footprint. By adopting these multi-tiered compression strategies, data providers can significantly lower the barrier to entry for geospatial analysis.
Product grid
The product grid determines how the finished map is stored and distributed. At a minimum, the map should be distributed in the CRS in which it was predicted, typically the UTM zone of each tile, so that no pixel is resampled and its values are exactly those the model produced. It can additionally be offered in a single global CRS, which is convenient for visualization and for analyses spanning several UTM zones, but which requires reprojecting every pixel. Resampling introduces artifacts whose severity depends on the interpolation method and on the geometric distortion between the source and target projections.
Native-CRS products can be distributed as a collection of tiles, one per CRS involved. Tiles can be stored as COGs, which support partial reads via HTTP range requests, allowing downstream users to retrieve only the spatial extent or resolution level they need. Discovery and access can be further streamlined by publishing the tile collection as a SpatioTemporal Asset Catalog (STAC), which provides a standardized, queryable index of assets along with their spatial extents, timestamps, and associated metadata. The tiles can also be stored as Zarr arrays, which do not need STAC to be navigated.
A global layer in a single CRS is most easily distributed as one chunked array, such as a Zarr store. Some platforms, however, require other formats: Google Earth Engine, for example, ingests GeoTIFFs, and large areas are in practice uploaded as several tiles. Many global products are distributed as such tiles: the ESA WorldCover [2] and global canopy height [3] products are distributed in 3°×3° tiles, and the Tropical Moist Forests dataset [4] in 10°×10° tiles.
For products that include vector outputs (e.g., from polygonization), cloud-native formats such as GeoParquet for efficient columnar storage, PMTiles for web-based visualization, and FlatGeobuf for streaming and spatial filtering over HTTP offer lightweight, interoperable alternatives to traditional shapefiles.
Platforms
Several platforms are available for hosting global products, each with different trade-offs in accessibility, infrastructure requirements, and long-term sustainability. Research data repositories such as Zenodo are built for archiving rather than access: their per-record limits (currently 50 GB and 100 files, extendable to 200 GB on request) mean that large products are typically split into regional files or archives, which users must download before use rather than stream for a specific area of interest. In exchange, they offer long-term preservation, versioning, and a DOI. Object storage provides a reliable backbone for distributing large datasets in cloud-native formats, and community-oriented repositories such as Source Cooperative lower the barrier further by offering (to this date) free hosting for open geospatial data. Self-hosting on an institutional server gives full control over formats and access at little direct cost, but ties the product’s availability to the group’s resources and staff. Google Earth Engine offers high visibility and built-in interactive tooling, but requires data to be ingested into its own infrastructure, introducing platform dependency. Public infrastructures such as the French Theia or the Belgian Terrascope keep data under public control with long-term commitments, often exposing it through STAC catalogs, although they are typically not yet as convenient to use as commercial platforms. Domain-specific platforms such as Global Forest Watch and EOForestSTAC provide established dissemination channels with dedicated user bases; however, contributing new datasets to these platforms typically requires coordination with their maintainers rather than direct self-service upload, making them more suitable as complementary high-visibility channels than as primary distribution mechanisms. Furthermore, no single platform is universally optimal, and the long-term availability of any given service cannot be guaranteed.
A map product is only as credible as its validation. The preceding sections addressed how to build a map; the next section addresses how to determine whether that map is accurate, and under what conditions its accuracy claims can be trusted. We argue that validation is not a final box-checking exercise but a design problem in its own right, one that should be planned alongside the map itself.