IT-Anwendungen

Carbot ist ein mobiler, autonomer Robot und bietet eine Plattform zur Entwicklung von Verfahren und Algorithmen zur autonomen Robotik. Langfristig soll eine 3D-Objekterkennung mit Hilfe der Kamera-Bilder möglich sein. Ein 3D-Umgebungsmodell soll einerseits eine Navigation und Umfahrungsstrategien erlauben, andererseits soll die interne Positionsbestimmung (aktuell basierend nur auf den Umdrehungssensoren) verbessert werden. Im Rahmen dieses IT-Projektes soll dazu die komplette Verarbeitungskette vom der HD-Kamera bis hin zur Bildauswertung eingerichtet werden. Prototypisch soll eine Bildauswertung mit OpenCV programmiert werden.

Weitere Materialien

Die vollständige Aufgabenstellung als PDF

Sommersemester 2012

Aufbau eines vektorbasierten Kartendienstes

Aufgabenstellung

Das dorenda-Projekt erlaubt die Generierung von so genannten Kartenkacheln aus Geo-Datenbanken. Kartenkacheln sind vorberechnete Bitmapgraphiken für Kartendienste. Diese fügen sich nahtlos zu einem flächendeckenden Teppich zusammen, der für verschiedene Zoomstufen und Orientierungen berechnet wurde.
Es soll untersucht werden, wie man die dorenda-Kartengenerierung auf der Basis von Vektor- Grafiken aufbauen könnte.

Weitere Materialien

Die vollständige Aufgabenstellung als PDF

Wintersemester 2011/2012

Navigation auf Android-Mobiltelefonen

Aufgabenstellung

Ziel des Projektes ist es, eine Wegeplanung (Navigation) auf einem Android-Smart-Phone zu implementieren. Die Navigation soll 'offline' erfolgen, d.h. das Kartenmaterial liegt komplett in dem Flash-Speicher des Smart-Phones. Auch die Ausführung des kürzeste-Wege-Algorithmus findet auf dem Smart-Phone statt, ohne dass ein externer Dienst benutzt wird.
Als Datenmaterial stehen umfangreiche Straßendaten zur Verfügung, die aus dem offenen Geo-Datenbestand von OpenStreetMap (OSM) importiert wurden. Das Datenmaterial wurde schon soweit vorverarbeitet, dass sowohl Vektorobjekte (z.B. Straßen) als auch die Wegetopologie in Form von Kreuzungen und Streckenabschnitt vorliegen. Zurzeit umfasst der Datenbestand für Deutschland:

13,6 mio. Geo-Objekte,
davon für die Navigation relevante 5,1 mio. Straßenobjekte,
13,8 mio. Kreuzungen und
17,5 mio. Streckenabschnitte (von Kreuzung zu Kreuzung)

Mit der donavio-Umgebung wurde schon gezeigt, dass ein Navigationsalgorithmus auf der Basis dieser Daten unter einem Desktop-Betriebssystem in einigen Sekunden einen Weg quer durch Deutschland planen kann. Allerdings erfordert die Umgebung zur Laufzeit ca. 300 MB im Hauptspeicher.
Ziel des Projektes ist es nun, die Wegplanung auf ein Android-Smart-Phone mit einem Arbeitsspeicher von 24 MB für eine Android-App zu übertragen. Darüber hinaus können mehrere Gigabyte auf relativ langsamen Flash-Speichern ausgelagert werden. Als Herausforderung soll im Projekt ein geeignetes Verfahren entwickelt werden, das mit dem wesentlich kleineren Laufzeitspeicher kombiniert mit einem großen Flash-Speicher funktioniert.
Hierzu einige Denkanstöße:

Man könnte versuchen, das gesamte Wegenetz über eine geeignete Kompression in 24 MB unterzubringen.
Man könnte das Wegenetz in eine effiziente Dateistruktur auf dem Flash-Speicher ablegen und arbeitet vollständig auf einer Datei (z.B. mit java.io.RandomAccessFile), wandert dabei mit einem File-Pointer an die relevanten Stellen der Datei.
Man könnte Teile des Wegenetzes in den Arbeitsspeicher laden und versucht so lange wie möglich auf diesem Anteil zu arbeiten, bevor man den nächsten Anteil aus dem Flash-Speicher einlagert.
Man könnte eine Art virtuellen Speicher realisieren, der immer die verwendeten Daten automatisch in den Speicher lädt, dabei Caching benutzt.

Diese Liste muss nicht vollständig sein. Ziel des Projektes ist es, unkonventionelle Ansätze vorzuschlagen und zu testen. Das Projekt ist bewusst so gestaltet, dass es nicht 'ad-hoc' implementiert werden kann. Statt dessen sollen verschiedene Ansätze durch Experimente (z.B. Zeitmessungen) verglichen und erst nach und nach ein geeignetes Verfahren entwickelt werden.

Arbeitspunkte:

Recherche über mögliche Verfahren
Entwickeln möglicher eigener Verfahren
Experimente und Zeitmessungen als Grundlage für eine Entscheidung
Entwickeln eines geeignete Verfahrens, dazu
- Realisierung eines Datenexports von der Server-Geo-Datenbank in das entwickelte Smart-Phone-Format
- Realisierung des Verfahrens für die Android-Plattform als Software-Bibliothek
- Realisierung einer Android-Test-Anwendung, die diese Bibliothek nutzt
Dokumentation dergestalt, dass später weitere Gruppen das Verfahren weiterentwickeln oder einsetzen können

Realisierung:

Android-Anteile werden mit dem Android-SDK entwickelt, d.h. Java;
der Export der Geodaten auf das Smart-Phone wird mit Java SE entwickelt.

Weitere Materialien

Diese Aufgabenstellung als PDF

Sommersemester 2011

Augmented Reality mit Geodaten

Es steht eine Geo-Datenbank zur Verfügung, für die es eine Implementierung für Android gibt. Auf dem Mobiltelefon installierte Geo-Daten können über ein Bild projiziert werden, das über die Kamera aufgenommen wird.

Wintersemester 2010/2011

Bestimmung von Transportmitteln auf Android-Mobiltelefonen

Aufgabenstellung

Aktuelle Smartphones verfügen in der Regel über Einrichtungen zur Positionsbestimmung über die Satellitennavigation. Dadurch ist es möglich, dass Anwendungen den Benutzer in ortsbezogenen Aufgaben unterstützen beispielsweise bei der Orientierung in unbekannten Städten.

In bestimmten Situationen versagt die Satellitennavigation aber, insbesondere wenn Transportmittel des Nahverkehrs (z.B. U-Bahnen) benutzt werden. Hier wäre es für eine Anwendung zumindest interessant zu wissen, welche Art von Transportmittel gerade benutzt wird, um dem Benutzer eine entsprechende Unterstützung (z.B. in Form von Fahrplänen oder Aussteigepunkten) anzubieten.
Fast jedes Smartphone verfügt heutzutage über einen Sensor, der die Ausrichtung des Gerätes erfasst. Dieser Sensor wird zwar vorwiegend dazu benutzt, die Informationen auf dem Bildschirm auszurichten oder Spiele zu steuern, es können aber auch Beschleunigungsprofile erfasst werden.
Mittlerweile gibt es erste Arbeiten darüber, inwieweit Beschleunigungsprofile benutzt werden können, verschiedene Transportmittel zu erkennen [1]. Damit wurde gezeigt, dass eine grundsätzliche Unterscheidung zwischen Fußgänger, Auto und Zug mit einer hohen Trefferquote möglich ist. Ziel dieses Projekts ist, ein entsprechendes Verfahren selbst zu realisieren und für die Android-Plattform zur Verfügung zu stellen. Idealerweise wird die Anzahl der unterscheidbaren Transportmittel dabei signifikant vergrößert.

Arbeitspunkte:

Recherche über entsprechende Verfahren zur Auswertung von Beschleunigungsprofilen.
Erfassen von Testprofilen.
Konzeption eines Verfahrens, das für eine große Anzahl unterscheidbarer Transportmittel und für eine hohe Trefferquote optimiert wurde.
Realisierung des Verfahrens für die Android-Plattform.

Diese Aufgabenstellung als PDF

Sommersemester 2010

Ein Indoor-Kartendienst für Android-Handys

Im Projekt roofi soll eine Navigation in Gebäuden ermöglicht werden. Hierzu wird die vom Fraunhofer IIS entwickelte Lokalisierungstechnologie Mobile Locator eingesetzt.

Wintersemester 2009/2010

Straßennavigation

Aufgabenstellung

Geodaten waren in der Vergangenheit sehr teuer und ermöglichten nur einigen hochspezialisierten Unternehmen die Entwicklung komplexer ortsbezogener Anwendungen. Mittlerweile steht eine Fülle von frei verfügbaren Geodaten insb. durch das Projekt OpenStreetMap zur Verfügung. Der aktuelle Geodatenbestand von Deutschland umfasst ca. 5 Mio. Einträge – davon sind alleine ca. 3 Mio. Objekte Straßen und Wege.

Auf der Basis dieses Datenbestandes soll ein Straßennavigationsdienst entwickelt werden: Durch Eingabe von Start- und Zielposition soll eine nach bestimmten Kriterien optimale Route gefunden werden. Es sollen auch weite Routen zwischen Städten (von Haustür zu Haustür) berechnet werden. Darüber hinaus sollen Geschwindigkeitsprofile zu verschiedenen Straßenarten berücksichtigt werden. Es sollen keine Navigationsansagen wie bei mobilen Navigationssystemen berechnet werden. Die Ausgabe ist lediglich eine Liste von Abbiegepunkten.
Die Arbeitspunkte des Projektes sind:

Recherche und Gegenüberstellung von einschlägigen Navigationsalgorithmen.
Konzeption eines geeigneten Verfahrens, das auch auf großen Datenbeständen funktioniert.
Definition einer geeigneten Repräsentation der Geodaten für die Wegeplanung. Import des Datenbestandes.
Implementierung und Dokumentation des Verfahrens.

Voraussetzungen

Das Projekt richtet sich an Studenten, die sich mit Fragestellungen im Geodaten-Bereich auseinandersetzen möchten. Spezielle Vorkenntnisse im Bereich Geo-Informatik sind jedoch nicht erforderlich. Geodaten in großem Umfang werden zur Verfügung gestellt. Hierzu steht auch schon eine Umgebung zur Verfügung, um den Datenbestand sequenziell zu durchsuchen und Geoobjekte in ein eigenes Format zu konvertieren. Die Implementierung erfolgt in Java. Um eine langfristige Wartbarkeit der Plattform zu gewährleisten, soll in diesem Projekt möglichst auf Third-Party-Software verzichtet werden und im Wesentlichen nur die Java-Basis-Klassen verwendet werden. Als Ausnahme:

Geometrie-Operationen können mit der Java Topology Suite (JTS) durchgeführt werden.
Für die effiziente Datenhaltung kann eine Datenbank (bevorzugt PostGres) verwendet werden. Für Geometrie-Anfragen steht die räumliche Erweiterung GAO zur Verfügung.

Weitere Materialien

Diese Aufgabenstellung als PDF

Sommersemester 2009 (1)

Effiziente Verwaltung von Geodaten

Aufgabenstellung

Der Geodaten-Editor depro ist entwickelt worden, um Geodaten aus verschiedenen Quellen (z.B. ATKIS, OpenStreetMap) effizient zu einem Datenbestand zusammenfassen zu können und für aktuelle ortsbezogene Dienste aufzubereiten. Der aktuelle Datenfluss beim Laden und Verarbeiten ist in der Abbildung a) dargestellt: Alle Geoobjekte sind in XML-Dateien gespeichert. Beim öffnen der Anwendung wird der gesamte Datenbestand in den Java-Heap geladen, um dort bearbeitet werden zu können. Der signifikante Nachteil dieser Vorgehensweise ist, dass durch den begrenzten Java-Heap die Größe des Datenbestandes stark limitiert wird. So gelangt man mit den Geodaten von Bayern mit derzeit ca. 260 000 Objekten unter 32-Bit-Windows (mit einer Beschränkung des Java-Heaps auf ca. 1.6 GB) an die Grenzen der Datenhaltung.
Eine alternative Vorgehensweise ist unter b) dargestellt: Über eine Import-Funktion wird der gesamte Datenbestand in eine Datenbank kopiert. Zur Laufzeit wird nur der jeweils relevante Datenbestand in den Java-Heap kopiert und zur Bearbeitung angeboten. Hiermit können auch größere Datenbestände (Ziel: alle Geo-Objekte weltweit) verwaltet werden. Ziel dieses IT-Projektes ist, den Geodaten-Editor auf die Variante b) umzustellen. Folgende Punkte sind im Projekt zu bearbeiten:

Realisierung der Import- und Export-Funktionen;
Umstellen des Editors auf die Datenbank; hierbei Realisierung eines effizienten Systems zur Einblendung relevanter Geo-Objekte in den Java-Heap;
Umstellung und Erweiterung der Plug-In-Schnittstelle des Geodaten-Editors.

Eine räumliche Datenbankerweiterung steht zur Verfügung. Darüber hinaus wird eine intensive Unterstützung in die Einarbeitung der Quellen des Geodaten-Editors durch den Entwickler gewährleistet.

Voraussetzungen

Das Projekt richtet sich an Studenten, die sich mit Fragestellungen im Geodaten-Bereich auseinandersetzen möchten. Spezielle Vorkenntnisse im Bereich Geo-Informatik sind jedoch nicht erforderlich.

Weitere Materialien

Diese Aufgabenstellung als PDF

Sommersemester 2009 (2)

Entwicklung eines Web Map Service

Aufgabenstellung

Web Map Services liefern auf Anfrage Kartenausschnitte der Umgebung und bilden die Grundlage für ortsbezogene Dienste. Ein populäres Beispiel für solch einen Map Service ist Google Maps.

Ein Web Map Service kann in zwei separate Komponenten zerlegt werden (siehe Abbildung): in einer Offline-Phase werden Bitmap-Kacheln aus Geoobjekten, die in der Regel in Vektor-Form vorliegen, vorberechnet. Der Datenbestand vorberechneter Kacheln deckt die gesamte Abdeckungsfäche in allen erforderlichen Zoom-Stufen ab. Online kann dann ein Client auf den (u.U. sehr großen) Datenbestand vorberechneter Kacheln zugreifen und gewünschte Anteile zur Anzeige bringen.
Folgende Punkte sind im Projekt zu bearbeiten:

Realisierung eines Verfahrens zur Vorberechnung der Bitmap-Kacheln
Einsatz eines speichersparenden Ablageformates für die Bitmap-Kacheln, Entwicklung eines effizienten Zugriffsverfahrens
Realisierung einer OGC-konformen Web-Map-Service-Schnittstelle
Entwicklung einer Demo-Client-Anwendung, die diese Schnittstelle nutzt

Folgende Fragestellungen sollen bei der Vorberechnung der Bitmap-Kacheln berücksichtigt werden:

Das Darstellungsverfahren soll in bestimmten Grenzen konfiguriert werden können. So soll einstellbar sein, welche Objekttypen überhaupt dargestellt werden. Die Reihenfolge der dargestellten Objekte soll wählbar sein, darüber hinaus die geometrische Darstellung (Farbe, Strichstärke, Strichtyp, Zeichensatz). Zusätzlich kann für bestimmte Objekttypen die Beschriftung generell abgeschaltet werden. Die Konfiguration soll über eine Textdatei erfolgen.
Es soll automatisch entschieden werden, welche Objekte in welcher Zoomstufe dargestellt werden. Unter Umständen müssen Objekte darüber hinaus für die Darstellung auf bestimmten Zoomstufen automatisch „verbreitert“ werden (z.B. Autobahnen, die auch auf der Deutschlandkarte sichtbar sein sollen).
Es soll eine sinnvolle Projektion der vorliegenden Koordinaten (die sich auf die gekrümmte Erdoberfläche beziehen) auf ein rechteckiges Raster-System gefunden werden.
Es soll ein Verfahren realisiert werden, das Schriftzüge (z.B. in Straßenzügen) automatisches vernünftig darstellt. Darüber hinaus soll automatisch entschieden werden, ob in einer bestimmten Zoomstufe eine Beschriftung überhaupt sinnvoll ist.
Schriftzüge von großen Objekten (z.B. Autobahnen) wiederholen sich. Hier soll ein Verfahren entwickelt werden, das diese Wiederholung steuert.

Voraussetzungen

Das Projekt richtet sich an Studenten, die sich mit Fragestellungen im Geodaten-Bereich auseinandersetzen möchten. Spezielle Vorkenntnisse im Bereich Geo-Informatik sind jedoch nicht erforderlich. Die Implementierung erfolgt in Java. Um eine langfristige Wartbarkeit der Plattform zu gewährleisten, soll in diesem Projekt möglichst auf Third-Party-Software verzichtet werden und im Wesentlichen nur die Java-Basis-Klassen verwendet werden. Als Ausnahme:

Geometrie-Operationen können mit der Java Topology Suite (JTS) durchgeführt werden.
Für die effiziente Datenhaltung kann eine Datenbank (bevorzugt PostGres) verwendet werden. Für Geometrie-Anfragen steht die räumliche Erweiterung GAO zur Verfügung.

Geodaten in großem Umfang werden zur Verfügung gestellt.

Weitere Materialien

Diese Aufgabenstellung als PDF

Wintersemester 2008/2009

Selbstlokalisierung mit Schwarm-Intelligenz

Aufgabenstellung

Mit dem Begriff SLAM (Simultaneous Localization and Mapping) beschreibt man das Problem, eine unbekannte Umgebung zu kartographieren, wobei die eigene Position auch unbekannt oder zumindest nur ungenau bekannt ist. Die Lösung des SLAM-Problems ist beispielsweise für die mobile Robotik interessant, so zum Beispiel, um einen optimalen Reinigungspfad einer mobilen Reinigungsmaschine zu berechnen, ohne dass eine Karte des Raumes vorliegt.

Werden mehrere individuelle Einheiten gekoppelt, können diese ihr bruchstückhaftes Wissen über die Umwelt ergänzen. Verrichten relativ einfache Einheiten durch gegenseitige Absprache eine relative komplexe Aufgabe, spricht man auch von Schwarm-Intelligenz. In diesem Projekt soll das Konzept der Schwarm-Intelligenz auf das SLAM-Problem angewendet werden. Der Aufbau erfolgt über fünf mobile Klein-Roboter, die auf der Basis von Lego-Mindstorms realisiert werden (siehe Abbildung). Diese sind mit verschiedenen Sensortypen (z.B. Ultraschall, Taktil, Gyroskop oder Kompass) ausgestattet, erlauben die Ansteuerung von drei Schrittmotoren und verfügen über zwei Kommunikationseinrichtungen (Bluetooth und Infrarot).
Das Projekt umfasst u.a. folgende Teilaspekte:

Konzeption und Durchführung des mechanischen Aufbaus der mobilen Einheiten;
Konzeption eines Weltmodells, das die Umgebung, sowie die Positionen der Einheiten (teilweise unbekannt oder ungenau) beinhaltet;
Ansprechen der Motorik, dabei Abbilden der Fahrbewegungen auf das interne Weltmodell;
Ansprechen der Sensoren; Fusionierung verschiedener Sensordaten, dabei Integration der Daten in eine Umgebungskarte;
Aufbau der Ad-hoc-Kommunikation zwischen den Einheiten;
Aufbau einer intelligenten Steuerung, die insbesondere die kollektive Problemlösung erlaubt.

Voraussetzungen

Das Projekt erfordert interdisziplinäres Denken, da neben Problemen der Informatik der mechanische Aufbau, die Navigation und Sensorauswertungen zu behandeln sind. Die Programmierung erfolgt mit einer speziellen Java-Umgebung Lejos. Der mechanische Aufbau soll mit der Lego-CAD-Umgebung LDD oder MLCad dokumentiert werden.

Weitere Materialien

Diese Aufgabenstellung als PDF

Beispielaufbau mit Mindstorms

Sommersemester 2008

Konzeption und Entwicklung einer Rendering-Engine für Kartendaten

Aufgabenstellung

In diesem IT-Projekt soll eine Rendering-Engine für geografische Kartendaten entwickelt werden. Diese Rendering-Engine soll anhand von vektorbasierten Geodaten, die als Sammlung von XML-Dateien vorliegen, eine Karte für einen vorgegeben Kartenausschnitt auf einem Endgerät darstellen. Die Darstellung soll in bestimmten Grenzen zur Laufzeit konfigurierbar sein und für das jeweilige Endgerät optimiert sein (insb. in Bezug auf die Bildschirm-Auflösung). Die Rendering-Engine soll später möglichst flexibel auf verschiedenen Endgeräten einsetzbar sein. Im Rahmen dieses IT-Projektes soll zunächst nur die Plattform Java Standard Edition unterstützt werden, aber in der Zukunft soll auf einfache Weise eine Portierung auf JavaME-Geräte oder auf eine Browser-basierte Darstellung möglich sein. Auch wenn diese weiteren Plattformen nicht Bestandteil des Projektes sind, soll bei der Konzeption der Lösung die spätere Erweiterung auf diese Plattformen durch flexible Datenstrukturen schon vorbereitet werden.
Die zu erstellende Rendering-Engine wird in Form einer Klassenbibliothek vorliegen, die sowohl die notwendigen Laufzeit-Komponenten als auch die notwendigen Schnittstellen zur Konfiguration und Benutzung enthält. Zur Demonstration der Funktionen der Rendering-Engine ist im Rahmen des Projektes darüber hinaus eine Demonstrations- und Testanwendung zu entwickeln, die auf der Rendering-Engine aufbaut.
Arbeitspunkte des Projektes:

Definition einer geeigneten Dienstschnittstelle (API).
Geeignete Verteilung der Funktionen auf Endgerät und Server. Hierbei soll auf Effizienz der Kommunikationsschnittstelle geachtet werden.
Realisierung der Funktionen; hierbei Berücksichtigung zukünftiger Entwicklungen insb. JavaME und Web-based.
Realisierung einer Demonstrationsanwendung.

Voraussetzungen

Weitere Materialien

Diese Aufgabenstellung (ergänzt um einige Details)
Die Hybris Homepage

Typische vektorbasierte Geodaten

Wintersemester 2007/2008

Realisierung einer Geodatenimport-Schnittstelle

Einleitung

Der Nimbus-Geodaten-Editor (siehe Abbildung) wurde zur Bearbeitung von Geodaten für zukünftige ortsbezogene Dienste entwickelt. Der Editor verfügt über verschiedene Schnittstellen um umfangreiches Geo-Datenmaterial zu importieren. Für den Editor soll eine weitere Schnittstelle für das Projekt OpenStreetMap entwickelt werden. In diesem Projekt sind schon umfangreiche Datenmengen verfügbar (12 GB, Stand Mitte Sept. 2007). Daraus resultieren verschiedene Herausforderung für die Aufgabestellung:

Entwicklung eines schnellen XML-Imports aus der Planet-Datei von OpenStreetMap.
Entwicklung von Filter-Werkzeugen, um die Datenmenge geeignet einzuschränken.
Entwicklung eines Verfahrens, um nur die änderungen in den Datenständen abzugleichen.

Darüber hinaus erwartet das Projekt OpenStreetMap so-genannte GPS-Logs (Text-Dateien, in die fortlaufende Ausgaben eines GPS-Empfängers geschrieben wurden) als Eingabe. Da diese Dateien in der Regel noch Fehler enthalten (z.B. Fehlmessungen), sollen die GPS-Logs im Geodaten-Editor überarbeitet werden können. Die notwendigen Werkzeuge sollen teilweise als Konsolen-Programme realisiert werden, teilweise in den Geodaten-Editor integriert werden. Für den zweiten Fall wird eine komfortable Plug-In-Schnittstelle zur Verfügung gestellt.

Voraussetzungen

Weiterführende Literatur

(Urheberrechtshinweis)

Sommersemester 2007

Eine Foto-Mapper-Anwendung mit Google-Maps

Aufgabenstellung

Mit diesem Projekt sollen geografische Positionen zu aufgenommenen Digitalfotos ermittelt werden, die ähnlich dem Aufnahmezeitpunkt die näheren Umstände einer Foto-Aufnahme beschreiben.
Heutige Speicherkarten in Digitalkameras erlauben die Speicherung vieler hundert Fotos. Zu dem Zeitpunkt, wenn die Digitalfotos weiterverarbeitet oder vervielfältigt werden, hat der Benutzer bei dieser Datenmenge oft den Überblick darüber verloren, wo ein Foto aufgenommen wurde. Die in dem Projekt zu entwickelnde Anwendung soll dieses Problem lösen. Da heutige Digitalkameras (leider) noch über keine Einrichtung zur Positionsbestimmung verfügen, liegt dem Projekt folgende Idee zu Grunde:

Der Benutzer trägt am Tag der Foto-Aufnahmen ein Gerät mit sich, das dauernd über Satellitennavigation (GPS) ermittelte Positionen in eine Datei speichert. Dieser so genannte GPS-Logger ist ein passives Gerät, das lediglich eingeschaltet wird und während der Laufzeit nicht vom Benutzer bedient wird.
Zu dem Zeitpunkt, wenn die Speicherkarte mit den Digitalfotos entladen wird, wird auch die Datei mit den Positionen aus dem GPS-Logger ausgewertet. Anhand der Zeitstempel kann jedem Foto die jeweilige Position zum Aufnahmezeitpunkt zugeordnet werden.
Da die geografische Position in der Regel nicht aussagekräftig ist, werden zusätzliche symbolische Daten (z.B. "Marktplatz Nürnberg") beim Einlesen automatisch hinzugefügt.
Die Fotos können danach auf einer Karte angezeigt werden. Die Kartenanwendung wird mit der Plattform Google Maps entwickelt. Innerhalb der Kartenanwendung können Kommentare sowie die Blickwinkel zu den Aufnahmen manuell eingegeben werden (letztere werden durch die Positionsbestimmung noch nicht erfasst). Zusätzlich besteht die Möglichkeit, zu Abbildungen, für die keine Position erfasst wurde, von Hand einzutragen.
Alle gewonnen Informationen zu den Abbildungen werden schließlich in den Meta-Daten der Bilddateien abgespeichert und so konserviert.

Die Architektur des Gesamtsystems ist in der Abbildung rechts dargestellt.

Voraussetzungen

Das Projekt richtet sich an Studenten, die sich mit geometrischen Fragestellungen und der Auswertung geografischer Daten auseinandersetzen möchten. Die Realisierung einiger Komponenten erfolgt in Java, daher sind Kenntnisse in Java Standard Edition von Vorteil. Die Entwicklung der Kartenanwendung erfolgt mit der Google-Maps-API unter Javascript. Entsprechende Kenntnisse werden zum Projektstart nicht vorausgesetzt.

Wintersemester 2006/2007

Modellierung räumlicher Daten

Einleitung

Der Nimbus-Geodaten-Editor (siehe Abbildung) wurde zur Bearbeitung von Geodaten für zukünftige ortsbezogene Dienste entwickelt. Obwohl alle wichtigen Operationen (Bearbeiten von Struktur- und Meta-Daten, Bearbeiten der Geometrie, etc.) realisiert wurden, sind diverse Erweiterungen denkbar, z.B.

Refactoring-Operationen
Darstellen von Statistiken
Durchführen von Plausibilitätsprüfungen
Berechnungen von topologischen Beziehungen

Bei zukünftigen Erweiterungen ist es wünschenswert, dem Entwickler nicht den Zugriff auf alle Editor-Interna zu gewähren, sondern die Entwicklung auf der Basis einer vordefinierten Schnittstelle durchzuführen.

Ziel des Projektes

Ziel des Projektes ist es, eine geeignete Plug-In-Schnittstelle für den Geodaten-Editor zu entwickeln und prototypisch zu nutzen. Das Projekt umfasst folgende Punkte:

Entwicklung einer geeigneten Plug-In-Schnittstelle für den Geodaten-Editor mit der Zielsetzung, die Interna des Editors abzuschotten und gleichzeitig auf Geodaten, Strukturdaten und Kartendaten zugreifen zu können. Die Plug-In-Schnittstelle soll für mögliche zukünftige Plug-Ins eine solide Plattform darstellen.
Implementierung von drei Plug-Ins unter Benutzung dieser Schnittstelle.

Voraussetzungen

Das Projekt richtet sich an Studenten, die sich mit geometrischen Fragestellungen und der Modellierung geographischer Daten auseinandersetzen möchten. Die Realisierung erfolgt in Java, daher sind Kenntnisse in Java Standard Edition von Vorteil.

Weiterführende Literatur

(Urheberrechtshinweis)

Kapitel 11.2 und 11.4 aus Jörg Roth: A Decentralized Location Service Providing Semantic Locations, Informatik Bericht 323, Fernuniversität Hagen, Jan. 2005
Jörg Roth: Modelling Geo Data for Location-based Services, in 3. GI/ITG KuVS Fachgespräch "Ortsbezogene Anwendungen und Dienste" 7.-8. Sept. 2006, Berlin, Institut für Informatik der Freien Universität Berlin, ISBN 3-929619-39-3
Folien zum Papier "Modelling Geo Data for Location-based Services"

Sommersemester 2006

Ein ortsbezogener Kartendienst für Mobiltelefone

Einleitung

Ortsbezogene Dienste sind Informationsdienste, die die geographische Position des Benutzers berücksichtigen. Erste ortsbezogene Dienste benutzten Mobiltelefone als mobile Umgebung und erlaubten beispielsweise Hotels, Geldautomaten oder Tankstellen in der Umgebung des Benutzers zu suchen. Nicht zuletzt für neue Mobilfunktechnologien wie UMTS verspricht man sich durch ortsbezogene Dienste einen großen kommerziellen Erfolg.
Im Rahmen dieses Projekts soll ein ortsbezogener Kartendienst entwickelt werden: Mit einem Mobiltelefon kann ein Benutzer eine Umgebungskarte des aktuellen Standorts anfordern, die von einem Dienstanbieter mit entsprechenden Geoinformationen bereitgestellt wird (siehe Abbildung). Interessante Punkte, so genannte Points of Interest (POIs) (z.B. ein Lieblingsrestaurant) können am Mobiltelefon eingegeben werden. POIs können dabei im Gerät gespeichert werden oder an den Dienstanbieter übertragen werden. Öffentlich freigegebene POIs sind dabei von jedem anderen Dienstnutzer einsehbar. Zusätzlich können so genannte Buddy-Lists (die Liste von Bekannten) definiert werden. Wenn ein Benutzer es erlaubt, werden eigene POIs sowie der aktuelle Standort an die Mitglieder der Buddy-Liste verteilt.

Vorgehensweise

Bei der Anwendung liegt eine typische Client-Server-Architektur zu Grunde: Der Server bietet über ein Netzwerk auf Anforderung den Kartendienst an, der von einem mobilen Client in Anspruch genommen wird. Eine Zerlegung der Server-Anwendung in mehrere, über ein Netzwerk kommunizierende Komponenten, ist nicht notwendig, aber erlaubt. Ohne Anspruch auf Vollständigkeit sind die folgenden Komponenten zu entwickeln:

Auf Server-Seite:
- Import von vektorbasierten Geodaten
- Verwalten der Benutzerstammdaten, Accounting
- Verwalten der POIs
- Verwalten der Buddy-Lists, verteilen der POIs und Standorte zwischen den Buddies
- Bereitstellung der Kartendaten auf Client-Anfrage
Auf Client-Seite:
- Anbindung an die Positionsbestimmung
- Karten- und POI-Darstellung
- Verwalten der POIs
- Verwalten der Buddy-Lists
- Verwalten der Stammdaten, Registrierung und Kündigung des Dienstes

Problemstellungen

Es ist zu berücksichtigen, dass die Client-Anwendung auf Endgeräten mit reduzierten Ein/Ausgabefähigkeiten läuft. Darüber hinaus ist die Kommunikationsverbindung zwischen Mobiltelefon und Server in aktuellen Mobilfunknetzen immer noch der sehr schmalbandig. Umfangreiche Daten können daher nicht in kurzer Zeit zum Mobiltelefon übertragen werden. Daraus ergeben sich einige Fragestellungen. An dieser Stelle sollen keine konkreten Vorgaben gemacht, sondern nur Denkanstöße gegeben werden:

Sollen die Kartendaten zum Mobiltelefon vektor- oder rasterbasiert übertragen werden?
Wie reduziert man das Datenvolumen bei kleinen Änderungen der Position, damit nicht laufend komplette Kartenausschnitte übertragen werden müssen?
Soll der Client im Hintergrund schon im Voraus Kartendaten laden, bevor man einen Standort erreicht hat (proaktives Caching, z.B. anhand der Bewegungsrichtung)?
Wie reduziert man die Zugriffszeit auf Kartendaten auf Server-Seite? (Das System soll u.U. für mehrere Tausend Benutzer lauffähig sein).

Voraussetzungen

Das Projekt richtet sich an Studenten, die sich für mobile Netzwerkanwendungen interessieren und sich darüber hinaus mit geometrischen Fragestellung und der Modellierung geographischer Daten auseinandersetzen möchten. Die Server-Komponente soll in Java Standard Edition, die Client Komponente in Java Micro Edition entwickelt werden. Reale digitale Kartendaten werden zur Verfügung gestellt. Kenntnisse in Java Standard Edition sind von Vorteil; Kenntnisse in Java Micro Edition können während der Projektlaufzeit erworben werden.

Weiterführende Literatur

(Urheberrechtshinweis)

Kapitel 2.2, 11.2 und 11.4 aus Jörg Roth: A Decentralized Location Service Providing Semantic Locations, Informatik Bericht 323, Fernuniversität Hagen, Jan. 2005
SUNs Java ME Homepage