Im Zuge unseres Projektes haben wir eine Umfrage durchgeführt, um die Kundenbedürfnisse besser verstehen zu können. Wir erhielten knapp über 100 Antworten und konnten so repräsentative Schlüsse aus dieser Umfrage schließen. Welche Fragen wir gestellt haben und welche Antworten wir darauf bekommen haben, können Sie hier nachlesen.
Die Stadtdaten werden aus verschiedenen Datenquellen extrahiert und anschließend bereinigt, verarbeitet und dann zusammengeführt. Schlussendlich werden die Werte zahlenbasierter Parameter in Bewertungsstufen eingeteilt, um so eine aussagekräftige und leicht prozessierbare Ausprägung jedes Parameters für jede Stadt zu erhalten.
Regionsparameter entstehen aus Stadtparametern. Jede Region erhält dabei drei verschiedene Ausprägungen pro Parameter:
1. Das Maximum der in der Region liegenden Städte
2. Das Minimum der in der Region liegenden Städte
3. Der Durchschnitt aller in der Region liegenden Städte
Parameter für Länder können weitgehend unbearbeitet aus den externen Datenquellen übernommen werden. Die Daten aus den verschiedenen Datenquellen werden zusammengeführt und die Werte zahlenbasierter Parameter in Bewertungsstufen eingeteilt (vgl. Stadtparameter).
Die Wetterdaten beziehen sich jeweils auf eine Wetterstation. Gespeicherte Städte werden diesen Wetterstationen mittels Längen- und Breitengrad zugeordnet. Die Tageswerte der Rohdatenquelle werden zu durchschnittlichen Monatstemperaturen umgerechnet.
Verkürzen Sie die Zeit der Seitenentwicklung mit dem Drag-and-Drop Website Baukasten. Ziehen Sie Blocks auf Ihre Seite, bearbeiten Sie den Inhalt und veröffentlichen Sie Ihre Website – da braucht keine technischen Fähigkeiten.
Wählen Sie aus einer großen Auswahl der jüngsten voreingestellten Blocks - Full Screen Intro, Bootstrap Slider, Content Slider, responsive Bildergalerie mit der Lightbox, Parallax Scrolling, Video Hintergründe, mobiles Menü sowie noch viele weitere Dinge.
Für Länder werden folgende Basisdaten gespeichert: Name, Id, Einwohneranzahl, Gesamtfläche, ländliche Fläche, städtische Fläche und Waldfläche. Diese Daten stammen von der WorldBank. Die gesammelten Länder dienen als Grundlage für die Sammlung der Stadtdaten.
Für alle gespeicherten Länder werden die dazugehörigen Städte von der geoDBCitites-API ausgelesen und anschließend gespeichert, wenn die Einwohneranzahl der Stadt mindestens 100 000 beträgt. Pro Stadt werden folgende Basisdaten gespeichert: Name, Id, Land, Region, Längen- und Breitengrad, Einwohneranzahl, Höhe und Zeitzone.
Für jede Stadt haben wir über eine automatisierte Suche mit der Suchmaschine Bing einen Bild-Link extrahiert und das Bild gespeichert. Die Bilder werden anschließend in einen AWS S3 Bucket gepusht.
Für jedes Land haben wir den Link zu der Landesflagge gespeichert. Dieser wird von der API REST Countries extrahiert, sodass aufrufende Seiten die Länderflaggen direkt über den Link anzeigen lassen können.
Stadt, Region
OpenTripMap
Stadt, Region
OpenTripMap
Stadt, Region
OpenTripMap
Land
WorldBank
Stadt, Region
OpenTripMap
Stadt, Region
OpenTripMap
Land
Numbeo
Stadt, Region
OpenTripMap
Stadt, Region
OpenTripMap
Stadt, Region
OpenTripMap
Land
Numbeo
Stadt
NOAA-GHCN
Die Rohdaten werden aus verschiedenen Datenquellen extrahiert und sind die Grundlage für Stadt-, Regions-, und Landparameter und enthalten weitere Daten, die nicht für die Parameterberechnung verwendet werden. Dazu gehören beispielsweise Breiten- und Längengrad von Städten, Einwohnerzahlen von Städten und Ländern und die Zeitzone, in der sich eine Stadt befindet.
Alle Ländercodes werden von ISO3 auf ISO2 umgestellt, Stadttupel, die gewisse Kriterien erfüllen, werden entfernt und ein einzigartiger Regionscode aus ursprünglichem Regionscode und Ländercode erstellt.
Dieser Schritt entfällt für Länderparameter, da die Parameter direkt aus den bereinigten Rohdaten in Schritt vier übernommen werden können. Die zahlenbasierten Stadtparameter werden hingegen durch gewichtete Addition aus den bereinigten Daten berechnet, da in der Datenquelle verschiedene Level pro Parameter gespeichert sind.
Als Grundlage für die Regionsparameter dienen die in Schritt vier zusammengeführten zahlenbasierten Stadtparameter (exklusive Wetterdaten).
Stadtdaten und die verschiedenen Stadtparameter werden zusammengeführt. Ebenso werden Landdaten und Landparameter zusammengeführt. Dieser Schritt entfällt für Regionsdaten, da diese auf den bereits zusammengeführten Stadtparametern aufbauen.
Die Werte der zahlenbasierten Stadt-, Regions- und Landparameter werden in einziffrige Bewertungsstufen (integer) eingeteilt. So sparen wir Speicherkapazität, verbessern unsere API Performance und können leicht verständliche Ergebnisse zurückgeben. Die Einteilung in Stufen wird hier näher erklärt.
Die Grundlage unserer API ist ein Gerüst aus Parametern, die aus automatisiert gesammelten Daten generiert wurden. Eine Übersicht über die zur Datensammlung und -verarbeitung verwendeten Skripte bekommen Sie hier.
In diesem Diagramm wird der Fluss unserer Daten aufgezeigt - startend von externen Datenbanken bis hin zu der Generierung der finalen Daten, die wir schlussendlich in unserer eigenen Datenbank, die der Discoveroo API zu Grunde liegt, speichern. Die Ergebnisse der Python-Skripte und der R-Skripte, werden in csv-Dateien gespeichert. Die Aneinanderreihung von Skripten und csv-Dateien endet im Falle der Stadt,- Regions- und Landdaten mit der Generierung der stufenbasierten Parameter in den finalen zwei csv-Dateien cityData_level und countryData_level. Die finalen Wetterdaten werden in der csv-Datei weatherData_final gespeichert.
Die Daten aus OpenTripMap dienen als Grundlage für unsere Stadt- und Regionsparameter. Die gesammelten Daten haben wir verarbeitet und bereinigt. Die Ursprungsdaten waren in fünf Level eingeteilt (Level 0, 1, 2, 3 und 7). Wir haben diese Level gewichtet addiert und so einen einzigen Wert pro Stadt generiert. Das Level 0 haben wir im Voraus entfernt, da hier unbekannte und eher uninteressante Sehenswürdigkeiten enthalten sind. So verhindern wir, dass Discoveroo Ergebnisse verzerrt werden. Die von OpenTripMap verwendeten Level haben wir dann zu einheitlichen Stufen umgerechnet. Die Wertungen der Ausprägung einzelner Parameter werden so für jede Stadt gleichmäßig in fünf Stufen eingeteilt. Die Regionsparameter entstehen aus dem Durchschnitt, Minimum und Maximum der Stadtparamater der in der Region beinhalteten Städte.
Die Parameter Lebenshaltungskosten und Sicherheit werden unmittelbar aus der Quelle entnommen und werden anschließend kongruent zu den Stadtparametern in Stufen eingeteilt. Eine separate Berechnung der Parameter ist hier im Vergleich zu den Stadtparametern nicht notwendig, da die Ursprungswerte nicht in Level aufgeteilt sind. Die Datenbank, welche als Quelle für den Parameter Infrastruktur dient, speichert die Ländercodes im ISO3-Format. Diese werden in das ISO2-Format geändert, bevor auch hier Bewertungsstufen erstellt werden.
Es hat sich als sehr schwer herausgestellt, frei zugängliche historische Wetter- bzw. Klimadaten zu finden. Die gefundene Datenquelle stellt die Wetterdaten in einem besonderen Format bereit. Die Wetterdaten werden daher nicht wie die restlichen Daten über Python-Skripte, sondern über R extrahiert. Die Quelle enthält Wetterstationen und deren Wetterdaten pro Tag. Es war daher notwendig, die bereits vorhandenen Städte Wetterstationen zuzuordnen. Dies ist über Längen- und Breitengrade möglich.
Die finalen Wetterdaten enthalten eine StationsID und die maximale und minimale Temperatur pro Monat. Die monatlichen Maximal- bzw Minimaltemperaturwerte entstehen durch Durchschnittssbildung der Tageswerte. Die Wetterdaten werden in einer separaten MySQL-Tabelle abgelegt und können über die StationsId mit den Städten gematcht werden.
In der API haben wir die Temperaturen in Korridore eingeteilt (-30° bis -10°, -10° bis 10°, 5° bis 15°, 10° bis 25°, 20° bis 30°, 25° bis 35° und über 30°). Jedem Korridor wird eine Zahl zugewiesen. So soll eine sinnvolle und performante Abfrage der Temperatur über die API möglich sein. Die gewünschte Temperatur wird von der API ausschließlich verarbeitet, wenn ein Start- oder Enddatum für diese Reise angegeben wird. Abfragt werden dann alle Monate, die in der Reisezeit beinhaltet sind.
| Parameter | Stufen | Bedeutung |
|---|---|---|
| Architektur, Berge, Industrie, Geschichte, Kultur, Natur, Religion | 1: 0%-20% 2: 20%-40% 3: 40%-60% 4: 60%-80% 5: 80%-100% | Von 1 - sehr wenig vorhanden bis 5 - sehr stark vorhanden |
| Strand | 1: 0-4 2: 5-30 3: >30 | Von 1 - sehr wenig vorhanden bis 3 - sehr viel vorhanden |
| Infrastruktur | 1: 1-2,2 2: 2,2-3,4 3: 3,4-4,5 4: 4,5-5,8 5: 5,8-7 | Von 1 - sehr schlecht bis 5 - sehr gut |
| Lebenshaltungskosten | 1: 0%-20%
2: 20%-40% 3: 40%-60% 4: 60%-80% 5: 80%-100% | Von 1 - sehr billig bis 5 - sehr teuer |
| Sicherheit | 1: 0%-20% 2: 20%-40% 3: 40%-60% 4: 60%-80% 5: 80%-100% | Von 1 - sehr unsicher bis 5 - sehr sicher |
- Basisinformationen zu allen Discoveroo-Städten
- Detailinformationen zu Stadt aus Nutzereingabe
- Basisinformationen zu allen Discoveroo-Regionen
- Detailinformationen zu Region aus Nutzereingabe
- Alle Städte in einer Region aus Nutzereingabe
- Basisinformationen zu allen Discoveroo-Ländern
- Detailinformationen zu Land aus Nutzereingabe
- Alle Regionen in Land aus Nutzereingabe
- Alle Städte in Land aus Nutzereingabe
- Alle Discoveroo-Wetterstationen und dazugehörige Städte
- Wetter für Stadt aus Nutzereingabe
- Wetter für eine Wetterstation aus Nutzereingabe
- Empfehlung einer Stadt basierend auf Nutzereingaben
Mehr Informationen
Die Parameter werden in Form von query strings empfangen und können in beliebiger Reihenfolge übergeben werden. Parameter, welchen der Endkunde keine Wichtigkeit zuweist, müssen nicht übergeben werden. Sie können ebenfalls mit dem Wert null an die API gesendet werden. Beide Optionen sind möglich, um den Frontendentwicklern so viel Spielraum wie möglich zu geben. Die übergebenen Parameter werden in Arrays zwischengespeichert. Dabei wird zwischen den drei Parameterkategorien Stadt, Land und Wetter unterschieden. Zur Speicherung werden pro Parameterkategorie zwei Arrays gebildet, eines mit Platzhaltern (bspw. ' nculture = ? ') und eines mit den übergebenen Werten (bspw. '3'). Dadurch wird gewährleistet, dass die SQL-Abfrage dynamisch und unabhängig von der Reihenfolge der Parameter in der URL erzeugt werden kann. Außerdem kann so sichergestellt werden, dass kein Fehler entsteht, wenn nur eine Teilmenge der Parameter empfangen wird. Die Verwendung von Prepared Statements/ Escape-Sequenzen verhindert außerdem SQL Injections.
Die SQL-Abfrage wird in Abhängigkeit von den empfangenen Parametern erzeugt. Dazu wird diese mit den zwischengespeicherten Eingabewerten parametrisiert. Die SQL-Abfrage besteht aus drei geschachtelten SELECT-Anweisungen, um eine Rückgabe in angemessener Zeit zu ermöglichen. Die durch die Abfrage zurückgelieferten Städte sind nach Relevanz sortiert. Der Grad der Relevanz wird ebenfalls durch die Nutzereingabe bestimmt. Wenn die Abfrage Ergebnisse erhält, werden diese als JSON gespeichert und anschließend in zwei Funktionen gefiltert, bevor die JSON als Ergebnis zurückgesendet wird.
Für die Distanzberechnung werden die gefundenen Städte und die Parameter Distanz (gewünschte maximale Distanz des Nutzers) und Postleitzahl benötigt. Zuerst werden Längen- und Breitengrad des Kunden mittels seiner PLZ ermittelt. Anschließend werden die Distanzen der durch die SQL-Abfrage ausgewählten Städte zum Nutzerstandort ermittelt. Ist die berechnete Distanz größer als die gewünschte Distanz des Nutzers, wird diese herausgefiltert. Alle Städte, die im gewünschten Radius liegen, werden in eine neue JSON gespeichert und an die nächste Filterfunktion weitergegeben.
Nach der Distanzfilterung wird die zweite Filterfunktion angewendet, welche sicherstellt, dass das Ergebnis nicht aus sich naheliegenden Städten besteht. In der Funktion wird dazu überprüft, welche Städte auf dieselbe Wetterstation verweisen. Verweisen zwei oder mehr Städte auf eine Wetterstation, kann davon ausgegangen werden, dass diese Städte sehr nah beieinander liegen. Anschließend wird die einwohnerreichste Stadt beibehalten, während die anderen Städte nicht mehr weitergegeben werden. Das Ergebnis ist eine JSON-Datei mit der finalen Auswahl an Städten, die an die aufrufende Seite zurückgesendet werden.
Als Ergebnis wird eine JSON-Datei mit den in den Schritten zwei bis vier ausgewählten Städten und den dazugehörigen Stadt-, Land-, und Wetterparameterm gesendet. Jede Stadt ist in einem Array gespeichert. In welcher Form die Informationen dargestellt werden, bleibt der aufrufenden Seite bspw. dem Reiseanbieter überlassen.
Die Reihenfolge der Stadt-Arrays in der JSON-Datei, die an die aufrufende Seite gesendet wird, wird durch die Nutzereingaben bestimmt. Für die meisten Paremater gilt folgendes: Parameter, für welche die API einen Wert größer oder gleich drei empfängt, werden in die "order by"-Klausel der SQL-Abfrage einbezogen. Dabei wird zuerst nach Parametern sortiert, deren Wert durch die aufrufende Seite mit fünf oder vier besetzt wird und anschließend nach Parametern, deren Wert von der API als drei empfangen wird.
Für den Lebenshaltungsparameter wird allerdings umgekehrt vorgegangen, da kleine Werte niedrige Lebenshaltungskosten bedeuten. So wird hier zuerst nach Parametern sortiert, für welche der Wert eins oder zwei übergeben wird und anschließend für Parameter, deren Wichtigkeit mit drei bestimmt wird.
Mit der "random shuffle"-Funktion kann sich der Nutzer inspirieren lassen, ohne sich im Voraus einzuschränken. Wenn der Nutzer keine Eingaben macht und/oder direkt Ergebnisse anfordert, werden zufällig Ergebnisse zurückgeliefert. Gibt der Nutzer keine Parameter, aber eine Postleitzahl und die gewünschte Maximaldistanz ein, werden zufällige Ergebnisse gesendet, die im gewünschten Umkreis liegen. Mit jedem erneuten Aufruf der API werden andere, zufällig gewählte Städte zurückgegeben.
Die SQL Query, die an die Datenbank geschickt wird, enthält mehrere Einfügestellen für Nutzereingaben. Um die Datenbank vor SQL Injections zu schützen, werden Prepared Statements mit Platzhaltern für diese Nutzereingaben verwendet, die zur Laufzeit bei Aufruf der Recommendation Route mit den vom Client erhaltenen Werten parametrisiert werden. So werden Metazeichen in den Nutzereingaben zu regulären Ausdrücken umgewandelt, um beispielweise zu verhindern, dass ein mit dem Select-Statement geschicktes Delete- oder Update-Statement an die Datenbank gesendet und verarbeitet wird.
Ein Ansatzpunkt zur Optimierung der Performance sind die Funktionen, welche die Rückgaben der SQL-Abfrage filtern. Hier müssen oft Arrays durchlaufen werden, um Städte zu vergleichen. Eine Verringerung schon geprüfter Schleifenelemente nach jedem Durchlauf senkt die Zeit von ca. 80ms auf ca. 8ms (bei lokalem Aufruf). Der reine Aufruf vom Eingang der Anfrage bis zur Rückgabe der Daten dauert somit ca. 30-50ms. Hierbei ist das Empfangen, Weiterleiten und Zurücksenden der Daten nicht enthalten.
In dem API-Aufruf übergene Stadt-, Land- und Wetterparameter werden getrennt verarbeitet. Der Aufbau der SQL-Abfrage hängt davon ab, welche dieser drei Parameterarten empfangen werden. Dadurch ist jegliche Kombination von Parametereingaben möglich. Die SQL-Abfrage wird dynamisch zusammengebaut, das bedeutet, dass nicht alle Parameter empfangen werden müssen, um eine funktionierende SQL-Abfrage zu erzeugen. Parameter, die mit null übergeben werden, werden nicht in die Abfrage einbezogen. Wird nach einem &-Zeichen ein String übergeben, der keinen in der DB enthaltenen Parameter abbildet, wird dieser ignoriert. Werden keine passenden Ergebnisse gefunden, wird eine Nachricht "Did not find matching recommendation" an den Client geschickt, um so eine Korrektur zu ermöglichen.
