A web-based application for the display of geolocated Tweets on a map

seaurchininterpreterInternet και Εφαρμογές Web

7 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

116 εμφανίσεις

UNIVERSITY OF FRIBOURG
Pervasive & Artificial Intelligence Research Group
LTMap
A web-based application for the display
of geolocated Tweets on a map
MASTER THESIS
Aron Martinez
Student number:06-208-771
Address:Via Ravecchia 11b,CH-6512 Giubiasco
Email:aron.martinez@unifr.ch
Head:Prof.Beat Hirsbrunner
Supervisor:Apostolos Malatras
Giubiasco,March 24,2013
Swiss Joint Master of Science in Computer Science
Acknowledgements
Acknowledgements
First of all,I would like to thank Apostolos Malatras for his support,guidance and good
advice,and also for all the valuable feedback he provided me.
I would also like to thank Prof.Beat Hirsbrunner for giving me the chance to be part
of the PAI group for the duration of my master thesis.It has been a great pleasure to
collaborate with the PAI research group and to meet all its very kind members during
the project meetings and presentations.
Finally I want to thank my family and friends for their moral support,and last but
not least,I want to thank my wife Lucile for having always believed in me,and for her
invaluable support and her continuous encouragement during the writing of the thesis.
iii
Abstract
Abstract
Today,different services offer geolocated information based on social networks,but in
most cases this information is available only for some major cities around the world,for
only one social network at a time and without focusing on the actual personal interests
of the user.
The purpose of this master thesis is to create a web-based application that uses open-
source APIs to access localization services and social network information and displays
the retrieved information on a map,based on the user’s location.
One of the main focuses of the application is usability,therefore the display of infor-
mation needs to be user-friendly by using a clear and simple design on one hand,and
functions simplifying the display (like,for example automatic localization of the user’s
actual position) on the other hand.
To simplify the portability and future enhancements of the application,it will be
integrated into a Drupal 7 module,respecting the standards for Drupal module devel-
opment.
Keywords
Usability,Geolocation,Google Maps,Social networks,Twitter,Facebook,Drupal
iv
Contents
Contents
1 Introduction 1
1.1 Outline.....................................1
2 State of the Art 3
2.1 Introduction..................................3
2.2 Social Networks................................4
2.2.1 Twitter................................4
2.2.1.1 Overview..........................4
2.2.1.2 APIs.............................5
2.2.2 Facebook...............................6
2.2.2.1 Overview..........................6
2.2.2.2 APIs.............................6
2.2.3 Summary...............................6
2.3 Geolocation..................................7
2.3.1 HTML5................................7
2.3.2 IP Geolocation............................8
2.3.3 Summary...............................8
2.4 Maps......................................9
2.4.1 Google Maps.............................9
2.4.2 Yahoo Maps..............................9
2.4.3 Nokia Maps..............................9
2.4.4 Other map providers.........................10
2.4.5 Summary...............................10
2.5 CMS......................................10
2.5.1 Drupal.................................11
2.5.2 ExpressionEngine...........................13
2.5.3 Comparison..............................15
2.5.3.1 Price.............................15
2.5.3.2 Usability..........................15
2.5.3.3 Add-ons...........................15
2.5.3.4 Final Choice........................16
2.6 Related Work.................................16
2.6.1 Trendsmap..............................16
2.6.2 Tweography..............................18
2.6.3 GeoChirp...............................18
2.6.4 A World of Tweets..........................19
v
Contents
2.7 Summary and Analysis............................20
3 Concept 22
3.1 Introduction..................................22
3.2 Requirements Analysis............................22
3.2.1 Geolocation..............................22
3.2.2 Map..................................23
3.2.3 Tweets.................................23
3.2.4 Layout.................................23
3.3 SWOT Analysis................................23
3.4 Components..................................24
3.4.1 CMS..................................24
3.4.2 LTMap Module............................24
3.4.3 Twitter Plug-In............................26
3.5 Technologies..................................26
3.5.1 PHP..................................26
3.5.2 CSS..................................26
3.5.3 JavaScript...............................27
3.5.4 SQL..................................27
3.6 Used software.................................27
4 Implementation of LTMap 29
4.1 Introduction..................................29
4.2 Architecture of LTMap............................29
4.3 LTMap Module................................30
4.3.1 Configuration Page..........................31
4.3.2 Fetching new Tweets.........................32
4.3.3 Storing new Tweets..........................32
4.3.4 Displaying all Tweets.........................32
4.4 JavaScript Functions.............................32
4.4.1 Map Display..............................33
4.4.2 Geolocation..............................33
4.4.3 Tweet Radius.............................33
4.4.4 Tweet Display.............................34
4.4.5 Map Update..............................34
4.4.6 Other functions............................34
5 Operation instructions 35
5.1 Introduction..................................35
5.2 Installation..................................35
5.3 LTMap User Interface............................36
5.3.1 The Map................................36
5.3.2 Infos..................................38
5.3.3 Actions................................39
vi
Contents
5.3.4 Items..................................40
6 Evaluation 41
6.1 Introduction..................................41
6.2 Functional Evaluation............................41
6.2.1 Efficiency...............................41
6.2.2 Functionality.............................42
6.2.3 Maintainability............................43
6.2.4 Portability...............................43
6.2.5 Reliability...............................44
6.2.6 Usability................................44
6.3 Functional Comparison............................44
6.3.1 Trendsmap..............................45
6.3.2 GeoChirp...............................47
6.3.3 A World of Tweets..........................49
6.3.4 Summary...............................50
6.4 User Study..................................50
6.4.1 Metrics................................51
6.4.1.1 Typology..........................51
6.4.1.2 Participants.........................51
6.4.1.3 Variables..........................51
6.4.2 Scenario................................52
6.4.2.1 Use of LTMap.......................52
6.4.2.2 Installation of LTMap...................54
7 Conclusion 56
7.1 Summary...................................56
7.2 Limitations..................................56
7.3 Future Work..................................57
7.4 Final Thoughts................................57
vii
List of Figures
List of Figures
2.1 Basic Structure................................4
2.2 Nokia Maps satellite view..........................10
2.3 Drupal Architecture [Buy12e]........................12
2.4 ExpressionEngine Architecture [Ell12c]...................14
2.5 Trendsmap - Topics on the map.......................16
2.6 Trendsmap - Additional features.......................17
2.7 Tweography..................................18
2.8 Geochirp....................................19
2.9 A World of Tweets..............................20
3.1 Allowing geolocation in Google Chrome...................22
4.1 Architecture of LTMap............................29
5.1 Activation of the LTMap module......................36
5.2 Configuration of the LTMap module....................37
5.3 UI of LTMap.................................38
5.4 Example of Tweet infowindow........................39
5.5 Example of address autocomplete suggestion................39
5.6 Example of search query...........................40
viii
List of Tables
List of Tables
3.1 SWOT analysis of LTMap..........................24
3.2 Metadata contained in the.info file.....................25
3.3 Database fields and corresponding data types created by ltmap.install..25
6.1 Load times of LTMap.............................42
6.2 Load times of Trendsmap..........................45
6.3 Load times of GeoChirp...........................47
6.4 Load times of A World of Tweets......................49
ix
List of Tables
List of Acronyms
AJAX....................................
Asynchronous
JavaScript
And
XML
API......................................
Application
Programming
Interface
ASQ.....................................
After
Scenario
Questionnaire
CMS.....................................
Content
Management
System
CSS......................................
Cascading
Style
Sheets
cURL....................................
client
URL
FQL.....................................
Facebook
Query
Language
FTP.....................................
File
Transfer
Protocol
GPS.....................................
Global
Positioning
System
GUI......................................
Graphical
User
Interface
HTML...................................
Hyper
Text
Markup
Language
HTTP....................................
Hyper
Text
Transfer
Protocol
IP........................................
Internet
Protocol
ISP......................................
Internet
Service
Provider
JSON....................................
Java
Script
Object
Notation
LTMap...................................
Local
Twitter
Map
PHP.....................................
PHP
Hypertext
Preprocessor
SQL......................................
Structured
Query
Language
SWOT...................................
Strengths,
Weaknesses,
Opportunities and
Threaths
VPN.....................................
Virtual
Private
Network
W3C.....................................
World
Wide
Web
Consortium
XML.....................................e
Xtensible
Markup
Language
x
1 Introduction
1 Introduction
Geolocation is gaining increasing importance for many features related to web devel-
opment.Some of the areas where geolocation is used are:advertising (displaying ad-
vertisements that are related to the actual position of the visitor),language detection
(displaying a website automatically in the visitor’s language),currency detection (dis-
playing prices of an e-commerce site automatically in the visitor’s currency) and auto-
matic redirection (redirecting the visitor to the website in his country).By behaving
like this,websites are not attempting to violate the privacy of visitors,but simply trying
to display content that is relevant to the visitors [TDC12].
Social networks are also getting increasing popularity today,and most of them offer
geolocation features which allow the users to geo-tag their posts,status updates or
Tweets.
Even though social networks offer geolocation features to their users,it is not always
very easy and intuitive to read such information,because not every item in the list of
a user will be geo-tagged,and also because a single item tagged in a given location will
probably not have much meaning for a user.
Having the possibility to display many geo-tagged items would be more efficient:for
example by letting a user display all geo-tagged items near his actual position in order
to dicover what is happening around him.To allow for an immediate understanding and
analysis,this information is ideally displayed on a map,in order to make the location
of the single social network items (posts,staus updates,Tweets,etc.) more clear and
intuitive.
Currently,different services offer localized information based on social networks (see
for example [Sta12a],[Cue13a] and [OP12]),but in most cases this information is still
limited to a single social network and some applications are not very intuitive to use in
their current form.
In this Master thesis,the concept of a map displaying geolocated Tweets,with an ac-
cording prototype,Local Twitter Map (LTMap),has been created and will be presented.
LTMap uses Google Maps and the Twitter search API to display golocated Tweets
around the user’s actual position on a map.It focuses on innovative features,easy
extendability,usability and simplicity and attempts to optimize the caracteristics of
some existing systems which will be analysed throughout the thesis.
1.1 Outline
This thesis is structured as follows:in chapter 2,the state of the art will be analysed.
An overview of the existing social networks,geolocation technologies,map services and
1
1.1 Outline
Content Management Systems (CMS) will be given and some examples of similar existing
applications will be analyzed.
In chapter 3,the concept behind LTMap will be explained.After a look at the
Strengths,Weaknesses,Opportunities and Threaths (SWOT) analysis carried out for
the project,the components of LTMap will be explained,togeteher with its architecture
and the involved technologies and used software.
In chapter 4,the way LTMap was implemented will be explained in detail.After an
overview of the architecture of LTMap,the LTMap module,with its different functions,
and the JavaScript functions needed for LTMap will be presented.
Chapter 5 represents an operation manual for LTMap.First of all,the installation of
the LTMap module will be explained,and then the different features of the user interface
will be explained.
In chapter 6,an evaluation of LTMap will be carried out.First of all a functional
evaluation of the main characteristics of LTMap will be done,then,a functional com-
parison with other systems will be carried out,and in the end,a user study plan will be
presented.
Finally,in chapter 7,a conclusion will be given,with an overview of the obtained
results and a proposal of future enhancements.
2
2 State of the Art
2 State of the Art
2.1 Introduction
This chapter gives an overview of the aspects that build the foundations of displaying
localized social media information with today’s technologies.
There exist different ways to display data from social networks.A very popular form
are lists (as it is the display chosen by most social networks,like for example [Twi12b],
[Fac12a] and [Goo12a]),but also other displays are used,like maps (see for example
[Sta12a] and [ZM12]).These alternative display methods are getting more and more
popular.Each display method has its interesting features and also its limits,but this
depends mainly on one’s personal needs,requirements and desires.
In most cases (see for example [Sta12a],[Cue13a] and [OP12]) the display of social
media is done one social network at a time,due to the different protocols and data of
each network,which make an interaction between multiple networks quite difficult.
Displaying social media on a map,like it will be done in the prototype related to
this thesis,is a relatively new kind of application,and few systems offering such type
of display exist today (like [Sta12a],[Cue13a] and [OP12]).The reason for this is that
displaying social media on a map is complex and implies many different questions and
choices:which area needs to be displayed,how many items to display,how to localize
the visitor correctly,where to display the data on the map,what data to display,how
to refresh the displayed data while the user is moving along the map,etc.
Each choice from the above list implies a cascade of other choices:if,for example,you
choose to display hundreds,or even thousands of tweets,you will not be able to display
them on a small area of the map;or if you want to display lots of details about each
single post (picture,location,date,title,text,etc.),you will not be able to display lots
of items at once,due to the limited space available.
Additionally,an application fetching data from social networks needs to adapt to the
rules and limitations of the respective Application Programming Interfaces (APIs),like
for example the maximum number of possible requests of Twitter APIs [Twi12d].
There are three main components needed for the localized display of social media (as
depicted in figure 2.1):one or more social networks,a geolocation algorithm and a map
on which to display the fetched data.There would be a fourth main component in this
list,namely the users posting and viewing the data,but it is beyond the scope of this
thesis to do a psychological analysis of the users’ behavior,so we will skip them and
focus only on the technical aspects implied.
In the following sections,we will look at these main components necessary for the
localized display of social media,namely the main social networks (with their protocols,
3
2.2 Social Networks
Figure 2.1:Basic Structure
available fields,limitations,etc.),the existing geolocation techniques (with the difficul-
ties related to them),the available map interfaces and,last but not least,the CMS into
which the application will be integrated.
After this,we will look at some examples of applications displaying social media on a
map,and try to analyze their pros and cons in order to take inspiration from existing
systems.For each example of application,an analysis will be made about which features
could come in handy,which aspects could be improved and which ones should be ignored
in the prototype of LTMap.
Finally we will sum up the findings in a brief conclusion.
2.2 Social Networks
The main social networks from which data is fetched are Twitter and Facebook,this
because on one hand,they have well working APIs for reading the data (see [Twi12c]
and [Fac12b]),and on the other hand,because they already provide their users with
a geo-tagging feature that allows them to add a location to their posts.This feature
greatly facilitates the localized display of data.
2.2.1 Twitter
2.2.1.1 Overview
Twitter is an online social network (or better,it is “one of the largest microblog services”
available today [IET12]) that allows its users to post short messages limited to a length
4
2.2.1 Twitter
of 140 characters,which can be read by all other Twitter users [HRW08].These short
messages are commonly called Tweets [IET12].
Tweets can have different structures:actual messages by the user writing,messages
forwarded from other users (called Retweets and indicated by “RT” in the concerned
message),messages containing user identifiers (“@” followed by the user name) that are
directed to these users,messages containing hashtags (“#” followed by a word) and also
a mix of the above [KLPM10].
Tweets usually contain metadata,which represents additional information like the
author,the time and date at which a message was posted and,if available,also the
location at which the message was posted [LSdV
+
11].
People can follow other Twitter users in order to receive all Tweets that are posted
by these users [KLPM10].Each time a user you are following posts a new Tweet,this
will be added to your timeline,together with the Tweets of all other people you are
following.Each time another user follows you,it will be added to your list of Followers.
On the other hand,each time you follow another user,it will be added to your list of
Followings.
2.2.1.2 APIs
Twitter offers different APIs that reflect different ways to access its data.These APIs
are [Twi12c]:
• Search API:this API allows to run anonymous searches inside an index of recent
Tweets,which includes between six and nine days of Tweets;the search focuses
on relevance and not on completeness,which means that only the most relevant
Tweets are fetched and therefore “some Tweets and users may be missing from
search results”;the results can be limited to a given location by using the geocode
parameter,and limited to a given area around the location by using the radius
parameter [Twi12g].
• REST API:the REST API is the most complete API provided by Twitter,as it
contains many different methods divided in the categories “Timelines”,“Tweets”,
“Search”,“Streaming”,“Direct Messages”,“Friends & Followers”,“Users”,“Sug-
gested Users”,“Favorites”,“Lists”,“Accounts”,“Notification”,“Saved Searches”,
“Places & Geo”,“Trends”,“Blocks”,“Spam Reporting”,“OAuth”,“Help”,“Le-
gal” and “Deprecated” (the methods inside this category are,as the name suggests,
deprecated);inside these categories,there are GET and/or POST methods to re-
trieve and publish data [Twi12e].
• Streaming APIs:this set of APIs provides access to public streams (the “public
data flowing through Twitter”),user streams (the “data corresponding with a single
user’s view of Twitter”) and site streams (a “multi-user version of user streams”)
[Twi12f].
The choice of the corresponding API depends strongly on the type of application that
needs to be created,each API (or set of APIs) having its strengths and weak points for
5
2.2.2 Facebook
given aspects (limit of queries,need of user authentication,etc.).
2.2.2 Facebook
2.2.2.1 Overview
Facebook originated in 2004 as an online social network exclusively available to college
students [GWH07].Only in 2006 it became publicly available and started its huge
spread [HP10],to become the most important social network available today,with over
950 million active users [SEC12].
Facebook allows its users to publish different types of data:status updates in text
form (mostly short messages in the style of “I’m going to the mall” or “Working hard on
that big project”) or containing a photo/video (in addition to an optional text message),
life events (salient moments of one’s life,like a new job,a marriage,etc.) and places
(the place where one is in that moment,togheter with a text message) [Fac12a].
Unlike Twitter,there are no one-way relationships in Facebook,in order to add some-
one as a friend and see his data,one needs to wait for a confirmation of the friend request.
If the other person has a public Facebook profile,his data will be publicly available and
therefore one can freely visit his profile,but to create a real link with another person
(and therefore add it to your list of friends) the friend request must be mutual [Fac12a].
2.2.2.2 APIs
Facebook provides three distinct ways to access its data [Fac12b]:
• Graph API:this API allows to access the social graph,which is Facebook’s core and
contains information about people,photos,events,pages and everything connected
to them [Fac12d].
• Facebook Query Language (FQL):this is not really an API itself,but can be used
through the Graph API (see above) to run queries in the style of Structured Query
Language (SQL);it allows to access some advanced features that the Graph API
does not provide (e.g.“batching multiple queries into a single call”) [Fac12c].
• REST API:this API will be deprecated and is listed here only for completeness,
it allows the user to interact programmatically with Facebook through HyperText
Transfer Protocol (HTTP) requests [Fac12e].
As with Twitter,the choice of the corresponding API depends on the needs of the
application to be developed:FQL can be used if more advanced features are needed (or
if the developer prefers the SQL-like request style),while the Graph API can be used
for all other situations.
2.2.3 Summary
Although we have seen “only” the two major social networks existing today (many more
could have been taken into consideration),only one was used for LTMap,namely Twitter.
6
2.3 Geolocation
The reason for this limitation is that for the first prototype of LTMap,the purpose was
to focus on only one social network in order to lay down a very solid foundation for
future improvements and additions.The choice of Twitter is mainly due to the fact that
Tweets are more easily interpretable,as they have a limited length and focus mainly on
text content.
2.3 Geolocation
In order to display data coming from the user’s position (or at least from the user’s
surroundings),the application must be able to localize the user’s position.This is done
through geolocation algorithms that can determine the user’s position in different ways
[Kaa03]:
• Reading the data from a Global Positioning System (GPS) module:this is the
most precise way,but requires that the user’s PC or mobile phone is equipped
with a GPS module.
• Analyzing the cellphone towers (triangulation) or wireless access points in the
surroundings:this may not always be very precise,due to the possible distance
between the user and the cellphone towers or access points.
• Reading the user’s Internet Protocol (IP) address:this may not always be very
precise (especially if the user is connected to a Visrtual Private Network (VPN)
or accesses the internet through a proxy server).
• Through a form in which the user physically enters its position:this position is
then transformed into its actual coordinates through a separate service.
Most of the APIs available today provide automatic fallback mechanisms in order to
try to get the most accurate position by GPS first,then by falling back to cellphone
tower triangulation or WiFi network and IP address reading and finally,in some cases,
by providing the user with a form for inserting his address.
No API available will give a warranty that the exact position of the user is returned.
The attempt is always to get the position of the user within a radius of N meters (which
will depend on the API and on the available technology,i.e.GPS,WLAN,IP address,
etc.).
In the following sections we will look at some of the main providers of geolocation
APIs.
2.3.1 HTML5
One of the most diffused geolocation APIs available today is the Geolocation API pro-
vided by the World Wide Web Consortium (W3C) and making use of HTML5 [W3C12].
The API provides access to many different sources providing location information:
“GPS and location inferred from network signals such as IP address,RFID,WiFi and
Bluetooth MAC addresses,and GSM/CDMA cell IDs,as well as user input”.
7
2.3.2 IP Geolocation
It allows to make single (or “one-shot”) position requests and also to track position
through repeated updates [W3C12].
Being part of the W3C Recommendation ensures high compatibility and stability of
the API.
2.3.2 IP Geolocation
There are many IP geolocation services available today,but most of them are paid
services (see for example [Max12c]).There are also free alternatives available,but often
they are outdated,limited or distributed only as binary files.
Some examples of free IP geolocation services are:
• MaxMind GeoLite [Max12d] (which provides also paid IP databases [Max12a],
paid web services [Max12c] and a paid JavaScript API [Max12b]),giving access
to downloadable IP databases updated once per month and distributed under a
Creative Commons Attribution-ShareAlike 3.0 Unported License [Cre].
• freegeoip.net,which provides both a free web service [Fio11b] and a JavaScript
API [Fio11a],but has a quite old database (last updated in April,2011).
• hostip.info,which provides an API returning geocoded IP addresses in the three
formats HyperText Markup Language (HTML),eXtensible Markup Language
(XML) and JavaScript Object Notation (JSON) [hos12b] and also downloadable
IP databases [hos12a].
• ipinfodb.com,which provides IP location APIs in XML format [ipi12b] and JSON
format [ipi12a].
All of the above provide different results and accuracy,due to the age of the updates
and the available granularity level (city,state or country),but none of them is satisfac-
tory,because at most they will be able to provide the location of your actual Internet
Service Provider (ISP),which is not always located near the user.
IP geolocation services can be a good solution for general purposes (like,for example,
automatically detecting the user’s language,or showing a country specific version of a
website) but they can only be used as a fallback mechanism,and not as a standalone
service,for geolocated display of information on a map.
2.3.3 Summary
For the geolocation features of LTMap,it has been chosen to use HTML5 geolocation,
as it allows for a more accurate positioning of the user than IP geolocation techniques.
This was necessary in order to provide accurate data to the visitors and avoid to display
data coming from the region of the user’s ISP (which would be completely useless to the
user).
8
2.4 Maps
2.4 Maps
The display of interactive maps is very popular today,and there exist many different
providers that offer APIs for displaying maps and objects (markers,lines,polygons,etc.)
on them.
In this section we will cite some of the major map API providers and describe their
main features.The comparison of the different map services will be based on [SW12].
This section will give only an overview of the existing services,for a more in-depth
analysis and comparison,please refer to the original paper [SW12].
2.4.1 Google Maps
Google Maps was published in 2005 and was the first free Web mapping service [SW12].
Today Google Maps is still the most important and complete free mapping service
provider available (based on a comparison of the features described in [SW12]).
The main features of Google Maps are [Goo12b]:
• Interaction:it offers various different,and well working,interaction possibilities
(keyboard shortcuts,mouse pointer,mouse wheel,etc.).
• Technologies:it offers different popular technologies to display,and interact with,
the map interface (JavaScript,Ajax,iFrame,JSON,XML,etc.).
• Extra features:it offers a large number of interesting extra features,like directions,
public transport integration,walking directions,live traffic information,etc.
Google Maps offers a very complete and comprehensive JavaScript API,offering many
methods to create maps and interact with them (by creating overlays,changing map
types,using services like geocoding,etc.) [Goo12e].
Google offers also other APIs,like for example a simpler image API,a more complete
business version of the Google Maps API,and specific APIs for Google Earth and Google
Places [Goo12c].
2.4.2 Yahoo Maps
Yahoo Maps is another big mapping service and map API provider.It has quite the
same features as Google Maps,but it is slightly more limited:it offers less zoom levels,
less extra features and is also less intuitive to use [Yah12a].
The main problemwith Yahoo Maps is that its APIs where discontinued in September
13,2011.By visiting the corresponding website you find a note recommending to use
Nokia’s Ovi Maps API [Yah12b].
2.4.3 Nokia Maps
Nokia Maps [Nok12] is more recent than the two previous mapping services.As we have
seen above (see chapter 2.4.2),it replaced Yahoo Maps in September,2011 [Yah12b].
9
2.4.4 Other map providers
Even if Nokia Maps is one of today’s well-known mapping services and map API
providers,it does still give the impression of a development version for the moment,as
it provides unsatisfying map data/images (especially for what concerns satellite images,
see for example figure 2.2) and more limited features than Google Maps [Nok12].
Figure 2.2:Nokia Maps satellite view
2.4.4 Other map providers
There are other mapping service and map API providers,like Bing Maps [Mic11] or
MapQuest [Map12],but they have still some drawbacks (mainly the lack of satellite
data),similarly to Nokia Maps.
Another well known example is OpenStreetMap [Ope12b],but it is even more limited
than the others (the streets displayed on the map are not always correct and up to date,
there are no satellite images,etc.).The difference between OpenStreetMap and the
providers cited above is that its maps are created and improved directly by the users
and freely distributed under an open license [Ope12b].
2.4.5 Summary
In order to provide an optimal user experience and the best features and map material
available (at least for free),it has been chosen to use Google Maps as mapping service
for LTMap.This results from the feature-richness and accuracy of Google Maps with
respect to its main concurrents.
2.5 CMS
In order to facilitate and improve some aspects of the prototype,it has been chosen
to integrate the final application into a CMS.The main reasons for this are that a
CMS already provides the main basic security features,a modular (and therefore easily
10
2.5.1 Drupal
extendable) plugin/module system and also an easy content management mechanism
[AH08].
Today,the most well-known free CMSs are Drupal [Buy09c],WordPress [Wor12] and
Joomla [Ope12a].These three CMSs offer different features and fit for different types of
applications:WordPress is often used as a blogging platform,Drupal as a platform for
informative sites and Joomla fits best for intranet sites [PRP11].
Of these three alternatives,only Drupal has been retained as a possible candidate for
the development of LTMap,this because it is the fastest one [PRP11],and also the one
that best fits the needs of LTMap.Additionally,the author has previous experience
with the installation,setup and development of Drupal,which is of a great help with
the development of LTMap.
In addition to these free CMSs,there is also a commercial (but still open source)
alternative,namely ExpressionEngine [Ell12a].ExpressionEngine costs up to 299$ and
also most of its add-ons have a price,but it is very stable,easy to use and extend and
offers a very good support (one of the main advantages of commercial products).
Still another option would have been to create a CMS from scratch,as it was done in
a previous work by the author [Mar10].But instead,it resulted preferrable to use an
existing CMS solution.This choice has been made in order to use the modular structure
(plugins/modules) of an existing CMS solution and to increase the security and stability
of the final prototype.Additionally,in the previous work by the author it turned out to
be too time consuming to create a CMS from scratch,even a very simple one like the
one created for eGlossar [Mar10].
Instead of a CMS,a single page displaying the map and integrating all the logic
for geolocation and display of the social network data could have been used.A CMS
solution was preferred in order to rely on the existing security features,an existing
content management mechanism and mainly a well established and working plug-in
structure to use for easy future extensions of LTMap.
In the next sections,Drupal and ExpressionEngine (the two CMS solutions retained as
main candidates for the prototype of this thesis) will be presented and analyzed.After
this,a comparison and summary will be proposed.
2.5.1 Drupal
Drupal is a very popular open-source CMS offering a wide range of possibilities for
adapting the design and the features through the use of many themes and plug-ins
[Buy09c].
Drupal is written in the PHP Hypertext Preprocessor (PHP) language and uses SQL
as a database language,Cascading Style Sheets (CSS) for theming and JavaScript for
interactive and asynchronous features.
Drupal works on different levels (or tiers),as you can see in figure 2.3:first of all
there is the data level,where the data of the page is stored;then comes the module
level,where Drupal’s modules can access the site’s data and carry out special functions;
after that comes the blocks level,where blocks are displayed (these can contain data
from the modules,from a menu or directly from the user);on top of the block level is
11
2.5.1 Drupal
the level concerned with user permissions,which controls which data can be displayed
for which user;last but not least comes the most important level,namely the templates
level,where the whole layout of the site is generated by Drupal’s templates.
Figure 2.3:Drupal Architecture [Buy12e]
In this section we will look at the main characteristics and features of Drupal,by
trying to analyze their pros and cons.Please note that the parts where no citations are
provided are based on previous personal experience of the author.
First of all,Drupal is open-source,and the same applies to most of its themes and
modules.This means that you can get the CMS and its components for free and make
changes to the source code as it pleases you.This first point is a big advantage,because
it means that you do not need to spend any money for the CMS,and you can adapt its
source code to your needs.On the other hand,since Drupal is developed and maintained
by a huge community (more than 630,000 users and developers),and since the support
is provided by a volunteer community,it can be quite difficult to get reliable support,
because every support request is done on public forums and therefore is not always
answered in an acceptable time lapse [Buy09c]
1
.
Another important feature of Drupal is its very large number of modules (more than
17,000 available modules in total [Buy09a]) and themes (more than 1400 themes available
1
Please note that only the basic information is taken from [Buy09c],the more critical part is based on
previous personal experience.
12
2.5.2 ExpressionEngine
in total [Buy09b]).This very large repository can be useful,because usually it is quite
easy to find a module or theme that fits your needs,but the big number does also mean
that for each search you do,you will find 5,10,or even more results,which need to be
installed and tested to see if they effectively correspond to your needs.This can be time
consuming and stressing,since most of the results you find will not correspond to your
needs or will need some fine tuning (either to adapt even better to your needs,or simply
because the module/theme contains some bugs that need to be fixed).
For what concerns usability,Drupal is quite easy to use.Once you installed it suc-
cessfully,it will appear with some very basic content and a quite simple administrative
menu on top.This could already be sufficient for most users,but as a developer with
some experience and given needs,you will first want to improve Drupal’s features with
some additional modules.
For the design part,you can use existing themes and adapt them to your needs,but if
you need to accomplish given special layouts or outputs (e.g.a different layout for each
page in your CMS),it can get quite tricky to get the desired result.
2.5.2 ExpressionEngine
As we did with Drupal,we will describe the main features of ExpressionEngine and
analyze their pros and cons.As before,the parts where no citations are provided are
based on previous personal experience of the author.
The main architecture of ExpressionEngine is very similar to the one of Drupal:it
uses PHP,SQL,CSS and JavaScript as its main components.The difference comes in
the way it works (see also figure 2.4):the data (or information) layer is inside so-called
channels (basically a grouping of fields for a given content,like for example “Title”,
“Text”,“Images”,etc.);these channels are then read inside ExpressionEngine’s tem-
plates through the use of tags (which are very similar to XML tags and can output
channel data or data from modules/plugins);these templates (which contain the HTML
layout of the respective pages) can be grouped into template groups (a sort of folder)
according to one’s needs and are displayed on the site.
In contrast to Drupal,ExpressionEngine is a commercial CMS and therefore has a
cost (of 99-299 $,depending on the license you choose [Ell12b]) associated with it,but
it is “built on an Open Source foundation” and therefore still allows full access to its
codebase [Ell12a].
With this combination,ExpressionEngine offers the “best of both worlds”,by pro-
viding commercial advantages (e.g.quick answers to customers,worldclass technical
support and a reliable development and support team) on one hand,and the advan-
tages of an open source foundation (through the use,as its core,of CodeIgniter,a very
popular,fast,lightweight and open source PHP framework) on the other hand [Ell12a].
This combination makes ExpressionEngine a very powerful CMS solution for bigger
projects,as one gets a very good commercial support and also the ability of adapting
the core to one’s needs.
ExpressionEngine is very complete:as soon as one has finished installing it,you
get access to lots of interesting modules and plug-ins that you would need to install
13
2.5.2 ExpressionEngine
Figure 2.4:ExpressionEngine Architecture [Ell12c]
additionally in other CMS solutions.These include security features,user management,
blog features,e-mailing/communication features,and many more [Ell12b].This allows
you to have a very complete system from the beginning,which covers most needs.For
those core features that are not needed,there is the possibility to deactivate or uninstall
the corresponding modules or plug-ins,so that they do not unnecessarily slow down the
system.
Another interesting feature of ExpressionEngine is that everything can be managed
online,from the admin interface,without having to connect to a File Transfer Protocol
(FTP) server.It is still possible to access configuration files or templates directly on the
FTP server,but it is not strictly necessary as with other CMS solutions.This allows
for a great flexibility as you are free to access everything from a web browser,without
needing any other software or access rights.
One of the disadvantages of ExpressionEngine is that after having finished installing it,
you are provided with no content (if you choose the default layout,and not the example
theme provided with the basic installation).This means that when you access the site
after having installed ExpressionEngine,you will be provided with a blank page.
On the other hand,it is very easy to add new pages:basically,you can simply copy
and paste the HTML code from an existing,static site (or from HTML templates) and
simply make the desired parts dynamic by adding the contents,menus,etc.
For more special features,you need to install add-ons (modules,plug-ins or exten-
sions),like with other CMSs.There is only a limited number of available add-ons
(approximatively 1700),which means that you are not granted that you will find an
add-on that fits your needs exactly,but on the other hand,if you find one,you can be
quite sure that it will be of good quality (although it will eventally be commercial).
14
2.5.3 Comparison
2.5.3 Comparison
In this section we will compare the two CMSs described above,in order to find an ideal
candidate.
2.5.3.1 Price
As we have seen,Drupal has no costs related with it,as it is free (and so are all its
modules),while ExpressionEngine has a quite important cost connected with it,as you
need to purchase a license for the CMS and eventual additional licenses for the add-ons
you may need.
Even if the cost for a working install of ExpressionEngine may seem important,it has
been proved,by previous personal experience of the author,to be quickly amortized by
a quicker overall development of the working website.
2.5.3.2 Usability
On the administrative side,both CMSs descibed above are quite usable,but in order to
make Drupal really usable,you need to perform some changes and add some modules,
while with ExpressionEngine you have already everything you need from the beginning,
right after the install.
The main features of ExpressionEngine that increase the usability for administrators
are:
• Admin menu:the menu allows already to access all respective sub-items (and not
only the main items,as with the basic Drupal install).
• Completely separed admin interface:the admin interface of ExpressionEngine is
clearly separed from the public site,this means that you have no admin menu or
editing icons breaking up your layout when you visit the public site while connected
as an administrator.
• Easy template integration:you can simply copy and paste your HTML code into a
new template,without having to take care of special CMS elements as in Drupal.
• Completeness:ExpressionEngine comes with many pre-installed features that you
would need to manually add in Drupal,these include,for example,functions for
easily communicating with other site members,access rights and automatic noti-
fications based on given events.
2.5.3.3 Add-ons
Drupal has much more modules than ExpressionEngine has add-ons,but as we have
seen,this does not necessarily need to be an advantage,as for each module you search,
you will find lots of different possibilities,which do not always work as desired.
ExpressionEngine,on the other hand,has only few available add-ons,but most of
them are of good quality.The disadvantage is that the add-ons of very good quality are
commercial and therefore a license needs to be purchased.
15
2.6 Related Work
2.5.3.4 Final Choice
Although from the previous sections it should clearly appear that the author prefers
the use of ExpressionEngine over the use of Drupal,the CMS used to develop LTMap
is Drupal.The reason for this is that LTMap aims to be compatible with the existing
website of the University of Fribourg.Since Drupal has been used for the existing
website,LTMap will be developed using Drupal,too,in order to be able to integrate it
easily and make it work properly on the website of the university.
Please note that the use of Drupal is in no way a negative point (even if this may
appear from the above sections).Drupal is a very good platform for the development of
LTMap:it is free and open source,it offers lots of existing modules from which one can
take a very good inspiration,and it allows for an easy integration into the university
infrastructure.
2.6 Related Work
In this section we will look at some examples of existing applications displaying data
fetched from social networks on a map.
2.6.1 Trendsmap
Trendsmap is “a real-time mapping of Twitter trends across the world” [Sta12a].It
tracks the most important words and topics on Twitter and displays them on a map
(see figure 2.5),by regularly updating the display as words become more or less popular
[Sta12b].
Figure 2.5:Trendsmap - Topics on the map
Trendsmap was programmed in Ruby [Rub12] and uses the JQuery JavaScript frame-
work [The12].The topics are fetched from the Twitter API [Twi12c] and are displayed
on a map using Google Maps [Goo12e].
It is one of the most promising applications displaying data from Twitter on a map,
and it offers many interesting features,which we will describe now.
16
2.6.1 Trendsmap
First of all,Trendsmap is lightweight and hence loads very fast.When you visit
the homepage [Sta12a] you are already presented with the map (and if the localization
feature is enabled in your browser,it will already be centered on your location,city
or region).Depending on your location and on the corresponding number of topics to
display,after some seconds you are provided with the topics displayed according to their
importance (larger and darker topics indicate stronger trends [Sta12b]).
Trendsmap offers automatic localization features,allowing you to localize your exact
location,your city or your region.Additionally,it offers some overviews on the homepage
(below the map,see figure 2.6),displaying actual trends (globally,by country and by
region) and also the globally trending users [Sta12a].
Figure 2.6:Trendsmap - Additional features
By clicking on a topic in the “Breaking Globally list”,you will be presented with
a map showing all locations where the given topic appears.The same happens when
clicking on a user in the “Globally Trending Users” list,with the difference that you are
provided with the locations where that user has published Tweets.You have even the
possibility to display all locations where Tweets are available [Sta12c].
Trendsmap does also have some drawbacks.The first main problem with the map
is that the topics are not always displayed in their exact position,because there may
be many topics from a given location (and therefore there is a cloud around a given
location) [Sta12b].This is not a fault of the application itself,but more a physical limit
of the map space available.To overcome this problem,a different display of the topics
would be needed,which would probably not be as intuitive as the display chosen by the
developers of Trendsmap.
Additionally,the topics may not be visible at first,because they are shown based on
their importance (and topics of a minor importance appear only starting from a given
zoom level),which means that if you look at Switzerland,for example,you will see
no topics on the map,but if you zoom in to its major cities,like Zurich,you start to
see some topics that appear.This,too,is not a problem of the application itself,but
depends on the limited space available on the map display:if everything would be shown
from the beginning,the map would become overloaded and the topics would be very
hard to distinguish.
Nevertheless,Trendsmap stays one of the fastest and most complete applications
around today.It runs very well and has many interesting features,with only some
minor drawbacks concerning usability and not really depending on the application itself.
17
2.6.2 Tweography
2.6.2 Tweography
Another interesting application for displaying Tweets on a map is Tweography [OP12].
The particularity of Tweography is that it does not display all geotagged Tweets
around you,but only your personal geotagged Tweets [She09].This allows a single user
to keep track of his geotagged Tweets,even if “only” 200 at a time.
In order to access your Tweets,Tweography uses Twitter OAuth to authenticate you.
The OAuth authentication protocol “allows users to approve application to act on their
behalf without sharing their password” [Twi11a].
The problem with Tweography is that it is facing some difficulties and the message
“Twitter API is suffering from epic failulitis.Refresh and hope for the best?” does
always appear above an empty map (see figure 2.7).
Figure 2.7:Tweography
Another sad aspect of Tweography is that it is far from being well documented.All
you get is a footer with two links to Twitter profiles,but there is no documentation
at all.Because of this,the information above is either taken from external sources,or
directly deduced from the behaviour of the application.
2.6.3 GeoChirp
Geochirp [Cue13a] is another very promising application,although it is slightly different
from the other applications,considering that it does not display Tweets on a map.
In Geochirp you are provided with a map,but it is not used to display Tweets on it,
but to choose a given location around which you want to display Tweets.
Once you have chosen a location,you can set a search radius in miles and the number
of Tweets to display per page,and you are provided with an according list of Tweets in
the specified search area.The bigger the search radius,and the more varied the found
18
2.6.4 A World of Tweets
Tweets will be.By increasing the number of Tweets to display,you can have a better
overview of the Tweets posted inside your search radius.
On the right side,you are provided with the most influent people (or “Tweple”,as
Geochirp calls them) in the area you specified (see figure 2.8).
Figure 2.8:Geochirp
In addition to these features,Geochirp provides the user with the possibility to trans-
late the Tweets that are displayed and to interact directly with each single Tweet,by
replying to it,retweeting it or adding its author to one’s list of following.Additionally,
the user can get more informations about a given author by clicking on his nickname,
this will open a popup window displaying a description,the location,the number of
updates,the number of followers/following,and some other data about the author.
All the basic functions (which are already very promising) are accessible without
logging in,but if a user does login to Geochirp (with OAuth,the same protocol already
described for Tweography,see chapter 2.6.2),he is provided with even more features,
like the possibility to save his searches,create and manage people groups and add people
to these groups.
2.6.4 A World of Tweets
A World of Tweets [ZM12] displays where people are tweeting around the world.The
display happens anonymously (no Tweet data,whether the text nor the author of the
Tweet,is displayed),the focus is only on the actual position of the Tweet.
From the location data,A World of Tweets generates a heatmap (or,if desired,a
“Smoky Clouds” map) updated in real time as new Tweets are posted in a given location.
As the number of Tweets in a given location grows,the location gets “hotter” or,in other
words,more red (see image 2.9).
19
2.7 Summary and Analysis
Figure 2.9:A World of Tweets
There are different options to choose from for the display of the data:you can switch
between a heatmap and a “Smoky Clouds” view,between a map and satellite view,you
can hide the map or the heatmap,you can display labels which show you the country
of the posted Tweets,you can clear the heatmap and you can even get a 3D stereo view
(by wearing 3D red cyan glasses).
In addition to the map view,A World of Tweets displays also different statistics,like
real time tweeting stats,tweeting stats of the current day,tweeting stats fromthe launch
of the application on 1st November 2010,the number of countries where Tweets have
been posted,the total number of Tweets processed,the top 20 countries,etc.
A World of Tweets uses Twitter’s Streaming API (with occasional aid of Yahoo Place-
maker [Yah12c]) to fetch geolocated Tweets and display them on a static map using
HTML5 (or Flash if the browser should not support HTML5).
Although not displaying actual Tweet data (texts,authors,details,etc.),A World of
Tweets is very interesting because it allows to get a very intuitive overview of where the
most Tweets are posted,focusing only on the location and ignoring other details about
the Tweets.
2.7 Summary and Analysis
In this section we will sumup the findings fromthe descriptions of the single components
described above,and define which component fits best for the use in our prototype and
why this is so.We will also take into consideration the strengths and weaknesses of the
examples that we have seen.
For what concerns the social networks,in this thesis (and for the related prototype),
we will focus first of all on Twitter.Additional social networks can be added at the end
(subject to time limitations) or in future improvements,thanks to the modular structure
of the application which allows easy improvements.
The reason for this limit is that with this thesis we want to build the solid foundations
20
2.7 Summary and Analysis
for an application displaying data coming from social networks on a map,therefore the
main focus will be on the underlying technology for displaying data on a map,and Twit-
ter will be used as a first “example” social network due to the fact that Tweets already
contain information about their location,which helps with the geolocation feature of the
application.
For the geolocation features of the application,the application will make use of the
HTML5 Geolocation API,as it provides more accurate results.The IP geolocation
techniques would ensure a higher cross-browser compatibility,but it is preferrable to use
them as a fallback mechanism on browsers that do not support HTML5,and provide
accurate positions on browsers that support HTML5.
The display of the map will be achieved through the Google Maps API,because it is
the most complete and accurate maps API availbale today.It provides both a complete
set of API methods on the developer side,and a very good and accurate display of the
map on the user side.With other map APIs it would be hard to achieve the same results,
as we have seen before (see chapter 2.4).
The CMS on which the application will run would have been ExpressionEngine as a
first choice,because of the advantages seen in chapter 2.5,but in order to maintain an
optimal compatibility with the rest of the IT infrastructure of the University,Drupal
has been chosen as the best solution.
21
3 Concept
3 Concept
3.1 Introduction
In this chapter,we will provide an insight into the different aspects that have been taken
into consideration for supporting the development of LTMap.
After a short introduction outlining the requirements analysis and considering the
SWOT analysis,we will look at the general structure of LTMap and the components
and technologies used to develop it.
3.2 Requirements Analysis
In this section an overview of the main features of LTMap will be given.
3.2.1 Geolocation
Although being a hidden feature running in the background,geolocation is the first
feature a visitor encounters on LTMap.
Geolocation needed to be as easy and intuitive as possible,but still very accurate.
This was made possible through the use of HTML5:it is very simple,as (for privacy
reasons) it just needs a confirmation by the user the first time he visits the website (see
image 3.1),after that the geolocation of the user is entirely automatic,and it is also
very accurate,as it can access different data about the user (GPS position in case a GPS
module is available,or else network position and/or IP address of the user).
Figure 3.1:Allowing geolocation in Google Chrome
In case the automatic geolocation described above does not work,an error message
is displayed and a text-field for manual input of the user’s address is activated.The
address entered is then converted to a location using the Google Maps API,and the
map is refreshed,showing the corresponding location.
22
3.2.2 Map
3.2.2 Map
The map is the foundation of LTMap,as it is needed to display the Tweets on it.
The map used for LTMap needed to be very intuitive,but still feature-rich and detailed
enough to display also precise addresses with a good resolution.The best available choice
for this was Google Maps,because it is very popular (and therefore well known by most
users),intuitive and also very feature rich if compared to other mapping services (see
chapter 2.4).
3.2.3 Tweets
The Tweets to display on the map needed first of all to have location information in
order to be displayed in an accurate manner.A possible fallback mechanism for non-
geolocated Tweets could have been to use the location provided by the Tweet’s author in
his profile,but this choice would not have been ideal,due to the fact that large amounts
of Tweets would have been located in one single point (due to the fact that many Tweets
are not geolocated).
Additionally,the Tweets needed to be as many as possible,in order to be able to
display Tweets for every region that may be displayed on the map.
Since Twitter limits the number of requests that can be done on its APIs,the only
way to display many Tweets was to store them in a database and load them on the map.
Each time a visitor reaches the website,a request is done to the Twitter API in order to
fetch the latest Tweets and then these are stored in the database and displayed together
with the previous Tweets already stored before.
3.2.4 Layout
The layout of LTMap was the last,but not least,point to take into consideration during
development:on one hand the focus was on the features of LTMap,therefore the design
was only considered in a later moment,but on the other hand LTMap needed to be both
appealing and usable,therefore the design needed to be studied with care.
3.3 SWOT Analysis
Before the start of the development of LTMap,a SWOT analysis was carried out to
determine and preview the strengths,weaknesses,opportunities and threaths of an ap-
plication displaying localized Tweets on a map.This analysis is shown in table 3.1 and
should not need any further explanations.
23
3.4 Components
Strengths
Low costs
Intuitive to use
Automatic position detection
Easy to improve and expand
Automatic recovery of content
Multiple possible data sources
Easy future addition of other data sources
Weaknesses
Not many available examples
Learning of involved technologies
Need to respect given plugin structure for future additions
Dependance on external services
Opportunities
Big spread through Open Source license
Adaptation for use in other applications
Threats
Users not understanding purpose of the system
Browser incompatibility
Privacy of users
Table 3.1:SWOT analysis of LTMap
3.4 Components
3.4.1 CMS
Although the CMS is only a minor part of this project,it is the cornerstone on which
the LTMap module relies and it is also used to display informative pages describing the
project and documentation pages trying to help the user if he should need support.
The choice to add informative pages has been made because some of the existing
examples (see chapter 2.6) consist only of a single page containing the application itself,
but lack of any additional information or documentation.The purpose of LTMap,in
contrast,is to be well documented and easily understandable for everyone.
3.4.2 LTMap Module
The core of the LTMap application is the LTMap module,a Drupal module responsible
for displaying the map (using Google Maps),fetching the user’s location (using HTML5
geolocation) and displaying data from a given set of social networks (determined by the
corresponding installed plugins).Although the module supports only Twitter for the
moment,it is able to integrate with additional social networks in the future.
The LTMap module was built from scratch following the instructions on the Drupal
website [Hun12].It consists of the following files:
• ltmap.info - contains all metadata about the project (see also table 3.2).
• ltmap.install - creates the base structure needed when installing the module
(this includes database tables and the corresponding fields and data types,see
also table 3.3).
• ltmap.module - the actual code executed by the module;
• plugins/twitter.php - the custom functions needed to store and display Tweets.
All the above files are located inside the module folder ltmap,inside the folder
/sites/all/modules/,recommended by Drupal for custom modules [BDF
+
10].
24
3.4.2 LTMap Module
In table 3.2 you can find all possible metadata fields that may appear inside a.info
file (optional fields are in italics).
name
The name of the module,displayed on the Modules page
description
Aone-line description telling administrators what the module
does,displayed on the Modules page
core
The version of Drupal the module is for
stylesheets
CSS files to be loaded by the module
scripts
JavaScript files to be loaded by the module
files
External files the module uses (for class or interface decla-
rations)
dependencies
Other modules that the module requires
package
The name of the package the module is part of
php
Minimum PHP version required by the module
configure
The path to the main configuration page for the module
required
Allows to make the module enabled by default
hidden
Allows to hide modules from the Modules page
Table 3.2:Metadata contained in the.info file
In table 3.3 you can find all database fields of the database table ltmap and the
corresponding data types that are created by the ltmap.install file.
tid
Primary identifier of the Tweet
created_at
Creation date of the Tweet
from_user
Author of the Tweet (nickname)
from_user_id
User ID of the Tweet’s author
from_user_name
Username of the Tweet’s author
text
Content of the Tweet
source
Source of the Tweet
geo
Geo data for the Tweet
lat
Latitude of the Tweet’s location
lon
Longitude of the Tweet’s location
iso_language_code
Language code of the Tweet
profile_image_url
Profile image URL of the Tweet’s author
to_user_id
User ID of the Tweet’s recipient
Table 3.3:Database fields and corresponding data types created by ltmap.install
Even if not all of the fields cited above are used by LTMap,the attempt was to store
as much data as possible,in order to be prepared for eventual future adaptations of the
application.
The LTMap module first of all tries to fetch the actual position of the user by using
HTML5 geolocation (see chapter 2.3.1),then it generates the map,centered on the
user’s actual position,using the Google Maps JavaScript API (see chapter 2.4.1),to
which the coordinates fetched by the geolocation are passed,and finally it displays the
social network data read from the corresponding plug-in(s).
The map displayed lets the user freely decide which type of map (satellite or map)
and which zoom level he wants to display.The application does in no way limit the
user from this point of view,it simply displays the Tweets inside the geographical area
chosen by the user.
The geolocation is intended to be as easy as possible and should happen nearly au-
tomatically (in the ideal case),the user only needs to confirm that the application can
25
3.4.3 Twitter Plug-In
access its position information.If the automatic geolocation should fail,the user is
provided with a field in which he can provide his address.
For the display of the data from the social networks,the module gives the user the
possibility to filter the displayed data according to a search filter,which will be described
in more detail in chapter 5.
We will not describe the source code of the LTMap module in detail,because the code
is well documented and therefore no additional description should be needed.
3.4.3 Twitter Plug-In
The Twitter plug-in is the first,and for the moment the main and only,plug-in for the
LTMap module.
Its purpose is to read the public stream provided by Twitter and format it correctly
for the LTMap module to be able to display the data on the map.
Please note that the use of “plug-in” is not related to the module structure of Drupal,
it has been chosen as a name for the social network extensions which can be added
(or “plugged in”) to the LTMap module to read the data from the corresponding social
network.
The plugin consists of a single file,twitter.php,located in the plugins folder inside
of the module folder.
The plugin does not display data directly,and the user has no direct interaction with
it,it does “only” get the Tweet data from Twitter and sends it to the LTMap module.
As with the module file,we will not describe the code of the Twitter plug-in,because
the code is already well documented.
3.5 Technologies
In this chapter we will describe the main technologies used for the development of
LTMap.
3.5.1 PHP
The LTMap module,as well as Drupal itself,are programmed in PHP.
PHP is a very rich scripting language allowing a very good and fluid interaction with
SQL,therefore it fitted the needs of this project optimally.
In addition,the author had already used PHP for different personal,university and
work projects,which allowed to acquire a good background experience,being a great
advantage for the development of this project.
3.5.2 CSS
The layout of the application,and also of the CMS in general has been personalized
through the use of CSS.
26
3.5.3 JavaScript
The common practice of using external CSS files was adopted,in order to have a
cleaner overall structure and,more over all,to be able to use the same rules in all
involved files,without needing to repeat them in each file.
As with PHP,CSS was already used in many previous projects by the author,therefore
a very good background knowledge was already available,which facilitated the design
and development process.
3.5.3 JavaScript
JavaScript was used mainly for the Google Maps part of the application,but it was
used also for the filtering process and some additional features,like for example the
display of the address field and the corresponding search button when the automatic
geolocation does not work properly (due to missing permission in the user’s browser
or communication problems).Additionally,JavaScript was used to do Asynchronous
JavaScript And XML (AJAX) calls to external,Drupal related files.
Where JavaScript was used for custom purposes,the framework jQuery [The12] was
used to enhance and simplify the use of JavaScript through its built in functions for
loops,recovery of HTML elements,calculations,etc.
Like with CSS,the used functions are stored in external files,in order to reuse them
in the whole project,without having to rewrite them in each single file.
As with PHP and CSS,JavaScript and jQuery were already used for various projects
by the author,so there was already a good background knowledge.
3.5.4 SQL
The database used by the CMS and by the LTMap module is based on the database
language SQL.
SQL is a good choice for applications of this type,as it is quite fast (for smaller
datasets like the ones used in this project) and still simple to use.
As with the other techonologies used,the author had already good background knowl-
egde of SQL,which simplified the development process.
To enhance the working experience with the databases,Adminer [Vrá12] was preferred
upon phpMyAdmin [php12] due to its optimal structure (a single,lightweight PHP file
without the need of any installation) and its very intuitive and complete Graphical User
Interface (GUI).
3.6 Used software
For the development of LTMap,and for the writing of this thesis,the following software
was used:
• For editing the PHP,CSS and JavaScript files,Sublime Text 2 [Sub12] and Note-
pad++ [Ho11] were used.
27
3.6 Used software
• To test the prototype of LTMap locally on the PC,XAMPP [Sei12] was used to
install an Apache webserver and a MySQL server (additionally,the prototype was
also tested directly on the hosting of the author).
• This thesis was written in L
A
T
E
X2
ε
,with the support of [OPHS11];for the writing
of the thesis,LEd [DS09] was used;the bibliography was generated automatically
using BibTeX [Fed06] and the list of acronyms was generated using the nomencl
package [VS05].
• For the management of the used litarature,JabRef [Jab12] was used.
28
4 Implementation of LTMap
4 Implementation of LTMap
4.1 Introduction
This chapter allows the reader to look behind the curtains of LTMap,by explaining its
implementation and how its single functions work exactly.
Although this chapter is only an addition to the comments present in the sourcecode,
which are already quite exhaustive,the implementation of LTMap will be described with
as much details as possible,in order to allow the reader to better understand its features.
Before explaining the implementation of the different features of LTMap,its underlying
architecture will be outlined in the next section.
4.2 Architecture of LTMap
In this section,we will describe the architecture of LTMap in some more details.You
can see an overview of the architecture in figure 4.1.
Figure 4.1:Architecture of LTMap
The LTMap application is built with the components described in the previous chapter
(see chapter 3.4),which are interconnected in the following way:the Drupal CMS is the
29
4.3 LTMap Module
foundation of the application,into which the LTMap module and its social network
plug-ins are integrated,the social network plug-ins receive data from the APIs of the
corresponding social networks and store it in the database (DB),this data is then fetched
by the LTMap module and diplayed on the corresponding map (using Google Maps for
the map display and HTML5 geolocation to fetch the position of the user).
Dashed arrows in figure 4.1 represent interactions with external services,while plain
arrows represent internal interactions.Gray elements (additional social networks and
their corresponding plug-ins) are not integrated into LTMap yet and will be implemented
in future improvements.
The Twitter plugin uses the following data extracted from the fetched Tweets:
• Author:the author of the Tweet.
• Text:the actual text of the Tweet.
• Date:the date at which the Tweet was posted.
• Coordinates:the geographical coordinates of the Tweet.
The author,text and date are displayed on the map inside an infowindow for each
Tweet,toghether with the date of the Tweet.The coordinates are used to display the
Tweets in their corresponding position on the map.
Tweets without geolocation data are filtered out,as they would not allow to be placed
on the map.
4.3 LTMap Module
The LTMap module uses the standard structure of a Drupal 7 module and accesses dif-
ferent hook functions of the Drupal core to execute the needed functionalities [Buy12d].
The different functions have the following purposes:
• ltmap_help:displays a short help text on the module’s help page;
• ltmap_enable:used when the module is enabled,to detect if the database
schema,available in the ltmap.install file (see chapter 3.4.2),must be installed
or not;
• ltmap_menu:used to create the administrative menu item to configure the
module;
• ltmap_form:used to generate the configuration form for the module’s configu-
ration page;
• ltmap_cron:this function is called periodically,when a Drupal cron run happens
[Buy12c];it is used to retrieve new Tweets each time a user visits the homepage;
• ltmap_block_info:used to declare the blocks used by the LTMap module and
optional block configurations (see [Buy12a] for a complete list of available config-
urations);
30
4.3.1 Configuration Page
• ltmap_block_view:returns the actual content of the block [Buy12b].
The following functions are located in the twitter.php plug-in and are needed to
load and store Tweets:
• ltmap_save_tweets:customfunction which goes through each newfound Tweet
and checks if it is already stored in the database,if not,it is added by calling
ltmap_save_tweet;
• ltmap_get_tweets:custom function used to fetch new Tweets in the JSON for-
mat via the PHP Client URL (cURL) library and convert them into PHP objects;
• ltmap_save_tweet:customfunction used to store a new Tweet in the database;
• ltmap_load_tweets:custom function used to load all Tweets stored in the
database.
In the next subsections,we will look in more detail at the module’s configuration page
and the process of fetching,storing and displaying the Tweets,and also at the functions
executed to carry out these tasks.
4.3.1 Configuration Page
The configuration page is generated through the two functions ltmap_menu (allow-
ing to access the corresponding menu item under admin/config/content/ltmap) and
ltmap_form (generating the configuration form).
The function ltmap_menu places the configuration page of LTMap under “Configura-
tion” » “Content authoring” » “LTMap” by defining the path admin/config/content/
ltmap.
It also defines the title of the configuration page (“LTMap”) and gives a short descrip-
tion for the overview pages (admin/config and admin/config/content).
For the page callback of the configuration page,the standard callback drupal_get_form
is used.
To access the configuration page,the privilege “access administration pages” is needed.
The arguments are defined in the function ltmap_form,which contains three form
fields:
• ltmap_cron_key:a textfield for storing the cron key of Drupal;
• ltmap_gmap_key:a textfield for storing the Google Maps API key;
• ltmap_max:a textfield for storing the maximum number of Tweets to display
in the LTMap block (defaults to 100);
• ltmap_twitter_app:a field of type “item”,which contains a link to the page
for creating a new Twitter application.
31
4.3.2 Fetching new Tweets
4.3.2 Fetching new Tweets
New Tweets are fetched each time a visitor interacts with the map (see chapter 4.4.5 for
more details),by calling the cron function ltmap_cron.
This function first of all does a SQL query to determine the ID of the last stored
Tweet,then it generates a Twitter search URL containing the location of the user,a
search radius around his position,the desired number of results and the ID of the last
Tweet (in order to assign it to the since_id parameter of the search string,used to
avoid searching for Tweets already stored in the database).
The URL generated above is then passed to the function ltmap_save_tweets (see
chapter 4.3.3).
4.3.3 Storing new Tweets
The function ltmap_save_tweets,which stores new Tweets in the database,uses the
search string generated through ltmap_cron and passes it to the function ltmap_get_
tweets to recover the latest Tweets.
The function ltmap_get_tweets then uses cURL to read the page with the results
fromthe search string and converts the results into a PHP object,which is then returned
to ltmap_save_tweets.
For each Tweet found,ltmap_save_tweets checks if it is not a duplicate already
existing in the database (as a double check to avoid duplicate content),and if it is a new
one it is passed to the function ltmap_save_tweet.
The function ltmap_save_tweet takes the data from each single Tweet and stores it
in the database,provided that it contains geolocation data.If this should not be the
case (and therefore the Tweet could not be displayed with a precise position on the map)
the Tweet is discarded.
4.3.4 Displaying all Tweets
The Tweets stored in the database are displayed using the function ltmap_load_tweets,
which simply executes a SQL query to load the stored Tweets and return an array
containing all of them.
4.4 JavaScript Functions
In order to make everything work properly,some helper functions in JavaScript have
been added to the LTMap module,inside the file main.js.
These functions initialize the map with the needed options,manage the geolocation
and the alternative manual address field,calculate the radius for the Tweets to display
based on the visible portion of the map and manage the markers and overlays connected
to the single Tweets.
We will look in more detail at each of these functions in the next subsections.
32
4.4.1 Map Display
4.4.1 Map Display
The map display is handled by Google Maps,by executing the line
map = new google.maps.Map(document.getElementById("map_canvas"),
myOptions);
in the initialize function.This command generates a new map,using the options
concerning the map’s zoom and type,defined in the array myOptions.
The array myOptions defines the default zoom level and map type and deactivates
scrollwheel zooming and the StreetView control.
4.4.2 Geolocation
The geolocation is handled by the HTML5 geolocation function and interacts with the
map in the conditional if(navigator.geolocation) {...}.
First of all,a check is performed if geolocation is supported by the browser.
If it is supported,the user’s position is stored in two hidden fields on the website (one
for the longitude and one for the latitude) and the map is centered on this position.
If it is not supported,the function handleNoGeolocation is executed,which displays
an error message and a field allowing the user to manually enter his address (with an
autocomplete function to support him).There are two possible error messages displayed
to the user,depending on whether the geolocation is simply not working at the moment,
or if it is not supported by the browser.
After the user has compiled the text field for a manual search of his address,the func-
tion codeAddress is executed,which checks if the address is valid and uses the Google
Maps geocoder to transform the textual address entered by the user into coordinates
that can be displayed on the map.
4.4.3 Tweet Radius
To optimize the loading of Tweets,the search string generated by the LTMap module
(see chapter 4.3.2) uses the radius parameter to limit the fetched Tweets inside a given
search radius.This radius is calculated by the function getRadius (calculations adapted
from [Mer07]).
The function getRadius determines the position of the center and one of the corners
(the South-West one),converts their coordinates into radians and calculates the distance
between them by using the great circle distance formula (see equation (4.1)) [Mer07].
d = earthR∙ arccos[sin(centerLat) ∙ sin(cornerLat)+
cos(centerLat) ∙ cos(cornerLat) ∙ cos(cornerLon −centerLon)]
(4.1)
This formula returns the radius of a hypothetic circle that encloses the visible map
portion.This is done to limit loading times and optimize Tweet visualization when
fetching new Tweets:if each time we would load all new Tweets since the last update,
33
4.4.4 Tweet Display
this would eventually make the system very slow (depending on the time lapse between
two updates);on the other hand,if we load only n Tweets (let’s say 100,for example)
but they are not necessarily located around the visible portion of the map,there will be
only few possibilities that a visitor will see new Tweets for his geographic region.
4.4.4 Tweet Display
The display of Tweets is handled by the function display_tweets,executed after each
update of the map,just after the cron run of the Module (see chapter 4.3.2).
The function display_tweets receives the existing Tweets (stored in the database)
fromthe cron run and loops through each of them(until the maximumnumber of Tweets
to display is reached) to check if it is inside the map boundaries actually displayed.If
this is the case the Tweet is added to the map (the corresponding marker and infowindow
are generated) and to the Tweet list (using the same HTML content as in the infowindow
for maintaining a coherent user interface).
The function is also responsible for displaying the information in the “Map info”
section and the filters in the “Actions” section.
In order to allow the dynamic loading of the author’s Twitter profile and of the “Re-
ply”,“Retweet” and “Favorite” pages,Twitter’s intents [Twi12h] are used.For this
the file widgets.js is included by the module and special links are generated by the
display_tweets function.The rest is managed dynamically by Twitter.
4.4.5 Map Update
Among the JavaScript functions described,there is also a listener which checks for the
“idle” event and is executed each time a visitor interacts with the map (moving,zooming,
etc.).
The listener is deactivated when an infowindow is opened,allowing the user to move
the map and read eventual hidden parts of the infowindow.
When an interaction with the map is detected,the listener calculates the new radius
of the visible portion,stores the new position and executes an AJAX call to the file
cron.php,responsible for executing all cron calls of Drupal,including our function
ltmap_cron (see chapter 4.3.2).After successful execution of the AJAX call,the Tweets
are displayed on the map.
4.4.6 Other functions
There are other,minor JavaScript functions responsible for listening to specific events,
like for example the submission of the address field if the geolocation does not work,
the submission of the “Go to address” field in the “Actions” section,the submission of
the “Filter results” field and the click on the “Clear” buttons (all the above take into
consideration both the click on the “Submit” or “Clear” button and the pressing of the
“Enter” key on the keyboard while inside the corresponding textfield).
34
5 Operation instructions
5 Operation instructions
5.1 Introduction
One of the main goals of this thesis was to create an easy to use and intuitive application.
The purpose of this chapter is to explain the operation of LTMap with as many
details as possible,although its operation is very intuitive and well explained inside the
application itself.
First of all,the installation of the module will be explained,then the interaction with
the single user interface elements (such as the map,the Tweets and the available filters)
will be explained.
5.2 Installation
In order to install the LTMap module you need to have a working Drupal 7 system,with
admininstrative access to it and access to the FTP server where it is installed.
In order to make the LTMap module work properly,you also need a valid Google Maps
API key associated to your Google account (you can get one by following the instructions
on [Goo12d],please take care that you activate an API key for the “Google Maps API
v3 service”).Additionally,you need to create a Twitter application (see [Twi12a]) with
your Twitter account.
To install the LTMap module you need to take the following steps:
• Download the module fromhttp://ltm.aronmartinez.com/ltmap-7.x-1.x-dev.
zip (.zip archive) or http://ltm.aronmartinez.com/ltmap-7.x-1.x-dev.tar.
gz (.tar.gz archive);
• Extract the downloaded archive and copy the resulting folder ltmap to the modules
folder of your Drupal 7 installation (which is located under sites/all/modules);
• Go to the Modules administration page of your Drupal installation (under www.
yoursite.com/admin/modules),open the module group “AM”,enable the LTMap
module and save your configuration (see figure 5.1);
• Still on the Modules administration page,next to the LTMap module,click on
the “Configure” link and on the module configuration page (see figure 5.2) insert
your Drupal cron key (which can be found in the Status report page,under “Cron
maintenance tasks”),your Google Maps API key and the maximum number of
Tweets you want to display in the LTMap block;additionally,if you have not
35
5.3 LTMap User Interface
done it already,you can click on the “Create Twitter application” link to access
Twitter’s page for creating a new application;
• Go to the Blocks administration page (under www.yoursite.com/admin/structure/
block) and search the block named LTMap under the “Disabled” group;
• Click on the “configure” link next to the LTMap block and configure it according
to your needs (you can,for example,choose to display it on you front page by
assigning it to the “Content” region of your theme and assign the value <front>
to the “Only the listed pages” option in the “Pages” tab;
• Go to the corresponding page and check if the block is showing correctly.
Figure 5.1:Activation of the LTMap module
5.3 LTMap User Interface
The LTMap user interface is composed of the following elements (see figure 5.3):
• Map area:the interactive map of LTMap,with the Tweets found in the corre-
sponding area displayed as markers;
• Infos:some information about the displayed map and Tweets;
• Actions:the available actions for the map and the display of items;
• Items:the items (for the moment only Tweets) found in the selected area of the
map.
5.3.1 The Map
When the page containing the LTMap block is loaded the first time,the visitor’s browser
will ask him if he wants to allow the computer to share the actual location (see figure
3.1,in chapter 3.2.1,for an example).
If the visitor accepts to share his location,the map will automatically be centered on
the visitor’s position (this will also automatically be done for future visits,depending
on the browser settings).
36
5.3.1 The Map
Figure 5.2:Configuration of the LTMap module
If the visitor denies the request to share his location,an error message is displayed
and a text field,allowing him to enter his address manually,is displayed below the map.
While the map and Tweets are loading,an animated loader image is displayed on top
of the map,in order to make it clear to the visitor that the system is running in the
background.
The Tweets are represented as standard Google Maps markers on the map.When a
visitor passes over one of the markers with the mouse,the Twitter username of its author
appears.By clicking on the marker,instead,an infowindow opens,which displays all
information related to the Tweet (see figure 5.4).
Inside the Infowindow you find the following information:
• Profile picture:the author’s profile picture,linked to the corresponding Twitter
profile;
• Author name:the full name of the author (e.g.Aron Martinez),linked to the
corresponding Twitter profile;
• User name:the “@username” of the author;
• Text:the text of the Tweet,with its mentions,hashtags and links;
• Date:the publish date of the Tweet;
• Reply:a link to directly reply to the Tweet;
37
5.3.2 Infos
Figure 5.3:UI of LTMap
• Retweet:a link to directly retweet the Tweet;
• Favorite:a link to directly set the Tweet as favorite;
• Twitter icon:a Twitter icon to immediately distinguish an itemas a Tweet when
additional social networks will be added in the future;
• Close button (x):a button to close the infowindow.
5.3.2 Infos
The “Map info” box below the map,on the left side,displays some information to the
visitor.These include the radius displayed on the map (which is also used in the request