POI recommender systems for location-based social network services, such as Foursquare or Yelp, have gained tremendous popularity in the past few years. Much work has been dedicated into improving recommendation services in such systems by integrating di↵erent features that are assumed to have an impact on people's preferences for POIs, such as time and geolocation. Yet, little attention has been paid to the impact of weather on the users' final decision to visit a recommended POI. In this paper we contribute to this area of research by presenting the first results of a study that aims to recommend POIs based on weather data. To this end, we extend the state-of-the-art Rank-GeoFM POI recommender algorithm with additional weather-related features, such as temperature, cloud cover, humidity and precipitation intensity. We show that using weather data not only significantly increases the recommendation accuracy in comparison to the original algorithm, but also outperforms its time-based variant. Furthermore, we present the magnitude of impact of each feature on the recommendation quality, showing the need to study the weather context in more detail in the light of POI recommendation systems.
Location-based social networks (LBSN) enable users to check-in and share places and relevant content, such as photos, tips and comments that help other users in exploring novel and interesting places in which they might not have been before. Foursquare1, for example, is a popular LBSN with millions of subscribers doing millions of check-ins everyday all over the world2. This vast amount of check-in data, publicly available through Foursquare’s data access APIs, has inspired many researchers to investigate human mobility patterns and behaviors with the aim of assisting users by means of personalized POI (point of interest) recommendation services [15, 16].
Problem Statement. The problem we address in this paper is the POI recommendation problem. Hence, given a user u and their check-in history Lu, i.e., the POIs that they have visited in the past, and current weather conditions C = {c1, . . . , c|C|}, where ci are weather features such as temperature, wind speed, pressure, etc., we want to recommend the POIs Lˆu = {l1, . . . , l|L|} that they will likely visit in the future that are not in Lu.
Objective. Most of the existing approaches on POI recommendation exploit three main factors (aka contexts) of the data, namely, social, time and geolocation [5, 10, 15]. While these approaches work reasonably well, little attention has been paid to weather, a factor that may potentially have a major impact on users’ decisions about visiting a POI or not. For example, if it is raining in a certain place in a certain period of time, the user may prefer to check-in indoor POIs.
In this paper we contribute to this area of research by presenting the first results of a recently started project that exploits weather data to recommend, for a given user within a given city, the POIs that they will likely visit in the future. To this end, we extract several weather features based on data collected from forecast.io such as temperature, cloud cover, humidity or precipitation intensity, and feed it into a state-of-the-art POI recommender algorithm called RankGeoFM [10]. The reason why we decided to build our approach on top of this algorithm is twofold: (i) Rank-GeoFM has shown to outperform other strong baselines from the literature and (ii) it is very easy to extend it with additional contextual data.
Research Questions. To drive our research the following three research questions were defined: • RQ1. Do weather conditions have a relation with the check-in behavior of Foursquare users? • RQ2. Is it possible to improve current POI recommendation quality using these weather features? • RQ3. Which weather features provide the highest impact on the recommendations? 2https://foursquare.com/infographics/10million
Contributions. To the best of our knowledge, this is the first paper that investigates in detail the extent to which weather features such as temperature, cloud cover, humidity or precipitation intensity impact on users’ check-in behaviors and how these features perform in the context of POI recommender systems. Although there is literature showing that POI recommender systems can be improved by using some kind of weather context such as e.g. temperature, it is not clear yet, how much they add or what type of weather feature is the most/least useful one. Another contribution of this paper is the introduction of a weather-aware recommender method that builds upon a very strong state-ofthe-art POI recommender system called Rank-GeoFM. The method is implemented and embedded into the very popular recommender framework MyMediaLite [7] and can be downloaded for free from our GitHub repository (details in Section 8).
Outline. The structure of this paper is as follows: In Section 2 we highlight relevant related work in this field. Section 3 describes how we enriched Rank-GeoFM with weather data. Section 4 describes the experimental setup and presents results from our empirical analysis. Section 5 presents insights on the results obtained with our weather-aware recommender approach. Finally, Sections 6 and 7 conclude the paper with a summary of our main findings and future directions of the work.
With the advent of LBSNs, POI recommendation rapidly became an active area of research within the recommender systems, machine learning and Geographic Information Systems research communities [2]. Most of the existing research works in this area exploit some sort of combination between some (or all) of the following data sources: check-in history, social relations (e.g. friendship relations), time and geolocations [1, 5, 6, 8, 10, 13, 15]. While these die↵rent sources of data (aka contexts) a↵ect the user’s decision on visiting a POI in di↵erent ways, weather data, which according to common sense may have a great influence on this decision, are still rarely used.
Martin et al. [11] proposed a mobile application which architecture considered the use of weather data to personalize a geocoding mobile service, but no implementation or evaluation was presented. A similar contribution was done by Meehan et al. [12], who proposed a hybrid recommender system based on time, weather and media sentiment when introducing the VISIT mobile tourism recommender, but they neither implemented nor evaluated it.
Among the few works that have actually used weather in the recommendation pipeline, Braunhofer et al. [3] introduced a recommender system designed to run in mobile applications for recommending touristic POIs in Italy. The authors conducted an online study with 54 users and found out that recommendations that take into consideration weather information were indeed able to increase the user satisfaction. Compared to this work, our implementation is based Sym.
U L F Cf F ⇥ Xul Xulc D1 D2 W W I Nk(l) yul yulc I(·) ✏ w g E(·) ucll0 b |Ln| c g, µ
Description
set of users u1, u2, ..., u|U|
set of POIs l1, l2, ..., l|L|
set of classes for feature f
set of weather feature classes f1, f2, ..., f|F Cf |
latent model parameters containing the learned weights
{L(
In summary, compared to previous works which have used weather as a contextual factor for recommendation systems, we provide detailed information about the recommendation algorithm and we contribute an implementation extending a state-of-the-art matrix factorization model exploiting rich weather data. Moreover, we also provide details on how the weather features were exploited by it, as well as a detailed analysis about the impact of the features on the recommendation performance.
Our recommendation approach is built upon a
state-ofthe-art POI recommender algorithm named Rank-GeoFM
[10], a personalized ranking based matrix factorization method.
fc(
ll(
Pc+2 F Cf wicc+ fc(+1)⌘ transforming continuous values of weather features (e.g., temperature) into intervals might alleviate this problem. Hence, a mapping function is introduced (see Equation 1) that converts the weather features into interval bins. |F Cf | defines the number of bins for the current weather feature. We will refer to these bins as feature classes. The best results were obtained with |F Cf | = 20 (validated on hold-out data).
cf (value) =
(value min(f )) · (|F Cf |
(max(f ) min(f ))
1) ⌫
(
To extend the original Rank-GeoFM approach with weather
context, three additional latent factors are introduced that
are represented by matrices in a K-dimensional space. The
first one is for incorporating the weather-popularity-score
that models whether or not a location is popular with
respect to a specific weather feature class and is named L(
P
u2 U u2 U
Pl2 L x2ulc
Pl2 L xulcxulc0 qP
P u2 U l2 L x2ulc0 Algorithm 1: Rank-GeoFM with weather context Input: check-in data D1, D2, geographical influence matrix W , weather influence matrix W I, hyperparameters ✏, C, ↵ , and learning rate g and w Output: parameters of the model
⇥ = {L(
Compute yulc as Equation 3 and set n = 0 repeat
Sample l0 and c0, Compute yul0c0 as Equation 3 n++ until I(xulc > xul0c0 )I(yulc < yul0c0 + ✏) = 1 or n > |L| if I(xulc > xul0c0 )I(yulc < yul0c0 + ✏) = 1 then ⌘ = E ⇣j |Ln| k⌘
ucll0
end
Project updated factors to accomplish
constraints
21 end
22 until convergence
23 return ⇥ = {L(
Table 2 describes the symbols used in the recommender algorithm. For each type of contextual data considered, latent model parameters are introduced. The prediction score of a <user, POI, context> triple is then made based on this learned latent parameters. The parameters are trained using a fast learning scheme introduced by the authors that is based on Stochastic Gradient Descent (SGD).
To add the weather context into Rank-GeoFM, the weather
features’ values needed to be discretized. This was done to
reduce data sparsity. For example, if we considered
temperature as a real number, most of the check-ins concerning
specific temperature values would probably be zero. Thus,
To calculate the recommendation score for a given user u,
POI l and weather feature class c, Equation 3 is introduced,
where yul denotes the recommendation score as computed
in Li et al. [10].
(
X l⇤ 2 Nk(l)
wll⇤ ll(⇤1)
yulc = yul + fc(
X
wicc⇤ fc(⇤1) c⇤ 2 F C
Algorithm 1 describes how we incorporated the weather context features into the base Rank-GeoFM approach. Taking the initialization and the hyperparameters from the original approach, we first iterate over all pairs of users and POIs (u, l) 2 D1, where D1 is the set of all check-ins and do the adjustments of the latent parameters as described in Li et al. [10].
We then introduce an iteration over all <user, venue, feature-class> triples (u, l, c) 2 D2 in order to adjust the latent parameters on the incorrect ranked venues according to the specific weather context. This adjustment is necessary because the algorithm might rank a triple (u, l, c) correctly where on the other hand (u, l, c0) might be ranked incorrectly. The adjustments are then done accordingly to the base algorithm in lines 6-20.
During our studies we found that with a learning rate
of g = .0001, as used in Li et al. [10], the algorithm did
not converge. The reason for that is that the adjustments
are done on a higher granularity for each (u, l, c) triple and
not just on the (u, l) level. Henceforth, we introduce a new
learning rate parameter w = .00001 for the weather
context, for which stable results could be observed (validation
on hold-out data). Similarly to Li et al. [10], we found in
our experiments that the best values of the hyperparameters
are as follows (validated on hold-out data): ✏ = .3, C = 1.0,
↵ = = .2, and K = 100 as used for the dimensions of the
matrices L(
In this section we describe in detail our experimental setup, i.e., the datasets we used, a brief characterization of these datasets concerning the weather features used, and the evaluation protocol we have chosen to conduct our study. 4.1
The dataset we used in this study was obtained from the work of Yang et al. [14]. It is a Foursquare crawl comprising user check-in data from April 2012 to September 2013. The original dataset contains more than 33 million check-ins from 415 cities in 77 countries. However, before dealing with our problem on such a large scale, we decided to first concentrate our investigation on a small set of US cities. We selected four cities that could represent some weather variety in order to investigate whether our model is robust to such variety of weather conditions (see Figure 3). Table 1 provides an overview of the check-in statistics of the four target cities chosen for our experiments: Minneapolis, Boston, Miami and Honolulu.
Concerning the weather information, we have used the API of forecast.io3 to collect, for each <time, place> tuple present in our dataset, their corresponding weather information. For that, we need to pass the following request to the API: https://api.forecast.io/forecast/APIKEY/LAT,LON,TIME For the purposes of our analysis, we obtained eight weather features, namely, cloud cover, visibility, moon phase, precipitation intensity, pressure, temperature, humidity and wind speed, for all places and time-stamps in our dataset that are provided by forecast.io. 4.2
Figure 1 shows the probability distributions of check-ins for each of the eight weather features used. Notice that the distributions of pressure, temperature, humidity and wind speed resemble a normal distribution (see the colored approximation curve). Moreover, while moon phase seems to follow a uniform distribution, which indicates that it will likely not help the recommendation model, the distribution of precipitation is very skewed, showing that users have a strong preference to check-in places when there is low precipitation intensity (i.e., not raining), indicating that this feature might have a good discriminative power.
3https://developer.forecast.io/docs/v2 (c) Moonphase
(d) Precipitation intensity (e) Pressure
(f) Temperature (g) Humidity (h) Windspeed Figure 3: Weather feature variability (sorted) measured via standard deviation over cities. Left: cities with lowest variability. Right: cities with highest variability.
In addition to this, Figure 2 illustrates the check-in distribution as a function of temperature in four di↵erent POI categories. As highlighted in this figure, di↵erent patterns occur depending on the category chosen. While people prefer to check-in in e.g., “Austrian Restaurants” or “Ski Areas” when the temperature is low, “Ice Cream Shops” or “Farms” are preferred when temperatures are higher.
Figure 3 shows how the weather features vary in each city of the original Foursquare dataset. Notice that with the exception of moon phase, all the features present a dependency regarding the city where they are measured, indicating that a die↵rent recommendation model should probably be trained for each di↵erent city. Moreover, in general, weather shows a higher variability in the north of the US and a very low variability in the south that peaks in the island Honolulu which shows almost no variability in terms of weather. Figure 4 shows the di↵erent mean values of the eight weather features over the POI categories. With the small overlapping of the standard error of the means it’s revealed that indeed categories have a distinct popularity across various weather feature values. Even moon phase shows a divergent category popularity at its tails.
After this analysis we can confidently state that there is indeed a relation between the weather conditions and the check-in behavior of Foursquare users, which answers our first research question (RQ1) stated at Section 1. 4.3
Protocol. To evaluate the performance of our algorithm, we have chosen the same evaluation protocol as described in the original Rank-GeoFM paper [10]. Hence, we split the dataset (according to the time line) into training, validation and test sets for each city by adding the first 70% of the check-ins of each user to the training set, the following 20% to the test set and the rest to the validation set (=10%). The training set was then used to learn the latent model parameters. During the training phase of the algorithm, the validation set was used to tune the algorithm convergence. When convergence was observed (typically around 3,000 – 5,000 iterations with fast learning scheme enabled), the training was stopped and the learned parameters were used to evaluate the model on the test set.
Baselines. As baselines for our experiments, we used the original Rank-GeoFM approach, that takes into account both the check-in history of users and geographical influence. We also compare to the time-based method of Rank-GeoFM, that was also introduced in Li et al. [10].
Metric. As evaluation metric NDCG@k (Normalized Discounted Cumulative Gain) with k = 204 was chosen, as we want to predict the top-k POIs for a user. 5.
Figure 5 shows the results of our o✏ine experiment. As shown, in all cases Rank-GeoFM enriched with our proposed weather features significantly outperforms the original Rank-GeoFM algorithm, which answers RQ2. For all pairwise-comparisons (recommenders with weather context vs. without) a standard t-test showed that the p-values were always smaller than p < .001. What is even more interesting to note is the performance of Rank-GeoFM that utilizes the time feature as contextual factor. As highlighted, in all cases, Rank-GeoFM with weather features, such as visibility and precipitation intensity outperforms the time-based variant, showing that indeed weather conditions may help to improve the recommendation quality.
We also highlight the fact that certain weather features perform better than others and this ranking seems to be city dependent. This can be clearly observed in Figure 5, where the results of Rank-GeoFM with each weather feature is shown. This answers RQ3, showing which features provide the highest gain in recommendation quality. For example, in Honolulu the best performing feature is precipitation intensity, while in Minneapolis visibility seems to work best among all investigated weather features. Similar patterns can be observed for other features, such as temperature or cloud cover, changing their relative importance across the four cities. These observations are in line with the results in Figure 1, showing a strong tendency of check-ins into POIs under certain weather conditions. However, what is also interesting to note is the good performance of the moon phase feature, which appeared to be uniformly distributed in gen4Please note, that we have also run simulations with k = 5 or 10, with similar trends in the results as obtained with k = 20. However, due to limited space, they were not included into this paper. (a) Minneapolis (b) Boston eral (cf. Figure 1). Hence, it appears, that at the level of locations there is indeed a strong preference for check-ins in di↵erent phases of the moon. In a recent research, Kohyama et a. [9] found a relation between moon phase, tidal variation, humidity and rainfall. Notably, we found a positive relation by analyzing these data based on check-ins, finding a small but positive correlation between moon phase and precipitation intensity, humidity, cloud cover and pressure, as seen in the last row of the correlation matrix shown in Figure 6. Although further analysis should be performed to establish a link between our study and theirs, this might be a possible explanation regarding the e↵ect of moon phase in our POI recommendation model.
Finally, the relative performance improvement over the original Rank-GeoFM also seems to be location dependent. Hence, while our approach work to a great extent better compared to the baseline for Miami and Honolulu, the differences are less pronounced for Minneapolis. One reason for this observation could be that there are more POIs available showing similar weather profiles. However, to further confirm these hypotheses, additional analyses are needed.
In this paper we presented our preliminary findings on how weather data may ae↵ct users’ check-in behavior and how this information can be used in the context of a POI recommender system. As our preliminary analyses on the Foursquare check-in data showed, the weather factors have indeed a significant impact on the people’s check-in behavior, showing die↵rent check-in profiles for di↵erent kinds of places (which answers RQ1). Furthermore, we use the proposed weather features within a state-of-the-art POI recommender and we were able to increase the recommender accuracy in comparison to the original method that does not use weather data (thus answering RQ2). Furthermore, our experiments revealed that the weather context is more useful than the context of time and, that the weather features used in this work are city-dependent. Finally, our study showed (see RQ3) that among the considered weather features, precipitation intensity and visibility are the most significant ones to improve the ranking in a weather-aware POI recommender system.
Currently, our work only investigates one weather feature at a time. Investigating di↵erent hybridization or contextaware recommender system (CARS) methods and other context variables will be therefore a task to be conducted in our future work. Furthermore, it will help to investigate in more detail, how the algorithm performs on the whole Foursquare dataset, as more interesting patterns across cities may occur. Finally, we would like to extend our investigations also at user levels, since the current ones concentrate only on the weather profiles of the POIs.
In order to make the results obtained in this work reproducible, we share code and data of this study. The proposed method Rank-GeoFM with weather context is implemented with the help of the MyMediaLite framework [7] and can be downloaded for free from our GitHub repository5. Furthermore, the data samples used in the experiments can be requested for free via email to the corresponding author.
This work is supported by the Know-Center. The KnowCenter is funded within the Austrian COMET Program managed by the Austrian Research Promotion Agency (FFG). The authors Denis Parra and Leandro Marinho were supported by CONICYT, project FONDECYT 11150783 and EU-BR BigSea project (MCTI/RNP 3rd Coordinated Call) respectively.