tijdruimtelijke tekstuele analyse van brand gerelateerde data op...

Pieterjan Lambein

data op sociale mediaTijdruimtelijke tekstuele analyse van rampgerelateerde

Academiejaar 2015-2016Faculteit Ingenieurswetenschappen en Architectuur

Voorzitter: prof. dr. ir. Jan VierendeelsVakgroep Mechanica van Stroming, Warmte en Verbranding

Voorzitter: prof. dr. ir. Rik Van de WalleVakgroep Elektronica en Informatiesystemen

Master of Science in de industriële wetenschappen: informaticaMasterproef ingediend tot het behalen van de academische graad van

Begeleiders: Viktor Slavkovikj, dhr. Florian VandecasteelePromotoren: prof. dr. Steven Verstockt, prof. dr. ir. Bart Merci

Woord Vooraf

De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen

van de masterproef te kopieren voor persoonlijk gebruik. Elk ander gebruik valt onder de

bepalingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron

uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.

The author gives permission to make this master dissertation available for consultation and

to copy parts of this master dissertation for personal use. In the case of any other use,

the copyright terms have to be respected, in particular with regard to the obligation to state

expressly the source when quoting results from this master dissertation.

10/06/2016

Sinds de laatste twee jaren van mijn studie ben ik reeds gebeten door alles wat te maken

heeft met kunstmatige intelligentie, ofwel big data. Ik was dan ook zeer tevreden om een

masterproef te mogen doen rond tekstuele data analyse. Daarnaast was natuurlijk ook het

thema, het real time opsporen van informatie over rampen, een prachtig, nobel, doel dat

hopelijk ooit effectief ingezet wordt. Persoonlijk had ik niet verwacht zo ver te geraken in

zo’n beperkte tijd, dus ik kijk zeker en vast positief terug op dit werk.

Ik wil vooral mijn promotor, prof. dr. Steven Verstockt en begeleider Florian Vandecasteele,

bedanken voor hun interesse, duidelijke verbeteringen, kritische vragen en positieve feedback .

Verder wil ik ook de andere labo medewerkers bedanken, die soms kwamen luisteren naar de

tussentijdse evaluaties of achter de schermen hun feedback gaven. Tenslotte bedank ik ook

nog mijn vriendin, Alicia Boone, voor het nalezen van het volledige werk.

ii

Abstract

Student: Pieterjan Lambein

Opleiding: Master of Science in de industriele wetenschappen: informatica

Titel: Tijdruimtelijke tekstuele analyse van rampgerelateerde data op sociale media

Begeleiders: Viktor Slavkovikj, dhr. Florian Vandecasteele

Promotoren: prof. dr. Steven Verstockt, prof. dr. ir. Bart Merci

Recent onderzoek heeft aangetoond dat er tijdens rampen heel wat sociale media wordt uit-

gewisseld tussen gebruikers die nuttig kan zijn voor hulpdiensten. De vrije opmaak van deze

media zorgt echter voor heel wat uitdagingen om de relevante informatie er uit te kunnen ha-

len. Deze masterproef poogt zo’n systeem, voor filtering en analyse van tekstuele berichten op

Twitter, ofwel tweets, te implementeren. Op basis van bestaand wetenschappelijk onderzoek

wordt een methodologie vastgesteld die een oplossing kan bieden voor de grootste uitdagingen.

Deze uitdagingen zijn: het onderscheiden van relevante informatie, het zoeken naar waar de

noodgevallen zich voordoen en het zoeken naar wat voor noodgeval er zich voordoet. Voor al

deze problemen werd een bestaande techniek gezocht en aangepast zodat alle informatie uit de

tekst van de berichten kan worden gehaald. Dit maakt het systeem heel breed inzetbaar. De

voorgestelde architectuur wordt stap voor stap geımplementeerd en geevalueerd met behulp

van enkele gegevenssets gerelateerd aan recente rampen. In een eerste fase worden de berich-

ten opgehaald, daarna worden de irrelevante berichten er uit gehaald. Uit de resterende set

worden de plaatsnamen en gebeurtenissen gehaald. Als er genoeg berichten hetzelfde voorval

beschrijven, binnen een bepaalde tijdsgrens, wordt er een noodgeval opgeworpen dat wordt

gevisualiseerd op kaart. Het resultaat levert effectief waardevolle informatie op over de ram-

pen, maar de hoeveelheid gegevens is sterk afhankelijk van de verwoesting en de spreiding

van de gebeurtenis. Verder kunnen aanvullende technieken zoals wijsheid van de massa er

voor zorgen dat het systeem efficienter en sneller kan worden ingezet.

iii

Spatio-temporal textual analysis of disaster relatedsocial media data

Pieterjan Lambein

Supervisor(s): prof. dr .Steven Verstockt, prof. dr. ir. Bart Merci, Viktor Slavkovikj, Florian Vandecasteele

Abstract— Recent research has shown that social media is widely usedduring disasters. Citizens share their observations, opinions and emotionsand therefore generate a lot of impactful content for emergency services.The unstructured input of social media, however, makes it very difficult toextract the relevant information from the messages. This work representsa methodology to cope with this issue and to filter and analyse textual mes-sages on Twitter (tweets). Based on related state-of-the-art research an ar-chitecture is developed, which can help to overcome some of the challengesin social media language processing. The proposed system is trained andevaluated with datasets from recent disasters.

Keywords— Data analysis, big data, artificial intelligence, emergencies,social media, twitter

I. INTRODUCTION

DISASTERS like wildfires, floods and earthquakes are themost destructive emergencies on this planet. Wildfires can

spread very fast, making them extremely destructive for their en-vironment. Earthquakes cause people to be trapped inside col-lapsed buildings with no food or water.

The destructions that these disasters can cause are highly de-pendent on the response time of the emergency services. Tomake sure these services are employed in the right place and atthe right time a certain detection of emergencies is necessary.Because wildfire moves fast, it is impossible for anyone, not be-ing at the spot, to assess the situation.

Even though there are several systems that can detect wild-fires with special cameras, their use is quite expensive and im-practical[1]. Another method, proposed in [1], to detect andfollow up emergency situations is by using social media data,send by users at the spot. During disasters, citizens share theirobservations, opinions and emotions witch each other. By doingthis they create ad-hoc communities (for example certain Twitterhashtags) containing lots of information about the disaster.

However, the free writing style of social media makes it hardto efficiently extract trustworthy, real time, information. In thisabstract we will propose an architecture for such a system anddiscuss a strategy for the greatest challenges is each section. Aprototype had been build to test the system which uses datasetsfrom a few past disasters.

II. STRATEGY & ARCHITECTURE

To develop a system that copes with this issue, a well estab-lished architecture is needed. The EmerGent project1 proposessuch a strategy for processing and analysing social media datastreams in emergencies[2]. This architecture was the founda-tion for building this system. Not all sections from the proposedstrategy were used, or implemented like described in [2], but

1http://www.fp7-emergent.eu/

Fig. 1THE DIFFERENT PHASES OF THE ARCHITECTURE.

they where adjusted to create a minimalistic system for the pur-pose of this research.

The following sections each describe one of the differentphases of the proposed workflow (shown in Fig. 1).

III. INFORMATION GATHERING AND DATA PREPARATION

During disasters there are enormous peaks of exchanged so-cial media data. Thus collecting and storing all this data hasto be memory efficient. Twitter has their own Application Pro-gramming Interface (API) that, with the use of OAuth authen-tication, has the ability to gather messages specified by certainkeywords or locations. Collecting those messages can be easilydone in Python by using the tweepy library.

Once the messages are coming in, they still need to be storedon disk for the information mining phase. A tweet however con-tains a lot of unwanted information, so they need to be saved ina standard format. The standard used in [2] is the OpenSocialActivity Stream standard, which has a minimum of three fields:verb (type of activity, like message), actor (the one sending theactivity) and object (the actual content, like the message itself).In order to perform spatio-temporal analysis, We also add thetime the tweet was send, its geographic coordinates (if present)and its ID.

To efficiently work with the messages, it is necessary to beable to put an index on their words. To do so, the message hasto be tokenized, which means words and symbols need to beseparated by a space and URL’s and @-mentions are replacedby a dummy text, e.i, URL and AT MENTION.

The message can now be used for information extraction, sothey’re saved into a MongoDB database.

IV. INFORMATION MINING

This building block takes standardized messages, and trans-forms them into only relevant events. An event is defined by twoinformation entities: what is happening and where it’s happen-ing. An event can have three different types: dead people, in-jured people or damaged infrastructure. The types are detectedon the use of words in the text. Therefore it can be extended toall kinds of subjects. Detecting a fire for example could be doneby looking for the words: “fire”, “smoke”, “burn”, “burning”,etc. Every event is created from just one message, but a mes-sage can generate multiple events, e.g., if the content is aboutinjured people and damaged houses.

The information mining phase is a three-step process. Firstthe messages that don’t contain any information are removed.After that we look for the location, described in the message.The last step is to find the subject of the disaster.

A. Remove the irrelevant messages

During disasters a lot of messages, expressing emotions andopinions, are usually worthless for information extraction. Tofilter these out, a Naıve Bayes classifier is used. Such a classifiercan be easily implemented using the Python Natural LanguageToolkit (NLTK) libraries[3].

The idea is to manually classify about 200 messages being re-lated or non-related. The classifier will than learn from this setby calculating for each word, the probability of being used ina related or non-related context. When asked to classify a newmessage, based on the learning set, it will calculate the prob-ability, based on the words in the message, of being related ornon-related. The one with highest chance is the given tag. NaıveBayes classifiers are widely used because of their simplicity andquite good precision[4].

B. Extract the event location

After the classification, the location of all the relevant mes-sages is searched. The location we need is the location of thecontext, not the location of the sender. Since is it possible totalk about an event without being there, this can make a big dif-ference[5]. The only way to find the contextlocation is to lookinto the message itself.

Extracting the location however comes with two very bigchallenges. First of all, the location names are hard to be recog-nized. Tweets are written in free writing styles and are limitedto 140 characters, leading to the predominant use of colloquiallanguage, misspellings, abbreviations and grammatical errors.Secondly, many of the placenames can be ambiguous and manyrefer to different concepts in different contexts[6].

To cope with the first challenge, a location extractor, calledPETAR, was used. PETAR was introduced in [6] anduses Foursquare check-in tweets to construct a geographicaldatabase, which includes abbreviations and colloquial names ofall the places in a specific town. To handle the second challenge,a lineair chain Conditional Random Field tagger is used to cal-culate if the candidate placenames in the message (whom werefound in the geographical database) actually represent a place-name. The proposed algorithm is based on the implementationof [6]. The objective of PETAR was to extract the location of

the user, and not the location he was talking about. If a place-name was found, the temporal awareness would state if a userwas currently there, has been there in the past or will be there inthe future. Because the movement of the sender is not necessaryfor this research, this part was not implemented.

C. Extract the event type

When a message consists of relevant information, and a loca-tion can be extracted from it, it is time to actually find the typeof the event. To do this an existing lexicon was used, whichconsist of the most commonly used words or word sequencesin tweets of a given type. The lexicon was found at [7] and itsconstruction is described in [8]. There are a set of words forevery category of crisis related communication but for this re-search only the ones called “injured people”, “dead people” and“infrastructure damage” were used. If at least two terms froma list were present in a message, an event was saved with thatlocation and event type.

V. ALERT DETECTION

In this phase all the events are given, with a certain locationand event type. However not all messages, describing a location,containing the words “dead”, “dead people” or even “dying” areactual emergencies. That’s why this last step is doing the detec-tion of alerts.

An alert looks pretty much like an event, but it is bound intime and space. Practically the world is divided into squareswith the dimensions of, for example, 1 latitude by 1 longitude.This would be a square of approximately 110 by 110 km, whichis quite large but the dimensions are adaptable. Then an alertshould be defined as being a number of events, happening in thesame square at the same timespan. The correct number of eventsand timespan highly depends on the number of messages and theactual duration of the disaster. The bigger the number of eventsin a smaller timespan, the more trustworthy the alert.

VI. INFORMATION VISUALISATION

The last section is the visualisation of alerts. Similar likeevents, alerts contain a location and a type. There are numerousways of visualising these alerts. In this research they are shownon a map, with a size similar to the number of events on thatsquare. The maps can be calculated within different timespansand filtered on specific event types.

VII. EVALUATION

The evaluation of the system was done by testing the effec-tiveness on three different datasets. The datasets consisted oftweets that were send during three different disasters. The dis-asters are:• The Colorado Wildfires of 2012, whose dataset can be foundat [9].• Hurricane Sandy of 2012, whose dataset can be found at [10].• The Paris terrorist attacks of 2015, whose dataset can befound at [11]. Only a part of this set was used, since it is verylarge.

Each dataset runs trough all the phases discussed in this pa-per. Table I shows how many messages are left after each phase.Unfortunately, the dataset of Hurricane Sandy didn’t contain

TABLE INUMBER OF MESSAGES AFTER EACH PHASE.

Disaster Start Naıve Bayes Location TypeColorado 3 381 228 184 24Sandy 80 331 26 NA NAParis 422 457 95 313 90 024 6 803

Fig. 2ALERT VISUALISATION OF THE COLORADO WILDFIRES DATASET.

enough relevant information to be visualized. The dataset ofthe Paris terrorist attacks generated the most events, probablydue to the extremity of the disaster.

At every stage a sample of 200 random messages was taken,from one or more datasets, and manually corrected. The correc-tion leads to a counting of the false positives (e.g. non-relatedmessages, tagged as related) and false negatives (e.g. relatedmessages, tagged as non-related). The Naıve Bayes classifierand the location extractor gave only very few false positives andnegatives (below 5% for Naıve Bayes and below 10% for loca-tion extraction). The event type classifier had no false positives,but a lot of false negatives. This is also clear from Table I sincethere are so few false positives in the related messages set, whilethe type classifier doesn’t even find 10% of them being an event.

The results from the Colorado dataset is shown in Fig. 2 andthe one from the Paris terrorist attacks in Fig. 3. Because ofthe small region in which the Paris disaster took place, all alertshave been grouped in a single square. To show these differentplaces of interest anyway, the dimensions of the squares havebeen divided by 100, so they are now about 1.1 by 1.1 km. Theresult, together with the corresponding placenames are shown inFig. 4.

It should be noted that the geographical database, constructedfrom Foursquare check-in tweets, could not be tested becausethere were not that many tweets of that kind available. To con-sider constructing a database for a given town or small region,one would have to monitor tweets for months[6].

VIII. CONCLUSION

The results of the evaluation show that the information ex-tracted from the messages contains a good impression of whathappened during the disasters. All information is correct, butincomplete. It became clear that the largest cut in the related

Fig. 3ALERT VISUALISATION OF THE PARIS ATTACKS DATASET.

Fig. 4ALERT VISUALISATION OF THE PARIS ATTACKS DATASET WITH HIGHER

PRECISION.

messages was during the type extraction, which was unable toclassify at least 10% of the messages. Since the type extractorwas the only system using only external resources (the lexiconfrom [8]) this could prove that only resources, very closely re-lated to the disaster data, gives decent results. Another approachwould be learning people how to tweet by proposing specificwriting styles where the placenames and subjects are easier todetect.

The Naıve Bayes classifier, as well as the location extractor,give very promising results. Only the event type extractor couldbe improved.

Future work can be done in the area of improving the eventtype extraction by using other techniques. Furthermore, theevents with placenames that correspond to cities or countriescould be spread across their full reach, instead of binding themto points in the middle of the region. Finally, labelling the learn-ing sets with the help of the wisdom of the crowd and gamifica-tion could aid getting in more relevant learning data.

REFERENCES

[1] Viktor Slavkovikj, Steven Verstockt, Sofie Van Hoecke, and Rik Van deWalle. Review of wildfire detection using social media. Fire safety journal,68:109–118, 2014.

[2] Matthias Moi, Therese Friberg, Robin Marterer, Christian Reuter, and

Thomas Ludwig. Strategy for processing and analyzing social media datastreams in emergencies. 2015.

[3] Laurent Luce. Twitter sentiment analysis using pythonand nltk. http://www.laurentluce.com/posts/twitter-sentiment-analysis-using-python-and-nltk/,2012. [Online; accessed 02-May-2016].

[4] StatSoft. Naive bayes classifier introductory overview. http://www.statsoft.com/textbook/naive-bayes-classifier. [On-line; accessed 02-May-2016].

[5] Oluwaseun Ajao, Jun Hong, and Weiru Liu. A survey of location infer-ence techniques on twitter. Journal of Information Science, 41(6):855–864, 2015.

[6] Chenliang Li and Aixin Sun. Fine-grained location extraction from tweetswith temporal awareness. In Proceedings of the 37th international ACMSIGIR conference on Research & development in information retrieval,pages 43–52. ACM, 2014.

[7] Alexandra Olteanu. A repository of crisis-related social media data andtools. http://crisislex.org/. [Online; accessed 16-March-2016].

[8] I Temnikova, C Castillo, and S Vieweg. Emterms 1.0: A terminologicalresource for crisis tweets, 2015.

[9] Alexandra Olteanu, Sarah Vieweg, and Carlos Castillo. What to ex-pect when the unexpected happens: Social media communications acrosscrises. In Proceedings of the 18th ACM Conference on Computer Sup-ported Cooperative Work & Social Computing, pages 994–1009. ACM,2015.

[10] Haoyu Wang, Eduard Hovy, and Mark Dredze. The hurricane sandy twittercorpus. Links, 499:539–515, 2014.

[11] Nick Ruest. A look at 14,939,154 #paris #bataclan #parisat-tacks #porteouverte tweets. http://ruebot.net/post/look-14939154-paris-bataclan-parisattacks-porteouverte-tweets,2015. [Online; accessed 04-May-2016].

Inhoudsopgave

Woord vooraf ii

Abstract iii

Extended Abstract iv

Inhoudsopgave viii

Lijst van figuren xi

Lijst van tabellen xiii

Lijst van afkortingen en symbolen xiv

1 Inleiding 1

2 Strategie & Architectuur 4

2.1 Informatievergaring en voorbereiding . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Verrijking van de gegevens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Datamining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Semantische informatiemodellering met behulp van ontologien . . . . . . . . . 7

2.5 Kwaliteit van de informatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6 Alarmdetectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.7 Informatievoorstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.8 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Informatievergaring en voorbereiding 12

3.1 Twitter feed ophalen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Standaard voor de dataopslag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Opslaan in een MongoDB databank . . . . . . . . . . . . . . . . . . . . . . . 16

viii

Inhoudsopgave ix

4 Datamining 18

4.1 Nodige informatie voor het detecteren van noodgevallen . . . . . . . . . . . . 18

4.2 Wegfilteren van irrelevante berichten . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.1 De Naıve Bayes classificeerder . . . . . . . . . . . . . . . . . . . . . . . 19

4.2.2 Implementatie met behulp van NLTK . . . . . . . . . . . . . . . . . . 21

4.3 Locatiebepaling uit sociale media berichten . . . . . . . . . . . . . . . . . . . 22

4.3.1 Classificate van locatiebepalingsmethodes op Twitter . . . . . . . . . . 22

4.3.2 Implementatie van de lokalisatie . . . . . . . . . . . . . . . . . . . . . 24

4.4 Content detectie uit sociale media berichten . . . . . . . . . . . . . . . . . . . 24

4.5 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Bepaling van de contextlocatie 26

5.1 Implementatie van de POI inventory . . . . . . . . . . . . . . . . . . . . . . . 27

5.2 Implementatie van de POI tagger . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2.1 Lexicale kenmerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.2 Grammaticale kenmerken . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.3 Geografische kenmerken . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2.4 BILOU-schema kenmerk . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2.5 CRF labeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Conclusies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6 Alarmdetectie 38

6.1 Indelen van de events in een rooster . . . . . . . . . . . . . . . . . . . . . . . 39

6.2 Detectie van de alarmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7 Informatievoorstelling 41

7.1 Een wereldkaart tekenen met matplotlib . . . . . . . . . . . . . . . . . . . . 41

7.2 Punten op de kaart tekenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.3 Visualisatie van events per type . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.4 Visualisatie van alarmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

8 Het Prototype 47

8.1 De Gegevenssets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8.1.1 Ophalen van de gegevenssets . . . . . . . . . . . . . . . . . . . . . . . 48

8.1.2 Achtergrondinfo over de rampen . . . . . . . . . . . . . . . . . . . . . 48

8.2 Informatievergaring en voorbereiding . . . . . . . . . . . . . . . . . . . . . . . 51

8.3 Datamining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.3.1 Wegfilteren van de irrelevante data . . . . . . . . . . . . . . . . . . . . 51

8.3.2 Bepaling van de locatie . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8.3.3 Bepaling van het type noodgeval . . . . . . . . . . . . . . . . . . . . . 55

Inhoudsopgave x

8.4 Alarmdetectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.5 Informatievoorstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.6 Evaluatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

9 Conclusie 61

10 Toekomstig werk 63

Bibliografie 64

A Gebruikte klassen 67

A.1 De klasse Tokenizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

A.2 De klasse Trie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Lijst van figuren

2.1 Vereenvoudigd proces voor de verwerking en analyse van sociale media data [1] 5

2.2 Voorbeeld van een mogelijke aanpak voor het bouwen van de ontologie [1] . . 8

2.3 Voorbeeld van een alarm visualisatie. . . . . . . . . . . . . . . . . . . . . . . . 10

2.4 Bouwstenen van het systeem in deze masterproef. . . . . . . . . . . . . . . . . 11

3.1 De drie stappen van de informatievergaring en voorbereiding. . . . . . . . . . 12

3.2 Ingeklapte JSON structuur van een tweet . . . . . . . . . . . . . . . . . . . . . 14

3.3 Structuur van een gestandaardiseerd bericht. . . . . . . . . . . . . . . . . . . 17

4.1 De drie stappen van de datamining. . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Structuur van een event in de databank. . . . . . . . . . . . . . . . . . . . . . 25

5.1 Een overzicht van de onderdelen van PETAR[2]. . . . . . . . . . . . . . . . . 27

5.2 Structuur van een bericht in de POI inventory. . . . . . . . . . . . . . . . . . 29

5.3 Een overzicht van de kenmerken voor de locatiebepaling, gebruikt in deze mas-

terproef. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.1 De verschillende stappen in het omzetten van events naar mogelijke alarmen. 38

6.2 Het verdelingsrooster als aanduiding van de gebieden. . . . . . . . . . . . . . 39

7.1 Basis wereldkaart getekend met matplotlib . . . . . . . . . . . . . . . . . . . 42

7.2 Basis wereldkaart met enkele punten, getekend aan de hand van matplotlib 43

7.3 Visualisatie van events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.4 Visualisatie van alarmen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.1 Overzicht van de branden in Colorado, 2012. (bron: thetrendguys.com) . . . 49

8.2 Overzicht van het vernielingspad van orkaan Sandy. (bron: mapbox.com) . . 50

8.3 Overzicht van de terroristische aanslagen in Parijs op 13 november 2015. (bron:

BBC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.4 Colorado: Overzicht van alle alarmen gedurende de volledige periode. . . . . 56

8.5 Colorado: Overzicht van de plaatsen waar alarmen optraden. . . . . . . . . . 57

8.6 Parijs: Overzicht van alle alarmen gedurende de volledige periode. . . . . . . 58

xi

Lijst van figuren xii

8.7 Parijs: Gedetailleerd overzicht van de rampen. . . . . . . . . . . . . . . . . . 58

Lijst van tabellen

8.1 Woordkenmerken van een bericht. . . . . . . . . . . . . . . . . . . . . . . . . 54

8.2 Overzicht van de resultaten van het protoype. . . . . . . . . . . . . . . . . . . 56

xiii

Lijst van afkortingen en symbolen

API Application Programming Interface 12, 13

CRF Conditional Random Field 27, 29, 59

EMS Emergency Management Services 2

ISO Internationale Organisatie voor Standaardisatie 14

JSON JavaScript Object Notation 13

MUG Mobiele Urgentiegroep 18

NER Named Entity Recognition 23, 26, 27, 32, 36

NLP Natural Language Processing 6, 7, 18, 23, 26

NLTK Natural Language Toolkit 21, 51

OOV Out Of Vocabulary 32

POI Point Of Interest 26, 28, 33, 34, 35

POS Part-Of-Speech 32, 53

xiv

Hoofdstuk 1

Inleiding

Rampen zoals bosbranden en orkanen behoren wereldwijd tot de meest verwoestende nood-

gevallen. Door hun snelheid en kracht zijn, vooral branden, een van de grootste bedreigingen

voor het ecosysteem[3]. Recente bosbranden zoals The Okanogan Complex Fire1 (Washing-

ton, 2015) en The Black Forest Fire2 (Colorado, 2013) hebben een zeer grote impact gehad

op de levens van veel mensen, alsook op het milieu. Factoren zoals droogte zorgen er voor dat

een bosbrand vaker voorkomt, intenser is en langer duurt dan gewoonlijk[4]. Ook in stedelijke

gebieden krijgt men vaak te maken met hevige branden. In Belgie waren er in 2013 maar liefst

22 733 brandinterventies, door 78% van de brandweerlieden in het land[5], dat komt neer op

iets minder dan drie branden per uur.

Om grote schade te voorkomen is tijdelijke en accurate detectie van groot belang[3]. Op die

manier kunnen hulpdiensten zo snel mogelijk op de juiste locatie worden ingezet. Tegenwoor-

dig wordt dat, voor bosbranden, onder andere gedaan met ICT-systemen, verbonden met

camera’s of via vliegtuigen, satellieten en drones. Uiteraard zijn deze systemen erg kostelijk.

Voor de camera’s moeten netwerkvoorzieningen gebouwd worden en de vliegtuigen zijn op

zich al een dure oplossing met weinig resultaat bij bewolkt weer[3].

De laatste jaren is er veel onderzoek gaande rond een heel andere manier van detectie, geba-

seerd op sociale media. Slakovikj et al. toonde hier reeds de voordelen van aan in [3] en dit

was dan ook de basis van het onderzoek in deze masterproef. De sociale media is een snel

groeiend medium voor het aangaan en behouden van netwerken. Volgens een onderzoek van

GlobalWebIndex naar het gedrag van social networking heeft 92% van alle volwassenen met

internet minstens een account op een sociale media site en gebruikt 44% die voor het behou-

den van sociale netwerken. Deze groei verandert de manier waarop mensen communiceren

1The Okanogan Complex Fire ontstond op 15 augustus 2015 door een reeks blikseminslagen, verbrande

meer dan 120 000 ha land en zorgde voor de evacuatie van heel wat dorpen. Pas tegen 19 september was 95%

van de brand onder controle.2The Black Forest Fire startte op 11 juni 2013 en was volledig onder controle op 20 juni 2013. Het vuur

verbrande 57.8 km2 en vernielde daarbij minstens 500 huizen.

1

Hoofdstuk 1. Inleiding 2

en informatie delen of verkrijgen, dit ook specifiek tijdens noodgevallen en crisissituaties[6].

Tijdens zulke situaties beschikken de sociale netwerk providers, zoals Facebook en Twitter,

dus over heel wat impactvolle informatie bestaande uit observaties, meningen en emoties van

hun gebruikers. Dit werd reeds aangetoond aan de hand van een postanalyse op een dataset

van 97 000 tweets, verzonden voor, na en tijdens de storm op Pukkelpop 2011[7].

Het grootschalig gebruik van sociale media is zeker niet vernieuwend. Door de overheid worden

ze reeds gebruikt om mensen te laten weten dat ze voorzorgsmaatregelen moeten nemen of

moeten evacueren[3]. Facebook gaat zelfs al een stap verder en laat gebruikers, waarvan zij

weet dat ze in het rampgebied zijn, toe om zich bij al hun vrienden veilig te melden3. Post-

analyse van verschillende rampen heeft reeds uitgewezen dat de berichten op sociale media,

na verwerking, heel wat nuttige informatie bevat, en dat vaak nog een hele tijd voor de

eerste nieuwsinstanties daarover beschikken[8]. De laatste jaren werd er bij catastrofes zoals

orkaan Sandy in 2012, de bosbranden van Colorado in 2013 en, nog recenter, de terroristische

aanslagen in Parijs (2015) en Brussel (2016) enorm veel sociale activiteit vastgesteld op de

verschillende media. Gedurende deze rampen werden ad-hocnetwerken gebouwd met behulp

van sociale media kanalen, die echter weinig of geen verbinding hadden met de hulpdiensten

of Emergency Management Services (EMS)[6].

Hoewel er reeds veel onderzoek beschikbaar is rond het gebruik van berichten uit sociale media

voor de ondersteuning van hulpdiensten, zijn er nog weinig of geen geteste implementaties.

In deze masterproef wordt een systeem ontworpen en geımplementeerd dat aan de hand

van tekstuele berichten op Twitter noodgevallen automatisch detecteert en visualiseert. Een

noodgeval wordt daarbij gedefinieerd als een meermaals voorkomend onderwerp, gebonden in

de tijd en in de ruimte. Stel dat er 50 berichten worden gedetecteerd in een straal van 1 km

die het woord “gewonden” bevat, dan hebben we waarschijnlijk te maken met een noodgeval.

Als de datum waarop die berichten verstuurd zijn dagen van elkaar verwijderd liggen is dat

niet meer het geval. Om effectief hulpdiensten te kunnen bijstaan is naast de locatie ook het

onderwerp van groot belang. De brandweer bijvoorbeeld zal vooral interesse hebben in schade

of brand, terwijl de medische diensten liever meldingen ontvangen als er mogelijke doden of

gewonden bij betrokken zijn[6]. Na de tekstuele analyse moet er dus zeker een classificatie

worden gemaakt volgens onderwerp[9]. De toegevoegde waarde die dit onderzoek levert is dat

bestaande systemen worden aangepast zodat enkel de inhoud van het bericht een rol speelt in

het zoeken naar informatie. Zo worden meerdere systemen eigenhandig gecodeerd, aangepast

en samengevoegd tot een volledig programma. Door enkel tekstuele berichten te gebruiken is

het programma heel breed inzetbaar.

In hoofdstuk 2 wordt eerst een strategie en architectuur voorgesteld en opgesplitst in ver-

3Voor Facebook heet dit Safety Check. Werd het eerst gebruikt bij de aardbeving in Nepal van 2015.

Gebruikers die aanmeldden in een rampgebied konden laten weten of ze buiten gevaar waren of niet.

Hoofdstuk 1. Inleiding 3

schillende onderdelen. In de hoofdstukken 3 tot 7 worden voor de gebruikte onderdelen de

reeds bestaande technieken onderzocht, de uitdagingen geıdentificeerd en een oplossing voor-

gesteld. Na het uitwerken van alle onderdelen apart volgt in hoofdstuk 8 een overzicht van

de implementatie van deze oplossingen. Voor het evalueren van dit prototype werden een

aantal gegevensbanken met ramp-gerelateerde Twitter berichten, of tweets, opgehaald. Om

de analyse op basis van de tijd te simuleren worden deze tweets in volgorde van verzonden

tijdstip verwerkt. De uitvoer is een landkaart waarop alle alarmen worden weergegeven. Een

alarm wordt getekend op zijn positie als er genoeg berichten een melding van een noodgeval

bevatten. Zo’n melding is een bericht dat wordt omgezet naar een event door uit dat bericht

de locatie en het onderwerp te halen. Als er genoeg events binnen hetzelfde bereik en dezelfde

tijdspanne zitten, dan wordt er een alarm gedetecteerd. De resultaten op de kaart kunnen

worden gefilterd op tijd door het meegeven van een tijdspanne. Verder kan het bereik van

alarmen vergroot of verkleind worden.

Hoofdstuk 2

Strategie & Architectuur

De opkomst van sociale media zorgde voor een verandering in de manier waarop mensen

communiceren, informatie verkrijgen en delen. Ook voor crisismanagement kan sociale me-

dia steeds meer worden ingezet. Tijdens heel wat overstromingen, bosbranden en tornado’s

werd data reeds uitvoerig verspreid over de verschillende sociale netwerktoepassingen [3, 1].

Gebruikers delen hun observaties, meningen en emoties en die bevatten vaak waardevolle

informatie.

Er zijn echter nog heel wat uitdagingen te overwinnen om sociale media datastromen te

converteren naar nuttige informatie. Een van de grootste uitdagingen is de hoeveelheid aan

irrelevante data, zoals berichten die steun en bezorgdheid uiten. Verder bezitten berichten

vaak informatie over hetzelfde incident, zodat een verkeerd beeld kan worden geschetst van de

schade. Er is nood aan een systeem dat deze grote pakken irrelevante informatie kan omzetten

naar kleine pakketten nuttige informatie.

Een strategie om zo’n systeem uit de bouwen is ontwikkeld door het EmerGent1 project en

is te vinden in [1]. Dit hoofdstuk tracht een kort overzicht te geven van de verschillende

onderdelen van de strategie voorgelegd door EmerGent. Bij elk onderdeel wordt nagegaan of

dit toepasbaar is in de context van dit onderzoek. In de volgende hoofdstukken worden voor

de passende onderdelen een correcte techniek gezocht.

De strategie concentreert zich op twee verschillende vormen van communicatie: van burgers

naar overheid en tussen burgers. Tussen overheden en van overheid naar burgers kan alleen

gebruikt worden als de data reeds geanalyseerd is. In Figuur 2.1 is een vereenvoudigd overzicht

opgenomen van het proces dat verder wordt besproken.

1Dit Europees onderzoeksproject poogt de positieve en negatieve impact van sociale media bij rampen in

kaart te brengen. http://www.fp7-emergent.eu/

4

http://www.fp7-emergent.eu/

Hoofdstuk 2. Strategie & Architectuur 5

Figuur 2.1: Vereenvoudigd proces voor de verwerking en analyse van sociale media data [1]

Eerst moet de sociale media worden opgehaald en de nuttige informatie worden opgeslagen

in een standaardformaat. Ondertussen kunnen andere nuttige gegevens worden berekend uit

de data en worden toegevoegd. Daarna volgt de datamining, die de relevante berichten zal

filteren en er de nodige gegevens uit zal halen. Uit deze informatie kan dan worden vastgesteld

of er al dan niet noodgevallen optreden en worden ze gevisualiseerd voor de eindgebruiker.

2.1 Informatievergaring en voorbereiding

Data uit sociale media komt meestal van meerdere bronnen, zoals Facebook, Twitter, etc.,

en in verschillende vormen, zoals tekst, video, foto, etc. Daarom is het belangrijk om een

standaard te voorzien die al deze verschillende informatie bronnen naar hetzelfde formaat

omzet. EmerGent kiest voor het gebruik van OpenSocial2, meer specifiek het formaat voor

Activity Streams, dat minimaal drie velden voorziet: een berichtgever, het bericht en de vorm

van het bericht.

In deze masterproef wordt enkel gebruik gemaakt van Twitter als sociaal netwerk en tekstuele

berichten als data. Andere sociale media, zoals Facebook, zijn zeker en vast even bruikbaar,

dus de keuze van dit onderdeel berust zich vooral op het feit dat de meeste recente publicaties

ook afgestemd zijn op Twitter. Aangezien dit onderzoek zich enkel baseert op tekstuele data,

is de techniek heel schaalbaar en kan ze, mits enkele technische wijzigingen in de informatie-

vergaring, voor alle media worden ingezet. Naast tekstuele data zijn zeker ook andere vormen

2Dit is een publieke specificatie die onder andere enkele API’s definieert voor webgebaseerde toepassingen.


van berichtgeving interessant, maar deze vallen buiten het bereik van deze masterproef.

Alles omtrent informatievergaring en voorbereiding (information gathering and data prepara-

tion) wordt gedetailleerder besproken in Hoofdstuk 3.

2.2 Verrijking van de gegevens

Hoewel er veel irrelevante gegevens uit de tweets worden weggefilterd, wordt er ook data

toegevoegd. Verrijken van de gegevens (data enrichment) is het toevoegen van metadata

aan de tweets, dat kan gebruikt worden bij de verdere analyse. Men kan een onderscheid

maken tussen brongebaseerde en berekeningsgebaseerde metadata. Brongebaseerde metadata

is ofwel onmiddellijk beschikbaar uit de ruwe data ofwel niet gegeven. Wat deze data inhoudt

is afhankelijk van het sociale netwerk, maar veel voorkomende voorbeelden zijn: datum,

tijd, berichtgever, titel, hashtags, reacties, locatie, leeftijd, geslacht, aantal uploads, shares

of retweets, etc. Berekeningsgebaseerde metadata kan alleen worden verkregen door een of

meerdere algoritmische bewerkingen. Voorbeelden zijn taaldetectie en sentiment analyse3.

Het grote voordeel van te werken met metadata is dat het mogelijk is een informatiesysteem

te ontwikkelen dat automatisch relevante data selecteert maar toch de eindgebruiker toelaat

deze automatisatie bij te sturen door het toevoegen van, voor hem, kwalitatieve metadata. Zo

is het bijvoorbeeld eenvoudig om een optie in te bouwen die de leeftijden van de berichtgevers

toevoegt aan de tweets, zonder daarvoor grote wijzigingen te doen.

De Twitter API, die voor deze masterproef wordt gebruikt voor het ophalen van tweets, stuurt

reeds heel veel van deze metadata automatisch mee. Voor deze masterproef wordt dit deel

dan ook toegevoegd aan het hoofdstuk over Informatievergaring en voorbereiding (Hoofdstuk

3) omdat er geen nieuwe zaken moeten worden opgehaald.

2.3 Datamining

De vorige twee stadia maakten van de ruwe data gestandaardiseerde data, aangevuld met

metadata. Bij datamining (information mining) wordt deze data omgezet in objecten die

domeingerelateerde kennis bevatten. Zoals reeds aangehaald moet irrelevante data worden

weggefilterd en data over hetzelfde incident worden geclusterd. Voor de irrelevante data stelt

EmerGent in [1] voor om een Naıve Bayes Classifier te gebruiken. Een Naıve Bayes Classi-

fier is een algoritme dat entiteiten classificeert op basis van kansberekening en voornamelijk

gebruikt wordt voor machinaal leren. Voor de clustering van incidenten is een algoritme dat

verschillende gelijkaardigheidsmetrieken gebruikt, aangewezen.

3Is een toepassing binnen de Natural Language Processing (NLP) voor het detecteren van subjectieve

informatie in het bericht. Bijvoorbeeld achterhalen of een reactie positief of negatief is.


Naast het beperken van informatie moeten er, op basis van de nuttige informatie, extra zaken

berekend worden. Het gaat hier vooral om locatie en onderwerp van het incident. Tweets

kunnen voorzien zijn van een geotag die onmiddellijk de coordinaten van de berichtgever

meegeeft, jammer genoeg zijn er maar heel weinig mensen die hier gebruik van maken [10,

2, 11]. Zelfs als de locatie is meegegeven in een geotag moet er alsnog een tekstuele analyse

gebeuren. Tenslotte kan iemand zonder problemen posten over een incident zonder daar in

de buurt te zijn.

Naast de locatie van het incident is ook een diepe analyse van het incident zelf nodig. De

geclusterde berichten bevatten allemaal info over hetzelfde onderwerp. Uit al deze berichten

moet de essentie van het voorval worden gehaald. Voor dit onderdeel worden vooral NLP

technieken gebruikt.

Van dit onderdeel wordt wel deels afgeweken in deze masterproef. In plaats van de berichten

te clusteren in samenhorende entiteiten en daarna locatie en onderwerp te achterhalen, wordt

hier per bericht locatie en onderwerp berekend en worden ze pas achteraf geclusterd (zie

Sectie 2.6). Dat maakt dat enkele van de volgende secties overbodig worden (zie verder).

Het idee hier achter is dat als de berichten eerst moeten worden geclusterd, er reeds een

tekstuele analyse gebeurt. Om de berichten te clusteren in samenhorende entiteiten gebeurt

dat namelijk ook op, onder andere, locatie en onderwerp. Om dat geen tweemaal te willen

doen is daarom de clustering uitgesteld naar de alarmdetectie. Het voordeel van wel op

voorhand te clusteren is dat berichten die slechts een deel van de informatie bevatten, elkaar

kunnen aanvullen, maar dit valt buiten de scope van deze masterproef.

Details omtrent de implementatie van datamining worden besproken in Hoofdstuk 4.

2.4 Semantische informatiemodellering met behulp van onto-

logien

Het doel van dit onderdeel is om de grote hoeveelheid verkregen informatie in een concep-

tueel schema te steken. Dit maakt de interpretatie er van eenvoudiger. Een overzichtelijk,

gestandaardizeerd systeem vermijdt daarmee misverstanden tussen de verschillende hulpor-

ganisaties. Een voorgestelde ontologie door EmerGent is te zien in Figuur 2.2.


Figuur 2.2: Voorbeeld van een mogelijke aanpak voor het bouwen van de ontologie [1]

De uiteindelijk ontologie wordt gebruikt voor semantische analyse zoals verdere data mining

voor het ontdekken van patronen en incidenten en de detectie van correlaties. Nog een

voordeel van deze aanpak is dat gegevens uit meerdere soorten informatiebronnen makkelijk

gecombineerd, gecorreleerd en bevraagd kunnen worden.

In de vorige sectie werd reeds aangehaald dat de berichten niet op voorhand worden geclusterd

naar samenhorende entiteiten, waardoor dit onderdeel niet verder wordt behandeld in deze

masterproef.

2.5 Kwaliteit van de informatie

Het berekenen van de kwaliteit van de informatie is essentieel voor het inzetten van hulpor-

ganisaties. Rond dit thema is nog maar weinig onderzoek verricht. De uitdaging is om een

kwalitatief informatie (Information Quality) raamwerk van criteria en relevante indicatoren

op te zetten die men kan meten aan de hand van data uit sociale media in crisissituaties

zoals tijdstip, begrijpbaarheid, betrouwbaarheid, precisie, etc. Nog een grote uitdaging is

een referentiewaarde voor elk van de indicatoren bepalen, bijvoorbeeld het instellen van een

acceptabel tijdsverschil of de maximale afstand tussen berichtgever en incident. Het opzetten

van zo’n raamwerk valt buiten de scope van deze masterproef.

Initieel wegen alle criteria even zwaar door in de bepaling van de kwaliteit maar dit zou dyna-

misch aanpasbaar moeten zijn. Wat de ene eindgebruiker belangrijk vindt, is niet noodzakelijk

zo voor de andere.

Voor deze masterproef is dit onderdeel geıntegreerd in de alarmdetectie (sectie 2.6). De reden

hiervoor is dat daar pas de berichten worden geclusterd naar effectieve entiteiten, gebonden


in ruimte en in tijd. Of zo’n entiteit een noodgeval voorstelt hangt af van een aantal instel-

bare parameters zoals tijdspanne, aantal gerelateerde berichten in de zone, precisie van de

locatie, etc. Precisie van de locatie wordt reeds in rekening gebracht bij het onderdeel data-

mining (sectie 2.3); berichten met locaties die te vaak verspreid voorkomen kunnen worden

verwijderd4.

2.6 Alarmdetectie

Aan de hand van de kwaliteitswaarde voor de informatie wordt een gebeurtenis die deel

uitmaakt van een ramp, bijvoorbeeld “twee gewonde personen”, gedetecteerd.

Een alarm is altijd domeingerelateerd omdat verschillende hulporganisaties verschillende taken

hebben. Het systeem kan worden gezien als een semantic reasoner , die logische beslissingen

neemt en acties uitvoert in een informatieruimte op basis van de gegeven feiten en axioma’s.

Een voorbeeld van zo’n feit is bijvoorbeeld: “Verschillende mensen ruiken een brandgeur in

zone x”. Als er in de informatieruimte iets wijzigt kunnen bepaalde feiten plots omslaan en

worden nieuwe alarmen gedetecteerd. Er zijn heel wat bestaande systemen beschikbaar voor

het bouwen van dergelijk type reasoner [1].

De grootste uitdaging voor het ontwikkelen van de alarmdetectie zijn de definities van rele-

vante feiten en axioma’s die een alarm genereren, omdat er nood is aan een brede kennis van

de domeinen van de hulporganisaties.

Voor deze masterproef wordt het veld Source altijd ingevuld met de locatie van het alarm.

Zoals aangehaald in sectie 2.3 is de invoer van het onderdeel alarmdetectie, in dit onderzoek,

de gerelateerde berichten met hun locatie en onderwerp, events genoemd. De events worden

op basis van hun lengte- en breedtegraad, hun tijdspanne (bijvoorbeeld de laatste 3 uren) en

hun onderwerp geclassificeerd en geteld. Vanaf een bepaald aantal hebben we een noodgeval

en wordt er een alarm geınitialiseerd. De technieken voor de alarmdetectie worden besproken

in Hoofdstuk 6.

2.7 Informatievoorstelling

Het voorstellen van de alarmen is het laatste onderdeel van de strategie uitgewerkt door het

EmerGent project. De visualisatie kan op veel verschillende manieren worden uitgevoerd

zoals bijvoorbeeld met behulp van eenvoudige lijsten, tijdruimtelijke en zelfs graaf-gebaseerde

voorstellingen. EmerGent richt zich op het combineren van deze technieken in een dynamisch

4In Hoofdstuk 4 is te zien dat hiervoor een metriek wordt berekend. Locaties die slechts een keer voorkomen

in het gebied (bv.: “‘Cafe De Trollenkelder in Gent”) zijn heel betrouwbaar. Als ze meermaals voorkomen

(bv.: “Starbucks”) kan men niet weten welke er bedoeld wordt en zijn ze dus minder betrouwbaar.


concept. Op hoog niveau zijn de filters strenger, zodat zo weinig mogelijk data er door geraakt.

Lagere niveaus geven een gedetailleerder beeld van de situatie. Zowel burgers, hulpdiensten

en onderzoekers moeten alle niveaus kunnen bekijken.

Burgers zullen eerder interesse hebben in samengevatte informatie zoals lijsten en ruimtelijke

voorstellingen. Hulporganisaties moeten bij de samengevatte informatie extra details kun-

nen terugvinden, onder de vorm van grafen of voorstellingen in de tijd. Onderzoekers zijn

vooral geınteresseerd in details en mogelijke relaties tussen objecten, dus vooral grafen en

grafieken.[1]

In deze masterproef werd voor de alarmdetectie de wereldkaart opgedeeld in een rooster. De

voorstelling van de alarmen op dat rooster is afhankelijk van het gekozen onderwerp en het

aantal berichten, over dat onderwerp, per roostervakje. In het midden van elk roostervakje

komt dan een bol (de standaardvoorstelling van een punt bij de gebruikte bibliotheek), die

evenredig is met het aantal berichten binnen die grenzen. Een voorbeeld van zo’n visualisatie

is te zien op Figuur 2.3. De grootste bol op de kaart telt 271 berichten over het gekozen

onderwerp, waardoor er een veel grotere kans is om op die positie noodgevallen aan te treffen,

tegenover de andere vakken.

Figuur 2.3: Voorbeeld van een alarm visualisatie.

De methode die in deze masterproef werd gebruikt voor de visualisatie van de informatie is

te vinden in Hoofdstuk 7.


2.8 Overzicht

In dit hoofdstuk werd de EmerGent architectuur voor analyse van sociale media data tijdens

rampen besproken. Voor ieder onderdeel werd bestudeerd of het nuttig is om te integreren in

ons eigen raamwerk. De relevante onderdelen komen allemaal in de volgende hoofdstukken

aan bod. Figuur 2.4 toont de bouwstenen van het systeem dat wordt besproken. De labels

“IN” en “UIT” verwijzen respectievelijk naar de invoer en de uitvoer van ieder deelsysteem.

Figuur 2.4: Bouwstenen van het systeem in deze masterproef.

Hoofdstuk 3

Informatievergaring en

voorbereiding

Tijdens noodgevallen en crisissituaties worden enorme pieken gehaald in de hoeveelheid uit-

gewisselde informatie[8]. Als deze data niet efficient wordt opgeslagen is het onmogelijk om

hier snel berekeningen en filters op toe te passen. Hoe sneller de informatie beschikbaar is,

hoe sneller hulpdiensten efficient kunnen worden ingezet. In dit hoofdstuk wordt het eerste

onderdeel uit de strategie van EmerGent [1] besproken, namelijk de ophaling en voorbereiding

van informatie. Eerst wordt er besproken hoe de ruwe Twitter feed wordt opgehaald uit de

Twitter Application Programming Interface (API). Ten tweede wordt gekeken naar het stan-

daardiseren van de data en welke velden er moeten worden toegevoegd aan het basisformaat.

Er wordt afgesloten met het invoegen in de databank. Figuur 3.1 visualiseert de verschillende

stappen.

Figuur 3.1: De drie stappen van de informatievergaring en voorbereiding.

3.1 Twitter feed ophalen

Voor het ophalen van tweets voorziet Twitter zijn eigen API. Hiermee kan men zowel tweets

ophalen als versturen. Alles gebeurt natuurlijk vanuit de account waarop wordt aangemeld.

Het aanspreken van de API kan in verschillende programmeertalen. Hier wordt Python

gebruikt, aangezien deze taal zeer geschikt is voor prototypes doordat er veel bibliotheken

12

Hoofdstuk 3. Informatievergaring en voorbereiding 13

worden ondersteund en er, in tegenstelling tot C++, met weinig code een werkend geheel te

verkrijgen is. Python voorziet de tweepy bibliotheek voor het verbinden met de Twitter API.

Listing 3.1: Tweets ophalen met behulp van een StreamListener.

from tweepy.streaming import StreamListener

from tweepy import OAuthHandler

from tweepy import Stream

class FireStatusListener(StreamListener):

def on_data(self, data):

prepare_data(data)

return True

# Create an authenticated Twitter API instance

authHandler = OAuthHandler(’my_consumer_key ’, ’my_consumer_secret ’)

authHandler.set_access_token(’my_access_token ’, ’my_access_token_secret ’)

# Create a FireStatusListener object and Twitter Stream

fireStatusListener = FireStatusListener ()

stream = Stream(authHandler , fireStatusListener)

# Track the following keywords from the global Twitter stream

stream.filter(track =[’fire’, ’explosion ’, ’wildfire ’], async=True)

Listing 3.1 geeft een codevoorbeeld voor een methode, die alle Twitter API output van de glo-

bale live Twitter stream naar een methode prepare data stuurt (zie sectie 3.2). Dat gebeurt

met behulp van een StreamListener, die een event on data bevat. De stream wordt hier,

louter als voorbeeld, gefilterd op tweets die minstens een van de woorden “fire”, “explosion”

of “wildfire” bevatten. De uitvoer is in het JavaScript Object Notation (JSON) formaat en

bevat vrij veel informatie. In de volgende sectie wordt gekeken welke informatie er nuttig is

en welke niet.

3.2 Standaard voor de dataopslag

In theorie zouden de opgehaalde tweets uit de Twitter API zonder meer kunnen worden

ingevoegd in een MongoDB databank. Zoals te zien in figuur 3.2 bevat zo’n tweet echter

veel irrelevante informatie, en bij miljoenen tweets komt dat niet ten goede van de rekentijd

en opslagcapaciteit. Hoewel deze masterproef enkel tekstuele berichten analyseert op het

sociale medium Twitter, moet er ook wel gekeken worden naar de mogelijkheid voor eventuele

uitbreidingen. Om deze twee redenen is een standaard nodig die enkel de relevante velden

invult, waar de meeste soorten berichten, van verschillende types en allerlei sociale media,

aan kunnen voldoen.


Figuur 3.2: Ingeklapte JSON structuur van een tweet .

In [1] wordt hiervoor de OpenSocial standaard voorgesteld. OpenSocial is een publieke speci-

ficatie die onder andere enkele API’s definieert voor webgebaseerde toepassingen. Hier wordt

het formaat voor Activity Streams gebruikt, dat bestaat uit minstens drie delen. De drie

onderdelen zijn verb, actor en object .

Verb is een type activiteit zoals een like, post, share, etc.

Actor is de persoon die het uitvoert.

Object is bijvoorbeeld een afbeelding of een stukje tekst.

Voor deze masterproef volstaan deze drie velden niet en worden ook de volgende velden

toegevoegd:

Created at is de Internationale Organisatie voor Standaardisatie (ISO) datum waarop de

tweet werd verstuurd.

Geo bevat een lijst met eerst de lengtegraad en daarna de breedtegraad (indien aanwezig,

anders NULL).


Tweet id is het unieke ID van de tweet .

Tokens is een andere vorm van het bericht, waarbij elk apart woord of teken gesplitst wordt

door een spatie.

Om bewerkingen te kunnnen doen op de woorden in het bericht, in de fase van de datamining,

moeten alle woorden kunnen geındexeerd worden. Er is dus een voorstelling nodig van het be-

richt die alle woorden en leestekens los van elkaar zet. Verder moeten de hashtags verdwijnen

en de @-annotaies en URL’s gewisseld worden voor een plaatsvervanger, om geen verkeerde

resultaten te krijgen bij bijzondere gebruikersnamen of domeinnamen. Ook speciale tekens

en emoticons worden weggefilterd. Als voorbeeld nemen we een bericht verzonden tijdens de

aanslagen in Parijs op 13 november 2015. Het eerste bericht is het origineel, het tweede is

dat na verwerking:

“@CBSNews: SPECIAL REPORT: French police report gunfire, explosions in #Paris; several

reported dead https://t.co/sVof4ziiD2 https://t.co”

“AT USER SPECIAL REPORT : French police report gunfire , explosions in Paris ; several

reported dead URL URL”.

Bovenstaande tekst wordt opgeslagen onder de sleutel “tokens”. Bemerk dat als deze op het

spatie-symbool wordt gesplitst, we over alle woorden en tekens apart bezitten, die nu kunnen

geındexeerd worden. Dit gebeurt allemaal met een zelfgeschreven module: tokenizer, te

vinden in Bijlage A.

Codevoorbeeld 3.2 bevat de functie prepare data die de benodigde data uit de gegeven

tweet haalt. Het type bericht wordt hier standaard aangeduid met een 0, aangezien er alleen

tekstuele berichten worden gebruikt. Het object bevat het gedecodeerde bericht (bv.: “&”

wordt gewoon “&”). Uiteindelijk wordt het nieuwe item aangemaakt en doorgestuurd naar

de methode save to database waar het wordt opgeslagen in de databank.

Listing 3.2: De opgehaalde tweets omzetten naar bruikbare standaard objecten.

import HTMLParser

import tokenizer as tok

from datetime import datetime

htmlp = HTMLParser.HTMLParser ()

tokenize = tok.Tokenizer ()

def prepare_data(tweet):

verb = 0

actor = tweet[’user’][’id’]

object = htmlp.unescape(tweet[’text’])

created_at = datetime.strptime(tweet[’created_at ’],’%a %b %d %H:%M:%S +0000 %Y’)

geo = tweet[’geo’][’coordinates ’] if tweet[’geo’] else None


tweet_id = tweet[’id’]

tokens = ’ ’.join(tokenize.tokenize_tweet(object))

item = {’verb’:verb , ’actor’:actor , ’object ’:object , ’created_at ’:created_at , ’geo

↪→ ’:geo , ’tweet_id ’:tweet_id , ’tokens ’:tokens}

save_to_database(item)

3.3 Opslaan in een MongoDB databank

Aangezien de tweets JSON geformatteerd zijn, ligt het voor de hand om de gegenereerde items

op te slaan in een MongoDB1 databank. De interne structuur van MongoDB werkt goed voor

grote hoeveelheden data. MongoDB is een opensource document-georienteerde databank die

zijn data opslaat in een Binary JSON formaat. De elementen in dezelfde databank hoeven niet

dezelfde sleutels te bevatten of even groot te zijn, in tegenstelling tot een relationele databank.

Achteraf kunnen heel complexe query’s geschreven worden om de data op te halen, op basis

van de sleutel-waarde paren. Python voorziet hiervoor de bibliotheek pymongo.

Listing 3.3: Een JSON object invoegen in een MongoDB databank met behulp van pymongo.

import pymongo

MONGO_DATABASE = pymongo.MongoClient(’localhost ’, port =27017).db.my_database

def save_to_database(item):

MONGO_DATABASE.update ({’tweet_id ’ : item[’tweet_id ’]}, item , upsert=True)

In Listing 3.3 wordt getoond hoe een Python Dictionary kan worden ingevoegd in een Mon-

goDB databank. De gebruikte instellingen, voor het ophalen van de MongoClient, zijn de

default instellingen voor de lokale databank van een systeem. Als de databank nog niet be-

stond, dan wordt deze aangemaakt bij het invoegen van het eerste element. Let op dat de

methode update gebruikt wordt in plaats van de methode save. Dit is een veilige manier

om nooit tweemaal hetzelfde bericht in te voegen. De methode update zal namelijk eerst

kijken of er reeds een item aanwezig is met dat tweet id . Indien dat zo is wordt het oude item

vervangen, anders wordt er een nieuw toegevoegd (optie upsert=True).

Op het einde van dit onderdeel ziet een gestandaardiseerd bericht er uit zoals in Figuur 3.3.

Als de tweet niet voorzien was van een geotag dan is de waarde van het veld geo gelijk aan

NULL.

1https://www.mongodb.com/

https://www.mongodb.com/


Figuur 3.3: Structuur van een gestandaardiseerd bericht.

Hoofdstuk 4

Datamining

Het doel van datamining (of information mining) is de grote hoeveelheid data uit sociale

media, inclusief metadata, om te zetten naar nuttige, geclassificeerde, informatie [1]. In

dit hoofdstuk wordt eerst gekeken naar welke informatie we uit de data willen halen en

welke uitdagingen daarbij komen kijken. Tenslotte wordt voor ieder probleem een techniek

besproken en in code omgezet.

4.1 Nodige informatie voor het detecteren van noodgevallen

Bij een grote ramp, die zich over tientallen kilometers verspreidt, is het, vanzelfsprekend,

noodzakelijk om hulpdiensten gericht te kunnen inzetten. De tijd die verloren zou gaan bij

het omleiden van brandweer, ziekenwagen, Mobiele Urgentiegroep (MUG), etc. kan levens

kosten. Om deze hulpdiensten correct te kunnen inzetten op de plaats waar zij nodig zijn,

moet er een antwoord gevonden worden op twee vragen: wat en waar.

Wat er precies gaande is bepaalt het soort hulpdienst. Een brandend huis zonder slachtoffers

heeft enkel nood aan een brandweer die zo snel mogelijk de brand komt beperken en verdere

verspreiding kan vermijden. Als er wel slachtoffers aanwezig zijn, dan is ook een ziekenwagen

noodzakelijk om zo snel mogelijk de gewonden te kunnen verzorgen. Het soort noodgeval kan

op basis van tekst worden meegedeeld, maar ook met behulp van andere media zoals foto of

video. Deze laatsten vallen echter buiten de scope van deze masterproef. Aan de hand van

NLP technieken op een datastroom wordt voor ieder bericht bepaald of het over een incident

gaat, en wat voor soort het is, zoals schade, gewonde, etc. De grootste uitdaging hierbij is

het onderscheiden van berichten met nuttige informatie.

Waar het noodgeval zich voordoet is een tweede noodzakelijk gegeven. Als hulpdiensten

moeten worden ingezet wil men natuurlijk weten waar die precies noodzakelijk zijn. Er zijn

verschillende locaties die we kunnen halen uit de tweets zoals de locatie van de gebruiker,

van het bericht en van de context van het bericht. Deze laatste is de meest betrouwbare.

18

Hoofdstuk 4. Datamining 19

Als de laatste niet voor handen is, maar er wordt wel een noodgeval beschreven, dan kan

het gaan om plaatselijke observaties en is de locatie van het bericht wel een goede maat voor

de locatie van het noodgeval. Twitteraars kunnen daarvoor aan hun tweets een zogenaamde

geotag toevoegen die hun GPS-coordinaten bevat. Deze GPS-coordinaten zijn dan publiekelijk

beschikbaar. Jammer genoeg is er slechts een heel klein percentage (minder dan 0.5%) van

de twitter gebruikers die gebruik maken van deze locatieservice [10, 2]. De uitdaging is hier

dus de locatie van de context achterhalen.

Al deze bewerkingen zijn vrij intensief en worden daarom best op zo weinig mogelijk irrele-

vante data uitgevoerd. De eerste stap zal dus zijn: alle berichten zonder nuttige informatie

wegfilteren. Daarna wordt eerst gezocht naar de locatie en vervolgens naar het type noodge-

val. Figuur 4.1 toont deze stappen in een processtructuur. De gebruikte techniek staat steeds

tussen haakjes onder de functie.

Figuur 4.1: De drie stappen van de datamining.

4.2 Wegfilteren van irrelevante berichten

Om enerzijds het geheugen van het systeem zo veel mogelijk efficient werk te laten verrichten,

en anderzijds geen onterechte alarmen op te gooien, moet er zo veel mogelijk irrelevante data

worden weggefilterd. Het zoeken op bepaalde, ramp gerelateerde, kernwoorden levert heel

veel verkeerde berichten op [1]. Dat blijkt ook uit eigen onderzoek, waarbij er gezocht werd

in de dataset van Hurricane Sandy[12] op veel voorkomende woorden uit rampgerelateerde

sociale media[13]. Een van deze woorden was “dead” en zorgde er voor dat 20% van de,

vermeende, nuttige berichten over de serie “The Walking Dead” gingen, en hoe teleurgesteld

de kijkers zouden zijn moest de orkaan hun televisie verstoren. EmerGent stelt in [1] een

systeem voor met behulp van een Naıve Bayes Classifier . Deze techniek maakt gebruik van

machinaal leren om entiteiten in te delen in klassen. Ondanks de eenvoud van Naıve Bayes,

wordt de methode frequent gebruikt voor classficiatie systemen zoals spam filtering en levert

dit opmerkelijk goede resultaten[14]. In deze sectie wordt zo’n systeem besproken.

4.2.1 De Naıve Bayes classificeerder

Een Naıve Bayes classificeerder wordt in het vakgebied van het machinaal leren gedefinieerd

als een familie van eenvoudige classificatiealgorimen gebaseerd op kansverdelingen. De naam


Bayes wilt zeggen dat zij gebaseerd zijn op de wet van Bayes over de voorwaardelijke kans

(zie Formule 4.1). Er zal nu worden aangetoond dat deze wet kan gebruikt worden voor

classificatie.

P (A|B) =P (B|A)P (A)

P (B)(4.1)

Stel dat men, bij wijze van voorbeeld, een sentimentele analyse wilt doen op recensies van

een nieuw product. Iedere recensie moet een label krijgen dat ofwel positief (voor een goede

recensie) ofwel negatief (voor een slechte recensie) is. Dan worden de te berekenen kansen,

voor ieder bericht gelijk aan: de kans op een negatief label en de kans op een positief label,

gegeven de woorden in dit bericht. Immers de woorden in het bericht bepalen of de schrijver

tevreden was of juist niet. Vandaar dat de woorden de kenmerken of features zijn van de

recensie. Dit kan worden voorgesteld aan de hand van volgende twee formules:

P (negatief|recensie) =P (recensie|negatief)P (negatief)

P (recensie)(4.2)

P (positief|recensie) =P (recensie|positief)P (positief)

P (recensie)(4.3)

Bemerk dat de gebeurtenis “recensie” eigenlijk de gebeurtenis is dat de n woorden wi uit de

recensie samen voorkomen: w1∧w2∧w3∧ . . .∧wn. P (recensie) wordt dan via de vermenigvul-

digingswet gelijk aan P (w1)P (w2)P (w3) . . . P (wn), aangezien bij Naıve Bayes alle kenmerken

onafhankelijk van elkaar beschouwd worden (vandaar naıve).

De termen die nodig zijn om bovenstaande formules op te lossen worden gehaald uit een set

handmatig gelabelde berichten. Men neemt dus een leerset van berichten en geeft handmatig

aan welke positief en negatief zijn. Het systeem analyseert dan de woorden in deze berichten

en hoeveel keer ze voorkomen, in een negatieve en positieve context.

De gebeurtenis “recensie”, P (recensie), is dus de kans dat de woorden uit de recensie worden

aangetroffen in alle berichten uit de leerset. P (recensie|negatief) is dan analoog te berekenen,

maar enkel uit de negatief gelabelde berichten van de leerset. Tenslotte wordt P (negatief)

gezien als de kans op een negatief bericht in de leerset. Bemerk dat alle informatie uit de

leerset te berekenen is. De formules worden dus:


P (negatief) =#negatieve berichten

#berichten

P (recensie) =#w1

#berichten

#w2

#berichten. . .

#wn

#berichten

P (recensie|negatief) =#w1 in neg. berichten

#neg. berichten. . .

#wn in neg. berichten

#neg. berichten

Analoog wordt ook P (recensie|positief) berekend. De gebeurtenis met de hoogste kans wijst

dan uit of het bericht negatief of positief gelabeld wordt. Dit is het basisprincipe achter Naıve

Bayes.

Voor deze masterproef wordt de Python Natural Language Toolkit (NLTK)1 bibliotheek ge-

bruikt, zoals in het voorbeeld in [15].

4.2.2 Implementatie met behulp van NLTK

De eerste fase is het samenstellen van een lijst van de leerset. Elk item van de lijst is een tuple

met twee elementen: de woorden van het bericht, als lijst, en het corresponderende label. De

woorden kleiner dan twee karakters worden er uit gelaten. Vervolgens moet van deze lijst

een lijst met alle woorden berekend worden. Deze lijst bestaat uit alle mogelijke woorden

van de leerset, geordend volgens voorkomen. In codevoorbeeld 4.1 wordt deze lijst berekend.

disaster tweets stelt de leerset voor.

Listing 4.1: Berekenen van de woordkenmerken uit de leerset.

def get_words_in_tweets(tweets):

all_words = []

for (words , crisis) in tweets:

all_words.extend(words)

return all_words

def get_word_features(wordlist):

wordlist = nltk.FreqDist(wordlist)

word_features = wordlist.keys()

return word_features

word_features = get_word_features(get_words_in_tweets(disaster_tweets))

Voor de classificeerder is een functie nodig die alle kenmerken uit een bericht haalt. De

kenmerken worden samengesteld door een woordenboek, met als sleutels alle woorden en als

waarde: True als dit woord in het huidige bericht voorkomt en False als dat niet zo is. Code-

voorbeeld 4.2 toont de extractiefunctie en hoe de classificeerder wordt opgesteld. De functie

1NLTK is een platform voor het ontwikkelen van systemen die werken met natuurlijke taal.


extract features krijgt de woorden uit het bericht als invoer en geeft het woordenboek met

de kenmerken als uitvoer. De apply features methode uit de NLTK bibliotheek neemt dan

deze functie en de leerset als invoer en geeft een set terug waaruit de classificeerder kan leren.

Na het leren kunnen nieuwe berichten worden geclassificeerd.

Listing 4.2: Ophalen van de kenmerken en leren van de Naıve Bayes classificeerder.

import nltk

def extract_features(document):

document_words = set(document)

features = {}

for word in word_features:

features[’contains (%s)’ % word] = (word in document_words)

return features

training_set = nltk.classify.apply_features(extract_features , disaster_tweets)

classifier = nltk.NaiveBayesClassifier.train(training_set)

Listing 4.3 geeft weer hoe het etiket uit het bericht (message) wordt gehaald eenmaal de

classificeerder (classifier) klaar is met leren.

Listing 4.3: Classificeren van nieuwe berichten.

tag = classifier.classify(extract_features(message.split ()))

4.3 Locatiebepaling uit sociale media berichten

Locatiebepaling uit tweets bevat heel wat informatie over de plaats zelf en over het gedrag

van de twitteraars [11]. Deze informatie is zeer waardevol voor toepassingen zoals marketing

en crisis management . Om deze redenen is dit onderzoeksveld zeer ruim vertegenwoordigd

en is het onmogelijk om alle methoden na te gaan. Aan de hand van [10] volgt eerst een

classificatie van al deze verschillende technieken. Daarna wordt een methode die past binnen

het kader van dit onderzoek geımplementeerd.

4.3.1 Classificate van locatiebepalingsmethodes op Twitter

Locatie types op Twitter Op Twitter kunnen verschillende soorten locaties worden ach-

terhaald. De locatie vanwaar de tweet verstuurd werd en de locatie waarover het bericht gaat

hoeven niet noodzakelijk dezelfde te zijn i.e., het is niet omdat een gebruiker over een plaats

schrijft dat hij daar effectief is. Hier volgt een overzicht:

� Thuislocatie beschrijft waar de berichtgever woont en is al dan niet ingegeven op het pro-

fiel van de gebruiker. Dit tekstveld kan vrij worden ingevuld dus bevat vaak (ongeldige)

afkortingen en bijnamen.


� Tweetlocatie is vanwaar het bericht verzonden is en wordt meegegeven als geotag of

moet worden achterhaald door middel van data analyse.

� Contextlocatie beschrijft over welke plaats het bericht gaat en kan alleen via tekstuele

analyse op het bericht worden achterhaald.

Deze masterproef beperkt zich tot tekstuele analyse. Daarom wordt hier enkel gezocht naar

de contextlocatie.

Ruimtelijke kenmerken De vorige locaties zijn meestal niet altijd beschikbaar en moeten

via data analyse worden achterhaald. Er zijn heel wat methoden, die elk hun eigen set

ruimtelijke kenmerken hanteren. Dit zijn de meest gebruikte:

� Locatie beschrijving in de tekst is gewoon een plaatsnaam in het bericht.

� Vriendennetwerk is een goede indicatie van waar een gebruiker zich kan bevinden.

� Locatieveld op het profiel kan indien ingevuld naar een geldige thuislocatie wijzen.

� Website IP adres kan worden gelokaliseerd als de gebruiker een website heeft ingevuld

op zijn profiel.

� Geotags bevatten zeer precieze coordinaten.

� URL’s in het bericht kunnen worden gelokaliseerd aan de hand van het IP adres.

� Tijdzone kan eventueel dienen voor lokalisatie met een precisie tot op landniveau.

Zoals reeds besproken wordt enkel gezocht naar de contextlocatie. Van al deze ruimtelijke

kenmerken kan enkel de eerste, locatie beschrijving in de tekst, hier meer informatie over

geven.

Methoden voor locatiebepaling Ten slotte zijn er nog de algoritmen zelf, die op basis

van een of meer ruimtelijke kenmerken een type locatie probeert te achterhalen. De grootste

uitdaging hierbij is de betekenis en context van berichten, waarin vaak emoticons, sarcasme,

hashtags, afkortingen en schrijffouten voorkomen, te achterhalen[10].

� NLP is het veld binnen de computerwetenschappen dat zich bezighoudt met de interac-

tie tussen menselijke talen en computers. Technieken zoals Named Entity Recognition

(NER) kunnen plaatsnamen uit tekst identificeren, bijvoorbeeld: “Tom koopt 300 aan-

delen van Google Inc. in 2005.” wordt na analyse gelabeld als: “[Tom]Persoon koopt

300 aandelen van [Google Inc.]Bedrijf in [2005]Tijd.”. De entiteiten kunnen zowel via

grammaticale of statistische (machinaal leren) methoden worden geıdentificeerd. Ge-

vestigde NER methoden geven echter veel fouten door het vrije taalgebruik op Twitter.


Dat maakt efficiente NLP methoden complex om te implementeren, maar wel sneller en

flexibeler dan geografische databanken.

� Geografische databanken worden gebruikt door het zoeken van alle woorden uit een

bericht in een databank met veel voorkomende plaatsnamen. Deze databank kan zelf

opgesteld worden of vanuit een externe bron komen, bijvoorbeeld OpenStreetMap2. Er

bestaan ook methoden die de vorige twee combineren door eerst met behulp van NER

de plaatsnamen te identificeren in de tweet en ze dan te verifieren in een geografische

databank[2].

� Machinaal leren is de laatste methode. Een voorbeeld hiervan is de locatie van een

gebruiker achterhalen op basis van de gegeven locaties van zijn vrienden en de sterkte

van de vriendschapsband[16].

4.3.2 Implementatie van de lokalisatie

Door de grote hoeveelheid recente publicaties rond locatiebepaling uit tweets blijkt duide-

lijk dat dit een zeer actief onderzoek is waarbij vaak dezelfde moeilijkheden en uitdagingen

optreden. De methoden die werden gekozen voor deze studie zijn veelbelovend op vlak van

het aantal citaties en de manier waarop ze een oplossing bieden aan de grootste uitdagingen

binnen dit onderwerp.

In dit onderzoek wordt enkel gezocht naar de locatie uit de context van het bericht. Met andere

woorden, er wordt gezocht naar de plaats waar de berichtgever over spreekt. De namen van

deze plaatsen zijn heel plaatsgebonden en vaak moeilijk te herkennen. Het systeem, dat voor

deze masterproef volledig werd geımplementeerd, is vrij uitgebreid en wordt daarom in een

apart hoofdstuk besproken, namelijk Hoofdstuk 5.

4.4 Content detectie uit sociale media berichten

Voor dit onderzoek werd gekozen om drie verschillende types noodgevallen te achterhalen:

doden, gewonden en schade. De vorige sectie haalde reeds alle berichten, die effectief een

noodgeval beschrijven, uit de volledige set. In deze sectie wordt er in de berichten gekeken

welk type noodgeval er beschreven wordt. [17] bevat een lijst met veel voorkomende ramp

gerelateerde termen, geclassificeerd volgens onderwerp. Hoe de lijst werd opgesteld is te

vinden in [18]. De nodige onderwerpen zijn: Injured people, Dead people en Infrastructure

damage.

In een eerste stap worden de termen uit de set gehaald en met behulp van reguliere expressies

gezocht in alle berichten. Een reguliere expressie is een manier om patronen te beschrijven

2OpenStreetMap is een internationaal project dat de wereld in kaart probeert te brengen met behulp van

de gemeenschap.http://osm.be/

http://osm.be/


waarmee een computer tekst kan herkennen. Om het aantal false positives te beperken wordt

een bericht pas aan een onderwerp verbonden als er minstens twee termen uit de lijst in

voorkomen, bijvoorbeeld: “{Number} people” en “injured” in hetzelfde bericht wordt gezien

als een “gewonde” event. Daarna wordt het bericht opnieuw opgeslagen in de databank, met

een “type” parameter er bij.

Bemerk dat eenzelfde bericht meermaals in de databank kan voorkomen, als het over meerdere

onderwerpen gaat.

4.5 Conclusies

In dit onderdeel werden de locatie en het onderwerp gezocht voor ieder bericht apart. Pas

als beide gedetecteerd worden, zal het bericht opnieuw worden opgeslagen als een event.

Deze events worden hier bekeken als “vermeldingen van een noodgeval” en bevatten minstens

volgende sleutels:

Type is het onderwerp van het bericht en kan de waarden “dead”, “injured” of “damaged”

aannemen.

Timestamp beschrijft wanneer het bericht verzonden is.

Source bevat een of meerdere contextlocaties.

De bekomen structuur is te zien in Figuur 4.2.

Figuur 4.2: Structuur van een event in de databank.

De methoden uit dit hoofdstuk worden toegepast voor het te testen prototype in Sectie 8.3.

De events vormen de invoer voor de alarmdetectie, besproken in Hoofdstuk 6.

Hoofdstuk 5

Bepaling van de contextlocatie

In dit hoofdstuk wordt een systeem besproken voor de bepaling van de contextlocatie. Met

andere woorden, het programma probeert op basis van de text te weten te komen over welke

locatie een berichtgever het heeft.

De techniek die hier wordt besproken staat beschreven in [2]. De methode heeft de naam

PETAR wat staat voor Point Of Interest Extractor with Temporal Awareness. PETAR maakt

gebruik van twee van de meest voorkomende technieken voor locatiebepaling: eerst wordt een

geografische databank gemaakt, daarna wordt, met behulp van NLP technieken, uit elk bericht

de plaatsnamen gehaald die ook voorkomen in de databank. Het doel van PETAR is om de

locatie van de berichtgever te achterhalen, aan de hand van de inhoud van zijn bericht.

Er zijn twee problemen die PETAR probeert op te lossen. Ten eerste de omgangstaal die

veel voorkomt in tweets en waar traditionele NER tools het moeilijk mee hebben. “The

United Kingdom”, bijvoorbeeld, kan eventueel voorkomen als “UK”, “GB”, “GBR” of zelfs

“GR8 Britain”[10]. Ten tweede kunnen plaatsnamen, hier Point Of Interest (POI) genoemd,

een andere betekenis krijgen naargelang de context waarin ze zich bevinden. Een restaurant

met de naam “The Smile”, bijvoorbeeld, is moeilijk te herkennen doordat smile een veel

voorkomend Engels woord is.[2].

Als invoer krijgt PETAR een grote collectie tweets. Per tweet worden alle POI’s er uit

gehaald, en per POI wordt aan de hand van de context een temporal awareness label uit de

lijst: {“verleden”, “heden”, “toekomst”} toegekend. Op die manier weet men of de gebruiker

op die plaats geweest is, er zich momenteel bevind of er naartoe gaat. Voor deze masterproef

is dit minder van belang, aangezien er naar de context van het bericht wordt gezocht en

minder naar de positie van de persoon.

De implementatie van PETAR rust daarvoor op twee onderdelen. Ten eerste, een POI inven-

tory dat een soort databank is van mogelijke POI namen en ten tweede, een POI tagger die

bepaalt of de POI kandidaat geldig is en met behulp van de context de temporal awereness van

26

Hoofdstuk 5. Bepaling van de contextlocatie 27

de kandidaat achterhaald. De POI inventory wordt opgesteld aan de hand van Foursquare

check-in tweets. Een check-in tweet bestaat uit een breedte- en lengtegraad en een tweet .

In die tweet staat altijd een POI naam, door gebruikers gespecificeerd en door Foursquare

geformatteerd. Men kan dus eenvoudig de POI’s er uit halen. Aangezien de plaatsnamen op

Foursquare door gebruikers ingegeven worden bevatten deze vaak bijnamen of afkortingen.

Op die manier wordt er gepoogd zelfs tweets met informele plaatsnamen te lokaliseren.

Uit de tweets van de invoer worden, met behulp van de POI inventory , alle POI kandidaten

verzameld. Daarna wordt met de POI tagger de context ervan onderzocht. Hiervoor wordt het

linear-chain Conditional Random Field (CRF) model gebruikt die alle woorden uit elk bericht

uitbreid met vier klassen kenmerken: lexicaal, grammaticaal, geografisch en BILOU-schema.

Een CRF model is een klasse van statistische modelleringsmethoden die vooral voor structu-

reel leren gebruikt worden. Een voorbeeld van structureel leren is NER uit een tekst, waarbij

het label dat een woord krijgt sterk afhankelijk is van de woorden die er rond staan. Bij-

voorbeeld het woord “Washington” kan verwijzen naar de staat Washington, of naar de stad

Washington DC, die daar kilometers ver van verwijderd ligt. De context van het bericht zal

dus beiden moeten onderscheiden. Het basisprincipe achter CRF is gebaseerd op de wet van

Bayes, zoals uitgelegd in sectie 4.4.

Volgende secties beschrijven een implementatie van de beide onderdelen van PETAR, die

gebaseerd is op [2]. Figuur 5.1 toont deze onderdelen in een overzicht.

Figuur 5.1: Een overzicht van de onderdelen van PETAR[2].

5.1 Implementatie van de POI inventory

Aangezien de check-in tweets steeds dezelfde structuur hebben, is het eenvoudig om de POI’s

er uit te halen via een reguliere expressie. Een voorbeeld is te zien in listing 5.1. De methode

extract POI strings krijgt een bericht mee en geeft een lijst terug van plaatsnamen. Eerst

worden de volledige namen er uit gehaald en daarna gesplitst aan de hand van stopwoorden

zoals “at” en “of”. Verder worden ook de @-tags van de plaatsnamen geknipt en meerdere

namen, meestal gescheiden door een “-” afgezonderd.


Listing 5.1: Uit een check-in tweet de POI’s halen met een regex.

import re

def extract_POI_strings(text):

re_result = re.search(r"(?:I\’m at (.*?) |.*?) $( .*? )(?:w / .*?|\( .*?|)$ .*?",

↪→ text)

poi_list = list()

if re_result:

for result in re_result.groups ():

if result is None:

continue

poi_list += [ x.strip() for x in re.split(’ @ | at | , | - | of | the | :

↪→ | / ’, str(result).lower ()) ]

return poi_list

Heel wat POI namen bestaan uit meerdere woorden. Vaak worden echter niet al die woorden

gebruikt in de plaatsbeschrijving. Daarom worden voor alle POI namen die uit meer dan

twee woorden bestaan, ook de sub-sequenties van de woorden toegevoegd (tot maximum vijf

woorden per sequentie). Verder wordt dan steeds gezocht naar de langst mogelijke sequentie

in de POI inventory . Listing 5.2 geeft hier een code voorbeeld van.

De methode expand POI strings krijgt als parameters: een lijst van alle POI’s die in deze

procedure worden verwerkt (poi list) en de coordinaat die bij deze lijst hoort als breedte-

graad (lat) en lengtegraad (lon). Er wordt niets teruggegeven, aangezien ALL POI gewoon

wordt aangevuld.

Listing 5.2: Deze methode voegt alle sub-sequenties van de huidige tweet zijn POI namen toe aan

een dict die het voorkomen bijhoudt in de volledige tweet set.

ALL_POI = dict()

def expand_POI_strings(poi_list , lat , lon):

for poi in poi_list:

if poi == ’’:

continue

poi_words = poi.split(’ ’)

if len(poi_words) > 1: # don’t do this for poi’s with only one word

for i in range(0, len(poi_words)):

for j in range(i+1, i+7): # i+7 - i+1 = 6 => maximum num of words = 5

if j > len(poi_words):

break

if len(’ ’.join(poi_words[i:j])) < 2: # remove poi’s of one char

continue

poi_part = ’ ’.join(poi_words[i:j])

times_added = 1

if poi_part in ALL_POI:

times_added += ALL_POI[poi_part ][’times_added ’]

ALL_POI[poi_part] = {’poi’ : poi_part , ’lat’: lat , ’lon’ : lon , ’

↪→ times_added ’ : times_added}

Deze sub-sequenties zorgen echter voor een heel pak ongeldige POI namen zoals bijvoorbeeld

“east bus” uit “jurong east bus interchange”. Daarom worden op het einde alle POI namen


die in minder dan vijf check-in tweets voorkomen verwijderd. Een codevoorbeeld hiervan is

te zien in listing 5.3.

Listing 5.3: Telt alle voorkomens van de POI in de berichten. Als het voorkomen kleiner is dan vijf

wordt ze niet toegevoegd aan de uiteindelijke lijst.

def count_poi_occur_and_delete_less_used ():

del_list = list()

for poi in ALL_POI:

if ALL_POI[poi][’times_added ’] < 5:

del_list.append(poi)

for d in del_list:

del ALL_POI[d]

del_list = []

for poi in ALL_POI:

kl = 0

for text in ALL_TEXT:

if re.search(re.escape(poi), text.lower()):

kl+=1

ALL_POI[poi][’count’] = kl

if kl < 5:

del_list.append(poi)

for d in del_list:

del ALL_POI[d]

Voor de datastructuur van de POI inventory wordt door [2] een meerwegse trie aanbevolen.

Op die manier kan eenvoudig naar de langste POI kandidaat gezocht worden. De implemen-

tatie van de trie gebruikt in deze masterproef is gegeven in bijlage A.

Figuur 5.2 toont de structuur, in de databank, van een POI document. De spatial randomness

en location name confidence worden verder in deze sectie besproken.

Figuur 5.2: Structuur van een bericht in de POI inventory.

5.2 Implementatie van de POI tagger

In het CRF model wordt elk woord voorgesteld als een vector van kenmerken. Als een kenmerk

wordt berekend voor een woord, wordt dat kenmerk ingevuld in zijn vector. Als een kenmerk


wordt berekend voor een bericht, worden de kenmerken van al haar woorden aangepast naar

deze waarde. Woorden worden hier nogal ruim gezien, i.e., alles wat wordt gesplitst door

de module Tokenizer (zie bijlage A) wordt gezien als woord. Als er verder in deze sectie

wordt verwezen naar een bericht bedoelt men dan ook een gesplitst (met Tokenizer) en terug

samengevoegd bericht, met als scheidingsteken een spatie.

Zoals reeds vermeld wordt de contextuele info bij elke POI kandidaat in een tweet bepaald

door vier klassen van kenmerken: lexicaal, grammaticaal, geografisch en BILOU-schema. In

de rest van deze sectie volgt de beschrijving en implementatie voor het ophalen of berekenen

van elk van deze kenmerken.

Merk op dat sommige kenmerken alleen voor kandidaat plaatsnamen kunnen worden ingevuld.

De overige woorden krijgen voor dit kenmerk een NULL in de plaats. De kandidaat plaatsnamen

zijn alle langste, niet overlappende plaatsnamen die te vinden zijn in de POI inventory .

Codevoorbeeld 5.4 toont hoe deze uit een bericht gehaald worden. Als invoer van de methode

get poi mentions wordt het bericht (message) meegegeven en als uitvoer wordt een set

teruggeven met tuples die de indices (van, tot) van de woorden die de plaatsnamen voorstellen

bevatten. De constante POI TRIE is van het type Trie (klassendefinitie in Bijlage A) en bevat

alle POI’s uit de POI inventory .

Listing 5.4: Alle langste kandidaat plaatsnamen halen uit een bericht.

def get_poi_candidates(message):

word_list = message.lower().split()

# Search for all POI mentions

poi_mentions = set()

for i in range(0, len(word_list)):

for j in range(i + 1, len(word_list) + 1):

if POI_TRIE.in_trie(’ ’.join(word_list[i:j])):

poi_mentions.add((i,j))

# Filter mentions to candidates

poi_candidates = list()

while (len(poi_mentions)):

longest_poi = tuple(); lon_length = 0

for poi in sorted(poi_mentions):

l = poi[1]-poi[0]

if l > lon_length:

lon_length = l

longest_poi = poi

poi_candidates.append(longest_poi)

poi_mentions.remove(longest_poi)

for poi in poi_mentions.copy():

if (poi [0] >= longest_poi [0] and poi[0] < longest_poi [1]) or (poi [1] >=

↪→ longest_poi [0] and poi [1] < longest_poi [1]):

poi_mentions.remove(poi)

return poi_candidates


5.2.1 Lexicale kenmerken

Er zijn zeven lexicale kenmerken, vier basis kenmerken van het woord zelf en drie contextuele

kenmerken van wat er zich rondom het woord bevindt.

1. Basis kenmerken van het woord zelf:

(a) Het woord zelf en het woord in kleine letters.

(b) Vorm van het woord: hoofdletters, gekapitaliseerd, alfanumeriek of numeriek.

(c) Alle voor-en achtervoegsels, van een tot drie tekens.

(d) Voorafgaande waarschijnlijkheid dat het woord gekapitaliseerd of volledig gekapi-

taliseerd is.

2. Contextuele kenmerken van het woord:

(a) Bag-of-words bestaande uit de voorgaande twee woorden, het woord zelf en de

volgende twee woorden.

(b) De voorgaande twee woorden

(c) De volgende twee woorden

Lexicaal kenmerk 1d (Voorafgaande waarschijnlijkheid...) kan op voorhand worden berekend

door te zoeken in een grote dataset naar alle woorden, en voor ieder woord het aantal keer

dat het gekapitaliseerd, en volledig gekapitaliseerd, voorkomt delen door het aantal keer dat

het voorkomt.

Listing 5.5 toont een codevoorbeeld van de extractie van de basis kenmerken in Python. De

methode lexical basic neemt een bericht als argument en geeft alle basis lexicale kenmer-

ken terug in een lijst (lex basic) van lijsten (w list), waarbij elke index in lex basic de

index van een woord voorstelt in het bericht. De contextuele kenmerken hoeven niet op voor-

hand berekend te worden, aangezien zij worden ingegeven in de CRF methode. De variabele

LEX PRIOR PROB stelt de waarschijnlijkheden van de kapitalisatie voor en is opgebouwd uit

een woordenboek, met als sleutel alle woorden en als waarde een lijst met als eerste en tweede

element respectievelijk de voorafgaande waarschijnlijkheid dat het woord gekapitaliseerd of

volledig gekapitaliseerd is.

Listing 5.5: Extractie van de basis lexicale kenmerken van alle woorden in een tweet .

LEX_PRIOR_PROB = calculate_prior_case_prob ()

def lexical_basic(tweet):

lex_basic = []

for w in tweet.split():

w_list = []

w_list.append(w.lower())


w_list += [int(w.isupper ()), int(w.istitle ()), int(w.isdigit ()), int(w.isalpha

↪→ ())]

for i in range(1, 3 + 1):

if i > len(w):

w_list.append(None)

w_list.append(w.lower()[0:i])

w_list.append(w.lower()[-i:])

w_list.append(LEX_PRIOR_PROB[w.lower () ][0])

w_list.append(LEX_PRIOR_PROB[w.lower () ][1])

lex_basic.append(w_list)

return lex_basic

5.2.2 Grammaticale kenmerken

Er worden zeven grammaticale kenmerken gebruikt.

1. Part-Of-Speech (POS) labeling is een bestaande softwaremethode die woorden in een zin

identificeert en er labels, aan toekent op basis van hun grammaticale classificatie. Het

verschil ten opzichte van NER is dat er geen plaatsnamen of personen worden herkent,

maar wel zelfstandige of bijvoeglijke naamwoorden, werkwoorden en hun tijden, etc.

Aan de hand van de context probeert de labeling onderscheid te maken tussen de ver-

schillende mogelijkheden, bijvoorbeeld “eten” kan een werkwoord zijn of een zelfstandig

naamwoord. Voor PETAR wordt TwitterNLP [19] gebruikt als POS labeling.

2. Tegen Out Of Vocabulary (OOV) woorden, zoals spellings- en typfouten, wordt Brown

clustering [20] gebruikt. Dit is een hierarchische, agglomeratieve, clustering die gelijk-

aardige woorden groepeert, op basis van de context waarin ze voorkomen. Als invoer is

een zo groot mogelijke set van zinnen nodig en als uitvoer wordt een bitstring gegeven

voor ieder woord, die zijn classificatie voorstelt op verschillende niveaus (afhankelijk

hoeveel karakters men neemt). Dit is een tijdsintensief werk dat best op voorhand ge-

beurt. Voor deze implementatie wordt de repository uit [21] gebruikt. De clustering

wordt op voorhand berekend aan de hand van een opgehaalde gegevensset. Voor ieder

woord worden de clusters op basis van bit vier, acht en twaalf bijgehouden als kenmerk.

3. De time-trend score van een bericht is het gemiddelde van de time-trend scores van

zijn woorden en bepaalt de temporal awareness. Hiervoor wordt initieel een lijst opge-

steld met een 40-tal woorden die de tijd aanduiden zoals modaalwerkwoorden: {“will”,

“would”}, hulpwerkwoorden: {“be”, “is”, “am”} en adjectieven of bijwoorden: {“tomorrow”,

“future”, “yesterday”}. Al deze woorden krijgen een score op basis van hun tijdsaan-

duiding: -1 voor het verleden, 0 voor het heden en 1 voor de toekomst. Per woord in

het bericht gebeurt de toekenning van de time-trend score in drie stappen:


(a) Als het woord een woord uit de verzameling is, krijgt hij de bijhorende score.

(b) Komt het woord niet voor in de verzameling, dan nemen we alle gelijkaardige

woorden uit de Brown clustering gebaseerd op het twaalfde bit. Alleen als alle

woorden in de cluster dezelfde time-trend score hebben wordt deze score toegekend

aan dit woord.

(c) Tenslotte nemen we, met behulp van de POS labeling, alle werkwoorden uit de

tweet die geen score kregen in de vorige twee stappen en geven hen een score op

basis van de tijd van de werkwoorden in het bericht (aangeduid door het POS

label).

4. Het werkwoord dat het dichtst ligt bij de POI kandidaat krijgt een label op basis van

zijn tijd1 (zie POS label) uit de lijst {“pst”, “pre”, “prep”}. Ten slotte wordt ook nog

de afstand en de positie (links of rechts) van het dichtste werkwoord bijgehouden als

kenmerk.

In Listing 5.6 wordt een codevoorbeeld getoond, dat nu wordt toegelicht. De me-

thode gramm closest verb krijgt als parameters: het bericht met zijn POS labels

(pos tweet), een lijst van de tokens van het bericht (word list) en ten slotte de begin-

en eindindex van de POI kandidaat in word list. Eerst worden de werkwoorden, samen

met het label dat hun tijd aanduid, uit het POS bericht gehaald. Vervolgens wordt de

index van het werkwoord, dat het dichtst bij de POI kandidaat ligt, gezocht. Aan de

hand van deze index kunnen de drie kenmerken in het features woordenboek worden

ingevuld.

Listing 5.6: Informatie extractie van het werkwoord dat het dichtst bij een POI kandidaat ligt.

def gramm_closest_verb(pos_tweet , word_list , poi_start , poi_end):

features = dict(); verbs = list()

for verb in re.findall("(?:\s|)(\S*?) (?:/\S*?) *(/VB[NDZPG ]{0 ,1})\S*?(?:\s|$)"

↪→ , pos_tweet):

verbs.append(tuple(verb))

if len(verbs):

closest = word_list.index(verbs [0][0])

closest_dist = poi_start -closest if poi_start -closest >0 else closest -

↪→ poi_end

for verb in verbs:

l = poi_start - word_list.index(verb [0])

r = word_list.index(verb [0]) - poi_end

if l > 0 and l < closest_dist:

closest_dist = l

closest = word_list.index(verb [0])

elif r > 0 and r < closest_dist:

1De POS labels voor werkwoorden zijn VBN: voltooid deelwoord; VBD: verleden tijd; VBZ: derde per-

soon enkelvoud tegenwoordige tijd; VBP: niet-derde persoon enkelvoud tegenwoordige tijd; VBG: onvoltooid

deelwoord; VB: basis vorm.


closest_dist = r

closest = word_list.index(verb [0])

tense = [t[1] for t in verbs if t[0] == word_list[closest ]][0]

if tense in [’/VBN’, ’/VBD’]:

features[’tense ’] = ’pst’

elif tense in [’/VBG’]:

features[’tense ’] = ’prep’

else: # [’/VBZ ’, ’/VBP ’, ’VB ’]

features[’tense ’] = ’pre’

features[’distance ’] = poi_start -closest if closest < poi_start else

↪→ closest - poi_end

features[’position ’] = ’left’ if closest < poi_start else ’right ’

return features

else:

return None

5. Van het dichtste woord, dat een time-trend kreeg, bij de POI kandidaat worden ook

een aantal zaken bijgehouden: het woord zelf, zijn time-trend score, zijn afstand tot de

POI kandidaat en zijn positie (links of rechts ervan). De implementatie is analoog aan

Listing 5.6.

Bemerk dat deze drie laatste kenmerken enkel een invloed hebben op de tijdsaanduiding van

een plaatsnaam en niet op de precisie ervan[2].

5.2.3 Geografische kenmerken

Er zijn drie geografische kenmerken.

1. Het grondgebied waar de berichten over gaan (bijvoorbeeld een stad) wordt verdeeld in

een evenredig rooster met S vakjes. Elk vak heeft ten minste een check-in tweet . Voor

elke kandidaat POI, l, wordt de ruimtelijke toevalscoefficient (of spatial randomness,

0 ≥ R(l) ≥ 1, berekend, zo dat een POI naam die slechts in een vakje voorkomt R(l)

gelijk aan 0 heeft. POI namen als McDonald’s of Starbucks hebben dus een veel grotere

R(l) aangezien ze vaak voorkomen in meerdere vakjes. Stel kl het totaal aantal check-in

tweets die l bevatten en stel kl,s het totaal aantal check-in tweets die l bevatten en die

in vakje s vallen. De kans dat l geassocieerd is met s is dan: P (l, s) =kl,skl

. R(l) is dan

de genormaliseerde entropie, en wordt berekend met formule 5.1.

R(l) = − 1

log(|S|)∑s∈S

P (l, s) logP (l, s) (5.1)

Aangezien de ruimtelijke toevalscoefficient vast ligt per POI kan deze berekend worden

bij het opstellen van de POI inventory . Codevoorbeeld 5.7 kan dus worden toegevoegd


achter de methode in listing 5.3. De methode add spatial randomness stelt eerst en

vooral een lijst op met alle vakjes met minstens een check-in tweet . Daarna wordt voor

iedere POI de ruimtelijke toevalscoefficient berekend.

Listing 5.7: Berekenen van de ruimtelijke toevalscoefficient voor alle plaatsnamen.

S_GRID = [[[] for y in xrange (360)] for x in xrange (180)]

for poi in ALL_POI:

S_GRID[int(poi[’lat’]) + 90][ int(poi[’lon’]) + 180]. append(poi[’poi’])

def add_spatial_randomness ():

s_list = list()

for latitude in range (180):

for longitude in range (360):

if len(S_GRID[latitude ][ longitude ]) > 0:

s_list.append ((latitude , longitude))

for poi in ALL_POI:

kl = ALL_POI[poi][’count ’]; s_sum = 0

for s in s_list:

kls = 0

for text in S_GRID[s[0]][s[1]]:

if re.search(re.escape(poi), text.lower()):

kls += 1

P_ls = kls / (float(kl) if kl != 0 else 1)

s_sum += P_ls * (math.log(P_ls) if P_ls != 0.0 else 0)

R_l = (-1 / math.log(len(s_list))) * s_sum

ALL_POI[poi][’spatial_randomness ’] = R_l

2. Een hoge ruimtelijke toevalscoefficient hoeft niet noodzakelijk een restaurantketen te

zijn, zoals in het voorbeeld hierboven. POI namen als “room”, “bus” en “center” zullen

ook een zeer hoge score tonen. Daarom wordt hier de betrouwbaarheidscoefficient, F (l),

van de plaatsnaam (of location name confidence) berekend. De betrouwbaarheid wordt

berekend aan de hand van het aantal woorden in de POI kandidaat. Meer woorden

betekent een grotere betrouwbaarheid[2]. Stel µi en σi gelijk aan het gemiddelde en de

standaardafwijking van alle kl’en met i woorden. F (l) voor l met i woorden wordt dan

berekend met formule 5.2.

F (l) =1

1 + e−5 (kl−µi)

σi

(5.2)

Een codevoorbeeld wordt getoond in Listing 5.8 en kan wederom worden toegevoegd

aan de code voor het opstellen van de POI inventory .

Listing 5.8: Berekenen van de betrouwbaarheidscoefficient voor alle plaatsnamen.

def add_location_name_conf ():

count_by_length = dict(); all_counts_by_length = dict()

for poi in ALL_POI:

key = str(len(poi.split ()))

count_by_length[key] = count_by_length.get(key , 0) + ALL_POI[poi][’

↪→ count’]


all_counts_by_length.setdefault(key , []).append(ALL_POI[poi][’count’

↪→ ])

# Average and deviation poi mentions in check -in tweets by length

avg_count_by_length = dict(); dev_count_by_length = dict()

for l in count_by_length:

avg_count_by_length[l] = count_by_length[l] / float(len(

↪→ all_counts_by_length[l]))

c_sum = 0

for c in all_counts_by_length[l]:

c_sum += (c-avg_count_by_length[l])**2

dev_count_by_length[l] = c_sum / float(len(all_counts_by_length[l]))

for poi in ALL_POI:

l = str(len(poi.split ()))

k_l = ALL_POI[poi][’count’]

F_l = 1 / (1 + math.e ** (-5 * (k_l - avg_count_by_length[l]) /

↪→ dev_count_by_length[l])) if dev_count_by_length[l] != 0 else 1

ALL_POI[poi][’location_name_confidence ’] = F_l

3. Als een tweet meerdere POI kandidaten heeft, is de kans groter dat ze allemaal POI’s

voorstellen [2]. Daarom wordt als laatste geografische kenmerk een binair veld toege-

voegd dat aangeeft of er meerdere POI kandidaten in de tweet zitten of niet.

5.2.4 BILOU-schema kenmerk

BILOU-schema is een techniek uit de NER die hier wordt gebruikt om voor een POI naam,

bestaande uit meerdere woorden, een Beginning , Inside en Last label te geven en voor een

enkelvoudige POI naam de Unit-length toe te wijzen. Woorden die buiten de POI naam

vallen krijgen een Outside label. Pas als alle kandidaat plaatsnamen in het bericht gevonden

zijn kunnen de BILOU-schema labels worden toegewezen.

5.2.5 CRF labeling

De laatste stap in de plaatsbepaling is voor iedere kandidaat plaatsnaam aanduiden of het

wel degelijk een plaatsnaam is of niet. Op die manier worden ongeldige kandidaten zoals

“home” of “office” weggefilterd. De voorgestelde tool , voor PETAR, in [2] is CRF++. Het

werken met CRF++ is volledig beschreven in [22]. Het programma wordt eerst getraind door

de woorden van een aantal berichten handmatig te labelen met NPOI, Unknown, POIp,

POIz en POIf . De laatste drie duiden er op dat de kandidaat effectief een locatie aanduid

en specifieren respectievelijk een tijdsaanduiding in het verleden, het heden en de toekomst.

NPOI wijst er op dat de kandidaat geen locatie aanduid en Unknown dat het niet kan

worden afgeleid uit de context. Met deze leerset kan het programma dan getraind worden om

nieuwe berichten te labelen.


5.3 Conclusies

In dit hoofdstuk werd een methode besproken voor het herkennen van plaatsnamen in een

bericht. Aangezien PETAR is ontwikkeld als systeem om de locatie van de berichtgever te

achterhalen, in plaats van de locatie van de context, werden voor deze masterproef enkele

wijzigingen gedaan aan het originele model. In het geval dat een bericht meerdere locaties

bevat is het moeilijk te zeggen welke effectief verwijst naar de ramp en welke niet. Daarom

zullen alle locaties als even belangrijk beschouwd worden. Vervolgens is het temporele aspect

van de locatienamen minder van belang, aangezien het niet uitmaakt wanneer de berichtgever

daar precies was. Zolang er een locatienaam voorkomt in een bericht, zal deze dus gelinkt

worden aan een event. De implementatie voor het prototype zal dus geen gebruik maken van

de kenmerken die uitsluitend invloed hebben op de tijdsaanduiding.

Figuur 5.3 geeft een overzicht van alle kenmerken die gebruikt werden voor de implementatie

van het systeem in deze masterproef. Behalve de POS labeling en de Brown clustering, zijn

alle methoden zelf geschreven. De twee bovenste groepen, “Lexicaal” en “Grammaticaal”

kunnen zonder een POI inventory ook worden gebruikt. Dit kan handig zijn als er niet

genoeg check-in tweets zijn verzameld in een bepaald gebied, maar men toch een overzicht

wenst van de ramp (met een aangepaste methode voor de visualisatie weliswaar).

Figuur 5.3: Een overzicht van de kenmerken voor de locatiebepaling, gebruikt in deze masterproef.

Hoofdstuk 6

Alarmdetectie

In de vorige fase (Hoofdstuk 4) werden de locatie en het onderwerp gezocht voor ieder bericht

apart en werd deze data opgeslagen in events. Deze worden pas betrouwbaar als er zich een

groot aantal rond dezelfde plaats bevinden, en binnen dezelfde tijdspanne optreden. Eens

betrouwbaar spreken we van een alarm. Zo’n alarm bestaat dus uit meerdere events, binnen

hetzelfde gebied en binnen dezelfde tijd. Alarmen zullen dus steeds in het centrum van

hun overkoepelende gebied worden geplaatst in plaats van op een specifieke coordinaat. Er

wordt hier dus ietwat afgeweken van de definitie gegeven in [1], die aan de hand van de

informatieruimte, gegeven voor alle informatie uit alle berichten, met een semantic reasoner

de alarmen detecteert.

De volgende stap in onze applicatie is het indelen van de events in gebieden, op basis van

tijd, zodat er uit het resultaat eenvoudig een tijdruimtelijk overzicht van het aantal events

kan worden opgevraagd. Aan de hand van dit overzicht kunnen dan de alarmen worden

gedetecteerd. Figuur 6.1 toont de verschillende stappen in het omzetten van de set met

events naar effectieve alarmen.

Figuur 6.1: De verschillende stappen in het omzetten van events naar mogelijke alarmen.

Merk op dat alarmen niet apart worden opgeslagen in de databank, maar steeds opnieuw

38

Hoofdstuk 6. Alarmdetectie 39

worden berekend uit de set van events.

6.1 Indelen van de events in een rooster

Om de events in te delen in hun gebieden werd over de wereldkaart een rooster getekend.

De grootte van de vakjes van dit rooster is, bij deze masterproef, een breedtegraad op een

lengtegraad, wat overeenkomt met gemiddeld 110x110 km. Dit zijn vrij grote gebieden, maar

de code kan heel eenvoudig worden aangepast naar een tiende of honderdste van de grootte.

In Figuur 6.2 is het rooster te zien over Belgie.

Figuur 6.2: Het verdelingsrooster als aanduiding van de gebieden.

Door te werken met breedte- en lengtegraden is het heel eenvoudig om de events te verde-

len over het rooster. Codevoorbeeld 6.2 laat zien hoe alle events in een tweedimensionale

lijst (stelt het rooster voor) kunnen worden verdeeld, op basis van het type event en de

tijdspanne. Eerst wordt het tijdstip van het eerste bericht (FIRST DATE) en van het laatste

bericht (LAST DATE) achterhaald. Daarna kan de methode calculate grid worden opgeroe-

pen, die eerst op basis van het argument type, de zoekopdracht samenstelt en vervolgens alle

gevonden events in een rooster, event grid, steekt met de breedtegraad (bereik van −90 tot

+90 wordt omgezet naar 0 tot +180) als eerste en de lengtegraad (bereik van −180 tot +180

wordt omgezet naar 0 tot +360) als tweede index.

Listing 6.1: Indelen van de events in een tijdruimtelijk rooster.

import pymongo

Hoofdstuk 6. Alarmdetectie 40

EVENTS_DB = pymongo.MongoClient(’localhost ’, port =27017).db.some_events

FIRST_DATE = EVENTS_DB.find().sort ([(’timestamp ’, pymongo.ASCENDING)]).limit (1) [0][’

↪→ timestamp ’]

LAST_DATE = EVENTS_DB.find().sort ([(’timestamp ’, pymongo.DESCENDING)]).limit (1) [0][’

↪→ timestamp ’]

def calculate_grid(type=’all’, time_from=FIRST_DATE , time_until=LAST_DATE):

if type == ’all’:

query = {’timestamp ’:{’$gte’:time_from , ’$lt’:time_until }}

else:

query = {’type’:type , ’timestamp ’:{’$gte’:time_from , ’$lt’:time_until }}

event_grid = [[0 for y in xrange (360)] for x in xrange (180)]

for event in EVENTS_DB.find(query):

event_grid[int(event[’source ’][1]) +90][ int(event[’source ’][0]+180)] += 1

return event_grid

Met behulp van deze methode kan men dus bijvoorbeeld een rooster opvragen van alle events

met type “injured” in de laatste drie uur.

6.2 Detectie van de alarmen

Nu rest alleen nog het overlopen van het bekomen rooster, en een alarm notificeren voor een

bepaald aantal events. Codevoorbeeld 6.2 toont hoe zoiets zou kunnen worden geımplementeerd.

Er wordt eerst een event rooster, event grid, gemaakt aan de hand van de methode calculate grid

uit Listing 6.2 met als type “injured” en als tijdspanne de laatste drie uren. Daarna worden

de lengte- en breedtegraden van de gebieden met minstens 25 events uitgeschreven.

Listing 6.2: Alarmen zoeken in de laatste drie uur.

import datetime

from datetime import timedelta

now = datetime.datetime.now()

event_grid = calculate_grid(type=’injured ’, first_date=now -timedelta(hours =3),

↪→ last_date=now)



if event_grid[latitude ][ longitude] >= 25:

box = ’(’ + str(longitude -180) + ’,’ + str(latitude -90) + ’)’

print "Injured alert at %s" % (box)

Het aantal events dat een alarm oplevert is een maat die niet vast staan maar afhankelijk is

van de ramp en meer bepaald hoeveel mensen getroffen worden door die ramp. Ze blijft dus

best aanpasbaar.

Hoofdstuk 7

Informatievoorstelling

Er zijn heel wat manieren om de bekomen informatie voor te stellen, zodat alarmen ge-

bruiksvriendelijk kunnen worden voorgelegd aan de gebruiker. In de vorige sectie werd het

standaardformaat aangetoond waarmee de events kunnen worden voorgesteld. De visualisatie

focust zich zowel op het tonen van de events als van de alarmen, maar werkt steeds vanuit

de dataset van events. Aangezien de nadruk van deze masterproef ligt op de analyse van de

data, wordt de visualisatie redelijk basis gehouden. Er wordt gebruik gemaakt van de Python

bibliotheek matplotlib, en de Basemap toolkit , om alle alarmen of events op een kaart te

vermelden. Voor de visualisatie van events worden de verschillende types in een andere kleur

getekend. De implementatie is sterk gebaseerd op [23], aangevuld met voorbeelden uit [24].

De alarmen worden getoond door in het midden van hun domein een punt te zetten, waarvan

de grootte evenredig is met het aantal events. Alle visualisaties kunnen worden aangepast

naar een bepaald type event en binnen een bepaalde tijdspanne.

7.1 Een wereldkaart tekenen met matplotlib

Om te beginnen wordt een Robinson projectie getekend, met enkele basisopties zoals kustlij-

nen en landgrenzen.

Listing 7.1: Eenvoudige wereldkaart tekenen met matplotlib.

from mpl_toolkits.basemap import Basemap

import matplotlib.pyplot as plt

import numpy as np

map = Basemap(projection=’robin’,resolution = ’l’,area_thresh =1000.0 , lat_0=0,lon_0 =0)

map.drawcoastlines ()

map.drawcountries ()

map.fillcontinents(color=’coral ’)

map.drawmapboundary ()

map.drawmeridians(np.arange(0, 360, 30))

41

Hoofdstuk 7. Informatievoorstelling 42

map.drawparallels(np.arange(-90, 90, 30))

plt.show()

Codevoorbeeld 7.1 stemt overeen met het resulaat in figuur 7.1.

Figuur 7.1: Basis wereldkaart getekend met matplotlib

7.2 Punten op de kaart tekenen

De coordinaten die de events of alarmen beschrijven bestaan allemaal uit lengtegraad, breed-

tegraad paren. Met de plot functie van Basemap kunnen deze op de kaart worden getekend.

De code in listing 7.2 wordt toegevoegd aan listing 7.1, net voor de plt.show() procedure. Bij

wijze van voorbeeld zijn lijsten met breedtegraden en lengtegraden aangemaakt die werden

uitgetekend.

Listing 7.2: Punten tekenen op de wereldkaart.

lons = [ -135.3318 , -134.8331 , -134.6572]

lats = [57.0799 , 57.0894 , 56.2399]

x,y = map(lons , lats)

map.plot(x, y, ’ro’, markersize =10)

Met dit voorbeeld wordt na inzoomen figuur 7.2 bekomen.


Figuur 7.2: Basis wereldkaart met enkele punten, getekend aan de hand van matplotlib

7.3 Visualisatie van events per type

Zoals reeds aangehaald kunnen alle events op dezelfde kaart worden getoond, elk met hun

eigen kleur. Listing 7.3 bevat twee functies. De functie plot events neemt een eventtype, een

kleur voor het punt, en een tijdspanne. Daarna haalt zij alle nodige events uit de databank,

met behulp van de MongoDB instantie EVENTS DB, en tekent ze op de juiste coordinaten. Het

bekomen van de standaardwaarden voor time from en time until is analoog aan de methode

uit het vorige hoofdstuk.

De functie plot all events tekent, binnen een bepaalde tijdspanne, voor alle mogelijke

events alle punten uit, waarbij die met het type “damaged” in het geel komen, die met

het type “dead” in het rood en die met het type “injured” in het groen.

Listing 7.3: Events tekenen op de wereldkaart.

def plot_events(type , marker_color=’ro’, time_from=FIRST_DATE , time_until=LAST_DATE):

lats = list(); lons = list()

for event in EVENTS_DB.find({ ’type’:type , ’timestamp ’:{’$gte’:time_from , ’$lt’:

↪→ time_until }}):

lons.append(event[’source ’][0])

lats.append(event[’source ’][1])

x,y = map(lats , lons)

map.plot(x, y, marker_color , markersize =7)

def plot_all_events(time_from=FIRST_DATE , time_until=LAST_DATE):

plot_events(’damaged ’,marker_color=’yo’,time_from=time_from ,time_until=time_until)

plot_events(’dead’,marker_color=’ro’,time_from=time_from , time_until=time_until)

plot_events(’injured ’,marker_color=’go’,time_from=time_from ,time_until=time_until)


Figuur 7.3 is een voorbeeld van een overzicht, gegenereerd met behulp van de functie plot all events.

De afbeelding stelt het oosten van de Verenigde Staten voor. Het valt op dat vooral de oost-

kust geteisterd wordt door de ramp, maar er toch overal berichten verschijnen.

Figuur 7.3: Visualisatie van events.

7.4 Visualisatie van alarmen

De voorstelling van de alarmen kan er dan, met dezelfde data als in vorige sectie, uitzien als

in Figuur 7.4. De limiet van het aantal events voor een alarm is hierbij ingesteld op twintig.

Nu is duidelijk zichtbaar welke regio’s er het zwaarst getroffen worden door de ramp. Op

hoeveel deze limiet moet staan hangt enorm af van hoeveel events er worden binnengehaald

en hoe lang de tijdspanne is. Het is dan ook sterk aangeraden om deze niet hard te coderen,

maar eerder op het moment zelf af te toetsen aan de hand van reeds verkregen informatie.


Figuur 7.4: Visualisatie van alarmen.

Figuur 7.4 is getekend met behulp van de functie draw grid uit Listing 7.4. Deze methode is

sterk analoog aan de functie calculate grid uit Listing 6.2. ook hier wordt eerst een rooster

opgesteld op basis van de ingevulde variabelen. Daarna wordt op het middelpunt van elk

roostervakje een punt getekend, waarvan de grootte evenredig is met het aantal events in dat

gebied.

Listing 7.4: Alarmen tekenen op de wereldkaart

def draw_grid(type=’all’, marker_color=’co’, time_from=FIRST_DATE , time_until=

↪→ LAST_DATE , label=True , min_num_of_tweets =10):

if type == ’all’:

query = {’time’:{’$gte’:time_from , ’$lt’:time_until }}

else:

query = { ’type’:type , ’timestamp ’:{’$gte’:time_from , ’$lt’:time_until }}

event_grid = [[0 for x in xrange (360)] for x in xrange (180)]

for event in EVENTS_DB.find(query):

event_grid[int(event[’source ’][1]) +90][ int(event[’source ’][0]+180)] += 1

lats = list(); lons = list(); magnitudes = list();

num_events = EVENTS_DB.count(query)



if event_grid[latitude ][ longitude] >= min_num_of_tweets:

lats.append(latitude -90)

lons.append(longitude -180)

magnitudes.append(event_grid[latitude ][ longitude ])


for lon , lat , mag in zip(lons , lats , magnitudes):

x, y = map(lat -0.5, lon +0.5)

mag_perc = mag / float(num_events)

map.plot(x, y, marker_color , markersize=mag_perc *200)

if label:

plt.text(x, y, mag , ha=’center ’, va=’center ’)

Hoofdstuk 8

Het Prototype

In dit hoofdstuk wordt, aan de hand van de uitgebouwde architectuur in de voorgaande delen,

een prototype ontworpen en geımplementeerd die met behulp van een aantal gegevenssets

wordt gesimuleerd en geevalueerd. Het eerste deel bespreekt de gebruikte gegevenssets en hoe

die opgehaald werden. Vervolgens worden de modellen uit voorgaande hoofdstukken een voor

een toegepast en geevalueerd.

8.1 De Gegevenssets

Omdat er voor dit onderzoek geen real time data kon worden gebruikt, is er uitvoerig gebruik

gemaakt van gegevenssets. In dit onderdeel wordt kort gekeken naar welke gegevenssets er

gebruikt zijn, en hoe die zijn opgehaald. Alle gegevenssets bevatten namelijk tweet ID’s die

verwijzen naar een tweet in de Twitter databank, en kunnen opgehaald worden via de API.

Dit is een overzicht van de gebruikte sets:

� 3 381 geotagged tweets over de Colorado Wildfires van 2012. Deze set is besproken

in [25] en komt uit een van de collecties van [17], een opslagplaats voor crisis-related

sociale media data en tools. De tijdspanne van de berichten is van 2012-06-08 06:22:06

tot 2012-07-09 03:46:04 (ongeveer 1 maand).

� 80 331 geotagged tweets over Hurricane Sandy van 2012. Deze set is besproken in

[12]. Origineel telde de set meer dan 6 miljoen tweets, maar dit werd een heel pak minder

na het filteren op berichten die effectief het woord “sandy” bevatten1. De tijdspanne

van de berichten is van 2012-10-22 05:55:15 tot 2012-11-02 04:49:14 (ongeveer 10 dagen).

1Deze dataset werd samengesteld op basis van de locatie van de gebruiker. Als deze in de buurt was van

de orkaan, dan werd het bericht toegevoegd. Aangezien deze masterproef zich enkel richt op tekstuele data

werden dus, aan de hand van deze filter, de berichten over de orkaan zelf afgescheiden van de rest. In een echte

situatie zou uiteindelijk hetzelfde gebeuren in de datavergaringsfase.

47

Hoofdstuk 8. Het Prototype 48

� 422 457 tweets over de aanslagen in Parijs van 13 november 2015. Dit is een deel

van de collectie uit [26]. Alle berichten zijn verstuurd op de dag zelf. De tijdspanne van

de berichten is van 2015-11-13 21:17:59 tot 2015-11-13 22:33:47 (ongeveer 1 uur).

8.1.1 Ophalen van de gegevenssets

Aangezien alle dataverzamelingen bestaan uit tweet ID’s moeten deze eerst worden opgehaald

uit de Twitter API. Jammer genoeg is het onmogelijk om alle miljoenen tweets na elkaar op

te halen door de Twitter API rate limits. Deze limiet bepaalt dat men per account maximum

18 000 tweets kan ophalen per kwartier2.

Listing 8.1: Aan de hand van tweet ID’s tweets ophalen via tweepy

import tweepy

authHandler = OAuthHandler(’my_consumer_key ’, ’my_consumer_secret ’)

authHandler.set_access_token(’my_access_token ’, ’my_access_token_secret ’)

for status in tweepy.API(authHandler).statuses_lookup(some_tweet_ids):

print status

In listing 8.1 toont een codevoorbeeld hoe de tweets via hun ID worden opgehaald. De methode

statuses lookup neemt een lijst met maximum 100 ID’s en geeft al deze tweets terug met een

enkel antwoord. Voor deze masterproef is een script dat deze methode gebruikt opgesteld en

om het kwartier uitgevoerd door middel van het Linuxprogramma Crontab. Op een volledige

dag kunnen zo meer dan anderhalf miljoen tweets worden opgehaald.

8.1.2 Achtergrondinfo over de rampen

De Colorado Wildfires van 2012. Deze waren een reeks van ongewoon verwoestende

branden gedurende de periode van juni tot augustus 2012. De branden waren moeilijk te

controleren door de droge winter van hetzelfde jaar. In totaal worden er zo’n veertien branden

tot deze groep gerekend zoals: the Flagstaff Fire en the Highpark Fire [27].

2180 GET requests met 100 tweets per request


Figuur 8.1: Overzicht van de branden in Colorado, 2012. (bron: thetrendguys.com)

Hurricane (of orkaan) Sandy van 2012. Volgens Wikipedia is dit de achttiende storm

en tiende orkaan van het Atlantisch orkaanseizoen 2012. Ze richtte al schade aan in Jamaica,

de Bahama’s, Haıti en Florida en was daarna actief aan de oostkust van de Verenigde Staten

en in het oosten van Canada. Sandy ontstond op 22 oktober 2012 als tropische golf in het

westen van de Caraıbische Zee. Reeds na zes uur werd ze een tropische storm waarna ze zich

naar de Grote Antillen voortbewoog. Op 24 oktober kwam ze aan op Jamaica als orkaan.

Sandy ontwikkelde zich in de avond van 25 oktober tot de tweede categorie en kwam aan op

Cuba. Daarna zwakte ze af tot de eerste categorie en bewoog ze zich noordwaarts voort over

de Bahama’s. Toen had de orkaan reeds 67 slachtoffers gemaakt. In de nacht van 29 oktober

op 30 oktober bereikte Sandy als superstorm de oostkust van de Verenigde Staten, waarna ze

nog meer in kracht afzwakte en zich naar het noorden bewoog. Boven het oosten van Canada

is de storm op 31 oktober opgelost[28]. Een overzicht van de storm is te zien in Figuur 8.2.


Figuur 8.2: Overzicht van het vernielingspad van orkaan Sandy. (bron: mapbox.com)

Aanslagen in Parijs van 13 november 2015. Deze omvatten een zestal terroristische

aanslagen in de avond en nacht van 13 november 2015. Vijf aanslagen vonden plaats in het

tiende en elfde arrondissement van de Franse hoofdstad, een zesde aanslag werd gepleegd in

de voorstad Saint-Denis. Tijdens de aanslagen vielen 129 doden en meer dan 350 gewonden

van wie er daags na de aanslagen nog veel in kritieke toestand verkeerden. Een zwaargewonde

overleed een week later waardoor het totale dodentol op 130 kwam[29]. Figuur 8.3 geeft een

overzicht van de aanslagen op die dag.

Figuur 8.3: Overzicht van de terroristische aanslagen in Parijs op 13 november 2015. (bron: BBC)

De vraag voor de evaluatie van het systeem is dus in welke mate dezelfde trends uit de Twitter


datasets kan worden gehaald.

8.2 Informatievergaring en voorbereiding

Eenmaal de tweets waren opgehaald werden alle berichten opnieuw opgeslagen onder het

standaardformaat. Voor elk bericht werden ook de tokens berekend.

8.3 Datamining

In een eerste fase werd de Naıve Bayes classificeerder gebruikt om alle nuttige berichten te

behouden en de rest weg te filteren. Daarna werden deze berichten ingedeeld per onderwerp:

“dead”, “injured” of “damaged”. Ten slotte werd ook de locatie bepaald. Alle methoden zijn

reeds besproken in Hoofdstuk 4, hier volgt de uitleg over de effectieve implementatie op de

datasets.

8.3.1 Wegfilteren van de irrelevante data

In een eerste stap worden de berichten die nuttige informatie bevatten uit de set gehaald door

middel van de Naıve Bayes classificeerder, geımplementeerd volgens de NLTK bibliotheek (alle

details staan in sectie 4.2.2). Hiervoor moet natuurlijk eerst een leerset worden opgesteld.

Een groot voordeel van Naıve Bayes is dat zij geen grote leerset vereist om degelijke resultaten

op te leveren[30]. De set moet enerzijds groot genoeg zijn om de beste resultaten te bekomen

en anderzijds niet te groot, zodat zij op het moment van de ramp snel kan worden opgesteld.

Een grootte van 200 berichten leek een ideaal compromis. Bij alle drie de leersets werden

zowel heel wat relevante als irrelevante berichten gevonden terwijl de tijd voor het labelen

beperkt bleef.

Als leerset werden voor iedere dataset 200 berichten handmatig gelabeld als relevant (“R”) of

niet relevant (“NR”). De vereisten voor een relevant bericht is de mate waarin het informatie

kan bieden aan de hulpdiensten. Met andere woorden, of er een duidelijke locatie en type

noodgeval in beschreven staat. Voorbeelden van relevante berichten zijn:

1. “RT MarwaMfarid: Death toll in #Paris shootings rise to 26 + 60 hostages via @AP”

2. “RT metesohtaoglu: #Paris: Shooting in a restaurant,#Bataclan concert hall,explosion

outside Stade de France Breaking3zero URL”

3. “RT reportedly: VIDEO: Automatic gunfire in #Paris #bataclan #fusillade URL”

Voorbeelden van irrelevante berichten zijn:

1. “Thinking of everyone in Paris. One of my favorite cities #Paris”


2. “This is too fucking awful. Will this shit ever end? #Paris”

3. “Explosion en #Paris mientras se jugaba el #Francia #Alemania URL”

Volgende lijst toont de resultaten van het systeem op de datasets:

� Colorado Wildfires: Uit de 3 381 berichten werden er 228 als relevant aangeduid,

wat overeenkomt met 6.74%.

� Orkaan Sandy: Uit de 80 331 berichten werden er 26 als relevant aangeduid, wat

overeenkomt met 0.03%.

� Aanslagen in Parijs: Uit de 422 457 berichten werden er 95 313 als relevant aangeduid,

wat overeenkomt met 22.56%.

Volgende vaststellingen konden worden gedaan uit de resultaten aan de hand van de hand-

matig gelabelde berichten.

Uit orkaan Sandy is dus slechts heel weinig nuttige informatie te halen. Een reden hiervoor

zou kunnen zijn dat de ramp niet zo’n gigantische impact heeft gehad in het gebied waarvan

de berichten afkomstig zijn. De dataset eens van dichterbij bekijken toont aan dat de storm

in dit gebied verre van serieus wordt genomen:

1. “All stocked up on wine. Ready to hide inside for a couple of days. #Sandy”

2. “hurricane drinking playlist set. everytime ”sandyor ”hurricaneıs said everyone drink!”

3. “I love storms. Bring it on #sandy. Bed early, heating pad for huge knot in my back,

sleeping late. #excited #nightnight”

4. “Wow this sandy storm is really rippin up mactown #not”

5. “Sippin on some brew ready for this bitch sandy”

Bij de andere twee rampen is er ook een groot verschil tussen percentage relevante berichten.

De Colorado Wildfires dataset werd opgehaald op basis van de locatie en niet op basis van een

relevante hashtag . De set van de aanslagen in Parijs bevat dus automatisch alleen berichten

die verstuurd werden over de ramp. De meeste niet relevante berichten van deze laatste zijn:

steunbetuigingen, paniekreacties of berichten in een andere taal.

De Naıve Bayes classificeerder behaalde zeer veelbelovende resultaten voor alle datasets. Voor

de set van Parijs namen we willekeurig, verspreid over de volledige set, 200 berichten en telden

het aantal false positives en negatives. Zo was slechts 4% false positive en 3% false negative.


8.3.2 Bepaling van de locatie

De locatie bepalen van de berichten in de datasets, met behulp van het besproken systeem in

Sectie 4.3.2, legt enkele eisen op aan de berichten. Ten eerste moeten er voldoende check-in

tweets zijn om een POI inventory te construeren die de meeste plaatsnamen inhoudt. Ten

slotte moeten genoeg berichten voorzien zijn van een plaatsnaam, om een leerset te krijgen

die voldoende informatie bevat om alle overige berichten te labelen.

Zoals reeds vermeld in Sectie 4.3.2 is de tijdsaanduiding, wanneer de berichtgever op die

locatie was, minder van belang voor deze masterproef. De kenmerken die enkel een bijdrage

leveren aan de detectie van die tijdsaanduiding worden zo weggelaten. Verder wordt de POI

inventory er pas achteraf bijgehaald, na het labelen van de berichten. Op die manier wordt

het probleem van een tekort aan check-in tweets aangepakt. Dat maakt een minimum van

negen kenmerken, gegroepeerd uit 28 feiten, voor ieder woord:

1. Het woord zelf en het woord in kleine letters (a), de vorm van het woord (b), de 3-letter

prefixen en suffixen (c) en de waarschijnlijkheid dat het woord begint met een grote

letter of volledig in grote letters staat (d).

2. Twee voorgaande woorden + woord + twee volgende (e), twee voorgaande (f) en de

twee volgende (g)

3. POS etiketten van het vorige woord, het huidige woord en het volgende woord (h)

4. De vierde, achtste en twaalfde bits van de woord groep, gebaseerd op Brown clustering

(i)

Als de POI inventory wel aanwezig is, worden ook volgende drie kenmerken beschouwd voor

alle woorden in de kandidaat plaatsnamen. De overige woorden krijgen een NULL (of None in

Python):

1. De ruimtelijke toevalscoefficient (j)

2. De Betrouwbaarheidscoefficient (k)

3. Of er meerdere kandidaat plaatsnamen zijn in dit bericht of niet (l)

Aangezien het BILOU-schema kenmerk wegvalt is het niet helemaal duidelijk waar de plaats-

namen beginnen en eindigen. Daarom werden de labels aangepast naar deze drie: NPOI,

BPOI en IPOI. Respectievelijk staan ze voor No, Beginning of en Inside of Point Of Inte-

rest . Een voorbeeld van de labeling, uit het bericht “Large wildfire in N. Colorado prompts

evacuations” is gegeven in Tabel 8.1. In dit bericht zit dus een effectieve plaatsnaam, name-

lijk “N. Colorado”. Enkel “Colorado” was ook te vinden in de POI inventory waardoor enkel

hij waarden heeft voor kenmerken j, k en l.


Tabel 8.1: Woordkenmerken van een bericht.

a b c d h i j,k,l TAG

Large 0 1 0 1 l e la ge lar rge 0.0 0.0 JJ 1 1 NPOI

wildfire 0 0 0 1 w e wi re wil ire 0.0 0.01 NN 0 0 NPOI

in 0 0 0 1 i n in in 0.0 0.0 IN 1 1 NPOI

N 1 1 0 1 n n 0.64 0.64 NNP BPOI

. 0 0 0 0 . . 0.0 0.0 . 0 0 IPOI

Colorado 0 1 0 1 c o co do col ado 0.01 0.02 NNP 0 0 0 0.67 0.99 0 IPOI

prompts 0 0 0 1 p s pr ts pro pts 0.0 0.0 JJ 0 1 NPOI

evacuations 0 0 0 1 e s ev ns eva ons 0.0 0.0 NNS 1 0 NPOI

� Colorado Wildfires: Uit de 228 relevante berichten kon er uit 184 berichten minstens

een plaatsnaam worden bepaald (80.70%). Het totale aantal plaatsnamen kwam neer

op 264. De handmatig gelabelde dataset bestond uit de eerste 50 berichten. De tien

meest voorkomende plaatsnamen, gevonden in de berichten, zijn: “stove prairie school

(2), rd (3), estes (3), northern colorado (4), fort collins (4), n . colorado (7), new mexico

(7), co (13), colorado springs (31) en colorado (125)”.

� Orkaan Sandy: De 26 relevante berichten waren te weinig om een degelijke lokalisering

te kunnen doen. De lokalisatie kon dus niet voor deze dataset worden getest.

� Aanslagen in Parijs: Uit de 95 313 relevante berichten kon er uit 90 024 berichten

minstens een plaatsnaam worden bepaald (94.45%). Het totale aantal plaatsnamen

in alle berichten kwam neer op 128 812. De handmatig gelabelde dataset bestond

uit de eerste 100 berichten. De tien meest voorkomende plaatsnamen zijn: “bataclan

concert theater (978), paris france (1116), central paris (1225), paris bataclan concert

hall (1370), stadium (2926), bataclan (3246), bataclan concert hall (4493), france (4561),

stade de france (6024) en paris (93325)”

In [2] werden een maand lang tweets binnen gehaald uit de stad Singapore. Op die manier

kon een degelijke POI inventory worden samengesteld. Om een systeem als dit volledig uit

te werken is het dus noodzakelijk om dit voor iedere stad apart te kunnen opstellen.

De lokalisatie gaf zeer veelbelovende resultaten. Bij de dataset op Parijs, werd via een hand-

matig test nagegaan voor 200 willekeurige, over de hele set verspreidde, berichten hoeveel

plaatsnamen er effectief juist werden ontdekt en welke er niet werden ontdekt. De resultaten

hiervan waren 5% false positives en 8% false negatives. De plaatsnamen die niet werden ont-

dekt kwamen meestal ook niet voor in de leerset. Dit probleem kan waarschijnlijk opgelost

worden door gebruik te maken van een POI inventory , die de plaatsnamen in de buurt kent en


via het BILOU-schema kenmerk op voorhand aanduidt. Door een tekort aan check-in tweets

kon dit echter niet getest worden.

8.3.3 Bepaling van het type noodgeval

Voor de bepaling van het onderwerp werden de berichten onderzocht op voorkomen van de

termen uit de lexicon van [18]. Als meer dan een term uit dezelfde groep voorkomt in het

bericht wordt het bericht gelinkt aan een event van dat type. Om de resultaten niet de kunnen

beınvloeden voor deze test wordt de bepaling van types noodgevallen gedaan op de relevante

berichten, in plaats van de berichten waar een locatie kon uit worden bepaald. In de volgende

sectie wordt wel de juiste sequentie gebruikt voor de detectie van alarmen.

� Colorado Wildfires: Uit de 228 relevante berichten werden er 10 events geclassificeerd

waarvan: 1 als doden (10%), 1 als gewonden (10%) en 8 als schade (80%).

� Orkaan Sandy: Uit 26 relevante berichten werd er geen enkel event geclassificeerd.

� Aanslagen in Parijs: Uit de 95 313 relevante berichten werden er 7 407 events ge-

classificeerd waarvan: 4 210 als doden (56, 84%), 3 164 als gewonden (42, 72%) en 33

als schade (0, 45%).

8.4 Alarmdetectie

Voor de detectie van alarmen worden de berichten eerst gelokaliseerd alvorens het type nood-

geval kan worden bepaald. Dat is logisch aangezien hetzelfde bericht meermaals kan worden

opgeslagen, onder een ander type noodgeval. Elke entiteit heeft nu een type, een tijdstip en

een of meerdere plaatsnamen waardoor men vanaf nu spreekt van een event.

� Colorado Wildfires: Uit de 184 relevante berichten met minstens een plaatsnaam

konden 24 events worden bepaald.

� Orkaan Sandy: De 26 relevante berichten waren te weinig om een degelijke lokalisering

te kunnen doen. Voor deze dataset kon dit onderdeel dus niet getest worden.

� Aanslagen in Parijs: Uit de 95 313 relevante berichten met minstens een plaatsnaam

konden 6 803 events worden bepaald.

8.5 Informatievoorstelling

In Tabel 8.2 is een overzicht gegeven van het aantal berichten dat overbleef na iedere fase

van het systeem. De laatste kolom duidt het aantal events aan, die zowel een type, locatie en

tijdstip bezitten.


Tabel 8.2: Overzicht van de resultaten van het protoype.

Ramp Aantal Tweets Naıve Bayes Lokalisatie Classificatie

Colorado Wildfires 3 381 228 184 24

Orkaan Sandy 80 331 26 n.v.t. n.v.t.

Aanslagen Parijs 422 457 95 313 90 024 6 803

Omdat de dataset uit Colorado en die uit Parijs niet genoeg check-in tweets bevatten om

een POI inventory te construeren werden de effectieve plaatsnamen handmatig gelinkt aan

hun coordinaten. Op deze manier was toch een visualisatie op kaart mogelijk. Alle volgende

kaarten zijn getekend volgens de methode beschreven in Hoofdstuk 7.

Figuur 8.4 toont het resultaat van de ramp in Colorado. Figuur 8.5 toont hetzelfde resultaat

maar met de plaatsnamen van de locaties erbij.

Figuur 8.4: Colorado: Overzicht van alle alarmen gedurende de volledige periode.


Figuur 8.5: Colorado: Overzicht van de plaatsen waar alarmen optraden.

Figuur 8.6 toont de resultaten van de events in Parijs. Aangezien de afmetingen van de vakjes

in het rooster 1 lengtegraad op 1 breedtegraad zijn, worden alle events samengenomen in

eenzelfde alarm. Daarom is in afbeelding 8.7 dezelfde visualisatie berekend, met als afmetingen

1.1 op 1.1 km (1/100 lengtegraad op 1/100 breedtegraad).


Figuur 8.6: Parijs: Overzicht van alle alarmen gedurende de volledige periode.

Figuur 8.7: Parijs: Gedetailleerd overzicht van de rampen.

Bemerk in Figuur 8.7 dat het alarm dat de plaatsnaam “Paris” bevat, wordt afgebeeld in het

vakje dat het midden van deze stad omvat. Aangezien de stad bestaat uit meerdere vakjes,

zou het logischer zijn om de events met deze plaatsnaam over al deze vakjes te spreiden.

Dat vereist natuurlijk een databank die de landen, steden, provincies en andere gebieden


kan omzetten in een rooster. Het opstellen en gebruik hiervan valt buiten de scope van deze

masterproef.

8.6 Evaluatie

Uit de resultaten, weergegeven in de sectie over informatievoorstelling kunnen enkele zaken

worden vastgesteld.

Ten eerste valt op dat hoe lokaler de ramp, hoe meer relevante sociale media data er wordt

gegenereerd. De aanslag in Parijs was heel lokaal (binnen een straal van 100 km) en bracht een

grote hoeveelheid relevante data op (2.56% relevant). De rampen in Colorado waren verspreid

over de hele staat en brachten al heel wat minder relevante data op (6.74% relevant). Tenslotte

waren de berichten over orkaan Sandy opgenomen uit een groot deel van de Verenigde Staten

en waren bijna allemaal irrelevant (0.03% relevant).

Een tweede vaststelling is dat eenmaal een bericht relevant is bevonden door de Naıve Bayes

classificeerder, er bij de meerderheid een locatie uit kon worden gehaald met behulp van de

POI tagger (tussen de 80 en de 95%). Uit de top tien van deze locatienamen blijken die ook

nog eens in de meeste gevallen correct.

Het herkennen van noodgevallen uit de relevante berichten geeft echter minder succes (onder

de 10%). Uit een aparte test op 200 berichten, waarin duidelijk een noodgeval beschreven

wordt, bleek dat 96% van de berichten vals negatief wordt aangeduid. Er worden dus slechts

heel erg weinig noodgevallen ontdekt. Dat het verschil hierin zo groot is kan komen door

het feit dat de leerset voor de CRF labeling is opgebouwd uit berichten van de dataset zelf,

terwijl de kernwoorden waar op gezocht werd voor het herkennen van het type noodgeval uit

een externe bron werden gehaald. Dit toont jammer genoeg de negatieve impact aan van het

gebruik van bronnen, die niet specifiek voor de ramp werden gecreeerd.

Als ten slotte de visualisatie van de alarmen naast de tijdslijn van de rampen (Colorado en

Parijs) wordt gelegd is te zien dat de informatie die uit de berichten wordt gehaald, niet de

volledige ramp beschrijft, maar wel correcte informatie geeft. Bij Colorado wordt vooral de

brand bij Fort Collins opgemerkt. Bij de aanslagen in Parijs worden effectief de alarmen

in het stadium en in de theaterzaal Bataclan opgemerkt. Ook de schietpartij in “90 rue de

Charonne” werden besproken in de tweets maar deze plaatsnaam werd jammer genoeg niet

correct aangeduid. De meerderheid van de leerset ging dan ook over de andere rampen, dus

de kans is groot dat er daardoor een ongeldige kansverdeling is berekend.

Hoewel de resultaten op zich redelijk veelbelovend zijn, hangt toch nog veel af van wat voor

soort ramp er optreedt, en hoe de gebruikers daarop reageren. Heel lokale, choquerende,

rampen zoals aanslagen genereren een massa aan nuttige informatie terwijl de grote, veel


voorkomende rampen zoals orkanen of branden in een droog gebied, vaak veel minder nuttige

data genereren. Voor zulke rampen kan het een oplossing zijn om de berichten te sturen, door

middel van sociale media kanalen die specifiek vragen om relevante informatie over rampen in

de buurt. Dat neemt natuurlijk ook het idee weg achter de informatiebron die sociale media

bevat. Een mogelijke oplossing hiervoor zou een systeem kunnen zijn dat de wijsheid van de

massa goed weet in te zetten.

De wijsheid van de massa is een techniek waarbij iedereen die zich geroepen voelt de moge-

lijkheid krijgt om hulp te bieden bij het oplossen van problemen. Bij de verdwenen Malaysia

Airlines vlucht MH370, in maart 2014, bijvoorbeeld, werd 3 200 km2 aan satellietbeelden on-

line gezet. Op een eenvoudige manier kon iedereen met een netwerkconnectie over het gebied

navigeren. Als iemand iets vond dat leek op een wrakstuk of een reddingsvloot kon die dat

markeren[31]. Het crisisteam kreeg dan een overzicht van de markeringen en kon zo gerichter

op zoek gaan.

Op een analoge manier zou men aan vrijwilligers kunnen vragen om de handmatige annotatie

op zich te nemen. Een uitdaging die hierbij kan opduiken is het blijven motiveren van de

massa[31]. Vrijwilligers motiveren voor het herkennen van patronen en ontrafelen van com-

plexe structuren wordt steeds meer gedaan met behulp van gamification [32]. Het basisidee

achter gamification is gebruikers tonen hoe iets moet en hun belonen als ze het goed doen.

Beloningen kunnen gaan van een “goed gedaan!” berichtje met een muziekje erbij tot virtuele

medailles.

Hoofdstuk 9

Conclusie

Wetenschappelijk onderzoek toonde reeds aan dat tijdens rampen heel wat nuttige informatie

wordt gegenereerd door gebruikers die communiceren over hun emoties, observaties en me-

ningen [6, 7]. Jammer genoeg zijn er slechts weinig hulpdiensten die deze informatie op het

moment zelf ophalen en er gebruik van maken[6]. De reden hiervoor is dat het formaat en de

hoeveelheid data het zeer ingewikkeld maken om er analyse op de doen.

Het doel van deze masterproef was de ontwikkeling van een systeem dat zowel voor real time

als voor post analyse zo veel mogelijk van de nuttige informatie kan visualiseren. Voor dit

systeem werd eerst en vooral een, reeds ontwikkelde, architectuur overgenomen en aangepast

naar een minimale opzet. Aangezien deze masterproef vrij beperkt was in tijd, zijn er be-

paalde strategische beslissingen genomen om een zo compleet, efficient en werkend systeem

uit te werken. De grootste aanpassing werd het uitvoeren van alle analyses op de berichten

zelf, in plaats van ze in te delen in samenhorende entiteiten. Alle deelsystemen rond dit on-

derdeel kunnen echter ongewijzigd ingezet worden voor beide strategieen. Deze uiteenzetting

is volledig te vinden in Hoofdstuk 2.

Vervolgens werden al deze deelsystemen onafhankelijk besproken en omgezet in code, voor

de analyse van tekstuele berichten op het sociale medium Twitter. In elk onderdeel werden

alle uitdagingen besproken en werd een oplossing voorgesteld en uitgewerkt. De systemen die

werden gebruikt voor dit onderzoek staan volledig los van elkaar en werden nog nooit eerder

achtereen geschakeld. Deze uiteenzetting wordt besproken in Hoofdstukken 3 tot 7.

Het volledige programma werd uiteindelijk geevalueerd aan de hand van drie datasets: de

bosbranden van Colorado in 2012, orkaan Sandy aan de Oostkust van de Verenigde Staten in

2012 en de terroristische aanslagen in Parijs in 2015. De drie gegevenssets kwamen van heel

diverse rampen en zijn ook op andere manieren opgehaald. De belangrijkste vaststellingen uit

deze test zijn ten eerste dat de informatie, bekomen uit de berichten, overeenkomt met wat

er effectief gebeurde op die dag. Een tweede vaststelling is dat hoe lokaler en choquerende

61

Hoofdstuk 9. Conclusie 62

de ramp, hoe meer relevante sociale media data er te vinden was. Hoewel de bosbranden in

Colorado enorm veel schade toebrachten aan de omgeving is er toch weinig informatie hierover

terug te vinden. Bij de aanslagen in Parijs echter kwamen de trends uit de beschrijving van

de ramp wel degelijk terug. Orkaan Sandy is dan weer een natuurfenomeen, waar mensen zich

dagenlang op voorhand op kunnen voorbereiden, en geeft weinig of geen relevante informatie

op.

Algemeen waren de resultaten dus vrij positief. Doorheen het onderzoek valt wel op dat

het effectief inzetten van zo’n systeem veel werk zal vereisen van de lokale instanties. Het

opstellen van een geografische databank bijvoorbeeld, die alle bijnamen en afkortingen van

plaatsnamen bevat, is iets dat enkel heel lokaal kan worden gebruikt. Ook voor de indeling

van berichten in relevant en niet-relevant is een handmatig gelabelde set gegevens nodig, die

ongetwijfeld de beste resultaten geeft als deze van dezelfde soort ramp wordt gehaald.

Een systeem als dit kan dus zeker de hulpdiensten helpen bij het snel verkrijgen van een

overzicht over een rampsituatie. Het voorbereidend werk echter, om te kunnen werken met

vrije tekstuele data, is redelijk intensief om een degelijk resultaat te bekomen. Zoals reeds

aangehaald op het einde van Hoofdstuk 8 kan de wijsheid van de massa, met behulp van

gamification hier misschien een oplossing bieden.

Hoofdstuk 10

Toekomstig werk

In dit hoofdstuk worden, op basis van de besluiten, eventuele mogelijkheden tot toekomstig

werk aangehaald.

Een eerste mogelijkheid voor toekomstig werk is de classificatie van relevante berichten in

events. In deze masterproef werd daarvoor in de berichten gezocht naar woorden uit [18].

Deze set bevat veel voorkomende woorden uit berichten over doden, gewonden en schadege-

vallen. Tijdens de evaluatie werd echter duidelijk dat er uit deze filtering slechts heel weinig

events overbleven, terwijl uit de handmatige controle, van de relevante berichten, bleek dat er

nauwelijks false positives in de invoerset zaten. Een ander systeem kan hier dus waarschijnlijk

veel meer uit halen.

Een tweede suggestie tot verbetering is het verspreiden van events met plaatsnamen die

gebieden voorstellen, zoals een land of een stad, verdelen over het rooster dat dit gebied

bevat. Op die manier is het heel eenvoudig te zien welk gebied er precies geteisterd wordt

door de ramp.

Tenslotte zou de wijsheid van de massa kunnen gebruikt worden voor handmatige labeling

van berichten. De uitdagingen in dit verdere onderzoek liggen vooral in de gamification. Men

kan dan vrijwilligers vragen om relevante en irrelevante berichten uit elkaar te houden of om

plaatsnamen in berichten aan te duiden. De manier van labeling moet zo eenvoudig mogelijk

zijn om een groot doelpubliek aan te spreken, maar moet ook wel correct gebeuren om zo

weinig mogelijk foutieve data te verkrijgen. Meer info hierover is te vinden op het einde van

Hoofdstuk 8.

63

Bibliografie

[1] Matthias Moi, Therese Friberg, Robin Marterer, Christian Reuter, and Thomas Ludwig.

Strategy for processing and analyzing social media data streams in emergencies. 2015.

[2] Chenliang Li and Aixin Sun. Fine-grained location extraction from tweets with temporal

awareness. In Proceedings of the 37th international ACM SIGIR conference on Research

& development in information retrieval, pages 43–52. ACM, 2014.

[3] Viktor Slavkovikj, Steven Verstockt, Sofie Van Hoecke, and Rik Van de Walle. Review

of wildfire detection using social media. Fire safety journal, 68:109–118, 2014.

[4] Cetin Enis, Akers Dennis, Aydin Ilhami, Dogan Nurettin, Gunay Os-

man, and Toreyin Ugur. Using surveillance systems for wildfire detection.

http://www.firefighternation.com/article/wildland-urban-interface/

using-surveillance-systems-wildfire-detection, 2013. [Online; accessed 30-

March-2016].

[5] Statistieken belgische brandweer 2013. http://www.civieleveiligheid.be/sites/

default/files/explorer/partie_s_incendie/Verslag_Statistieken_brandweer_

2013_NL_def.pdf, 2013. [Online; accessed 30-March-2016].

[6] EmerGent. The emergent project: Background and objectives. http://www.

fp7-emergent.eu/project/. [Online; accessed 30-March-2016].

[7] Teun Terpstra, A de Vries, R Stronkman, and GL Paradies. Towards a realtime Twitter

analysis during crises for operational crisis management. Simon Fraser University, 2012.

[8] Terpstra Teun, Hartman Marco, and Geerte Paradies Arnout, de Vries. Twitter in

crisisbeheersing. http://www.infopuntveiligheid.nl/Infopuntdocumenten/541325_

Social_media_eindrapport.pdf, 2011. [Online; accessed 30-March-2016].

[9] Muhammad Imran, Carlos Castillo, Fernando Diaz, and Sarah Vieweg. Processing so-

cial media messages in mass emergency: a survey. ACM Computing Surveys (CSUR),

47(4):67, 2015.

64

http://www.firefighternation.com/article/wildland-urban-interface/using-surveillance-systems-wildfire-detection

http://www.firefighternation.com/article/wildland-urban-interface/using-surveillance-systems-wildfire-detection

http://www.civieleveiligheid.be/sites/default/files/explorer/partie_s_incendie/Verslag_Statistieken_brandweer_2013_NL_def.pdf



http://www.fp7-emergent.eu/project/

http://www.fp7-emergent.eu/project/

http://www.infopuntveiligheid.nl/Infopuntdocumenten/541325_Social_media_eindrapport.pdf

http://www.infopuntveiligheid.nl/Infopuntdocumenten/541325_Social_media_eindrapport.pdf

Bibliografie 65

[10] Oluwaseun Ajao, Jun Hong, and Weiru Liu. A survey of location inference techniques

on twitter. Journal of Information Science, 41(6):855–864, 2015.

[11] David Jurgens, Tyler Finethy, James McCorriston, Yi Tian Xu, and Derek Ruths. Ge-

olocation prediction in twitter using social networks: a critical analysis and review of

current practice. In Proceedings of the 9th International AAAI Conference on Weblogs

and Social Media (ICWSM), 2015.

[12] Haoyu Wang, Eduard Hovy, and Mark Dredze. The hurricane sandy twitter corpus.

Links, 499:539–515, 2014.

[13] Alexandra Olteanu, Carlos Castillo, Fernando Diaz, and Sarah Vieweg. Crisislex: A

lexicon for collecting and filtering microblogged communications in crises. In ICWSM,

2014.

[14] StatSoft. Naive bayes classifier introductory overview. http://www.statsoft.com/

textbook/naive-bayes-classifier. [Online; accessed 02-May-2016].

[15] Laurent Luce. Twitter sentiment analysis using python and nltk. http://www.

laurentluce.com/posts/twitter-sentiment-analysis-using-python-and-nltk/,

2012. [Online; accessed 02-May-2016].

[16] Ryan Compton, David Jurgens, and David Allen. Geotagging one hundred million twit-

ter accounts with total variation minimization. In Big Data (Big Data), 2014 IEEE

International Conference on, pages 393–401. IEEE, 2014.

[17] Alexandra Olteanu. A repository of crisis-related social media data and tools. http:

//crisislex.org/. [Online; accessed 16-March-2016].

[18] I Temnikova, C Castillo, and S Vieweg. Emterms 1.0: A terminological resource for crisis

tweets, 2015.

[19] Alan Ritter. Osu twitter nlp tools. https://github.com/aritter/twitter_nlp.

[20] Peter F Brown, Peter V Desouza, Robert L Mercer, Vincent J Della Pietra, and Jeni-

fer C Lai. Class-based n-gram models of natural language. Computational linguistics,

18(4):467–479, 1992.

[21] Michael Heilman. Tan clustering: Hierarchical word clustering based on brown clustering.

https://github.com/mheilman/tan-clustering.

[22] Crf++: Yet another crf toolkit. https://taku910.github.io/crfpp/. [Online; acces-

sed 03-May-2016].

[23] ehmatthes. Visualization: Mapping global earthquake activity. http://introtopython.

org/visualization_earthquakes.html, 2012. [Online; accessed 17-March-2016].

http://www.statsoft.com/textbook/naive-bayes-classifier

http://www.statsoft.com/textbook/naive-bayes-classifier

http://www.laurentluce.com/posts/twitter-sentiment-analysis-using-python-and-nltk/

http://www.laurentluce.com/posts/twitter-sentiment-analysis-using-python-and-nltk/

http://crisislex.org/

http://crisislex.org/

https://github.com/aritter/twitter_nlp

https://github.com/mheilman/tan-clustering

https://taku910.github.io/crfpp/

http://introtopython.org/visualization_earthquakes.html

http://introtopython.org/visualization_earthquakes.html

Bibliografie 66

[24] Wes McKinney. Python for data analysis: Data wrangling with Pandas, NumPy, and

IPython. ”O’Reilly Media, Inc.”, 2012.

[25] Alexandra Olteanu, Sarah Vieweg, and Carlos Castillo. What to expect when the unex-

pected happens: Social media communications across crises. In Proceedings of the 18th

ACM Conference on Computer Supported Cooperative Work & Social Computing, pages

994–1009. ACM, 2015.

[26] Nick Ruest. A look at 14,939,154 #paris #bataclan #pa-

risattacks #porteouverte tweets. http://ruebot.net/post/

look-14939154-paris-bataclan-parisattacks-porteouverte-tweets, 2015.

[Online; accessed 04-May-2016].

[27] 2012 colorado wildfires. https://en.wikipedia.org/wiki/2012_Colorado_

wildfires. [Online; accessed 03-May-2016].

[28] Sandy (orkaan). https://nl.wikipedia.org/wiki/Sandy_%28orkaan%29. [Online; ac-

cessed 03-May-2016].

[29] Aanslagen in parijs van november 2015. https://nl.wikipedia.org/wiki/Aanslagen_

in_Parijs_van_november_2015. [Online; accessed 03-May-2016].

[30] Naive bayes classifier. https://en.wikipedia.org/wiki/Naive_Bayes_classifier.

[Online; accessed 03-May-2016].

[31] Vliegtuig vermist: soms liever geen hulp van het publiek. https://wisdomofthecrowd.

nl/2014/03/19/vliegtuig-vermist-soms-liever-geen-hulp-van-het-publiek/

#more-9921, 2014. [Online; accessed 03-May-2016].

[32] Denis Duvauchelle. Overcoming the user engagement cri-

sis with gamification. http://thenextweb.com/dd/2014/03/15/

overcoming-user-engagement-crisis-gamification/#gref, 2014. [Online; ac-

cessed 03-May-2016].

[33] Marco Bonzanini. Mining twitter data with python (part 2: Text pre-processing). https:

//marcobonzanini.com/2015/03/09/mining-twitter-data-with-python-part-2/,

2015. [Online; accessed 03-March-2016].

[34] Ravikiran Janardhana. how to build a twitter sentiment analyzer ? http://ravikiranj.

net/posts/2012/code/how-build-twitter-sentiment-analyzer/, 2012. [Online; ac-

cessed 06-March-2016].

[35] senderle. How to create a trie in python. http://stackoverflow.com/a/11016430,

2012. [Online; accessed 25-March-2016].

http://ruebot.net/post/look-14939154-paris-bataclan-parisattacks-porteouverte-tweets

http://ruebot.net/post/look-14939154-paris-bataclan-parisattacks-porteouverte-tweets

https://en.wikipedia.org/wiki/2012_Colorado_wildfires

https://en.wikipedia.org/wiki/2012_Colorado_wildfires

https://nl.wikipedia.org/wiki/Sandy_%28orkaan%29

https://nl.wikipedia.org/wiki/Aanslagen_in_Parijs_van_november_2015

https://nl.wikipedia.org/wiki/Aanslagen_in_Parijs_van_november_2015

https://en.wikipedia.org/wiki/Naive_Bayes_classifier

https://wisdomofthecrowd.nl/2014/03/19/vliegtuig-vermist-soms-liever-geen-hulp-van-het-publiek/#more-9921



http://thenextweb.com/dd/2014/03/15/overcoming-user-engagement-crisis-gamification/#gref

http://thenextweb.com/dd/2014/03/15/overcoming-user-engagement-crisis-gamification/#gref

https://marcobonzanini.com/2015/03/09/mining-twitter-data-with-python-part-2/

https://marcobonzanini.com/2015/03/09/mining-twitter-data-with-python-part-2/

http://ravikiranj.net/posts/2012/code/how-build-twitter-sentiment-analyzer/

http://ravikiranj.net/posts/2012/code/how-build-twitter-sentiment-analyzer/

http://stackoverflow.com/a/11016430

Bijlage A

Gebruikte klassen

A.1 De klasse Tokenizer

De klasse Tokenizer was gebouwd aan de hand van de voorbeelden in [33] en [34].

Listing A.1: De klasse Tokenizer.

import re

import HTMLParser

class Tokenizer(object):

def _init_(self):

self.emoticons_str = r"""

(?:

[:=;] # Eyes

[oO\-]? # Nose (optional)

[D\) \]$\]/\\ OpP] # Mouth

)"""

self.regex_str = [

self.emoticons_str ,

r’ <[^>]+>’, # HTML tags

r’(?:@[\w_]+)’, # @-mentions

r"(?:\#+[\ w_]+[\w\’_\-]*[\w_]+)", # hash -tags

r’http[s]?://(?:[a-z]|[0 -9]|[$-_@ .&+]|[!*\($ ,]|(?:%[0 -9a-f][0-9a-f]))+’,

↪→ # URLs

r’(?:(?:\d+,?) +(?:\.?\d+)?)’, # numbers

r"(?:[a-z][a-z’\-_]+[a-z])", # words with - and ’

r’(?:[\w_]+)’, # other words

r’(?:\S)’ # anything else

]

self.tokens_re = re.compile(r’(’+’|’.join(self.regex_str)+’)’, re.VERBOSE | re

↪→ .IGNORECASE)

self.emoticon_re = re.compile(r’^’+self.emoticons_str+’$’, re.VERBOSE | re.

↪→ IGNORECASE)

self.htmlparser = HTMLParser.HTMLParser ()

67

Bijlage A. Gebruikte klassen 68

def tokenize_tweet(self, string , lowercase=False):

string = self.htmlparser.unescape(string)

#Convert www.* or https ?://* to URL

string = re.sub(’((www \.[^\s]+)|(https ?://[^\s]+))’,’URL’,string)

#Convert @username to AT_USER

string = re.sub(’@[^\s]+’,’AT_USER ’,string)

#Remove ; character , for later use in CSV files

string = re.sub(’;’, ’’, string)

# Remove " and ’ character

string = re.sub(’"|’, ’’, string)

#Remove additional white spaces

string = re.sub(’[\s]+’, ’ ’, string)

#Replace #word with word

string = re.sub(r’#([^\s]+)’, r’\1’, string)

#trim

string = string.strip(’\’"’)

# remove trailing and leading white spaces

string = re.sub(’^\s|\s$’, ’’, string)

# replace consecutive non -ASCII characters

string = re.sub(r’[^\x00 -\x7F]+’, ’ ’, string)

tokens = self.tokens_re.findall(string)

if lowercase:

tokens = [token if self.emoticon_re.search(token) else token.lower () for

↪→ token in tokens]

return tokens

A.2 De klasse Trie

De klasse Trie was gebouwd aan de hand van het voorbeeld in [35].

Listing A.2: Implementatie van een trie in Python.

class Trie(object):

def _init_(self, end=’_end_ ’):

self._root = dict()

self.end = end

self._count = 0

def insert(self, obj):

current_dict = self._root

for letter in obj:

current_dict = current_dict.setdefault(letter , {})

current_dict[self.end] = self.end

self._count +=1

def in_trie(self, obj):

current_dict = self._root

for letter in obj:

if letter in current_dict:

current_dict = current_dict[letter]

else:

return False

else:

Bijlage A. Gebruikte klassen 69

if self.end in current_dict:

return True

else:

return False

@property

def count(self):

return self._count

@property

def root(self):

return self._root

tijdruimtelijke tekstuele analyse van brand gerelateerde data op...

Documents