Warning: include_once(/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php): failed to open stream: No such file or directory in /var/www/html/fields/dbp11/local/config.php on line 4

Warning: include_once(): Failed opening '/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php' for inclusion (include_path='.:/opt/php/lib/php') in /var/www/html/fields/dbp11/local/config.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/fields/dbp11/local/config.php:4) in /var/www/html/pmwiki-2.2.86/pmwiki.php on line 1250
Datenbankpraktikum SS 2011 - Main - Backend-trips
?

Funktionalität Trips bzw. Requests

Eine der Hauptfunktionalitäten unserer Mitfahrzentrale besteht darin, eine Fahrt oder ein Fahrtgesuch zu erstellen. Dies wurde durch eine Trip- bzw Request-Entität verwirklicht, die unter Anderem die Datenfelder PLZ, Ort und Straße für Start- und Zieladresse beinhalten. Bevor ein Trip erstellt wird muss das Model also prüfen, ob alle benötigten Daten zugrundeliegen, die für spätere Funktionalitäten verlangt werden.

Das folgende Schaubild zeigt den Ablauf, der eingehalten werden muss, damit ein Request, bzw. ein Trip erstellt werden kann:

Im folgenden wird der Ablauf zur Verdeutlichung beispielsweise erläutert:

Die vom Nutzer getätigte Eingabe wird geocodiert.

Hierbei kann es vorkommen, dass ein Nutzer nur eine Postleitzahl oder eine Stadt ohne dazugehörigen Straßennamen und Hausnummer eingibt. Durch das Kontaktieren der Controller von Google Maps mithilfe des Programms Geocoder wird die Eingabe automatisch auf eine eindeutige Adresse vervollständigt. D.h. Geocoder sucht für eine nicht eindeutige Eingabe, wie z.B. Köln (ohne Straßenname und PLZ) die zentrumsnahen Koordinaten, welche dann in die dazu gehörigen Datenfelder geschrieben werden.

Optimierung der Eingabe.

Da es möglich sein sollte, dem Anwender eine vielfältige Eingabe zu ermöglichen, lag es an uns, die restlichen Spalten der Entität zu ergänzen, vervollständigen oder die Eingabe zu korrigieren. Dazu mussten wir ein sogenanntes reverse geocoding vornehmen, dass uns zu den im Vorfeld ermittelten Koordinaten alle Informationen liefert, die genau dieser Punkt enthält.

Im folgenden Beispiel wird die Variable start_a mit allen Informationen gefüllt, die uns Gmaps4rails für die Startkoordinaten starts_at_N (Längengrad) und starts_at_E (Breitengrad) liefert.

Für die Koordinaten von beispielsweise Hörstel (52.30012439999 Nord und 7.58706790000 Ost) ergäbe sich dann folgende Ausgabe.

Danach sind wir mit entsprechender Hash- und Array-Notation an die gewünschten Informationen gekommen und haben diese in die dafür vorgesehenen Datenfelder (zipcode, city, street) gespeichert. Dies gestaltete sich jedoch als äußerst schwierig, da in der Google Maps API nicht angegeben war, wie die jeweiligen Hashes/Arrays formatiert sind. Letztendlich bot sich uns ein stark verschachteltes "Konstrukt" aus Hashes und Arrays: self.zipcode = start_a[0][:full_data]["address_components"][6]["long_name"]

Des öfteren standen weiterhin gesuchte Informationen im Array an verschiedenen Stellen, sprich es kann vorkommen, dass bei größeren Städten die Postleitzahl beim Hash address_components nicht im Array an Stelle 6, sondern z.B. an Stelle 7 zu finden ist. Gelöst haben wir dieses Problem, durch eine einfache, von Ruby gegebene Methode. So mussten wir jedes Array im Hash mit der Methode include? darauf untersuchen, an welcher Stelle jeweilige Information steht.

Berechnung der Route

Nachdem wir alle Informationen erhalten haben, wird die Routendistanz und -dauer berechnet. Dazu wird vom Controller die Methode set_route ausgerufen, in der wiederum anfänglich Google Maps kontaktiert wurde, um die Route zwischen Startpunkt und Endpunkt zu berechnen. Im weiteren Verlauf stellte sich jedoch heraus, dass Google Maps mit nur 2500 Routenberechnungsanfragen am Tag zu wenig Kapazität bietet, so dass wir in der set_route Methode nun Bing-Maps verwenden.

Speicherung in die Datenbank

Erst jetzt, wenn alle Datenfelder ermittelt wurden, kann der Trip, bzw. Request gespeichert werden. Falls Datenfelder nicht gesetzt sind greifen mehrere Validations und der Trip kann nicht erstellt werden.

Folgende Probleme können dazu führen, dass ein Trip nicht gespeichert werden kann:

  • Die Eingabe vom Benutzer kann nicht geocodiert werden! (Beispiel: Eingabe von: "hallo" nach: "98765")
    • Validation: die Koordinatenfelder dürfen nicht Null sein
  • Die Route kann nicht berechnet werden! (Beispiel: Von Nordamerika kann keine Route nach Europa berechnet werden.)
    • Bing (Gem für Routenberechnung) wirft eine Exception, die an Controller weitergeleitet wird, Trip wird verworfen.
  • Die Eingabe vom Benutzer ist nicht eindeutig! (Beispiel: Eingabe von: "Ham" nach: "Ber")
    • In diesem Fall kann es vorkommen, dass die Eingabe geocodiert, als auch die Route berechnet wird, es liegt also im Nachhinein am Anwender zu entscheiden, ob er diese Route fahren will oder nicht.
  • Der Startzeitpunkt des Trips liegt in der Vergangenheit.
  • Der Benutzer möchte einen Trip erstellen, in dem er allerdings keine freien Sitzplätze zur Verfügung hat.


Page last modified on August 19, 2011, at 01:38 PM