Augmented Reality Visualisierung von archäologischen Daten

Größe: px
Ab Seite anzeigen:

Download "Augmented Reality Visualisierung von archäologischen Daten"

Transkript

1 Masterarbeit Dennis Hücker Augmented Reality Visualisierung von archäologischen Daten Augmented Reality Visualization of archeological data Betreuer: Prüfer: Zweitprüfer: M.Sc. Daniel Eggert Prof. Dr.-Ing. habil. Monika Sester Prof. Dr. rer. nat. Volker Paelke

2 Augmented Reality Visualization of archeological data Abstract Augmented reality (AR) visualizations are very well suited to present archeological data and contents (e.g. overlaying an excavation site (or a corresponding map) with a reconstructed 3D model). The goal of this thesis is the identification of potential augmentation content and appropriate ways of interacting with the visualized content. The outcome must include a working prototype implementation of the proposed visualization and interaction schemes. The thesis might include temporary residence in Barcelona/Spain to get in contact with the local archeologists in order to identify necessary requirements and demands. Tasks and schedule 1. Review of archeological maps 2. Identification of potential augmentation content and interactive functionality in collaboration with archeologists and museum staff 3. Selection of demonstrator content 4. Selection of camera/marker based AR framework 5. Iterative design a. Augmentation content b. Interactive functionality c. Implementation d. User Tests 6. Analysis of results Tools Android tablet/smartphone Prerequisites Basic knowledge of Android application development (Java/C++/OpenGL ES) Basic AR knowledge Contact Daniel Eggert ( Tel ) Institut für Kartographie und Geoinformatik, Appelstraße 9a, Hannover, Raum 604

3 Kurzfassung Ein Ziel der Archäologie ist die Dokumentation und Rekonstruktion der geschichtlichen Entwicklungen der Menschheit. Die aufgrund einer archäologischen Ausgrabung gewonnenen Daten haben in der Regel einen räumlichen Bezug und werden mit Hilfe von Papierkarten oder Geoinformationssystemen visualisiert. Sowohl Papierkarten, als auch digitale Repräsentationen haben in ihrer Anwendung zum Teil komplementäre Vor- und Nachteile. Mit Augmented Reality Visualisierungen können beide Systeme kombiniert werden und sich somit gegenseitig ergänzen. In dieser Arbeit wird ein Konzept zur Erweiterung von archäologischen Papierkarten mit 3D Modellen und zusätzlichen Interaktionsmöglichkeiten vorgestellt. Die identifizierten Anwendungsszenarien umfassen neben der dreidimensionalen Präsentation von Daten, zum Beispiel für Museumsbesucher, auch die Generierung neuer Inhalte, um die archäologische Arbeit auf einer Ausgrabung zu unterstützen. Mit ARAC Maps (Augmented Reality for Archeological Content on Maps) wird das Konzept in Form einer mobilen Anwendung auf Basis handelsüblicher Endgeräte mit Android- Betriebssystem umgesetzt. Abstract One intention of archeology is the documentation and reconstruction of historical development of mankind. The extracted data of an archeological excavation is ususally spatial referenced and visualized with the help of maps or geographical information system. Both, papermaps and digital representations have partly complementary strengths and shortcomings in their application. With Augmented Reality, both Systems can be combined and complement each other. This Work presents a concept for augmenting archeological paper maps witd 3D models and additional interaction options. Besides the presentation of contents in 3D space for museum visitors, the identified examples of usage include the generation of new contents to support the archeological work on an excavation site.the mobile application ARAC Maps (Augmented Reality for Archeological Content) realizes this concept based on commercially available devices with the Android operationsystem.

4 Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die vorliegende Masterarbeit selbstständig verfasst habe. Es wurden keine anderen als die in der Arbeit angegebenen Quellen und Hilfsmittel benutzt. Die wörtlichen oder sinngemäß übernommenen Zitate habe ich als solche kenntlich gemacht. Hannover, den 16. Oktober 2012 Dennis Hücker

5 I Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis III IV VI 1 Einleitung Motivation Zielsetzung Aufbau der Arbeit Grundlagen Augmented Reality Tracking Displays Mobile Computing Android ios Windows Phone Archäologie Archäologische Ausgrabungen Vorteile und Einschränkungen von Papier- und digitalen Karten 10 3 Konzept und Anforderungen Konzept Zielgruppen Funktionsumfang Anforderungen Verwandte Arbeiten Entwurf Auswahl der Mobilen Plattform Auswahl Software Basis Metaio Mobile SDK OpenCV Vuforia Vergleich und Entscheidung Software Architektur Android SDK Android NDK Java Native Interface OpenGL ES

6 Inhaltsverzeichnis II VRML Implementierung D Darstellung Datenstruktur Shader Organistation in Ebenen Anzeige von Zusatzinformationen Color Picking Darstellung der Zusatzinformation Generatives Straßenmodell Definition des Umrisses Straßengenerierung Annotationen Programmdemonstration Konfiguration des Programmes Marker Erstellung Konfigurationsdatei ARAC Maps Programmstart Darstellung der 3D Modelle Anzeige von Zusatzinformationen Straßengenerierung Annotationen Evaluation Testaufbau Aufgabenstellung Nutzungsverhalten Bearbeitungserfolg Fragebogen Ergebnis Identifikation der Schwachstellen Verbesserung der Gebrauchstauglichkeit Zusammenfassung und Ausblick 64 Literaturverzeichnis 66 Anhang VII

7 III Abkürzungsverzeichnis API Application Programming Interface AR Augmented Reality ARAC Maps... Augmented Reality for Archeological Content on Maps ARmsk Augmented Reality Markerless Support Kit AV Augmented Virtuality CAD Computer Aided Design CCW counter clockwise CPU Central Processing Unit DVM Dalvik Virtual Machine FBO Frame Buffer Object FFP Fixed Function Pipeline GIS Geoinformationssystem GLSL Open GL Shading Language GPS Global Positioning System GPU Graphic Processing Unit HMD Head-Mounted-Display HTML Hypertext Markup Language ICS Ice Cream Sandwich JIT Just in Time JNI Java Native Interface JVM Java Virtual Machine MR Mixed Reality NDK Native Development Kit OpenCV Open Source Computer Vision OpenGL ES.... Open Graphics Library for Embedded Systems QCAR Qualcomm AR SDK QDevNet Qualcomm Developer Network RFID radio frequency identification SDK Software Development Kit SUS System Usability Scale TMS Target Managment System VRML Virtual Reality Modeling Language XML Extensible Markup Language

8 IV Abbildungsverzeichnis 2.1 Mixed Reality Kontinuum Optisches Tracking Smartphone Markt Android Verteilung Archäologischer Ausgrabungsprozess und dessen Produkte Luftbild Archäologie Grabungskarte einer römischen Therme in Guissona, Spanien Vereinfachte Museumskarte der römischen Therme Römischer Stadtbau ArcheoGuide Augmented Maps Verwendete Entwicklungsplattformen Metaio Augmented City 3D Marker Target Managment System Topographische Karte der Asseburg [IKG, 2009] Android Systemarchitektur OpenGL ES Fixed Function Pipeline VRML Format Programmkomponenten Berechnung der Vertexnormale Lichteinfallswinkel Einfluss des Shading auf 3D-Eindruck Ebenen Auswahl über SlidingDrawer Color Picking: Farbcodierung der Objekte WebView zur Anzeige von Zusatzinformationen OpenGL Kamera Koordinatensystem Fünf Schritte zum Straßennetz Vier Mögliche Konstellationen beim Linienclipping Linienclipping nach Cyrus-Beck Notizansicht zur Verwaltung der Notizen Konfiguration des Markers im TMS Marker Download Startlogo von ARAC Maps Menü zum Wechseln des Marker-Datensets Hauptmenü mit Ebenenauswahl Darstellung der verknüpften Zusatzinformation Straßengenerierung Verändertes Straßennetz

9 Abbildungsverzeichnis V 6.9 Aktivierter Annotations-Modus ohne Darstellung der 3D Modelle Hinzufügen einer Notiz Symboldarstellung der Notizen Ergebnisse Nutzungsverhalten Mittlerer Bearbeitungserfolg jeder Aufgabe Verbessertes Menüsymbol Hinweise über Toasts zur Unterstützung der Benutzer

10 VI Tabellenverzeichnis 3.1 Funktionsumfang Anforderungen Ergebnisse der Software Untersuchung Bewertungsskala des Bearbeitungserfolgs

11 1 1 Einleitung 1.1 Motivation Augmented Reality (AR) ist eine Technologie zur Erweiterung der realen Umgebung mit computergenerierten Inhalten. Die Geschichte von AR reicht weit zurück. Bereits Sutherland [1968] entwickelte ein AR-System basierend auf einem Head-Mounted- Display (HMD). Anfang der 90er Jahre wurden aufgrund der fortschreitenden Computertechnologie immer neue Anwendungsfelder für AR entwickelt. Der in den vergangenen Jahren aufkommende Smartphone Boom hat zu einer rasanten Entwicklung auf dem Markt der mobilen Endgeräte geführt. Geräte in der Größe eines Mobiltelefons sind heutzutage ähnlich leistungsfähig wie gewöhnliche Computer. Aufgrund dieser Entwicklung erhält AR als mobile Anwendung Einzug in den alltäglichen Gebrauch. Mit Hilfe von AR lassen sich Informationen interaktiv und aus einer völlig neuen Perspektive vermitteln. Archäologie ist eines der Anwendungsgebiete, die durch AR Präsentationen profitieren können. Es liegt im Wesen der Archäologie, dass die durch eine Ausgrabung freigelegten künstlichen Strukturen und Objekte (Artefakte) unvollständig oder beschädigt sind. Im Rahmen der archäologischen Arbeit wird aus diesen unvollständigen Daten eine Rekonstruktion der Vergangenheit erstellt. Die meist raumbezogenen Ergebnisse dieser Rekonstruktion werden in Museen in Form von Plakaten oder Karten zweidimensional visuell kommuniziert. Aus Kostengründen wird auf eine, für den Menschen besser verständliche, Präsentation in der dritten Dimenson häufig verzichtet. Archäologieparks mit Rekonstruktionen von Gebäuden in Originalgröße sind selten und bedürfen zur Refinanzierung ein entsprechend hohes kulturelles Interesse. Häufiger werden Rekonstruktionen als maßstäbliche, plastische Modelle dargestellt. Zwar sind solche Modelle für die Besucher optisch ansprechend, können jedoch nur begrenzt zur Wissensvermittlung beitragen, da sie statisch und nicht interaktiv sind. Diese Lücke kann durch AR gefüllt werden. Neben der Visualisierung im, für den Besucher gewohnten, dreidimensionalen Raum besteht die Möglichkeit, mit den Inhalten zu interagieren. Durch die starke Verbreitung von Smartphones und Tablets ist die Infrastruktur für ein AR-System bereits bei den Nutzern selbst vorhanden. Dreidimensionale Inhalte, wie etwa Rekonstruktionen, zur Erweiterung von Karten oder den Ausgrabungsstätten selbst, sind durch die archäologische Arbeit in der Regel bereits vorhanden und können ohne größeren Aufwand verwendet werden. Für die Nutzer dieser Technologie ist somit ist eine einfache und kostengünstige Realisierung möglich.

12 1 Einleitung Zielsetzung In dieser Arbeit soll die Anwendbarkeit von AR in einem archäologischen Kontext untersucht werden. Dazu werden zunächst archäologische Inhalte, die für eine Visualiserung mit einem AR-System geeignet sind, identifiziert. In einem weiteren Schritt sollen in Zusammenarbeit mit Archäologen und Museums-Personal sinnvolle Methoden zur Visualisierung und Interaktion mit den AR-Inhalten ausgearbeitet werden. Neben den reinen Visualisierung von Inhalten sollen insbesondere auch Anwendungsszenarien für AR innerhalb der archäologischen Arbeit untersucht werden. Die ermittelten Anforderungen sollen anschließend zu einem Gesamtkonzept für eine AR-Anwendung zusammengefasst und in Form eines Prototypen auf Basis einer geeigneten mobilen Plattform implementiert werden. 1.3 Aufbau der Arbeit Die vorliegende Arbeit gliedert sich in acht Abschnitte. Nach dieser Einleitung behandelt Kapitel 2 neben den Grundlagen zu Augmented Reality auch das Thema Mobile Computing und die Einsatzzwecke von Karten innerhalb der Archäologie. In Kapitel 3 wird ein Konzept für ein archäologisches AR-System entwickelt und daraus die Anforderungen für eine mobile Anwendung abgeleitet. Im Anschluss werden verwandte Arbeiten vorgestellt und das eigene Konzept von diesen abgegrenzt. Die Entwurfsentscheidungen zur Entwicklung der Prototyp-Anwendung werden in Kapitel 4 vorgestellt. Neben der Auswahl einer geeigneten Hardwarebasis werden verschiedene Softwarepakete zur Entwicklung von AR-Anwendungen verglichen. Nachdem die Entscheidungen für eine mobile Plattform und die Softwarebasis getroffen sind, werden kurz die Besonderheiten der gewählten Software-Architektur vorgestellt. Kapitel 5 befasst sich mit der eigentlichen Implementierung der Anwendung. Es wird zunächst der allgemeine Programmaufbau vorgestellt und dann näher auf die technische Umsetzung der in Kapitel 3 festgelegten Funktionen eingegangen. In Kapitel 6 wird die entwickelte Anwendung vorgestellt. Zunächst wird die Konfiguration des Programmes und die Erstellung von neuen Markern beschrieben. Anschließend werden die einzelnen Funktionen und ihre Verwendung dargestellt. Die Gebrauchstauglichkeit der Anwendung wird in Kapitel 7 mit einer Evaluation untersucht. Aus den gewonnenen Erkenntnissen werden Maßnahmen zur Steigerung der Gebrauchstauglichkeit abgeleitet und anschließend umgesetzt. Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick über zukünftige Entwicklungsmöglichkeiten ab.

13 3 2 Grundlagen In diesem Kapitel wird auf die Grundlagen dieser Arbeit eingegangen. Es wird der Begriff Augmented Reality (AR) in Abgrenzung zur Virtual Reality erläutert und näher auf das Thema Mobile Computing eingegangen. Des Weiteren werden verschiedene Typen von archäologischen Karten vorgestellt und ihre Vor- sowie Nachteile gegenüber digitalen Datenbeständen dargestellt. 2.1 Augmented Reality Unter Augmented Reality bzw. Erweiterter Realität versteht man eine Anreicherung der realen Welt mit virtuellen Inhalten. Um AR gegenüber anderen Mixed Reality (MR) Technologien abzugrenzen, ist es sinnvoll das Mixed Reality Kontinuum nach Milgram u. a. [1994] zu betrachten. Mixed Reality Real Environment Augmented Reality (AR) Augmented Virtuality (AV) Virtual Environment Abbildung 2.1: Mixed Reality Kontinuum [Milgram und Kishino, 1994] Wie in Abbildung 2.1 zu erkennen ist, ordnet sich AR zwischen der vollständig realen Umgebung und Augmented Virtuality (AV) ein. AR unterscheidet sich von AV dadurch, dass es sich um eine Anreicherung mit überwiegend Realen Inhalten handelt. Bei AV wird dagegen eine Virtuelle Umgebung in Teilen mit Realen Objekten angereichert. Da es sich um ein Kontinuum handelt sind die Grenzen zwischen AR und AV jedoch fließend und nicht fest definierbar. Zur weiteren Definition von AR hat Azuma [1997] drei Charakteristiken aufgestellt, die jedes AR System erfüllen muss: 1. Kombiniert Real und Virtuell in der realen Umgebung 2. Interaktiv in Echtzeit 3. 3D Registrierung der virtuellen Objekte Dabei beschränkt sich die Kombination von Realem und Virtuellem nicht nur auf die visuelle Wahrnehmung. Auch eine Erweiterung der auditiven und taktilen Wahrnehmung ist denkbar. Ebenso umfasst es das Konzept, Teile der realen Umgebung auszublenden, bzw. durch virtuelle Objekte zu ersetzen.

14 2 Grundlagen Tracking Tracking bezeichnet die Bestimmung der Position und Orientierung von Objekten bzw. Nutzern im Raum und dient damit der räumlich konsistenten Darstellung zwischen realen und virtuellen Objekten. Für die Bestimmung der sechs Freiheitsgrade ( 3 Translationen, 3 Rotationen), welche auch als Pose bezeichnet werden, gibt es verschiedene Verfahren, die nach Rolland u. a. [2001] in sechs Klassen eingeteilt sind. Eines dieser Verfahren ist das optische Tracking, welches hier näher erklärt werden soll. Optisches Tracking Beim Optischen Tracking werden Videobilder mit Hilfe von Bildverarbeitungsalgorithmen ausgewertet, um die Pose zu bestimmen. Man unterscheidet weiter zwischen zwei Konfigurationen (Abb. 2.2). Bei der Outside-In Konfiguration bilden (mehrere) festinstallierte Kameras die Referenz und es wird die Pose von beweglichen Zielen bzw. Objekten zu dieser Referenz bestimmt. Im Fall der Inside-Out Konfiguration ist die Kamera selbst das Ziel, dessen Pose bestimmt werden soll, während ein Objekt als Referenz dient. Reference Target Target Reference (a) Outside In (b) Inside-Out Abbildung 2.2: Optisches Tracking [Rolland u. a., 2001] Um die Objekte in den Videobildern zu identifizieren, werden in der Regel planare Marker eingesetzt. Einfache Marker basieren dabei auf Schwarz-Weiß Codierungen, die selbst unter ungünstigen Lichtbedingungen noch gut identifiziert werden können. Bilder können ebenso als Marker verwendet werden, stellen aber höhere Anforderungen an die Rechenleistung und sind weniger robust gegenüber Umgebungsveränderungen Displays Um die Realität mit den virtuellen Objekten zu kombinieren wird ein Display benötig. In Kombination mit dem optischen Tracking bietet es sich an, eine Video Augmentierung zu wählen. Hierbei wird die Realität durch die Kamera erfasst und auf dem Bildschirm dargestellt. Mit Hilfe der aus dem Tracking bestimmten Pose lassen sich dann die virtuellen Objekte an der korrekten Position auf den Bildschirm

15 -32,1-64,6 110, ,4 5,4 4,1 3,2 277,3 2,1 5,1 0,8 15,2 68,1 2 Grundlagen 5 zeichnen. Man unterscheidet hier zwischen immersiven Displays, d.h Displays, die den Nutzer vollständig umgeben und nicht-immersiven Displays, die lediglich einen Auschnitt der Realen Welt zeigen. Zu ersten Klasse gehören z.b. Head-Mounted- Displays (HMD) während Smartphones und Tablets zur zweiten Kategorie gehören. Neben der Videoaugmentierung gibt es weitere Verfahren zur Darstellung der virtuellen Informationen, die in Milgram u. a. [1994] beschrieben sind. 2.2 Mobile Computing Zunehmend erhalten Mobile Computer in Form von Smartphones und Tablets Einzug in unseren Alltag. Aufgrund der stetig wachsenden Rechenleistung und der hohen Zahl an integrierten Sensoren sind solche Geräte besonders für AR Anwendungen geeignet. Eine Vielzahl von Herstellern bieten Geräte auf Basis unterschiedlicher mobiler Plattformen an, aber nur drei Plattformen scheinen sich zur Zeit durchzusetzen: Android, ios und Windows Phone (Abb. 2.3). Diese drei Mobilen Plattformen sollen an dieser Stelle näher betrachtet werden. Globaler Smartphonemarkt 2012 Verkäufe Q2'2012[%] Wachstum [%] Q2'12/Q2'11 Abbildung 2.3: Smartphone Markt 2012, Canalys Estimates Android Android ist ein von der Open Handset Alliance 1 unter Führung von Google entwickelte Plattform für mobile Endgeräte wie Smartphones oder Tablets. Android basiert auf dem Linux Kernel 2.6 und ist Open Source, d.h der Quelltext kann von jedem eingesehen und verändert werden. Für Gerätehersteller ist die Verwendung von Android kostenlos, weshalb es eine breite Auswahl an verschiedener 1

16 2 Grundlagen 6 Hardware mit Android Betriebssystem gibt. Eine Analyse des Unternehmens Staircase 2012 zeigt, das es zur Zeit etwa 4000 verschiedene Android-Geräte von 600 verschiedenen Herstellern gibt [OpenSignal, 2012]. Die zur Zeit aktuellste Version 4.1 des Android Betriebsystem nennt sich Jelly Bean und wurde im Juni 2012 veröffentlicht. Wie Abbildung 2.4 zeigt, ist die zur Zeit am stärksten verwendete Android Version Android 2.3 Gingerbread mit 56%, gefolgt von Android 4.0 Ice Cream Sandwich mit 24% und Android 2.2 Froyo mit 13%. Die neueste Version Jelly Bean ist mit 1,8% noch nicht stark verbreitet. Android 4.1 Jelly Bean Android 2.1 und älter Android 4.0 Ice Cream Sandwich Android 2.2 Froyo Android 3.0 Honeycomb Android 2.3 Gingerbread Abbildung 2.4: Verteilung Android Versionen, android.com Diese Fragmentierung, sowohl auf Betriebssystem-Ebene, als auch auf Hardware- Ebene macht es vor allem für Entwickler schwierig ihre Anwendungen auf jedem Android Gerät zu unterstützen ios ios ist ein mobiles Betriebssystem der Firma Apple und wurde 2007 zusammen mit dem ersten iphone veröffentlicht. Die aktuelle Version 6.0 wurde im September 2012 veröffentlicht. Da ios lediglich auf den Apple-eigenen Geräten verwendet wird, ist die Hardware-Fragmentierung gegenüber Android deutlich geringer. Zur Zeit wird ios auf folgenden Geräten eingesetzt: iphone ipad ipod touch Apple TV

17 2 Grundlagen 7 Für die Entwicklung von AR Anwendungen eignen sich aufgrund der Hardware (Kamera, GPS) lediglich das iphone und ipad. Unter Berücksichtigung aller Generationen von iphone und ipad reduziert sich die Zahl der Geräte mit unterschiedlicher Hardware damit auf neun, was eine Entwicklung mit Unterstützung aller Geräte einfacher macht. Nachteilig ist dagegen, dass Apple das offizielle ios Software Development Kit (SDK) nur für sein eigenes Desktop Betriebssystem Mac OS zur Verfügung stellt Windows Phone Das zur Zeit jüngste Betriebssystem für mobile Systeme stammt von Microsoft und nennt sich Windows Phone. Es ist der Nachfolger von Windows Mobile. Die aktuelle Version Windows Phone 7.5 Refresh wurde im Juni 2012 veröffentlicht. Von den bereits vorgestellten mobilen Plattformen besitzt Windows Phone zwar die geringsten Marktanteile, das Wachstum (Abb. 2.3) zeigt jedoch gegenüber allen anderen Wettbewerben noch ein starkes Entwicklungspotential aufgrund der hohen Nachfrage. Im Gegensatz zu Android ist die Verwendung von Windows Phone für die Gerätehersteller nicht kostenlos, was zu einer geringen Anzahl an verfügbaren Geräten führt.auch die Hardwarefragmentierung wird aufgrund fester Mindestanforderungen durch Microsoft verringert. 2.3 Archäologie Diese Arbeit beschäftigt sich mit der AR Visualisierung von archäologischen Daten. Daher soll hier ein kurzer Überblick über die archäologische Arbeit und die bei ihr entstehenden Daten gegeben werden. In den meisten Fällen handelt es sich bei archäologischen Daten um raumbezogene Daten. Die Präsentation dieser Daten erfolgt daher in der Regel mit Hilfe von ausgedruckten Papierkarten oder als digitale Karte innerhalb eines Geoinformationssystems (GIS). Papierkarten eignen sich optimal für ein optisches Tracking und bieten damit eine geeignete Alternative für eine AR-Visualisierung gegenüber einer direkten Erweiterung innerhalb der Landschaft. Die direkte Erweiterung einer Ausgrabungsstätte durch ein auf GPS und Neigungssensoren basierenden Tracking ist wegen der eingesetzten Lowcost-Sensoren fehleranfälliger und schränkt somit das Benutzererlebnis ein. Es sollen daher insbesondere die typischen Einsatzfelder von Karten innerhalb eines archäologischen Kontextes näher behandelt werden. Daneben sollen die Vorteile und Einschränkungen bei der Nutzung, sowohl von Papierkarten, als auch digitaler Repräsentationen, diskutiert werden Archäologische Ausgrabungen Betrachtet man den Prozess einer archäologischen Ausgrabung, von der Prospektion der Örtlichkeit, über die Freilegung, den wissenschaftlichen Befund, bis hin zur Präsentation der Fundstücke, so stellen Karten ein typisches Produkt oder Hilfsmittel

18 2 Grundlagen 8 dar. Abbildung 2.5 zeigt diesen Prozess in vereinfachter Form und die Produkte oder Hilfsmittel der einzelnen Arbeitsschritte. Prospektion Freilegung Interpretation Präsentation topogr. Karte Luftbild, Orthokarte Fundkarte Rekonstruktionen Museumskarten Abbildung 2.5: Archäologischer Ausgrabungsprozess und dessen Produkte Prospektion Unter Prospektion versteht man die Erkundung des Bodens nach archäologischen Stätten in einem lokal begrenzten Gebiet. Für die archäologische Prospektion stehen verschiedene, hauptsächlich bildgebende Verfahren zur Verfügung. So können mit Hilfe von Luftbildern, oder luftgestützten Laserscanneraufnahmen erstellte Karten einen ersten Eindruck über ober- oder unterirdische archäologische Strukturen liefern (Abb. 2.6). (a) Luftbild (b) Laserscanner Aufnahme Abbildung 2.6: Prospektion einer archäologischen Stätte durch Fernerkundungsmethoden [Bofinger u. a., 2007] Neben den luftgestützten Methoden gibt es auch bodengebundene Verfahren. Dazu gehören die klassische Geländeaufnahme durch Tachymetrie und GPS, oder Verfahren wie die geomagnetische Prospektion und das Bodenradar, die einen Einblick auf Gegenstände unter der Erde ermöglichen. Alle Verfahren haben gemein, dass als Produkt der Auswertung eine Karte mit möglichen Ausgrabungsstätten erzeugt wird.

19 2 Grundlagen 9 Freilegung Unter Freilegung wird die eigentliche Ausgrabung einer archäologischen Stätte verstanden. Werden archäologische Artefakte gefunden, muss der Fundort in einer Fundkarte dokumentiert werden. Daneben werden die lokalen, nicht beweglichen Gegebenheiten um den Fund, der sogenannte Befund, durch Kartierung, Fotografien, schriftliche Notizen, oder moderne Methoden wie terrestrisches Laserscanning dokumentiert. Eine Befundkarte ist in Abbildung 2.7 dargestellt. Diese Art der Dokumentation ist wichtig, da es sich bei dem Entfernen des Fundes vom Fundort um eine kontrollierte Zerstörung des Befundes handelt. Abbildung 2.7: Grabungskarte einer römischen Therme in Guissona, Spanien Interpretation Die bei der Freilegung gewonnenen Informationen über Funde und Befunde müssen anschließend wissenschaftlich interpretiert werden. Ein Teilgebiet dieser wissenschaftlichen Interpretation ist zum Beispiel die Rekonstruktion von Funden und Befunden. Rekonstruktionen können z.b. aus baulichen Überresten, in Form von vollständigen Grundrissen, oder ganzen Gebäuderekonstruktionen erstellt werden. Zusätzlich werden alle Funde datiert und ihre Herkunft bestimmt. Daraus lassen sich z.b. komplexe Handelsbeziehungen zwischen verschiedenen Kulturen ableiten.

20 2 Grundlagen 10 Präsentation Am Ende einer archäologischen Ausgrabung steht in der Regel die Präsentation der Funde in Museen oder der Ausgrabungsstätte selbst. Dazu werden die während des Prozesses gewonnenen Informationen aufbereitet und in einfacherer Form dargestellt. Dies kann zum Beispiel in Form von Karten der Ausgrabungsstelle, mit zusätzlichen Erklärungen, wie in Abbildung 2.8, dargestellt werden. Abbildung 2.8: Vereinfachte Museumskarte der römischen Therme Vorteile und Einschränkungen von Papier- und digitalen Karten Die im vorangegangenen Abschnitt vorgestellten Karten werden häufig als Papierkarten für die tägliche archäologische Arbeit genutzt. Während das Verhältnis von Papierkarten zu ihren digitalen Repräsentationen oft als konkurrierend angesehen wird, beschreibt Dymetman und Copperman [1998] das Verhältnis als komplementär. Dies zeichnet sich aus ihren Eigenschaften ab. Papierkarten sind permanent, das heißt ihr Inhalt ist fest und kann nicht verändert werden. Sie sind günstig herzustellen, leicht und damit einfach zu transportieren und erlauben bei einer entsprechenden Größe die Nutzung durch mehrere Personen. Digitale Karten sind dagegen dynamisch, können sich an die Bedürfnisse des Benutzers anpassen, animieren den Benutzer zur Interaktion und sind nicht auf eine 2D Darstellung beschränkt. Problematisch bei digitalen Karten ist die teure Infrastruktur und die damit einhergehende eingeschränkte Mobilität und nicht vorhandene Störungssicherheit. Digitale Karten könnten für die jeweiligen Nutzungsarten in der Archäologie durch ihre komplementären Eigenschaften Vorteile in der Verwendung bringen. Betrachtet

21 2 Grundlagen 11 man zum Beispiel die Museumskarten zur einfachen Präsentation von wissenschaftlichen Sachverhalten, so ist zunächst verständlich, warum diese als Papierkarten ausgelegt sind. Sie sollen den Museumsbesucher als eine Unterstützung bei dem Wissenserwerb dienen, dabei aber möglichst kostengünstig sein. Papierkarten sind damit im Sinne der Kommunikationstheorie ein Push-Medium, d.h. der Informationsgehalt wird vom Kartenersteller vorgegeben und bietet keine Möglichkeit, weitere Informationen zu erhalten. Digitale Karten könnten diese Wissensvermittlung durch ihre interaktive Komponente um das Pull-Prinzip erweitern. Die Nutzer könnten durch Interaktion mit der Karte weitere Informationen für die sie interessierenden Bereiche erhalten. Wissen könnte so wesentlich effizienter und attraktiver vermittelt werden. Gegen eine solche Anwendung von digitalen Karten sprechen die hohen Anschaffungskosten für die Anzeigegeräte. In den übrigen Anwendungsfeldern von Karten in der Archäologie hat sich die Verwendung digitaler Karten bereits durchgesetzt. Computer-Aided-Design (CAD) und GIS sind feste Bestandteile bei der Bearbeitung einer archäologischen Ausgrabung. Dennoch wird häufig auf Papierkarten zurückgegriffen. Diese bieten vor allem auf der Ausgrabungsstätte selbst eine einfachere Handhabung, da sie leicht und ausfallsicher sind.

22 12 3 Konzept und Anforderungen In diesem Kapitel soll das Konzept für eine AR Anwendung auf Basis archäologischer Karten entwickelt werden. Aus dem Konzept werden dann die Anforderungen für die Entwicklung abgeleitet. 3.1 Konzept Wie aus Kapitel 2.3 hervorgeht haben Papierkarten und elektronische Karten komplementäre Eigenschaften. Da Papierkarten in vielen Bereichen der Archäologie ein alltägliches Hilfsmittel darstellen, erscheint es sinnvoll ein AR System zu entwickeln, welches bei Bedarf dynamisch Informationen über diese Karten legen kann und erweiterte Interaktionsmöglichkeiten bietet. So können die Vorteile von digitalen Repräsentationen genutzt werden, ohne die vorhandenen Papierkarten und deren Vorzüge vollständig zu ersetzen und die damit einhergehenden Nachteile in Kauf nehmen zu müssen. Bevor die einzelnen Funktionen genauer spezifiziert werden können, sollten zunächst die Benutzergruppen der Anwendung eingegrenzt werden Zielgruppen Um die Umsetzung eines Prototypen in einem begrenzten Zeitrahmen zu ermöglichen sollen primär zwei Benutzergruppen von der Anwendung unterstüzt werden. Die erste Gruppe entspricht den nicht fachkundigen Kartennutzer. Dies können zum Beispiel Museumsbesucher sein, welche als Informationsmaterial zur Besichtigung einer archäologischen Ausgrabungsstätte eine Karte bekommen haben. Da die Besucher im Umgang mit archäologischen Karten wenig geübt sind, stellen die Museumskarten die Sachverhalte in der Regel stark vereinfacht dar. Für diese Zielgruppe ist daher die gezielte Darstellung von Zusatzinformationen sinnvoll. Die zweite Zielgruppe umfasst die fachkundigen Kartennutzer, also Wissenschaftler bzw. Archäologen. Diese Nutzergruppe ist im Umgang mit archäologischen Karten durch den täglichen Einsatz geübt und kann somit auch komplexere Sachverhalte aus den Karten erkennen. Die reine Darstellung von Zusatzinformationen zu Lehrzwecken ist hier also wenig sinnvoll. Hier werden viel mehr Funktionen benötigt, die typische Aufgabenstellungen im Umgang mit Karten auf einer Ausgrabungsstelle vereinfachen oder bisher nicht durchführbare Aufgaben ermöglichen. Die Präzisierung der umzusetzenden Funktionen für die Nutzergruppen erfolgt im nächsten Abschnitt.

23 3 Konzept und Anforderungen Funktionsumfang Die Programmfunktionen müssen sich an den Anforderungen der künftigen Anwender orientieren. Um dies zu gewährleisten ist eine Befragung dieser Anwender notwendig. Hierzu wurde in einem zweiwöchigen Spanienaufenthalt in Kooperation mit dem Institut de Geomatica 1 in Castelldefels und dem Institut Català d Arqueologia Clàssica 2 in Tarragona der Funktionsumfang erhoben. Die Ergebnisse dieser Recherche werden im Folgenden, nach den beiden Nutzergruppen gegliedert, näher erläutert. Nicht Fachkundige Nutzer Für die nicht fachkundigen Nutzer stehen Lehrzwecke im Vordergrund. Die Anwendung soll es dem Nutzer also ermöglichen die grundlegenden Strukturen auf einer archäologischen Karte einfacher zu interpretieren und weitere Informationen zu erhalten. Häufig stellen die Strukturen auf archäologischen Karten die Grundrisse von Gebäuden dar. Im Zuge der archäologischen Arbeit werden aus diesen Grundrissen in der Regel dreidimensionale Rekonstruktionen entwickelt. Diese 3D- Rekonstruktionen sind wesentlich anschaulicher als die zweidimensionalen Grundrisse und damit besser als Präsentation für nicht fachkundige Nutzer geeignet. Die erste Funktion für diese Nutzergruppe stellt somit die Visualisierung von 3D-Modellen dar. Um die Übersichtlichkeit zu wahren, sollte es die Möglichkeit geben, einzelne Modelle, nach dem Prinzip eines gewöhnlichen GIS, ein- bzw. auszublenden. Neben der reinen Visualisierung von 3D-Modellen soll es auch eine Möglichkeit geben, weitere Informationen zu diesen Modellen zu erhalten. Diese zusätzlichen Inhalte können Texte, Bilder, oder auch Videos sein. Fachkundige Nutzer Mit Hilfe der Recherche konnten für die fachkundigen Nutzer im wesentlichen zwei Anwendungen identifiziert werden. Zum einen das Hinzufügen von Inhalten in Form von Annotationen. Diese sind zwar auch auf klassischen Papierkarten möglich, haben aber mehrere Nachteile. Zum einen verändern sie den Karteninhalt in der Regel dauerhaft, d.h. sie sind irreversibel und zum anderen verdecken sie unter Umständen andere Bestandteile der Karte. Annotationen, die digital auf dem Gerät erstellt werden, können dagegen beliebig hinzugefügt, entfernt oder, um Verdeckungen zu vermeiden, ausgeblendet werden. Des Weiteren erlaubt eine Speicherung inklusive der Annotationsposition eine direkte Weiternutzung in anderen Systemen. Eine weitere Anwendung ist die generative Erstellung von Modellen, in diesem Fall speziell für römische Archäologie. Bei den Gesprächen mit den Archäologen stellte sich heraus, dass das Auffinden der Straßen in einer römischen Stadt oder Kolonie ein wichtiger Schritt zur Erschließung der gesamten Ausgrabungsstätte ist. Der typische römische Stadtbau basiert im Wesentlichen auf der Anlegung eines regelmäßigen Rasters, bei dem einzelne Häuserblöcke durch Straßen getrennt sind (Abb. 3.1)

24 3 Konzept und Anforderungen 14 Wenn also die Überreste einer römischen Straße gefunden werden, kann man unter Kenntnis der Straßenbreite und des Straßenabstandes die Ausgrabungsstätte gezielt nach Gebäuden untersuchen. Das Problem hierbei ist, dass die Straßenparameter zunächst keine bekannte Größe sind. Zwar verwendeten die Römer häufig standardisierte Größen in Römischen Fuß, diese konnten jedoch mangels Reproduzierbarkeit erheblich variieren. Auch topographische Gegebenheiten führten zu unterschiedlichen Straßenabständen in den römischen Siedlungen. Damit ist das Auffinden des Straßennetzes häufig ein iterativer Prozess. Zunächst werden Erkenntnisse vor Ort auf der Ausgrabungsstätte, etwa die topographischen Gegebenheiten, bereits freigelegte Straßenüberreste oder Gebäude, gesammelt. Daraus wird im Büro ein mögliches Modell für das Straßenmodell erzeugt, welches wiederum durch Grabungen verifiziert und sukzessive überarbeitet werden muss. Amphitheater C A R D O DECUMANUS Forum Abbildung 3.1: typischer Aufbau einer römischen Stadt Ließen sich die Straßenmodelle mit wenigen Schritten direkt vor Ort erzeugen und variieren, könnte dieser Prozess beschleunigt werden. Die Anwendung soll daher die

25 3 Konzept und Anforderungen 15 Erzeugung eines einfachen Gitter-Straßenmodells und dessen Variation unterstützen. Zusammenfassung Für beide Nutzergruppen ergibt sich somit ein Funktionsumfang von vier Grundfunktionen, die in Tabelle 3.1 zusammengefasst sind. Nutzergruppe nicht fachkundige Nutzer fachkundige Nutzer Funktion Darstellung von 3D Modellen in Ebenen Anzeige von Zusatzinformationen Annotation generatives Straßenmodell Tabelle 3.1: Funktionsumfang Die genaue Umsetzung der einzelnen Funktionen wird in Kapitel 5 näher erläutert. 3.2 Anforderungen Aus dem entwickelten Konzept und den Charakteristika eines AR-Systems nach Azuma (vgl. Kapitel 2.1) ergeben sich verschiedene Anforderungen an die zu nutzende Hard- und Software. Diese Anforderungen dienen als Grundlage für die Entwurfsentscheidungen und sind in Tabelle 3.2 dargestellt. Das Konzept sieht die Erweiterung von archäologischen Karten vor. Daher ist für das Tracking ein markerbasierter Ansatz zu wählen, der mit Hilfe einer Kamera die Pose des Gerätes gegenüber der Karte bestimmt. Neben der damit notwendigen Kamera sollte das mobile Gerät über ein hochauflösendes Display verfügen, um die erweiterten Inhalte ohne Qualitätseinbußen darstellen zu können. Um eine intuitive Interaktion mit den Inhalten zu ermöglichen, sollten Multi-Touch-Gesten, eine gleichzeitige Bedienung mit mehren Fingern, unterstützt werden. Der Prozessor (CPU) und die Grafikeinheit (GPU) müssen leistungsfähig genug sein, um das markerbasierte Tracking und die Darstellung komplexer Modelle nach dem Kriterium von Azuma (vgl. Kapitel 2.1) in naher Echtzeit zu realisieren. Um einen Einsatz der Anwendung über mehrere Stunden zu ermöglichen muss das Gerät über eine leistungsfähige Batterie verfügen, da das markerbasierte Tracking und die 3D Darstellung den Akkuverbrauch stark erhöhen. Damit das Gerät die Umwelteinflüsse auf einer Ausgrabungsstelle überstehen kann, sollte ein gewisser Schutz gegenüber Staub und Feuchtigkeit vorhanden sein. Auch die Lesbarkeit des Displays bei starker Sonneneinstrahlung spielt hier eine Rolle. Weitere Anforderungen ergeben sich für die zu verwendende Software. Da die Entwicklung eines eigenen Trackingalgorithmus zu zeitaufwendig ist, muss auf ein ferti-

26 3 Konzept und Anforderungen 16 Hardware Software Anforderung Ausstattung Leistung Outdoortauglichkeit Tracking Lizenz Datenformat Tabelle 3.2: Anforderungen Kamera Display Multitouch CPU GPU Batterie Staub Flüssigkeiten Displayheligkeit Geschwindigkeit Robustheit Kosten Weitergabe Verbreitung Erweiterbarkeit ges Softwarepaket zurückgegriffen werden, welches diese Funktion unterstüzt. Dabei sind vor allem die Geschwindigkeit und die Robustheit gegenüber äußeren Einflüssen, etwa Verdeckungen oder Lichtveränderungen, wichtige Kriterien. Die Lizenz der Software entscheidet darüber, ob sie kostenlos verwendet werden kann und ob weitere Auflagen einzuhalten sind. Die Inhalte, also 3D Modelle oder Texte sollten in standardisierten Formaten gespeichert sein. Hier ist von Vorteil, wenn Formate unterstützt werden, welche verbreitet und akzeptiert sind und die Möglichkeiten zur Erweiterung der Inhalte bieten. 3.3 Verwandte Arbeiten Die Verwendung von AR zur Erweiterung der Funktionalität von Papierkarten ist bereits seit längerem ein Forschungsthema. Auch die Nutzung von AR Techniken innerhalb eines archäologischen Kontexts wurde von verschiedenen Projekten untersucht. An dieser Stelle sollen kurz einige der Projekte, die sich mit Fragestellungen aus dem Bereich der AR für Papierkarten, oder Archäologie beschäftigen vorgestellt und zu der eigenen Arbeit abgegrenzt werden. Archeoguide Archeoguide (Augmented Reality based Cultural Heritage On-site GUIDE) ist ein von der EU finanziertes Projekt zur Entwicklung eines AR-Systems für Besucher einer archäologischen Ausgrabungsstätte [Vlahakis u. a., 2002]. Die Idee des Projektes ist, die Besucher mit einer mobilen Einheit bestehend aus einem transportablen Computer, einem HMD mit Kamera und GPS zur Navigation auszustatten. Dem

27 3 Konzept und Anforderungen 17 Besucher soll dann nach Eingabe seiner Interessen eine Route durch die Ausgrabungsstätte vorgeschlagen werden. Während des Rundgangs blendet das System über das HMD 3D Modelle von Monumenten ein (Abb. 3.2). Die Interaktion mit den Modellen ist über Zeigegesten realisiert, so dass der Besucher über eine AudioAusgabe weitere Informationen erhält, wenn er auf ein Objekt zeigt. (a) reale Umgebung (b) erweiterte Sicht Abbildung 3.2: Präsentation einer 3D Rekonstruktion durch Archeoguide [Vlahakis u. a., 2002] Augmented Maps Eines der ersten Systeme zur Erweiterung von Papierkarten mit Hilfe von ARTechniken wurde von Bobrich und Otto [2002] entwickelt. Augmented Maps nutzt ein optisches Tracking mit einfachen Markern, die auf der Papierkarte angebracht werden. Die Darstellung der 3D Information erfolgt über ein HMD. Um eine Interaktion mit den digitalen Inhalten zu ermöglichen, können weitere Marker in das Sichtfeld der Kamera geführt werden, die bei ihrere Erkennung vordefinierte Aktionen auslösen (Abb. 3.3). Da das Tracking über einen Computer berechnet wird, ist die Anwendung nur begrenzt mobil. (a) Augmented Maps Visualisierung (b) AR Zeiger Abbildung 3.3: Darstellung eines Geländemodells mit Augmented Maps [Bobrich und Otto, 2002]

28 3 Konzept und Anforderungen 18 Mobile Systeme stammen von Reilly u. a. [2006], die in der Papierkarte integrierte RFID-Chips für das Tracking verwenden, oder der auf optischen Markern basierte Ansatz von Schöning u. a. [2006]. Ein AR-System zur Unterstützung der Kartennutzung in der Sportbootfahrerei wird von Paelke und Sester [2010] beschrieben. Kwak [2004] und Schmalstieg und Wagner [2005] beschreiben mobile, markerbasierte Anwendungen für virtuelle Schnitzeljagden innerhalb von Museen. In Hall u. a. [2001] wird die grundsätzliche Anwendbarkeit von AR für Museums-Führungen untersucht. Bei den bisherigen Arbeiten handelt es sich hauptsächlich um Demonstrationen des technisch Machbaren. Die Verwendung von Laptops und HMD s macht eine praktische Verwendung unkomfortabel und teuer. Durch das hohe Gewicht wird die Akzeptanz bei den potentiellen Nutzern weiter geschwächt. Die mobilen Systeme verwenden zusätzliche Infrastruktur in Form von RFID-Chips oder einfachen Markern, die auf den Karten angebracht werden müssen. Die Arbeiten zu AR in der Archäologie betrachten lediglich die Zielgruppe der Museumsbesucher und beschränken sich auf die Präsentation von Inhalten. In dieser Arbeit soll eine Prototyp-Anwendung entwickelt werden, die neben der Präsentation von Inhalten auch die archäologische Arbeit selbst unterstüzt. Smartphones und Tablets haben sich im Massenmarkt etabliert. Durch die Verwendung einer solchen mobilen Plattform ist die kostengünstige, praktische Anwendbarkeit gewährleistet. Aufgrund der gestiegenen Leistungsfähigkeit der mobilen Hardware soll diese Arbeit, gegenüber den vorherigen Arbeiten, auf natürliche Merkmale anstelle von einfachen Markern für das Tracking zurückgreifen. Dadurch sind keine Veränderungen an den als Marker zu verwendenden Karten mehr notwendig, wodurch die Verwendung vereinfacht wird.

29 19 4 Entwurf In diesem Kapitel werden aus den Anforderungen die Entwurfsentscheidungen abgeleitet. Im Idealfall sollten die Entwurfsentscheidungen kapselbar sein, damit bei Änderungen nur einzelne Module betroffen sind und nicht das gesamte Programm. Zu Beginn muss sich für eine Plattform entschieden werden, da diese die gesamte folgende Entwicklung bestimmt. 4.1 Auswahl der Mobilen Plattform Mit Android, ios und Windows Phone stehen prinzipiell drei mobile Plattformen zur Auswahl. Bei dem umzusetzenden AR-System handelt es sich um ein nichtimmersives System. D.h. es wird lediglich ein kleines Fenster der realen Welt erweitert. Hierbei ist es sinnvoll ein großes Display zur Verfügung zu haben, um diesen Ausschnitt möglichst groß zu halten. Für Windows Phone ist dies bereits ein Ausschlußkriterium, da es lediglich auf Smartphones mit kleinen Bildschirmdiagonalen von 3-4 verfügbar ist. Android und ios erfüllen dagegen fast alle Anforderungen. Für beide Plattformen gibt es Geräte mit großem Bildschirm (Tablets), Kamera und schnellen Prozessoren. Problematisch bei ios ist die Tatsache, dass es keine outdoortauglichen Modelle gibt. Für Android sind dagegen mehrere Smartphones und Tablets verfügbar, die nach DIN EN Schutzarten von bis zu IP67 1 besitzen. Neben diesen harten Faktoren spielen für die Entscheidung auch weiche Faktoren eine Rolle. Unter die weichen Faktoren fallen zum Beispiel die Verbreitung der mobilen Plattform, um möglichst viele Nutzer zu erreichen. Außerdem bereits vorhandene Erfahrung mit einer mobilen Plattform, um den Entwicklungsaufwand gering zu halten, oder die Anschaffungskosten für ein Gerät. Auf dieser Grundlage fällt die Entscheidung zu Gunsten von Android aus. Zum einen besitzt Android gegenüber ios den größeren Marktanteil, zum anderen ist am Institut für Kartographie bereits ein Gerät in Form des Asus Transformer TF101 vorhanden. Daneben sind für den Arbeitseinsatz auf Ausgrabungsstätten Outdoor- Modelle verfügbar. Das Asus Transformer (Abbildung 4.1a) verfügt über einen Bildschirm mit 10 Diagonale und einer Auflösung von 1280*768 Pixel. Der Tegra2 Chip sorgt mit seinem 1.0GHz Doppelkernprozessor und einer zusätzlichen GPU sowie 1GB Arbeitsspeicher für ausreichend Rechenleistung. Die Kamera verfügt über eine Auflösung von 5 Megapixel. Des Weiteren bietet es durch GPS, elektronischem Kompass und Neigungssensoren die Möglichkeit weitere Trackingverfahren neben dem optischen Tracking zu realisieren. Als Betriebssystem kommt Android 4.0 ICS zum Einsatz. Um die 1 IP67 bezeichnet nach DIN EN den vollständigen Schutz gegen Staub und Schutz gegen zeitweiliges Untertauchen

30 4 Entwurf 20 (a) Transformer TF101 [Asus, 2012] (b) Galaxy Tab 7.7 [Samsung, 2012] Abbildung 4.1: Verwendete Entwicklungsplattformen. Kompatibilität der Anwendung bei unterschiedlicher Hardware zu gewährleisten, wird im späteren Entwicklungsverlauf zusätzlich das Galaxy Tab 7.7 von Samsung zur Entwicklung verwendet. Dieses verwendet mit dem Exynos 4210 Zweikernprozessor und der Mali-400GPU grundsätzlich andere Chipsätze als das Asus Transformer und eignet sich damit gut zur Kontrolle der Kompatibilität. 4.2 Auswahl Software Basis Für Android steht eine Vielzahl an Software zur Verfügung, die durch bereits implementierte Tracking Algorithmen eine einfache Umsetzung eines AR-Systems ermöglichen. Die drei ausichtsreichsten Softwarepakete sollen hier vorgestellt werden und anschließend hinsichtlich ihrer Eignung verglichen werden Metaio Mobile SDK Metaio ist ein Software Development Kit (SDK) der Firma metaio GmbH und steht sowohl für Android als auch für ios zur Verfügung. Es vereint verschiedene Tracking Möglichkeiten mit einem auf OpenGL basierenden 3D Rendering. Neben einem markerbasierten optischen Tracking besteht auch die Möglichkeit, die Kamerapose mit Hilfe der Gerätesensoren, etwa GPS und Kompass, zu bestimmen. Das proprietäre Framework ist kostenlos verwendbar, wenn das metaio Logo in der Anwendung angezeigt wird. Möchte man auf die Logos verzichten, müssen je nach Lizenz zwischen 5000 e bis e Gebühren gezahlt werden. Eine Besonderheit des Metaio Mobile SDK ist die Möglichkeit, beliebige 3D Objekte als Marker zu verwenden. Ein Stadtmodell als Beispiel ist in Abbildung 4.2 zu sehen. Zur Darstellung von 3D Modellen werden zwei unterschiedliche Datenformate unterstüzt. Zum einen das Wavefront- OBJ-Format, welches ein gängiges Format zur Speicherung von statischen Geometrien ist. Zum anderen das md2-format zur Speicherung von animierten Modellen.

31 4 Entwurf 21 Abbildung 4.2: Metaio Augmented City 3D Marker [Metaio, 2012]. Das Hinzufügen neuer Marker erfolgt einfach durch Konfiguration einer XML (Extensible Markup Language) Datei mit Angabe eines Bildes vom Marker im JPEGoder PNG-Format. Für das Erstellen eines 3D-Markers müssen Bilder des Objektes aus unterschiedlichen Perspektiven aufgenommen werden. Hierbei hilft jedoch eine zusätzliche Anwendung. Die zur Zeit aktuellste Version des Metaio Mobile SDK ist die Version OpenCV OpenCV (Open Source Computer Vision) ist eine ursprünglich von Intel und heute von Willow Garage entwickelte, freie Softwarebibliothek. Sie ist in C++ geschrieben und besitzt über 2500 optimierte Algorithmen zur Bildverarbeitung [OpenCV, 2012]. Für Android steht eine eigene Version zur Verfügung. Möchte man die OpenCV Funktionen in anderen Programmiersprachen als C++ verwenden, muss man sogenannte Wrapper, wie etwa JavaCV, verwenden. Da OpenCV nicht speziell auf AR Anwendungen ausgerichtet ist, muss selbständig ein Tracking Algorithmus auf Basis bereits implementierter Bildverarbeitungsalgorithmen, z.b mit Hilfe von SURF oder FAST, entwickelt werden. Da OpenCV als Open Source Software unter der BSD Lizenz steht, kann es sowohl für nicht kommerzielle als auch für kommerzielle Zwecke kostenlos verwendet werden. Die zur Zeit aktuellste Version für Android ist Vuforia Vuforia ist ein AR SDK des amerikanischen Telekommunikationsunternehmen Qualcomm. Es ist aus dem Qualcomm AR SDK (QCAR) hervorgegangen und aktuell in der Version 1.5.9, sowohl für ios als auch Android, verfügbar. Die Nutzungslizenz von Vuforia sieht keine Gebühren vor. Auch eine kommerzielle Nutzung ist

32 4 Entwurf 22 kostenlos. Die Erstellung neuer Marker stellt sich im Gegensatz zu dem Metaio SDK komplizierter dar. Zunächst muss ein Benutzerkonto für das Qualcomm Developer Network (QDevNet ) erstellt werden, mit dem man Zugriff auf das Target Managment System (TMS) erhält. Dort lassen sich Bilder hochladen und analysieren. Die Analyse zeigt die gefundenen Features, eine fünf Sterne Skala, die angibt wie gut das Bild sich als Marker eignet und gegebenenfalls Hinweise, wie man die Eignung verbessern kann (Abb. 4.3). Abbildung 4.3: Target Managment System Die Ergebnisse der Analyse sind jedoch nur Empfehlungen, das Bild lässt sich anschließend in jedem Fall als Marker nutzen. Nach der Analyse lassen sich die von Qualcomm als Target bzw. Trackable bezeichneten Marker in einem Binärformat, welches lediglich die extrahierten Features enthält, herunterladen und in die Anwendung integrieren. Neben einzelnen Markern können auch mehrere Bilder zu einem Multitarget zusammengefasst werden. Diese Multitargets erlauben somit die Erstellung einfacher 3D Marker, etwa von Würfeln oder rechteckigen Schachteln. Für beliebige 3D Marker, wie sie bei dem Metaio SDK möglich sind, eignet sich dieser Ansatz jedoch nicht Vergleich und Entscheidung Grundsätzlich eignen sich alle drei vorgestellten Softwarepakete mit ihrem theoretischen Funktionsumfang für die Umsetzung der AR Anwendung. An dieser Stelle soll daher die Praxistauglichkeit anhand mehrerer Kriterien verglichen werden. Die

33 4 Entwurf 23 ersten beiden Kriterien leiten sich aus den Anforderungen an die Software ab und betreffen die Geschwindigkeit und Robustheit des Trackings. Um diese Kritieren zu testen, wurde für jedes Softwarepaket eine topographische Karte der Asseburg als Marker definiert (Abb. 4.4). Abbildung 4.4: Topographische Karte der Asseburg [IKG, 2009] Diese Karte zeichnet sich durch feine Details und sehr große, weiße Flächen aus und besitzt damit die typischen Merkmale einer archäologischen Karte. Für die Trackingalgorithmen sind solche Marker besonders schwierig zu erkennen, da sie aufgrund der großen untexturierten Bereiche wenig Features enthalten. Neben dieser bereits anspruchsvollen Aufgabe wird des Weiteren untersucht, wie die einzelnen Trackingalgorithmen mit Verdeckungen des Markers umgehen. Hierfür wird der Marker einmal zu 20 % und einmal zu 50 % verdeckt Die Geschwindigkeit des Trackings und der Darstellung der 3D Inhalte sollte sich an die Bildwiederholfrequenz der Videokamera angleichen, die typischerweise bei 25 bzw. 30 Bildern pro Sekunde liegt, um eine für das menschliche Auge flüssige Wahrnehmung zu erreichen. Bei langsamen Bewegungen der Kamera können jedoch schon Bildwiederholraten von 15 Bildern pro Sekunde flüssig erscheinen. Da die verschiedenen Softwarepakete keine Möglichkeit bieten, die Bildwiederholfrequenz anzuzeigen, wird dieses Kriterium rein subjektiv als ausreichend oder nicht ausreichend bewertet. Um den Entwicklungsaufwand für diese Tests möglichst gering zu halten, wird lediglich der Marker in bereits vorhandene Beispielanwendungen integriert. Da OpenCV keine Beispielanwendung für markerbasiertes AR bietet, wird auf das Augmented Reality Markerless Support Kit (ARmsk) der schwedischen Firma Combitech 2 zurückgegriffen. Dieses Softwarepaket basiert auf OpenCV und bietet sich daher als Testgrundlage für die Eigenschaften einer OpenCV Implementierung an. 2

34 4 Entwurf 24 Die Ergebnisse der Untersuchung sind in Tabelle 4.1 mit Hilfe eines einfachen positiv/negativ Bewertungssystem aufgeführt. Metaio Vuforia OpenCV Geschwindigkeit % Verdeckung % Verdeckung Tabelle 4.1: Ergebnisse der Software Untersuchung Bei der Untersuchung zeigte vor allem die OpenCV Lösung Schwächen bei der Geschwindigkeit. Mit subjektiven Bildwiederholraten im unteren einstelligen Bereich ist die OpenCV-Lösung des ARmsk damit für den praktischen Einsatz unbrauchbar. Die Softwarepakete Metaio und Vuforia zeigten bei der Geschwindigkeit keine großen Unterschiede und wirkten beide flüssig. Ebenso können Metaio und Vuforia selbst mit größeren Verdeckungen noch eine Kamerapose bestimmen. Das Metaio SDK zeigt jedoch von Zeit zu Zeit, trotz fester Kamera und Marker, Bewegungen des 3D Objektes. Dies ist vermutlich auf die Filterung des Trackingergebnis zurückzuführen. Zwar lässt sich die Filterung in einem kleinen Bereich konfigurieren, aber vollständig verhindert werden kann das unerwünschte Verhalten damit nicht. Da dieses Verhalten bei einem anderen Marker mit vielen Features nicht auftritt, liegt die Vermutung nahe, dass die wenigen Features der Asseburg Karte hier neben der Filterung ebenfalls dieses Verhalten begünstigen. In der engeren Auswahl stehen aufgrund der Schwächen der OpenCV Umsetzung somit nur noch das Metaio SDK und Vuforia. Metaio hat besonders bei der Implementierung neuer Marker, als einfache Bilddateien und dem bereits implementierten GPS Tracking und 3D Markern als alternative Trackingmöglichkeiten Vorteile. Damit wäre die Erweiterung zum Beispiel von realen Ausgrabungsstellen, anstelle von Karten mit den selben 3D Inhalten ohne größeren Entwicklungsaufwand möglich. Negativ ist allerdings das Verhalten des optischen Trackings bei Markern mit wenigen Features, welches dem Konzept nach der Hauptanwendung entspricht. Vuforia dagegen zeigt keine Schwächen beim Tracking, aber das Hinzufügen neuer Marker gestaltet sich aufwendig. So ist man immer auf das TMS des QDevNet angewiesen und sollte Qualcomm diesen Service irgendwann beenden, ohne eine Alternative anzubieten, könnten keine neuen Marker mehr zur Anwendung hinzugefügt werden. Die Entscheidung fällt trotz der Schwäche bei der Markererstellung zugunsten von Vuforia aus. Ein einwandfreies Tracking ist im täglichen Gebrauch für die Akzeptanz einer AR Anwendung wichtiger, als das (einmalige) Erstellen eines Markers. 4.3 Software Architektur Mit der Wahl von Android als mobile Plattform und Vuforia als Software Basis ergeben sich einige Besonderheiten für die Entwicklung der Anwendung. Wie Abbildung 4.5 zeigt, besteht die Android System-Architektur aus fünf grundlegenden Komponenten. Die Abstraktionsstärke der einzelnen Schichten steigt dabei von unten nach oben an.

35 4 Entwurf 25 Abbildung 4.5: Android Systemarchitektur Linux Kernel Der Linux Kernel ist als Hardwareabstraktionsschicht die Verbindung zwischen Hardware und Software und bildet somit die Grundlage für das Android-System. Libraries Zu den Libraries gehören in C/C++ geschriebene Softwarebibliotheken. Diese Ebene kann auch als native Ebene bezeichnet werden, da sie mit C/C++ auf der Programmiersprache des Linuxkernels aufbaut. Google bietet zur Entwicklung auf nativer Ebene das Native Development Kit (NDK) an. Android Runtime Die Android Laufzeitumgebung besteht aus der Dalvik Virtual Machine (DVM) und den Core Libraries. Die DVM unterscheidet sich in ihrem Aufbau grundlegend zu gewöhnlichen Java Virtual Machines und ist für Hardwaresysteme mit geringem Speicherplatz optimiert [Mosemann und Kose, 2009]. Jede Android Anwendung wird in einer eigenen virtuellen Maschine ausgeführt um die Datensicherheit zu erhöhen. Die Core Libraries enthalten die wichtigsten Funktionen aus der Java Standard Edition. Application Framework Das Application Framework ist vollständig in Java geschrieben und damit das Pendant zu den in C++ geschriebenen Libraries. Es stellt mit seinen Funktionen und Schnittstellen zu den unteren Schichten die Grundlage für jede Android Anwendung dar. Zur Anwendungsentwicklung auf dieser Ebene steht das Android SDK zur Verfügung. Applications Die Anwendungsebene beinhaltet die auf dem Androidsystem installierten Anwendungen und stellt damit die stärkste Abstraktionsebene dar. Analog zur untersten Schicht, die die Verbindung zwischen Hard- und Software schafft, bildet die Anwendungsebene die Verbindung zwischen Software und Nutzer.

36 4 Entwurf Android SDK Das Android SDK liefert die Programmierschnittstellen (eng: application programming interface (API)) und Entwicklungstools um Anwendungen zu kompilieren, testen und zur Fehlerbeseitigung. Daneben werden etliche Beispielanwendungen geliefert, die typische Funktionen von Android näher erklären. Die Entwicklung mit dem Android SDK erfolgt in Java mit Hilfe der Eclipse Entwicklungsumgebung, aber der Aufbau einer Android Anwendung unterscheidet sich signifikant von der einer gewöhnlichen Java Anwendung. Eine Android Anwendung besteht aus verschiedenen Komponenten, die im folgenden näher erklärt werden sollen. Activity Eine Activity repräsentiert ein Benutzerinterface und kann zum Beispiel ein Auswahlmenü anzeigen und die damit verbundenen Interaktionen verwalten. Sie ist damit der Hauptbestandteil der Anwendung, die vom Benutzer wahrgenommen wird. Eine Anwendung kann prinzipiell aus mehreren Activities bestehen, aber nur eine kann jeweils aktiv sein. Layouts Layouts beschreiben die Struktur des Benutzerinterfaces einer Activity und enthalten alle Elemente, die für den Benutzer sichtbar sind. Layouts können auf zwei Weisen definiert werden, entweder über XML Dokumente fest vorgegeben, oder programmatisch zur Laufzeit des Programmes. Beide Möglichkeiten können auch zeitgleich verwendet werden, womit die Benutzeroberfläche nach einer Initialisierung durch Interaktion dynamisch verändert werden kann. Content Provider Content Provider dienen dem Zugriffsmanagment auf strukturierte Daten. Sie dienen damit als Interface zum Datenaustausch zwischen Anwendungen. Services Services sind Dienste die im Hintergrund laufen und keine eigene Benutzeroberfläche haben. Intent Intents sind asynchrone Nachrichten, die es Anwendungen erlauben Funktionalitäten von anderen Komponenten, etwa Activities oder Services anzufordern. Broadcast Receiver Soll eine Anwendung auf Intents einer anderen Anwendung reagieren können, so muss sie über einen Broadcast Receiver verfügen, der dies koordiniert. Android Manifest Jede Android Anwendung besitzt eine AndroidManifest.xml Datei. Innerhalb dieser Datei werden die von der Anwendung verwendeten Komponenten, also Services, Activities Content Provider und Broadcast Receivers beschrieben. Des Weiteren müssen hier die Berechtigungen der Anwendung festgelegt werden, um auf geschützte Bereiche der API zugreifen zu können. Dies umfasst unter anderem Zugriff auf das Internet, die SD-Karte und die Hardwaresensorik wie GPS Android NDK Das Android NDK ist eine Erweiterung des SDK, die es ermöglicht nativen, in C/C++ geschriebenen Code in die Android Anwendung zu integrieren. Diese Vorgehensweise bringt zwei Vorteile mit sich. Zum einen können die vielen in C/C++

37 4 Entwurf 27 entwickelten Softwarebibliotheken unter Android weiterverwendet werden. Zum anderen können die vorkompilierten C/C++ Bibliotheken bei rechenintensiven Aufgaben einen Geschwindigkeitsvorteil bis zu Faktor 10 gegenüber Java Implementierungen haben [Batyuk u. a., 2009]. Seit der Einführung des Just in Time (JIT) Compilers für die DVM mit der Android Version 2.2 und der damit verbundenen schnelleren Ausführung des Java Byte-Codes ist dieser Faktor jedoch geschrumpft Java Native Interface Um aus Java heraus nativen Code auszuführen existiert das Java Native Interface (JNI). Das JNI ermöglicht sowohl den Zugriff von Java aus auf C/C++ Funktionen, als auch den Zugriff von C/C++ auf Java Funktionen und Variablen. Nach Guihot [2012] sind für die Kombination von Java und C/C++ Code mit Hilfe von JNI sechs Schritte notwendig: 1. Deklaration der nativen Methode im Java Code 2. Implementierung des JNI Layers 3. Implementierung der nativen Methode in C/C++ 4. Erstellen der Android Makefiles 5. Kompilierung der nativen Bibliothek 6. Laden der nativen Bibliothek Dabei sind vor allem die ersten drei Punkte interessant, während sich die übrigen Punkte nur unwesentlich von der Erstellung einer gewöhnlichen C/C++ Anwendung unterscheiden. Diese drei Punkte werden daher im folgenden näher erläutert. Deklaration der nativen Methode im Java Code Um eine in C/C++ geschriebene Funktion in Java verwenden zu können, muss diese zunächst als native Funktion deklariert werden. Dies geschieht mit dem Prefix native und unterscheidet sich sonst nicht von einer gewöhnlichen Deklaration. 1 public native float addiere ( float a, float b); Listing 4.1: Deklaration der nativen Methode im Java Code Listing 4.1 zeigt eine solche Deklaration für eine einfache Funktion die zwei Zahlen addiert. Die Funktion ist damit unter Java bekannt und kann prinzipiell wie jede andere Java Funktion aufgerufen werden. Da bis jetzt aber keine Implementation auf nativer Ebene (C/C++) vorliegt, würde das Programm zur Laufzeit mit der Fehlermeldung UnsatisifiedLinkError abstürzen. Um die Java Deklaration mit einer C/C++ Implementierung zu verbinden ist als nächstes die Erstellung des JNI Layers notwendig. Implementierung des JNI Layers Der JNI Layer wird in C/C++ implementiert und dient als Verbindung zwischen dem Java und C/C++ Code. Listing 4.2 zeigt den entsprechenden Code für das Ad-

38 4 Entwurf 28 1 # include <jni.h> 2 3 JNIEXPORT jfloat JNICALL Java_com_JNIBeispiel_addiere 4 ( JNIenv * env, jobject obj, jfloat a, jfloat b) 5 { 6 return a+b; 7 } Listing 4.2: JNI Layer Code ditionsbeispiel. In diesem Beispiel sind die Schritte zwei und drei, also die Implementierung des JNI Layers und der eigentlichen nativen Funktion zusammengefasst. Nach dem Einbinden von JNI mittels #include <jni.h> wird der JNI Layer mit JNIEXPORT eingeleitet, gefolgt von dem Rückgabewert, den die in Java deklarierte Methode besitzt. JNI nutzt hier eigene Datentypen um die Konversion zwischen Java und C/C++ Datentypen zu ermöglichen. Im Falle eines floats ist dies einfach jfloat. Weitere Datentypen können in der JNI Dokumentation nachgeschlagen werden [JNI, 2012]. Anschließend kommt das Schlüsselwort JNICALL gefolgt von dem in Java deklarierten Funktionsnamen. Dem eigentlichen Funktionsnamen muss dabei der Java Package Name immer vorangestellt sein, der in diesem Beispiel Java_com_JNIBeispiel ist. Die Liste der Argumente beginnt immer mit zwei JNI Datentypen, JNIenv und jobject. Diese beiden Argumente spiegeln die JNI Umgebung selbst wieder und werden benötigt, wenn aus dem C/C++ Code heraus auf die JVM bzw. im Fall von Android auf die DVM zugegriffen werden muss. Dies wäre zum Beispiel der Fall, wenn aus C/C++ heraus eine Java Methode genutzt werden soll. In diesem Beispiel ist jedoch der genau umgekehrte Fall vorhanden, womit diese Argumente nicht weiter verwendet werden. Nach den beiden JNI Argumenten folgen die in der Javamethode deklarierten Argumente, jeweils mit dem passenden JNI Datentyp. Der Funktionsrumpf enthält dann die eigentliche Implementation der Addition, deren Ergebnis direkt mittels return zurückgeliefert wird. Nach der Kompilierung des C/C++ Codes kann nun auch die in Java deklarierte native Methode ohne Fehlermeldung ausgeführt werden OpenGL ES Open Graphics Library for Embedded Systems (OpenGL ES) ist eine freie API zur Erzeugung von 2-D und 3-D Grafik und eine vereinfachte Version von OpenGL, die für den Einsatz in mobilen Systemen wie Android optimiert ist. OpenGL ES wird von der Khronos Gruppe 3 entwickelt und ist zur Zeit in der Version 2.0 aktuell. 3

39 4 Entwurf 29 Rendering Vor der Version 2.0 unterstützte OpenGL ES lediglich eine Fixed Function Pipeline (FFP). Die FFP erzeugt aus einem im 3D-Raum gegebenen Objekt die entsprechende Projektion in den 2D-Raum mit Hilfe fest vorgegebener Rechenschritte. Abbildung 4.6 zeigt die grundlegenden Schritte einer FFP. Application Primitives & image data Vertex Transform & Lighting Geometry Primitive assembly Clipping Fragment Texturing Fog Framebuffer Alpha,stencil & depth test Framebuffer blending Abbildung 4.6: OpenGL ES Fixed Function Pipeline [Apple, 2012] Die einzelnen Vertices 4 durchlaufen dabei verschiedene Transformationen, bis sie schließlich als Fragment 5 bzw. Pixel auf den Bildschirm gezeichnet werden können. Die Arbeitsschritte der FFP können nur durch das Verändern verschiedener Parameter manipuliert werden, was eine Limitierung für die 3D-Grafikerzeugung darstellt. Daher wurde mit Open GL ES 2.0 die Open GL Shading Language (GLSL) eingeführt. Damit ist es möglich, die fest vorgegebenen Schritte für Vertices, Geometrie und Fragments durch eigene Programme, sogenannte Shader, zu ersetzen. Da Android seit der Version 2.2 Open GL ES in der Version 2.0 unterstüzt, wird für das Rendering auf diese Version gesetzt. Dies erfordert zwar durch die Shaderprogrammierung einen höheren Aufwand gegenüber fest vorgegebenen Funktionen, dieser hält sich aber bei der Implementierung einfacher Beleuchtungsmodelle in Grenzen und bietet gleichzeitig die Möglichkeit die Grafikdarstellung jederzeit weiter zu individualisieren. 4 Ein Vertex beschreibt einen Punkt im 3D-Raum und kann weitere Merkmale, z.b. eine Farbe besitzen 5 Als Fragment wird ein Pixel bezeichnet, der noch nicht auf dem Bildschirm gezeichnet wurde.

40 4 Entwurf VRML Für die Bereitstellung von 3D-Modellen stehen eine Vielzahl von Datenformaten zur Verfügung. Für die Entwicklung des Prototypen wird die Virtual Reality Modeling Language (VRML) verwendet. Es hat den Vorteil, dass es von vielen 3D- Bearbeitungsprogrammen unterstützt wird und somit auch die Möglichkeit besteht, andere Formate in das VRML Format zu konvertieren. VRML bietet neben der einfachen Speicherung von Geometrien in Form einer Baumstruktur auch die Möglichkeit Animationen durch die Grundoperationen Skalierung, Rotation und Translation zu realisieren. Materialeigenschaften wie etwa Farben oder Texturen können ebenso für jedes Objekt gespeichert werden. Für die Anzeige komplexer Geometrien mit Hilfe von Open GL ES 2.0 eignen sich in der Regel nur triangulierte Objekte, d.h. Objekte, welche aus mehreren Dreiecken zusammen gesetzt sind. Das VRML Format bietet zur Speicherung solcher Geometrien das sogenannte IndexedFaceSet. Dazu werden zunächst alle Punkte eines Objektes gespeichert und anschließend über Indizes die entsprechenden Verknüpfungen zu Dreiecken hergestellt. #VRML V2.0 utf8 Shape { geometry IndexedFaceSet { coord Coordinate { point [ ] } coordindex [ ] } } (a) VRML Format (b) gerendertes Dreieck Abbildung 4.7: Dreieck als Beispiel für das VRML Format Abbildung 4.7 zeigt die Struktur eines solchen IndexedFaceSet für ein einfaches Dreieck. Zunächst werden die drei Punkte des Dreiecks mit drei Koordinaten X, Y, Z im Bereich coord Coordinate als Punkte definiert. Die Reihenfolge, in der die Punkte vorgegeben werden, definiert auch ihren Index. Der erste Punkt bekommt automatisch den Index 0, die folgenden Punkte werden entsprechend fortlaufend indiziert. Die Definition als Dreieck erfolgt im Abschnitt coordindex. Hier werden für jedes zu zeichnende Dreieck jeweils die drei Eckpunkte in Form ihrer Indizes angegeben.

41 31 5 Implementierung In diesem Kapitel werden die einzelnen Funktionen und ihre Implementierung genauer vorgestellt. Abbildung 5.1 zeigt die grundlegenden Komponenten des Programmes. Mit Hilfe des TMS können verschiedene Karten als Marker erzeugt werden. Um mehrere Marker zeitgleich durch das Vuforia SDK tracken zu können, lassen sich diese als ein Dataset zusammenfassen. Das Vuforia SDK selbst kümmert sich lediglich um das Tracking der Marker und leitet die bestimmte Pose in Form einer Matrix an OpenGL weiter. Marker Target 0 n VRML Model Inhalte Config XML Info HTML Dataset Vuforia SDK OpenGL ES 2.0 Bildschirm Programm Abbildung 5.1: Programmkomponenten Damit OpenGL die Szene rendern kann, benötigt es Informationen über die Objekte und ihre Positionen auf der Karte. Die Verwaltung hierfür übernimmt eine zentrale Konfigurationsdatei, die es ermöglicht den verschiedenen Targets mehrere 3D-Modelle und ihre Position zuzuordnen. Die 3D-Modelle selbst liegen im VRML- Format vor. Daneben lassen sich zu jedem 3D-Modell zusätzliche Informationen in Form einer HTML-Datei verknüpfen. Mit den Informationen der Konfigurationsdatei kann OpenGL dann die Szene zeichnen und auf dem Bildschirm ausgeben.

42 5 Implementierung 32 Im Folgenden werden die einzelnen Komponenten und ihr Zusammenspiel anhand der in Kapitel 3 definierten Funktionen erläutert D Darstellung Um die 3D-Modelle darstellen zu können, bedarf es im Wesentlichen zweier Schritte. Zum einen müssen die im VRML-Format vorliegenden Geometrien für OpenGL aufbereitet werden, zum anderen muss ein Shader geschrieben werden, der eine Beleuchtung der Szene ermöglicht Datenstruktur Um das eigentliche Programm unabhängig von dem Format der 3D-Objekte zu entwickeln, wird die Klasse Model3D eingeführt. Diese Klasse repräsentiert ein 3D- Modell und speichert die hierfür notwendigen Daten, etwa den Namen, die Vertices, die Triangulation und Farben des Modells. Die Informationen hierfür werden durch die VRMLReader Klasse, die als Schnittstelle zu den VRML-Dateien dient, zur Verfügung gestellt. Dieser Aufbau ermöglicht ein späteres Ausstauschen des Datenformates, ohne dass tiefer greifende Veränderungen an den programminternen Abläufen notwendig sind. Neben den reinen Objektgeometrien ist auch eine Zuordnung der Modelle zu verschiedenen Markern notwendig. Hierzu wird eine Konfigurationsdatei eingeführt, die nach einem eigenen XML-Schema aufgebaut ist. Listing 5.1 zeigt den Aufbau dieser Konfigurationsdatei für ein Target mit zwei Modellen. 1 < TRACKABLES > 2 < TRACKABLE > 3 < TRACKABLENAME > Guissona </ TRACKABLENAME > 4 <MODEL > 5 < MODELNAME >tower. wrl </ MODELNAME > 6 <X> -5.0 </X> 7 <Y>35 </Y> 8 <Z>0.0 </Z> 9 <SCALE >1.7 </ SCALE > 10 </ MODEL > <MODEL > 13 < MODELNAME >house. wrl </ MODELNAME > 14 <X> </X> 15 <Y> </Y> 16 <Z>0.0 </Z> 17 <SCALE >0.2 </ SCALE > 18 </ MODEL > 19 </ TRACKABLE > 20 </ TRACKABLES > Listing 5.1: Aufbau der Konfigurationsdatei

43 5 Implementierung 33 Diese Datei liegt als config.xml im Hauptverzeichnis des Programmes auf dem internen Speicher, wodurch eine Konfiguration ohne Programmierkenntnisse vor dem Starten des Programmes möglich ist. Ein Marker, in der Konfigurationsdatei als Trackable bezeichnet, wird durch seinen eindeutigen Namen identifiziert. Dieser Name muss mit dem bei der Erstellung des Markers im Qualcomm TMS angegebenen übereinstimmen. Anschließend können beliebig viele Modelle einem Trackableabschnitt zugeordnet werden. Jedes Modell wird durch seinen Dateinamen, mit dem es auf dem internen Speicher liegt, identifiziert. Die Positionierung des Modells auf dem Marker erfolgt über die Tags X,Y,Z. Diese geben eine Translation des Modells, in der im TMS angegebenen Einheit, an. Das Koordinatensystem hat seinen Ursprung in der Mitte des Markers und die 3D Modelle werden bei ihrer Erzeugung als Model3D Objekte bereits in diese Position verschoben. Um die Modelle in ihrer Größe an den Marker anzupassen, gibt es den Skalierungsparameter Scale. Nach dem Starten der Anwendung wird für jedes in der Konfigurationsdatei angegebene Trackable ein Objekt vom Typ Target erzeugt. Jedes Target verfügt über einen Namen, die zugeordneten Modelle und ihre Translations- bzw. Skalierungsparameter. Stimmt ein vom Trackingalgorithmus gefundener Marker mit einem der Target Objekte überein, werden die verknüpften 3D Modelle mit ihren jeweiligen Parametern gerendert. Das Einlesen der Modelle als auch der Konfigurationsdatei wird aufgrund bereits vorhandener Routinen zum parsen von VRML- und XML-Formaten in Java realisiert. Das Tracking und Rendering wird aus Performance-Gründen jedoch auf nativer Ebene in C/C++ realisiert, braucht aber die in Java bereits vorhandenen Daten. Um dies zu ermöglichen werden die Objekte vom Typ Model3D und Target mit Hilfe von JNI in gleich aufgebaute Datentypen auf nativer Ebene gespiegelt. Durch dieses Vorgehen wird zwar potentiell die doppelte Menge an Arbeitsspeicher benötigt, das sollte bei den vorliegenden Datenmengen jedoch unkritisch sein. Vertex Normale und Farbe Für die Berechnung eines Beleuchtungsmodells benötigt man in OpenGL ES 2.0 für jedes Vertex eine Normale und eine Farbe. Sind diese nicht bereits in dem Modell definiert, müssen sie manuell berechnet werden. Da Normalen lediglich für Flächen mathematisch definiert sind, muss man für die Berechnung der Vertexnormale auf die Flächennormalen der anliegenden Dreiecke zurückgreifen. Hierfür gibt es verschiedene Methoden, von denen eine näher beschrieben und verwendet wird. Die Situation ist in Abbildung 5.2 verdeutlicht. Zunächst müssen die Flächennormalen der Dreiecke berechnet werden. Dabei ist zu beachten, dass für die spätere Beleuchtungsberechnung die nach Außen zeigende Normale benötigt wird. Dies kann über die Definition der Dreiecke in einer einheitlichen Punktreihenfolge gewährleistet werden. Für gewöhnlich wird eine Reihenfolge gegen den Uhrzeigersinn ( eng: counter clockwise - CCW) gewählt. Eine falsche Definition würde später zu vollständig schattiert (schwarzen) gerenderten Flächen führen. Zur korrekten Darstellung müsste die berechnete Normale dann negiert werden. Da die

44 5 Implementierung 34 Abbildung 5.2: Berechnung der Vertexnormale (rot) aus den angrenzenden Flächennormalen (blau) korrekte Dreieckdefinition aber in den Bereich der Modellerzeugung fällt, soll dies hier nicht weiter berücksichtigt werden. Die Vertexnormale berechnet sich dann als Mittelwert aller angrenzenden Flächennormalen. Aus Effizienzgründen wird die Vertexnormale zusammen mit der Vertexfarbe berechnet. Die Vorgehensweise für die Vertexfarbe ist analog zu der Berechnung der Vertexnormalen. Sie ergibt sich als Mittel aus allen angrenzenden Flächenfarben. Die Memberfunktion calculatevertexcolorandnormal() der Klasse Model3D implementiert diese Berechnungen. Da die Vertexnormale und Farbe nur für das spätere Rendering benötigt werden, ist die Funktion lediglich auf nativer Ebene in C/C++ realisiert Shader Um einen 3D Effekt zu erzeugen, ist die Berechnung von Schattierungen (eng: Shading) notwendig. Hierzu wird zum einen eine Lichtquelle benötigt, und zum anderen ein Reflexionsmodell für die 3D Objekte. Als Reflexionsmodell wird die diffuse Reflexion nach Lambert verwendet. Dabei wird das Licht vom Objekt in jede Richtung gleich stark reflektiert, die Position des Betrachters spielt also keine Rolle. Die Intensität des reflektierten Lichts ist abhängig von der Position der Lichtquelle zum reflektierenden Objekt, also vom Lichteinfallswinkel. Dieser Winkel ergibt sich aus der Oberflächennormale und der Richtung zur Lichtquelle (Abb. 5.3). Nach dem Lambertschen Kosinusgesetz ergibt sich die reflektierte Intensität damit zu I = I 0 cos(θ) Verwendet man für die Vertexnormale und den Richtungsvektor zur Lichtquelle normalisierte Vektoren, dann lässt sich der Intensitätsfaktor cos(θ) aus dem Skalarprodukt zwischen Vertexnormale N und dem Richtungsvektor zur Lichtquelle L bestimmen. Multipliziert man nun jeden Farbkanal mit diesem Faktor, erhält man die reflektierende Farbe und somit einen dreidimensionalen Eindruck vom Objekt. Listing 5.2 zeigt einen Vertex Shader, der dieses Reflextionsmodell als Gouraud Shading implementiert. Bei dem Gouraud Shading wird das Reflexionsmodell für jedes

45 5 Implementierung 35 Normale N L θ Abbildung 5.3: Lichteinfallswinkel Vertex berechnet und die resultierenden Vertexfarben anschließend vom Fragmentshader für jedes Pixel interpoliert. Dies bietet gegenüber dem Phong Shading, bei dem das Reflexionsmodell für jedes Pixel im Fragmentshader berechnet wird, deutliche Geschwindkeitsvorteile, kann aber an den Dreieckkanten zu Artefakten führen. 1 attribute vec4 vertexposition ; 2 attribute vec4 vertexnormal ; 3 attribute vec4 vertexcolor ; 4 5 varying vec4 color ; 6 7 uniform mat4 modelviewprojmatrix ; 8 9 void main () 10 { 11 gl_position = modelviewprojmatrix * vertexposition ; 12 vec3 lightpos = vec3 ( -1.0,1.0,1.0); 13 vec3 N = vec3 ( vertexnormal ); 14 vec4 V = modelviewprojectionmatrix * vertexposition ; 15 vec3 L = normalize ( lightpos - V. xyz ); 16 color = vertexcolor * vec4 ( max (0.1, dot (N, L ))); 17 } Listing 5.2: Vertex Shader für Gouraud Shading Dem Vertexshader werden zunächst die Eigenschaften der Vertices in Form von attribute Variablen übergeben. Dies sind neben der eigentlichen Vertexposition auch die Vertexnormale und die Vertexfarbe. Die später nach dem Reflexionsmodell berechnete Vertexfarbe wird in der Variable color vom Typ varying gespeichert. Varying-Variablen sind Variablen, die beim Übergang von Vertices zu Fragments für jedes Pixel interpoliert werden und somit das Konzept des Gouraud Shaders ermöglichen. Um die Vertices zu transformieren wird eine Projektionsmatrix übergeben. Für die perspektivisch transformierten Vertices hält OpenGL die Variable gl_position vor. Im Anschluss findet die eigentliche Berechnung des Reflexionsmodells statt. Zunächst wird das Beleuchtungsmodell in Form einer Punktlichtquelle mit einer festen

46 5 Implementierung 36 Position in der linken oberen Ecke der Szene definiert. Diese Lichtquelle ist fest an das Koordinatensystem des Markers gebunden und entspricht damit der in der Kartographie üblichen Beleuchtung aus Nord-West Richtung zur Erzeugung eines plastischen Eindrucks [Hake u. a., 2002]. Dann wird der Vektor L in Richtung der Lichtquelle berechnet und anschließend die Vertexfarbe als Produkt aus unbeleuchteter Vertexfarbe und dem Intensitätsfaktor aus dem Reflexionsmodell bestimmt. Hierbei ist anzumerken, dass der Intensitätsfaktor einen minimalen Wert von 0.1 annehmen kann. Objektbereiche, die nach dem Beleuchtungsmodell kein Licht reflektieren würden, erscheinen somit nicht exakt schwarz, sondern lediglich sehr verdunkelt. 1 precision mediump float ; 2 3 varying vec4 color ; 4 5 void main () 6 { 7 float red = color [ 0]; 8 float green = color [ 1]; 9 float blue = color [ 2]; 10 gl_fragcolor = vec4 (red, green,blue,0.0); 11 } Listing 5.3: Fragmentshader Der Fragmentshader (Listing 5.3) erhält die im Vertexshader berechneten Farbwerte der Vertices über die varying Variable color. Diese Farbe wird beim Übergang zum Fragmentshader automatisch von der GPU interpoliert für die einzelnen Pixel. Die einzige Aufgabe des Fragmentshaders ist somit, diese Farbe den Pixeln zuzuordnen. Dies geschieht über die OpenGL-eigene Variable gl_fragcolor. (a) ohne Shading (b) mit Shading Abbildung 5.4: Einfluss des Shading auf 3D-Eindruck Abbildung 5.4 zeigt den Einfluss des Shadings auf die dreidimensionale Wahrneh-

47 5 Implementierung 37 mung der Objekte. Beide Abbildungen zeigen das Rendering des selben Objektes, der einzige Unterschied ist die Verwendung des Intensitätsfaktors bei Abbildung b.) zur Manipulation des Farbwertes. Ohne Shading wirkt das einfarbige Objekt wie ein einfaches Polygon und ein dreidimensionaler Eindruck des Gebäudes fehlt völlig. Da im weiteren Verlauf der Entwicklung neben triangulierten Objekten auch Linien und Punkte gezeichnet werden sollen, die kein Shading benötigen, werden hierfür weitere einfachere Shader verwendet. Die einzelnen Shader werden in einem eigenen Ordner /shaders/ im Anwendungsverzeichnis als glsl Dateien gespeichert. Dieses Vorgehen ermöglicht später ein einfaches Austauschen der Shader ohne den Quellcode der Anwendung direkt verändern zu müssen. 5.2 Organistation in Ebenen Um trotz vieler 3D-Modelle die Visualisierung übersichtlich zu halten, ist die Organisation der Daten in Ebenen sinnvoll. Um einzelne Modelle einer Ebene zuzuordnen, wird die Konfigurationsdatei um den Eintrag LAYER erweitert. Dieser Eintrag muss lediglich einen Namen für die Ebene besitzen. Ein Modell kann dabei mehreren Ebenen, wie in Listing 5.4 zu sehen, zugeordnet werden. 1 < TRACKABLES > 2 < TRACKABLE > 3 < TRACKABLENAME > Guissona </ TRACKABLENAME > 4 <MODEL > 5 < MODELNAME >tower. wrl </ MODELNAME > 6 <X> -5.0 </X> 7 <Y>35 </Y> 8 <Z>0.0 </Z> 9 <SCALE >1.7 </ SCALE > 10 <LAYER >Alle Gebäude </ LAYER > 11 <LAYER >Turm </ LAYER > 12 </ MODEL > <MODEL > 15 < MODELNAME >house. wrl </ MODELNAME > 16 <X> </X> 17 <Y> </Y> 18 <Z>0.0 </Z> 19 <SCALE >0.2 </ SCALE > 20 <LAYER >Alle Gebäude </ LAYER > 21 <LAYER >Haus </ LAYER > 22 </ MODEL > 23 </ TRACKABLE > 24 </ TRACKABLES > Listing 5.4: Definition von Ebenen in der Konfigurationsdatei, hier: Alle Gebäude, Turm und Haus

48 5 Implementierung 38 Beim Auslesen der Konfigurationsdatei wird dann für jede auftretende Ebene ein Layer-Objekt innerhalb des zugehörigen Target-Objektes erzeugt. Jedes Layer-Objekt speichert neben den ihm zugeordneten Modellen auch seinen Status, also ob die Ebene für die Visualisierung aktiviert oder deaktiviert ist. Zu Beginn werden alle Ebenen als aktive Ebenen angelegt. Die grafische Benutzeroberfläche zur Auswahl der einzelnen Ebenen wird durch einen SlidingDrawer realisiert. Ein SlidingDrawer ist ein Menü, welches zunächst nicht sichtbar ist (Abb. 5.5a) und lediglich durch ein kleines Symbol am Rand des Bildschirms repräsentiert wird. Tippt der Benutzer auf das Symbol, oder zieht es nach Innen, wird das eigentliche Menü sichtbar (Abb. 5.5b). Durch die Verwendung einer solchen Benutzeroberfläche wird kein Platz für die eigentliche Visualisierung der Szene verschwendet, es ist aber dennoch möglich, schnell auf wichtige Funktionen zuzugreifen. Innerhalb des Menüs werden die einzelnen Ebenen mit ihren Namen und einer Checkbox dargestellt. Durch einen Klick auf die Checkbox kann für jede einzelne Ebene der Status verändert werden. (a) geschlossenes Menü (b) geöffnetes Menü Abbildung 5.5: Ebenen Auswahl über SlidingDrawer 5.3 Anzeige von Zusatzinformationen Neben der reinen Anzeige von Zusatzinformationen muss auch ein Interaktionsmechanismus implementiert werden, mit dem die Zusatzinformationen aufgerufen werden können. Das Konzept sieht vor, dass durch das Berühren eines 3D-Objektes auf dem Bildschirm beliebige Zusatzinformationen angezeigt werden. Dafür ist das Berechnen eines 3D-Punktes innerhalb der Szene aus den 2D-Koordinaten der Bildschirmberührung nötig, was häufig als Picking oder 3D-Selection bezeichnet wird. Zum Lösen dieser Problematik gibt es verschiedene Verfahren. Die 2D-Koordinaten der Bildschirmberührung spiegeln im 3D-Raum der Szene einen Strahl wieder. Man kann nun alle 3D-Objekte mit diesem Strahl schneiden und somit das Objekt finden, auf das getippt wurde. Nachteil dieser Methode ist, dass der Rechenaufwand bei Objekten mit vielen Dreiecken enorm steigt und die Berechnungen nur auf der CPU ausgeführt werden. Dies ist vor allem nachteilig, da die CPU durch das Tracking bereits stark beansprucht wird. Für diese Anwendung wurde deswegen ein Ansatz

49 5 Implementierung 39 verwendet, der im Prinzip keine Berechnungen auf der CPU benötigt, sondern auf OpenGL bzw. die GPU zurückgreift Color Picking Die grundlegende Idee des Color Picking ist durch Woo u. a. [1999] beschrieben. Zunächst wird die 3D-Szene im Falle einer Berührung neu gezeichnet. Anstelle der normalen Objektfarben mit Schattierungen wird dabei jedoch für jedes Objekt eine einzigartige Farbe verwendet und statt des Kamerabildes wird der Hintergrund schwarz gezeichnet (Abb. 5.6). (a) originale Szene (b) farbcodierte Szene Abbildung 5.6: Color Picking: Farbcodierung der Objekte Da der Benutzer diesen Vorgang nicht mitbekommen soll, darf die neue Szene nicht in den Frontbuffer der Grafikkarte gerendert werden, da dieser das Ergebnis immer auf dem Bildschirm zeigt. Stattdessen verwendet man ein Frame Buffer Object (FBO), das es ermöglicht eine gerenderte Szene zu speichern ohne sie auf dem Bildschirm zu zeigen. Um zu identifizieren, welches Objekt berührt wurde, wird dann die Farbe des berührten Pixels aus dem FBO gelesen. Da jedem Objekt zuvor eine einzigartige Farbe zugewiesen wurde, kann so umgekehrt über die Farbe des selektierten Pixels das Objekt ermittelt werden. Da für das Rendering der Farbmodus RGB888 verwendet wird, also für jeden der drei Farbkanäle Rot, Grün, Blau jeweils 8 Bit zur Verfügung stehen, ist es möglich bis zu verschiedene Farben und damit Objekte zu unterscheiden. Wird zusätzlich noch der Alpha Kanal (Transparenz) für die Kodierung verwendet, ließen sich über 4 Milliarden Objekte unterscheiden. Beide Grenzen sind aber nur theoretischer Natur, da die mobile GPU bereits viel früher an ihre Grenzen stößt und das Rendering nicht mehr flüssig ist. Der eigentliche Color Picking Algorithmus wird vollständig auf nativer Ebene implementiert. Bei Erstellung der 3D-Modelle auf nativer Ebene wird zunächst jedem Objekt eine eindeutige Farbe zugeordnet. Wird nun auf Java-Ebene eine Berührung registriert, werden die Koordinaten des berührten Pixels über JNI auf die native

50 5 Implementierung 40 Ebene weitergeleitet. Hier wird dann die Szene in den FBO gerendert, die Pixelfarbe am Berührungspunkt ausgelesen und mit den Modellfarben verglichen. Wurde ein Objekt getroffen, wird dessen ID wiederum über das JNI zurück an die Java-Ebene übermittelt. Auf Java-Ebene wird dann ermittelt, welche Zusatzinformationen angezeigt werden müssen und diese entsprechend dargestellt Darstellung der Zusatzinformation Für die Wiedergabe der Zusatzinformationen wird die Hypertext Markup Language (HTML) verwendet. Diese bietet die Möglichkeit sowohl Texte, Bilder als auch Videos strukturiert wiederzugeben. Außerdem bietet das Android SDK mit dem Webkit bereits einen HTML-Interpreter zur Darstellung von HTML-Inhalten, der einfach in eigene Anwendungen integriert werden kann. Um die Verknüpfung zwischen Modellen und Zusatzinformationen zu erreichen, wird wieder die Konfigurationsdatei verwendet. Der <MODEL> Abschnitt wird hierfür mit dem <INFO> Eintrag erweitert (Listing 5.5). 1 < TRACKABLES > 2 < TRACKABLE > 3 < TRACKABLENAME > Guissona </ TRACKABLENAME > 4 <MODEL > 5 < MODELNAME >tower. wrl </ MODELNAME > 6 <X> -5.0 </X> 7 <Y>35 </Y> 8 <Z>0.0 </Z> 9 <SCALE >1.7 </ SCALE > 10 <INFO >tower. html </ INFO > 11 </ MODEL > 12 </ TRACKABLE > 13 </ TRACKABLES > Listing 5.5: Konfigurationsdatei mit <INFO> Erweiterung Innerhalb des Info-Bereichs steht der Name einer HTML-Datei, in der die entsprechenden Informationen zum Objekt enthalten sind. Die HTML-Datei muss sich dabei im Ordner /html/ des Anwendungsverzeichnis befinden. Die eigentliche Anzeige der HTML-Seite erfolgt mit Hilfe des Android Webkits in einem WebView (Abb 5.7). Das WebView ist mit einer Auflösung von 400x400 Pixeln kompatibel zu den meisten Smartphone- und Tabletbildschirmen und bietet ausreichend Platz zur Anzeige von Text und Bildern. Da die Anwendung zur Nutzung der Internetverbindung des Gerätes berechtigt ist (vgl. Kapitel 4.3.1), können die anzuzeigenden Informationen auch zentral auf einem Server gelagert werden. Dadurch ist ein Austauschen der Inhalte ohne Veränderungen am Gerät möglich. Hierfür muss lediglich eine Webadresse, die mit oder www. beginnt, innerhalb des <INFO> Bereichs anstelle einer HTML-Datei angegeben werden.

51 5 Implementierung 41 Abbildung 5.7: WebView zur Anzeige von Zusatzinformationen 5.4 Generatives Straßenmodell Zur Erstellung und Veränderung eines Straßenmodells sind mehrere Schritte notwendig. Die Erstellung besteht im Wesentlichen aus zwei Schritten. Zunächst muss der Umriß der Stadt in Form eines Polygons definiert werden. Zwar entspricht das Idealbild einer römischen Siedlung einem Rechteck, aber topographische Bedingungen führten beim Städtebau häufig zu anderen Formen. Die Definition eines Umrisspolygons ermöglicht daher die Anpassung an jede beliebige Form. Anschließend müssen anhand eines Parametersatzes die Straßen innerhalb dieses Polygons erzeugt werden. Um das Straßenmodell in Echtzeit zu verändern, müssen nur noch die Parameter, z.b. durch Fingergesten, variiert werden Definition des Umrisses Da das Umrisspolygon als Erweiterung der Papierkarte anzusehen ist, muss es flach auf der Karte dargestellt werden. Zur Definition der Polygonpunkte soll der Touchscreen des mobilen Gerätes verwendet werden. Dieser liefert 2D-Koordinaten, benötigt werden jedoch die korrespondierenden 3D-Koordinaten auf der Papierkarte. Die 2D-Koordinaten der Berührung definieren jedoch einen Strahl in der 3D-Szene, der mit der Kartenfläche geschnitten werden kann, um so die korrespondierenden Koordinaten auf der Karte zu bestimmen. Der Strahl lässt sich aus dem OpenGL- Kamera-Koordinatensystem wie in Abbildung 5.8 herleiten. Das Koordinatensystem ist durch einen Standardwürfel mit einer Seitenlänge von 1 beschrieben, dessen Nullpunkt der Kameraposition entspricht. Die Z-Achse entspricht der Entfernung zur Kameraposition in Blickrichtung. Die Ebene mit einem Z-Wert von 0 wird auch als Near Clipping Plane bezeichnet und entspricht der Bildschirmebene. Die Ebene am anderen Ende des Würfels mit einem Z-Wert von 1 wird Far Clipping Plane genannt. Die beiden Punkte P0 und P1 des gesuchten Strahls befinden sich auf diesen Ebenen und unterscheiden sich somit nur in ihrem Z-Wert. Die

52 5 Implementierung 42 p1 p0 Z=1 Z=0 near clipping plane far clipping plane Abbildung 5.8: OpenGL-Kamera-Koordinatensystem [Katic, 2009] X- und Y-Werte sind durch den Berührungspunkt auf dem Bildschirm vorgegeben und in beiden Ebenen gleich. Um den Schnitt dieses Strahls mit der Kartenebene durchzuführen, muss der Strahl zunächst mit Hilfe der inversen Projektionsmatrix vom Kamerasystem in das Koordinatensystem der 3D Szene bzw. des Markers transformiert werden. Die Transformation und das Schneiden mit der Ebene erfolgen mit der Funktion transformscreencoord() auf nativer Ebene. Anschließend wird noch überprüft ob der Schnittpunkt innerhalb der Karte liegt. Sollte der Punkt innerhalb der Karte liegen, wird dieser dem Umrisspolygon als neuer Punkt hinzugefügt. Wenn die Erstellung des Umrisses abgeschlossen ist, werden die Straßen darin erstellt Straßengenerierung Die Straßen sollen als einfache Linien innerhalb des Umrisspolygons angezeigt werden. Als Parameter werden neben einer Translation des Straßennetzes auch der Abstand der Straßen zueinander und eine Rotation angesetzt. Die Straßengenerierung orientiert sich an dem Ablauf des römischen Stadtbaus und ist durch fünf Schritte implementiert (Abb. 5.9). Nach Definition der Stadtgrenzen (Umrisspolygon) wird der Mittelpunkt der Stadt definiert, der gleichzeitig der Schnittpunkt von zwei Hauptstraßen ist. Die Cardo ist typischerweise eine in Nord-Süd Richtung verlaufende Straße, während die Decumanus in Ost-West Richtung verläuft (vgl. Abb. 3.1, S.14). Die übrigen Straßen werden dann mit einem festen Abstand parallel zu Cardo und Decumanus gelegt.

53 5 Implementierung 43 (a) Umriss Definition (b) Berechnung des Zentrums (c) Cardo & Decumanus generieren (d) Nebenstraßen generieren (e) Clipping Abbildung 5.9: Fünf Schritte zum Straßennetz Als Startparameter für die Generierung wird die Translation zu Null gesetzt. Dadurch liegt der Schnittpunkt von Cardo und Decumanus zu Beginn im Zentrum des Umrisspolygons. Als nächster Schritt werden Cardo und Decumanus mit einem Rotationswinkel von 0 in dem gegebenen Schnittpunkt erzeugt. Anschließend werden parallel zu diesen Straßen die weiteren Straßen mit einem vorgegebenen Abstand erzeugt. Die erzeugten Straßen werden zunächst über den Rand des Umrisspolygons hinaus definiert und müssen anschließend durch einen geeigneten Clipping- Algorithmus auf den Innenbereich des Polygons beschränkt werden. Clipping Als Clipping wird das Abschneiden von Objekten am Rand eines Polygons bezeichnet. In diesem speziellen Fall müssen dabei Linien an einem Polygon abgeschnitten werden. Da das Umrisspolygon beliebig definiert werden kann, eignet sich nicht jeder Algorithmus für diese Aufgabe. Der Algorithmus von Cohen-Sutherland [Newman und Sproull, 1979] eignet sich beispielsweise nur für rechteckige Polygone. Aus diesem Grund wurde der Cyrus-Beck Algorithmus [Cyrus und Beck, 1978] verwendet. Dieser eignet sich für beliebige Polygone mit der Einschränkung, dass diese konvex sein müssen. Da sich die Umrisse einer römischen Stadt jedoch idealerweise an einem Rechteck orientieren und damit konvex sind, ist diese Einschränkung weniger kritisch. Der Algorithmus muss zwischen vier möglichen Fällen unterscheiden, die in Abbildung 5.10 dargestellt sind. Die zwei trivialen Fälle, bei denen die Linie vollständig im Polygon (grün) bzw. außerhalb des Polygons (rot) liegen erfordern kein Abschneiden

54 5 Implementierung 44 Abbildung 5.10: Vier Mögliche Konstellationen beim Linienclipping der Linie. Die Linien im Polygon können vollständig übernommen werden, während die Linien außerhalb des Polygons vollständig verworfen werden können. Für die anderen zwei Fälle müssen die Schnittpunkte mit dem Polygon berechnet werden. Bei einem n-eck können bis zu n Schnittpunkte existieren, jedoch sind maximal zwei davon tatsächlich Schnittpunkte mit dem Clip-Polygon (Abb. 5.11a). P i+1 B A v n i P i (a) n mögliche Schnittpunkte (b) Schnittgeometrie Abbildung 5.11: Linienclipping nach Cyrus-Beck Um die tatsächlichen Schnittpunkte zu ermitteln wird zunächst aus der Schnittgeometrie (Abb. 5.11b ) die Parameterform des Schnittpunktes hergeleitet, die zu Formel 5.1 führt. t = (A P i) n i v n i (5.1) Nach dieser Formel wird für jede Polygonkante ein Schnittpunkt mit der Straßenlinie berechnet. A beschreibt den Anfangspunkt der zu clippenden Linie während P i den Anfangspunkt der Polygonkante definiert. n i ist die nach Außen zeigende Normale der Polygonkante und v i = B A beschreibt die Richtung der zu clippenden Linie. Liegt der Parameter t außerhalb des Intervalls [0;1 ], also nicht zwischen dem Anfangs- und Endpunkt der Polygonkante, wird dieser Schnittpunkt verworfen. Sonderfälle, bei denen der Nenner Null wird, z.b. weil die zu clippende Linie parallel zur

55 5 Implementierung 45 Polygonkante verläuft, werden vorher abgefangen. Sind für die zu clippende Linie alle möglichen Schnittpunkte mit dem Polygon in Form des Parameters t bestimmt, werden diese nach zwei Typen klassifiziert. Verlässt die zu clippende Linie an dem Schnittpunkt das Polygon, wird sie als Leaving klassifiziert. Tritt die Linie an dem Punkt in das Polygon ein, wird sie als Entering klassifiziert. Mathematisch wird dies durch die Formeln 5.2 und 5.3 ausgedrückt. n i v > 0; t i t l i(leaving) (5.2) n i v < 0; t i t e i (Entering) (5.3) Damit die Parameter korrekt klassifiziert werden, muss die Normale n i der Polygonkante immer nach außen zeigen. Dies entspricht einem gegen den Uhrzeigersinn definierten Polygon und muss bei der Erstellung des Umrisspolygons entsprechend berücksichtigt werden. Sind alle t s für eine zu clippende Linie klassifiziert, lassen sich die tatsächlichen Schnittpunkte und damit die neuen Endpunkte der geclippten Linie bestimmen. Dazu wird das Maximum t e bzw. Minimum t l der beiden Klassen bestimmt. t e = max(t e i, 0) t l = min(t e i, 1) Falls t e > t l ist, liegt die zu clippende Linie vollständig außerhalb des Polygons und kann verworfen werden. Sonst definieren die beiden Parameter die neuen Endpunkte der zu clippenden Linie. Der Algorithmus wird dann für jede generierte Straßenlinie ausgeführt, um diese auf das Umrisspolygon zu begrenzen. Variation des Straßenmodells Das Straßenmodell soll durch Fingergesten manipulierbar sein. Die zu variierenden Parameter sind das Zentrum, also der Schnittpunkt von Decumanus und Cardo, sowie die Ausrichtung und der Abstand der Straßen zueinander. Es werden also drei verschiedene Fingergesten zur Manipulation des Straßennetzes benötigt. Android bietet zur Implementierung eigener Fingergesten sogenannte MotionEvents an. Tritt ein solches MotionEvent durch die Berührung des Bildschirms auf, wird die Methode ontouchevent(motionevent event) aufgerufen. Innerhalb dieser Methode kann dann die Berührung analysiert und entsprechend weiterverarbeitet werden. Ein MotionEvent ist immer einem bestimmten Typ zugeordnet. Die wichtigsten Typen sind ACTION_DOWN : Eine Geste wurde durch einen ersten Finger eingeleitet ACTION_POINTER_DOWN : Ein weiterer Finger wurde registriert

56 5 Implementierung 46 ACTION_MOVE : Eine Veränderung der Fingerposition(en) ist aufgetreten ACTION_POINTER_UP : Ein sekundärer Finger wurde wieder angehoben ACTION_UP : Die Geste wurde durch Anheben des primären Fingers beendet Das Verschieben des Zentrums soll über einfaches verschieben des Fingers auf dem Bildschirm erfolgen. Für diese Geste ist also ein MotionEvent vom Typ ACTI- ON_DOWN relevant, da hiermit die Geste eingeleitet wird. Die Bewegung des Fingers wird durch den Typ ACTION_MOVE erkannt und die Geste wird mit ACTION_UP wieder beendet. 2 public boolean ontouchevent ( MotionEvent event ) { 3 4 switch ( event. getactionmasked ()) { 5 case MotionEvent. ACTION_DOWN : { 6 movestartx = event. getx (); 7 movestarty = event. gety (); 8 break ; 9 } 10 case MotionEvent. ACTION_MOVE : { 11 movecenter (...); 12 movestartx = event. getx (); 13 movestarty = event. gety (); 14 } case MotionEvent. ACTION_UP : { 17 return true ; } 20 } 21 return false ; 22 } Listing 5.6: ontouchevent Methode für Translation Listing 5.6 zeigt eine ontouchevent Methode, die dieses Verhalten erkennen kann und den Schnittpunkt von Decumanus und Cardo entsprechend verschiebt. Die Fingerposition wird beim erstmaligen Berühren des Bildschirms in den Variablen movestartx bzw. movestarty gespeichert. Wenn eine Bewegung des Fingers erkannt wird und ein ACTION_MOVE Event auftritt, wird mit Hilfe der nativen Funktion movecenter() aus der gespeicherten Startposition und der aktuellen Position der Finger ein Translationsvektor berechnet, der auf nativer Ebene in das Koordinatensystem des Markers transformiert wird und auf die gespeicherte Zentrumsposition angebracht wird. Anschließend werden die Straßen mit dem veränderten Parameter neu generiert. Die aktuelle Fingerposition wird wiederum als Startposition für das nächste MotionEvent gespeichert. Das Verändern der Straßenrichtung und des Straßenabstandes soll mit Hilfe von Multitouchgesten erfolgen. Die Richtungsänderung soll dabei durch Drehen von zwei

57 5 Implementierung 47 Fingern auf dem Bildschirm erfolgen. Die Veränderung des Straßenabstandes soll durch das aufeinander zu- bzw. wegbewegen von zwei Fingern realisiert werden. Diese Geste wird auch als Pinch to Zoom bezeichnet. Die ontouchmethode muss hiefür lediglich um die Typen ACTION_POINTER _DOWN und ACTION_POINTER_UP erweitert werden, die bei ihrem Auftreten jeweils eine Bool-Variable setzen, um anzuzeigen, ob zwei Finger auf dem Bildschirm liegen. Tritt ein MotionEvent vom Typ ACTION_MOVE auf und es sind zwei Finger auf dem Bildschirm, wird aus den Startkoordinaten vor der Bewegung und den aktuellen Koordinaten beider Finger zum einen ein Winkel für die Rotation berechnet, zum anderen ein Skalierungsfaktor für den Straßenabstand. Da beide Gesten mit zwei Fingern durchgeführt werden, lassen sie sich auf diese Weise nicht unterscheiden. Somit werden immer beide Parameter, Richtung und Straßenabstand, zeitgleich verändert. Um das unabhängige Verändern dieser beiden Parameter zu ermöglichen, lassen sich beide Parameter über Checkboxen als unveränderlich festsetzen. 5.5 Annotationen Gemäß des Konzepts muss das Annotationsmodul drei grundlegende Funktionen unterstützen. Es müssen neue Notizen auf dem Marker bzw. der Karte erzeugt werden können. Bereits vorhandene Notizen sollen über ein Symbol visualisiert und bearbeitet werden können. Des Weiteren müssen erstellte Notizen wieder löschbar sein. Die Notizen werden durch die Datenstruktur Note repräsentiert. Eine Notiz besteht immer aus dem eigentlichen Notiztext, einer Position auf dem Marker, und einer einzigartigen Farbe zur Identifikation. Um die geforderten Funktionen umzusetzen, wird auf bereits implementierte Verfahren zurückgegriffen. Tritt im Annotationsmodus eine Berührung auf dem Bildschirm auf, wird mittels Color-Picking geprüft, ob ein Notizsymbol berührt wurde. Ist dies der Fall, öffnet sich die in Abbildung 5.12 dargestellte Notizansicht für die ausgewählte Notiz. Abbildung 5.12: Notizansicht zur Verwaltung der Notizen Die Notizansicht stellt das zentrale Element zur Verwaltung der Notizen dar. Neben der Darstellung des Notiztextes kann dieser auch editiert, gespeichert oder gelöscht werden. Das Erstellen neuer Notizen erfolgt ähnlich dem Aufrufen bereits vorhan-

58 5 Implementierung 48 dener Notizen. Stellt das Color-Picking fest, dass keine vorhandene Notiz berührt wurde, so wird aus der Berührungsposition ein Strahl in die 3D-Szene berechnet. Liegt der Schnittpunkt dieses Strahls mit der Marker-Ebene innerhalb der Kartenfläche, wird ein neues Notizobjekt im Schnittpunkt erzeugt. Gleichzeitig öffnet sich die Notizansicht, um das Hinzufügen des Notiztextes zu ermöglichen.

59 49 6 Programmdemonstration In diesem Kapitel wird die fertige Anwendung vorgestellt und die Verwendung der einzelnen Funktionen demonstriert. Dazu werden alle notwendigen Schritte, von der Erstellung eines Markers mit Hilfe des TMS, der Konfigurationsdatei und der Ordnerstruktur auf dem Gerät, bis hin zur Verwendung der Funktionen, mit Bildern verdeutlicht. 6.1 Konfiguration des Programmes Dieser Abschnitt behandelt die grundlegenden Schritte, um die Anwendung vor Inbetriebnahme korrekt zu konfigurieren Marker Erstellung Die Erstellung eines Markers erfolgt im TMS auf der Webseite https://ar.qualcomm. at/sdk. Da ein Zugriff nur für registrierte Benutzer möglich ist, können folgende Daten zum einloggen verwendet werden: Passwort: ARACmap2012 Nach dem Einloggen besteht die Möglichkeit unter My Trackables den Prozess zur Erstellung eines Markers zu starten. Zunächst wird man aufgefordert, ein neues Projekt zu erstellen. Innerhalb eines Projektes können beliebig viele Marker verwaltet werden. Nach Erstellung des Projektes lässt sich über die Verknüpfung Create a trackable ein Marker zu dem Projekt hinzufügen. Im darauf folgenden Schritt muss Abbildung 6.1: Konfiguration des Markers im TMS

60 6 Programmdemonstration 50 ein Name für den Marker, der Typ und die Größe angegeben werden (Abb. 6.1). Der Name identifiziert den Marker später in der Anwendung eindeutig. Als Markertyp werden von der Anwendung lediglich einzelne Bilder (Single Image) unterstüzt. Die Angabe der Markerbreite beeinflusst später das Koordinatensystem des Markers. Hier ist es sinnvoll, die Blattgröße der Karte, etwa in Millimetern, anzugeben. Anschließend muss der Marker in Form einer Bilddatei hochgeladen werden. Danach muss man zurück zur Projektansicht wechseln, in der jetzt der neu erstellte Marker auftaucht. Dieser kann selektiert und anschließend heruntergeladen werden (Abb. 6.2). Abbildung 6.2: Marker Download Es können auch mehrere Marker in einem Projekt selektiert und heruntergeladen werden. Dies ermöglicht es der Anwendung später, automatisch zwischen den Markern unterscheiden zu können oder mehrere Marker zur selben Zeit zu augmentieren. Bei der heruntergeladenen Datei handelt es sich um eine komprimierte Datei vom Typ *.zip. Diese enthält sowohl eine XML-Datei, in der die Markerkonfiguration gespeichert ist, als auch eine Datei im Binärformat, die die Features des Markers enthält. Beide Dateien bilden ein Datenset und müssen unkomprimiert auf den Speicher des mobilen Gerätes in den Ordner /ARMaps/datasets/ kopiert werden. Die für diese Demonstration verwendete Karte der Ausgrabungsstätte Guissona in Spanien befindet sich in digitaler Form auf dem beigefügten Datenträger und kann zum Testen der Anwendung verwendet werden Konfigurationsdatei Die Konfigurationsdatei liegt im Hauptverzeichnis der Anwendung /ARMaps/ und trägt den Namen config.xml. Soll ein Marker in der Konfigurationsdatei hinzugefügt werden, so muss mit dem im TMS vergebenen Namen, bzw. den Dateinamen der zwei generierten Markerdateien, ein neuer <TRACKABLE> Bereich erzeugt werden. Die in der Konfigurationsdatei verknüpften 3D-Modelle müssen sich ebenfalls in dem Hauptverzeichnis der Anwendung /ARMaps/ befinden. In Listing 6.1 ist eine vollständige Konfigurationsdatei für den im vorherigen Schritt erstellten Marker dargestellt. Insgesamt werden in diesem Beispiel drei 3D-Modelle auf den Marker augmentiert. Neben der Positionierung und Skalierung werden diesen Modellen auch weitere Informationen durch die Verknüpfung mit HTML-Dateien hinzugefügt.

61 6 Programmdemonstration 51 1 <? xml version = 1.0 encoding = UTF -8 standalone = yes?> 2 < TRACKABLES > 3 < TRACKABLE > 4 < TRACKABLENAME > Guissona </ TRACKABLENAME > 5 <MODEL > 6 < MODELNAME >tower. wrl </ MODELNAME > 7 <X> -5.0 </X> 8 <Y>35 </Y> 9 <Z>0.0 </Z> 10 <SCALE >1.7 </ SCALE > 11 <INFO >tower. html </ INFO > 12 <LAYER >Alle Gebäude </ LAYER > 13 <LAYER >Turm </ LAYER > 14 </ MODEL > 15 <MODEL > 16 < MODELNAME >house. wrl </ MODELNAME > 17 <X> </X> 18 <Y> </Y> 19 <Z>0.0 </Z> 20 <SCALE >0.2 </ SCALE > 21 <INFO >bath. html </ INFO > 22 <LAYER >Alle Gebäude </ LAYER > 23 <LAYER >Therme </ LAYER > 24 </ MODEL > 25 <MODEL > 26 < MODELNAME >Roman1. wrl </ MODELNAME > 27 <X>700 </X> 28 <Y> -400 </Y> 29 <Z>0.0 </Z> 30 <SCALE >0.08 </ SCALE > 31 <INFO >house. html </ INFO > 32 <LAYER >Alle Gebäude </ LAYER > 33 <LAYER >Haus </ LAYER > 34 </ MODEL > 35 </ TRACKABLE > 36 </ TRACKABLES > Listing 6.1: vollständige Konfigurationsdatei Die im <INFO> Abschnitt angegebenen Dateien müssen sich zur korrekten Anzeige im Verzeichnis /ARMaps/html/ befinden. Zusätzlich wird jedes Modell in zwei Ebenen dargestellt. Alle erfordelichen Dateien und Verzeichnisse befinden sich auch auf dem beigelegten Datenträger. Die Konfiguration der Anwendung ist damit abgeschlossen und die Anwendung kann gestartet werden.

62 6 Programmdemonstration ARAC Maps Die entwickelte Anwendung wird im weiteren Verlauf als ARAC Maps bezeichnet. Dieses Akronym steht für Augmented Reality for Archeological Content on Maps und spielt damit auf das Hauptanwendungsgebiet des Programmes, der Erweiterung von Papierkarten mit archäologischen Daten, an Programmstart Beim Programmstart wird zunächst ein einfaches Startlogo angezeigt (Abb. 6.3). Dieser Startbildschirm erfüllt zwei Aufgaben. Bevor das eigentliche Kamerabild auf dem Bildschirm angezeigt wird, werden alle notwendigen Daten, etwa die Marker, 3D-Modelle und die Konfigurationsdatei in den Arbeitsspeicher geladen. Da dieser Vorgang einige Zeit in Anspruch nimmt und deshalb keine grafischen Ausgaben oder Benutzereingaben möglich sind, dient das Startlogo während dieser Zeit als ein Ladebildschirm. Abbildung 6.3: Startlogo von ARAC Maps Des Weiteren legen die Lizenzbedingungen des Vuforia SDK dem Entwickler nahe, bei Veröffentlichung der Anwendung, die Verwendung des SDK durch die Anbringung des Vuforia Logos zu kennzeichnen. Dieses Logo wird daher im Startbildschirm angezeigt, um die Lizenzbedingungen zu erfülllen. Nachdem alle notwendigen Daten geladen wurden, wird der Startbildschirm durch das Kamerabild ersetzt. Ab diesem Zeitpunkt ist bereits das Tracking aktiv und es wird nach einem Marker im Bild gesucht. Wurden bei der Konfiguration mehrere

63 6 Programmdemonstration 53 Datensets auf das Gerät geladen, so kann über die Android Menütaste ( ) und den Eintrag Switch Datasets das Datenset gewechselt werden (Abb. 6.4). Abbildung 6.4: Menü zum Wechseln des Marker-Datensets Darstellung der 3D Modelle Sobald ein Marker des momentan aktiven Datensets im Kamerabild erkannt wird, beginnt das Rendering der in der Konfigurationsdatei zugeordneten 3D-Modelle. Am rechten Bildschirmrand befindet sich der Knopf zum Öffnen des Hauptmenüs. In diesem Menü befindet sich die Anzeige und Auswahl der verschiedenen Ebenen, (a) Alle Ebenen aktiviert (b) Eine Ebene Aktiviert Abbildung 6.5: Hauptmenü mit Ebenenauswahl und erweiterten Funktionen sowie die Möglichkeit, auf die erweiterten Funktionen, wie die Notizfunktion, zuzugreifen (Abb. 6.5). Objekte, die zu nicht ausgewählten Ebenen gehören, werden entsprechend nicht gerendert. Über den verfügbaren Ebenen ist eine Auswahlbox

64 6 Programmdemonstration 54 für den Marker. Werden mehrere Marker gleichzeitig getrackt, kann hierüber die Ebenenauswahl des gewünschten Markers angezeigt werden Anzeige von Zusatzinformationen Um die in der Konfigurationsdatei hinterlegten Webseiten mit Zusatzinformationen anzuzeigen, genügt es, ein Modell mit dem Finger anzuklicken. Die verknüpfte Webseite des angeklickten Modells öffnet sich dann in einem WebView der sich in der Mitte des Bildschirms befindet (Abb. 6.6). Abbildung 6.6: Darstellung der verknüpften Zusatzinformation Zum Schließen der Informationsansicht befindet sich am oberen rechten Rand des WebViews der Knopf Close X Straßengenerierung Über den Knopf Activate Streetmode im ausklappbarem Hauptmenü der Anwendung lässt sich der Straßenmodus starten. Sobald der Straßenmodus gestartet ist, erscheint ein neuer Knopf Create New Boundary, um mit der Definition des Stadtumrißes zu beginnen (Abb. 6.7a). Wird dieser aktiviert, können über einfaches Antippen des Bildschirms neue Punkte zum Umrißpolygon hinzugefügt werden (Abb. 6.7b). Wurden mindestens drei Punkte definiert und ein geschlossenes Polygon wird auf der Karte dargestellt, kann die Umrißerzeugung über den Knopf Finish Boundary beendet werden (Abb. 6.7c). Nach dem Beenden werden direkt Straßen innerhalb dieses Polygons erzeugt (Abb. 6.7d). Das erzeugte Straßennetz ist zunächst recht fein strukturiert. Um das Straßennetz zu manipulieren eignen sich die in Abschnitt beschriebenen Fingergesten. Abbildung 6.8 zeigt ein gedrehtes Straßennetz mit verschobenem Zentrum und verändertem Straßenabstand. Am unteren Rand des Bildschirms sind die zwei Checkboxen zum Festsetzen der Parameter Rotation und

65 6 Programmdemonstration 55 (a) Straßenmodus aktiviert (b) Erste Kante definiert (c) Umriß vollständig definiert (d) Straßen generiert Abbildung 6.7: Prozess der Straßengenerierung Abbildung 6.8: Verändertes Straßennetz

66 6 Programmdemonstration 56 der Straßenabstände zu erkennen, die ein Verändern dieser Parameter unabhängig voneinander ermöglichen Annotationen Der Annotations-Modus wird genauso wie die Straßengenerierung über das seitliche Hauptmenü gestartet. Im aktivierten Zustand werden keine 3D-Modelle gerendert, um die gesamte Markerfläche für Notizen verwenden zu können (Abb. 6.9). Abbildung 6.9: Aktivierter Annotations-Modus ohne Darstellung der 3D Modelle Das Hinzufügen einer Notiz erfolgt durch einfaches Antippen des Bildschirms im Bereich der Markerfläche. Es erscheint dann die Notizansicht und eine Bildschirmtastatur, um den Notiztext einzugeben (Abb. 6.10). Neben der Möglichkeit, die Abbildung 6.10: Hinzufügen einer Notiz

67 6 Programmdemonstration 57 Notizansicht zu schließen, kann man die aktuell dargestellte Notiz bei Veränderungen abspeichern oder wieder löschen. Ist die Detailansicht für Notizen nicht aktiv, werden alle Notizen, wie in Abbildung 6.11 dargestellt, durch ein farbiges Quadrat symbolisiert. Abbildung 6.11: Symboldarstellung der Notizen Über den Menüeintrag Deactivate Annotation Mode kann der Annotations-Modus wieder verlassen und zur Darstellung der 3D-Modelle zurück gewechselt werden.

68 58 7 Evaluation Die Evaluation der Anwendung hinsichtlich ihrer Gebrauchstauglichkeit (eng: Usability) stellt einen wichtigen Schritt zur Sicherstellung eines benutzerfreundlichen Designs dar. In der ISO Norm 9241 sind drei Leitkriterien als Anforderungen an die Gebrauchstauglichkeit definiert: Effektivität zur Lösung einer Aufgabe Effizienz der Handhabung des Systems Zufriedenheit der Nutzer einer Software Um die Gebrauchstauglichkeit der entwickelten Anwendung empirisch zu untersuchen, wird die Anwendung von einer Gruppe von Testpersonen mit klar definierten Aufgaben benutzt. Aus dem Verhalten der Testnutzer können dann Rückschlüsse auf die Gebrauchstauglichkeit gezogen werden. In den folgenden Abschnitten wird der Aufbau des Tests vorgestellt und die Ergebnisse präsentiert. 7.1 Testaufbau Der in dieser Arbeit verwendete Usability-Test verwendet drei Methoden um die Gebrauchstauglichkeit zu messen. Während die Anwendung von der Testperson zur Bearbeitung der Aufgabenstellung genutzt wird, werden durch die Software im Hintergrund Daten zum Nutzungsverhalten für jede Aufgabe aufgezeichnet und gespeichert. Diese Daten dienen später dazu, die Effizienz objektiv zu bestimmen. Nach Beendigung jeder Aufgabe wird durch den Testleiter der Bearbeitungserfolg bewertert. Dies liefert später eine einfache Kennzahl für die Effektivität der verschiedenen, getesteten Funktionen der Anwendung. Am Ende des gesamten Tests wird die Zufriedenheit der Nutzer mit Hilfe eines Fragebogens untersucht Aufgabenstellung Die Aufgabenstellung des Tests sollte den gesamten Funktionsumfang der Anwendung abdecken, um Probleme in der Gebrauchstauglichkeit aufzudecken. Daher besteht der Test aus insgesamt vier Aufgaben. Die Aufgabenstellungen sind bewusst allgemein gehalten, um zu überprüfen, wie intuitiv die einzelnen Funktionen von den Testpersonen angewendet werden können: 1. Informationszugriff Greifen sie auf zusätzliche Informationen eines beliebigen Objektes zu. 2. Ebenenauswahl Blenden sie alle Modelle bis auf die Therme aus.

69 7 Evaluation Straßengenerierung Die Anwendung unterstüzt die Generierung eines Straßennetzes auf der Karte. Starten sie hierfür den Straßenmodus und definieren sie zunächst gegen den Uhrzeigersinn einen Umriss in konvexer Form. Verändern sie nach der Erstellung die Parameter des Straßennetzes. 4. Annotationen Starten sie den Notizmodus und erstellen sie zwei Notizen auf der Karte. Greifen sie danach auf die zuerst erstellte Notiz zu, und löschen sie diese wieder Nutzungsverhalten Für jede Aufgabe wird zum einen die benötigte Zeit zur Lösung, als auch Art und Anzahl der benötigten Benutzereingaben in Form von Bildschirmberührungen aufgezeichnet. Setzt man die Mittelwerte der Stichprobe in Relation zu Idealwerten, die eine Person mit Vorerfahrung erzeugt, erhält man ein objektives Maß für die Effizienz in der Handhabung des Systems Bearbeitungserfolg Der Bearbeitungserfolg wird durch eine dreistufige Skala nach Tullis und Albert [2008] bewertet: Bewertung Interpretation 1,0 Vollständiger Erfolg ohne Hilfestellung 0,5 Teilweiser Erfolg / Hilfestellung 0,0 Abbruch, falsche Lösung Tabelle 7.1: Bewertungsskala des Bearbeitungserfolgs Mit Hilfe der Mittelwerte für jede bearbeitete Aufgabe können die unterschiedlichen Aufgaben hinsichtlich ihrer Effektivität verglichen werden. Gleichzeitig können so die von den Nutzern als problematisch empfundenen Aufgaben identifiziert werden Fragebogen Nach dem eigentlichen Usability-Test wird der Gesamteindruck der Testnutzer durch einen Fragebogen erhoben. Hierfür wird der System Usability Scale (SUS) nach Brooke [1996] verwendet. Der SUS zeichnet sich durch seine einfache Anwendung und Auswertung, sowie durch robuste Ergebnisse auch bei kleinen Stichproben aus. Der Fragebogen besteht aus insgesamt 10 Aussagen, die auf einer fünfstufigen Skala, mit Gewichten von 1 für starke Ablehnung bis 5 für volle Zustimmung, bewertet werden: 1. Ich denke, das ich dieses System gerne häufig nutzen würde. 2. Ich fand das System unnötig komplex.

70 7 Evaluation Ich denke, das System war einfach zu benutzen. 4. Ich denke, ich würde die Hilfe eines Technikers benötigen, um das System benutzen zu können. 5. Ich halte die verschiedenen Funktionen des Systems für gut integriert. 6. Ich halte das System für zu inkonsistent. 7. Ich kann mir vorstellen, dass die meisten Leute den Umgang mit dem System schnell lernen würden. 8. Ich fand das System sehr mühsam zu benutzen. 9. Ich fühlte mich bei der Nutzung des Systems sehr sicher. 10. Ich musste viele Dinge lernen, bevor ich das System nutzen konnte. Der Fragebogen wird mit Hilfe des SUS Scores ausgewertet. Um den SUS Score zu ermitteln, werden zunächst die Beiträge der einzelnen Aussagen bestimmt. Die Skalenwerte der Aussagen 1, 3, 5, 7 und 9 werden um eins verringert und können somit den Maximalwert von 4 haben. Der Skalenwert der Aussagen 2, 4, 6, 8 und 10 wird von fünf subtrahiert und liegt somit ebenfalls bei maximal 4. Alle Beiträge werden dann aufaddiert und mit 2,5 multipliziert. Der so ermittelte SUS Score liegt in einem Bereich von 0 bis 100. Zur Interpretation ist es sinnvoll, den SUS Score nach Sauro in eine Prozentskala zu konvertieren. Mit dieser Prozentskala lässt sich die allgemeine Gebrauchstauglichkeit der Anwendung in Noten von 1 Sehr Gut bis 5 Mangelhaft bewerten. 7.2 Ergebnis Die Evaluation der Anwendung durch insgesamt 12 Probanden liefert die nachfolgend dargestellten und erläuterten Ergebnisse. Nutzungsverhalten Das in Form von Klicks und Bearbeitungszeit aufgezeichnete Nutzungsverhalten der Testprobanden ist in Abbildung 7.1 zusammen mit Idealwerten, die bei der Nutzung durch eine mit der Anwendung vertraute Person entstehen, dargestellt. Die Testprobanden brauchten für die Lösung der Aufgaben im Schnitt 25% mehr Klicks, als minimal notwendig wären. Dies ist auf die erste notwendige Orientierung innerhalb der Anwendung zurückzuführen, die meist durch Berührung der verschiedenen Menüelemente zurückzuführen ist. Zieht man die Bearbeitungszeit der einzelnen Aufgaben hinzu, zeigt sich ein differenzierteres Bild. Im Vergleich zu der Idealzeit eines erfahrenen Benutzers ist zu erwarten, dass alle Aufgaben durch die unerfahrenen Testnutzer weniger schnell bearbeitet werden können. Während die Aufgaben 1 und 2 eine wenig höhere Bearbeitungszeit gegenüber dem Idealwert zeigen, fallen hier die Aufgaben 2 und 3 mit Bearbeitungszeiten, die einem Vielfachen der Idealzeit entsprechen, auf. Die Effizienz bei der Bearbeitung dieser Aufgaben ist also signifikant schlechter gegenüber den übrigen Aufgaben.

71 Klicks Zeit [s] 7 Evaluation Anzahl benötigter Klicks Aufgabe 1 Aufgabe 2 Aufgabe 3 Aufgabe 4 Mittel Ideal Benötigte Zeit Aufgabe 1 Aufgabe 2 Aufgabe 3 Aufgabe 4 Mittel Ideal (a) Benötigte Klicks (b) Bearbeitungszeit Abbildung 7.1: Gemitteltes Nutzungsverhalten im Vergleich zu Idealwerten Bearbeitungserfolg Der Bearbeitungserfolg der Aufgaben bestätigt zum Teil die Ergebnisse des Nutzungsverhalten. Die Aufgaben 1 und 4 haben einen mittleren Bearbeitungserfolg von 0,92 bzw. 0,88. Diese Aufgaben konnten somit von der überwiegenden Zahl der Testnutzer ohne Hilfestellung durch den Testleiter gelöst werden. Aufgabe 2 hat einen Bearbeitungserfolg von 0,75. Es benötigten also im Mittel die Hälfte der Testnutzer die Hilfe des Testleiters zum Lösen der Aufgabe. Aufgabe 3 hat einen Bearbeitungserfolg von lediglich 0,5. Die Aufgabe konnte somit von keinem Testprobanden ohne Hilfestellung gelöst werden. 1 Bearbeitungserfolg 0,5 0 Aufgabe 1 Aufgabe 2 Aufgabe 3 Aufgabe 4 Abbildung 7.2: Mittlerer Bearbeitungserfolg jeder Aufgabe Fragebogen Die Auswertung des Fragebogens ergab einen durchschnittlichen SUS Score von 79,5. Nach Sauro entspricht dieses Ergebnis einer überdurchschnittlichen Usability, die mit einer Note zwischen 1 und 2 bewertet werden könnte. Zu beachten ist, das der SUS Score lediglich den Gesamteindruck einer Anwendung bewertet und keinerlei Diagnosemöglichkeit für Probleme bietet. Um die Zufriedenheit der Nutzer nach ISO 9241 zu bewerten eignet er sich dennoch und bescheinigt der Anwendung in diesem Fall eine gute Gebrauchstauglichkeit.

72 7 Evaluation Identifikation der Schwachstellen Trotz der im Allgemeinen als gut eingestuften Gebrauchstauglichkeit, zeigen Nutzungsverhalten und Bearbeitungserfolg bei den Aufgaben 2 und 3 Defizite im Bereich der intuitiven Bedienung. Bei Aufgabe 2 führte das Auffinden und Öffnen des seitlichen Menüs, um Zugriff auf die Ebenenauswahl zu erhalten, zu Problemen. Der Knopf zum Öffnen des Menüs wurde von den Probanden nur schlecht wahrgenommen und ist aufgrund der geringen Größe schwierig zu bedienen. Bei Aufgabe 3 wurde von den Probanden übersehen, das ein weiterer Menüpunkt betätigt werden muss, um die Umrissdefinition zu starten. Dies ist darauf zurück zu führen, dass der entsprechende Menüeintrag erst beim Starten des Straßenmodus angezeigt wird und den Menüeintrag des Notizmodus an gleicher Stelle ersetzt. 7.4 Verbesserung der Gebrauchstauglichkeit Ein Usability-Test hat immer das Ziel, die Bedienbarkeit einer Anwendung zu verbessern. Die in Abschnitt 7.3 identifizierten Schwachstellen sollen daher durch einfache Maßnahmen beseitigt werden. Um die Probleme bei der Wahrnehmung des seitlichen Menüs zu verbessern, wird das Symbol zum Öffnen ausgetauscht (Abb. 7.3). (a) Altes Menüsymbol (b) Neues Menüsymbol Abbildung 7.3: Vergleich zwischen alten und verbesserten Menüsymbol Das neue Symbol bietet einen besseren Kontrast gegenüber den typischerweise dominierenden hellen Flächen des Markers und kann somit besser wahrgenommen werden. Die um das dreifache vergrößerte Fläche unterstützt diesen Effekt und vereinfacht zusätzlich das Öffnen des Menüs. Als weitere Schwachstelle wurde die Generierung des Straßennetzes identifiziert. Um den Nutzer auf den neu hinzukommenden Knopf zur Definition des Umrisses hinzuweisen, werden zwei Maßnahmen ergriffen. Bei der erstmaligen Aktivierung des Straßenmodus wird der neue Knopf durch eine pulsierende Animation dargestellt. Durch diesen optischen Reiz wird der Benutzer sofort auf die nächste notwendige

App-Entwicklung für Android

App-Entwicklung für Android App-Entwicklung für Android Einleitung - Systemarchitektur Hochschule Darmstadt WS15/16 1 Inhalt Historie Systemarchitektur Sandbox 2 Motivation Kontra Pro Limitierte Größe Begrenzte Ressourcen Kein Standardgerät

Mehr

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel ab 2.6, aktuell 3.8 Managed Code,

Mehr

Mobile Augmented Reality

Mobile Augmented Reality Mobile Augmented Reality Semantische Bauwerksmodelle als Datengrundlage einer Smartphone-basierten Augmented Reality Anwendung RWTH Aachen University Geodätisches Institut Lehrstuhl für Bauinformatik &

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

SMARTPHONES. Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl

SMARTPHONES. Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl SMARTPHONES Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl A-SIT/Smartphones iphone security analysis (Q1 2010) Blackberry security analysis (Q1 2010) Qualifizierte Signaturen und Smartphones

Mehr

ClickShare The one click Das One-Click-wonder W

ClickShare The one click Das One-Click-wonder W ClickShare Das The One-Click-Wonder one click wonder Teamarbeit leicht gemacht Die Verbesserung der Tagungsdynamik und eine schnellere Entscheidungsfindung sind aktuell zwei der großen Herausforderungen

Mehr

Virales Marketing mit Smartphones. Jens Doose - Onwerk GmbH 05.11.2010

Virales Marketing mit Smartphones. Jens Doose - Onwerk GmbH 05.11.2010 Virales Marketing mit Smartphones Jens Doose - Onwerk GmbH 05.11.2010 Über Onwerk Was ist ein Smartphone? Eigene Inhalte auf dem Telefon Statistiken Virales Marketing Mobiles virales Marketing Beispiel

Mehr

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel 2.6 Managed Code, Angepasste Java

Mehr

Mobile Applications. Adrian Nägeli, CTO bitforge AG

Mobile Applications. Adrian Nägeli, CTO bitforge AG Mobile Applications Adrian Nägeli, CTO bitforge AG Inhalt Vorstellung Marktübersicht Entwicklung Adrian Nägeli Dipl. Inf.-Ing FH Seit 2005 bei bitforge bitforge AG Standort Rapperswil-Jona Gründung 2004

Mehr

Plattformen mobiler Endgeräte Windows Phone, ios, Android

Plattformen mobiler Endgeräte Windows Phone, ios, Android Plattformen mobiler Endgeräte Windows Phone, ios, Android 13.12.2012 Inhaltsverzeichnis 1. Einführung 2. Ecosystem Smartphone OS 3. Mobile Software Platform 4. Android App Entwicklung 5. Zusammenfassung

Mehr

CREATIVE PROGRAMMING TOOLKITS

CREATIVE PROGRAMMING TOOLKITS CREATIVE PROGRAMMING TOOLKITS Unter Creative Programming Toolkits verstehen wir Software-Teile welche uns helfen vielfältige Medien-kunst zu erstellen. Viele dieser Werkzeuge wurden durch Künstler für

Mehr

Einführung in Betriebssysteme

Einführung in Betriebssysteme Einführung in Betriebssysteme APPLE ios Entwicklung von ios Entwickelt auf der Basis von MacOS X UNIX Vorgestellt am 9.1.2007 Zusammen mit iphone Markenname von Cisco Internetwork Operating System Für

Mehr

Eine App, viele Plattformen

Eine App, viele Plattformen Eine App, viele Plattformen Anwendungsentwicklung für Mobile Heiko Lewandowski 23.04.2013 EINLEITUNG Festlegung App-Strategie: Welche Ziele möchte ich erreichen? Die Vielzahl der Plattformen und Geräte(hersteller)

Mehr

Unterscheidung Tablet PC & Tablet Computer. Tablet PC; ursprüngliche Bezeichnung von Microsoft. Tablets gemeint

Unterscheidung Tablet PC & Tablet Computer. Tablet PC; ursprüngliche Bezeichnung von Microsoft. Tablets gemeint Überblick Unterscheidung Tablet PC & Tablet Computer Tablet PC; ursprüngliche Bezeichnung von Microsoft Mit Tablet Computer sind die heutigen gängigen Mit Tablet Computer sind die heutigen gängigen Tablets

Mehr

GEO-DIENSTE AUF BASIS DER ANDROID-PLATTFORM. Seminar: Datenbankunterstützung für mobile GIS Michael Goj

GEO-DIENSTE AUF BASIS DER ANDROID-PLATTFORM. Seminar: Datenbankunterstützung für mobile GIS Michael Goj GEO-DIENSTE AUF BASIS DER ANDROID-PLATTFORM Seminar: Datenbankunterstützung für mobile GIS Michael Goj AGENDA Einleitung Standortbezogene Dienste und Anwendungen Geo-Dienste Die Android-Plattform Google

Mehr

Walkabout: Location Based Services mit Android und dem Google Phone

Walkabout: Location Based Services mit Android und dem Google Phone Walkabout: Location Based Services mit Android und dem Google Phone Teilbereich 1: Die Android Plattform für mobile Geräte (Software) Von: Sebastian Schul Inhalt Einleitung Was ist Android Exkurs: Wie

Mehr

Präsentation Von Laura Baake und Janina Schwemer

Präsentation Von Laura Baake und Janina Schwemer Präsentation Von Laura Baake und Janina Schwemer Gliederung Einleitung Verschiedene Betriebssysteme Was ist ein Framework? App-Entwicklung App-Arten Möglichkeiten und Einschränkungen der App-Entwicklung

Mehr

Mobile Application Development

Mobile Application Development Mobile Application Development Android: Einführung Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Lernziele Der/die Kursbesucher/in kann

Mehr

Smartphone - Betriebssysteme. Smartphone - Betriebssysteme

Smartphone - Betriebssysteme. Smartphone - Betriebssysteme Smartphone - Betriebssysteme Peter Rami - Graz, 28.04.2009 Inhalt Smartphone Symbian OS Windows Mobile BlackBerry OS iphone OS Android Marktanteile & Ausblick Smartphone - Betriebssysteme Peter Rami -

Mehr

We put the REAL in Real Estate.

We put the REAL in Real Estate. We put the REAL in Real Estate. Von Architekturvisualisierungen bis Augmented Reality. BÜRO OG / GARTENGASSE 21 A-1050 VIENNA / +43 (0) 1 545 78 25 OFFICE@BUROWHAT.COM / WWW.BUROWHAT.COM Visualisierungen

Mehr

Chancen und Möglichkeiten der Nutzung von Augmented Reality Technologien im Industrie 4.0 Umfeld Vortrag auf dem Karlsruher Entwicklertag 2015

Chancen und Möglichkeiten der Nutzung von Augmented Reality Technologien im Industrie 4.0 Umfeld Vortrag auf dem Karlsruher Entwicklertag 2015 Karlsruhe Technology Consulting www.karlsruhe-technology.de Chancen und Möglichkeiten der Nutzung von Augmented Reality Technologien im Industrie 4.0 Umfeld Vortrag auf dem Karlsruher Entwicklertag 2015

Mehr

App-Entwicklung mit Titanium

App-Entwicklung mit Titanium Masterstudienarbeit Betreuung Prof. Dr. M. von Schwerin 1 Gliederung 1.Motivation 2.Aufgabenstellung 3.Projektbeschreibung 4.Projektstatusbericht 5.Fazit und Ausblick 2 1.Motivation Verbreitung von Smartphones

Mehr

LaVida. Mobile Endgeräte. Andreas Neupert

LaVida. Mobile Endgeräte. Andreas Neupert LaVida Mobile Endgeräte Andreas Neupert Einleitung 1 33 Was? 1) Android a. Hardware b. Entwickeln i. Tools ii. Architektur & Konzepte iii. Google App Inventor c. Benutzen versus 2) WP 7 a. Hardware b.

Mehr

C++ und mobile Plattformen

C++ und mobile Plattformen Dieser Artikel stammt aus dem Magazin von C++.de (http://magazin.c-plusplus.de) C++ und mobile Plattformen Mit diesem Artikel möchte ich euch einen kurzen Überblick über die verschiedenen Plattformen für

Mehr

Business Case. Lenovo setzt bei neuem Netbook auf Android statt eigenem Linux Kernel. Felix Feldmeier Heinrich Peuser Raissa Sachs Martin Stopczynski

Business Case. Lenovo setzt bei neuem Netbook auf Android statt eigenem Linux Kernel. Felix Feldmeier Heinrich Peuser Raissa Sachs Martin Stopczynski Business Case Lenovo setzt bei neuem Netbook auf Android statt eigenem Linux Kernel Felix Feldmeier Heinrich Peuser Raissa Sachs Martin Stopczynski 10.06.2010 Technologie- und Marketing-Management in IT-/TIMES-Märkten

Mehr

Erste Erfahrungen mit Android

Erste Erfahrungen mit Android Java User Group München, 22. 9. 2008 Erste Erfahrungen mit Android 1 Was ist Android? Die erste vollständige, offene und freie Plattform für mobile Telefone Entwickelt von der Open Handset Alliance (Telecoms,

Mehr

PLAZA Apps informativ, intuitiv und barrierefrei. September 2013

PLAZA Apps informativ, intuitiv und barrierefrei. September 2013 PLAZA Apps informativ, intuitiv und barrierefrei September 2013 1. Bestandsaufnahme: Smartphone, App und Geodaten 2. PLAZA als App-Framework 3. Best Practice Beispiele Bestandsaufnahme: Smartphones und

Mehr

Industrielle Bildverarbeitung mit OpenCV

Industrielle Bildverarbeitung mit OpenCV Industrielle Bildverarbeitung mit OpenCV Zhang,Duoyi 6.7.2 Gliederung. Einführung für OpenCV 2. Die Struktur von OpenCV Überblick Funktionsumfang in Ausschnitten mit Beispielen 3. Industrielles Anwendungsbeispiel

Mehr

Mobile App Testing. Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013. Functional Test Automation Tools

Mobile App Testing. Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013. Functional Test Automation Tools Functional Test Automation Tools Mobile App Testing Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013 Presenter: Christoph Preschern (cpreschern@ranorex.com) Inhalte» Ranorex Company Overview»

Mehr

Eine kurze Einführung in die Technologiegrundlage. Future Internet Technologies and Funding for Agri-Food, Logistics, Transport and Manufacturing

Eine kurze Einführung in die Technologiegrundlage. Future Internet Technologies and Funding for Agri-Food, Logistics, Transport and Manufacturing Eine kurze Einführung in die Technologiegrundlage www.finish-project.eu Future Internet Technologies and Funding for Agri-Food, Logistics, Transport and Manufacturing Was ist FIWARE? Future Internet Ware

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung

Fertigprodukte. Bruno Blumenthal und Roger Meyer. 18. Juli 2003. Zusammenfassung Fertigprodukte Bruno Blumenthal und Roger Meyer 18. Juli 2003 Zusammenfassung Dieses Dokument beschreibt die Fertigprodukte welche im Projekt NetWACS eingesetzt werden sollen. Es soll als Übersicht dienen

Mehr

NEXT GENERATION MOBILE PHONE PLATFORMS

NEXT GENERATION MOBILE PHONE PLATFORMS Stephan Zeisberg NEXT GENERATION MOBILE PHONE PLATFORMS Ein Einblick in die Systemarchitekturen aktueller Smartphones 1 Motivation Technologischer Stillstand in der Entwicklung mobiler Betriebssysteme

Mehr

Technologie Impulse Deutschland 2012. Rainer Fritzsche 5.10.2012

Technologie Impulse Deutschland 2012. Rainer Fritzsche 5.10.2012 Technologie Impulse Deutschland 2012 Rainer Fritzsche 5.10.2012 Vorstellung: Rainer Fritzsche BSc Computer Science stellvertretender KPZ-Leiter Java Software Engineer Seit 1983 auf der Welt Seit 2009 Berater

Mehr

Content Management Systeme

Content Management Systeme Content Management Systeme Ein Vergleich unter besonderer Berücksichtigung von CoreMedia und TYPO3 Bachelorthesis im Kooperativen Bachelor Studiengang Informatik (KoSI) der Fachhochschule Darmstadt University

Mehr

Smartphones und Tablets als touch-sensitive User-Interfaces im Automatisierungsumfeld

Smartphones und Tablets als touch-sensitive User-Interfaces im Automatisierungsumfeld Smartphones und Tablets als touch-sensitive User-Interfaces im Automatisierungsumfeld Prof. Dr. Miriam Föller-Nord, Hochschule Mannheim, Fakultät für Informatik Institut für Embedded and Mobile Computing

Mehr

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze) 03.06.2013 2 Innovationen

Mehr

TP2. Gefördert durch: Projektträger: www.uni-stuttgart.de. Halbzeitpräsentation TP2 1 01-10

TP2. Gefördert durch: Projektträger: www.uni-stuttgart.de. Halbzeitpräsentation TP2 1 01-10 TP2 Gefördert durch: Projektträger: Halbzeitpräsentation TP2 1 Ziele: Technisches Systemkonzept, Integration und Demonstratoren Bereitstellung von Verfahren: Einheitliche Sensordaten-Erfassung und Verarbeitung

Mehr

greenpaper 13. mobile apps am hype partizipieren.

greenpaper 13. mobile apps am hype partizipieren. Marken und Märkte aktivieren. Mit emotionaler Intelligenz als Basis exzellenter Ideen, die durchschlagend Erfolg versprechen com Icons 2011 24 Themen um die Sie sich für nächstes Jahr kümmern sollten greenpaper

Mehr

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features.

Inhalt. 1 Übersicht. 2 Anwendungsbeispiele. 3 Einsatzgebiete. 4 Systemanforderungen. 5 Lizenzierung. 6 Installation. 7 Key Features. Inhalt 1 Übersicht 2 Anwendungsbeispiele 3 Einsatzgebiete 4 Systemanforderungen 5 Lizenzierung 6 Installation 7 Key Features Seite 2 von 11 1. Übersicht MIK.mobile for ipad ist eine Business Intelligence

Mehr

Animation der Montage von CATIA-Bauteilen

Animation der Montage von CATIA-Bauteilen Animation der Montage von CATIA-Bauteilen KONZEPTION UND PROTOTYP PRÄSENTATION ZUM PRAXISPROJEKT SS 2007 VON TIM HERMANN BETREUER: PROF. DR. HORST STENZEL Motivation Voraussetzungen Ziele Datenkonvertierung

Mehr

Datenhaltung für Android. Model First

Datenhaltung für Android. Model First Datenhaltung für Android Model First Frederik Götz, Johannes Tysiak 26.05.2011 Unser Ziel! 26.05.2011 Datenhaltung in Android - Model First» Frederik Götz, Johannes Tysiak 2 Agenda Android Quickstart Datenhaltung

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

CRM KINDERLEICHT NEUERUNGEN IM RELEASE 8.4

CRM KINDERLEICHT NEUERUNGEN IM RELEASE 8.4 CRM KINDERLEICHT NEUERUNGEN IM RELEASE 8.4 STRATEGISCHE ZIELE Terminumfrage, Termine und Aufgaben in GEDYS IntraWare 8.web Unabhängig vom E Mail und Kalendersystem Termine auch für Kunden Ablösung der

Mehr

Autorensysteme für mobile Anwendungen - Totgesagte leben länger. Prof. Dr. Michael Bauer 25.10. 2012 Autorensysteme

Autorensysteme für mobile Anwendungen - Totgesagte leben länger. Prof. Dr. Michael Bauer 25.10. 2012 Autorensysteme Autorensysteme für mobile Anwendungen - Totgesagte leben länger Was ist, was will ein Autor? Produzent interaktiver, multimedialer Inhalte geschlossene Einheiten (Apps) keine Grenzen für Kreativität Entwicklungs-

Mehr

Consulting Development Design

Consulting Development Design Consulting Development Design 59. Bundesweites Gedenkstättenseminar - AG 4 Agenda Vorstellung Was verbirgt sich hinter einer mobilen App? Beispiel TABTOUR mehr als nur eine App Was ist jetzt und zukünftig

Mehr

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme

Diplomarbeit. Entwurf eines generischen Prozessleitstandes für Change Request Systeme Fakultät für Mathematik, Informatik und Naturwissenschaften Forschungsgruppe Softwarekonstruktion Diplomarbeit Entwurf eines generischen Prozessleitstandes für Change Request Systeme Development of a Generic

Mehr

Mobile Enterprise Application Platforms

Mobile Enterprise Application Platforms Mobile Enterprise Application Platforms 17. April 2013 Fachbereich Wirtschaft und Gesundheit Prof. Dr. Volker Wiemann volker.wiemann@fh bielefeld.de +49 (0) 521/106 389 Problem 0. Ausgangslage Blackberry

Mehr

Architekturen mobiler Multi Plattform Apps

Architekturen mobiler Multi Plattform Apps Architekturen mobiler Multi Plattform Apps Wolfgang Maison & Felix Willnecker 06. Dezember 2011 1 Warum Multi- Plattform- Architekturen? Markt. Apps für Smartphones gehören zum Standardinventar jeder guten

Mehr

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Wiki-basierte Dokumentation von Software-Entwicklungsprozessen Erfahrungen aus der industriellen Praxis Fraunhofer IESE Kaiserslautern Inhalt Wiki-basierte Dokumentation von Software-Entwicklungsprozessen

Mehr

X PAD für Android Das Erste, das Fortschrittlichste.

X PAD für Android Das Erste, das Fortschrittlichste. Designed und entwickelt von X PAD für Android eröffnet eine neue Welt auf der Android Plattform. Auf dieser für mobile Geräte am weitesten entwickelten und technologisch fortschrittlichsten Plattform haben

Mehr

mscape Projektgruppe: Lab on Mobile Gaming Daniel Kress

mscape Projektgruppe: Lab on Mobile Gaming Daniel Kress mscape Projektgruppe: Lab on Mobile Gaming Daniel Kress Zusammenfassungder Vor-und Nachteile Vorteile -Geringe/keine Programmierkenntnisse notwendig - Graphische Oberfläche -Erweiterbarkeit des Frameworks

Mehr

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08

Security Patterns. Benny Clauss. Sicherheit in der Softwareentwicklung WS 07/08 Security Patterns Benny Clauss Sicherheit in der Softwareentwicklung WS 07/08 Gliederung Pattern Was ist das? Warum Security Pattern? Security Pattern Aufbau Security Pattern Alternative Beispiel Patternsysteme

Mehr

CRM KINDERLEICHT NEUERUNGEN IM RELEASE 8.4

CRM KINDERLEICHT NEUERUNGEN IM RELEASE 8.4 CRM KINDERLEICHT NEUERUNGEN IM RELEASE 8.4 STRATEGISCHE ZIELE Terminumfrage, Termine und Aufgaben in GEDYS IntraWare 8.web Unabhängig vom E Mail und Kalendersystem Termine auch für Kunden Ablösung der

Mehr

Mobile App Development. - Einführung -

Mobile App Development. - Einführung - Mobile App Development - Einführung - Inhalt Organisatorisches Vorlesungsinhalt Mobile Geräte Android Architektur App Aufbau Praktikum Organisatorisches 4 SWS, 5 ECTS 2 Vorlesung / 2 Praktikum ca. 10 Wochen

Mehr

ios,android, Windows Phone

ios,android, Windows Phone Name: Mario Pomberger Klasse: 1AHWIM Jahr: 2012/2013 1 2,, 3 1 http://mobilemag.com 2 http://www.lesen.net 3 http://www.geekovation.de Vergleich Ios Windows Word 23.01.13 Seite 1 von10 Inhalt 1.Einführung...

Mehr

INDUSTRIE 4.0 Informatisierung der klassischen Industrie mit dem Ziel der Smart Factory

INDUSTRIE 4.0 Informatisierung der klassischen Industrie mit dem Ziel der Smart Factory INDUSTRIE 4.0 Informatisierung der klassischen Industrie mit dem Ziel der Smart Factory Prozessoptimierung mit Hilfe mobiler Applikationen Steuerung - Kontrolle - Überwachung - Konfiguration VORTEILE VON

Mehr

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche

Ein Auszug aus... Studie. Content Management Systeme im Vergleich. Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Ein Auszug aus... Studie Content Management Systeme im Vergleich Empfehlungen und Entscheidungshilfen für Unternehmensbereiche Die komplette Studie ist bei amazon.de käuflich zu erwerben. Inhaltsverzeichnis

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

1. Schnellkurs Android-Tablet den Startbildschirm individuell anpassen und optimal nutzen

1. Schnellkurs Android-Tablet den Startbildschirm individuell anpassen und optimal nutzen . Schnellkurs Android-Tablet den Startbildschirm individuell anpassen und optimal nutzen Android-Tablets lassen sich sprichwörtlich mit dem richtigen Fingerspitzengefühl steuern. Das Grundprinzip von Tippen,

Mehr

Android. LUG-LD Christoph Maya 2011 http://demaya.de. Lizenz: http://creativecommons.org/licenses/by-nc/3.0/de/

Android. LUG-LD Christoph Maya 2011 http://demaya.de. Lizenz: http://creativecommons.org/licenses/by-nc/3.0/de/ Android LUG-LD Christoph Maya 2011 http://demaya.de Lizenz: http://creativecommons.org/licenses/by-nc/3.0/de/ Inhalt Inhalt: ein Mix für Einsteiger und Fortgeschrittene Was ist Android und wo kommts her?

Mehr

Allgemeine Informationen Slides2Go Stand April 2015

Allgemeine Informationen Slides2Go Stand April 2015 Allgemeine Informationen Slides2Go Stand April 2015 1. ALLGEMEINE INFORMATIONEN... 3 1.1 SYSTEMANFORDERUNGEN WEB-BACKEND... 3 1.2 SYSTEMANFORDERUNGEN FRONTEND / APP... 3 1.3 UNTERSTÜTZTE DATEIFORMATE...

Mehr

MMI2 Übung 10: Kamera-basierte mobile Interaktion. Prof. Dr. Michael Rohs, Dipl.-Inform. Sven Kratz michael.rohs@ifi.lmu.de MHCI Lab, LMU München

MMI2 Übung 10: Kamera-basierte mobile Interaktion. Prof. Dr. Michael Rohs, Dipl.-Inform. Sven Kratz michael.rohs@ifi.lmu.de MHCI Lab, LMU München MMI2 Übung 10: Kamera-basierte mobile Interaktion Prof. Dr., Dipl.-Inform. Sven Kratz michael.rohs@ifi.lmu.de MHCI Lab, LMU München Aktuelles Klausur am 8.2.2012 Anmeldung Fragen zur Klausur jeweils zu

Mehr

Digitale Checklisten sparen Zeit und Geld. Stellen Sie jetzt um von Papier auf eine moderne digitale Lösung.

Digitale Checklisten sparen Zeit und Geld. Stellen Sie jetzt um von Papier auf eine moderne digitale Lösung. firstaudit DIGITALE CHECKLISTEN Digitale Checklisten sparen Zeit und Geld Stellen Sie jetzt um von Papier auf eine moderne digitale Lösung. Die neue Checklisten-App firstaudit optimiert Ihren Workflow.

Mehr

Ein mobiler Electronic Program Guide für Android

Ein mobiler Electronic Program Guide für Android Whitepaper Telekommunikation Ein mobiler Electronic Program Guide für Android Prototyp für Android Apps 2011 SYRACOM AG 1 Einleitung Apps Anwendungen für mobile Geräte sind derzeit in aller Munde. Durch

Mehr

Mobile Marketing. Mobile Erfolgsstrategien mit interoperativen Systemen im Ökosystem des mobile Webs

Mobile Marketing. Mobile Erfolgsstrategien mit interoperativen Systemen im Ökosystem des mobile Webs Mobile Marketing Mobile Erfolgsstrategien mit interoperativen Systemen im Ökosystem des mobile Webs Smartphones gerne lautlos anlassen :-) Kurzvorstellung Martin Schmitz E-Marketing-Manager, Projektleiter

Mehr

Mobiles Marketing mit Smartphone Apps

Mobiles Marketing mit Smartphone Apps Mobiles Marketing mit Smartphone Apps 18. Juni 2012 Jens Doose, Onwerk GmbH Wer bin ich? Jens Doose Geschäftsführer der Onwerk GmbH 10 Jahren Software aus Ideen Server, PC, Smartphone-Apps Beratung, Konzeption,

Mehr

VCM Solution Software

VCM Solution Software VCM Solution Software Die BORUFA VCM Solution ist ein umfangreiches Werkzeug für virtuelles Content Management basierend auf hochauflösenden vollsphärischen Bildern, 360 Videos und Punktwolken. In der

Mehr

WE CALL IT CONTENT BACKBONE

WE CALL IT CONTENT BACKBONE CONTENTI HUB D A T E N D R E H S C H E I B E CONTENTI ENGINE C E N T R A L R E P O S I T O R Y WE CALL IT CONTENT BACKBONE MEDIA ASSET MANAGEMENT + DIGITAL EDITIONS Visit us at World Publishing Expo 2015,

Mehr

Windows 7 mittels Shrew Soft VPN Client per VPN mit FRITZ!Box 7390 (FRITZ!OS 6) verbinden

Windows 7 mittels Shrew Soft VPN Client per VPN mit FRITZ!Box 7390 (FRITZ!OS 6) verbinden Windows 7 mittels Shrew Soft VPN Client per VPN mit FRITZ!Box 7390 (FRITZ!OS 6) verbinden Veröffentlicht am 28.11.2013 In FRITZ!OS 6.00 (84.06.00) gibt es neuerdings die Möglichkeit, VPN Verbindungen direkt

Mehr

Revox Joy S232 App D 1.0

Revox Joy S232 App D 1.0 Inhalt Revox Joy S232 App 1 D 1.0 Revox M-Serie Android App M235 Inhalt Herzlich Willkommen... 3 Funktionsumfang... 3 Voraussetzungen... 3 Installation... 3 Versionsnummer... 4 Konfiguration... 5 Erweiterte

Mehr

Entwicklung und Integration mobiler Anwendungen. Oracle Deutschland B.V. & Co. KG

Entwicklung und Integration mobiler Anwendungen. <Speaker> Oracle Deutschland B.V. & Co. KG Entwicklung und Integration mobiler Anwendungen Oracle Deutschland B.V. & Co. KG Global Users (Millions) Der Trend ist eindeutig. Trend zu mobilen Endgeräten Wachstum des mobilen Datenverkehrs

Mehr

November 2013 FLASH INSIGHT. ibeacon Attraktive Use Cases am POS werden Realität

November 2013 FLASH INSIGHT. ibeacon Attraktive Use Cases am POS werden Realität November 2013 FLASH INSIGHT ibeacon Attraktive Use Cases am POS werden Realität Copyright Die Nutzung der Inhalte und Darstellungen in Drittdokumenten ist nur mit vorheriger Zustimmung von MÜCKE, STURM

Mehr

Das erste epaper für alle Geräte. Die erste Zeitung, mit der Sie sprechen können! Zwei neue epaper Apps

Das erste epaper für alle Geräte. Die erste Zeitung, mit der Sie sprechen können! Zwei neue epaper Apps epaper ios App + HTML5 epaper 3 bis 7 Cent/Download alles inklusive (Software + Service) Die erste Zeitung, mit der Sie sprechen können! Testen Sie uns auf der World Publishing Expo vom 13.-15. Okt. 2014

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Exposé NetDiscovery. Haupteinsatzgebiete und Nutzen

Exposé NetDiscovery. Haupteinsatzgebiete und Nutzen Exposé NetDiscovery Mit der Nutzung von NetDiscovery erhalten ITK - Serviceunternehmen die Möglichkeit Ihre Kundendienstleistungen in der Netzwerkaufnahme und dokumentation wirksam zu verbessern und so

Mehr

Workflow Systeme mit der Windows Workflow Foundation

Workflow Systeme mit der Windows Workflow Foundation Studiengang Electronic Business (EB) Diplomarbeit (280000) Workflow Systeme mit der Windows Workflow Foundation externe Betreuung durch Christoph Müller vorgelegt bei Prof. Dr. Michael Gröschel von Hans-Martin

Mehr

Handbuch für ios 1.4 1

Handbuch für ios 1.4 1 Handbuch für ios 1.4 1 Inhaltsverzeichnis 1. Leistungsumfang... 3 1.1 Über Boxcryptor Classic... 3 1.2 Über dieses Handbuch... 4 2. Installation... 5 3. Grundfunktionen... 6 3.1. Einrichtung von Boxcryptor

Mehr

Die dritte Dimension in der Medientechnik

Die dritte Dimension in der Medientechnik Die dritte Dimension in der Medientechnik Dr.-Ing. Matthias Bues Competence Team Visual Technologies Fraunhofer IAO, Stuttgart Visual Technologies was wir tun Interaktive Systeme von 3D bis 2D Neue Interaktionsformen

Mehr

Mobile: Die Königsfrage

Mobile: Die Königsfrage Mobile: Die Königsfrage - Native App,Mobile Website oder doch Responsive Design? - Native App oder Mobile Website? Wer am Boom der mobilen Anwendungen teilhaben möchte, hat im Prinzip zwei Möglichkeiten:

Mehr

Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac

Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac Zusatz zum digitalstrom Handbuch VIJ, aizo ag, 15. Februar 2012 Version 2.0 Seite 1/10 Zugriff auf die Installation mit dem

Mehr

Collaborative Virtual Environments

Collaborative Virtual Environments Collaborative Virtual Environments Stefan Lücking Projektgruppe Kreativität und Technik AG Domik WS 02/03 09.01.2003 1/35 Was sind CVE? Versuch einer Definition : Ein CVE ist ein Programm, das eine virtuelle

Mehr

Matrox Imaging Library MIL die weltweit hochprämierte und industrieerprobte Bildverarbeitungs-Bibliothek

Matrox Imaging Library MIL die weltweit hochprämierte und industrieerprobte Bildverarbeitungs-Bibliothek Matrox Imaging Library MIL die weltweit hochprämierte und industrieerprobte Bildverarbeitungs-Bibliothek Release MIL 9.2 Matrox Imaging Library weltweit ein voller Erfolg! RAUSCHER BILDVERARBEITUNG Telefon

Mehr

Android Context Twitter. Software Engineering Projekt WS 09/10

Android Context Twitter. Software Engineering Projekt WS 09/10 Software Engineering Projekt WS 09/10 Gliederung Motivation Zielsetzung Grundlagen Implementation Komponentenüberblick Komponentenkommunikation Serverkomponenten (ACT) Ergebnisse / Zusammenfassung 2 Motivation

Mehr

Praxisbericht Mobile Publishing. Willkommen in der Welt der Publikationen! seit 1799

Praxisbericht Mobile Publishing. Willkommen in der Welt der Publikationen! seit 1799 Praxisbericht Mobile Publishing Willkommen in der Welt der Publikationen! seit 1799 Inhalte Entwicklung, Geräte, Markt, Nutzung Publikationswege für Tablet-PC Demonstrationen, Beispiele Mobile Publishing

Mehr

i3sync DRAHTLOSES "PLUG&PLAY" PRÄSENTATIONSTOOL

i3sync DRAHTLOSES PLUG&PLAY PRÄSENTATIONSTOOL i3sync DRAHTLOSES "PLUG&PLAY" PRÄSENTATIONSTOOL ERLEBEN SIE EINE NEUE ART VON MEETING Mit diesem kompakten und leichten Präsentationstool wird sich die Art, wie Sie Präsentationen halten und Meetings führen

Mehr

JAVA. Ein kurzer Überblick. Thomas Karp

JAVA. Ein kurzer Überblick. Thomas Karp JAVA Ein kurzer Überblick Thomas Karp WAS IST JAVA? Java ist eine fast rein objektorientierte Sprache nicht JavaScript eine professionelle Sprache eine im Unterricht weit verbreitete Sprache für verschiedene

Mehr

Mobile Apps mit DSLs. und entfernter Codegenerierung. Codierst Du noch oder generierst Du schon? Powered by

Mobile Apps mit DSLs. und entfernter Codegenerierung. Codierst Du noch oder generierst Du schon? Powered by Mobile Apps mit DSLs C1 und entfernter Codegenerierung Codierst Du noch oder generierst Du schon? Generative Software GmbH Freiburg Inhalt Plattformabhängige Entwicklung JavaScript Firefox OS Java Android

Mehr

Mit Cloud Power werden Sie zum

Mit Cloud Power werden Sie zum Mit Cloud Power werden Sie zum Windows 8 und Windows Phones Apps Mark Allibone Noser Engineering AG History Channel Computing Technology 1960 Mainframe Computing 1970 Mini Computing 1980 Personal Computing

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Das etwas andere Smartphone

Das etwas andere Smartphone Das etwas andere Smartphone Frank Prengel Technical Evangelist Microsoft Deutschland GmbH http://blogs.msdn.com/windowsphone 01./02. Dezember 2010 Köln www.iphonedevcon.de Microsoft? Auf der iphone DevCon??

Mehr

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaften

Mehr

Computer Augmented Reality

Computer Augmented Reality Computer Augmented Reality Eine Zusammenfassung von Joachim Steinmetz Vorwort: Die folgenden Seiten sollen einen Überblick über den jetzigen Stand im Bereich CAR (Computer Augmented Reality) wiedergeben.

Mehr

TM1 mobile intelligence

TM1 mobile intelligence TM1 mobile intelligence TM1mobile ist eine hochportable, mobile Plattform State of the Art, realisiert als Mobile BI-Plug-In für IBM Cognos TM1 und konzipiert als Framework für die Realisierung anspruchsvoller

Mehr

Verwaltung von Geräten, die nicht im Besitz des Unternehmens sind Ermöglich mobiles Arbeiten für Mitarbeiter von verschiedenen Standorten

Verwaltung von Geräten, die nicht im Besitz des Unternehmens sind Ermöglich mobiles Arbeiten für Mitarbeiter von verschiedenen Standorten Tivoli Endpoint Manager für mobile Geräte Die wichtigste Aufgabe für Administratoren ist es, IT-Ressourcen und -Dienstleistungen bereitzustellen, wann und wo sie benötigt werden. Die Frage ist, wie geht

Mehr

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Proseminar Objektorientiertes Programmieren mit.net und C# Florian Schulz Institut für Informatik Software & Systems Engineering Einführung Was hat Cross-Plattform

Mehr

OpenGL. (Open Graphic Library)

OpenGL. (Open Graphic Library) OpenGL (Open Graphic Library) Agenda Was ist OpenGL eigentlich? Geschichte Vor- und Nachteile Arbeitsweise glscene OpenGL per Hand Debugging Trend Was ist OpenGL eigentlich? OpenGL ist eine Spezifikation

Mehr

Hochschule Heilbronn Technik Wirtschaft Informatik

Hochschule Heilbronn Technik Wirtschaft Informatik Hochschule Heilbronn Technik Wirtschaft Informatik Studiengang Electronic Business (EB) Diplomarbeit (280000) Evaluierung und Einführung eines Web Content Management Systems bei einem internationalen und

Mehr

Mobile Device Management

Mobile Device Management 1 Mobility meets IT Service Management 26. April 2012 in Frankfurt Mobile Device Management So finden Sie Ihren Weg durch den Endgeräte- Dschungel Bild Heiko Friedrich, SCHIFFL + Partner GmbH & Co.KG http://www.schiffl.de

Mehr

KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777

KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777 KNX IP Interface 730 KNX IP Router 750 KNX IP LineMaster 760 KNX IP BAOS 770 KNX IP BAOS 771 KNX IP BAOS 772 KNX IP BAOS 777 Fernzugriff mit der ETS Achatz 3 84508 Burgkirchen Tel.: 08677 / 91 636 0 Fax:

Mehr