Weather forecasting at Wankhede Stadium is a useful machine-learning project because the decision is local and time-sensitive. Match organisers may need short-horizon estimates for rainfall, temperature, humidity, wind, and heat stress—not a generic forecast for Mumbai. A multilayer perceptron (MLP) can learn relationships between recent observations, calendar signals, and nearby weather measurements, provided the dataset is designed carefully.
An MLP will not replace the India Meteorological Department (IMD), nowcasting systems, or radar-based alerts. Its practical role is to provide a calibrated, venue-specific layer that supports decisions such as ground preparation, staff deployment, player cooling breaks, and event communication.
Define the forecasting task first
Start with one target and one forecast horizon. A project becomes difficult to evaluate when it tries to predict every weather variable at once without defining what “accurate” means.
Useful first targets include:
- Rain occurrence: Will measurable rain occur at the stadium in the next 1, 3, or 6 hours?
- Rainfall amount: How many millimetres of rain will be recorded during the next time window?
- Temperature: What will the air temperature be one hour ahead?
- Humidity or heat index: Will conditions cross an operational threshold?
- Wind: What will the average speed or direction be during the next hour?
Use a binary output with a sigmoid activation for rain occurrence, a linear output for temperature or wind speed, and a count or regression approach for rainfall amount. For a first prototype, a one-hour-ahead rain classifier and temperature regressor are manageable separate models.
This is a point-forecasting problem, not a claim that an MLP can predict the exact weather above every part of the ground. Wankhede’s coastal setting, sea breeze, monsoon convection, surrounding buildings, and sparse local sensors create uncertainty. Report that uncertainty instead of presenting a single number as fact.
Build a venue-focused dataset
The best input is a consistent time series at a fixed interval, such as 10 or 15 minutes. Combine the following sources, documenting the timestamp, location, units, and licence for each field:
- A reliable station near the stadium, ideally supplemented by an on-site sensor.
- Historical observations from a recognised meteorological provider.
- Radar or satellite-derived precipitation indicators where licensing and resolution permit.
- Forecast variables from a numerical weather prediction service.
- Calendar features: month, hour, day, and match or event status.
- Derived features such as rolling rainfall, temperature change, pressure trend, and wind-vector components.
Do not silently treat a city-wide weather reading as a stadium observation. Store the distance and elevation of every station, then compare candidate stations during exploratory analysis. For operational use, log sensor outages and maintenance periods because missingness itself may reveal an unreliable input source.
The pipeline should resemble the production approach used in implementing scalable ML pipelines for predictive analytics: version the raw data, retain feature definitions, and make each training run reproducible.
Engineer features that respect time
Weather is sequential. An MLP does not automatically understand sequence order, so provide that context explicitly. For each prediction timestamp, create lagged and rolling features such as:
- Temperature, humidity, pressure, wind speed, and rainfall at the previous 1, 2, 3, 6, and 12 intervals.
- Rolling rainfall totals over 30 minutes, 1 hour, 3 hours, and 24 hours.
- Rolling mean, minimum, and maximum temperature.
- Pressure slope and changes in wind direction.
- Cyclical encodings for hour and month using sine and cosine.
- Distance or direction to the nearest active rainfall cell, if available.
Avoid leakage. A feature must contain only information that would have been available at prediction time. For example, a daily rainfall total that includes the hours after the forecast timestamp cannot be used as an input. Fit imputers and scalers on the training period only, then apply them unchanged to validation and test data.
Cyclical time encoding is preferable to feeding “23” and “0” as unrelated numbers. For hour h, use sin(2πh/24) and cos(2πh/24). Apply the same idea to the month or day of year to represent seasonal continuity.
Split and prepare the data correctly
Do not use a random train-test split for time-dependent weather data. It can place nearly identical observations from the same weather event in both sets and produce an inflated score. Use a chronological split, for example:
- Training: earliest 70% of timestamps.
- Validation: subsequent 15% for tuning and early stopping.
- Test: final 15%, kept untouched until the end.
A stronger evaluation uses walk-forward validation: train on an expanding historical window, forecast the next block, then move forward. Include at least one monsoon period and one dry-season period in the test design. If your data covers only a short period, label the result as a prototype rather than a reliable year-round system.
Handle missing values explicitly. Short gaps may be interpolated for slowly changing variables, but rainfall should not be casually smoothed across an event. Add missingness flags, investigate sensor downtime, and reject or quarantine records with impossible values. Standardise numerical features with a training-only StandardScaler; one-hot encode categorical variables if they are needed.
Build a baseline before the MLP
A model is useful only if it beats a sensible baseline. Compare the MLP against:
- Persistence: the next value equals the latest observation.
- Seasonal or hourly average.
- Logistic regression for rain occurrence.
- Random forest or gradient-boosted trees for tabular features.
- The external forecast used by the operations team.
For a rain classifier, report precision, recall, F1 score, ROC-AUC, and especially precision-recall AUC when rain events are uncommon. For continuous targets, report MAE and RMSE. Also assess calibration: if the model says there is a 70% chance of rain, rain should occur roughly 70% of the time across comparable predictions.
Implement a compact MLP in Python
A small network is usually a better starting point than a deep architecture for a venue-sized dataset. The following Keras pattern assumes X_train, y_train, X_val, and y_val have already been created without leakage:
import tensorflow as tf
from tensorflow import keras
from tensorflow.keras import layers
model = keras.Sequential([
layers.Input(shape=(X_train.shape[1],)),
layers.Dense(64, activation="relu"),
layers.Dropout(0.20),
layers.Dense(32, activation="relu"),
layers.Dense(1, activation="sigmoid") # rain probability
])
model.compile(
optimizer=keras.optimizers.Adam(learning_rate=1e-3),
loss="binary_crossentropy",
metrics=[keras.metrics.AUC(name="pr_auc"), "accuracy"]
)
callbacks = [
keras.callbacks.EarlyStopping(
monitor="val_pr_auc", mode="max", patience=10,
restore_best_weights=True
)
]
history = model.fit(
X_train, y_train,
validation_data=(X_val, y_val),
epochs=150,
batch_size=64,
callbacks=callbacks,
verbose=1
)For temperature, replace the sigmoid with a linear output and use a regression loss such as MAE or Huber loss. Class imbalance may require class weights, threshold tuning, or focal loss. Select the decision threshold based on the operational cost of missed rain versus unnecessary ground-cover deployment—not automatically at 0.5.
Validate for real stadium decisions
Evaluate performance separately for monsoon and non-monsoon periods, daytime and night matches, light rain and heavy rain, and different lead times. A model that performs well on average but misses intense showers is not operationally safe. Plot predicted versus observed values, confusion matrices, reliability curves, and error by hour.
Run a backtest that simulates the actual workflow: freeze inputs at each timestamp, generate a forecast, record the alert, and compare it with observations. Keep a human-readable prediction log containing model version, input timestamp, forecast horizon, probability, threshold, and data-quality status.
For monitoring, track feature drift, missing-data rates, calibration, and recent error. Retrain on a schedule only after checking whether the new data is representative. A simple dashboard can show the MLP output beside official forecasts, recent observations, confidence bands, and a clear “data unavailable” state.
The same disciplined approach applies to other Indian location-specific forecasting projects, including Bhubaneswar weather prediction with Hugging Face models and Guwahati weather prediction with Hugging Face models. The model architecture may change, but provenance, temporal validation, and transparent uncertainty remain essential.
Limitations and responsible use
An MLP cannot create information that the sensors do not capture. Coastal convection can develop rapidly, and a station several kilometres away may not represent conditions over the pitch. Avoid promising “accurate weather” without a defined horizon, target, geography, and test period. Use official alerts for safety-critical decisions, and provide escalation rules when the model is uncertain or inputs are stale.
For a production deployment, add data-quality checks, model versioning, access controls, alert audit trails, and a fallback to the external forecast. A predictive analytics solution for Indian SMEs offers a useful reference point for connecting model outputs to practical business workflows rather than treating prediction as the final product.
Conclusion
To use a multilayer perceptron to predict weather in Wankhede Stadium, Mumbai, define a narrow forecast target, collect venue-relevant time series, engineer lagged features without leakage, validate chronologically, and compare the MLP with simple baselines. Treat probability calibration, seasonal robustness, and data quality as first-class requirements. The result should be a decision-support service with clear limits—not a replacement for official meteorological guidance.
FAQ
Can an MLP predict rain at Wankhede Stadium accurately?
It can learn useful local patterns, especially for short horizons, but accuracy depends on sensor proximity, historical coverage, rainfall labels, and the rapidly changing monsoon environment. Benchmark it against persistence and official forecasts.
How much data is needed?
Use as much consistent, timestamped history as possible, ideally covering multiple monsoon cycles. A small dataset can support a prototype, but it will not justify strong claims about rare extreme events.
Should I use an LSTM instead?
An LSTM or temporal model may help when long sequential dependencies matter. Start with an MLP using well-designed lag features; choose a more complex model only if walk-forward tests show a meaningful improvement.
What should organisers do when the model disagrees with IMD guidance?
Use predefined escalation rules, inspect data freshness, and defer to official warnings for safety-critical action. Record the disagreement for later evaluation rather than overriding guidance automatically.
AI builders in India working on climate, sports, or public-interest applications can explore support through AI Grants India.