granite-geospatial-biomass

What is Granite Geospatial Biomass?

Granite Geospatial Biomass is an open-weight geospatial foundation model from IBM Granite. Its task is specific: estimating total above-ground biomass from optical satellite imagery. Above-ground biomass refers to living and dead plant material located above the soil surface, including vegetation in forests, grasslands, and agricultural areas.

Unlike a language model, chatbot, or general-purpose computer-vision system, this model produces a numerical regression result. In practical terms, it analyzes prepared satellite-image data and estimates biomass values across geographic areas, potentially supporting pixel-level biomass maps.

IBM identifies the initial release as version 1, dated July 28, 2024. The model weights and configuration are publicly distributed through the IBM Granite Hugging Face organization and the associated source repository. The release is intended for technical users working with geospatial machine learning, satellite imagery, and environmental analysis.

Primary purpose and positioning

Granite Geospatial Biomass sits within IBM Granite's geospatial model work rather than its text-generation lineup. It is associated with IBM's Geospatial Studio work and the TerraTorch geospatial modeling toolkit. Its purpose is to convert remote-sensing observations into an estimate of a useful environmental variable: above-ground biomass.

This positioning makes it more comparable to a specialized scientific or Earth-observation model than to a general AI assistant. It is intended for workflows where the user supplies appropriately prepared satellite data, runs inference, and then interprets or validates the resulting biomass estimates.

The model can be relevant to forest inventories, carbon accounting, conservation planning, land-use analysis, nature-based climate projects, and research into satellite-derived ecosystem indicators. It may also support agricultural biomass or crop-yield studies, although results should be checked for the specific crop, geography, and imagery conditions involved.

How the model works

The model uses Harmonized Landsat and Sentinel-2 L30 optical imagery. Its published configuration selects six spectral bands: blue, green, red, narrow near-infrared, short-wave infrared 1, and short-wave infrared 2. These bands capture different properties of reflected light from vegetation, soil, and other land surfaces.

Training labels come from NASA's Global Ecosystem Dynamics Investigation GEDI L4A above-ground biomass dataset. IBM reports that fine-tuning used Harmonized Landsat and Sentinel-2 imagery with GEDI biomass labels collected across 15 biomes. That geographic and ecological coverage is intended to expose the model to varied environments rather than a single local landscape.

Under the hood, the model is based on a Prithvi Swin-B geospatial backbone with a UPerNet decoder. The configuration defines a pixelwise regression task, uses a ReLU output activation, includes two learned upscaling layers, and trains with root mean squared error loss. The backbone is fine-tuned rather than kept frozen, allowing its representations to adapt to biomass estimation.

These details matter because the model is not simply classifying an image as forest or non-forest. It is trained to estimate a continuous quantity. The quality of the result therefore depends on image preparation, spatial alignment, the geographic area being analyzed, and the relationship between the supplied imagery and the GEDI-derived labels.

Inputs and outputs

The verified input modality is optical geospatial imagery. Specifically, the model expects prepared data based on six selected bands from Harmonized Landsat and Sentinel-2 L30 imagery. It is not documented as accepting ordinary photographs, text prompts, audio, video, or arbitrary image files without the expected geospatial preprocessing.

The output is a biomass regression result. The model card and configuration describe a pixelwise task, so the output is intended to preserve spatial information rather than provide a conversational explanation. It does not generate natural-language answers, images, audio, video, embeddings, or structured tool actions.

No context-window limit or maximum output-token limit is applicable in the language-model sense, and no model-specific numeric input-size or output-size limit is provided in the supplied research. Users should follow the model configuration and TerraTorch workflow when preparing image tiles and running inference.

Main strengths

• Focused environmental task: The model is built specifically for above-ground biomass estimation instead of requiring users to adapt a general vision model.
• Open distribution: Weights and configuration are available under the Apache 2.0 license, which supports inspection, local experimentation, and integration into suitable research or production workflows subject to the license and applicable data requirements.
• Multi-biome training coverage: The reported training data spans 15 biomes, providing a broader starting point than a model trained only on one local ecosystem.
• Useful geospatial architecture: The Prithvi Swin-B backbone and UPerNet decoder are configured for spatial prediction rather than general image captioning or classification.
• Compatibility with TerraTorch: IBM identifies TerraTorch as the toolkit for loading the checkpoint and configuration and running inference on prepared image directories.
• No hosted inference fee identified: The research found no official per-token or per-request hosted pricing for this model. Because it is distributed as open weights, users can evaluate deployment options based on their own hardware and infrastructure.

The open-weight format can be particularly useful when an organization needs to keep imagery and predictions within its own environment, test the model repeatedly, or build a larger geospatial processing pipeline without depending on a consumer-facing AI interface.

Limitations and risks

Granite Geospatial Biomass is specialized and should not be treated as a universal biomass estimator. Its output can be affected by satellite-data quality, cloud contamination or other preprocessing problems, geographic differences, seasonal conditions, spatial alignment, and the suitability of GEDI-derived labels for the target region.

Training across 15 biomes is useful context, but it does not prove equal accuracy in every country, ecosystem, season, sensor condition, or land-use type. A project that uses the model for carbon accounting, conservation decisions, or financial reporting should perform regional validation against appropriate field measurements or trusted reference data.

The model also does not provide the surrounding software capabilities that users may expect from a general AI platform. There is no verified natural-language interface, web search, conversational memory, function calling, streaming response mode, or general-purpose coding capability. It estimates biomass; it does not independently gather data, explain a result in natural language, or orchestrate a complete environmental workflow.

Preprocessing is another practical consideration. The published workflow expects particular spectral bands and prepared image directories. A user cannot assume that any six-channel image will be interchangeable with the required Harmonized Landsat and Sentinel-2 inputs. Differences in resolution, band definitions, geographic projection, scaling, missing data, and tile construction may affect results.

Pricing and availability

Granite Geospatial Biomass is available as an open-weight model under the Apache 2.0 license through IBM Granite's public model repository. The supplied research does not identify an official hosted API price, subscription price, per-image fee, per-request fee, or per-token price for this specific model.

That does not mean running the model is cost-free. Users may need storage, preprocessing pipelines, compatible compute, and engineering time to prepare satellite data and operate inference. The cost profile is therefore different from a hosted model with a simple usage meter: the software and weights are openly available, while infrastructure and operational costs remain the user's responsibility.

Availability of the model should also be distinguished from availability of IBM watsonx services. Granite Geospatial Biomass is an individual open-weight geospatial model, not a claim that every watsonx product or deployment offers a ready-made hosted endpoint for it.

Reasoning, coding, and speed considerations

The model does not perform language-based reasoning. Its published task is numerical geospatial regression, so a database-style reasoning score or conversational intelligence rating would not meaningfully describe its behavior. Similarly, it does not generate code, although developers can use code around it to prepare imagery, run inference, and analyze results.

The research does not provide a benchmark-based latency figure, throughput figure, hardware requirement, or maximum processing speed. As an editorial assessment, its open-weight local deployment may offer better cost control for repeated processing than a paid hosted service, but actual speed will depend on the image size, tiling strategy, hardware, storage, preprocessing pipeline, and implementation.

Compared with a general-purpose vision or language model, Granite Geospatial Biomass sacrifices broad interaction and tool capabilities for a narrower scientific objective. That trade-off is appropriate when the required output is biomass estimation from the correct satellite inputs, but not when the project needs image understanding across arbitrary subjects, natural-language reporting, or automated workflow control.

Best use cases

• Mapping above-ground biomass over forested or other vegetated regions.
• Supporting forest monitoring and timber-production analysis.
• Estimating carbon stocks as one component of a broader validated carbon-accounting workflow.
• Screening or studying nature-based climate projects.
• Analyzing ecological change and land-use patterns using satellite-derived indicators.
• Research into satellite-based agricultural biomass and crop-yield estimation.
• Developing or testing geospatial machine-learning pipelines with open model weights.

When to choose this model

Choose Granite Geospatial Biomass when the central problem is estimating above-ground biomass from the specified Harmonized Landsat and Sentinel-2 optical inputs, and when you can manage geospatial preprocessing, local inference, and validation. It is especially suitable for researchers and organizations that value open weights, Apache 2.0 licensing, and control over where imagery and predictions are processed.

Another option may be more appropriate when the project requires a conversational assistant, broad image understanding, text or code generation, image creation, real-time web research, or integrated tool calling. A general-purpose model may also be preferable for producing narrative reports after a separate biomass system has generated the measurements. Conversely, a locally trained or regionally calibrated model may be a better choice when the target geography differs substantially from the training distribution or when the application requires formally demonstrated local accuracy.

The most defensible deployment pattern is to treat Granite Geospatial Biomass as a specialized measurement component. Prepare compatible imagery carefully, run the model with TerraTorch, compare predictions with independent reference data, and communicate uncertainty and validation results alongside any biomass map.