How to Use Lasso Regression for Wankhede Weather Prediction

Weather forecasting for a cricket venue is a useful machine-learning project—but it needs more discipline than fitting a regression model to a spreadsheet. Wankhede Stadium sits on Mumbai’s coast, where humidity, sea breezes, monsoon rainfall, cloud cover, and fast-changing local conditions can affect match operations. A lasso model can help estimate a continuous target such as rainfall amount, temperature, or humidity, provided the dataset and validation strategy reflect the forecasting task.

This guide shows how to use lasso regression to predict weather in Wankhede Stadium with Python, while keeping the approach realistic for a 2026 prototype. It is suitable for analysts, students, and sports-technology teams building decision-support tools—not as a replacement for official warnings from the India Meteorological Department (IMD).

Define the forecasting task first

Start by deciding exactly what the model must predict and how far ahead. These choices determine the features, labels, and evaluation method.

Useful targets include:

Rainfall in millimetres during the next hour, three hours, or day.
Temperature at a specific forecast horizon.
Relative humidity at match start or innings break.
Probability of rain, created by converting rainfall into a binary outcome.

Lasso regression is designed for continuous outputs. If the requirement is “will rain exceed 1 mm in the next three hours?”, use logistic regression with an L1 penalty or another classification model. If the requirement is expected rainfall, lasso is appropriate as a baseline.

For venue operations, define practical thresholds. A grounds team may care about any measurable rain; broadcasters may need a probability of disruption; fans may need a simple rain-risk indicator. A technically accurate model is less useful if it does not answer an operational question.

Collect data for Wankhede Stadium

Use observations from the stadium or the nearest representative weather station. Mumbai’s coastal microclimate means that a distant station may not capture conditions at Marine Drive accurately.

Potential inputs include:

Temperature, dew point, and relative humidity.
Wind speed, wind direction, and gusts.
Atmospheric pressure and pressure change.
Rainfall, cloud cover, visibility, and solar radiation.
Hour, day of year, monsoon-season indicator, and holiday or match-event flags.
Radar, satellite, or nowcasting signals where licensing and access permit.

Possible sources include IMD data, a reliable weather API, airport or coastal station observations, and calibrated on-site sensors. Keep the source, timestamp, unit, station location, and collection method for every record. Do not silently merge data from providers with different measurement intervals or definitions.

If the project must operate across several locations, review the modelling principles in Bhubaneswar weather prediction with Hugging Face models and Guwahati weather prediction with Hugging Face models. The same pipeline can be adapted, but local calibration remains essential.

Prepare time-series features correctly

Create one row per forecast issue time. For example, a row issued at 10:00 should use information available at 10:00 and predict rainfall between 10:00 and 13:00. Never include observations that became available after the forecast was issued.

Useful engineered features include:

Lagged temperature, humidity, pressure, and rainfall values.
Rolling averages and maximums over the previous 3, 6, 12, and 24 hours.
Rainfall totals over recent windows.
Pressure tendency, such as the change over the previous three hours.
Sine and cosine transformations of hour and day-of-year to represent cyclical time.
Wind direction encoded as sine and cosine rather than an arbitrary number.
Interaction terms such as humidity multiplied by temperature, if justified.

Handle missing values using methods available at prediction time. Forward filling may be reasonable for a short sensor gap, but it can hide serious outages. Add missingness indicators when the absence of a reading may itself signal a sensor problem. Remove duplicate timestamps, standardise units, and inspect extreme values before training.

Lasso is sensitive to feature scale. Use StandardScaler inside a pipeline so scaling is fitted only on training data. This prevents test information from leaking into the model.

Train a lasso model in Python

A pipeline makes preprocessing and modelling reproducible. The example below predicts a continuous rainfall_next_3h_mm target from already-created features.

import pandas as pd

from sklearn.compose import TransformedTargetRegressor
from sklearn.impute import SimpleImputer
from sklearn.linear_model import Lasso
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler

weather = pd.read_csv("wankhede_weather_features.csv", parse_dates=["issue_time"])
weather = weather.sort_values("issue_time").dropna(
    subset=["rainfall_next_3h_mm"]
)

features = [
    "temperature_lag_1h", "humidity_lag_1h", "pressure_lag_1h",
    "rainfall_last_3h", "rainfall_last_24h", "wind_speed_lag_1h",
    "pressure_change_3h", "hour_sin", "hour_cos",
    "dayofyear_sin", "dayofyear_cos"
]

X = weather[features]
y = weather["rainfall_next_3h_mm"]

model = Pipeline([
    ("imputer", SimpleImputer(strategy="median")),
    ("scaler", StandardScaler()),
    ("lasso", Lasso(alpha=0.05, max_iter=20000))
])

model.fit(X, y)
predictions = model.predict(X.tail(24))

For rainfall, predictions can be negative because ordinary regression has no physical lower bound. Clip negative values to zero for a basic operational output, but record how often this happens. Frequent negative predictions indicate that a simple linear model may be poorly suited to the target. A log-transformed target, a two-stage rain/no-rain model, or a specialised count or probabilistic model may perform better.

Tune alpha without leaking future information

The alpha parameter controls the strength of the L1 penalty. A larger value produces more shrinkage and usually fewer active features; a smaller value fits the training data more closely and may overfit.

Do not use a random train-test split for a forecasting problem. Random splitting can place observations from the same weather episode in both sets, creating an unrealistically easy test. Instead:

Sort records chronologically.
Reserve the latest period as a final test set.
Use expanding-window or rolling-window cross-validation on the earlier period.
Tune alpha only within the training portion.
Refit once on the selected training data, then evaluate on untouched future observations.

TimeSeriesSplit can support this process, although the gap between training and validation windows may need adjustment for the forecast horizon. Test performance separately for dry season, southwest monsoon, post-monsoon, and extreme-rain events. An overall average can conceal poor performance during the exact conditions the venue team cares about most.

For a broader production workflow, see implementing scalable ML pipelines for predictive analytics. Version the data, feature code, model parameters, and evaluation results so a forecast can be audited later.

Evaluate what matters operationally

Use several metrics rather than relying on R-squared alone:

MAE: average absolute error, easy to explain in millimetres or degrees.
RMSE: penalises large misses, useful when heavy rain matters most.
R-squared: describes explained variance but can be misleading for seasonal or low-variance data.
Bias: shows whether the model systematically overpredicts or underpredicts.
Rain-event recall and precision: essential when converting rainfall into an alert.

Always compare lasso with simple baselines: persistence, seasonal averages, and a regular linear model. If lasso does not beat those baselines, the issue may be data quality or feature design rather than insufficient model complexity.

Inspect the fitted coefficients after accounting for standardisation. Non-zero coefficients show which inputs the model retained, but they do not prove causation. Correlated variables can cause lasso to select one feature and suppress another somewhat arbitrarily. Use coefficient stability across time folds to identify features that are consistently useful.

Deploy with safeguards

A usable Wankhede forecast service should store the issue time, forecast horizon, input snapshot, model version, prediction, and confidence or error history. Monitor missing sensors, distribution shifts, stale API responses, and forecast error by season. Trigger a fallback to an official provider or a simple baseline when data quality checks fail.

Present results as decision support—for example, “estimated rainfall: 2.4 mm in the next three hours”—rather than claiming certainty. For match postponements, lightning, flooding, or public-safety decisions, defer to official IMD alerts and venue protocols.

The project can also become a reusable asset for other operational use cases. Teams already exploring predictive analytics solutions for Indian SME spinning mills or AI predictive maintenance for railway infrastructure assets can apply the same principles: trustworthy data capture, time-aware validation, interpretable features, and monitoring after deployment.

Practical checklist

Before publishing a forecast dashboard, confirm that you have:

A clearly defined target and forecast horizon.
Local or properly calibrated observations.
Features built only from information available at issue time.
Chronological validation and a held-out future test period.
Baseline comparisons and seasonal error analysis.
A documented response to negative rainfall predictions and missing data.
Alerts that support, rather than replace, official weather guidance.

Lasso regression is valuable here because it creates a compact, interpretable baseline from many correlated weather signals. Its real strength is not a promise of perfect forecasting; it is a disciplined starting point for building a measurable, maintainable weather decision system for Wankhede Stadium.

Apply for AI Grants India