How to Use LightGBM to Predict Weather at Barabati Stadium

What you are actually building

A useful forecast for Barabati Stadium is not a generic city-level weather model. It is a location-specific, time-aware prediction system that estimates conditions at a defined lead time—for example, rainfall probability three hours before a match, temperature at kickoff, or wind speed during an evening event.

This distinction matters in Cuttack. A weather station several kilometres away may not capture local effects around the stadium, while a model trained on randomly shuffled observations can accidentally learn from future weather. LightGBM is a strong tabular machine-learning option, but the quality of the forecast will depend more on data design, leakage controls, and operational thresholds than on the algorithm alone.

For teams building a repeatable system, this workflow complements guidance on implementing scalable ML pipelines for predictive analytics.

Define the forecast target first

Do not begin by collecting every available weather variable. Start with one decision and one target.

Useful targets include:

Rainfall classification: whether measurable rain occurs in the next 1, 3, or 6 hours.
Rainfall amount: millimetres accumulated over a future interval.
Temperature regression: air temperature at a scheduled start time.
Wind prediction: mean or maximum wind speed during an event window.
Operational risk: a composite label such as “play disruption likely”.

For a cricket fixture, a binary target may be the most actionable: rain_next_3h = 1 when rainfall exceeds a chosen threshold in the following three hours. Keep the threshold explicit and review it with event operations. A drizzle threshold for pitch protection may differ from the threshold used for spectator safety.

Use separate models for materially different targets. A rainfall classifier and a temperature regressor require different objectives, metrics, and decision thresholds.

Assemble local, time-stamped data

Create a dataset at a fixed interval—such as 15 minutes, 30 minutes, or one hour. Every row should represent the information available at that moment, not observations collected later.

Potential inputs include:

IMD observations, forecasts, radar products, and nearby automatic weather stations where licensing permits.
Temperature, relative humidity, pressure, wind direction, wind speed, visibility, and precipitation.
Numerical weather prediction forecasts and their lead time.
Satellite or radar-derived rainfall indicators, if available.
Stadium coordinates, elevation, and distance to each observation source.
Match or event start time, duration, day of week, and indoor/outdoor status.

Record the source and retrieval timestamp for every forecast feed. A forecast issued at 10:00 for 14:00 is not equivalent to an observation recorded at 14:00. Preserve that distinction in columns such as issued_at, valid_at, and lead_minutes.

For nearby modelling patterns, compare the approach with Bhubaneswar weather prediction using Hugging Face models and Guwahati weather prediction using Hugging Face models. The locations differ, but the lesson is consistent: regional forecasts need careful handling of local observations and forecast horizons.

Engineer features without leaking the future

LightGBM handles numerical and categorical features well, so extensive scaling is usually unnecessary. Focus instead on features that represent recent weather dynamics and seasonality.

Recommended features include:

Lagged temperature, humidity, pressure, wind, and rainfall values.
Rolling averages and maxima over the previous 1, 3, 6, and 24 hours.
Rainfall totals over recent windows and time since the last rain event.
Hour of day, month, monsoon-season indicator, and cyclical sine/cosine time features.
Forecast values aligned to their issue time and target validity window.
Differences between forecast and latest observed conditions.
Distance and direction to observation stations, if multiple stations are used.

A critical rule is that every feature must be available at prediction time. Do not use the final daily rainfall total, a corrected observation, or a forecast revision published after the prediction timestamp. Missing values can be retained by LightGBM, but investigate whether missingness itself reflects a sensor outage or a meaningful operational signal.

Split the data chronologically

A random 80/20 split is inappropriate for time-series forecasting because it can place future weather patterns in the training set. Use chronological partitions instead:

Training: earliest historical period.
Validation: the next period for tuning and early stopping.
Test: the most recent untouched period.

Prefer rolling or expanding-window backtesting. For example, train on 2021–2023, validate on 2024, and test on 2025; then repeat with several forecast windows. Include monsoon and non-monsoon periods in evaluation. If the model will operate in 2026, a recent holdout is more informative than an average score across old data.

This methodology also applies to other Indian predictive systems, including predictive analytics solutions for Indian SME spinning mills, where temporal drift and operating conditions can distort random splits.

Train a LightGBM model

For rainfall occurrence, use binary classification. For temperature or rainfall amount, use regression. A practical Python baseline is:

import lightgbm as lgb
from sklearn.metrics import roc_auc_score, average_precision_score

features = [c for c in df.columns if c not in
            ["issued_at", "valid_at", "rain_next_3h"]]

train = df[df["issued_at"] < "2025-01-01"]
valid = df[(df["issued_at"] >= "2025-01-01") &
           (df["issued_at"] < "2026-01-01")]

a = lgb.LGBMClassifier(
    objective="binary",
    n_estimators=2000,
    learning_rate=0.03,
    num_leaves=31,
    min_child_samples=50,
    subsample=0.8,
    colsample_bytree=0.8,
    reg_lambda=1.0,
    random_state=42
)

a.fit(
    train[features], train["rain_next_3h"],
    eval_set=[(valid[features], valid["rain_next_3h"])],
    callbacks=[lgb.early_stopping(100), lgb.log_evaluation(0)]
)

probability = a.predict_proba(valid[features])[:, 1]
print(roc_auc_score(valid["rain_next_3h"], probability))
print(average_precision_score(valid["rain_next_3h"], probability))

Treat hyperparameters as a controlled experiment. Tune num_leaves, min_child_samples, learning rate, regularisation, and feature subsampling using time-aware validation. Avoid maximising a single score while ignoring rainy-event performance.

Evaluate for stadium decisions

Accuracy alone can be misleading, particularly when heavy rain is less frequent than dry conditions. For a rainfall classifier, report:

Precision, recall, F1 score, ROC-AUC, and average precision.
Confusion matrices at the chosen operational threshold.
Reliability or calibration curves for predicted probabilities.
Performance separately during monsoon, summer, winter, daytime, and evening periods.
Performance by forecast horizon: 1, 3, 6, and 12 hours.

For regression, use MAE, RMSE, and bias. Always compare LightGBM with simple baselines such as persistence, climatology, and the raw numerical weather forecast. A complex model should improve a decision, not merely produce an impressive offline metric.

If rainfall probability is used to trigger covers, staffing, or schedule changes, calibrate the probability and select the threshold using the cost of false alarms versus missed rain. Monitor drift after deployment: sensor changes, construction near the venue, and shifting monsoon patterns can all reduce performance.

Deploy a practical forecast workflow

A production setup can run every 15 or 30 minutes:

1. Fetch observations and the latest forecast files.
2. Validate timestamps, units, ranges, and missingness.
3. Generate features using only data available at the cutoff time.
4. Produce probabilities or point forecasts with a model version recorded.
5. Store inputs, outputs, and actual outcomes for later backtesting.
6. Send a concise alert to the operations team with horizon, confidence, and recommended action.

Do not present a model output as certainty. Show the forecast window, probability, recent observations, and data freshness. For high-consequence events, combine the model with official meteorological advisories and a human review process.

Common mistakes to avoid

Training on randomly shuffled weather rows.
Mixing station observations with different time zones or units.
Using future-corrected data during historical simulation.
Reporting only overall accuracy on an imbalanced rainfall target.
Assuming stadium-level precision without a nearby, reliable observation source.
Retraining without versioning features, data sources, and model parameters.

LightGBM is a capable baseline for Barabati Stadium, but it is not a substitute for sound meteorology or reliable local measurements. Build the smallest validated system that answers a real event-planning question, compare it with strong baselines, and improve it through monitored backtesting.

Apply for AI Grants India