Repository 

Geo-Tagging of Jpeg-Images 

 

Funktionale Anforderungen  

 

 

Im Rahmen der Übung „Softwarearchitekturen und Webtechnologien“ möchten wir eine Webapplikation zum Lesen bzw. Schreiben von Geokoordinaten in/aus JPEG Bildern entwickeln. Den Benutzern dieser Applikation wird die Möglichkeit geboten, Bilder über ein Webinterface hochzuladen. Im Anschluss daran wird das Bild nach vorhandenen Geo-Daten untersucht. Sind Koordinaten vorhanden, wird die Position auf einer Karte angezeigt. Sind keine Koordinaten vorhanden, so können Benutzer über eine Karte die Position bestimmen, welche dem Bild zugeordnet werden soll, und so diese Informationen als Exif-Tag im Bild speichern.  

 

Des Weiteren wird die Applikation über eine Suchfunktion verfügen, welche es ermöglicht Bilder zu bestimmen Koordinaten zu suchen. Eine einfache Benutzerverwaltung wird, wenn es die zeitlichen Rahmenbedingungen zulassen, ebenfalls implementiert. Der „Use-Case“ aus Abbildung 1 soll schemenhaft die Interaktionsmöglichkeiten der Anwender und Anwenderinnen beschreiben. 

 

Die erste, vereinfachte Visualisierung des Vorhabens 

 

 

 

Motivation: 

 

Es drängt sich natürlich die Frage auf, ob wir mit dieser Projektidee das Rad nicht neu erfinden. Geotagging-Tools und Webapplikationen gibt es einige. Dennoch bietet die Umsetzung dieses Projektes die Möglichkeit vieles zu lernen. Insbesondere die Verwendung des Google Map API’s. Um die Exif Daten zu lesen/schreiben stehen auch mehrere Wege zur Verfügung. Entweder wird jhead (um eines von mehreren möglichen command line tools zu nennen) bzw. fertige PHP Klassen. Eine MySQL Datenbank (welche auch der ZID Studierenden Anbietet) und SQL zum Lesen/Schreiben in die Datenbank sind weitere verwendete Technologien.  

 

Anwendungsbereiche: 

 

Die fertige Webapplikation kann in einem breiten Spektrum an Anwendungsbereichen sinnvoll eingesetzt werden. Sei es nun im Bereich der Immobilienverwaltung, wo Immobilienmakler Wohnungen (also bestimmte Koordinaten) mit Bildern versehen und Wohnungssuchende diese auf einer virtuellen Karte mittels markieren von Koordinaten (z.B. in Form eines Rechteckes) suchen und ansehen können. Ein mögliches Einsatzszenario könnte sein, dass Fotos bestimmten Vorfällen (und je nach Datenbankdesign auch mit Datumsangaben versehen) zugeordnet werden können. Ein Unfall in der Zieglergasse, ein Bankraub in der Mariahilferstraße,.. etc. könnten schnell registriert und mit weiteren Informationen versehen werden.  

 

Eine weitere Ankopplungsmöglichkeit wäre zu den so genannten BLOGs. Der Blogger könnte seine Images mit Geo-Daten versehen und location-based-infos anbieten. Ein Beispiel dazu wäre, dass neuralgische Punkte von Strecken/Routen z.B.: ein schwerer Anstieg einer Laufstrecke oder einer Radstrecke, gefährliche Punkte einer Wanderroute (und eventuell auch mit einer Beschreibung) mit Fotos in Beziehung zu setzen. Benutzer und Benutzerinnen könnten bei der Planung von Routen (auch über Google Maps) diese Informationen mit einfließen lassen. 

 

Eine leichte Modifizierung bzw. Erweiterung des Systems würde vielen Anwendern vielfältige Verwendungsmöglichkeiten anbieten. 

 

 

Von der Idee zur Oberfläche 

 

 

In der Abbildung wurde beispielsweise ein Jpeg-Image, ein Foto der Universität hochgeladen, welches bereits Geo-Daten beinhaltet. Diese Koordinaten werden sowohl auch der Karte dargestellt als auch Zeichen/Zahlen in den Formular-Text-Feldern angezeigt. 

 

Kurze Erklärung der Abbildung 2: 

 

 

Im Einstiegsszenario könnte das hochzuladende Bild: 

 

 

besitzen. 

 

Wenn keine Geo-Daten vorhanden sind, wird ein default-mäßig definierter Kartenausschnitt (z.B. Universität Wien) angezeigt. Die editierbaren Formular-Text-Felder beinhalten keine Daten (Koordinaten). Erst ein Markieren auf der Karte bewirkt die Übernahme der Koordinaten in die Formularfelder. Auch eine Eingabe in die Formularfelder würde auf der Karte die dazugehörende Position, d.h. den Kartenschnitt laden. 

 

Die Vorgehensweise bei falschen und richtigen Geo-Daten sind identisch: Die enthaltenen Koordinaten werden zunächst angezeigt, sowohl auf der Karte als auch in den editierbaren Formularfeldern. Sie können jederzeit überschrieben werden, sowohl durch Markieren auf der Karte als auch als Eingabe in den Formularfeldern. Änderungen in den Formularfeldern bewirken eine sofortige Aktualisierung der Karte und auch umgekehrt. 

 

Obwohl es eine klassische Webanwendung ist, möchten wir eine Desktop-Like-Darstellung erreichen. 

 

Eingesetzte Technologien 

 

Wir verwenden die Servertechnologie PHP/MySQL. Um die so genannten Hintergrundprozesse ohne ein Neuladen der Webseite abrufen bzw. um eine interaktive Desktop-Like-Darstellung erreichen zu können, verwenden wir vorhandene AJAX-Libraries so wie Spry, DoJo, DynAPI, Adobe Developer Box, etc. Um das Rad nicht neu erfinden zu müssen, werden wir vorhandene PHP-EXIF-Libraries anbinden. 

 

Meilensteine 

 

 

Nichtfunktionale Anforderungen 

 

Korrektheit, Zuverlässigkeit & Sicherheit 

 

Wir unterscheiden zwischen dem System und der Anwendung.  

 

Für das System (zu entwickelnde Software) setzen wir Open-Source-Produkte wie PHP und MySQL ein, die weltweit tagtäglich mehrfach getestet werden. Für die Sicherheit haben wir ein Rechtemanagement-System eingeplant, welches nur registrierte Benutzer für die Eingabe zulässt. Die allgemeinen Richtlinien zu einer sicheren Software-Entwicklung werden eingehalten. Die Zuverlässigkeit bietet der gehostete Server, der eine Hochverfügbarkeit anbietet. 

 

Die Korrektheit der Anwendung hängt von den Eingabedaten ab. Die Datenpflege, d.h. welches Bild wird zu welchen Koordinaten zugeordnet, liegt in der Hand des Benutzers. Falls der Benutzer falsche Daten einträgt, kann dies nicht abgefangen werden (nicht mit einem in der Übung zumutbaren Aufwand). Das ist vergleichbar mit einem User, der - egal welche Anwendung - falsche Daten in eine Datenbank einträgt. Auf jeden Fall könnten Benutzer höchstens ihre eigenen Bilder mit falschen Geo-Daten versehen.  

 

Aussehen, Handhabung und Benutzbarkeit 

 

Hierbei werden die Nielsens Kriterien eingehalten: 

 

Leistung, Effizienz und Skalierbarkeit 

 

Leistung und Effizienz werden bei zunehmender Anzahl der Daten umso wichtiger. Die eingesetzte Datenbank MySQL lässt sich nahezu beliebig skalieren. Die eingesetzte Hardware würde die Daten bis zu einer gewissen Grenze bewältigen. Ab einer gewissen Grenze (durch näheres HW-Sizing feststellbar) muss die HW erweitert und skaliert werden. Ein Engpass könnte bei Massenanwendungen die Third-Part-Services-API (Google Maps API) werden, da dort eine exakte Responsezeit nicht garantiert werden kann. 

 

Portierbarkeit, Betrieb und Umgebungsbedingungen 

 

Als Serverumgebung kann sowohl Microsoft Windows (ab 2000) als auch Linux verwendet werden. Der HTTP-Server ist Apache, die Datenbank ist MySQL, die Skriptsprache ist PHP. Solange diese Umgebungsbedingungen eingehalten werden, kann die Software leicht portiert werden. Diese Infrastruktur ist dür die Inbetriebnahme erforderlich.  

 

Wartbarkeit und Änderbarkeit 

 

Das System ist relativ einfach wartbar, in gewissen Abständen muss ein Backup gemacht werden, welches automatisiert ablaufen kann. Das System kann leicht verändert werden, da die Datenhaltung und Oberfläche über eine normierte Schnittstelle erfolgt und unabhängig von einander erweitert werden kann. Ein Beispiel hierzu wäre die Implementierung einer Benutzerverwaltung. Die EXIF-Database-Tabelle könnte unabhängig davon erweitert werden. 

 

Dokumentation 

 

Weitere Dokumentation wird (sofern nicht anders geordert) direkt im Quellcode vorgenommen und im Anschluss automationsunterstützt in HTML oder PDF extrahiert. 

 

 

Slides 

 

Slides 

 

UPDATE USE CASE AKTUELL - 03.11.2009 

 

UPDATE Klassendiagramm - 01.12.2009 

Verbessertes Klassendiagramm