How to Use Decision Trees to Predict Weather in Indore Stadium

What this model should predict

A decision tree can help an event team convert weather observations into an operational decision: proceed, monitor, delay, relocate, or cancel. That is more useful than attempting to predict weather as a single vague label.

For an event at Indore Stadium, define a forecast window first. A model for the next six hours may use recent observations and nowcast inputs, while a model for an event scheduled several days ahead must rely on forecast products and historical patterns. Treat the output as decision support, not an official warning. For lightning, extreme heat, heavy rain, or strong winds, follow advisories from the India Meteorological Department and instructions from local authorities.

A well-designed system might predict:

Rain during the event: yes or no.
Rain intensity: none, light, moderate, or heavy.
Playable conditions: suitable, uncertain, or unsuitable.
Safety risk: low, medium, or high based on weather thresholds.

This framing also makes the project easier to connect to a broader scalable ML pipeline for predictive analytics, especially when predictions must be refreshed automatically.

Why use a decision tree?

Decision trees split data into rules that people can inspect. For example, the model may learn that when recent rainfall is high, cloud cover is extensive, and humidity is elevated, the probability of rain increases. Unlike many black-box models, these rules can be visualised and explained to venue managers.

They are useful here because they:

Handle numerical inputs such as temperature, pressure, humidity, wind speed, and rainfall.
Accept categorical inputs such as month, weekday, or weather condition.
Capture non-linear relationships without requiring feature scaling.
Produce an interpretable structure for operational review.
Support both classification and regression.

A single tree can overfit easily. For production use, compare it with a Random Forest or gradient-boosting model, while retaining the tree as a transparent baseline. The model should not replace the forecast source; it should combine local observations and forecast information into a venue-specific decision.

Collect Indore-specific data

Use data from a station or forecast grid that represents the stadium’s surroundings. Airport observations, distant city stations, and urban weather sensors may differ from conditions at the venue. Record the source, coordinates, timestamp, units, and update frequency for every observation.

Useful fields include:

Air temperature and apparent temperature.
Relative humidity, dew point, and atmospheric pressure.
Wind speed, gusts, and direction.
Rainfall over the previous 15 minutes, hour, three hours, and 24 hours.
Cloud cover and visibility.
Lightning or thunderstorm indicators where available.
Official forecast variables and warning categories.
Month, hour, monsoon-season indicator, and event type.

The target must be defined from the event’s needs. For instance, set rain_next_2h = 1 when measurable rainfall occurs within the following two hours. If the target is “safe to continue”, document the thresholds with venue staff rather than inventing them from model output.

For a more advanced project, satellite and remote-sensing features can be evaluated alongside station data. The same discipline used in satellite-based yield prediction for insurance providers in India—consistent timestamps, geographic alignment, and leakage control—applies here.

Prepare the dataset correctly

Weather is time-dependent, so random splitting can produce misleading results. Sort records chronologically and use earlier periods for training, a later period for validation, and the most recent period for testing. A practical starting point is:

Training: the earliest 60–70% of observations.
Validation: the next 15–20%.
Test: the final 15–20%.

Avoid leakage. Do not include a variable measured after the prediction time, or a “future rainfall” field accidentally generated while creating the target. Handle missing values explicitly, preserve missingness flags where useful, and check for duplicate timestamps and impossible readings.

Weather events are often imbalanced: most time periods may be dry. Accuracy alone can therefore look impressive while the model misses rain. Report precision, recall, F1 score, balanced accuracy, and a confusion matrix. For probability outputs, also inspect calibration and the Brier score. Evaluate separately for monsoon and non-monsoon periods, daytime and night-time events, and short versus long forecast horizons.

Build a baseline in Python

The following example predicts whether rain will occur in the next two hours. Replace the column names with those in your dataset and ensure that each feature is available at prediction time.

import pandas as pd
from sklearn.tree import DecisionTreeClassifier
from sklearn.metrics import classification_report, confusion_matrix

weather = pd.read_csv("indore_stadium_weather.csv", parse_dates=["timestamp"])
weather = weather.sort_values("timestamp").dropna()

features = [
    "temperature_c", "humidity_pct", "pressure_hpa",
    "wind_speed_kmph", "rain_last_1h_mm", "cloud_cover_pct"
]

cutoff = int(len(weather) * 0.8)
train = weather.iloc[:cutoff]
test = weather.iloc[cutoff:]

model = DecisionTreeClassifier(
    max_depth=5,
    min_samples_leaf=25,
    class_weight="balanced",
    random_state=42
)

model.fit(train[features], train["rain_next_2h"])
predictions = model.predict(test[features])
probabilities = model.predict_proba(test[features])[:, 1]

print(classification_report(test["rain_next_2h"], predictions))
print(confusion_matrix(test["rain_next_2h"], predictions))

max_depth and min_samples_leaf constrain tree complexity. Tune them using time-based validation, not the final test set. If the output will trigger a costly action, select a probability threshold based on the relative cost of false alarms and missed rain. A cricket match, concert, and school event may reasonably use different thresholds.

Turn predictions into event actions

A probability is not a plan. Create a simple runbook with owners and lead times. For example:

Low risk: continue setup; monitor the next scheduled update.
Medium risk: inspect drainage, protect equipment, brief security, and prepare a delay announcement.
High risk: pause exposed work and escalate to the event controller.
Lightning or severe-weather warning: follow official guidance immediately, regardless of the model’s score.

Log every prediction, input snapshot, action, and eventual outcome. This creates an audit trail and supports retraining. The operational design is similar to AI predictive maintenance for railway infrastructure assets: detect risk early, define escalation rules, and measure whether alerts lead to useful action.

Common failure modes

Too little local data: supplement with nearby stations, but label the source and test location bias.
Random train-test splits: use chronological evaluation instead.
Overfitting: prune the tree and compare performance across seasons.
Uncalibrated probabilities: calibrate with a validation set before using risk thresholds.
False precision: show uncertainty and forecast horizons to users.
No monitoring: track data freshness, missing fields, drift, and alert frequency.
Ignoring microclimates: validate predictions against observations collected near the stadium.

A decision tree is especially valuable as a transparent baseline, not necessarily as the final model. If it performs poorly, investigate data quality and target design before adding complexity. For deployment, use reproducible versioning, automated tests, and monitoring practices described in predictive analytics solutions for Indian SME spinning mills.

Practical checklist for 2026

Before relying on the system for an event, confirm that you have:

At least one full year of timestamped local or nearby observations, with seasonal coverage preferred.
A clearly defined target and forecast horizon.
Chronological validation and a held-out test period.
Metrics beyond accuracy, including recall for hazardous conditions.
A documented escalation policy linked to official warnings.
Data-quality checks and a fallback when the feed is unavailable.
A human owner responsible for reviewing alerts.

The result should be a small, tested decision-support service: ingest current data, produce a calibrated risk estimate, display the factors driving the result, and route the decision to the event team. That is a safer and more useful interpretation of how to use decision trees to predict weather in Indore Stadium than treating a machine-learning label as a guaranteed forecast.

FAQ

Can a decision tree predict weather accurately several days ahead?
Its performance will usually decline as the horizon increases. For longer horizons, combine official forecasts with historical features and communicate uncertainty clearly.

Should weather data be normalised?
Decision trees do not require feature scaling, although consistent units and sensible ranges are essential.

How often should the model be retrained?
Set a schedule based on data volume and drift. Review performance after each season and after major sensor or forecast-source changes.

Can this be used for safety decisions?
Use it as supplementary decision support. Official warnings, local authorities, and the venue’s safety plan take priority for hazardous weather.

Apply for AI Grants India