Geo Business Model Engineering - Informatik.uni

ProjINF Geo Business Modell Engineering
Omar Abada† , Thorsten Ohler‡ , Ilhan Tas∗
Abstract— Im Rahmen eines Forschungsprojekts an der Universität Stuttgart in Kooperation mit dem Fraunhofer-Institut für
Arbeitswirtschaft und Organisation (IAO) wurde für die Initiative [Innovationsnetzwerk Morgenstadt] der Fraunhofer Gesellschaft
ein Softwaresystem in Form einer Desktop-Anwendung entwickelt. Ziel dieser Plattform ist dabei eine effiziente Analyse des
Standorts bezüglich der für eine Dienstleistung erfolgversprechenden Kriterien im Hinblick auf ihre Existenz beziehungsweise
Nichtexistenz für die Abgabe einer Prognose zu den wirtschaftlichen Erfolgsaussichten. Hierbei erfolgt die Prognose auf der
Grundlage der Auswertung von öffentlich zur Verfügung stehenden Daten, sowie Sensordaten, die über eine mobile Anwendung
erfasst werden. Infolge der Abwesenheit einer solchen Anwendung, wurden die Sensordaten auf Basis vorhandener Daten
realistisch simuliert. Die verschiedenen Datensätze werden aufgrund ihrer Relevanz für die jeweilige Dienstleistung gewichtet.
Die Ergebnisse der Auswertung werden visuell dargestellt. Ferner bietet die Anwendung die Möglichkeit der Suche eines idealen
Standorts in einer eingegebenen Umgebung. Als Testumgebung wurde das Zentrum der Stadt Stuttgart ausgewählt, sowie als
Anwendungsfälle vier Dienstleistungen. Der modulare Aufbau der Software ermöglicht jederzeit eine leichte Erweiterung der
Menge der Dienstleistungen.
Index Terms—Standortanalyse, automasierte Standortbestimmung, Dienstleistungen, Sensordaten, Big Data, Stadtsysteme
1
E INLEITUNG
UND
M OTIVATION
ermöglichen.
Der Anteil der in der Stadt lebenden Weltbevölkerung hat im Jahr
2007 die 50% Marke überschritten. Schätzungen zufolge wird dieser Wert in den nächsten Jahrzehnten bereits 70% betragen1 . Gegenwärtige Konzepte, welche in Kapitel 3 näher erläutert werden,
scheiden im Hinblick auf die Komplexität der Standortproblematik
in der Stadt von Morgen2 als Lösungsweg aus.
Dienstleistungen prägen das Bild einer Stadt und stellen einen
enormen wirtschaftlichen Faktor dar. Ihre effiziente Ansiedlung ist
aufgrund der zu erwartenden Entwicklung von essentieller Natur.
Während der Dienstleistungssektor im Jahr 1991 63% der Bruttowertschöpfung ausmachte, stieg selbiger Anteil in zwei Jahrzehnten
bereits auf 69% (siehe Abbildung 1). Die Standortanalyse liefert
Antworten auf die Frage, wo eine Dienstleistung anzusiedeln ist. Sie
beschreibt den objektiven, methodisch orientierten und fachlich fundierten Untersuchungsprozess für eine Immobilieninvestition. Die
Standortanalyse beinhaltet das Sammeln, Gewichten und Bewerten
von Informationen, welche direkten beziehungsweise indirekten Einfluss auf die zukünftige Entwicklung der Immobilie haben[3][12].
Städte sind komplexe Systeme, die sich durch ein vielschichtiges
Beziehungsgeflecht zwischen der Bebauungsstruktur, den Infrastrukturnetzen (Strom, Wasser, Abwasser, Straßen, Bahnen, Telekommunikation) und dem Verhalten der Bewohner kennzeichnen und
insbesondere moderne Datenquellen. Jedes dieser Teilsysteme erzeugt Daten, welche für die Standortanalyse relevant sind. Um eine
Dienstleistung in einer Stadt zu etablieren, ist es notwendig zu untersuchen, wie das zugehörige Geschäftsmodell unter Berücksichtigung
dieser Wechselwirkungen optimal in das System Stadt eingebettet
werden kann. Methoden aus den Bereichen des Business Process/
Model Engineering und dem Systems Engineering können dazu
beitragen diese Fragen zu beantworten. Unklar bleibt jedoch wie
diese Methoden maschinell unterstützt werden können, damit sie
der Komplexität von Stadtsystemen gerecht werden. Dieses Projekt
betrachtet eine Facette der genannten Problemstellung, nämlich die
Bewertung, inwiefern eine gegebene Dienstleistung zu den Orten
passt, an denen sie angeboten werden soll. Hierbei liegt der Fokus auf
der kombinierten Nutzung verschiedener Datenquellen (Sensordaten,
Geoinformationssysteme, etc.), um eine automatische Bewertung zu
†
Abbildung 1: Wirtschaftsstruktur in Deutschland[11]
2
Viele Großstädte und Metropolen weltweit verfügen heute über
enorme Bevölkerungszahlen und zunehmend wachsende Zuwanderung 1 . Infolge dieses Trends der steigenden Einwohnerzahl und
Bevölkerungsdichte ist es unabdingbar auch die Abdeckung und optimale Verteilung der Dienstleistungen zu gewährleisten. Die Folge
dieser ungleichmäßigen Verteilung kann sein, dass an einem bestimmten Ort ein Über- bzw. Unter-Angebot von Dienstleistungen
entsteht.
Große Städte und Metropolen sind komplexe Systeme, die aus vielen
voneinander abhängigen Teilsystemen bestehen. Die Verteilung der
Dienstleistungen und die ganze Infrastruktur in diesen Ballungsgebieten hängen stark vom Bedarf der Bevölkerung und deren Verhalten ab. Die Schwierigkeit ist den Bedarf sowie das Verhalten der
Bevölkerung quantitativ zu erfassen und daraus Erkenntnisse für die
Neuansiedlung von Dienstleistungen zu gewinnen. Man muss sich
die Fragen stellen, welche Daten sich überhaupt praktisch erfassen
lassen, welche davon quantitativ sinnvoll bewertet werden können,
welche Daten benötigt werden und wie schnell diese Daten altern.
Besonders die letzte Frage der Aktualität der Daten unterscheidet
unseren Ansatz von anderen3 . In den meisten bereits bestehenden
Ansätzen sind die verwendeten Daten zur Standortbestimmung statischer Art, werden nur sehr selten aktualisiert und sind geografisch
nur sehr grob erfasst. In unserem Ansatz sollen die Daten direkt von
‡ Thorsten Ohler
∗ Ilhan Tas
Omar Abada
{ abadaor
ohlertn
tasin}
@studi.informatik.uni-stuttgart.de
1 Fraunhofer-Gesellschaft:
P ROBLEMSTELLUNG
Visionen zur Morgenstadt, Oktober 2013
Oktober 2013
2 http://www.morgenstadt.de,
3 www.standortanalyse.biz,
1
Oktober 2013
der Bevölkerung stammen. Rohdaten, die über eine externe mobile
Anwendung von Benutzern pseudonym hochgeladen werden, werden weiterverarbeitet und daraus entstehen unmittelbar, sich ständig
ändernde, aktuelle Daten. Diese dynamischen Daten sind nun nicht
mehr statisch und geografisch grob, sondern können exakt einem
beliebig groß gewählten Gebiet zugeordnet werden.
2.1
existieren nicht. Wenn sie überhaupt existieren, sind sie im Besitz
von privaten Firmen (z. B. Telekom, Deutsche Bahn, Facebook),
die die Daten nicht herausgeben. Für eine realistischere Simulation,
wären solche Daten von großer Wichtigkeit.
3 S TAND DER W ISSENSCHAFT UND T ECHNIK
Im Folgenden werden verwandte Arbeiten und Ansätze aus Wissenschaft und Technik angeführt und erläutert. Diese lassen sich in
die Bereiche Standortanalyse und Big Data beziehungsweise DataMining kategorisieren. Den Abschluss bildet eine Einordnung der
Relevanz dieser Ansätze für unser Projekt.
Berechnung des optimalen Standorts
Eine der wichtigsten Fragen, die es zu beantworten galt, war der
Entwurf eines Algorithmus’ zur Bewertung von Standorten. Am
Anfang stand eine von der Umgebung unabhängige Bewertung der
jeweiligen Standortfaktoren im Raum. Unabhängig heißt in diesem
Fall, dass für jeden Standortfaktor Wertebereiche erarbeitet werden,
die man für gut oder schlecht erachtet und abhängig davon eine
absolute Bewertung zuordnet.
3.1 Standortanalyse
Die Wahl eines geeigneten Standorts beschäftigt die Anbieter
von Waren und Dienstleistungen seit den Anfängen des Handels
in der Antike bis hin zur unmittelbaren Gegenwart. Auch in der
Zukunft wird diese Frage Menschen vor Herausforderungen stellen.
Trotz der weitreichenden Geschichte der Standortwahl, lassen
sich Ansätze einer parametrisierten Standortanalyse erst im 20.
Jahrhundert finden. Reilly beschreibt in seinem Buch ”The law of
retail gravitation”(1931)[2][8], in Anlehnung an das Newtonsche
Gravitationsgesetz, dass die Nachfrage von einem Wohnort auf zwei
umliegende Einkaufsstätten proportional zu der Einwohneranzahl
der Einkaufsstätte und umgekehrt proportional zum Quadrat der
Entfernungen dieser Stätten zum dazwischen liegenden Wohnort
ist. Diesen Zusammenhang veranschaulicht Reilly mit Gleichung (1).
Beispiel: Für Stuttgart sei eine Kaltmiete von unter 5,00 e pro
Quadratmeter pro Monat sehr günstig und würde daher 100% als
Bewertung bekommen. Die nachfolgenden Mietpreissegmente
würden nun entsprechend gestaffelt werden. Eine Kaltmiete von
5,00 e bis 7,00 e pro Quadratmeter pro Monat würde eine 90%
Bewertung bekommen. Eine Kaltmiete von 7,00 e bis 9,00 e pro
Quadratmeter pro Monat würde eine 80% Bewertung bekommen,
usw.
Dieser Versuch der Gliederung in Wertebereiche mit zugehöriger
absoluter Bewertung hätte nun für alle Standortfaktoren analog versucht werden können. Das Problem an dieser Vorgehensweise ist,
dass die Bewertung zum einen von unserer subjektiven Meinung
abhängig ist und zum anderen statisch und unabhängig von der Umgebung ist, anstatt dynamisch von der unmittelbaren Umgebung
erzeugt zu werden. Somit wäre die Bewertung weder aktuell, noch
könnte man sie woanders als in Stuttgart-Mitte verwenden, da anderenorts ein anderes Mietpreisniveau herrscht.
2.2
=
Pa
Pb
2
Db
∗
Da
Gleichung (1) : Gravitationsgesetz nach Reilly
Ba,
Pa,
Da,
Wahl der Standortfaktoren und Gewichtungen
:
:
:
b
b
b
Nachfrageanteil der Stätte a bzw. b
Einwohneranzahl der Stätte a bzw. b
Distanzen von a bzw. b zu dem Wohnort
Reilly verwendet in seinem Ansatz lediglich die zwei Parameter Entfernung und Einwohnerzahl für seine Analyse. Der Schwachpunkt
dieses Ansatzes liegt in den betrachteten Parametern. Gegenwärtige
Konzepte betrachten eine größere Anzahl an Standortfaktoren.
Modernere Modelle benutzen ein stochastisches Modell basierend
auf dem Huffschen Ansatz (1963)[4]. Dieser Ansatz wird in
Gleichung (2) angeführt. Er berechnet die Wahrscheinlichkeit
einer Kaufentscheidung eines Konsumenten aus der Stadt i in dem
Standort j.
Ein ähnliches Problem trat auf, als es um die Wahl der Standortfaktoren ging. Zu viele Standortfaktoren erhöhen die Laufzeit des Programms und die Größe der Datenbank und verringern die Übersicht
und den Fokus auf Wesentliches. Bei zu wenig Standortfaktoren
hingegen besteht die Gefahr, dass wichtige Standortfaktoren weggelassen werden, die für manche Dienstleistung unabdingbar sind
oder zumindest relevant für die Entscheidung. Es ist unklar welche
Standortfaktoren wichtig und welche Standortfaktoren in der Praxis
verfügbar und quantifizierbar sind.
Direkt danach stellt sich dann die Frage, welche der gewählten
Standortfaktoren zu den jeweiligen Dienstleistungen gehören und
wie wichtig sie für die jeweilige Dienstleistung in Relation zu den
anderen Standortfaktoren für diese Dienstleistung sind. Diese Frage
ist nur sehr subjektiv zu beantworten. Jedes Unternehmen kann die
Rolle eines Einflussfaktors, anhand verschiedener Bedürfnisse und
Anforderungen, anders als andere Unternehmen bewerten. Daher
sind flexible Einstellungsmöglichkeiten der Gewichtungen unabdingbar.
2.3
Ba
Bb
Pi j =
A j ∗ di−λ
j
J
∑ A j ∗ di−λ
j
j=1
Gleichung (2) : Einkaufswahrscheinlichkeit nach Huff
Aj
di j
λ
Verfügbarkeit von Daten
:
:
:
Attraktivität des Standorts j
Distanz zwischen Wohnort i und Standort j
Distanzparameter
Heutige Verfahren nehmen diesen Ansatz auf und erweitern
die Gleichung um weitere Variablen wie Image, Kaufkraft,
Preisniveau etc.[9].
Mittlerweile existieren kommerzielle webbasierte Standortanalyse
Tools in Form von Geomarketing Anwendungen.
Ein Beispiel solcher Anwendungen bietet die gb consite GmbH.
In ihrem online Standortcheck4 berücksichtigt die Anwendung
folgende Standortfaktoren:[10]
Aufgrund der starken Abhängigkeit von einer externen mobilen Anwendung, die außerhalb des Rahmens dieses Projektes liegt, gestaltete sich die Datenbeschaffung schwierig. Diese mobile Anwendung
sollte von jedem Nutzer die persönlichen Angaben, Ortungsdaten,
geografischen und meteorologische Daten kontinuierlich ermitteln,
aufzeichnen und speichern, um diese dann sobald eine Internetverbindung verfügbar ist, pseudonymisiert für die Speicherung in einer
Datenbank hochzuladen. Ein großes Problem bereitete der Versuch
die Daten näherungsweise realistisch zu simulieren. Daten vom statistischen Amt sind zwar öffentlich verfügbar, aber sind leider viel zu
grob. Die meisten benötigten Daten sind zu meist ganzen Städten, in
Einzelfällen Stadtteilen zugeordnet. Feinere Untergliederungen, beispielsweise mit der Genauigkeit von Straßen oder gar Hausnummern,
• Beschaffungsorientierte Standortfaktoren (Verkehrsanbindung)
• Absatzorientierte Standortfaktoren (Umsatzprognose, Kaufkraft, Konkurrenz)
4 www.standortanalyse.biz,
2
Oktober 2013
das Konzept der Shareconomy 6 , also der zunehmenden gemeinschaftlichen Nutzung von Produkten, Dienstleistungen etc. Es soll
die optimale Verteilung und Nutzung von Waren in der Stadt unterstützt werden. In diesem Use Case geht es konkret um eine LogBox für Werkzeuge. Es soll der gemeinsame Gebrauch von Werkzeugen ermöglicht werden. Hierfür werden die über eine Anwendung in
der Community nachgefragten Artikel in einer vorher vereinbarten
LogBox abgelegt.
Szenario 1 (Anbieter): Start-Up Unternehmen A möchte für die Aufstellung seiner LogBoxen die optimalen Standorte ermitteln. Mit
Hilfe der Desktop-Anwendung, die Standorte analysiert, ermittelt es
die optimalen Standorte und erspart sich eine Standortanalyse und
die damit verbundenen hohen Kosten.
Szenario 2 (Nachfrager): Person B möchte kleine Reparaturen in seinem Haushalt durchführen. Hierfür benötigt er eine Bohrmaschine,
einen Akkuschrauber sowie eine Stichsäge. Bevor er viel Geld ausgibt und diese Geräte kauft, möchte er sie über das LogBox-System
leihen. Leider steht ihm keine LogBox in unmittelbarer Nähe zur
Verfügung, weshalb er über die mobile Anwendung mitteilt, dass er
regelmäßigen Bedarf an einer solchen LogBox in der Nähe seiner
Wohnung hätte.
• Arbeitsorientierte Standortfaktoren (Arbeitsmarktkennzahlen)
• Abgabenorientierte Standortfaktoren (Gewerbesteuerhebesatz)
• Infrastrukturelle Standortfaktoren (Bildungseinrichtungen)
3.2
Big Data / Data-Mining
Big Data hat sich zu einem der Schlagworte in der gegenwärtigen
Informatik entwickelt. Dabei umfasst die Big Data Thematik die
vier Dimensionen Datenvolumen, -geschwindigkeit, -vielfalt und
-glaubwürdigkeit[1]. Die Grundidee besteht darin aus vorhandenen
großen Datensätzen neue Geschäftsmodelle abzuleiten respektive
neue kundenorientierte Angebote herzuleiten. Insbesondere IBM
forscht in diesem Bereich und arbeitet an Lösungen für die Handhabung großer Datenmengen[5].
Ein wichtiger Bestandteil dieses Projekts liegt in der Erfassung
und Analyse von großen Datenmengen. Dabei handelt es sich um
öffentlich verfügbare beziehungsweise über eine mobile Anwendung
zu beschaffende Daten. Karamshuk et al.[6] analysieren räumliche
beziehungsweise geografische Datensätze aus dem sozialen Netzwerk Foursquare um Dienstleistungen bezüglich ihrer Qualität zu
verbessern, sowie Städte intelligenter zu machen. Ihre Arbeit klassifizieren sie als Urban Mining5 . Qu und Zhang[7] leiten aus Foursquare Checkins Aktivitätszentren von Benutzern ab und erstellen
eine location history für sie. Aus diesen Datensätzen leiten sie neue
Geschäftsmodelle wie ortsgebundene Werbung ab.
3.3
4.2
Die Theodor-Heuss-Straße hat sich zu der Club- und Barmeile in
Stuttgart entwickelt. Können weitere Bars mit den vorhandenen
konkurrieren?
Szenario 1 (Anbieter): Jungunternehmer C aus München möchte
eine Bar in Stuttgart eröffnen. Er hat viel von der Theodor-HeussStraße als Partymeile gehört. Er stellt sich nun die Frage ob diese als
Standort für seine Bar in Frage kommt oder ob ein anderer Standort
mehr Erfolg verspricht. Hilfe leistet ihm dabei die automatisierte
Standortanalyse der Desktop-Anwendung.
Szenario 2 (Nachfrager): Person D nimmt regelmäßig am Stuttgarter
Nachtleben teil. Jedoch findet er das aktuelle Angebot an Bars und
Lounges als zu knapp und die vorhandenen Lokale als zu überfüllt.
In die Anwendung gibt er den Wunsch für den Standort einer neuen
Bar samt seinen Wünschen zur Musik und Ausstattung ein.
Relevanz der Ansätze für unsere Arbeit
Die angeführten Ansätze beschäftigen sich direkt beziehungsweise
indirekt mit der diesem Projekt zugrunde liegenden Problemstellung.
Unser Ansatz nutzt die Erkenntnisse aus den oben beschriebenen Bereichen. Insbesondere werden Standortfaktoren sowie Sensordaten
in unserer Anwendung in der Analyse betrachtet.
3.4
Abgrenzung unseres Ansatzes
Unser Ansatz nutzt eine Kombination der Erkenntnisse aus den beiden oben beschriebenen Bereichen und stellt somit ein neues Konzept für die Standortanalyse dar. Ein weiterer wichtiger Unterscheidungspunkt unseres Ansatzes liegt in der dynamischen Erfassung
und Speicherung der Daten. Dies garantiert, dass die Berechnung des
optimalen Standorts stets mit aktuellen Datensätzen durchgeführt
wird.
4
4.3
Im Folgenden werden die vier Use Cases, die in dem Projekt Geo
Business Model Engineering implementiert sind, angegeben und
erläutert. Zu den einzelnen Use Cases werden jeweils zwei Szenarien angegeben. Hierbei betrifft das erste Szenario jeweils die
Standortauswahl des jeweiligen Services und stellt somit die Anbieterperspektive dar. Der Anbieter sucht einen Standort für seine
Dienstleistung. Das zweite Szenario ist aus Benutzer-Sicht formuliert und beschreibt die Möglichkeiten für die User ihre Wünsche
über eine mobile Anwendung zu äußern, wo, nach ihrer Meinung,
noch Bedarf an der jeweiligen Dienstleistung besteht. Dieses Szenario setzt die Entwicklung einer mobilen Anwendung voraus, die
diese Informationen sammelt und uns zugänglich macht, um diese Information ebenfalls in die Suchanfrage aus Szenario 1 zu integrieren.
Die Erfassung von aktuellen Wünschen aus der Bevölkerung und
Einbeziehung in die Standortanalyse unterstreicht nochmal den Unterschied der Dynamik und Aktualität der Anwendung im Gegensatz
zu vergleichbaren Anwendung.
4.4
Use Case 4: Kinderbetreuungseinrichtung
Die Stadt Stuttgart sowie private Unternehmen sind daran interessiert
Kinderbetreuungsstellen in der Stuttgarter Innenstadt zu errichten.
Alleinerziehende Mütter und Väter haben die Möglichkeit ihre Kinder während dem Einkauf betreuen zu lassen, um so den Einkauf
schnell und mühelos zu erledigen.
Szenario 1 (Anbieter): Die Stadt G sowie private Unternehmen wollen ein Netz aus Kinderbetreuungsstellen in der Innenstadt errichten.
Mit der Desktop-Anwendung können diese sich eine teure Standortanalyse ersparen.
Szenario 2 (Nachfrager): Person H möchte auf der Königstrasse
shoppen. Als alleinerziehende Mutter muss sie ihre vierjährige Tochter immer mitnehmen. Es gibt leider keine Kinderbetreuung in der
Nähe. Ihren Bedarf meldet sie in der mobilen Anwendung.
Use Case 1: LogBox
Die LogBox ist ein aktuelles Forschungsprojekt des FraunhoferInstituts IAO. Es geht bei diesem Projekt um die Entwicklung eines
innovativen Logistik-Systems. Der Gedanke hinter dem Projekt ist
5 http://de.wikipedia.org/wiki/Urban
Use Case 3: Food-Truck
Der Food-Truck stellt ein mobiles Restaurant dar. Das Angebot kann
weitgehend der Nachfrage angepasst werden.
Szenario 1 (Anbieter): Food-Truck Besitzer E stellt sich jeden Tag
die Frage, an welchem Standort er seine Produkte anbieten soll. In
Frage kommen Orte mit hohem Menschendurchsatz, Sportereignisse, Feste, Veranstaltungen, große Baustellen, Schulen, Hochschulen
etc. Bei der Auswahl des täglichen Standorts kann ihm die DesktopAnwendung behilflich werden.
Szenario 2 (Nachfrager): Baustellenarbeiter F möchte zum Mittagsessen eine Currywurst essen. Hierfür gibt er in die Anwendung
seine Postion ein und wird zukünftig eventuell bedient.
U SE C ASES
4.1
Use Case 2: Bar
6 http://www.gruenderszene.de/allgemein/shareconomy-infografik, Oktober 2013
Mining, Oktober 2003
3
5 L ÖSUNGSANSATZ
Unsere Anwendung soll eine automatische Bewertung von Standorten zur Ansiedlung von Dienstleistungen abgeben, welche mit
Hilfe einer kombinierten Nutzung verschiedener Datenquellen zustande kommt.
Praktisch könnte die Anwendung als Entscheidungshilfe von den Verantwortlichen der Stadtplanung eingesetzt werden, um transparent
zu machen, wie, wo und warum etwas neu gebaut bzw. geändert werden könnte. Aber auch Kreditinstitute, Unternehmer und Privatleute
könnten einen erheblichen Nutzen aus der Anwendung ziehen. Banken könnte beispielsweise die Entscheidung über eine Kreditvergabe
für Dienstleistungen, die neu gegründet werden sollen, erleichtert
werden. Zudem könnten Existenzgründer bei ihren Überlegungen
die Anwendung zu Hilfe nehmen.
Anzahl dieses Ergebnisses ist nun der Menschendurchsatz in einem
Jahr an dieser Stelle. Diese muss nun durch die Anzahl der Nutzer
und durch 8760 (365 Tage x 24 Stunden) geteilt werden. Um nun
eine realistische, absolute Zahl zu erhalten, müsste das Ergebnis
nun noch hochgerechnet werden, je nachdem wie viel Prozent der
Bevölkerung die Anwendung regelmäßig nutzen. Aber auch ohne
diese Hochrechnung erhält man hier gute Vergleichswerte zwischen
den verschiedenen Orten. Weiterhin können beispielsweise der
Beschleunigungssensor und die Geschwindigkeit benutzt werden,
um zu differenzieren, ob es sich tatsächlich um einen Fußgänger
handelt und nicht fälschlicherweise um einen Radfahrer oder
Autofahrer, die an dieser Stelle nicht erfasst werden sollten. Analog
müsste für die anderen semantisch angereicherten Daten verfahren
werden.
5.1 Kategorisierung der Daten
Um eine Struktur und Übersicht der Daten zu erhalten, wurde das
Vorhaben in 4 grundlegende Ebenen unterteilt:
Zu den semantisch angereicherten Daten zählen:
• Mietpreis in e/m2 pro Monat
• Durchschnittliche Temperatur im Sommer in ◦ C
• Durchschnittliche Temperatur im Winter in ◦ C
• Durchschnittlicher Niederschlag in mm/m2
• Durchschnittliche Luftfeuchtigkeit in %
• Durchschnittliche Windgeschwindigkeit in km/h
• Durchschnittliches Einkommen pro Einwohner pro Jahr in e
• Arbeitslosenquote in %
• Anteil an Erwerbstätigen in %
• Bevölkerungsdichte in Einwohnern pro km2
• Einzugsgebiet im km2
• Durchschnittliche Anzahl an Passanten pro Stunde
• Durchschnittliche Anzahl an Kraftfahrzeugen pro Stunde
• Anteil an 0-17-Jährigen in %
• Anteil an 18-39-Jährigen in %
• Anteil an 40-65-Jährigen in %
• Anteil an über 66-Jährigen in %
• Anteil weiblicher Einwohner in %
• Anteil der in einer Beziehung lebenden Einwohner in %
• Anteil an Singles in %
• Anteil an Ausländern in %
• Anteil an Einwohnern mit regelmäßiger PKW Benutzung in %
• Anteil an Einw. mit regelmäßiger Fahrrad Benutzung in %
• Durchschnittliche Anzahl an Personen pro Haushalt
• Zuwanderung an Personen pro Jahr in %
• Abwanderung an Personen pro Jahr in %
• Verkehrsunfälle pro Jahr pro 1000 Einwohner
• Kriminalitätsrate in Anzahl von gemeldeten Verbrechen pro
1000 Einwohner
• Level 1 - Rohdaten: Daten, die durch eine Vielzahl von Nutzern
einer externen mobilen Anwendung erzeugt werden.
• Level 2 - Mapping der Rohdaten auf semantisch angereicherte
Daten. Die Daten hierfür wurden simuliert.
• Level 3 - Mapping der semantisch angereicherten Daten auf
vorgegebene Dienstleistungen und Standortanalyse.
• Level 4 - Berechnung des optimalen Standorts
5.1.1 Level 1 Rohdaten
Nutzer loggen mit einer mobilen Anwendung auf ihrem Smartphone
Daten mit. Es werden von jedem Nutzer alle Sensordaten erfasst
und einer eindeutigen Nutzer-ID zugeordnet. Beispiele für solche
Daten sind Datum, Uhrzeit, Längengrad, Breitengrad, Höhe über
Meeresspiegel, Beschleunigungssensor (x-, y-, z-Richtung), Geschwindigkeit, Licht, Orientierung (x-, y-, z-Richtung), Luftdruck,
Temperatur und Schallpegel (siehe Tabelle 1). Angaben zu der
Person des Nutzers können eingegeben oder über soziale Netze
abgegriffen werden (siehe Tabelle 2), sodass die Kombination aus
Sensor- und Nutzer-Angaben dazu benutzt werden können die
semantisch angereicherten Daten zu bilden.
5.1.2 Level 2: semantisch angereicherte Daten
Die Tabellen 1 und 2 werden miteinander, durch die Zuordnung der
Nutzer-ID, verknüpft. Per passender SQL-Befehle bzw. anderen und
weiteren Berechnungen ist es dann auch möglich die semantisch
angereicherten Daten zu berechnen und diese in der Standortanalyse
zu verwenden.
Hierbei muss man beachten, dass die Sensordaten (siehe Tabelle 1)
enorm hohe Datenmengen ergeben. Angenommen der Datensatz
für einen Nutzer würde beispielsweise 60 Byte (15 Werte a 4 Byte)
betragen und es würde sekündlich geloggt werden. Dann würde
das bedeuten, dass die Datenbank innerhalb von 24 Stunden und
100.000 Nutzern folgende Datenmenge verwalten müsste:
100.000 Nutzer x (24 Stunden x 60 Minuten x 60 Sekunden) x 60
Byte (pro Datensatz) = 520 GByte.
Der Durchsatz würde bei 100.000 x 60 Byte = 6 MByte/s liegen.
Diese Datenmenge erfordert die intensive Untersuchung hinsichtlich
der Prinzipien des Big Data.
Unter anderem lässt sich beispielsweise der Menschendurchsatz aus
mehreren Faktoren der gesammelten Rohdaten bilden. Folgende
Rohdaten sind für die Berechnung des Menschendurchsatzes von
besonderer Bedeutung: Datum, Uhrzeit, Längengrad, Breitengrad,
Beschleunigungssensor und Geschwindigkeit.
Im Folgenden wird eine Vorgehensweise skizziert, um aus den
Rohdaten den durchschnittliche Durchsatz an Passanten pro Stunde
an einem bestimmten Ort zu bestimmen: Man nehme von allen
Nutzerdatensätzen den gleichen Ausschnitt von einem Jahr. Nun
sucht man in allen Datensätzen den Längen- und Breitengrad des
Ortes, für den der Menschendurchsatz bestimmt werden soll. Die
5.1.3 Level 3: Mapping der semantisch angereicherten Daten auf vorgegebene Dienstleistungen und Standortanalyse
In dieser Ebene geht es um das Mapping der semantisch angereicherten Daten auf vorgegebene Dienstleistungen und die darauf
aufbauende Suche nach optimalen Standorten für diese Dienstleistungen.
Da das Mapping, wie in Problemstellung 2.2 beschrieben, nicht allgemeingültig formuliert werden kann, wird es dem Nutzer überlassen
zu bestimmen, welche Standortfaktoren er als wichtig erachtet. Es
wird lediglich eine Vorauswahl an Standortfaktoren für eine jeweilige Dienstleistung getroffen. Auch die zugehörigen Gewichtungen,
also das Verhältnis der Wichtigkeit zwischen den Standortfaktoren
untereinander, kann vom Nutzer festgelegt werden. Der Nutzer hat
die Möglichkeit die Standortfaktoren individuell zu gewichten. Für
die Suche eines besonders niedrigen bzw. hohen Wert stehen ihm
dabei die Vorzeichen - und + zur Verfügung. Das heißt eine negative
Gewichtung bedeutet, dass die Anwendung bei der optimalen Standortsuche versucht einen von der Gewichtung abhängig möglichst
niedrigen Wert zu suchen bzw. bei einer positiven Gewichtung einen
möglichst hohen Wert (siehe Abbildung 2).
4
Datum
13.10.13
13.10.13
13.10.13
13.10.13
...
Uhrzeit
11:30:01
11:33:02
11:33:03
11:33:04
...
Breitengrad
48.7436
46.7437
46.7437
46.7438
...
Längengrad
9.1075
9.1075
9.1076
9.1077
...
Beschleunigungssensor (m/s2 )
(-0.011, 0.039, -1.004)
(-0.021, 0.041, -2.013)
(-0.021, 0.019, -0.099)
(-0.051, 0.211, -3.011)
...
Höhe (m)
448.5
449.1
449.3
449.3
...
Geschwindigkeit (m/s)
3.3
4.7
8.1
3.2
...
...
...
...
...
...
...
Tabelle 1: Log Tabelle für ausgewählte Sensordaten von einer Nutzer-ID
Nutzer-ID
001
002
...
Geburtsdatum
...
...
...
Beziehungsstatus
...
...
...
Beruf
...
...
...
Wohnort
...
...
...
Interessiert an
...
...
...
...
...
...
...
Tabelle 2: Persönliche Angaben der Nutzer - z. B. von Sozialen Netzwerken
dass der tatsächlich momentan niedrigste Preis auch wirklich mit
100% und der teuerste mit 0% bewertet.
Hierbei ist vorausgesetzt, dass ein niedrigerer Preis besser als ein
hoher Preis bewertet werden soll. Natürlich könnte man die Bewertung auch umdrehen. Durch dieses Vorgehen, ist die Bewertung
nicht mehr abhängig von einem einmal festgelegten, statischen Wert,
sondern wird dynamisch für jede Bewertung neu ermittelt und ist
somit immer aktuell. Außerdem wird damit verhindert, dass das Programm nur für Stuttgart-Mitte funktionieren würde, sondern auch
in München, wo die Mietpreise höher sind oder Leipzig, wo sie
niedriger sind.
5.2
Abbildung 2: Ausschnitt Programm: Wahl der Gewichtungen
5.1.4
Repräsentation der Karte in der Datenbank
Eine weitere Herausforderung die im Verlauf des Projektes Schwierigkeiten bereitet hat, war die Repräsentation eines Ortes in der
Datenbank.
Es gab zwei grundsätzlich verschiedene Optionen. Die erste war
einen Ort anhand seiner Adresse eindeutig in der Datenbank zu identifizieren. Dies hätte den Vorteil, dass weniger Geocoding-Anfragen
per Google-API (Application Programming Interface) gesendet
und empfangen werden müssten. Geocoding wird der Vorgang des
Übersetzens einer Adresse in Längen- und Breitengrad genannt. Reverse Geocoding ist dementsprechend die Rückrichtung, d. h. einem
Längen- und Breitengrad wird einer Adresse zugeordnet. Außerdem
könnten Daten, die wir für die Simulation erhalten, aber z. B. einer
Straße und nicht der Straße zugehörigen Längen- und Breitengrade
zugeordnet sind (beispielsweise der Durchsatz von Passanten pro
Stunde in einer bestimmten Straße), leichter in der Datenbank abgelegt werden.
Die zweite Option bestand darin, die Orte anhand ihres Längen- und
Breitgrades eindeutig in der Datenbank zu identifizieren. Der Hauptvorteil hier ist, dass jeder Ort eindeutig und viel genauer identifiziert
werden kann. Während zwischen Adressen einige hundert Meter liegen können, liegt die Genauigkeit hier im einstelligen Meterbereich.
Auch Orte ohne Adresse können zugeordnet werden. Ein weiterer
großer Vorteil dieser Option ist, dass die externe mobile Anwendung,
die der Desktop-Anwendung die Daten später zur Verfügung stellen
soll, höchstwahrscheinlich ebenfalls ihre Daten intern Längen- und
Breitengrad (z. B. SensorLog7 ) zuordnet und so eine Konsistenz
zwischen den Anwendungen bzw. den Datenbanken herrscht. Für
die interne Darstellung der Landkarte im Programm bzw. der Datenbank, wurde entschieden, dass die Variante der Darstellung eines
Ortes per Längen- und Breitengrad die bessere Variante ist.
Es galt allerdings noch die Frage zu klären, in wie große Segmente
die Karte unterteilt werden soll. Es gab wieder eine Abwägung:
Speicherbedarf und Rechenzeit gegen Genauigkeit der Bewertung.
Wie bereits erwähnt, wurde im Rahmen des Projekts die Region
Berechnung des optimalen Standorts
Wie in Problemstellung 2.1 angesprochen, war es ein Problem, dass
die Bewertung eines Ortes nicht unabhängig von seiner Umgebung
sein durfte. Das heißt die Idee die Bewertung abhängig von der
Umgebung zu machen war naheliegend. Die Vorgehensweise wird
am folgenden Beispiel verständlich:
Der Standortfaktor sei wieder die Kaltmiete pro Quadratmeter pro
Monat, d. h. es soll eine Bewertung für ein Objekt in StuttgartMitte ermittelt werden. Um eine Bewertung in Abhängigkeit der
Umgebung zu bekommen, betrachte man alle Preise in StuttgartMitte und ermittle die Anzahl an verschiedenen Vorkommen von
Werten. Der Einfachhalt halber nehmen wir an, dass die Preise linear
in 0,05 e Schritten verteilt sind. Die Werte in Stuttgart-Mitte reichen
von 4,00 e bis 16,00 e. Das heißt es gibt 20x12 = 240 verschiedene
Werte, dann wäre ein Objekt mit einem Mietpreis von 12,65 e mit
((12.65-4)/0.05)/240 = 72,08% zu bewerten. Somit ist garantiert,
7 https://itunes.apple.com/de/app/sensorlog/id388014573,
5
Oktober 2013
Stuttgart-Mitte untersucht. Der Bereich der intern in Segmente
unterteilt wurde ist exakt der folgende: (siehe auch Abbildung 4)
•
•
•
•
renden und förderlichen Dienstleistungen berechnet, Adressen in
Längen- und Breitengrad und umgekehrt per Geocoding übersetzt
und Near-By-Searches ausgeführt, um die eben genannten konkurrierenden und förderlichen Dienstleistungen in der Nähe eines Ortes
zu lokalisieren und zusätzliche Informationen über diesen Ort zu
erhalten.
Als Ausgabe erhält der Nutzer eine ausführliche Bewertung über alle
Einflussfaktoren, die zu diesem Ort existieren, zusammen mit dem
optimalen Standort und vier möglichen Alternativen. Dazu werden
die Werte auch mit den Durchschnittswerten der Region, in der die
Anwendung die Standortanalyse durchgeführt hat, verglichen. Weiterhin werden die vom Nutzer gewählten Einflussfaktoren in grün
gefärbt, um eine bessere Übersicht zu erhalten. Ebenfalls aufgeführt
sind die Distanzen zu förderlichen und konkurrierenden Dienstleistungen. Auf der Landkarte werden der optimale Ort und die vier
alternativen Orte eingezeichnet. Außerdem wird auf der Karte angezeigt, was für konkurrierende und förderliche Dienstleistungen sich
wo befinden, als auch Möglichkeiten zur Nutzung von öffentlichen
Verkehrsmitteln.
Oben-Links: Breitengrad: 48.7900, Längengrad: 9.1600.
Oben-Rechts: Breitengrad: 48.7900, Längengrad: 9.2000.
Unten-Links: Breitengrad: 48.7700, Längengrad: 9.1600.
Unten-Rechts: Breitengrad: 48.7700, Längengrad: 9.2000.
Dies ist ein Rechteck der Größe: Breite 2,94 km, Höhe: 2,2 km. Wir
haben uns daher dafür entschieden folgende Größen zu verwenden:
Gitternetzgröße: Breite: 7,32 m, Höhe: 11,1 m
Umrechnung Breitengrad in Meter:
Erdumfang/360 ≈ 40000 km/360 ≈ 111 km. Für eine Genauigkeit
von vier Nachkommastellen: 111 km/10000 = 11,1 m
Umrechnung Längengrad in Meter:
∆ Längengrad * cos(Breitengrad) ≈ 111 km * cos(48.77) ≈ 73,16
km. Für eine Genauigkeit von vier Nachkommastellen: 73,16
km/10000 ≈ 7,32 m
Das ergab für den obigen Bereich Stuttgart-Mitte ein Gitternetz
mit 201 Zeilen und 401 Spalten: 201 x 401 = 80601 Orte (80601
Zeilen in der Datenbank), wenn mit einer Genauigkeit von 4 Nachkommastellen gearbeitet wird. Praktisch möglich, d. h. von Google
unterscheidbar, wäre eine Genauigkeit von 6 Nachkommastellen
gewesen. Dies hätte einer Gitternetzgröße von nur wenigen Zentimetern entsprochen und wäre daher völlig übertrieben gewesen. Eine
Gitternetzgröße von einigen Metern erschien dahingegen sinnvoll,
da so einzelne Hausnummern relativ präzise unterschieden werden
können und der Speicherbedarf und die Geschwindigkeit trotzdem
erträglich bleiben. Wir hatten 28 Standortfaktoren pro Ort definiert
(28 Spalten in der Datenbank). Das heißt insgesamt waren 80601 x
28 = 2256828 Einträge in der Datenbank von Nöten, um Stuttgart
Mitte in der Datenbank mit der oben genannten Genauigkeit abzubilden. Bei einer Größe von 4 Byte pro Eintrag für einen Standortfaktor
in der Datenbank, ergibt dies eine Datenmenge von 2256828 x 4
Byte = 9027312 Byte = ca. 9 MByte.
5.3
6 I MPLEMENTIERUNG
6.1 Wahl des Datenbankmodells und der Datenbank
Für das relationale Datenbankmodell sprach die Repräsentation in
Tabellen, da erwartet wurde, dass die Daten sehr vieler Nutzer gesammelt und geschrieben werden müssen und sich diese am besten in
Tabellen repräsentieren lassen. Bei relationalen Datenbanken können
die Daten zeilenweise gut über Tabellen verwaltet werden und die
Beziehungen zwischen Daten kann flexibel, ohne eine vorausgesetzte Abhängigkeit, festgelegt werden. Somit stand die Datenbanksprache SQL (Structured Query Language) fest. Unter den SQLImplementierungen stehen eine große Ansammlung an Alternativen
zur Verfügung, wie z. B. Microsoft SQL Server, MySQL, SQLite.
Faktoren, die für die Wahl entscheidend waren, waren vor allem die
Kosten, die Lauffähigkeit auf den verschiedenen Betriebssystemen,
die unterstützten Programmiersprachen, die Geschwindigkeit und
die Skalierbarkeit. Aber auch die Verbreitung und der dadurch gute,
meist kostenlose, Support durch die große Nutzer- und Entwicklergemeinde waren zu berücksichtigen.
Als Datenbank wurde SQLite gewählt, da diese die konstengünstigste Option darstellt und kein Root-Server nötig ist. Außerdem war es mit SQLite möglich die Datenbank lokal mit dem
Programm mitzuführen und trotzdem die Vorteile von SQL nutzen zu
können. Des weiteren ist es sehr leicht möglich, insbesondere durch
eine gesonderte Datenbankschicht in der Anwendungsarchitektur,
die Anwendung mit wenig Zeilen Code auf MySQL umzustellen
und so eine MySQL-Datenbank online, statt lokal mitgeführt, zu
verwenden.
Allgemeiner Datenfluss und Programmablauf
In Abbildung 3 (siehe Anhang A) ist dargestellt, wie die Daten aus
der realen Welt über die schon angesprochene mobile Anwendung
von den Nutzern gesammelt und verarbeitet werden bis hin zur Berechnung des optimalen Standorts. Hierbei sollte man beachten, dass
der obere, gestrichelt gezeichnete Teil, in dem die Daten von der
realen Welt von den Nutzern per mobiler Anwendung eingelesen
werden, hin bis zur Verarbeitung der Rohdaten in semantisch angereicherte Daten außerhalb des Rahmens dieses Projekts stattfindet.
Der restliche Teil stellt den Datenfluss unserer Anwendung dar. Es
wurde also schon eine bestehende, befüllte Datenbank vorausgesetzt.
Diese ist als ”Level 2: Datenbank” in Abbildung 3 (siehe Anhang
A) dargestellt. Das Programm holt sich die benötigten Daten bei
jeder Ausführung neu per SQL-Anfragen aus der Datenbank. Es
wird versucht eine möglichst starke Vorauswahl per SQL-Befehlen
zu erreichen bzw. einfache Berechnungen von SQL erledigen zu
lassen, um so unnötige Übertragungszeiten einzusparen.
Die Eingabefelder im Programm fordern den Programm-Nutzer dazu auf, einen Ort einzugeben. Dies kann eine Straße, ein Stadtteil
oder eine ganze Stadt sein oder soll später auch per Auswahl auf
der Karte möglich sein. In unserer Anwendung ist momentan nur
Stuttgart Mitte implementiert. Weiterhin kann der Nutzer eines der
vier Dienstleistungen (siehe Use Cases) auswählen. Daraufhin werden ihm vorausgewählte Standortfaktoren inklusive der zugehörigen
Gewichtungen vorgeschlagen. Auch diese Daten werden vom Programm später verarbeitet.
Nach der Eingabe des Nutzers, schickt das Programm mehrere Anfragen an die Google-API 8 und an die OpenstreetMaps Server 9 ,
die die Landkarte bzw. Tile-Maps zur Verfügung stellen. Von der
Google-API werden Entfernungen zwischen Orten und konkurrie-
6.2 Architektur
Für die Strukturierung der Anwendung haben wir uns für die
Drei-Schichten-Architektur entschieden. Durch die drei Schichten
wird versucht die Komplexität der Abhängigkeiten innerhalb der
Anwendung zu reduzieren und somit eine geringere Kopplung bei
gleichzeitig höherer Kohäsion der einzelnen Schichten zu erreichen.
Dies soll eine gute Erweiter- und Wartbarkeit gewährleisten und
das Verständnis der Anwendung erhöhen. Die Drei-SchichtenArchitektur besteht aus den folgenden drei Schichten. Zu jeder
Schicht sind exemplarisch zugehörige Klassen aufgeführt.
Die Präsentationsschicht ist für die Repräsentation der Daten, Benutzereingaben und die Benutzerschnittstelle verantwortlich.
• Mainwindow.java - Benutzeroberfläche zur Eingabe des Ortes,
Auswahl der Dienstleistung und Wahl der Standortfaktoren
und Gewichtung
• SwingWaypoint.java - Klasse, um Standorte, förderlichen/
konkurrierenden Dienstleistungen und öffentlichen Verkehrsmittel per Wegpunkt auf der Karte anzuzeigen.
8 https://developers.google.com/maps/?hl=de,
9 http://wiki.openstreetmap.org/wiki/API
Oktober 2013
v0.6, Oktober 2013
6
preis
8.37
8.39
8.42
8.43
...
Die Logikschicht beinhaltet alle Verarbeitungsmechanismen. In
dieser Schicht befinden sich die Klassen, die die Anwendungslogik
implementieren.
• Optimise.java - Bereitstellung des Algorithmus und alle
nötigen Funktionen, die benötigt werden, um die Bewertung
aller Orte durchzuführen
• Location.java - Klasse, die die Orte in der Anwendungslogik darstellt. Jeder Ort hat seine eigenen Werte und die dazugehörigen Bewertungen für jeden Standortfaktor
• Service.java - Klasse, die die Dienstleistungen in der
Anwendungslogik darstellt.
Tabelle 3: Beispiel eines Ausschnitts der Tabelle für den Standortfaktor Preis, die man zurückbekommt, wenn man Zeile 6 ausführt
1
Datenhaltungsschicht: Sie enthält die Datenbank und ist verantwortlich für das Speichern und Laden von Daten.
2
3
• DBController.java - Steuerung der Datenbank. Laden des
JDBC-Treibers, Aufbauen und Abbauen der Verbindung mit
der Datenbank
• DBInterface.java - Datenbank-Schnittstelle
• GooglePlacesClient.java - Schnittstelle um mit der GoogleAPI zu kommunizieren
4
5
6
Es wurde versucht die Schichten gemäß der Einteilung so gut
wie möglich zu entkoppeln. Als Programmiersprache wurde Java
gewählt, da hier schon einige Bibliotheken vorhanden waren, um
schon vorhandene Dienste und APIs nutzen zu können. Ein weiterer
Vorteil von Java ist die Plattform-Unabhängigkeit.
Die Bibliotheken swingx.JXMapViewer, swingx.JXMapKit.* und
swingx.mapviewer.* wurden verwendet um den Zugriff zu den
OpenStreet-TileMaps zu realisieren und somit die Kartendarstellung
umzusetzen. Weiterhin wurden die Bibliotheken java.sql.Connection,
java.sql.DriverManager, org.sqlite.JDBC und sqlite-jdbc-3.7.2 verwendet, um eine SQL-Datenbank in die Anwendung zu integrieren.
Über diese Bibliotheken war es nun möglich eine Verbindung
zur Datenbank aufzubauen und SQL-Anfragen zu senden und
ResultSets zu empfangen. Für den Umgang mit der Google-API
wurden com.google.gson.Gson, java.net.URLConnection und
org.apache.http.* verwendet.
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
6.3
locations
(48.7701, 9.1718), (48.7701, 9.1718), (48.7701, 9.1718)
(48.7123, 9.1432), (48.7701, 9.1718)
(48.7821, 9.1321), (48.7701, 9.1718), (48.7701, 9.1718)
(48.7748, 9.1456)
...
Algorithmen
23
Der folgende Algorithmus führt eine Bewertung für jeden Standortfaktor eines Ortes durch. Diese Bewertung wird für alle zu bewertenden Orte durchgeführt. Die Bewertung ist nicht unabhängig, sondern
bezieht die anderen Orte vergleichend mit in die Bewertung ein, um
so eine Bewertung in Abhängigkeit ihrer Umgebung zu erhalten. Die
Rückgabe ist eine Liste mit allen bewerteten Orten. Die Laufzeit
beträgt O(n*m), wobei n = Anzahl der Orte und m = Anzahl der
Standortfaktoren. Für Stuttgart-Mitte ist n = 80601. In Zeile 3 wird
eine Hashmap angelegt, um so die Suche nach schon vorhandenen
Orten in konstanter Zeit durchführen zu können. In Zeile 5 wird
per SQL-Anfrage an die Datenbank die Anzahl an verschiedenen
Werten des jeweiligen Standortfaktors in der Datenbank ermittelt. In
Zeile 6 wird ebenfalls eine SQL-Anfrage ausgeführt. Die Rückgabe
ist eine Tabelle, die für jeden verschiedenen Wert eines jeweiligen
Standortfaktors die zugehörigen Längen- und Breitengrade als Location ausgibt (siehe Tabelle 3). In Zeile 9 wird die Bewertung für
den jeweiligen Standortfaktor berechnet. Sie ist der Quotient aus
der Platzierung innerhalb der verschiedenen Werte des jeweiligen
Standortfaktors und der Gesamtanzahl der verschiedenen Werte des
selbigen. Zeile 10 stellt sicher, dass alle Locations je nach Wert der
Tabelle durchlaufen werden. In den Zeilen 11-16 wird überprüft, ob
die Hashmap diesen Ort bereits enthält. Wenn dies der Fall ist, wird
dieser Ort genommen, wenn nicht wird ein neuer Ort erstellt und der
Hashmap hinzugefügt. Für den Ort wird nun die Bewertung für die
jeweilige Dienstleistung zugeteilt. In Zeile 22 wird eine Liste mit
den bewerteten Orten zurückgegeben.
public ArrayList<Location> locationOptima() {
double maxDistinct;
Map<Location, Location> locationMap := new
HashMap<Location,Location>();
for alle_Standortfaktoren standortfaktor do
maxDistinct := doQuery("SELECT count(
DISTINCT standortfaktor) as maxDistinct
FROM overall");
resultSet := doQuery("SELECT standortfaktor
, group_concat(lat) as lat,
group_concat(lng) as lng FROM overall
GROUP BY standortfaktor");
int zeile := 0;
while (resultSet.next())
bewertung := zeile/maxDistinct;
for alle_Locations_Je_Wert j do
if (locationMap.contains(j))
location := locationMap.get(j);
else {
location := new Location(j);
locationMap.put(j, location);
}
od
location.Bewertung_standortfaktor :=
bewertung;
zeile := zeile + 1;
}
od
return new ArrayList<Location>(locationMap.
values());
}
Algorithmus 1: Bewertung aller Standortfaktoren eins Ortes
Der folgende Algorithmus berechnet den optimalen Ort in
Abhängigkeit von den gewählten Standortfaktoren und ihren zugehörigen Gewichtungen. Die Laufzeit beträgt ebenfalls O(n*m),
wobei n = Anzahl der Orte und m = Anzahl der Standortfaktoren ist.
In den Zeilen 3-6 wird die Summe aller gewählten Gewichtungen
aufaddiert. In den Zeilen 7-15 wird für jeden Ort seine Gesamtbewertung in Abhängigkeit von den gewählten Standortfaktoren und
ihren zugehörigen Gewichtungen berechnet. Hierzu werden alle Orte durchlaufen und für jeden Ort wiederum alle zur Dienstleistung
gehörenden Standortfaktoren, um so jeweils die einzelne Bewertung
eines Standortfaktors mit seiner Gewichtung zu multiplizieren und
diese Teilergebnisse aufzusummieren. Diese Gesamtsumme wird am
Ende durch das vorher errechnete Gesamtgewicht geteilt um eine
Gesamtbewertung für einen Ort zu erhalten. In den Zeilen 9 und 11
wird überprüft, ob die Gewichtungen positiv oder negativ sind. Ist
die Gewichtung negativ ist ein niedrigerer Wert besser, ist sie positiv
ist ein höherer Wert besser. In Zeile 16 wird die Liste mit allen Orten
dann nach ihrer Gesamtbewertung sortiert, um so den optimalen Ort
und die nächstbesten Orte zu erhalten.
7
7
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public Location optimium() {
ArrayList<Location> allLocations :=
locationOptima();
double gesamtGewichtung := 0;
for alle_Eingaben_Gewichtung gewichtung do
gesamtGewichtung := gesamtGewichtung + Math
.abs(gewichtung);
od
for (allLocations currentLocation) do
for (alle_Standortfaktoren_Dieser_Dleistung
standortfaktor) do
if (standortfaktor_gewichtung < 0)
currentLocation.Gesamtbewertung :=
currentLocation.Gesamtbewertung +
(1 - currentLocation.
Bewertung_standortfaktor) *
standortfaktor_gewichtung * (-1);
else
currentLocation.Gesamtbewertung :=
currentLocation.Gesamtbewertung +
currentLocation.
Bewertung_standortfaktor *
standortfaktor_gewichtung;
od
currentLocation.Gesamtbewertung :=
currentLocation.Gesamtbewertung /
gesamtGewichtung;
od
sort(allLocations, Gesamtbewertung)
return location;
}
8
E VALUATION
Um sicherzustellen, dass sowohl die Normalfälle, als auch
fehlerhafte Eingaben sowie sämtliche Extremfälle korrekt behandelt
werden, wurden mehrere Testdurchläufe mit einem 2.7 GHz
Intel Core i7 Prozessor und einer Internetverbindung mit einer
Geschwindigkeit von bis zu 50 MBit/s durchgeführt. Im Folgenden
werden einige dieser Eingabe- und Ausgabedaten zusammen
mit der Berechnungsdauer aufgeführt und darauffolgend die
Ergebnisse diskutiert. Die Einträge unter der Spalte Dauer sind der
Durchschnittswert aus 10 Durchläufen pro Testfall.
Nr.
1
2
3
4
5
6
Eingabe
LogBox:
voreingestellte Gewichtung,
Ort: Stuttgart Mitte
Bar: voreingestellte
Gewichtung,
Ort:
Stuttgart Mitte
Food-Truck: voreingestellte Gewichtung,
Ort: Stuttgart Mitte
Kinderbetreuung: voreingest. Gewichtung,
Ort: Stuttgart Mitte
LogBox: Min. Preis
und die restl. Gewichtungen auf ’0’ setzen,
Ort: Stuttgart Mitte
Food-Truck: Preis und
Bevölkerungsdichte
auf ’10’ setzen , Ort:
Stuttgart Mitte
Ausgabe
Silberburgstr. 70A,
70176
Stuttgart,
Bewertung: 89.89%
Canstatter Str. 46,
70190
Stuttgart,
Bewertung: 92.47%
Urbanstr. 94, 70190
Stuttgart, Bewertung:
87.68%
Urachstr. 5, 70190
Stuttgart, Bewertung:
87.40%
Konrad-AdenauerStr. 3, 70173 Stuttgart,
Bewertung:
100.0%
Schottstr. 81, 70192
Stuttgart, Bewertung:
99.75%
Fehlermeldung:
data
no
0.1 s
Fehlermeldung: Bitte geben Sie mind.
einen Standortfaktor
an
0.1 s
Im Folgenden werden die Ergebnisse ausgewertet:
Algorithmus 2: Optimaler Standort
7
LogBox:
voreingestellte Gewichtung,
Ort: München
LogBox: alle Gewichtungen auf ’0’ setzen,
Ort: Stuttgart Mitte
Dauer
34.05 s
46.91 s
50.34 s
23.92 s
31.34 s
51.42 s
8
• Test 1: Normalfall LogBox
Folgende Standortfaktoren sind voreingestellt: Preis (-10), Einkommen (-8), Bevölkerungsdichte (9), Einzugsgebiet (9), Anzahl Personen pro Haushalt (-1), Anteil an Singles (1), Anteil weiblich (2), Distanz öffentliche Verkehrsmittel (-5), Distanz Baumarkt (-3), Distanz Wohnheim (-1). Das Ergebnis
des Mietpreises von 8,48 e pro m2 pro Monat ist realistisch
niedrig. Die Abweichung vom Durchschnittswert von 10,46 e
beträgt 18,92%. Auch das Einkommen ist mit 26694,17 e
ein gutes Stück, nämlich 8,34% unter dem Durchschnitt. Die
Bevölkerungsdichte lag dahingegen wie erwartet (positive Gewichtung) um 7,19% über dem Durchschnitt. Das Einzugsgebiet lag ebenfalls wie erwartet mit 25,42% über dem Durchschnitt. Die Dauer der Berechnung ist mit 34,05 s eine der
schnelleren gewesen, was auch erwartet war, da bei dieser
Dienstleistung im Gegensatz zu den anderen am zweitwenigsten Distanzen von Google zu überprüfen sind, was mitunter
am meisten Zeit bei der Bewertung in Anspruch nimmt.
• Test 2: Normalfall Bar
Folgende Standortfaktoren sind voreingestellt: Preis (-10),
Passanten pro Stunde (8), Alter 0-17 Jahre (3), Alter 18-39
Jahre (3), Verkehrsmittelbenutzung Auto (-2), Verkehrsmittelbenutzung Fahrrad (4), Bevölkerungsdichte (9), Einzugsgebiet
(9), Distanz konkurrierende Bars (9), Distanz öffentliche Verkehrsmittel (-5), Distanz Arenen und Stadien (-1), Distanz
Hochschulen (-1), Distanz Konzerthallen (-1), Distanz Sportvereine (-1). Hier waren ebenfalls die Ergebnisse alle wie erwartet und lagen je nach Vorzeichen der Gewichtung über
oder unter dem Durchschnitt des Rests von Stuttgart Mitte.
Die Zeit war mit 46,91 s relativ hoch, was einerseits an den
vielen Standortfaktoren liegt, aber auch hier vor allem den
Distanzüberprüfungen anzulasten ist.
• Test 3: Normalfall Food-Truck
Folgende Standortfaktoren sind voreingestellt: Preis (-10),
Passanten pro Stunde (8), Autos pro Stunde (4), Temperatur Sommer (3), Temperatur Winter (-3), Niederschlag (-3),
Bevölkerungsdichte (9), Einzugsgebiet (9), Anzahl Personen
pro Haushalt (-1), Anteil an Singles (-1), Distanz Fastfood (4),
Distanz Döner (4), Distanz Arenen und Stadien (-1), Distanz
Hochschulen (-1), Distanz Konzerthallen (-1), Distanz Sportvereine (-1). Auch hier waren die Ergebnisse alle wie erwartet
und lagen je nach Vorzeichen der Gewichtung über oder unter
dem Durchschnitt. Die Zeit war mit 50,34 s am höchsten, was
einerseits an den meisten Standortfaktoren liegt und zusätzlich
bei dieser Dienstleistung auch die meisten Distanzen berechnet
werden müssen.
• Test 4: Normalfall Kinderbetreuung
Folgende Standortfaktoren sind voreingestellt: Preis (-10), Alter 0-17 Jahre (6), Alter 18-39 Jahre (6), Verkehrsmittelsbenutzung Auto (3), Verkehrsmittelsbenutzung Fahrrad (2),
Bevölkerungsdichte (9), Einzugsgebiet (9), Anteil in einer Beziehung lebender Einwohner (2), Anzahl Personen pro Haushalt (5), Verkehrsunfälle (-2), Kriminalitätsrate (-2), Distanz
andere Kinderbetreuungen (4). Auch bei dieser Dienstleistung
waren die Ergebnisse alle erwartungsgemäß. Die Zeit war mit
23,92 s die niedrigste. Die Begründung ist analog zu den anderen Fällen. Die wenigsten Standortfaktoren, die aus der Datenbank gelesen und verarbeitet werden mussten und auch die
Distanz-Abfragen waren sehr gering.
• Test 5: Prüfung mit nur einem Standortfaktor
Bei diesem Test wurden alle Gewichtungen auf 0 gesetzt, mit
einer Ausnahme, dem Preis (-10). D. h. es sollte der niedrigste
Preis in ganz Stuttgart-Mitte gefunden werden. Dies wurde
erreicht. Der Preis liegt bei 8,37 e. Wenn man manuell in der
Datenbank nachschaut, ist dies tatsächlich der niedrigste Preis.
• Test 6: Prüfung mit nur zwei Standortfaktoren
Bei diesem Test wurden alle, bis auf zwei Gewichtungen auf
0 gestellt. Die zwei Gewichtungen waren der Preis (10) und
die Bevölkerungsdichte (10). Auch hier wurde das erwartete
Ergebnis erzielt. Der Preis liegt bei 12,54 e und ist damit einer
der höchsten in der Datenbank, wobei die Bevölkerungsdichte
ebenfalls einen der höchsten Einträge in der Datenbank darstellt.
• Test 7: Ungültige Eingabe: Ort
Bei Eingabe eines falschen Ortes, erscheint die Fehlermeldung
”no data”, was unseren Erwartungen entsprach, da nur die
Testumgebung Stuttgart-Mitte in der Datenbank abgebildet
ist. Die Überprüfung geht wie erwartet schnell von statten,
da nur überprüft werden muss, ob der jeweilige Längen- und
Breitengrad in der Datenbank vorhanden ist.
• Test 8: Ungültige Eingabe: kein Standortfaktor ausgewählt
Wenn alle Gewichtungen auf 0 gestellt sind, macht eine Standortanalyse keinen Sinn. Das Ergebnis wäre dann zufällig. Das
Programm gibt hier ebenfalls eine Fehlermeldung aus und bittet um die Eingabe von mindestens einem Standortfaktor, d. h.
einer Gewichtung ungleich Null. Die Überprüfung geht hier
sehr schnell, da nur die Eingabe überprüft werden muss.
8
Eine weitere Erweiterung der Software liegt in der Integration weiterer Dienstleistungen. Aufgrund des Pilotprojektcharakters der Anwendung wurden vier Dienstleistungen als Testfälle implementiert
und betrachtet.
Ein praktisches Problem stellt die begrenzte Anzahl an täglichen
Google-API Anfragen dar10 . Diese sind wichtig für die Angabe konkurrierender und förderlicher Dienstleistungen. Eine Lösung besteht
in der Implementierung eines Cashing Systems, welches unabhängig
von Anfragen sukzessive mit der Google-Api interagiert und die
Ergebnisse in der Datenbank für spätere Anfragen zur Verfügung
stellt.
ACKNOWLEDGMENTS
Die Autoren bedanken sich bei Dipl.-Ing. Steffen Braun, Dipl.-Inf.
Felix Baumann und M. Sc. Julian Eichhoff für ihre zahlreichen
Vorschläge und Hilfestellungen während der Durchführung dieses
Projekts.
L ITERATUR
[1] H. Buhl, M. Röglinger, F. Moser, and J. Heidemann. Big data. WIRTSCHAFTSINFORMATIK, 55(2):63–68, 2013.
[2] P. D. Converse. New laws of retail gravitation. The Journal of Marketing, 14(3):379–384, 1949.
[3] H. Gondring. Immobilienwirtschaft - Handbuch für Studium und Praxis.
Vahlen, München, 2011.
[4] D. L. Huff. A probabilistic analysis of shopping center trade areas.
Land economics, 39(1):81–90, 1963.
[5] IBM, P. Zikopoulos, and C. Eaton. Understanding Big Data: Analytics for Enterprise Class Hadoop and Streaming Data. McGraw-Hill
Osborne Media, 1st edition, 2011.
[6] D. Karamshuk, A. Noulas, S. Scellato, V. Nicosia, and C. Mascolo. Geospotting: mining online location-based services for optimal retail store
placement. In Proceedings of the 19th ACM SIGKDD international
conference on Knowledge discovery and data mining, KDD ’13, pages
793–801, New York, NY, USA, 2013. ACM.
[7] Y. Qu and J. Zhang. Trade area analysis using user generated mobile
location data. In Proceedings of the 22nd international conference on
World Wide Web, WWW ’13, pages 1053–1064, Republic and Canton of
Geneva, Switzerland, 2013. International World Wide Web Conferences
Steering Committee.
[8] W. Reilly. The Law of Retail Gravitation. University Microfilms, 1953.
[9] D. Reymann. Wettbewerbsanalysen für kleine und mittlere Unternehmen (KMUs): Theoretische Grundlagen und praktische Anwendung am
Beispiel gartenbaulicher Betriebe. BoD-Books on Demand, 2009.
[10] W. verbirgt sich hinter dieser Kategorie.
Jahrestagung des
Arbeitskreises geographische Handelsforschung vom 18.06.-19.06.
2009 in Wrürzburg. Nachhaltigkeit von Handelsimmobilien, page 47,
2009.
[11] I. Willand. Statistisches Jahrbuch 2013, Oktober 2013.
[12] S. Zöller. Erlebnishandel im Automobilvertrieb: Machbarkeitsstudie
und Nutzungskonzeption für ein Autothemencenter. Springer DE, 2006.
FAZIT
Eine Desktop-Anwendung für eine rechner- und webgestützte Standortanalyse wurde entwickelt und evaluiert. Diese kann sowohl in
dem wirtschaftlichen als auch in dem öffentlichen Sektor verwendet
werden. Die Anwendung kann von einem Existenzgründer oder einer
Stadtverwaltung als Entscheidungshilfe bei der Standortbestimmung
für eine spezifische Dienstleistung zu Rate gezogen werden. Die
Lösung der Standortproblematik mittels der Erhebung und Auswertung von öffentlich verfügbaren und Nutzer generierten Daten ist eine Möglichkeit mit Zukunftsperspektiven. In Anbetracht der rasanten
Fortschritte in der Computertechnologie, der Ausbreitung von sozialen Netzwerken, der Zunahme an Daten speichernden Applikationen,
sowie zukünftigen Stadtsystemen, die ihrerseits Daten generieren,
stellt der verwendete Ansatz eine berechtigte Herangehensweise der
Problemstellung dar. Insbesondere liegt die Zukunftsfähigkeit des
Ansatzes in der Nutzung von öffentlichen Ressourcen. Diese sind bereits heute in einer großen Fülle vorhanden und ihre Anzahl wird in
den kommenden Jahrzehnten deutlich anwachsen. Die Verarbeitung
dieser Ressourcen in der Wissenschaft und Forschung im Bereich
der Standortbestimmung ist von relevanter Natur.
9
AUSBLICK
A
Für die Erzielung qualitativ hochwertiger und präziser Ergebnisse
seitens der Anwendung müssen folgende Ergänzungen und Optimierungen in Angriff genommen werden.
Insbesondere ist die Entwicklung einer mobilen Anwendung zur
Erfassung von Nutzer generierten Daten unabdingbar. Neben Sernsordaten können über die mobile Anwendung ebenfalls Bedarfe ermittelt werden, welche in die Bewertung der Analyse hineinflißen.
Den Nutzern müsste hierfür in der Anwendung die Möglickeit geboten werden, den Wunsch einer speziellen Dienstleistung an einem
bestimmten Ort mitteilen zu können. Diese Daten wurden von uns
realitätsnah simuliert. Hierfür muss ein Lösungsansatz erarbeitet
werden, wie Nutzer dazu gebracht werden können, ihre Daten permanent loggen zu lassen. Dies impliziert eine Auseinandersetzung
mit Privatsphähre- und Datenschutzproblemen. Eine Spezifikation
für eine solche mobile Anwendung wird unsererseits erstellt.
Des weiteren erhöht die Vielzahl an disjunkten Datenquellen die
Genauigkeit der Analyse. Dieses Ziel kann mittels der Erschließung
neuer Datenquellen erreicht werden.
A NHANG
1. Abbildung 3: Datenfluss und Zusammenspiel zwischen der
Anwendung und externen Quellen
2. Abbildung 4: Testumgebung Stuttgart-Mitte
3. Abbildung 5: Screenshot der Anwendung: Auswertung
4. Abbildung 6: Screenshot der Anwendung: Map/Visualisierung
10 Google Places API: 1000 Anfragen pro Tag, Google Geocoding API:
2,500 Anfragen pro Tag, 10 Anfragen pro Sekunde
9
Abbildung 3: Datenfluss und Zusammenspiel zwischen der Anwendung und externen Quellen
Abbildung 4: Testumgebung Stuttgart-Mitte
10
Abbildung 5: Screenshot der Anwendung: Auswertung
Abbildung 6: Screenshot der Anwendung: Map/Visualisierung
11