Apply for AI Grants India

Weather prediction for a cricket venue is a useful machine-learning exercise, but it needs a realistic target and reliable local data. At Green Park Stadium, Kanpur, a model may support pitch-cover readiness, match-day staffing, drainage planning, broadcast operations, and spectator advisories. It should complement—not replace—official forecasts and warnings from the India Meteorological Department (IMD).

K-nearest neighbors (KNN) is a suitable baseline because it is easy to explain: for a new observation, it finds historically similar observations and uses their outcomes to make a prediction. Its weakness is equally important: KNN can produce misleading results when features are poorly scaled, timestamps are mishandled, or the training data does not represent Kanpur’s seasonal weather.

Define the prediction target first

Do not begin with the algorithm. Decide what the stadium operator needs to know and how far ahead the answer must be available.

Useful targets include:

• Rain classification: Will measurable rain occur at the venue in the next 1, 3, or 6 hours?
• Rain probability: Estimate the likelihood of rain during a defined match window.
• Temperature regression: Predict temperature for the next hour or next observation interval.
• Humidity or wind prediction: Forecast variables relevant to player comfort, covers, and broadcast equipment.
• Operational risk category: Classify conditions as normal, caution, or intervention required.

For a first project, use a binary target such as rain_next_3h. Define the label precisely—for example, rainfall above 0.1 mm in the following three hours. A precise time horizon prevents the model from mixing immediate nowcasting with longer-range forecasting.

Collect data for Green Park Stadium

KNN can only be as useful as the historical examples it searches. Build a time-stamped dataset for the stadium or the nearest defensible observation point. Possible inputs include IMD observations, approved weather APIs, airport or nearby station records, radar-derived rainfall, and a low-cost on-site weather station.

Record at least:

• Timestamp in Indian Standard Time (IST)
• Temperature, relative humidity, pressure, wind speed, and wind direction
• Rainfall amount and whether rain was observed
• Cloud cover, visibility, and solar radiation where available
• Forecast values available at the time the prediction would have been made
• Month, hour, and a monsoon-season indicator

Station data can differ from conditions inside the stadium because of distance, urban surfaces, and sensor exposure. Keep the source identifier and distance from the venue in the dataset. If you install a sensor, document its height, calibration, maintenance, and missing-data periods.

If your wider project involves operational forecasting, review how implementing scalable ML pipelines for predictive analytics handles data ingestion, monitoring, and repeatable model runs. The same engineering discipline matters even for a small stadium prototype.

Engineer features without leaking the future

Create features only from information available at prediction time. For a prediction issued at 2:00 p.m., you must not use rainfall recorded at 2:30 p.m. or a daily total calculated after the event.

Useful features include:

• Current and lagged temperature, humidity, pressure, wind, and rainfall
• Rolling rainfall totals over the previous 1, 3, and 6 hours
• Change in pressure and humidity over recent intervals
• Wind direction encoded as sine and cosine rather than a raw compass label
• Cyclical hour and month features using sine and cosine
• Forecast precipitation probability, if available at issue time
• Recent radar or satellite indicators, when their timestamps are known

Handle missing values with a documented method, such as forward-filling only within a limited time window or adding a missingness flag. Never use random imputation that quietly draws information from the future. For a practical overview of monitoring predictive systems after deployment, see building predictive maintenance systems with AI; although the application differs, drift and alerting principles transfer well.

Prepare and train the KNN model

KNN is distance-based, so scaling is mandatory when one feature is measured in pascals and another in millimetres. Use a pipeline so the scaler is fitted only on training data.

import pandas as pd
from sklearn.model_selection import TimeSeriesSplit, GridSearchCV
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.neighbors import KNeighborsClassifier
from sklearn.metrics import classification_report, average_precision_score

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

features = [
    "temperature", "humidity", "pressure", "wind_speed",
    "rain_last_1h", "rain_last_3h", "pressure_change_3h"
]
X = weather[features]
y = weather["rain_next_3h"]

split = int(len(weather) * 0.8)
X_train, X_test = X.iloc[:split], X.iloc[split:]
y_train, y_test = y.iloc[:split], y.iloc[split:]

pipe = Pipeline([
    ("scale", StandardScaler()),
    ("knn", KNeighborsClassifier(weights="distance"))
])

search = GridSearchCV(
    pipe,
    {"knn__n_neighbors": [5, 11, 21, 31, 51]},
    cv=TimeSeriesSplit(n_splits=5),
    scoring="average_precision"
)
search.fit(X_train, y_train)

probability = search.predict_proba(X_test)[:, 1]
prediction = probability >= 0.35
print(search.best_params_)
print(classification_report(y_test, prediction))
print("Average precision:", average_precision_score(y_test, probability))

Use a chronological split rather than a random 80/20 split. Random splitting can place nearly identical observations from the same rain event in both training and test sets, producing an inflated score. Time-based cross-validation is a better approximation of deployment.

Choose K and evaluate for operations

A small K reacts quickly but can be noisy; a large K is smoother but may miss short, intense showers. Test several values and compare them using chronological validation. Distance weighting often helps because the most similar observations receive greater influence.

Accuracy alone is a poor metric when rain is uncommon. Report:

• Precision: How often a rain alert was correct
• Recall: How many rain events the model detected
• F1 score: A balance between precision and recall
• PR-AUC or average precision: More informative for imbalanced rain labels
• Brier score and calibration: Whether predicted probabilities are trustworthy
• Lead-time performance: Results separately for 1-, 3-, and 6-hour horizons

Choose the alert threshold with the stadium’s costs in mind. A false alarm may mean unnecessary cover deployment, while a missed heavy shower can disrupt play and damage equipment. Evaluate performance separately for pre-monsoon storms, the southwest monsoon, winter, and extreme-heat periods. Kanpur’s seasonal structure means one overall score can conceal important failures.

Where KNN fits—and where it does not

KNN is valuable as a transparent benchmark and may work well with a modest, clean local dataset. It is less attractive when the data grows large, observations become high-dimensional, or predictions must be served with very low latency. Compare it with a persistence baseline, IMD or API forecasts, logistic regression, and tree-based models before calling it useful.

For a more advanced regional system, combine station data with radar or satellite inputs and test models that capture temporal structure. A related example is Bhubaneswar weather prediction with Hugging Face models, which illustrates how a weather workflow can move beyond a basic tabular baseline.

Deploy responsibly at the stadium

A production workflow should store every prediction, its issue time, input values, model version, and eventual observed outcome. Monitor missing sensors, unusual feature ranges, calibration, and seasonal drift. Retrain only through a documented process, and preserve a rollback model.

Create a simple operational output: probability of rain, forecast horizon, confidence or calibration status, last data update, and recommended action. Escalate severe-weather decisions to authorised staff and official warnings. Do not present a KNN estimate as a safety guarantee.

Key takeaways

• Define a measurable target and forecast horizon before selecting KNN.
• Use local, time-stamped observations and prevent future-data leakage.
• Scale numeric features inside a training pipeline.
• Validate chronologically and report recall, precision, calibration, and lead-time results.
• Compare KNN with official forecasts and simpler baselines.
• Log predictions and monitor the model after deployment.

KNN can provide a credible, explainable starting point for Green Park Stadium, but its value comes from disciplined data design and operational evaluation—not from the algorithm alone.