We’re in an unprecedented era where humans are living longer and longer (although 2015 & 2016 were a scary blip in the otherwise upward trend). It’s no secret, though, that life expectancy varies widely across the globe.

As a biomedical engineer, I’ve always attributed living longer with increased access to modern science and healthcare. To test this assumption and understand what actually best predicts life expectancy, I explored country-level data across a subset of the World Health Organizations’s 1,345 development indicators (from 1960- 2015).

I pared the data down to a subset of indicators that were not only reasonably related to life expectancy, but also representative of the main indicator categories (Economic Policy & Debt; Health; Infrastructure; Poverty; Private Sector & Trade; Public Sector; Social Protection & Labor).

Of these, the most statistically significant indicators of life expectancy was access to sanitation. Using sanitation alone to predict life expectancy had 77% accuracy and showed that a a one-year increase in life expectancy is associated with every 0.25% of the population with access to modern sanitation facilities.

“Up and to the right”

Pretty much no matter how the data is cut, life expectancy trends between 1960 and 2015 look like sales projections in a startup pitch deck: up and to the right.

Classifying countries based on income levels, we can see how economics impact health: a higher income is associated with a longer life expectancy, continuously between 1960 and 2015. High income countries see a steady, but slower, increase in life expectancy; middle income countries experienced large growth in the 1960s and saw a corresponding up-tick in life expectancy. In low income countries, life expectancy gains all but stopped between mid-80s — mid-90s, followed by a strong increase in life expectancy in recent years. Regional groupings (bottom graph) reveal which geographies drove the changes in the 1960 and 1980s.

I pared down the 1.3k development indicators to a representative subset of 21. Running a correlation on these metrics vs. life expectancy provides a quick assessment for relative importance.

Life expectancy has the highest positive correlation with: sanitation (r = 0.88), GDP per capita (r = 0.698), and health spend per capita (r = 0.63). There’s a strong negative correlation with: % of population in rural areas (r = -0.80) and adolescent fertility (r = -0.77).

Machine learning to predict life expectancy

To determine which indicators are statistically significant, and to predict life expectancy, I ran a few different models with various combinations of features. This application is a perfect use case for regression, which determines the relationship between one dependent variable (life expectancy) and a number of independent variables (development indicators).

Using the entire subset of 21 features was 89.7% accurate, and showed that sanitation and rural population (%) were both statistically significant.

Even with just these two variables, this model predicts life expectancy with 80.4% accuracy. On average life expectancy is 63 years with a one-year increase for every 0.18% increase in access to sanitation and 0.11% decrease in the percentage of population living in rural areas. Adding healthcare spend to the model only slightly increases accuracy (81%).

Probing into sanitation: To dig deeper into how sanitation specifically, I evaluated access to sanitation against statistics on child mortality rates. Not surprisingly, there’s a strong negative correlation between sanitation and mortality: as sanitation improves, mortality rates decrease for neonates, infants, and children under 5.

Sanitation as the key predictor of life expectancy — specifically child mortality — was unexpected, yet logical. Poor sanitation conditions increase the risk of sharing life-threatening contagions.

According to the World Health Organization, diarrheal disease, the leading cause of death for children under five, is spread by poor sanitation conditions:

‘Diarrhoea is a symptom of infections caused by a host of bacterial, viral and parasitic organisms, most of which are spread by faeces-contaminated water.’

Once sanitation has been improved in communities, initiatives could address other key indicators of life expectancy (e.g. education, health care, adolescent fertility). And, because sanitation is highly-correlated with childhood mortality, addressing on sanitation first should result in more children who would benefit from additional initiatives.

gussie/Springboard_data_science

What really drives higher life expectancy? was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

Bike share programs are cropping up in cities across the world, providing flexible transportation for professionals and tourists alike. Bike share systems are commonly built with “docking stations” where users can check out and return bikes. In 2013, San Francisco launched their bike share program which, as of 2015, had 70 stations throughout the city.

Bike share programs offer challenges for both the program owners (cities) and users (riders). For example, cities often manually redistribute bikes between stations to ensure availability of both bikes and docks (slots to return bikes). Cities also need to use rider data to inform where future bike stations should be installed. For users, the main questions is: If I leave home/work now, will there be a bike at the nearest station when I arrive? The uncertainty of bikes at a given station has strong business implications, as unpredictable bike supply can deter ridership and stagnate demand. This project focuses on user challenges of bike availability.

This project evaluates current ridership trends and predicted bike availability (within 30 minutes of a request) for the San Francisco bike share system. The three main sections of this project include: exploratory data analysis, a simple deterministic model, and two machine-learned models (1 with temporal & commute features, and 1 with the addition of weather data). Of all the features, the greatest predictor of future bike availability is current bikes at the station, followed by week, month, and commute hours. Of the weather features, cloud coverage was the strongest predictor — not a surprise if you’re familiar with San Francisco’s weather!

The machine learned model with advanced feature engineering out-performed the other two models model, with a false positive rate of 15% and a false negative rate of 0.01%.

Data overview

The following publicly available data were used (source):

• status: minute-by-minute update of the number of bikes and number of docks available for each of the 70 stations
• weather: zip-level daily weather patterns for the SF Bay Area
• station: metadata for each station (n = 70)
• trips: trip-level records, includes date, start/end time, start/end station ID, start/end station name, bike ID, rider subscription type, and trip duration

Exploratory data analysis

After grouping riders by subscription type (Subscriber: monthly or annual member, and Customer: casual pay-as-you-go rider), I explored seasonal, weekly, and daily ridership patterns. All timeframes highlight distinct patterns for Subscribers vs. Customers, supporting the hypothesis that Subscribers are commuters and Customers are largely tourists.

Customer ridership peaks in Aug/Sept/Oct and sees a lull around the winter holidays. This could be due to tourism trends or weather influencing whether casual commuters bike (Fall is notoriously San Francisco’s best season, and Winter — when we’re not in drought — is very wet).

Assumptions

Now that we’ve understood the rough trends of data and user behavior, the next step is to build a simple deterministic model for predicting bike availability. From a rider’s perspective, bike availability is a binary concern: Is a bike available? Yes or no. Thus, a binary classifier is appropriate. Note, from my experience, not all bikes in a bike share system are functional. Therefore, the classifier is adjusted slightly, and all models classify whether there are at least 2 bikes available at a station at a given time.

We can see in the plots above that different stations exhibit different patterns. Stations in residential areas, for example, see bikes decrease in the morning and increase in the evening. Conversely, stations near offices see the reverse trend. This justifies a simplifying assumption for our predictive models: we can build independent models for each station, thereby explicitly choosing to omit correlations between the behavior of different stations.

Data pipeline

All three models rely on preprocessing steps such as data filtering, harmonizing / simplifying data types, and feature engineering. To support faster processing and easier recovery from kernel crashes (raw status datafile is 2.5 GB), preprocessing is implemented Python scripts that persist output data. Together, these transformation stages constitute a data pipeline that feed into the models.

1. Converts human-readable timestamp into epoch milliseconds.
2. Generates a test dataset (for the simple model) where rows satisfy two conditions: (1) day of month is less than given max day of month (e.g. if max_day_of_month <5, returned test set contains the 5 days of each month, ~13%). (2) day of week equals the given day of week in ISO format(day_of_week = 3 since current deterministic model is calculated for Wednesday).

For both machine learned models (starting with the output from Step 1):

1. Adds two new columns (1-appropriate model time; 2-true bike availability for t+30 minutes) for each row in the dataset if the timestamp of the row is within 30-minutes of a specified model time (in array). Otherwise, it drops the row from the dataset.
2. Adds the following discretized datetime columns to the dataset: ISO day of week (1–7); ISO month (1–12); Commuter flags as 3 binary columns; non-commute hours (1/0); AM commute (1/0) — status update between 7 and 09:00; PM commute (1/0) — status update between 16 and 18:00.
3. Adds the true number of bikes at a station in t+30 mins.

Model building

Deterministic model

For comparison against the machine learning models we’ll ultimately build, let’s create a deterministic model to calculate a per-station change in bike availability over 30-minute intervals. The change in bike availability is approximated using least squares — which fits a curve that minimizes the sum of the squares of the difference between the dependent variable (bike availability) in the dataset and the value predicted by the linear function (time = x). To build the model, I use daily traffic patterns identified above to define appropriate model times. Based on high demand, the following 30-minute intervals were modeled: Morning (7:30, 8, 8:30, 9AM) & Evening (4, 4:30, 5, 5:30, 6PM). The least squares fit line is calculated for each station, and bike availability predicted as: current bike availability + (slope of least squares line x 30).

popt_all_stations = []
row_headers = []

for i in station_ids:
    s = station_availability(i, n_bikes= n_bikes, dow= dow)       
    popt_single = []
    for j in start_times:
        start_time = pd.to_datetime(j)
        end_time = start_time + delta
        df = s.between_time(start_time.time(), end_time.time())
        xdata = df.index.minute
        ydata = np.array(df.bikes_available)
        popt, pcov = optimization.curve_fit(func, xdata, ydata)
        popt_single.append(popt[1])
    popt_all_stations.append(popt_single)
    row_headers.append(i)
    
# reshape model ouput with time as column headers, station as index
df = pd.DataFrame(popt_all_stations)
df.columns = start_times
df.index = row_headers

# Convert model from minute-by-minute change in bike availabilty --> total change during 
# model window (e.g. the 16:00 model applies to status updates between 16:00 and 16:29)

model = df*29
model['station_id'] = model.index
model = pd.melt(model, id_vars = ['station_id'])
model.head()

I’ll evaluate all models together below.

Simple machine learned model

The first machine learning model uses simple features, engineered from the status timestamp: day of week, month, commute hours (non-commute, AM, or PM). The pre-processing is performed in the data pipeline — primarily because Jupyter notebook could not handle mapping future bike availability to each row in the status table. As mentioned, for riders the issue of bike availability is binary; riders do not care how many bikes are available, but rather that there is a bike. In this case, we’ll use a Random Forest Classifier, which will help use later tease apart the relative importance of our features.

The output is one model per station (70); the importance of each model’s features are summarized below. Using .describe(), we’re able to also glean insights into the variance of feature importance across stations. Across the board, current bike availability is the most predictive feature of future bike availability. To a lesser degree, the month and day of week are predictive. Commute times play little importance.

pd.DataFrame(feature_imp, columns=X_train.columns).describe()

Machine learned model 2: Advanced feature engineering

Now that we’ve seen a basic machine learning model, the next step is to add more sophisticated features with the hope of improving model performance. In particular, various aspects of weather (e.g. temperature, precipitation) are key determinants when commuters select their mode of transportation. In the next models we’ll pull in a host of daily weather features.

As with the first ML model, this model is station-specific. For a quick comparison, the weather-augmented model is created for a single station — station #2.

The feature importance method for random forest shows the relative importance for the features in the weather-augmented model (i.e. both the original ML model features, as well as the additional new weather features). We see that current bike availability is still far and beyond the best predictor of future bike availability. Day of week, AM commute, and non-commute hours are also decently important features from the original model. Of the newly-added weather features, cloud cover is the most important feature, followed by max dew point, min dew point, and max humidity. In a city with unpredictable weather and notorious cloud cover (I’m looking at you, Karl), it’s no surprise that cloud cover impacts bike ridership (and therefor bike availability).

*In case you’re not familiar with San Francisco, the daily fog is so intense and routine in summer, that it is fondly referred to as Karl.

So which one is “better”?

To answer this question, we must agree on how to appropriately evaluate the models. Accuracy, a common default evaluation metric, won’t fly here due to severe class imbalance (e.g. one class has a clear majority in the data). Only a small subset of the bike stations do not have sufficient bike availability during model times. In fact 96.6% of the stations have bikes available during the given time periods. Therefore, a classifier that predicted ALL stations have available bikes all the time would have 96% accuracy… but this would be a horrible classifier. A confusion matrix provides better metrics for assessment.

From a rider’s perspective one of the most important metrics is false positive rate: the ratio of false positives (number of negative events wrongly categorized as positive) and total number of actual negative events. In other words: If a model says a bike will be available in 30 minutes, will there actually be a bike when the users arrive?

For the most important metrics for users — false positive rate and false negative rate — both machine learned models outperforms the simple deterministic model. Specifically, the weather-augmented random forest model is far superior to the simple model in terms of false positive rate (one-third of the simple model’s FPR) and false negative rate (0.01% vs. 0.66% for the simple model).

Possible extensions

Beyond running additional machine learning classifiers (e.g. SVM, logistic regression) for comparison, this dataset holds rich potential for further feature engineering, including:

• Historical rate of change of bikes availability (e.g. slope of least-squares line as with simple model)
• Number of rides started / ended at the station in the previous x-minute window — providing insights into station popularity otherwise lost in the station status update (e.g. if 1 trip starts at Station A as another trip ends at Station A, the number of bikes available would be static)
• Trip start/end time popularity (e.g. use the first derivative to find local max & min number of trips)
• Mapping zip-level daily weather data with each station, rather than the Bay Area mean.

gussie/Springboard_data_science

To bike or not to bike? was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.