Analyse und Erweiterung eines Frameworks zur Modellierung von Nutzer-Bewegungen

Gottfried Wilhelm Leibniz Universität Hannover Fachgebiet Distributed Computing Distributed Computing Security Group Bachelorarbeit im Studiengang In...
Author: Eleonora Kaiser
1 downloads 3 Views 2MB Size
Gottfried Wilhelm Leibniz Universität Hannover Fachgebiet Distributed Computing Distributed Computing Security Group

Bachelorarbeit im Studiengang Informatik (B. Sc.)

Analyse und Erweiterung eines Frameworks zur Modellierung von Nutzer-Bewegungen

Verfasser:

Marcel Linke

Erstprüfer:

Prof. Dr. rer. nat. M. Smith

Zweitprüferin:

Prof. Dr.-Ing. G. von Voigt

Betreuer:

M. Sc. B. Henne

Datum:

29. Juli 2010

Hannover, den 29.07.2010 Hiermit versichere ich, dass ich diese Arbeit selbstständig verfasst habe und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.

Marcel Linke

Abstract Die Zahl vernetzter mobiler Endgeräte, wie zum Beispiel Smartphones, steigt stetig. Ebenso wächst die Zahl verschiedenster Web 2.0-Dienste, die Medien, von Text bis Video, speichern. Dabei verschmelzen gerade die mobilen Endgeräte und die Web 2.0-Dienste immer weiter, so dass es heute beispielsweise möglich ist, GPS-Daten abzugreifen und damit Bewegungsprofile zu erstellen. Durch die mobile, spontane Nutzung solcher Dienste stellen sich neue Herausforderungen im Bereich der Sicherheit und dem Schutz der Privatssphäre von Nutzern. Durch unterschiedliche Bewegungsmuster von Nutzern — teils zufällig, teils wiederkehrend, teils durch unregelmäßige Vorkommnisse bestimmt — lassen sich diese Problematiken nur schwer mathematisch oder visuell modellieren. Hier existiert die Möglichkeit der Simulation. In der Distributed Computing Security Group wird dazu das Framework CanuMobiSim eingesetzt, welches das Einlesen von Kartendaten im Geographic-Data-File-Format und die Definition von sich zufällig bewegten Objekten (auf oder neben den Kartenobjekten), ermöglicht. Dieses Framework wurde ursprünglich von der Universität Stuttgart entwickelt. Im Rahmen dieser Bachelorarbeit wird das Framework erweitert. Im ersten Teil der Arbeit soll ein Import für Kartendaten im XML-basierten Open-Street-Map-Format implementiert werden. Der zweite Teil der Arbeit soll die existierenden Bewegungsmodelle so erweitern, dass diese realistisches Verhalten aufzeigen. So sollen Attraktoren (POI) die Häufung von Personen hervorrufen können. Aktivitäten sollen zeitbegrenzt (Öffnungszeichen/nicht dauerhafte Events) sein. Die Affinitäten bestimmter Nutzergruppen zu bestimmten POI/Events (Beispiel: Jugendliche gehen morgens in die Schule, Erwachsene zur Arbeit) sollen ebenfalls umgesetzt werden.

i

Inhaltsverzeichnis

Abbildungsverzeichnis

iv

Abkürzungsverzeichnis

v

1 Einleitung

1

1.1

CanuMobiSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Motivation dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . .

1

1.3

Inhalt und Aufbau dieser Arbeit . . . . . . . . . . . . . . . . . . .

2

1.4

Erläuterungen zum besseren Verständnis . . . . . . . . . . . . . . .

3

2 CanuMobiSim

6

2.1

Die Eingabe-XML-Datei . . . . . . . . . . . . . . . . . . . . . . .

7

2.2

Das Paket MobiSim . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3

Das Paket GDFReader . . . . . . . . . . . . . . . . . . . . . . . .

9

2.4

Das Paket AWMLReader . . . . . . . . . . . . . . . . . . . . . . .

11

2.5

Das Paket SpatialModel . . . . . . . . . . . . . . . . . . . . . . . .

11

2.6

Das Paket TripModel . . . . . . . . . . . . . . . . . . . . . . . . .

13

3 Open-Street-Map-Import

17

3.1

Das Projekt Open Street Map . . . . . . . . . . . . . . . . . . . . .

17

3.2

Das OSM-Format . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.3

Die interne Datenrepräsentation vom OSMReader . . . . . . . . . .

20

3.4

Der OSMReader . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.5

Das räumliche Modell - Die Klasse OSMModel . . . . . . . . . . .

28

3.6

Probleme und Lösungen . . . . . . . . . . . . . . . . . . . . . . .

28

3.7

Verbesserungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

4 Zeitbeschränkt aktivierte POI

32

4.1

Vorüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

4.2

Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

ii

Inhaltsverzeichnis

5 Zeitbasiertes Benutzerverhalten

iii

39

5.1

Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.2

Das Entscheidungs- und Ankunftszeitpunktproblem . . . . . . . . .

44

6 Aufbau eines Demo-Szenarios

45

6.1

Import von Kartendaten . . . . . . . . . . . . . . . . . . . . . . . .

45

6.2

Der TimeBasedTripGenerator als Standardbewegungsmodell . . . .

47

6.3

Die Benutzergruppen . . . . . . . . . . . . . . . . . . . . . . . . .

50

7 Fazit 7.1

53 Verbesserungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

A Tags, Types, Class Codes und Subclass Codes

55

B Listings zum Demo-Szenario

58

Literaturverzeichnis

62

Abbildungsverzeichnis

2.1

Übersicht über CanuMobiSim . . . . . . . . . . . . . . . . . . . .

6

2.2

UML-Klassendiagramm das Pakets MobiSim . . . . . . . . . . . .

8

2.3

UML-Klassendiagramm das Pakets GDFReader . . . . . . . . . . .

9

2.4

UML-Klassendiagramm des Pakets SpatialModel . . . . . . . . . .

12

2.5

UML-Klassendiagramm des Pakets TripModel. . . . . . . . . . . .

13

2.6

Beispielautomat zum ActivityBasedTripGenerator . . . . . . . . . .

16

3.1

Open Street Map-XML-Format . . . . . . . . . . . . . . . . . . . .

18

3.2

Übersicht zur internen OSM Datenrepräsentation . . . . . . . . . .

20

3.3

UML des Pakets OSMReader . . . . . . . . . . . . . . . . . . . . .

21

3.4

Beispiel für mehrfache Tag-Bezeichnungen . . . . . . . . . . . . .

30

4.1

Programmablauf der Klasse TimeBasedTripGenerator . . . . . . . .

35

5.1

Automat zur Klasse RealisticConstantSpeedMotion . . . . . . . . .

43

6.1

OMS-Karte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

6.2

CanuMobiSim-Karte . . . . . . . . . . . . . . . . . . . . . . . . .

48

6.3

Demo Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

iv

Abkürzungsverzeichnis API

Application Programming Interface

AWML

Augmented World Modeling Language

DCSec

Distributed Computing Security Group

DOM

Document Object Model

GDF

Geographic Data File

GPS

Global Positioning System

GUI

Graphical User Interface

OSM

Open Street Map

POI

Points of Interest

SAX

Simple API for XML Parsing

StAX

Streaming API for XML

UML

Unified Modeling Language

UTM

Universal Transverse Mercator

WGS84

World Geodetic System 1984

XML

Extensible Markup Language

v

1 Einleitung

1.1 CanuMobiSim CanuMobiSim ist ein an der Universität Stuttgart entstandenes Framework zur Modellierung und Simulation von mobilen Benutzerbewegungen. Benutzerbewegungen können dabei zufällig im Raum einer vorgegebenen Karte oder zufällig auf dem Graphen, der die Karte bildet, erfolgen. Die aktuelle Version 1.3.4 des Frameworks wurde am 23.05.2005 veröffentlicht und ist seitdem nicht mehr weiter entwickelt worden [canu01]. Sie unterstützt, neben der Simulation von Benutzerbewegungen, das Einlesen von Kartendaten im GeographicData-File-Format (GDF) und im von der Universität Stuttgart entwickelten AugmentedWorld-Modeling-Language-Format (AWML). Außerdem können die Benutzerbewegungen und die Kartendaten zur Veranschaulichung der Simulation visuell ausgegeben werden. In der Distributed Computing Security Group (DCSec) wird die Software CanuMobiSim eingesetzt, um Bewegungen von Personen zu simulieren. Ziel ist, die simulierten Bewegungen als Grundlage weiterer Simulationen im bereich der IT-Sicherheit beziehungsweise dem Schutz der Privatsphäre zu verwenden.

1.2 Motivation dieser Arbeit Diese Arbeit ist in zwei Teile unterteilt. Im ersten Teil der Arbeit wird ein Open-Street-Map-Import (OSM) entwickelt, um Kartendaten im OSM-Format nutzen zu können. CanuMobiSim bietet derzeit nur die Möglichkeit Kartendaten im GDF-Format und im AWML-Format zu importieren. Beide Formate haben den Nachteil, dass sie nicht frei (GDF) oder nicht mit großer Weltabdeckung (AWML) verfügbar sind. Karten im GDF-Format sind nur mit einem hohen Kostenaufwand zu erwerben. Da das AWML-Format nur intern von der Universität Stuttgart verwendet wird, ist hier leider keine Kartenabdeckung bekannt. Im

1

1. Einleitung

2

Gegensatz zu diesen beiden Formaten hat das OSM-Format den Vorteil, dass es frei verfügbar ist und eine gute Weltabdeckung aufweist. Der zweite Teil der Arbeit beschäftigt sich damit, das Framework so zu erweitern, dass bestimmte Aspekte aus dem Bewegungsverhalten realer Benutzer besser oder überhaupt simuliert und abgebildet werden können. Bisher sind diese gleichverteilt im gesamten Graphen und bewegen sich eher zufällig. Dies ist in der Realität jedoch nur bedingt der Fall. Hier bewegen sich Benutzer teils zufällig, teils wiederholen sich Bewegungsabläufe allerdings auch täglich. Gerade Attraktoren (POI), wie zum Beispiel Rockkonzerte oder Fußballspiele, die zeitlich begrenzt an bestimmten Orten statt finden, erzeugen erhebliche Ansammlungen von Benutzern. Dadurch sind die Benutzer auf dem Graphen nicht mehr gleich verteilt und bewegen sich nicht mehr zufällig, sondern Verhalten sich nach vorgegebenen, zum Teil auch messbaren Werten.

1.3 Inhalt und Aufbau dieser Arbeit Das zweite Kapitel beschäftigt sich mit dem groben Aufbau der Software CanuMobiSim. Hier werden hauptsächlich die Pakete und Klassen beschrieben, die für die Lösung der Aufgabenstellung eine besondere Rolle spielen. Das dritte Kapitel dieser Arbeit beschäftigt sich mit dem Programmaufbau des OSMImports. Zu erst wird das OSM-Format erklärt. Danach wird auf die interne Datenrepräsentation eingegangen, die das auf der Extensible Markup Language (XML) basierte OSM-Format programmintern abbildet. Als dritter Punkt wird die Überführung aus der internen Datenrepräsentation in das räumliche Modell (SpatialModel) erklärt. Außerdem befasst sich das Kapitel mit den Problemen, Lösungen und Verbesserungen, die sich beim Import der Open-Street-Map-Daten ergeben haben. Das vierte und fünfte Kapitel beschäftigt sich mit der Realisierung einer eventbasierten Simulation. Hierbei liegt der Schwerpunkt im vierten Kapitel auf der Möglichkeit zeitbasiert aktivierte Points of Interest simulieren zu können. Das fünfte Kapitel beschäftigt sich mit dem Aufbau eines Bewegungsmodells, welches bestimmte Aspekte aus dem Bewegungsverhalten sich individuell bewegender, realistischer Benutzer modelliert. Zum besseren Verständnis der entstandenen Software wird im sechsten Kapitel ein Demo-Szenario realisiert.

1. Einleitung

3

1.4 Erläuterungen zum besseren Verständnis In diesen Abschnitten werden einige Begriffe, die zum besseren Verständnis und der Motivation der Bachelorarbeit wichtig sind, erläutert.

Das GDF-Format Durch das GDF-Format wird der Aufbau von Geographic Data Files beschrieben [wiki01][gdf01]. In den Geographic Data Files können Kartendaten erfasst, gespeichert und bei Bedarf ausgetauscht werden. Die Daten werden hierbei als Vektordaten erfasst, so dass sie beispielsweise zur Datenvisualisierung, beliebig skaliert werden können. Das GDF-Format wird hauptsächlich zur Speicherung von Straßenkarten eingesetzt und als Datengrundlage von den Herstellern von Navigationsgeräten verwendet. Im kommerziellen Verwendungsbereich stellen GDF-Daten die meistgenutzte Kartendatengrundlage dar. GDF-Dateien haben Felder mit fester Breite und 80 Zeichen pro Zeile. Fast alle Informationen im GDF-Format sind zahlenkodiert. Dies gilt nicht nur für die Koordinaten, sondern auch für die Arten von Elementen. So gibt es Class- und Subclasscodes, die jeweils zweistellige Zahlen sind und Objekttypen einer Karte definieren. Der Classcode, die vorderen zwei Ziffern, lässt hierbei auf eine Oberklasse von Elementen schließen, zum Beispiel Straßen. Der Subclasscode, die letzten zwei Ziffern, auf eine Unterklasse der Straßen, zum Beispiel Autobahnen. Geographische Koordinaten im GDF-Format liegen im World-Geodetic-System-1984Koordinatensystem (WGS84) vor. Kartendaten im GDF-Format werden größtenteils von den Firmen Navteq und Tele Atlas angeboten. Sie sind nicht frei verfügbar und nur mit einem hohen Kostenaufwand zu erwerben. Zu Demonstrationszwecken gibt es zwei kostenlose Karten, die die Städte Sulzbach im Taunus und den belgischen Flughafen Brüssel-Zaventem abdecken. WGS84 und UTM

Die Erde kann mathematisch als ein Ellipsoid angenommen werden. Das WGS84System beschreibt ein Koordinatensystem, dessen Gitternetz sich direkt auf den Ellipsoid legt [wiki02]. Zur Visualisierung auf einer zweidimensionellen Oberfläche,

1. Einleitung

4

wie man es von Karten gewohnt ist, ist das jedoch unpraktisch. Hier wird das UniversalTransverse-Mercator-Koordinatensystem (UTM) benutzt. In diesem Koordinatensystem wird der Ellipsoid auf eine Karte abgebildet [wiki03].

Bewegungsmodelle und TripGeneratoren Um Benutzerverhalten auf einer gegebenen Karte simulieren zu können, stellt die Software CanuMobiSim Bewegungsmodelle und TripGeneratoren bereit. Die Bewegungsmodelle stellen dabei individuelles Bewegungsverhalten dar. So können mit den Bewegungsmodellen Benutzer nachgebildet werden, die sich auf einer kompletten Karte oder nur auf einem bestimmten Graphen (zum Beispiel dem Straßennetz) bewegen. Benutzer können sich individuell mit verschiedenen Geschwindigkeiten bewegen. Außerdem lassen sich mehrere Benutzer, die das gleiche Verhalten aufzeigen sollen, zu einer Gruppe zusammen fassen. Durch die TripGeneratoren werden die Bewegungsmodelle erweitert. Bevor ein Benutzer sich anfängt zu bewegen, wird ihm durch einen TripGenerator eine Zielkoordinate übergeben. Diese kann sich entweder auf einem bestimmten Graphen befinden, aber auch ein Punkt außerhalb eines Graphens auf der Karte sein. Mit Hilfe der Zielkoordinate berechnet der TripGenerator nun den Pfad zum Ziel. Auch dies kann entweder zufällig geschehen oder mit Algorithmen (zum Beispiel dem DijkstraAlgorithmus) erfolgen. Hat ein Benutzer sein Ziel erreicht, wird ihm eine neue Zielkoordinate berechnet. Fehlende Bewegungsmodelle und TripGeneratoren

Um das Simulationsverhalten der Benutzer realistischer wirken zu lassen, ist es notwendig die Bewegungsmodelle und TripGeneratoren anzupassen. Da der Hauptaspekt für den höheren Realitätsgrad ein zeitbasiert agierendes System ist, soll ein Bewegungsmodell entwickelt werden, welches ermöglicht, dass unterschiedliche Benutzer zu unterschiedlichen Zeiten andere Aktivitäten annehmen. So ist ein Student vormittags in der Universität, während sich ein Arbeitnehmer vormittags an seinem Arbeitsplatz aufhält. Auch der TripGenerator kann für ein zeitbasiert agierendes System angepasst werden. So kann die Auswahl möglicher Zielkoordinaten an Hand der aktuellen Simulationszeit geschehen. Damit lassen sich dann zeitbegrenzt aktivierte Attraktoren realisieren. Zum Beispiel hat ein Nachtclub in den Tagstunden geschlossen und in den

1. Einleitung

5

Nachtstunden geöffnet. Aber auch das Beispiel der Rockkonzerte lässt sich modellieren, da ein Rockkonzert eine zeitbegrenzte Veranstaltung ist.

2 CanuMobiSim

Dieses Kapitel beschäftigt sich mit dem Aufbau der Software CanuMobiSim [canu03]. Es werden die für den Entwicklungsprozess der Bachelorarbeit wichtigen Klassen und Pakete vorgestellt und erläutert. Diese Pakete und Klassen sind der GDFReader, das SpatialModel und das TripModel.

GDFReader

AWMLReader

übergibt Kartendaten

SpatialModel

verwendet

Bewegungsmodell

verwendet

TripModel

meldet sich an verwendet Universe

verwendet

GUI

Abbildung 2.1: Übersicht über ausgewählte CanuMobiSim-Komponenten.

6

2. CanuMobiSim

7

An der Abbildung 2.1 kann man erkennen, wie die einzelnen, für die Bachelorarbeit wichtigen Komponenten zusammen hängen. Der GDFReader und auch der AWMLReader fügen dem SpatialModel Kartendaten hinzu. Bewegungsmodelle stellen einzelne Benutzer, die sich auf den Kartendaten bewegen, dar. Um ein neues Ziel und einen Pfad zu diesem Ziel zu generieren, verwendet ein Bewegungsmodell einen TripGenerator. Der TripGenerator greift auf das SpatialModel, genauer auf die dort hinterlegten Karten- und Graphendaten zu. SpatialModel und TripModel melden sich an der Klasse Universe an. Das Graphical User Interface (GUI) kann sich dort eine Referenz von beiden Objekten zurück geben lassen und die Daten auf der Bildschirmoberfläche zeichnen. Die GUI kann optional genutzt werden. Für den Programmablauf ist sie nicht notwendig und ist eher für eine Kontrolle durch den Anwender sowie zu Demonstrationszwecken interessant.

2.1 Die Eingabe-XML-Datei Um eine Simulation zu starten benötigt CanuMobiSim als Argument den Pfad auf eine XML-Datei. Sie definiert die Simulation. Mit den Daten dieser XML-Datei können Einstellungen vom Anwender am Programmablauf vorgenommen werden. CanuMobiSim ist sehr modular aufgebaut und so werden über die XML-Datei die Klassen, die der Anwender für die Simulation benötigt, direkt geladen. Über den Tag können solche Klassen dem Programm bekannt gemacht

werden und können von anderen Programmkomponenten, die zum Teil auch über die XML-Datei geladen werden, aufgerufen werden. Jede Programmkomponente kann ihrerseits auch Werte durch die XML-Datei, die zum Betrieb der Komponente benötigt werden, übergeben bekommen.

2.2 Das Paket MobiSim Das MobiSim-Paket beinhaltet die zentralen Klassen des Programms (vergleiche Abbildung 2.2).

Das Paket Core Im Paket Core befinden sich die für das Programm grundlegenden Klassen. Die Klasse Universe enthält Umgebungsvariablen, wie die aktuelle Simulationszeit.

2. CanuMobiSim

8

&RUH

([WHQVLRQV

*UDSK

8QLYHUVH

([WHQVLRQ0RGXOH

0RELOLW\0RGHOV

5DQGRP:D\3RLQW:DON

[[[2XWSXW 0RYHPHQW

([WHQGDEOH2EMHFW

1RGH

3RVLWLRQ'

%URZQLDQ:DON

Abbildung 2.2: Reduziertes Klassendiagramm des Pakets MobiSim.

Die Universe-Klasse liest auch die Eingabe-XML-Datei erstmalig ein. Abhängig davon, was in den direkten XML-Kindern gelesen wird, werden andere Java-Klassen gestartet. Auch die Klasse ExtensionModule ist eine für den Programmablauf und Programmaufbau grundlegend wichtige Klasse. CanuMobiSim ist sehr modular aufgebaut. So können viele Klassen als Erweiterung über die Eingabe-XML-Datei direkt aufgerufen werden. Diese Klassen erben vom ExtensionModule und melden sich, sobald der Konstruktor aufgerufen wird, auch an dem ExtensionModule an. Vom ExtensionModule werden sie dann temporär gespeichert und können später durch andere Klassen aufgerufen werden.

2. CanuMobiSim

9

Das Paket Extensions Im Paket Extensions befinden sich hauptsächlich Klassen, die für die Ausgabe von Daten zuständig sind. So werden hier auch die Positionen von Benutzerknoten ausgegeben. In diesem Paket befindet sich auch die Klasse Graph. Hier werden die Kanten und Knoten gespeichert, auf denen Bewegungen durch entsprechende Bewegungsmodelle stattfinden dürfen.

Das Paket MobilityModels Im Subpaket MobilityModels befinden sich die Bewegungsmodelle. Sie werden dazu eingesetzt, Benutzerbewegungen auf der Karte simulieren zu können. Neben entsprechenden Bewegungsmodellen, wie dem RandomWaypointWalk oder dem BrownianWalk, die sich unabhängig von einem Graphen über die Karte bewegen, gibt es auch Bewegungsmodelle, wie den GraphWalk, die nur auf dem Graphen stattfinden können.

2.3 Das Paket GDFReader

([WHQVLRQ0RGXOH

*')(GJH5HFRUG

*'))DFH5HFRUG

*')/LQH)HDWXUH5HFRUG

*')1RGH5HFRUG

*'); sims/demo/initial.txt 0.00.0 sims/demo/residential.txt 0.00.0 sims/demo/concert.txt 28002800 sims/demo/cafe.txt 5001000 sims/demo/university.txt 00 initialresidential 1 residentialresidential 1.0 concertresidential

6. Aufbau eines Demo-Szenarios

36

38

40

42

44

46

50

1.0 caferesidential 1.0 universityresidential 1.0 0.56

48

6.3 Die Benutzergruppen Es soll zwei Benutzergruppen zu je 10 Benutzern geben. Die erste Benutzergruppe befindet sich vormittags in der Universität und nachmittags in einem Cafe. Dies ist der tägliche Ablauf. Die restliche Zeit befinden sich die Benutzer zu Hause. Der Universitätsbesuch wird auf 10 bis 14 Uhr gelegt. Da jedoch nur der Entscheidungszeitraum angegeben werden kann, muss diese vor 10 Uhr fallen. In der Zeit von 7 (2.600) bis 9 Uhr (3.600) soll die Entscheidung zur Universität zu gehen getroffen werden. Die Aufenthaltszeit dort beträgt 1.600 Zeiteinheiten. Eines der Cafes soll um 16 Uhr besucht werden für die Dauer von ein bis zwei Stunden. Die Rückführung nach Hause geschieht durch den TimeBasedTripGenerator automatisch. Die XML-Eingabe für die erste Benutzergruppe, sieht folgendermaßen aus:

1

3

5

7

9

11

13

15

17

cafe 1.0 4600 1400 repeat 10000 400 800 university 1.0

6. Aufbau eines Demo-Szenarios

19

21

23

25

27

51

2600 1000 repeat 10000 1600 1600 0.56 1.39

29

Die zweite Benutzergruppe soll das gleiche Verhalten zeigen und sich, statt zu den Cafes, am ersten Tag zu dem Rockkonzert begeben. Die Entscheidung zum Rockkonzert zu gehen, fällt dabei circa eine Stunde vorher. Die Aufenthaltszeit soll 5 bis 6 Stunden (2.000-2.400 Zeiteinheiten) betragen.

2

concert 1.0 6400 1400 once 2000 2400 university 1.0 2600 1000 repeat 10000 1600 1600 0.56 1.39

6. Aufbau eines Demo-Szenarios

52

Abbildung 6.3: Eine Benutzergruppe versammelt sich auf einem Rockkonzert (Links im Bild).

Wie man an Abbildung 6.3 erkennen kann, versammeln sich im linken Teil des Bildes mehrere Benutzer. Sie versammeln sich an dem Punkt, an dem das Rockkonzert definiert worden ist. Wenn man dieses Demo-Szenario selbst starten möchte, muss man dazu die Klasse Runner mit dem Argument

sims/demo/demo.xml

stings der beiden XML-Dateien befindet sich im Anhang B.

starten. Li-

7 Fazit

Im Rahmen der Bachelorarbeit wurde das Programm CanuMobiSim erweitert. Entsprechend der Aufgabenstellung konnte der Import von Kartendaten im Open-StreetMap-Format implementiert werden. Kam es anfangs noch zu Problemen, die sich beim Import der OSM-Daten gestellt haben, konnten hier schnell Lösungen gefunden werden, die zudem eine Einarbeitung in die Struktur des Programms CanuMobiSim ermöglichten. Wie in Kapitel 6 durch die Demoszenarien beschrieben worden ist, wurde auch das Benutzerverhalten näher an die Realität angepasst. Schon vorher konnten in CanuMobiSim Szenarien so modelliert werden, dass einzelne Attraktoren die Häufung von Benutzern hervorrufen konnten. Jedoch war es bislang nicht möglich dies zeitbegrenzt und von den Affinitäten verschiedener Benutzergruppen abhängig zu machen. Auch dies ist jetzt möglich. Über den TimeBasedTripGenerator können Attraktoren zeitbasiert aktiviert werden. Es lassen sich beispielsweise Öffnungszeiten simulieren. Durch die Erweiterung der Klasse ConstantSpeedMotion zu RealisticConstantSpeedMotion können sich einzelne Benutzer aber auch Benutzergruppen für bestimmte Aktivitäten entscheiden. Passt man hier die Wahrscheinlichkeiten und Zeiten, ob eine Aktivität angenommen werden soll, entsprechend an, ist es möglich zeitbasiert zu bestimmen inwiefern Attraktoren die Häufung vieler Personen hervorrufen. Neben der Affinität zu einzelnen Aktivitäten, wie zum Beispiel Rockkonzerten, Kinobesuchen oder Fußballspielen, können nun auch gesamte Tagesabläufe periodisch oder einmalig definiert werden. Dadurch ist es möglich Alltagsverhalten zu simulieren. Darüber hinaus ist es auch hier durch die Angabe von Wahrscheinlichkeiten möglich, eine Abweichung vom Alltagsverhalten zu modellieren.

7.1 Verbesserungen Die Entwicklung der Software ist auf einem Stand abgeschlossen worden, der der Aufgabenstellung voll und ganz entspricht. Dennoch kann man an den neu program-

53

7. Fazit

54

mierten Teilen Verbesserungen vornehmen, die über den Rahmen dieser Bachelorarbeit jedoch hinaus gehen würden. Der Open-Street-Map-Import ist zwar vollständig implementiert. Jedoch wäre es hier wünschenswert, wenn die tags, die im OSM-Format definiert sind, auch direkt und möglichst unverarbeitet in das SpatialModel übernommen werden. Diese werden derzeit noch auf

typen

abgebildet, so dass einige

tags

eliminiert werden können,

da das OSM-Format theoretisch unendlich viele Tags erlaubt. Eine weitere Verbesserung kann am Zeitverhalten vorgenommen werden. Der TimeBasedTripGenerator kann die Ankunftszeiten eines Benutzers derzeit nur näherungsweise bestimmen, so dass Benutzer einen POI auch erreichen können, wenn dieser nicht mehr aktiv ist. Hier wäre es wünschenswert, wenn erst bei Ankunft an einer Zielkoordinate entschieden wird, ob diese aktiviert ist. Alternativ könnte man auch die Approximation an den realen Ankunftswert verbessern. Hierfür würde sich die Vorausberechnung mit Algorithmen, wie zum Beispiel Dijkstra anbieten. Damit einhergehend kann auch die Klasse RealisticConstantSpeedMotion verbessert werden. Hier kann nur der Entscheidungszeitraum definiert werden, in dem sich ein Benutzer für eine bestimmte Aktivität entscheidet. Jedoch kann es auch hier zu Abweichungen in der Ankunftszeit kommen. Wünschenswert wäre es hier, wenn man durch mehr Vorausberechnungen statt einem Entscheidungszeitraum den Zeitraum, in dem eine Aktivität von einem Benutzer durchgeführt werden soll, definieren kann.

A Tags, Types, Class Codes und Subclass Codes

Da tags aus dem Open-Street-Map-Format, bevor sie benutzt werden, vorher vereinfacht und übersetzt werden, ist es notwendig zu wissen, wie man die tags übersetzen möchte und wie diese hinterher auf der Karte dargestellt werden. Zu diesem Zweck hilft folgende Tabelle. Ist bei den

keys

oder

values

ein Wert nicht eingetragen, ist

der Wert für die weitere Verarbeitung irrelevant. Ebenso können für einige Class und Subclass Codes Werte direkt aus dem Open-Street-Map-Format, benutzt werden. Das ist mit @key oder @value gekennzeichnet. Die Farbe gibt an, in welcher Farbe das Objekt hinterher auf der Karte gezeichnet wird.

55

A. Tags, Types, Class Codes und Subclass Codes

Tag[osm02] key

Übersetzung value

56

Farbe

Class Code

Subclass Code

road

@value

Schwarz

road

motorway

Schwarz

junction

road

junction

Schwarz

traffic_calming

road

traffic_calming

Schwarz

cycleway

cycleway

@value

Weiß

waterway

waterway

@value

Blau

railway

railway

@value

Orange

aeroway

service

airport

Gelb

aerialway

service

aerialway

Gelb

service

service

@value

Gelb

highway motorroad

yes

service

shop

service

shop

Gelb

service

tourism

service

tourism

Gelb

amenity

@value

Rot

leisure leisure

park

landuse

park

Grün

leisure

dog_park

landuse

park

Grün

leisure

garden

landuse

park

Grün

sport

amenity

sport

Zyan

amenity

amenity

@value

Rot

man_made

building

@value

Beige

historic

building

historic

Beige

military

building

military

Beige

barrier

barrier

@value

Dunkles Grau

A. Tags, Types, Class Codes und Subclass Codes

57

landuse

village_green

landuse

park

Grün

landuse

recreation_ground

landuse

park

Grün

landuse

meadow

landuse

park

Grün

landuse

allotments

landuse

park

Grün

landuse

grass

landuse

park

Grün

landuse

cemetery

landuse

park

Grün

landuse

farm

landuse

farm

Dunkles Grau

landuse

farmland

landuse

farm

Dunkles Grau

landuse

farmyard

landuse

farm

Dunkles Grau

landuse

vineyard

landuse

woodland

Braun

landuse

orchard

landuse

woodland

Braun

landuse

forest

landuse

woodland

Braun

natural

wood

landuse

woodland

Braun

natural

tree

landuse

woodland

Braun

natural

water

waterway

water

Blau

natural

heath

landuse

park

Grün

construction

construction

Dunkles Grau

proposed

proposed

Dunkles Grau

landuse

residential

landuse

residential

Dunkles Grau

B Listings zum Demo-Szenario

demo.xml

2

5820 3970

4

sims/demo/initial.txt 0.0 0.0 sims/demo/residential/ .txt 0.0 0.0

58

B. Listings zum Demo-Szenario

26

28

30

32

34

sims/demo/concert.txt 2800 2800 sims/demo/cafe.txt / 500 1000 sims/demo/university./ txt00 initial residential 1 residential residential 1.0 concert residential / 1.0 caferesidential/ 1.0 universityresidential1.0 0.56

36

38

40

42

44

46

48

50

52

54

56

58

60

62

64

59

cafe 1.0 4600 1400 repeat 10000 400 800 university 1.0 2600 1000 repeat 10000 1600 1600 0.56 1.39

B. Listings zum Demo-Szenario 66

68

70

72

74

76

78

80

82

84

86

88

concert 1.0 6400 1400 once 2000 2400 university 1.0 2600 1000 repeat 10000 1600 1600 0.56 1.39

90



92



94



extractpoi.xml

1

3

5

7

9



60

B. Listings zum Demo-Szenario

11

amenitycafe landuseresidential

Literaturverzeichnis

[canu01]

C ANU M OBI S IM.

Stichwort

„Downloads“.

http://canu.

informatik.uni-stuttgart.de/mobisim/downloads/index.html.

Zuletzt besucht am 25.07.2010 um 11:24 Uhr. [wiki01]

W IKIPEDIA.

Stichwort

„Geographic

Data

Files“.

http:

//de.wikipedia.org/w/index.php?title=Geographic_Data_ Files&oldid=71474760.

Zuletzt besucht am 25.07.2010 um 11:28

Uhr. [gdf01]

E RTICO. Stichwort „GDF - Geographic Data Files“.

http:

//www.ertico.com/en/page_archive/gdf_-_geographic_data_ files.htm.

[wiki02]

Zuletzt besucht am 25.07.2010 um 11:29 Uhr.

W IKIPEDIA.

Stichwort

„World

Geodetic

System

1984“.

http://de.wikipedia.org/w/index.php?title=World_Geodetic_ System_1984&oldid=76841099.

Zuletzt besucht am 25.07.2010 um

11:30 Uhr. [wiki03]

W IKIPEDIA.

Stichwort

„UTM-Koordinatensystem“.

http://de.wikipedia.org/w/index.php?title= UTM-Koordinatensystem&oldid=74756600.

Zuletzt besucht am

25.07.2010 um 11:31 Uhr. [wiki04]

W IKIPEDIA. Stichwort „OpenStreetMap“.

http://de.wikipedia.

org/w/index.php?title=OpenStreetMap&oldid=76886701.

Zuletzt

besucht am 25.07.2010 um 11:32 Uhr. [osm01]

O PEN

S TREET

M AP.

Stichwort

„.osm“.

http://wiki.

openstreetmap.org/w/index.php?title=.osm&oldid=501318.

Zuletzt besucht am 25.07.2010 um 11:33 Uhr. [osm02]

O PEN

S TREET

M AP.

Stichwort

„Tag“.

http://wiki.

openstreetmap.org/w/index.php?title=Map_Features&oldid= 505262.

Zuletzt besucht am 25.07.2010 um 11:35 Uhr.

62

Literaturverzeichnis

[wiki05]

63

C HRISTIAN U LLENBOOM. Java ist auch eine Insel.

http:

//openbook.galileocomputing.de/javainsel8/javainsel_15_ 003.htm#mj0fff779ac9365f535b5c216632ae0d87

Zuletzt besucht

am 25.07.2010 um 11:36 Uhr. [canu02]

C ANU M OBI S IM. Stichwort „Licensing Information“. http://canu. informatik.uni-stuttgart.de/mobisim/licensing/index.html.

Zuletzt besucht am 25.07.2010 um 11:36 Uhr. [osm03]

O PEN

S TREET

M AP.

Stichwort

„Kartenausschnitt“.

http:

//www.openstreetmap.org/export/embed.html?bbox=9.69501, 52.3695,9.72659,52.38359&layer=mapnik.

Zuletzt besucht am

25.07.2010 um 11:37 Uhr. [canu03]

I LYA S TEPANOV. CanuMobiSim - a framework for user mobility modeling.

http://canu.informatik.uni-stuttgart.de/mobisim/

downloads/CanuMobiSim_1_3_4.pdf.

Suggest Documents