## 3 The Bike-Share Case
### Evaluation--Formulation of Simulation and ML Models
#### 3.4.1 Demand Forecasting  
Demand De-Censoring  
A crucial step in preparing the historical rental and return data for forecasting is removing outliers or de-censoring demands. Outlier correction aims to eliminate the impact of extraordinary circumstances [53], providing a solid base for forecasting [54]. Unusual events disrupt the stationarity assumption, which is essential for reliable forecasting, as it assumes historical patterns can be extrapolated to predict future demand. Outlier correction seeks to minimise these disruptions. For bike-share data, we detect and correct two types of outliers. The first occurs when the provider cannot meet rental or return demand due to insufficient bike or dock inventory, _censoring_ legitimate demand and incorrectly assuming the supply issue will continue. The second type arises from inventory balancing actions, such as bulk returns or rentals, which deviate _demands_ significantly from the average. Below, we outline the data preprocessing and cleansing steps used to create an outlier-corrected rentals and returns file. **Data preprocessing. ** Citi Bike's trip data contain transactional information used to determine bike-share rental and return demand. The key fields are location details and ride start and end times. We used Tableau Prep Builder ([[https://help.tableau.com/current/prep/en-us/prep_about.htm](https://help.tableau.com/current/prep/en-us/prep_about.htm)]([https://help.tableau.com/current/prep/en-us/prep_about.htm](https://help.tableau.com/current/prep/en-us/prep_about.htm)) (accessed on 10 October 2024)) to transform the source data into the desired format for demand forecasting. We applied a filter to the station fields (start or end) to focus the data on the nine stations selected for the case study's demand cluster. We split each day into ten-minute intervals and assigned ride start and end times to their respective slots. This aggregation reduces granularity, minimises demand variability, and improves forecast accuracy. Based on a preliminary analysis showing an average trip duration of 11 to 13 min, we selected ten-minute intervals to ensure we capture short trips to and from the same station. We then split rentals and returns into two streams for individual forecasting. For the incentives data from Citi Bike's Bike Angel program, we developed a Python script to run every ten minutes and pull real-time data. Using the fields \"name\", \"last_reported\", and \"bike_angels_action\", we determined the timing of incentives at the selected stations. Figure 6 illustrates the data pipeline, from demand and incentive data to the two critical prediction types for inventory management. With the _Raw Demands_ and _Incentives Data_ in place, we split the demands into _Incentivised Demands_ and _Uincinentivised Demands_ (or _Base Demands_). **Unincentivised or Base Demands. ** If a demand period at a ten-minute time slot for individual stations has no incentive, the base demand equals the raw demand. If an incentive is applied, the base demand is the average demand for that timeslot at the station and filtered for periods without incentives during that month. **Incentivised Demands. ** If a demand period is under incentive, the incentivised demand equals the raw demand. Otherwise, it equals the average demand for that timeslot at the station/month, filtered for periods with incentives. **Outlier correction. ** A demand is considered an outlier if it exceeds the Upper Threshold Limit (UTL) or falls below the Lower Threshold Limit (LTL). For Base Demands, outliers are those below the 10 th percentile or above the 95 th percentile. For Promoted Demands, the LTL is the 25 th percentile, and the UTL is the 99 th percentile. Any detected outliers are corrected to the average value for the same timeslot and station, excluding outliers from the calculation.