Anwendungen im Tourismus

Proseminar: Anwendungen für Augmented Reality
Inhaltsverzeichnis
Anwendungen im Tourismus
1. User Interfaces 2
1.1 Voraussetzungen 2
1.2 Wahl der Eingabegeräte 2
1.3 Die Implementierung eines User Interfaces
anhand von drei Beispielen 3
1.3.1 COTERIE 3
1.3.2 JABAR – Java Based AR 3
1.3.3 Ruby – A Rule Based Software Architecture 3
2. Anwendungsbeispiele 4
2.1 Columbia Touring Machine 4
2.1.1 Ziele 4
2.1.2 Systemspezifikationen 4
2.1.3 Nutzung von vier verschiedenen User Interfaces 5
2.2 Situated Documentaries 5
2.3 Das Virtual Showcase 5
2.4 Restaurant Guide 6
2.5 Weitere zukünftige Anwendungsmöglichkeiten 6
2.6 Noch vorhandene Probleme 7
3. Ausblick 7
4. Quellen 8

1. User Interfaces
1.1 Voraussetzungen
Die Grundvoraussetzungen für ein User Interface, dass sich mobil nutzen lässt, sind zuerst mal die
relativ trivial erscheinende Unterstützung von World- und Screen-stabilized Grafiken, idealerweise
sowohl in 2D, als auch in 3D, um eine Augmentierung überhaupt erst zu ermöglichen.
Wünschenswert sind zusätzlich noch Multimediafähigkeiten, um auch Sound und Videos abspielen
zu können. Ebenso banal wie selbstverständlich stellt sich auch die Unterstützung verschiedenster
Ein- und Ausgabegeräte dar, die von einer UI unterstützt werden müssen. Ebenso sollte das System
auf dem ganzen zugänglichen Gebiet, im Idealfall also weltweit, immer verfügbar sein, sowie
natürlich ortsabhängig anders reagieren. Das User Interace muss natürlich auch in der Lage sein mit
dem riesigem Bewegunsspielraum, den ein Nutzer hat, zurechtzukommen. Wünschenswert wären
natürlich auch Interaktionsmöglichkeiten, um überhaupt erst sinnvolle Anwendungen zu
ermöglichen. Mit Blick auf eine zukünftige kommerzielle Nutzung wäre zudem eine intuitive
Bedienbarkeit ein wichtiges Element, um Akzeptanz bei potentiellen Nutzern zu erzielen. Sobald
sich Augmented Reality im Alltag durchsetzt, wäre auch eine Datenfilterung, ähnlich eines Spam-
Blockers eines Mailprogramms oder eines Pop-Up-Blockers eines Browsers nötig, um einen Nutzer
nicht durch eine überhöhte Anzahl an Augmentierungen zu verwirren. Da die äußeren Umstände
eines Nutzers, also etwa Wetter oder Trackinggenauigkeit, nahezu unkontrollierbar sind muss die
UI außerdem in der Lage sein, sich flexibel und kontextbezogen an alle möglichen Ereignisse
anzupassen.
1.2 Wahl der Eingabegeräte
Es stellt sich nun also die Frage, welche Eingabegeräte für mobilen Einsatz am besten geeignet
wären. Offensichtlich ist, dass eine Tastatur nicht in Frage kommt, da es den Mobilitätsansatz ad
absurdum führt. Ebenso ist auch ein Datenhandschuh eher unpraktikabel, obwohl dieser sehr
zuverlässige Daten liefert, da auch dieser die Bewegungsfreiheit in gewissen Maße einschränkt.
Außerdem ist es sicherlich keinem Touristen zuzumuten, sich in seinem Urlaub mit etwas derart
unkomfortablem und auch nicht sonderlich hübsch anzusehendem zu bewegen. In etwas
handlichere Gefilde kommt man, falls man sich für die Benutzung einer (kabellosen) Maus oder
eines Trackballs entscheidet. Diese sind zwar sicherlich kein Musterbeispiel für Komfort oder
intuitive Bedienung, gehören allerdings im Augenblick zu den besten und auch am meisten
eingesetzten Alternativen.
Relativ gut funktioniert hingegen die Eingabe von Daten mittels eines Mikrofons, da die
Spracherkennung in den letzten Jahren rasante Sprünge gemacht hat und sich wohl noch weiter
entwickeln wird. Jedoch ist diese Eingabemöglichkeit leider nicht sonderlich universell, da durch
Störgeräusche im Hintergrund die Spracherkennung deutlich erschwert, wenn nicht gar unmöglich
gemacht wird, etwa falls sich der Nutzer innerhalb einer Menschenmenge befindet.
Bereits erprobt ist auch die Möglichkeit der Dateneingabe über einen PDA oder eines Palmtops
mittels eines Stiftes. Da diese Geräte sehr handlich sind und man sich durchaus die
Implementierung in ein Mobiltelefon vorstellen kann, was für einen Großteil der Gesellschaft auch
keine zusätzliche Hardware darstellen würde, ist diese Methode eine der besten Alternativen, zumal
eine große Funktionalität dadurch gegeben ist, dass derartige Geräte auch als Ausgabegeräte
verwendet werden können. Als unterstützendes “Eingabegerät” kann man sich auch noch die
Eingabe über Pupillentracking vorstellen. Dadurch kann das System nachvollziehen, worauf der
Benutzer sein Augenmerk legt. Fokussiert er nun ein Objekt über eine gewisse Zeitspanne hinweg,
so wird dieses selektiert, weitere Interaktion ist allerdings nur schwerlich möglich.

1.3 Die Implemtierung eines User Interfaces anhand von drei Beispielen
1.3.1 COTERIE
COTERIE wurde 1996 von MacIntyre an der Columbia University entwickelt und stellte eine
Weiterentwicklung von Modula-3 und Repo dar, welches unter Verwendung von Repo-3D (einer
Version von Obliq-3D, welche um Funktionalitäten für Virtual und Augmented Reality erweitert
wurde) Grundfunktionalitäten eines User Interfaces zur Verfügung stellte. So wurden Tracking und
AR-Anwendungen unterstützt. Einzige erwähnenswerte Besonderheit war die Möglichkeit, Objekte
als “Shared Objects” zu definieren. Unter Verwendung dieses Features konnte man ein Objekt auf
mehreren gleichzeitig genutzten Interfaces auch synchron erscheinen lassen, anstelle jedes Interface
einzeln zu ändern. Eine größere Anzahl an Problemen verhinderte jedoch den breiten Einsatz von
COTERIE. Zum einen war Repo eine sehr spezielle, weitgehend unbekannte Sprache, bei
Problemen konnte man also nicht auf kompetenten Support vertrauen, des weiteren wurde neuere
AR-Ausrüstung nicht standardmäßig unterstützt. Eine Implementierung war zwar möglich, aber
relativ umständlich. Auch konnte man eigentlich nur durch das Hintertürchen, dass Netscape von
COTERIE unterstützt wurde, auf Multimedia-Fähigkeiten zurückgreifen und dann über diesen Java-
Applets oder Videos aufrufen. Außerdem war COTERIE in der Zahl der Nutzer, die sich
gleichzeitig in der AR bewegen konnten sehr beschränkt, eine breitere und letzlich möglicherweise
sogar kommerzielle Nutzung von COTERIE war also allein dadurch schon nahezu ausgeschlossen.
COTERIE wurde unter anderem bei der Columbia Touring Machine benutzt.
1.3.2 JABAR – Java Based AR
JABAR wurde 1999 an der Columbia University von T. Höllerer entwickelt mit dem
Hintergedanken, die Einschränkungen, die COTERIE hatte, möglichst aufzuheben. So war dank der
Nutzung von Java nun ein plattformübergreifender Einsatz möglich (COTERIE war auf Windows
beschränkt). Auch waren und sind für Java sehr viel mehr Programmbibliotheken zu finden als dies
bei Repo der Fall ist. Zwar müssen auch in JABAR neue Geräte einzeln implementiert werden,
allerdings ist dies deutlich einfacher möglich als in COTERIE, ebenso brauchte man bei Problemen
oder gewünschten Erweiterungen des Systems “nur” jemanden finden, der Ahnung von Java hat,
was ein ganzes Stück einfacher sein sollte, als einen Repo-Experten aufzutreiben. Auch das
Problem der sehr beschränkten Nutzerzahl von COTERIE wurde mit JABAR weitestgehend gelöst.
Zusätzlich erhielt JABAR neben deutlich verbesserter Multimedia-Fähigkeiten auch noch neue
Funktionalitäten im Bereich der Objekt-Interaktion.
1.3.3 Ruby – A Rule based Software Architecture
Ruby wurde auf Basis von CGUI Lab AR (einem User Interface, das von Blaine Bell entwickelt
wurde und das JABAR sehr ähnlich war) und von JESS (der Java Expert System Shell) von T.
Höllerer an der Columbia University entwickelt. Ruby war darauf ausgelegt eine hohe Flexibilität
hinsichtlich Informationsfilterung, Blickfeldmanagment und der Reaktion auf kontextbezogene
Ereignisse zu bieten; so sollte das System beispielweise eingreifen können, wenn sich mehrere
Labels überlappten, die Tracking-Qualität oder das Wetter sich änderte. Dies geschah mittels einer
Bewertung durch die Regeln einer zentralen “Knowledge Base”, weswegen die Funktionalität des
User Interfaces sich auch sehr einfach mittels Hinzufügen von weiteren Regeln erweitern lässt.
Dadurch sollte ein User Interface entstehen, dass sich “angenehm” anfühlt und einen intuitiven
Zugang zur Augmented Reality ermöglichen soll.
Realisiert wurde dies durch die Beobachtung verschiedenster “Facts”, für den Benutzer unsichtbare
Meta-Informationen. Dazu gehörten die aktuelle Position des Nutzers, Objekte, die sich momentan

innerhalb oder außerhalb des Sichtfelds des Nutzers befinden oder welche Ein- und Ausgabegeräte
dieser augenblicklich benutzen kann. Insgesamt werden zwischen 1200 und 2500 derartiger Facts
vom System verwaltet. Außerdem besitzen alle Objekte Attribute, etwa die Sichtbarkeit, die
Transparenz, die Priorität oder die Tracking-Qualität, die nötig ist um dieses Objekt nicht bloß auf
der Minimap anzuzeigen. Zusätzlich werden Objekte, wie auch Ereignisse nochmals in
Unterklassen aufgeteilt, auf die jeweils anders reagiert werden kann (bei Objekten etwa Knopf,
Menüpunkt, Information oder Verbindung und bei Ereignissen etwa Kopfbewegung, Verdeckung
eines Objekts oder Sichtkontakt zu einem Objekt). Die Knowledge Base verwaltet eine ganze Reihe
von Regeln (2004 waren es 264), welche sich auf alle Facts, Objektattribute oder Ereignisse
anwenden lassen und sogar während der Laufzeit des Systems geändert werden können. Verändert
sich also lediglich ein einzelner “Fact”, so führt dies potenziell zu einer Änderung der gesamten
Anzeige. Je nachdem wie komplex und objektreich die aktuelle Umgebung ist, wird das User
Interface zwischen 15 und 60 mal pro Sekunde upgedatet. Um Lags zu verhindern, die durch das
Laden von Multimedia oder anderen Daten entstehen, teilt das System die Umgebung in gewisse
“Szenen” ein, welche wiederum aus kleineren “Räumen” bestehen. Betritt ein Nutzer nun eine neue
Szene, so werden präventiv möglicherweise später benötigte Daten heruntergeladen, um auf diese
im Bedarfsfall ohne Verzögerung zuzugreifen zu können. Beim Betreten einer Szene werden
zuerste solche Daten geladen, welche relativ wahrscheinlich innerhalb der nächsten Zeit benötigt
werden, also zuerst die näherliegenden Räume.
2. Anwendungsbeispiele
2.1 Columbia Touring Machine
2.1.1 Ziele
Das Hauptziel der Columbia Touring Machine bestand daraus, ein auf Augmented Reality
basierendes “Navigationssystem” zu erstellen, dass einen Nutzer über den Campus der Columbia
University führen können sollte. Außerdem sollte jederzeit eine World-in-Miniature, eine durch den
User frei bewegliche und drehbare Minimap, einblendbar sein. Desweiteren wollte man die
Möglichkeit haben, zu vielen Objekten zusätzliche Informationen oder Multimediadaten übers
Internet aufrufen zu können. Auch sollte ein virtueller “Wiederaufbau” von nicht mehr existenten
Gebäuden realisiert werden. Als Besonderheit sollte noch die Möglichkeit bestehen, dass der mobile
Nutzer mit einem immobilem Nutzer, einer Art Administrator kollaborativ zusammenarbeitet.
2.1.2 Systemspezifikationen
Zum ersten Testlauf bestand die Hardware des Systems aus einem Head-Mounted-Display mit einer
Auflösung von 263x230 Pixeln, einem Mitsubishi AMiTY Handheld mit einer 75 Mhz DX4-CPU,
auf dem Windows95 lief und der über ein Trackpad gesteuert werden konnte. Zusätzlich musste der
Nutzer noch einen Laptop auf dem Rücken tragen. Dieser hatte eine 133 Mhz CPU eingebaut und
war als Besonderheit mit einer 3D-Karte ausgestattet, um die für den Nutzer sichtbaren
Augmentierungen ohne Umweg über eine Workstation direkt vor Ort erzeugen zu können. Das
Tracking lief über einen InterSense IS6000 Mark II Hybrid Tracker mit Ultraschall und Inertial-
Tracking ab. Zusätzlich war der Nutzer noch mit einem GPS-Tracker ausgestattet. Der Zugriff ins
Internet wurde über das Universitäts-eigene WLan gewährleistet und erlaubte Geschwindigkeiten
bis zu 2 MBit. Die meisten Geräte wurden jedoch im Laufe des Projektes gegen leistungsstärkere
Versionen ausgetauscht.

2.1.3 Nutzung von vier verschiedenen User Interfaces
Wie bereits angedeutet wurden bei der Columbia Touring Machine vier verschiedene UIs
gleichzeitig eingesetzt. Zum einen war dies natürlich diejenige, welche der mobile Nutzer auf
seinem HMD dargestellt bekam. Die Entwickler entschieden sich dafür, Labels, Fahnen und
virtuelle Gebäude world-stabilized zu setzen, während sie Menüs, Richtungsweiser-Pfeile und die
einblendbare World-in-Miniature screen-stabilized implementiert hatten.
Außerdem wurde auf dem Handheld eine Karte des Campus eingeblendet, auf welcher man
erkennen konnte, wo man sich selbst befand und mit einem Stift ein Gebäude auswählen konnte.
Dann wurde ein Pfeil auf dem Handheld eingeblendet, der einen dort hinleiten sollte. Hatte der
Nutzer zusätzlich sein HMD auf, so wurde ihm auch dort ein Pfeil eingeblendet, der immer in
Richtung seines Zieles weisen sollte. Der Handheld war jedoch sowohl mit oder ohne Einsatz eines
HMDs nutzbar.
In eine ganz andere Richtung geht hingegen die Nutzung einer Indoor UI. Innerhalb des Campus
befand sich ein relativ immobiler Nutzer, vergleichbar mit einem Administrator, der auf einem
Bildschirm eine Karte, ähnlich der des Handhelds hatte und damit den mobilen Nutzer überwachen
konnte. Er hatte die Möglichkeit mit diesem zu kommunizieren (was auch in die andere Richtung
möglich war) und er konnte ihm den Weg weisen, indem er durch Setzen von Fähnchen auf der
Karte eine Route markierte, die dann auch gleichzeitig für den mobilen Nutzer sichtbar wurde. Auf
diese Weise sollte die Möglichkeit bestehen, dass der Administrator dem mobilen Nutzer
alternative, im Idealfall natürlich bessere Wege, zu bestimmten Orten weist.
Zu Demonstrationszwecken wurde ausserdem die Möglichkeit implementiert, dass der
Administrator nicht an einem Bildschirm sitzt, sondern über ein HMD eine 3D-Karte eingeblendet
bekommt, auf der er dann die gleiche Funktionalität besitzt und weiterhin Fähnchen setzen kann
zwecks Wegweisung. Besonders erwähnenswert ist die bereits angeschnittene Tatsache, dass die
Änderung in einem User Interface, etwa das Setzen eines Fähnchens, oder das Auswählen eines
Objektes über den Handheld dazu führt, dass diese Änderung für alle verfügbaren User Interfaces
übernommen wird.
2.2 Situated Documentaries
Situated Documentaries sollte eine Erweiterung der Columbia Touring Machine sein. Basierend auf
eben dieser wurde unter Verwendung von JABAR deren Funktionalität vergrößert; so war etwa
deutlich bessere Interaktion mit dem Handheld möglich, ebenso wurden die Multimedia-
Fähigkeiten verbessert. Der Nutzer sollte die Gelegenheit haben, eine zusammenhängende
Dokumentation zu erleben. Dies wollte man unter anderem durch Einführung kontextbasierender
Ereignisse erreichen. Hatte ein Benutzer den ersten Multimedia-Clip gesehen, so wurde der nächste
Clip am dafür fortgesehenen Ort freigeschaltet und dem Nutzer mitgeteilt, wie dieser zu erreichen
sei. Da ein dauerhafter Internet-Zugang über das Univeritäts-eigene WLan sichergestellt werden
konnte, wurden Daten präventiv auf den Handheld übertragen, um bei Bedarf dadurch sofort zur
Verfügung zu stehen. Erwähnenswert ist, dass zu diesem Projekt ein Editor erstellt wurde, der die
Schaffung einer eigenen AR-Dokumentation ohne Programmier-Kenntnisse und in nur geringer
Zeit erlaubt; ein notwendiger Schritt für eine kommerzielle Verwertung zukünftiger User Interfaces.
2.3 Das Virtual Showcase
Das Ziel des Virtual Showcase war es, antiken Ruinen wieder Leben einzuhauchen. Mittels
Augmented Reality sollten fehlende Stücke einer Ruine ergänzt werden und möglicherweise sogar
einstige Bewohner eben dieser sich dort bewegen und – eine ausgereifte KI vorausgesetzt – sich
sogar zu einem Gespräch mit den Ruinenbesuchern hinreißen lassen. Anstatt die fehlenden Stücke

einer Ruine zu ergänzen, wäre es sogar denkbar eine komplette Ruine via AR an einen anderen
Punkt zu transferieren. Denkbar wäre etwa ein ausgedientes Flugfeld (welches eine größere ebene
Fläche bietet) in einen Ruinenpark mit wöchentlich wechselnder begehbarer Ruine zu verwandeln.
So wäre auch die Begehung von Ruinen möglich, die aufgrund von Baufälligkeit für den
Publikumsverkehr gesperrt sind. Eine derartige Funktionalität besitzt das Virtual Showcase jedoch
noch bei weitem nicht. Der momentane Prototyp besteht aus einem einzigem durchsichtigem
Bildschirm, der in der Gegend des Heidentors in Österreich aufgestellt wurde. Dieser ist mit
mehreren Kameras verbunden, die die Anwesenheit eines Besuchers registrieren und dessen
Blickrichtung tracken. Darauf basierend ist dann auf dem Bildschirm eine Augmentierung des
dahinter liegenden Heidentors zu sehen. Außerdem tritt auf dem Bildschirm dann eine Person in
Erscheinung, die anbietet, dem Besucher die Geschichte des Heidentors zu erklären. Die
Kommunikation mit dieser Person läuft im Augenblick jedoch auch ausschließlich durch
Auswählen eines Buttons, der auf dem Bildschirm eingeblendet wird, ab. Dieses System hat
dadurch zwar den Vorteil, dass der Besucher keinerlei Hardware mit sich herumtragen muss, besitzt
aber die gravierenden Nachteile, dass es zum einen nicht mobil ist, d.h. nicht die Betrachtung des
Heidentors aus jedem erdenklichen Blickwinkel heraus gestattet, als auch natürlich nicht für
mehrere Benutzer geeignet, da nur ein einziger Bildschrim zur Augmentierung zur Verfügung steht.
Man kann sich jedoch durchaus eine Erweiterung des Systems vorstellen, die dann schon nahezu
die gewünschte Funktionalität bieten würde.
2.4 Der Restaurant Guide
Dieses Projekt sollte einen mobilen Restaurant-Führer darstellen, der das Gebiet um die
Morningside Heights in Manhatten abdeckt. Innerhalb eines Gebiets von 16 Blocks sind darin 40
Lokale verzeichnet. Mittels eines World Models wurde das fragliche Gebiet nachgebildet, um die
Möglichkeit zu haben, einzelne Objekte zu annotieren. Da allerdings in Manhattan kein
flächendeckendes WLan-Netz zur Verfügung steht, wurden alle relevanten Daten in einer SQL-
Datenbank auf dem Notebook des Nutzers gespeichert. Befand dieser sich nun im Gebiet eines
Restaurants, dass in der Datenbank verzeichnet war, wurde dieses annotiert. Wählte der Nutzer die
Annotation dann durch Eingabe mit einem Trackball aus, öffnete sich ein Pop-Up-Fenster. Dieses
wurde, dank der Verwendung von Ruby, automatisch so positioniert, dass es nicht die Sicht auf das
Restaurant oder andere relevante Objekte verdeckte und enthielt ein Bild des Inneren des Lokals,
einen kurzen Beschreibungstext und mehrere Buttons, um die Homepage des Restaurants, dessen
aktuelles Menu oder eine Seite mit Kommentaren verschiedener Nutzer des Systems zu dem Lokal
angezeigt zu bekommen – sofern denn eine Internet-Verbindung bestand, was bei diesem Projekt
nicht der Fall war. Zur Orientierungshilfe konnte der Nutzer sich eine World-in-Miniature
einblenden lassen. Auch auf dieser waren alle Restaurants in der Datenbank eingezeichnet und auch
direkt auswählbar.
2.5 Weitere zukünftige Anwendungsmöglichkeiten
Besonders die Idee des Restaurantführers scheint besonders dafür geeignet auf weitere Bereiche
ausgedehnt zu werden. Man kann sich durchaus einen Museumsführer vorstellen, der einzelne
Ausstellungsstücke annotiert und auf Wunsch weitere Informationen aus dem Internet oder
Videoclips zur Geschichte des Objektes präsentiert. Denkbar wäre auch eine Stadtführung via
Augmented Reality. Man könnte sich von dem System zu allen interessanten Sehenswürdigkeiten
leiten lassen und bei Bedarf weitergehende Informationen dazu abrufen, ebenso wie dies bei einer
echten Stadtführung wäre, jedoch kostengünstiger, weiterführender und individueller.
Auch historische Präsentationen liessen sich damit glaubwürdiger (und kostengünstiger) inszenieren
Beispielsweise werden in Amerika jedes Jahr wichtige Schlachten des Bürgerkrieges nachgespielt.

Dies geschähe etwa unter Einsatz von Augmented Reality deutlich glaubwürdiger und würde den
Zuschauern auch ermöglichen vom Standpunkt des aussenstehenden Beobachters sogar in eine
Perspektive direkt innerhalb des Schlachtfeldes zu wechseln. Eine weitere Anwendung, die sich
nahezu sicher durchsetzen wird, sobald Augmented Reality zum Massenprodukt wird, gehört
jedoch auch erwähnt. Mit Sicherheit werden wir uns in Zukunft nicht mehr bloß im Internet mit
Werbung herumärgern müssen, sondern auch in der Augmented Reality als “erweitertem Internet”.
Sicherlich ist aber noch eine ganze Reihe weiterer sinnvoller Anwendungsmöglichkeiten denkbar.
2.6 Noch vorhandene Probleme
Spekuliert man auf einen zukünftigen kommerziellen Erfolg von Augmented Reality, so ist zu
beachten, dass der Nutzer vor allem Komfort erwartet. So ist etwa ein Datenhandschuh als
Eingabegerät unzumutbar, da dieser die freie Nutzung der Hände einschränkt. Doch auch die
letzlich verwendete Hardware muss möglichst geringe Größe aufweisen. Gleichzeitig soll sie aber
eine hohe Leistung ermöglichen, ein hohes qualitatives Niveau erreichen und dennoch
kostengünstig – und damit erschwinglich – sein. Auch soll die Batterie eine hohe Laufzeit bieten.
Erschwerend kommt noch hinzu, dass sich diese Wünsche (zumindest teilweise) gegenseitig
widersprechen.
Doch es gibt auch noch eine ganze Reihe technischer Probleme, die bisher höchstens ansatzweise
gelöst sind. Man sollte schließlich auch bedenken, dass die Outdoor Environment, im Gegensatz zur
Laborumgebung, unberechenbar ist und einem System durch einen Wechsel der Lichtverhältnisse
oder der Trackinggenauigkeit massive Schwierigkeiten bereitet werden könnten. Auch ist zu
beachten, dass verschiedenste Ein- und Ausgabegeräte für die AR existieren und diese in nahezu
unendlich vielen Kombinationsmöglichkeiten miteinander genutzt werden können; wobei jede
einzelne natürlich auch sinnvoll unterstützt werden muss. Und letzlich bleibt, trotz der sehr guten
Ansätze, die Ruby bietet, wohl dennoch noch einiges zu tun im Bereich der Datenfilterung. Auch ist
für eine sinnvolle Nutzung der AR eine Verbindung zum Internet beinahe notwendig, allein schon
um aktuelle Daten bereitstellen zu können. Dies dürfte sich nahezu ausschließlich über ein
flächendeckendes WLan-Netzwerk errreichen lassen, momentan fällt die gebietsmäßige Abdeckung
allerdings noch nicht mal in den Promille-Bereich. Als problematisch wird sich auch gestalten, dass
die ganze Welt Teil des zugänglichen Environments ist. Deswegen ist es unmöglich eine
Annotation von Objekten über World Models zu gewährleisten, da ein derartiges Modell deutlich zu
komplex und zu großem Wandel unterworfen wäre. Auch hier muss wohl noch eine Alternative
gefunden werden, um einen effektiven Einsatz zu ermöglichen.
3. Ausblick
Besonders mit Blick auf Abschnitt 2.6 erscheint es offensichtlich, dass ein flächendeckender
Einsatz mobiler AR-Systeme noch nicht ansteht. Da allerdings ein großes Potential im Bereich der
AR steckt und sich vermehrt auch Forscher und Firmen dafür begeistern lassen, kann man durchaus
die Behauptung wagen, dass eine hohe Wahrscheinlichkeit besteht, dass Augmented Reality
zukünftig ein genau so akzeptierter und selbstverständlicher Teil unserer Kultur darstellen wird, wie
es heutzutage beim Internet der Fall ist. Mehr noch: dadurch, dass AR-Systeme primär das Internet
als Datenquelle nutzen werden, wäre es nicht verwunderlich, wenn Augmented Reality dereinst
seinem Namen entsprechend eine Erweiterung des Internets werden würde. Doch gerade aus der
Sicht eines potentiellen Anbieters von AR-Diensten gibt es neben den in Abschnitt 2.6 genannten
Problemen noch weitere, bei denen man sich um eine Lösung bemühen sollte. Momentan würden
etwa noch rechtliche Unklarheiten den Einsatz erschweren. Wer wäre schuld, wenn ein Anwender
einen Unfall verursacht, weil er durch Daten aus der AR abgelenkt wäre? Der Nutzer, weil er sich
ablenken liess? Der Entwickler des User Interface, weil die Datenfilterung nicht wie gewünscht

funktioniert hat? Oder der Anbieter, da von ihm die Daten stammen, die den Nutzer letztendlich
abgelenkt haben? Auch stellt sich das Problem wie man einen Unternehmer überhaupt dazu
überreden kann, AR-Dienste anzubieten. Geld würde durch die Benutzung von AR wohl nicht in
die Taschen des Unternehmers gespült, auch würden Einnahmequellen, etwa durch
Fremdenführungen zusätzlich wegfallen. Im Laufe der Zeit würden derartige Dienste zwar wohl
auch durch Privatpersonen angeboten, aber die Entwicklung und die Akzeptanz der Augmented
Reality könnten durch Unternehmern, die demgegenüber skeptisch eingestellt sind, durchaus
verzögert werden.
4. Quellen
1) A Survey of Augmented Reality - Azuma (1997) - www.cs.unc.edu/~azuma/ARpresence.pdf
2) Location Aware Scheduling with Minimal Infrastructure - Heidemann & Shah (2000) -
http://citeseer.ist.psu.edu/cache/papers/cs/15242/http:zSzzSzsys192.cs.washington.eduzSzRelatedz
SzHeidemann00b.pdf/heidemann00locationaware.pdf
3) Exploring MARS: Developing Indoor and Outdoor User Interfaces to a Mobile Augmented
Reality System - T. Höllerer et al. (1999) -
http://www1.cs.columbia.edu/graphics/publications/CandG99.pdf
4) User Interfaces for Mobile Augmented Reality Systems - T. Höllerer (2004) -
http://www.cs.ucsb.edu/~holl/pubs/hollerer-2004-diss.pdf
5) A touring machine: Prototyping 3D mobile augmented reality systems for exploring the urban
environment - Feiner et al. (1997) -
http://www1.cs.columbia.edu/graphics/courses/mobwear/resources/feiner-iswc97.pdf
6) Wearing it out: First steps towards Mobile Augmented Reality Systems - Feiner et al. (1999) -
http://www.cc.gatech.edu/~blair/papers/ismr99.pdf
7) Authoring 3D Hypermedia for Wearable Augmented and Virtual Reality - Güven & Feiner
(2003) - http://www.cs.columbia.edu/graphics/people/sinem/papers/Authoring-
ISWC2003/S.Guven-ISWC2003.pdf
8) Wearable Computing and Contextual Awareness - Starner (1999) -
http://hdl.handle.net/1721.1/9543
9) Presenting Past and Present of an Archaeological Site in the Virtual Showcase - Ledermann &
Schmalstieg (2003) - http://www.ims.tuwien.ac.at/media/documents/publications/vast2003draft.pdf
10) Wearable Computing: A First Step Toward Personal Imaging - Mann (1997) -
http://www.wearcam.org/ieeecomputer/r2025.htm
11) http://www1.cs.columbia.edu/graphics/projects/mars/mars.html
Stefan Knipl (knipl@in.tum.de), 2005