Code › ai-engineering-study
EDA Before Modeling Bike Sharing Demand
A Codeit mission on reading feature context, outliers, and model behavior in Kaggle's Bike Sharing Demand data
This was the third Codeit mission, based on the Kaggle Bike Sharing Demand dataset. The task covered EDA, preprocessing, model training, and a final report for predicting bicycle rental demand. I inspected the data and compared several models, but the instructor’s solution produced a wider range of checks and stronger insights before training.
I moved quickly toward improving predictive performance. The instructor spent more time verifying what each feature represented before deciding whether to use or remove it.
My Initial Approach
I extracted year, month, day, hour, and weekday from the timestamp, then used hour, temperature, apparent temperature, humidity, wind speed, and working-day status as input features. Rental count was the target. Splitting the hourly distribution by working-day status revealed two commute peaks on weekdays and a broader daytime peak on weekends. The same hour represented different demand patterns depending on how people were likely using the bicycles.
Rentals rose with temperature and apparent temperature, while high humidity and poor weather coincided with lower demand. I did not stop at the overall correlations. I replotted some variables after separating weekdays from weekends because demand depends on combinations of hour, working-day status, season, and weather rather than one feature in isolation.
I one-hot encoded the categorical features and applied log1p to the right-skewed rental counts. RMSLE was already specified as the evaluation metric, and I later confirmed that it was the metric required by the Kaggle competition. Some wind-speed values looked suspicious, so I tested the assumption that zeros might represent missing measurements rather than genuinely windless conditions and replaced them with the median.
Linear regression and the regularized Ridge and Lasso models produced similar results. My linear model reached an RMSLE of about 0.5814. I should have returned to the data to investigate why the score was high, but instead I first looked for other models. I tried Random Forest and XGBoost, neither of which had been covered in class yet, and XGBoost reached about 0.31. One possible explanation was that a single linear relationship could not capture the combined effects of hour, working-day status, and weather, while XGBoost could split the data by those conditions. The result was tempting, but the actual point of the exercise was to improve the linear regression approach we had studied.
One plot showed a sudden rise in mean rentals in the 50 m/s wind-speed range. The interpretation did not make sense, so I filtered the underlying rows. That range contained only four records, including one row with roughly 300 rentals. A wind speed of 50 m/s is about 180 km/h, severe enough that bicycle rentals at that level were difficult to accept as ordinary observations. I therefore decided to handle those values separately.
The analysis also needed to lead to possible business actions. Bicycles could be rebalanced near stations and residential areas before weekday commute periods, while availability around parks and rivers could be increased during weekend afternoons. Rainy or humid days with lower expected demand could be used to secure maintenance time and improve operational efficiency.
The Instructor’s Mission Walkthrough
The instructor went deeper into preprocessing and EDA before building a model. Weekday and weekend usage patterns were separated first, box plots were used to inspect humidity and wind-speed outliers, and the distributions were compared before and after filtering. Outliers were not removed immediately. Their context was checked first to distinguish incorrect measurements from rare but valid observations.
The season feature was not accepted solely by its label either. The earliest and latest dates in each category showed ranges that were difficult to group into a single season, so the seasons were redefined from the actual date boundaries. A category already present in the dataset does not guarantee that its meaning is accurate. The data still needs to be checked directly.
The solution then compared rental demand around season changes, weather changes, and combinations of favorable climate conditions. Those transition analyses came from the instructor’s solution, not my initial approach. They exposed changes that would disappear inside an overall average by looking again at the points where conditions changed.
The modeling stage followed a different order as well. After defining the input features and rental target, the instructor one-hot encoded the categorical variables and implemented RMSLE directly so that every model used the same evaluation rule. Features with weak correlations were removed to reduce unnecessary work during training, and the decisions made during EDA were carried through to model evaluation.
Conclusion and Reflection
I moved quickly from feature inspection to comparing linear and tree-based models, then examined the data further when the wind-speed plot produced a suspicious result, while the instructor worked through feature distributions, outliers, date ranges for categories, and condition transitions before training, resolving one question at a time.
I did not ask enough follow-up questions after drawing each chart: which conditions should be separated for another comparison, which source rows should be checked when a result looked unusual, and whether removing a feature actually changed performance. In the next EDA task, I will inspect sample counts, conditional distributions, and feature definitions before treating a correlation value or model score as the conclusion.