Click to enlarge!

There are a lot of Wikipedia visualizations. Some concentrate on article contents, others on the links between articles and some use the geocoded content (like in my previous blog post).

This new visualization is novel because it uses the geographical content of Wikipedia in conjunction with the links between articles. In other words, if a geocoded article (that is, an article associated with a location like a city) links to another geocoded article, a line will be drawn between these two points. The result can be found on the map on the left.

Read on for zoomed views, slideshows, browsable maps, etc.

Methodology

Scroll down to see the slideshows, pretty pictures and interactive maps.

Click to enlarge!

The first thing I had to do was to extract the geographical data included in the articles and the links between the articles. Instead of parsing the very complicated Wikipedia markup, I chose to use the good work done by the folks at GeoNames. In the download section, there a SQL file with the name of every geocoded Wikipedia article. Then, I downloaded all English articles in Wikipedia (9GB compressed, about 40GB uncompressed) and used a bit of Regex magic to extract reentrant links (that is, hyperlinks that link to geocoded articles). After these steps, I was left with two datasets: a list of all geocoded articles and a list of all links between articles.

To draw the map, I used the same technology I developed for my map of scientific collaborations. I had to adjust the tool to add features like other geographical projections (the Mercator projection, while simple, makes Greenland seems as large as Africa), linear transformations, etc. The datasets computed in the previous steps were then parsed and drawn by my mapping tool. I then played with the colors in Photoshop to convert the outputted grayscale map to color. To build the browsable and overlay maps, I used the fantastic MapTiller tool. By the way, the input projection for this tool is Equidistant Cylindrical – knowing this would have saved me a lot of time!

Slideshow

This slideshow contains zoomed parts of the map of different countries, continents and regions. Click on a picture to enlarge it. Browse to the bottom of this blog post to download the full size map (200M pixels – 18MB JPEG file).

Browsable Map

This map is projected using a Robinson projection; it is a “compromise” projection meaning that while it doesn’t resolve all the problems found in many projections, it minimizes most distortions.

Click here to open this map in a new window

Google Map Overlay

Like the title suggests, this map is overlaid onto a Google Map so that cities, countries and other landmarks can be easily situated. Obviously, populated areas contain a lot of Wikipedia articles.

Click here to open this map in a new window

Data & High Resolution Files

You can download an high resolution file of the map here. It’s quite big at 200M pixels. It’s a 18MB JPEG file and could crash your browser; even more so if you are using a smartphone. I also have a 1.7G pixels file, but it is too large to host here, so let me know if you need it. It uses the Equidistant Cylindrical projection, not the Robinson one like the other high resolution file.

The input dataset (30MB compressed, around 95MB uncompressed) can be downloaded here, the fields should be self-explanatory.

The drawing tool will be eventually open sourced, but I need time to clean it up.

Mountains, peaks, summits, etc.

A large number of Wikipedia articles are geocoded. This means that when an article pertains to a location, its latitude and longitude are linked to the article. As you can imagine, this can be useful to generate insightful and eye-catching infographics. A while ago, a team at Oxford built this magnificent tool to illustrate the language boundaries in Wikipedia articles. This led me to wonder if it would be possible to extract the different topics in Wikipedia.

This is exactly what I managed to do in the past few days. I downloaded all of Wikipedia, extracted 300 different topics using a powerful clustering algorithm, projected all the geocoded articles on a map and highlighted the different clusters (or topics) in red. The results were much more interesting than I thought. For example, the map on the left shows all the articles related to mountains, peaks, summits, etc. in red on a blue base map.  The highlighted articles from this topic match the main mountain ranges exactly.

Read on for more details, pretty pictures and slideshows.

A bit about the process

You can skip this section if you don’t really care about the nitty-gritty of the production of the maps. Scroll down to get to the slideshows.

Getting the data

Trains, stations, platforms, railways, etc.

The first the step to create these map was to retrieve all Wikipedia articles. There are 1.5 million of them and only a portion (400,000) are geocoded, but this doesn’t matter, because it’s an all or nothing deal: everything must be downloaded. I had to download the raw data from this page. It’s quite a large download at 9GB compressed and it expands to about 40GB once it is uncompressed. I then parsed this very large file to extract the article content, links and geographical coordinates.

Identifying topics

Islands, coasts, beaches, oceans, etc.

To extract topics from this huge corpus, I used Latent Dirichlet Allocation. This algorithm can extract a given number of topics from a large corpus. Usually the optimal number of topics can be inferred from the likelihood values over several topic runs. However, in this case, since the corpus is very large and each run is very time consuming (50 hours on the most powerful AWS cluster instance), I chose a number relying on an educated guess and my LDA experience.

I ran the LDA algorithm using Yahoo’s LDA implementation since it’s quite fast and can be parallelized. After 50 hours, I got 300 different topics linked to 1.5 million articles, but because only 400,000 of them are geocoded, the rest of this post only pertains to these 400,000. You can download the topic descriptions here. The topics are very varied and range from geographical regions, ethnic groups, science, sports (including both kinds of football!), historical sites and even archeological dig sites.

Drawing the maps

Archaeological, stone, site, ancient, remains, bronze, etc.

The maps were generated from an array of tools ranging from standard Unix utilities to custom developed tools in Python and Java. The previous steps provided me with two datasets, the first one was the geographical coordinates of all Wikipedia articles and the second was a linking table between the topics and the articles.

From there, using a custom tool, I mapped all the points using the Robinson projection. A map with all the articles was rendered in shades of blue and would serve as a base map.

Next, I generated 300 different datasets and rendered the same number of maps where the articles were in red; these were the topic maps. I then overlaid all these maps onto the base map using ImageMagick and added a caption at the bottom of each map to identify each topic.

You can download all the maps in high-resolution (18M pixels – 3MB per map – 900MB total) here.

Interesting Topics

This slideshow illustrates the interesting topics that I found while checking the finalized maps. Most of these maps are not related to political boundaries, but to subjects that are geographically interesting.

For example, all articles relating to football, climate, music, royal dynasties, naval bases, religions, etc. are highlighted. You can click on the maps to enlarge them and read the captions describing the highlighted articles.

Geographical, Colonial and Ethnic Boundaries

In this slideshow, you can see all the maps with strong geographical topics. Since geography is never far from history, a lot of maps show the colonial past of many countries. As ethnic groups don’t always fall inside political borders, several maps reveal the presence of multiple ethnic or cultural groups within a country or of groups stretching across borders. Other maps show old empires like the Ottoman, Roman or Persian empires.

Open Data

You can download the geocoded data here. This file includes the topic id, the probability of the article to belong this topic, an internal id, the name of the article, it’s latitude and longitude, and the pagerank of the article.

The raw LDA (including non-geocoded articles) is really massive. If you want it, post a comment (or contact me by email) and I’ll upload it.

Cette fusion entre l’informatique et la radio est connue comme la “Software Defined Radio”, ou la radio définie par logiciel. En d’autres mots, des codes informatiques font le travail qui était auparavant effectué par des circuits spécialisés. Il devient donc possible de décoder des contenus seulement accessibles à certains spécialistes ou à l’aide équipement très dispendieux. Ces contenus incluent les informations émises par les avions, comme le ADS-B. Autrement dit, il devient possible de recevoir la localisation des avions de lignes en temps réel .

Afin de capter ces signaux, il faut installer gnuradio. Ce logiciel, ou plutôt cet ensemble de logiciels est disponible pour Mac, Windows et Linux. J’utilise Ubuntu, une distribution de Linux, pour capter ces signaux, mais il existe plusieurs guides et tutoriels qui permettent d’utiliser le RTL-SDR. Sous Linux, un script permet de faire tout le travail d’un coup (situé sur ce site). Une liste des distributeurs où l’on peut acheter les RTL-SDR est disponible ici.

Une fois le code lancé, celui-ci compile et installe les logiciels nécessaires. Il suffit ensuite de lancer le logiciel (et la clé USB et l’antenne connectée):

modes_rx -d -l "45.5081,-73.555" -K planes.kml

Ce logiciel capte les informations diffusées par les avions, puis les envoient directement dans un fichier de type Google Earth. En ouvrant le fichier planes.xml dans Google Earth, on peut observer la position, l’altitude ainsi que la vitesse des avions.
La capture d’écran à droite montre qu’il est aussi possible d’observer la prise d’altitude des avions. Dans la même capture d’écran, la flèche indique que l’avion était à une altitude de 1 586 mètres lorsqu’elle survolait Saint-Léonard. Si vous n’avez pas l’équipement nécessaire, vous pouvez télécharger le fichier créé par modes_rx en cliquant ici. La carte Google Maps qui suit contient les mêmes données, mais elle ne permet pas de visualiser en 3D l’altitude des avions.

Cliquer pour ouvrir dans Google Maps

Ce n’est pas tout. En plus de pouvoir capter les émetteurs ADS-B des avions, il est possible de capter les conversations de tous les professionnels qui utilisent des radioémetteurs comme les corps policiers, la voirie, les chauffeurs de taxi et autres. Sur la capture d’écran à gauche, chaque ligne verticale rouge (sur le fond vert) est un canal. Certains canaux sont digitaux (et/ou encryptés), alors un équipement (ou logiciel, comme OP25) est nécessaire pour faire la conversion.

Les cellulaires et la plupart des équipements modernes communiquent à l’aide de protocoles encryptés, mais certains vieux standards ne sont pas encryptés comme le FLEX/POSCAG des pagettes. Avec le bon logiciel (PDW), il est possible de décoder les signaux des pagettes. La capture d’écran à droite montre le logiciel en pleine action. Le logiciel utilisé avec PDW est SDR# (prononcez SDR-Sharp), un des logiciels les plus conviviaux pour explorer les ondes.

Il est également possible de garder un oeil, ou plutôt une oreille, sur les radioamateurs. En effet, ceux-ci communiquent une foule d’information à l’aide du protocole APRS sur la fréquence 144.390 MHz. En utilisant un décodeur (inclus dans GQRX), il est possible de décrypter les communications:

14:12:53$ fm VA3RU-0 to APT311-0 via VE3IWJ-0,VE2PCQ-3,WIDE2-0 UI  PID=F0
          /111912z4442.11N/07531.88Wv241/000/A=000223
14:13:35$ fm VE2DNG-9 to APRS-0 via VE2CSN-3,VE2PCQ-3,WIDE2-1 UI^ PID=F0
          $GPGGA,191325,4545.9657,N,07229.4721,W,1,09,0.8,140.0,M,-31.6,M,,/GPS FIX
14:13:47$ fm VE2AH-1 to APFD57-0 via VE2PCQ-3,WIDE2-1 UI^ PID=F0
          @111913z4600.22N/07220.38W_112/000g000t037r023P000p000h63b10265WX au centre du Quebec {UIV32N}
14:14:01$ fm VE2CSN-9 to EFFR9Q-0 via VE2CSN-3,VE2PCQ-3,WIDE2-0 UIv PID=F0
          `d9]l"%>/]73 De Jean
14:14:35$ fm VE2SE-3 to APJI23-0 via VE2PCQ-3 UI  PID=F0
          }VE2PUI>API880,TCPIP,VE2SE-3*:/111914z2819.67N/08242.15Wk038/000/
14:14:46$ fm VE2FET-1 to APU25N-0 via VE2PCQ-3,WIDE2-1,QC2-1 UI^ PID=F0
          >111914zDX: VE2RTA-3 45.17.36N 72.38.26W 133.0km 118. 14:10
14:15:07$ fm VE2CSN-9 to EFFR7U-0 via VE2RAW-3,WIDE1-0,VE2PCQ-3,WIDE2-0 UIv PID=F0
          `d9omr0>/]"4h}73 De Jean
14:15:12$ fm VE2USL-14 to T5RR7U-0 via VE2FET-1,VE2PCQ-3,WIDE2-0 UIv PID=F0
          `eU/l]@v/`"4V} QSO SUR VE2PCQ 73 de Stephan_"
14:17:07$ fm VE2ROW-3 to APNU19-0 via VE2SBR-3,VE2PCQ-3,WIDE2-0 UI^ PID=F0
          !4646.20N107118.21W#PHG5560/W1,QCn Digi de Ste-Foy

Évidemment, ça ressemble à du chinois, mais les radioamateurs sont en mesure de lire ces informations et d’y extraire la position géographique des émetteurs ainsi que le contenu transféré.

Pour 20$ et un peu de temps, il est maintenant possible d’avoir accès aux ondes en utilisant des logiciels libres (ou du moins gratuits). Cette démocratisation du “Software Defined Radio” engendra sans aucun doute plusieurs nouvelles techniques, algorithmes et découvertes.

To resolve this problem and enable the importation of old responses tables, I’ve written a quick Python script. It uses MySQLdb, but that library should be installed by default on most Linux boxes. The script also requires a MySQL database backend but it should be easily adaptable to other database engines.

Before running the script, four variables must be configured:

dbaddr='127.0.0.1' #localhost
dbuser='username' #user name used to access the limesurvey tables
dbpass='password' #password used to access the limesurvey tables
dbdb='limesurveyDB' #limesurvey's database name

After configuring these settings, you should be able to launch the script. Launching the script with the –help switch will print out the usage help:

python importOldAnswers.py --help
usage: importOldAnswers.py [-h] [--list SID] [--copy TABLENAME SID]

Import old results in current answer table

optional arguments:
  -h, --help            show this help message and exit
  --list SID            list old result table for a given SID
  --copy TABLENAME SID  copy old table to a new result table

Using the script with the –list SID argument will list all the old result tables for a given survey id (SID):

python importOldAnswers.py --list 15946
lime_old_survey_15946_20120124220544
lime_old_survey_15946_20120130222036
lime_old_survey_15946_20120304201731
lime_old_survey_15946_20120703192749
lime_old_survey_15946_20130304201731

From there, you can choose an old result source table to import into an existing response table:

python importOldAnswers.py --copy lime_old_survey_15946_20130304201731 15946
Copying table lime_old_survey_15946_20130304201731 to lime_survey_15946
Retrieve headers
Number of columns in source table: 228
Number of columns in target table: 229
Number of columns in merged table: 228
Number of answers in source table: 2
Done copying

Now for the caveats: the script will not convert from a data type to another, it will not truncate data and it will not do any form of sanity check before inserting data. Never use on a production database, always work with a copy. If you find a bug, please let me know. I’ve released the code with a GPL license, but if that causes a problem let me know. If you know me in real life and you find that script useful, you can always buy me a beer!

You can download the code here, or copy and paste the following listing:

__author__ = 'Olivier H. Beauchesne'
__license__ = 'GPL'
__version__ = '0.1'
__email__ = 'olivier@olihb.com'

import sys
import MySQLdb as mysql
import argparse

#database settings
dbaddr='127.0.0.1' #localhost
dbuser='username' #user name used to access the limesurvey tables
dbpass='password' #password used to access the limesurvey tables
dbdb='limesurveyDB' #limesurvey's database name

#this should not change if using limesurvey's defaults
TablePrefix='lime_survey_'
OldTablePrefix="lime_old_survey_"

def getHeaders(table):
    cursor = db.cursor()
    sql = "SELECT * FROM %s" % table
    cursor.execute(sql)
    desc = cursor.description
    header = []
    for i in desc:
        header.append(i[0])
    return header

def buildResultMap(table, headers):
    cursor = db.cursor()
    sql = "SELECT * FROM %s" % table
    cursor.execute(sql)
    data = cursor.fetchall()
    m = dict()
    for h in headers:
        m[h]=[]
    for d in data:
        for i in range(0,len(d)):
            header = headers[i]
            m[header].append(d[i])
    return m

def getOldTables(sid):
    cursor = db.cursor()
    sql = "SHOW TABLES"
    cursor.execute(sql)
    data = cursor.fetchall()
    tableList = map(lambda x:x[0],data)
    return filter(lambda x: x.count(str(sid)) and x!=TablePrefix+str(sid),tableList)

def mergeHeaders(table1,table2):
    return filter(lambda x: x in table2,table1)

def insertNewData(header, results,tableName):
    numItems = len(results['id'])
    print "Number of answers in source table: "+str(numItems)
    header.remove('id')
    cursor = db.cursor()
    columns = ",".join(header)
    for i in range(0,numItems):
        columnsValues =  map(lambda x: results[x][i],header)
        format_strings = ','.join(['%s'] * len(header))
        cursor.execute("INSERT INTO "+tableName+" ("+columns+") VALUES (%s)" % format_strings, tuple(columnsValues))

def main():
    global db

    #argument parsing
    parser = argparse.ArgumentParser(description='Import old results in current answer table')
    parser.add_argument('--list',type=int, help="list old result table for a given SID",nargs=1,metavar='SID')
    parser.add_argument('--copy',type=str, help="copy old table to a new result table", nargs=2, metavar=('TABLENAME','SID'))

    #exit if empty
    args=parser.parse_args()
    if len(sys.argv)==1:
        parser.print_help()
        sys.exit(1)

    #connect to db
    db=mysql.connect(host=dbaddr,user=dbuser,passwd=dbpass,db=dbdb)

    #show list
    if args.list:
        tables = getOldTables(args.list[0])
        for t in tables:
            print t

    #copy table
    if args.copy:

        #format table name
        sourceTable = args.copy[0]
        targetTable = TablePrefix+str(args.copy[1])
        print "Copying table "+sourceTable+" to "+targetTable

        #get headers
        print "Retrieve headers"
        headersSource = getHeaders(sourceTable)
        headersTarget = getHeaders(targetTable)
        mergedHeaders = mergeHeaders(headersSource,headersTarget)
        print "Number of columns in source table: "+str(len(headersSource))
        print "Number of columns in target table: "+str(len(headersTarget))
        print "Number of columns in merged table: "+str(len(mergedHeaders))

        #merge results
        resultSource = buildResultMap(sourceTable, headersSource)
        insertNewData(mergedHeaders,resultSource,targetTable)
        print "Done copying"

#entry point
if __name__ == '__main__':
    main()

Les analyses de contenu peuvent répondre à certaines de ces questions, mais pour répondre à la question « où sont-ils? », il faut soit procéder par sondage ou utiliser les données que Twitter nous offre si gentiment. Si les utilisateurs de Twitter activent la fonction de localisation, il est possible de savoir où le “twitteur” est situé. Il suffit ensuite d’importer les données dans un logiciel de visualisation géographique ou Google Tables pour obtenir une carte interactive.

Malheureusement, sur les 1,5 million de micromessages recueillis lors de la campagne, un faible nombre contient une position géographique, soit environ 7 000. C’est moins de 0,5 % des tweets publiés. Même s’il s’agit d’un faible nombre, il est possible d’en retirer des informations intéressantes, quoique probablement pas très significatives.

Cliquez ici pour ouvrir la carte dans nouvelle fenêtre

Tout de même, il est intéressant d’observer la localisation des points. Les micromessages tendent à être localisés dans les grands centres urbains comme Québec et Montréal. De plus, les tweets semblent suivre les autoroutes. Possiblement qu’il s’agissait de journalistes, politiciens ou divers apparatchik politiques. Certains publiaient même des tweets de Toronto, d’Ottawa, de Calgary et même de Paris!

Une autre observation (toujours intuitive, car les données ne se prêtent pas vraiment à une interprétation statistique rigoureuse) est la densité des points dans certains quartiers de Montréal. En effet, il semble y avoir une concentration de points dans les arrondissements du Plateau Mont-Royal, Rosemont et Villeray.

Comme cette population est souvent décrite comme jeune, branchée et politisée, cette observation semble cadrer avec cette logique.

Dans la ville de Québec, on peut observer une plus grande concentration dans la haute ville, probablement en raison de la proximité du parlement.

Il serait également intéressant de faire une analyse croisée entre la localisation des micromessages et le contenu de ceux-ci. Les analyses possibles sont seulement limitées par notre créativité et le temps. Comme le temps me manque, j’ai l’intention de mettre les données à la disposition de tous, mais en raison des multiples changements de licence des données de Twitter ces derniers temps, j’aime mieux attendre que la situation se calme avant de libérer les données, probablement d’ici quelques mois.

Le module le plus intéressant est celui analysant la teneur du message et détermine si le message est plutôt positif ou négatif. Ce module repose sur un modèle bayésien (même principe qu’un filtre de polluriels) qui détermine à l’aide d’un modèle entraîné au préalable sur un échantillon de tweets. Le modèle est ensuite appliqué sur l’ensemble des tweets au fur à mesure que les micromessages sont emmagasinés dans la base de données.

Évidemment, cette analyse n’est pas parfaite, car l’engin de classification ne comprend pas le message et utilise des fragments (mots, syllabes, groupes de mots, etc.) pour classifier le message. Ceci signifie que l’engin n’est pas en mesure de détecter le sarcasme ou n’importe quel contenu qui demande un certain contexte ou une forme d’inférence. Certaines études parlent d’un taux d’erreur de 20%. Néanmoins, l’analyse demeure intéressante. De plus, la recherche est très active et certains classificateurs sont plus performants et peuvent détecter et comprendre le sarcasme.

Les autres pages permettent d’afficher les utilisateurs les plus bavards, ceux qui sont le plus retweetés ainsi que les liens les plus populaires. C’est donc une façon facile et rapide pour déterminer qui et quoi est très populaire dans la dernière heure, journée, semaine ou mois.

Il est également possible d’extraire la structure des discussions entre les utilisateurs. En écrivant le nom d’un usager de Twitter, puis en attendant quelques secondes, le réseau d’interaction de l’usager s’affiche. L’utilisateur s’affiche au centre en bleu et ses interlocuteurs (soit les utilisateurs qui ont été mentionnés par lui) sont liés par des liens. Évidemment, le graphe complet pour la plupart des utilisateurs populaires est immense, alors nous avons dû limiter le nombre d’utilisateurs mentionnés à 25 et le niveau à trois. L’image à droite illustre très bien les niveaux.

Évidemment, cette petite plateforme d’analyse touche seulement à une petite partie des analyses possibles avec la montagne de données disponibles dans la base de données d’IndiceQuebec. Néanmoins, l’outil a su intéresser plusieurs médias québécois:

Article de Florent Daudens de Radio-Canada sur IndiceQuebec:
http://www.radio-canada.ca/sujet/elections-quebec-2012/2012/08/23/024-analyse-twitter-campagne.shtml

Reportage vidéo de Tristan Péloquin de Cyberpresse sur l’outil:
http://www.lapresse.ca/videos/201208/24/46-1-87-des-tweets-sur-legault-sont-negatifs.php/eba9e518ca134ffa9e5c7ab824c43f76

Interview à la radio de Radio-Canada de Québec avec Claude Bernatchez:
http://www.radio-canada.ca/emissions/premiere_heure/2011-2012/chronique.asp?idchronique=240056

Mention d’IndiceQuébec et analyse effectuée à l’aide des données de l’outil:
http://www.ledevoir.com/politique/quebec/358331/les-doigts-agiles-des-twitteurs-quebecois-ont-fait-leur-marque

Le Patrouilleur du Net, Dominic Arpin parle de nous:
http://www.985fm.ca/audioplayer.php?mp3=143275

Pierre-Olivier Fortin du Soleil parle d’IndiceQuebec:
http://www.lapresse.ca/le-soleil/dossiers/elections-quebecoises/201208/28/01-4569034-elections-20-28-aout-2012.php

Si vous avez vu d’autres mentions, faites-nous signe!

L’image à gauche est une analyse du premier débat à Radio-Canada. La deuxième image (cliquez sur Read more) traite des faces à faces diffusées au réseau TVA.

Cette deuxième infographie analyse sommairement les tweets publiés durant les faces à faces diffusés à TVA. Les #mots-clics les plus fréquents et utilisateurs les plus mentionnés (soit qu’ils ont été mentionnés, adressés ou retweetés) sont illustrés sur les infographies. Le contenu des retweets les plus populaires est également présent dans les deux infographies.

La journaliste Sophie-Hélène Lebeuf de Radio-Canada a écrit un article analysant le débat sous le point de vue des médias sociaux. Ces deux infographies ont servi de point de départ à notre discussion.

Vous pouvez consulter l’article à cette adresse:
http://www.radio-canada.ca/sujet/elections-quebec-2012/2012/08/30/002-debat-duels-twitter.shtml

C’est ce que j’ai fait. En cliquant sur l’image, vous devriez obtenir l’image agrandie. Sinon, en cliquant ici, vous pourrez télécharger une version vectorielle en haute-résolution.

J’ai également fait une petite étude sur l’évolution des sujets (extraits algorithmiquement) présents dans les tweets traitant de la grève. On remarque que certains sujets sont transitoires et d’autres plus permanents.

Afin d’illustrer l’évolution des sujets liés à la grève étudiante, j’ai utilisé la version gratuite et publique de Tableau. Un logiciel très intéressant, mais la version web est un peu lente. À l’aide du logiciel, j’ai conçu une petite infographie interactive illustrant l’évolution des sujets des tweets. Cliquez sur le lien suivant pour y accéder: http://public.tableausoftware.com/views/Sujets-GGI/volutiondessujets?:embed=y

Les graphiques suivants ont été extraits de la visualisation interactive. Elles illustrent les sujets les plus intéressants ainsi que leur évolution dans le temps. Notez qu’un tweet peut traiter de plusieurs sujets, alors les tweets ont été fractionnés soit un tweet qui traite de trois sujets sera distribué dans une proportion de 33 % pour chaque sujet.

La manifestation (ou l’émeute) à Victoriaville est très évidente dans le graphique suivant (cliquez sur l’image pour agrandir le graphique):
Le rejet de la première entente (suivant le congrès du PLQ à Victoriaville) ainsi que les votes de reconduction de grève sont clairement illustrés:

Le graphique suivant montre le nombre de tweets traitant de Line Beauchamp. Le nombre de tweets atteint son maximum à sa démission, puis baisse tout à coup:

La réaction à la loi 78 est évidente et extrêmement puissante. En fait, il s’agit du plus gros pic sur le graphique:

Ensuite, le mouvement des casseroles suit très rapidement:

L’analyse temporelle des sujets est très intéressante. Elle permet de suivre l’évolution du conflit dans la twittosphere et ainsi voir les changements brusques dans l’agenda médiatique. Pour moi, c’est extrêmement intéressant, d’autant plus que mon sujet de maîtrise traitait du pouvoir d’agenda-setting des blogues politiques au Québec. J’ai presque le goût de refaire l’exercice avec les médias sociaux une fois la crise terminée. Presque.

Données:
greve_v3_status.tsv: Fichier contenant un identifiant, le texte du tweet, le nom et le nickname de l’utilisateur
greve_v3_data.tsv: Fichier contenant un identifiant et la date de publication du tweet

L’infographie précédente caractérisait le contenu des tweets, celle-ci s’attarde plutôt à la structure des interactions entre les individus. Comme dans l’infographie précédente, un histogramme illustre le nombre de tweets publiés par jour selon différents mots-clics (soit tous les tweets, #manifencours et #casseroles). Il est important de mentionner que les histogrammes sont normalisés, c’est-à-dire que pour chaque histogramme, la valeur maximale est utilisée pour pondérer chaque graphe. Cette méthodologie permet d’illustrer efficacement les variations de chaque série.

Une version haute-résolution en format PDF est disponible ici.

La première étape a été de récupérer tous les tweets traitant de la grève (ou conflit étudiant, selon la nomenclature du jour). Pour ce faire, tous les tweets contenant les mots-clics #ggi, #manifencours, #casseroles et #non1625 ont téléchargés. En tout, plus de 400 000 tweets ont été téléchargés, mais après un travail de déduplication (certains tweets sont très semblables), un peu plus de 200 000 tweets uniques ont été identifiés.

Comme ces tweets sont une source d’information intéressante sur la grève et que seulement une portion des données ont été utilisées, les données sont disponibles gratuitement. Si vous utilisez ces données, veuillez mentionner la source de celles-ci (moi!).

Tweets bruts : contient un identifiant, la date de publication (parfois invalide, voir avec Twitter!), le type de contenu, le contenu, le nom de l’auteur, le nick de l’auteur ainsi que le lien permanent du tweet.

Mots-clics : contient les #hashtags inclus dans chaque tweet. L’identifiant est relié (join, en sql) à l’identifiant des tweets du premier fichier.

Destinataires : contient les @destinataires des tweets. Encore une fois, l’identifiant est lié à chaque tweet.

À l’aide des données téléchargées et nettoyées, un réseau identifiant les individus ainsi que leurs interactions a été construit. Un petit script a également été conçu afin d’identifier les destinataires des tweets des individus. Celui-ci permet de construire des réseaux contenant tous les individus et leurs conversations. Ce graphe contient plus de 21 000 nœuds (individus) et 55 000 liens pondérés (conversations distinctes) ou 235 000 liens unitaires (conversations totales).

Le fichier complet du graphe est disponible ici (le logiciel Gephi est nécessaire pour ouvrir le fichier). Contrairement aux données disponibles plus haut, le fichier contient les données à jour jusqu’au 28 mai 2012.

La taille des nœuds est proportionnelle à l’influence des individus (inférée à l’aide du nombre total de retweets qu’ils ont eus). La taille des liens est proportionnelle au nombre de conversations entre les deux individus.

La couleur de chaque nœud dépend de la communauté d’appartenance de celui-ci. La communauté est identifiée à l’aide d’un algorithme de groupement. Celui-ci permet de regrouper les nœuds (dans ce cas, les individus) qui communiquent ensemble (réciproquement ou non).

Des réseaux où seulement les individus les plus influents/présents sont téléchargeables ci-bas:

Tous les mots-clics : fichier pdf

#manifencours : fichier pdf ou fichier Gephi

#casseroles : fichier pdf ou fichier Gephi

J’ai donc conçu cette petite infographie à l’aide de tweets que j’ai capturés. J’ai utilisé les hashtags suivants pour intercepter les tweets ayant comme sujet la grève: #ggi #non1625 et #22mar.

Il est possible de télécharger une version PDF en haute résolution de cette infographie [en cliquant ici].

Une fois les tweets récupérés (+ de 23k), j’ai écrit des scripts afin d’extraire les #hashtags ainsi que les @destinataires. J’ai également effectué certaines manipulations afin de les intégrer dans une base de données relationnelle pour faciliter l’analyse. J’ai utilisé Microsoft SQL Server, mais seulement par habitude. Les données publiées sont en format TSV (Tab-separated values), alors MySQL ou PostgreSQL peuvent être utilisés sans problème.

Voici les fichiers contenant les tweets publiés:

greve_tweets: contient un identifiant, la date de publication, le type de contenu, le contenu, le nom de l’auteur, le nick de l’auteur ainsi que le lien permanent du tweet.

greve_hashtags: contient les #hashtags inclus dans chaque tweet. L’identifiant est relié (join, en sql) à l’identifiant des tweets du premier fichier.

greve_destinataires: contient les @destinataires des tweets. Encore une fois, l’identifiant est lié à chaque tweet.

Avec ces fichiers, il est possible de calculer des statistiques sur le débit, le sujet, les destinataires, etc. des tweets sur la grève étudiante.

Le graphique central est un réseau où les noeuds (ou points) représentent un tweet. La disposition des points dépend de la similarité entre chaque tweet. La similarité est calculée selon la distance d’appartenance d’un tweet à son sujet (cluster). Comme il s’agit d’un algorithme automatisé, il est fort probable que plusieurs tweets soient mal classés. De plus, l’algorithme a beaucoup plus de succès avec les textes plus longs et ayant un vocabulaire contrôlé. Néanmoins, je suis quand même assez satisfait du travail effectué par cet algorithme.

greve_clusters: contient l’identifiant, le groupement, la probabilité que ce tweet appartienne au groupement et les coordonnées cartésiennes du tweet.

fond_blanc_tweets_abr: fichier PDF contenant la carte des tweets avec les tweets abrégés.

fond_blanc_tweets: fichier PDF contenant la carte des tweets sans texte.

Les données ainsi que les graphiques sont publiés sous la licence Creative Commons – Attribution. En gros, ça veut dire que vous pouvez faire ce que vous voulez avec l’infographie ainsi que les données, tant que vous mentionnez la source et mon nom.

Merci à Julie Ratté, Maureen Hillman et Véronique Martel pour les idées et les corrections.

This time I wanted to design a much more detailed map, one that could help to make decisions or help understand scientific collaborations. The USA is a very interesting country because they fund science in such a massive way. Also, the United States is a land of contrasts where no two states are alike and this makes for interesting comparisons.

While designing the new map, I also wanted to stay away from normal indicators based on ratios and averages. Why? Because most indicators postulate that the system being measured is linear. A linear system is one where the distribution of values follows a normal (or a Gaussian) curve, like the distribution of people’s height in a population. A non-linear system would one where the number of values doesn’t follow a Gaussian curve, like the distribution of letters in the English language or the distribution of wealth (I think that the “1%” referenced by the Wall Street protestors is a good example of a non-linear distribution).

Scientific production and collaboration also tends to behave in this way; the relationship between the number of papers a country produces and the number of scientific collaborations is not the same for each country. It varies a lot.

Using a method developed by Katz (2000) and Archambault et al. (2011) , I calculated a model of scientific collaborations. Using this model, it is possible to compute the number of collaborations that a Metropolitan Statistical Area (or MSA) would be expected to have considering its scientific output. You can read the technical details in this PDF file from a presentation I gave at the 4S conference in Cleveland last November.

Caveat: In the case of MSAs, the model is almost linear (but not quite), but this is the exception. In the case of states, provinces, countries and even Canadian universities the relationship is non-linear.

To illustrate this complicated data set, I needed a simple, but intuitive way to present the data. A choropleth map turned out to be the most intuitive way. Granted, it is not as visually striking as my previous map, but it could convey much more information. To implement the viewer, I used a map provided by the US Census and imported it in Flex. I then used the svglib library to dynamically update the map.

While there is a lot of data available in the tool, it is very simple to use. The global MSA affinity to collaborate is available by clicking on the “View Global Map” button in the right-hand corner. The two radio buttons located next to that button modify how the data is presented on the map: one shows the map with the scale-free collaboration index, and the other one shows the data without a scale-free indicator.

At the bottom of the screen, the collaboration index of every collaborating pair (one MSA with another MSA) is available by clicking a MSA in the first list on the left. A collaboration index higher than one means that the two MSAs are collaborating more than expected considering their scientific output and inversely, a collaboration index lower than one indicates that the two MSAs are collaborating less than expected.

Furthermore, it is possible to characterize the collaborations between two MSAs by selecting a collaborating MSA in the second list. The number of articles (in fractional count – meaning that the number of publications is normalized by the number of authors) is displayed by scientific field (using the Science-Metrix Ontology).

Click here to access the tool.

This was a challenge I could not refuse.

To design this visualization, three steps were necessary: data collection, data analysis and visualization.

The data collection seemed simple: I just had to download all the edits from a couple of thousand Wikipedia pages. Alas, it was more complicated than I thought. The database is massive and downloading it all and decompressing it would have taken more time than I had. With a bit of bash scripting, curl and a lot of bandwidth (about 100 GB), I implemented a script to download all edits from the Special:Export page. After a couple of days and nights of downloading, I had more than a thousand large XML files. I needed to parse these files to extract the names of the users, their edits and the time of these edits. Using a small custom Java program, I parsed this data and dumped it in a relational database.

Now that the data was in the database, the real work could begin. Since I wanted to analyze data from real and committed users, I got rid of edits made by IP addresses (since there is no way to identify users from their IP addresses) and by bots. Bots are automated tools that maintain Wikipedia by reverting bad edits or vandalism. The resulting data set was a list of Wikipedia pages, their edits, and when those edits occurred. The next step was to find a way to extract communities based on the edits that users had made.

The best way to identify communities is to look at collaboration networks. Since collaboration is such a vague word, I determined that when two Wikipedia contributors edited the same page, they were collaborating. Based on this assumption, I built a large collaboration network where each node was a contributor and the edges corresponded to a collaboration between two editors. To extract communities from this network, I clustered the nodes using the Blondel/Louvain clustering algorithm. The end result was a list of users, their communities and the pages they edited. Interestingly and not surprisingly, the communities were centered on scientific disciplines. For example, editors contributing to articles in physics, tended to edit articles related to physics.

The visualization of this data was a challenge since time was limited and the data set was multidimensional. Furthermore, since it was for a museum, it had to be at least attractive so I could not just slap a couple of charts on a web page and call it a day. To respect my time frame, I had to drop the time element of the data set. I would only concentrate on the communities and the articles they edited.

The design of this visualization is quite simple. On the left-hand side, all science related articles are grouped by categories in a list and on the right-hand side the participating communities for each selected article are illustrated by a particle flow proportional to their contribution to the article. A color is assigned to each community and the article is colored according to the community that has contributed the most.

You can access this visualization by going to Adobe Museum of Digital Media or directly at: http://www.olihb.com/WikiCommunities

The most interesting clusters are on both sides of Mount Royal. One side, situated in Westmount, contributes noticeably to the PLC while the other side, in Outremont, donates more to the Bloc Québec. To anybody living in Montréal, it’s hardly a surprising fact, but I think it’s nice to see it on a map.

The leaders’ debate is a golden opportunity to measure the Canadian political landscape as the primary talking points of the leaders and their parties are condensed into a manageable size. Using the transcript of the debate, I used a co-word analysis to try to extract the gist of the debate. I think the resulting maps are interesting and can shed light on current political trends.

(English will follow)

Afin de créer les cartes perceptuelles du débat, un travail de nettoyage a été nécessaire. Premièrement, chaque affirmation des chefs a  été séparée en mots. Ensuite, les mots inutiles (déterminants, verbes courants, etc.) ont été éliminés. Puis, une matrice de cooccurrences des mots a été calculée. À partir de cette matrice, des groupements (les couleurs sur la carte) et la position des mots (selon leur proximité à d’autres mots dans les déclarations des chefs)  ont été calculés à l’aide du logiciel VosViewer. Le résultat est un distillat du débat anglophone sous forme graphique.

Un coup d’oeil rapide nous permet d’identifier les préoccupations du Québec (à gauche en bleu), celles liées au crime (en haut en orangé) ou celles liées à l’économie (en bas en jaune et vert). L’analyse du réseau est également intéressante. Elle permet de visualiser les mots clés souvent utilisés dans la même affirmation ou le même contexte.

To create the maps, a preliminary cleaning of the raw dataset was necessary. Every line in the transcript was split into individual words. After that, noise words (e.g.: for, the, as…) were removed from the data as their presence only obscured relevant words and would clutter the map unnecessarily A co-word matrix was calculated from this list of words and then VosViewer data visualization software was used to calculate clusters (colors shown on the map) and word position (dependent on the proximity of words from other words in the data set).

From the computed map, major Canadian policy themes are visible. In blue, on the left, we can see Duceppe’s main talking points. In orange, near the  top of the map, law and order preoccupations are visible. At the bottom, in yellow and green, we can see all the words linked to the economy. I also generated a network graph in which the links between words belonging to the same theme thematic are very evident.

Each point on the chart represents an MP. The color of every MP follows their party affiliation. They are tightly clustered because of party discipline :  in Canada, MPs normally vote in accordance to directions given by the Prime Minister.

Since in Canada, MPs normally vote in accordance to directions given by the Prime Minister. On rare occasions, MPs can vote as they wish on ethical issues like abortion, the death penalty, etc. or on very regional subjects like gun control, ideally reflecting the opinions of their constituents. Because of that, one could think that an analysis of the voting patterns of Canadian MPs would be of limited value, but the same analysis of the voting record of the American senate (which has no party discipline) is very similar. See here.

The positions of the clusters don’t follow the usual left-right labelling of political parties. In Canada, the political party that is furthest to the right is the Conservative Party but their MPs are located on the left of the chart. This is because the PCA doesn’t care about our (subjective) labelling of political ideas. Apart from that, the order of the parties mostly reflects reality: the Liberals typically have policies that fall ideologically between the Tories and the NDP (and the Bloc).

I would be really interested in adapting this visualisation to other countries if I can find the raw data.

This visualization can be accessed at http://www.votum.ca. You’ll need Adobe Flash as it’s a Flex widget. By the way, I know there are a couple of bugs remaining. I’ll look into it when I get the time.