Weather prediction for Eden Gardens is a useful machine-learning project because the venue’s decisions are sensitive to short-term rain, humidity, temperature, wind, and wet-bulb conditions. A model can support match planning, ground-staff preparation, event operations, and research—but it should complement, not replace, official forecasts from the India Meteorological Department (IMD).
This guide explains how to use random forest regression to predict weather in Eden Gardens with a reproducible Python workflow. The focus is not on claiming perfect forecasts. It is on building a model that uses historical observations correctly, avoids time-series leakage, and produces measurements you can evaluate and improve.
Define the prediction task first
“Weather prediction” is too broad for a useful model. Choose one target, forecast horizon, and update frequency. Practical targets include:
- Rainfall amount in millimetres over the next hour, six hours, or 24 hours.
- Air temperature at a defined future time.
- Relative humidity or wet-bulb temperature.
- Wind speed or gust speed.
- Probability of measurable rain, which is a classification problem rather than regression.
For a first Eden Gardens project, predict the next-hour or next-six-hour rainfall amount. If rain/no-rain decisions matter more than exact millimetres, build a separate classifier. Do not turn regression outputs into probabilities without calibration.
A forecast must also specify its timestamp. Predicting conditions at 6 pm using data available at 5 pm is valid; including a 6 pm observation in the input is leakage. This distinction is more important than choosing a sophisticated algorithm.
Collect and align local weather data
Use the nearest reliable observation source available to you, while documenting its distance and exposure. Possible inputs include an on-site station, IMD observations, airport or city weather stations, and reputable weather APIs. Venue-level weather can differ from a city-wide reading, particularly during intense convective showers, so record the source and avoid presenting a proxy as ground truth.
Useful columns include:
- Timestamp in Asia/Kolkata time, stored consistently.
- Temperature, relative humidity, pressure, wind speed, wind direction, and rainfall.
- Cloud cover, visibility, dew point, solar radiation, and weather condition codes where available.
- A data-source identifier and quality-control flag.
Create a regular time grid, such as one row every 15 or 60 minutes. Remove duplicate timestamps, investigate impossible values, and preserve missingness indicators. Do not silently fill long gaps. Short gaps may be interpolated for slowly changing variables, but rainfall should generally be aggregated or treated carefully because an interpolation can invent rain.
For a production project, maintain a small data dictionary covering units, sensor changes, timezone rules, station moves, and API revisions. These details often explain sudden model degradation better than hyperparameters do.
Engineer features that respect time
Random forests cannot automatically understand that two timestamps are close in a cycle or that recent rainfall matters. Build features using only information available before the forecast issue time:
- Lagged temperature, humidity, pressure, wind, and rainfall values.
- Rolling rainfall totals over the previous 1, 3, 6, and 24 hours.
- Rolling mean, minimum, maximum, and standard deviation for temperature and pressure.
- Time of day, month, monsoon season, and days since the last measurable rain.
- Cyclical encodings such as
sinandcosfor hour and day-of-year. - Differences such as pressure change over three hours or humidity change over one hour.
For Kolkata, seasonality matters. Monsoon rainfall dynamics differ from winter and pre-monsoon conditions, so evaluate performance by season rather than relying only on one overall score. If you combine station observations with numerical weather forecasts or satellite-derived variables, retain the forecast issue time and lead time. This makes the feature set auditable.
A well-structured scalable machine-learning pipeline can automate ingestion, feature creation, validation, and retraining as the dataset grows.
Train a leakage-free Random Forest model
Use a chronological split instead of a random train-test split. For example, train on the earliest 70%, validate on the next 15%, and test on the latest 15%. Better still, use rolling-origin evaluation: train on an initial period, forecast the next block, expand the training window, and repeat.
import pandas as pd
from sklearn.ensemble import RandomForestRegressor
from sklearn.metrics import mean_absolute_error, mean_squared_error
weather = pd.read_csv("eden_gardens_weather.csv", parse_dates=["timestamp"])
weather = weather.sort_values("timestamp").dropna(subset=["target_rain_mm"])
features = [
"temp_lag_1", "humidity_lag_1", "pressure_change_3h",
"rain_rolling_3h", "rain_rolling_24h", "wind_lag_1",
"hour_sin", "hour_cos", "month_sin", "month_cos"
]
cutoff = weather["timestamp"].quantile(0.85)
train = weather[weather["timestamp"] < cutoff]
test = weather[weather["timestamp"] >= cutoff]
model = RandomForestRegressor(
n_estimators=400,
max_features=0.8,
min_samples_leaf=2,
random_state=42,
n_jobs=-1
)
model.fit(train[features], train["target_rain_mm"])
prediction = model.predict(test[features])
mae = mean_absolute_error(test["target_rain_mm"], prediction)
rmse = mean_squared_error(test["target_rain_mm"], prediction) ** 0.5
print({"MAE_mm": mae, "RMSE_mm": rmse})Random Forest is attractive for tabular weather data because it captures nonlinear relationships, handles mixed feature scales, and needs little preprocessing. Numerical normalization is usually unnecessary. However, it does not extrapolate well beyond the target range, can produce overly conservative rainfall estimates, and may struggle with rare extreme events.
Tune n_estimators, max_depth, min_samples_leaf, and max_features using only the training and validation periods. Keep the final test period untouched until model selection is complete. Compare against simple baselines such as “next value equals the latest value,” a seasonal average, and an official forecast. A complex model that does not beat these baselines is not ready for deployment.
Evaluate performance for real decisions
Report MAE for average error, RMSE when large misses matter, and a suitable explained-variance measure for continuous targets. R² alone can look acceptable while the model performs poorly during rainfall events. Break results down by:
- Rain versus dry periods.
- Light, moderate, and heavy rainfall.
- Monsoon, pre-monsoon, winter, and post-monsoon periods.
- One-hour versus longer forecast horizons.
- Day and night, if sensor coverage differs.
Inspect residual plots and the largest misses. For an event operator, a missed heavy shower may matter more than a small temperature error. Consider quantile models, conformal prediction, or ensembles to provide prediction intervals rather than a single number. Intervals should be checked for empirical coverage on a genuinely future period.
Feature importance can help diagnose the model, but impurity-based importance is biased toward high-cardinality variables. Use permutation importance or SHAP with care, and treat explanations as associations rather than causal evidence. This is similar to other predictive analytics systems: monitoring data quality and operational error matters as much as the model itself.
Deploy and monitor the forecast
A practical service can run every 15 or 60 minutes: fetch new observations, apply the identical feature pipeline, generate a forecast, store the input snapshot, and expose the result through a dashboard or API. Log model version, data timestamp, forecast horizon, source station, and missing-value actions.
Set alerts for stale data, impossible readings, feature drift, and error spikes. Retrain on a fixed schedule only after checking whether new data is trustworthy; automated retraining can amplify a broken sensor or API change. A lightweight ML pipeline for predictive analytics should include tests for timezone handling, lag calculations, schema changes, and chronological splits.
For match or event operations, display the model forecast alongside IMD and other trusted forecasts, with a clear “last updated” time and uncertainty range. Never present a point estimate as certainty. Keep human approval for decisions involving safety, travel, or match scheduling.
Common mistakes to avoid
- Randomly shuffling time-series rows before splitting.
- Using future rainfall totals or revised observations as features.
- Claiming venue-level accuracy from a distant station without qualification.
- Reporting only R² and hiding performance during heavy rain.
- Filling all missing rainfall values with zero.
- Reusing a feature pipeline during inference without version control.
- Comparing models on different test periods.
FAQ
Can Random Forest predict whether it will rain?
Not directly as a regression target. Use a RandomForestClassifier for rain/no-rain probability, define a measurable threshold, and calibrate the probabilities.
Should the model use weather API forecasts?
It can, provided you store the forecast vintage and lead time. Combining recent observations with external forecasts may improve longer horizons, but it must be evaluated against an observation-only baseline.
How much historical data is needed?
Start with at least one complete year to capture seasonality; multiple years are preferable for rare heavy-rain events. More data does not compensate for inconsistent sensors or poor timestamps.
Is Random Forest the best model?
Not automatically. Compare it with persistence, gradient boosting, linear models, and official forecasts. Select the model that performs reliably on future Eden Gardens data and meets operational needs.
If you are building an India-focused forecasting product, AI Grants India may be relevant for support, partnerships, and funding pathways.