Time Series Resampling in pandas

Imagine a bike rental station on the street outside your home. Before you leave in the morning, you would like to know whether a bike will be available when you need one. This is the situation behind the case study in this article. Citi Bike operates a network of rental stations across New York and uses a subscription system. Its rental data is made public in an anonymized form, and people have analyzed it in many ways.

The question is simple to state: given a day and a time, how many people will rent a bike from a station in front of the house? If the answer is high, the person living there may find that no bikes are left when they need one. The source describes this kind of problem as closer to common sense than to specialized expertise, which is why it makes a good first forecasting exercise. The tool that does the work is a pipeline of pandas operations, and you will follow one station through it.

The pipeline has three main moves. You load one station's data into a table, reshape it into a coarser time series, and then split it into a training period and a test period. At each move the data looks different, so the article traces what the data looks like after every step. Keeping track of that shape is the habit that will later help you find a surprising result.

The first step loads the data for August 2015 for one particular station as a pandas DataFrame. The source performs this loading with a helper from the mglearn package. The line that does it is a single assignment: the result of the function call is stored in a variable named citibike. Nothing else happens in that line, so the variable is the starting point for every later step.

Inspection comes next, and the most useful inspection is to read the output of each step rather than to trust it. In this case study the resampled series is printed, and the printout shows the first five timestamps, all on August 1, 2015. Each timestamp is paired with a number, which is the value stored for that three-hour window. The printout also names the series, which is one, and reports its dtype as float64.

Resampling changes how often the data has a value. The source resamples the station's data into three-hour intervals so that the main trends for each day become visible. A series with one value per hour would have 24 values per day, and it would show more noise from hour to hour. The three-hour version compresses each day into a small number of points, so the daily shape is easier to read.

The arithmetic is direct. Each day has 24 hours, and each three-hour window covers 3 of them, so each day contains $\frac{24}{3} = 8$ three-hour values. Those 8 values are the points the rest of the case study works with. The source states this count explicitly, and it is the number that makes the later split calculations come out cleanly.

The diagram above is a generated illustration rather than a figure from the source. It assumes that each day's windows start at midnight, which is one common way to group hours. Under that assumption, the 24 hourly positions collapse into 8 windows, and each window carries one value that summarizes the three hours it covers. The source does not spell out how that summary is computed, so the article keeps to the count of values and the meaning of each window.

After loading and resampling, the source plots the rental frequencies for the whole month. The plot shows the number of bike rentals over time for the selected station. Its purpose is pattern recognition. A single printed row cannot show whether a day is busy or quiet, but a plot across thirty-one days can.

When you read a plot like this, look for repetition. Ask whether the three-hour pattern seems to recur from one day to the next, and whether certain times of day tend to have higher counts. Those repeating shapes are the main trends that the resampling step was designed to expose. The prediction task depends on whether such trends are stable enough to learn from, so the plot is a check on whether the rest of the pipeline is worth trusting.

When a result differs from what you expected, the useful question is where in the pipeline the difference first appears. The steps in this case study are loading, resampling, plotting, and splitting, with the model consuming the split at the end. Checking each intermediate output in turn usually locates the problem faster than inspecting the final model. If you only look at the final accuracy, you cannot tell whether the error came from the data, the resampling, or the split.

Start at the top of the pipeline. The Freq line in the resampled output shows the sampling frequency, and it is the first thing to check if a result looks wrong. Then compare the first timestamps and values with what you expect for the station, confirm that the plot shows the pattern you would predict, and verify the split counts. Each check narrows the search, so the stage that first disagrees is the one to investigate.

The case study moves one station's rental history through three steps: load, reshape, and split. Resampling into three-hour intervals turns 24 hourly values per day into 8 values per day, which makes each day's trends easier to read. The split is made by time, with 184 points (23 days) for training and 64 points (8 days) for testing, and the boundaries follow from the 8-values-per-day count. When something looks wrong, check each stage in order, starting with the sampling frequency in the Freq line.