What is IBM Granite Geospatial Land Surface Temperature?
IBM Granite Geospatial Land Surface Temperature is an open-weight geospatial foundation model for predicting land surface temperature (LST) from Earth-observation data. Its primary purpose is not conversational text generation or image creation. Instead, it processes satellite imagery and climate inputs to produce spatial temperature estimates that can support urban heat analysis, environmental monitoring, and climate research.
The model is part of IBM's Granite geospatial model work and is available for local inference through published model weights and configuration files. It was fine-tuned from IBM's Prithvi-SWIN-L Earth observation foundation model, adapting a general geospatial representation to the specific task of estimating surface temperature.
Land surface temperature describes the temperature of the ground, buildings, vegetation, and other surfaces observed by a satellite. It is different from the air temperature reported by a weather station. Combining the two types of information helps the model estimate detailed surface temperatures while also making use of more frequent climate data.
Input data and model architecture
The documented training data combines Harmonized Landsat Sentinel-2 (HLS L30) imagery with ERA5-Land two-meter near-surface air temperature statistics. The data covers 28 global cities across different hydroclimatic zones and spans 2013 through 2023.
For each input patch, the model uses six HLS spectral bands, B02 through B07, together with an ERA5-Land two-meter temperature layer. The data is arranged into 224-by-224 pixel patches. The target land surface temperature values are derived from HLS data with a split-window algorithm, a remote-sensing technique that estimates surface temperature using thermal observations.
Architecturally, Granite Geospatial Land Surface Temperature uses a Shifted Windowing, or Swin, Transformer encoder. The encoder is based on Prithvi-SWIN-L, and its pretrained weights are unfrozen during fine-tuning. The model also uses a UperNet regression decoder, an auxiliary one-layer convolutional regression head, and a linear final activation layer. In practical terms, these components allow the model to preserve spatial information while producing a continuous temperature estimate for each location.
What the model produces
The model predicts land surface temperature at approximately 30-meter spatial resolution. This is useful for studying temperature differences within cities, where a single coarse grid cell may otherwise combine roads, rooftops, parks, water, and surrounding land.
IBM's documentation also describes hourly temporal use cases. The model can estimate temperature patterns between the relatively infrequent high-resolution satellite observations by using stacked satellite and ERA5 temperature inputs. This process is referred to as temporal gap filling, LST tweening, or LST in-betweening.
The hourly description should be understood as a supported modeling workflow rather than a claim that the model directly observes every location every hour. Satellite observations remain constrained by their acquisition schedule and conditions. The model uses available observations and climate statistics to estimate intermediate values.
Temporal gap filling and urban heat analysis
Temporal gap filling is one of the model's most distinctive uses. Landsat-derived imagery offers detailed spatial information but does not provide continuous observations at every location. ERA5-Land supplies more frequent temperature statistics but at a coarser scale. Granite Geospatial Land Surface Temperature is intended to help bridge this difference by combining the spatial detail of satellite imagery with the temporal information in climate data.
For example, a researcher could use the model to create a sequence of estimated surface-temperature maps for analyzing how heat changes across an urban area. These maps could help identify persistent hot spots, compare built-up areas with parks, or evaluate whether a heat-mitigation intervention is associated with different surface-temperature patterns. Such outputs should be validated against appropriate observations before being used for operational or policy decisions.
Main use cases
- Urban heat-island mapping: Estimate temperature differences between dense built environments, vegetation, water, and surrounding areas.
- Heat-wave analysis: Study the spatial distribution of surface heat during unusually hot periods.
- Environmental monitoring: Support research into land, vegetation, and climate-related changes.
- Temporal gap filling: Estimate land surface temperature between available satellite observations.
- Urban planning: Provide high-resolution evidence for evaluating shade, vegetation, reflective surfaces, and other heat-mitigation approaches.
- Geospatial research: Use an open-weight model in reproducible local workflows rather than relying on a hosted prediction service.
Strengths and practical trade-offs
The model's main strength is task specialization. It is designed around a specific geospatial regression problem, with inputs, training data, and output resolution aligned to land surface temperature estimation. That makes it more relevant to this use case than a general-purpose language model or a generic image model that has not been trained for geospatial temperature prediction.
Its open-weight distribution is another practical advantage. Users can download the weights and configuration, prepare compatible inputs, and run inference locally with TerraTorch, an open-source geospatial deep-learning toolkit. Local execution can be useful for research groups that need control over data handling, repeatable experiments, or integration with existing remote-sensing pipelines.
The model also addresses an important resolution-versus-frequency trade-off. Detailed satellite data can be spatially valuable but temporally sparse, while climate reanalysis data is more frequent but does not provide the same local detail. Granite Geospatial Land Surface Temperature is intended to combine these complementary sources rather than treat either source as sufficient on its own.
These advantages come with setup costs. The model is not a simple web chatbot or a hosted API that accepts a short prompt. Users need correctly prepared HLS bands, ERA5-Land temperature data, spatial reference information, and 224-by-224 input patches. Data preparation, geospatial alignment, local computation, and result validation are part of the workflow.
Supported inputs and outputs
| Category | Documented capability |
|---|---|
| Input type | HLS L30 satellite spectral data and an ERA5-Land two-meter temperature layer |
| Required HLS bands | B02 through B07 |
| Input format | 224-by-224 patches with compatible geospatial preparation |
| Output | Continuous land surface temperature predictions |
| Approximate spatial resolution | 30 meters |
| Temporal use case | Hourly estimation and temporal gap filling |
| Text generation | Not supported as a primary function |
| Hosted API pricing | Not specified in the model documentation |
The model accepts image and geospatial tensor inputs, but it should not be described as a general multimodal assistant. Its output is a numerical geospatial prediction rather than a generated image, audio file, video, or text response. The supplied documentation does not define a language-model context window or maximum output-token limit because those concepts do not apply to this regression workflow.
Pricing, deployment, and tooling
IBM publishes the model weights and configuration for local use under the Apache-2.0 license. The supplied model information does not list a per-call price, subscription plan, token price, commercial hosted endpoint, or maximum output size. Consequently, there is no verified model-specific API price to compare with hosted language or vision models.
Inference guidance is provided for TerraTorch. A typical workflow involves obtaining the required satellite and climate inputs, preparing and aligning the bands, dividing the data into compatible patches, running the model locally, and assembling or interpreting the resulting temperature maps. The repository documentation should be treated as the source of truth for installation and inference commands because those details can change between toolkit versions.
There is no documented function-calling or tool-use interface in the supplied research. TerraTorch and related scripts are deployment and inference tools, not model-level conversational tools. Similarly, streaming responses, batch APIs, JSON mode, and text-oriented caching are not specified for this model.
Limitations and validation requirements
The training coverage is limited to 28 cities and observations from 2013 through 2023. Performance may therefore vary in places, climate regimes, seasons, land-cover types, or sensor conditions that are poorly represented in the training data. A model trained on urban areas from selected hydroclimatic zones should not automatically be assumed to perform equally well in every rural, coastal, arid, tropical, or high-latitude environment.
Input quality is also important. Missing or incorrectly aligned HLS bands, incompatible spatial references, unsuitable ERA5-Land data, cloud-related artifacts, or incorrectly formatted patches can reduce the reliability of the output. The model's predictions are estimates, not direct measurements that remove the need for ground observations or established remote-sensing validation.
For research and planning, users should compare predictions with suitable observations and report the geographic, seasonal, and sensor conditions used for evaluation. Extra caution is appropriate when results could influence public-health responses, infrastructure decisions, or other operational actions.
When to choose Granite Geospatial Land Surface Temperature
Choose this model when the central task is high-resolution land surface temperature estimation from compatible satellite and climate data, especially when temporal gap filling or urban heat analysis is important. It is a good fit for researchers, geospatial analysts, and organizations that want open-weight local inference and are prepared to manage the data pipeline themselves.
A general-purpose language model is more appropriate when the goal is text generation, document analysis, coding assistance, conversation, or tool-driven automation. A conventional remote-sensing algorithm or a model trained for a different sensor may be preferable when the available data does not match the required HLS and ERA5-Land inputs. A hosted geospatial service may also be more suitable for teams that want an easier deployment path and do not need local control over model execution.
Overall, Granite Geospatial Land Surface Temperature is best understood as a focused geospatial regression model. Its value comes from combining satellite detail, climate-data frequency, and an open local-inference workflow—not from general-purpose reasoning, coding, or conversational capabilities.