=====5 Beispielanwendung ===== In den folgenden Beispielapplikationen wird ein Teil der zuvor beschriebenen Arbeitsumgebung (Wissenschaftlerarbeitsplatz) entwickelt. Bei diesem Prozess sollen die Anwendungsmöglichkeiten des Web 2.0 respektive des GIS-Webservice am Beispiel der Ausgrabungsstätten von Ur, Uruk und Nimrut im Irak evaluiert werden. Für die Bearbeitung der gestellten Aufgaben wurden einige Beispieldaten vom CDLI- Projekt ausgewählt und testweise implementiert. In diesem Fall wurden die Informationen in einem Filesystem und als Mashup bei Flickr hinterlegt, da zum Projektzeitpunkt kein Zugriff auf die CDLI-Datenbanken bestand. In dieser Anwendung sollen die zuvor erwähnten alten Städte unter zu Hilfenahme von Satellitenkarten visualisiert und mit Ausgrabungs- und Fundplänen verknüpft werden. ====5.1 Untersuchung Webmapping Tools==== Für die Beispielanwendung wurden einige Webmapping bzw. Geocoding Tools untersucht. Im Vorfeld der Untersuchung wurden in Zusammenarbeit mit Peter Damerow (MPIWG Berlin) und Jacob Dahl (CDLI Kalifornien) einige grundsätzliche Bedürfnisse und Funktionen definiert, die für die Arbeit des CDLI einen Mehrwert in ihren Arbeitsprozessen darstellen. Zunächst wurde überprüft, welche Qualität Geocoding Tools bieten, die eine Visualisierung erlauben. Auf Basis dieser Erkenntnisse soll eingeschätzt werden, mit welchem Tool die Visualisierung am effektivsten ist und in welchem Maße diese stattfindet. In einem weiteren Schritt wurde untersucht, in welchen Datenformaten die Inhalte hinterlegt werden und ob diese auch in lizenzfreie Formate umgewandelt werden können. Auf Basis der Formate fand eine Evaluierung für die Erstellung, Editierung und Verteilung von Geo- und ihren Metadaten in einer späteren Anwendung statt. Nach Klärung der Datenverteilung wurde die Einbeziehung von dreidimensionalen Objekten und die Berechnung der Polygone und die Größe der Texturen bzw. der Overlay auf den Objekten und auf dem Kartenmaterial evaluiert. __Google Earth/Maps:__ Google Earth und Maps besitzen durch den Aufkauf der Firma Keyhole[75] und deren Arbeit für den Geheimdienst der USA bzw. den vergangenen Krieg gegen den Irak die besten Satellitenbilder in diesem Bereich. Diese können in Google Earth (Desktop Client) und Google Maps (Browser Client) benutzt werden. Für die eigene Browser-Entwicklung steht eine umfangreiche API zu Verfügung. Diese kann auch in andere Programme wie Widgets eingebunden werden. Darüber hinaus bieten diese Applikationen ein eigens entwickeltes Geo XML Format (KML/KMZ) für die Speicherung von Geodaten. Der Datensatz beruft sich zurzeit auf 150 TByte an Kartenmaterial, welches stetig erneuert und erweitert wird. Diese Daten sind im Schnitt zwischen 2 Monaten und 3 Jahren alt und beinhalten Überflug- und Satellitenbilder mit einer Auflösung von bis zu 30 cm pro Pixel. __Yahoo Maps:__ Auch Yahoo[76] entwickelte einen eigenen Webmapping-Service. Dieser richtet sich allerdings mehr an den amerikanischen Markt. Er verwendet schlechtere Satelliten- und Überflugkarten als Google Maps. Es werden zur Zeit nur gute Auflösungen in Großstädten und auf dem amerikanischen Festland angeboten. Die für das CDLI relevanten Gebiete sind, wie in Abbildung 15 zu sehen, in nicht ausreichender Qualität vorhanden. In der Version 3 steht allerdings eine AJAX- und eine Flash- API zur Verfügung, was den Einsatzbereich gegenüber Google Maps erweitert. Mit dieser ist es möglich, in einer Browseranwendung auch dreidimensionale Objekte darzustellen. ---- {{wiki:thesis:web_2.0_science:19_yahoo_maps.jpg|}} ---- Abbildung 15: Yahoo Maps [38] ---- __Microsoft Virtual Earth (Windows live local):__ Microsoft[77] versucht ebenso wie Yahoo auf der Erfolgswelle von Google Maps/Earth mit zu schwimmen, jedoch mit mäßigem Erfolg. Es verwendet auch nur in den Großstädten relativ gute Satellitenbilder, bietet aber auch die Eigenschaft, dreidimensionale Modelle darzustellen. Darüber hinaus wird versucht, vom Boden aufgenommene 360° Videostreams einzubinden, um eine realistische Umgebung nachzubilden. Diese ist qualitativ hochwertiger als bei Google Earth, dessen Kartenmaterial nur aus Überflugkarten besteht. ---- {{wiki:thesis:web_2.0_science:20_virtual_earth.jpg|}} ---- Abbildung 16: Microsoft Local Search [39] ---- __Nasa World Wind:__ Die Nasa stellt die einzige Open Source Anwendung mit relativ detailliertem Kartenmaterial zur Verfügung und gilt somit als die einzige echte Alternative zu Google Earth/Maps. Auch hier können dreidimensionale Modelle und Strukturen dargestellt werden. Allerdings besitzt die Nasa nur einen Datensatz von etwa 4,9 TByte. Dafür stehen bei Nasa World Wind auch Karten vom Sternensystem und von Mond, Mars Jupiter und Venus zur Verfügung. Alle Datensätze und die erzeugten Bilder sind ebenfalls Open Source. ---- {{wiki:thesis:web_2.0_science:21_nasa_world_wind.jpg|}} ---- Abbildung 17: Nasa World Wind [40] ---- ====5.2 Zusammenfassung Google Earth/Maps==== Resultierend aus dieser Überprüfung der Webmapping Tools wurde bei der Testimplementierung der Anwendung Google Maps/Earth verwendet, das sich durch seinen Funktionsumfang und die detaillierten Satellitenbilder auszeichnet. Im Folgenden werden alle zurzeit angebotenen Produkte von Google Earth Clients (Standard, Plus, Pro, EC) und Google Maps/API kurz erläutert. Welche Variante bei einer späteren Anwendung im Institut implementiert wird, muss anhand der Projektanforderungen noch einmal genauer spezifiziert werden. Des Weiteren wird kurz auf die geographischen Eigenschaften der Google Earth/Maps Tools eingegangen [25]. ===5.2.1 Google Earth=== Google Earth ist ein freies Desktop Tool zum Erforschen und Erstellen von Geodaten. Mit dieser Anwendung können auf einfachste Weise Geodaten aufgenommen und verarbeitet werden. Der Funktionsumfang reduziert sich allerdings auf minimale Ein- und Ausgabe der Daten. Es können KML/KMZ Dateien erstellt und ex- oder importiert werden. ===5.2.2 Google Earth Plus=== Google Earth Plus ist eine 20$ teure Erweiterung des Goolge Earth Client’s. Sie beinhaltet Erweiterungen in der Ansicht und der Arbeitsweise. Inbegriffen sind dabei ein verbesserter Netzwerkzugriff und höhere Arbeitsgeschwindigkeit, ein Import von einem GPS-Gerät[78] in Echtzeit (GPS-Tracking) wie Punkte und Polygonzüge. Zusätzlich ist ein Ausdruck höherer Auflösung als die Bildschirmauflösung inbegriffen und es können Positionen aus .CSV-Dateien[79] importiert werden. ===5.2.3 Google Earth Pro=== Google Earth Pro ist die leistungsfähigste Version und kann für 400$ erworben werden. Hier wird der Funktionsumfang um verbesserte Druckfunktionen, höhere Arbeitsgeschwindigkeit (gegen über der Plus-Version) und implementierte Forschungs-, Präsentations- und Kollaborationswerkzeuge für ortsabhängige Informationen erweitert. Dieses Tool ist für den kommerziellen Einsatz in großen Firmen vorgesehen. ===5.2.4 Google Earth EC=== Mit dieser Enterprise Lösung können eigene oder Google Datenbestände in einer Organisation oder Firma selbst gehostet werden. Dazu werden zwei Optionen angeboten (Abbildung 18). __Google Earth Enterprise Pro:__ Vollständige Unternehmenslösung zum Entwerfen und Bereitstellen eigenständiger Earth-Datenbanken. __Google Earth Enterprise LT:__ Hybride Lösung, kostengünstiger als die EC-Pro Version, die ermöglicht das lokale Hosting unternehmenseigener Datenebenen (Punkte, Vektoren, bewegte Objekte) mit der Google Earth Basiskarte zu verbinden (Preisanfragen sind aber trotz mehrmaliger Versuche von Google nicht beantwortet worden). ---- {{wiki:thesis:web_2.0_science:22_google_enterorise.jpg|}} ---- Abbildung 18: Google Earth EC Pro und LT [33] ---- __Google Maps/API:__ Über diese API können Geodaten und eigene Anwendungen direkt mit Google Maps in die eigene Webseite eingebunden werden. Dabei steht eine umfangreiche Schnittstelle zur Verfügung, mit der individuelle Funktionen auf die Karte als „Layer“ implementiert werden können. ===5.2.5 Datenformate=== Vektordaten bestehen aus Punkten, Pfaden, Linien und Polygonen. Diese Daten werden in der Geographie für die genaue Darstellung von Punkten oder Flächen verwendet. In Google (EC, Pro) können Vektordaten von anderen Anbietern importiert, angezeigt und in das KML Format umgewandelt werden. GIS-Bilddaten sind Luftaufnahmen oder Topographische Karten. Diese können in Google Earth importiert und dargestellt werden. Bei diesem Prozess werden sie als Bild-Overlay auf das Kartenmaterial des Google Earth Client adaptiert. Es können folgen Formate importiert und verwendet werden: - TIFF (.tiff), einschließlich GeoTiff[80] und komprimierte TIFF-Dateien - National Imagery Transmission Format (.ntf) - Erdas Imagine Images (.img) - Atlas MFF Raster (.hdr) - PCIDSK Database File (.pix) - Portable Pixmap Format (.pnm) - Device Independent Bitmap (.bmp) Die zu importierenden Daten müssen die richtigen Projektionsangaben enthalten, um richtig dargestellt zu werden. Unter Projektion versteht man den Prozess, die Geodaten von der dreidimensionalen Erde auf eine zweidimensionale Karte zu übertragen. Es werden zurzeit keine Daten in der NAD83 Projektion für den Import in Google Earth unterstützt [33]. ===5.2.6 Projektion und Koordinatensystem=== Geo-Daten, in Google Earth importiert, sind in einem bestimmten geographischen Koordinatensystem erstellt worden. Dieses unterteilt sich nach Projektion und Koordinatensystem wie z.B. die UTM –Projektion (Universal transversale Mercator-Projektion) mit dem ETRS89- Bezugsystem. (Abbildung 20) ---- {{wiki:thesis:web_2.0_science:23_mercator.jpg|}} ---- Abbildung 19: Mercator Projektion [33] ---- Jedes dieser Koordinatensysteme weist einer Koordinate immer einen unterschiedlichen Punkt auf der Erde zu. Wenn Geodaten nach Google Earth importiert werden, müssen diese entweder im selben geographischen Koordinatensystem sein oder vorher in diese umgewandelt werden. Geschieht das nicht, interpretiert Google (wie auch andere GIS) die Geodaten nach seinen eigenen Spezifikationen und es kann dadurch zu Abweichungen in der Darstellung kommen. Für die Projektion der Geodaten verwendet Google das lat/log WGS84-Bezugssystem in einer einfachen Zylinderprojektion. Dabei sind Längen- und Breitengrad abstandstreu und gerade parallele Linien, die sich im rechten Winkel kreuzen (Abbildung 20). Es gibt zahlreiche Projektionsarten, die aber alle (auch WGS84) eine Verzerrung von Karteneigenschaften in Fläche, Form, Richtung und Größe beinhalten. Jede Projektion hat andere Eigenschaften und geht für die genauere Darstellung von Länge oder Fläche einen Kompromiss ein, z.B. bei Form und Richtung [33]. ---- {{wiki:thesis:web_2.0_science:24_zylinderprojektion.jpg|}} ---- Abbildung 20: Zylinderprojektion [33] ---- Ein Bezugssystem (Datum oder Kartendatum) wird benötigt, um eine Projektion der Welt auf der Karte abzubilden. Benötigt wird es resultierend aus der Tatsache, dass die Erde keine perfekte Kugel sonder ein Ellipsoid[81] ist (Abbildung 21). Somit kann man die tatsächliche Form mathematisch ausdrücken und eine Zuordnung von Breiten- und Längenkoordinaten zu Punkten auf der Erdoberfläche treffen. Erweiternd dazu hat man auch eine Basis für die Höhenmessung, Berechnung und Darstellung. Auch gibt es wieder eine Vielzahl von Bezugsthemen, Google verwendet das WGS84 Bezugssystem. In Europa ist z.B. das WMF, welches auch von der UNO genutzt wird, vorherrschend. In den USA finden eher NAD 1927 / 1983 und WGS84 Anwendung [33]. ---- {{wiki:thesis:web_2.0_science:25_bezugssystem_erde.jpg|}} ---- Abbildung 21: Bezugssysteme der Erde [33] ---- ====5.3 Testumgebungen==== Resultierend aus der Untersuchung wurden eine Browser- (Google Maps) und eine Client- Applikationsvariante (Google Earth) als Testumgebung aufgesetzt. Diese sollen im folgenden Abschnitt näher betrachtet werden. Der Testaufbau ist in der Abbildung 22 dargestellt. Dabei dient ein Mac OS X 10.4.8 in der Standardinstallation als Web- und KML- Server. ---- {{wiki:thesis:web_2.0_science:26_aufbau_anwendung.jpg|}} ---- Abbildung 22: Aufbau Testanwendung ---- Auf den verwendeten Servern müssen die „Mime Typs[82]“ in der Konfigurationsdatei angepasst werden, damit diese Formate richtig verarbeitet werden. Geschieht dies nicht, wird an die Formatendung „.KML“ beim Download oder Zugriff auf den Server ein „.XML“ angehängt. \\ \\ Mime Type für das KML/KMZ Format: \\ \\ application/vnd.google-earth.kml+xml kml application/vnd.google-earth.kmz kmz \\ \\ ===5.3.1 Google Maps=== Für den Server wird ein Zugangsschlüssel für die Verwendung von Google Maps aus dem Verzeichnis des Webservers und der Domain generiert. Dieser muss in Zusammenhang mit der API in die eigene Webseite eingebunden werden. Dieses ist im folgenden Scriptbeispiel dargestellt. Die Option „''v=2''“ gibt an, welche API genutzt werden soll. Bei einem neuen Release belässt Google standardmäßig die alte Version noch einige Monate auf dem Server, damit sich alle Entwickler darauf einstellen und ihre Anwendungen anpassen können. Die Karte selbst wird über ein DIV-Element in die Webseite eingebunden. Die API basiert auf Java-Script, sodass alle Funktionen in einem ''
\\ KML/XM L-Dateien und Google Maps: \\ Um sich nicht mit der Anpassung von Größe oder Inhalt der angezeigten Punkte befassen zu müssen, können Geodaten auch über einen in Google Earth oder per Script erzeugte KML- oder XML-Datei in Google Maps eingefügt werden. Dazu wird eine Variable erzeugt, die auf eine KML-Datei verweist, welche durch map.addOverlay(kml) wie ein normales Objekt geladen wird. var kml = new GGeoXml("http://domain.de/test.kml"); map.addOverlay(kml) Es besteht darüber hinaus die Möglichkeit, Geodaten durch ein KML File direkt auf der „maps.Google.de“ Seite anzeigen zu lassen. Durch dieses Verfahren ist es möglich, Geodaten über einen Link von der eigenen Webseite anzeigen zu lassen, ohne sich mit der Google API auseinandersetzen zu müssen. Dabei werden die Geodaten vorzugsweise in Google Earth erstellt und als KML bzw. KMZ abgespeichert. Diese werden auf einem Webserver abgelegt und können per Link auf der Webseite hinterlegt werden. Durch Betätigung öffnet sich Google Maps und die gespeicherte „example.kml“ wird angezeigt. Die Option „?q=“ gibt den Ort ,an dem das KML Files zu finden ist [44] [45]. \\ \\ LINK: http://maps.google.com/maps?q=http://www.eigener_Webserver.de/example.kml ===5.3.2 KML & Formatierung=== Für die Darstellung und Verarbeitung findet das KML/ KMZ Format Verwendung, welches derzeit in der Version 2.1 vorliegt. Generell werden KML und KMZ Dateien unterschieden. KMZ Dateien sind komprimierte KML Dateien und beinhaltet alle Bilder, Overlays und Polygonmodelle. Im nachfolgenden Abschnitt sollen die wichtigsten Komponenten und Funktionen des KML-Formates kurz erläutert werden. Für weitere Spezifikationen und Syntax der KML Struktur soll in Anbetracht des Umfanges der Ausarbeitung auf die googleeigene KML Referenz verwiesen werden. Eine KML-Datei besitzt als XML-Derivat grundsätzlich immer den gleichen Aufbau. Im nachfolgenden Beispiel ist die Struktur einer einfachen KML-Datei zum Anzeigen eines Punktes dargestellt. Das gesamte Dokument muss in einem „“ Tag geschachtelt sein. In diesem ist als Attribut die Versionsnummer des Formates mit „''''“angegeben. In diesem Tag können nun alle Informationen wie Punkte, Ordnerstrukturen, Bilder, Polygonmodelle etc. eingetragen werden [41] [42] [43]. \\ Punkte: \\ \\ Ein einfacher Punkt beginnt mit „''''“, dem Tag in dem der KML Dateiname steht. Der anzuzeigende Punkt beginnt mit einem „''''“-Tag. Dieser beinhaltet als Attribut eine „''id=''“. Mit dieser können später die einzelnen Punkte angesprochen und verändert werden. Im nachfolgenden „''''“-Tag wird der Name des Punktes angegeben und der „''''“-Tag gibt den Inhalt des Beschreibungsfensters an, wenn man auf diesen klickt. Im nachfolgenden „''''“-Tag werden als letztes die Koordinaten des Punktes hinterlegt [41] [42] [43]. \\ point123.kml point1 point1 -95.44000000000001,40.42,0 __ \\ Ground Overlay’s: \\ \\ Ground Overlay’s sind Bilder oder Vektordaten, die in einer neu erzeugten Schicht (Layer) über die Karte gelegt werden können. Damit sind zusätzliche Informationen wie Pläne, Zeichnungen oder Bilder in höherer Auflösung mit dem Google Material verknüpfbar. Diese werden über das „''< GroundOverlay >''“ Tag eingesetzt. Dabei wird in „''''“ der Ort angegeben, in dem das zu implementierende Overlay zu finden ist. Des Weiteren wird über „''''“ die genaue Position und Größe des Bildes festgelegt [41] [42] [43]. \\ ur_plan UR_g.png 30.96776717842454 30.9546810857953 46.11057913647022 46.09949861981426 __ \\ Folder: \\ \\ Die eingetragenen Punkte können für die bessere Übersicht in Orderstrukturen sortiert und angezeigt werden. Dazu kann ein „''''“-Tag Verwendung finden. Dabei unterscheidet man grundsätzlich zwischen „normalen“ und „schaltbaren“ Ordern. In einem schaltbaren Ordner kann immer nur ein Unterpunkt (Punkt oder Ordner) angezeigt werden. Diese wird durch Einfügen des Tags und der Option „radioFolder“ ermöglicht, während sonst alle Elemente ein- und ausgeschaltet werden können. Per Default ist eine normale Ordnerstruktur implementiert. Eine Aufteilung in Unterordner wird durch Verschachteln der „''''“-Tags realisiert (Folder in Folder anlegen). [41] [42] [43]. \\ Test 1 Unterornder1 Unterorder1.1 Unterordner1.2 __ \\ Polygonmodelle: \\ \\ In Google Earth können über das Zusatztool Sketchup Polygonmodelle eingesetzt werden. Ein 3D Objekt wird über das Tag „''''“ eingesetzt. In „''''“ wird die Position des Models angegeben und über „''''“ die Drehung über die x-, y-, z-Achse angezeigt. Die Daten selbst werden über den „''''“-Tag eingebunden. \\ 46.10311795758702 30.96270148740241 0 2.59416006139738 0 0 SUPreview1.dae __ \\ Screen Overlay: \\ \\ Durch Screen Overlay könne in Google Earth Bilder in das sichtbare Feld über alle Kartenelemente gelegt werden. Somit könne projektbezogen Icons oder Ähnliches erstellt werden (Abbildung23) [41] [42] [43]. ---- {{wiki:thesis:web_2.0_science:27_screen_overly.jpg|}} ---- Abbildung 23: Screen Overlay MPIWG-Logo ---- \\ Mpiwg-berlin.mpg.de 1 Max-Planck-Institut für Wissenschaftsgeschichte mpiwg_logo.png __ \\ Load-File: \\ \\ Ein Load-File wird in Google Earth dazu verwendet, Informationen über eine kleine Initiialisierungsdatei (siehe Abbildung 24) vollständig von einem Server nachzuladen. Dabei wird ein Link angegeben, wo Inhalte zu finden sind. Darüber hinaus kann definiert werden, wie die Daten vom Server zu laden sind. Mit „''onInterval ''“ und „''600''“ wird angegeben, das diese im Intervall alle 600 Sekunden inkrementell zuladen sind. Nachteilig ist, daß immer alle Daten geladen und abgeglichen werden, was bei großen Projekten zu einer hohen Netzbelastung führen kann. Diese wird mit der Option "''onRegion ''" umgangen. Nun werden nur Informationen nachgeladen, wenn die entsprechende Region sichtbar wird. Darüber hinaus kann mit der Option "''onExpire''" ein serverseitiger Updateprozess erfolgen. Somit werden Daten nur übertragen, wenn sich etwas auf dem Server ändert [41] [42] [43]. ---- {{wiki:thesis:web_2.0_science:28_load_file.jpg|}} ---- Abbildung 24: Nachladen von Daten mit Load-File's [42] ---- \\ loads.kml http://.../irak.kmz onInterval 600 __ \\ Change-File: \\ \\ Um bei häufigen Intervallen nicht immer alle Daten neu laden zu müssen, kann ein Change-File eingesetzt werden. Mit diesem ist es möglich, ein Objekt (im folgenden Beispiel ein Punkt) über seine ID anzusprechen und zu ändern. Dabei bleiben alle anderen Daten unberührt. Im '''' -Tag ist beschrieben, welche KML-Datei bearbeitet werden soll. Danach wird im '''' -Tag angegeben, was und wie geändert wird [41] [42] [43]. \\ point.kml Name changed by Update Change __ \\ ===5.3.3 Implementierte Daten=== {{wiki:thesis:web_2.0_science:29_irak.jpg | This is the caption}} In der Testanwendung sollen die bereit erwähnten Aus-grabungspunkte von Ur, Uruk und Nimrut im Irak visualisiert werden. Dabei wurden Ausgrabungspläne bzw. Material von dem CDLI/ MPIWG freundlicherweise zur Verfügung gestellt. Diese Pläne liegen im Encapsulated PostScript[85] Format vor und müssen für die Darstellung in Google Earth/Maps umgewandelt werden. Dabei wurde PNG durch die Bereitstellung des transparenten Layer für die Anzeige verwendet. Die Polygonenmodele liegen im .max[86]-Format vor und müssen bei der Verarbeitung in das .3ds[87]-Format umgewandelt werden. Dieses Format wird in den von Google kostenlos zu Verfügung gestellten 3d Tool ScetchUp[88] importiert und kann von dort aus in Google Earth eingesetzt werden [47]. ---- \\ ===5.3.4 Google Maps=== Zunächst wurde die Google Maps „API“ in ein HTML-Seite adaptiert. Durch diese ist es nun möglich, Satellitenkartenmaterial in eine selbst gestaltete Webseite einzubinden. Als Koordinaten wurden die zuvor erwähnten Punkte Ur, Uruk und Nimrod in die Testumgebung eingebunden. Die Geodaten wurden in dem Filesystem eines Webservers als KML Dateien abgelegt und können über PHP/Javascript ausgelesen und dargestellt werden. Bei größeren Datenmengen ist auch die Verwendung einer Datenbank vorgesehen. In den KML-Daten sind unter anderem alle georelevanten Informationen und die Ausgrabungskarten als „overlay“ zusammengefasst. ===5.3.5 Google Earth=== Als nächstes wurden die gleichen Testdaten in eine Google Earth Applikation eingebunden. Vorteil dieser Anwendung ist die maßstabsgerechte Darstellung von Ruinen oder anderen Rekonstruktionen in dreidimensionalen Abbildungen. Die Verteilung der Informationen kann aus Implementierungsgründen nicht wie bei Google Maps über den Webserver erfolgen, daher wurde ein KML-Loadfile[89] generiert, welches auf einen KML-Server[90] referenziert. ====5.4 Resultate==== Nach der Untersuchung der Testanwendungen wurde festgestellt, dass sich Web 2.0 Technologien und Techniken (Google Earth/Maps) in vollem Umfang für die Bearbeitung von wissenschaftlichen Projekten und deren Visualisierung eignen. Durch den Einsatz von Satelliten- und Überflugkarten ist es erstmals gelungen, Ausgrabungspläne und Fundorte digital für jede Person im Zusammenhang zugänglich zu machen. Im nächsten Abschnitt werden die Vorteile einer Google Earth/Maps Anwendung kurz erläutert. ===5.4.1 Ergebnisse Google Map=== Google Maps ist – über die Google API in die Webseite integriert – ein vielfältiges Tool für die Produktion von eigenen Geo-Web-Anwendungen und Services. Durch Unterstützung von Ajax kann man eine fast Desktop-ähnliche Arbeitsumgebung schaffen (Abbildung 25 und 26), in der nicht nur Ausgrabungspunkte bearbeitet werden können. Ferner lassen sich Anwendungen für alle Arten von Projekten entwickeln, bei denen es einer Verknüpfung bzw. Visualisierung von Geodaten bedarf. In Verbindung mit Wiki- und Blog- Technologien lässt sich auch eine komplette Arbeitsumgebung für geographisch getrennt arbeitende Projektgruppen entwickeln. Die Geodaten werden in einem XML- konformen Format gespeichert (KML/KMZ). Somit ist es möglich, die angesammelten Informationen bei einer Änderung oder Einstellung des KML Formates von Google in ein anderes XML Format einzufügen. Diese stehen allen weiteren Prozessen zur Verfügung und es ist somit keine direkte Abhängigkeit von dem Google Format gegeben. ---- {{wiki:thesis:web_2.0_science:30_google_maps.jpg|}} ---- Abbildung 25: Testanwendung Google Maps (Grabungsplan Uruk in der Übersicht) ---- {{wiki:thesis:web_2.0_science:31_google_maps.jpg|}} ---- Abbildung 26: Testanwendung Google Maps (Grabungsplan Uruk Großprojektion) ---- Leider fehlt in Google Maps noch die Möglichkeit der Einbindung von dreidimensionalen Objekten. Dieses kann unter Zuhilfenahme eines Flash Layer in der Anwendung (nur bei der Google API möglich), oder durch Implementierung der Objekte als Quick Time VR nachempfunden werden. In der Testanwendung ist die letztere Variante aus Gründen der einfachen Umsetzung implementiert (Abbildung 27). Dabei werden die Polygonmodelle in C4D angepasst und als Quick Time VR gerendert [47]. {{mpeg>http://cdli.mpiwg-berlin.mpg.de/dokuwiki/cdli_ur_klein.mp4 [400,400] | gegrregerg}} Abbildung 27: 3D-Darstellung mit Quicktime VR ===5.4.2 Ergebnisse Google Earth=== Google Earth ist im Vergleich zu Google Maps eine Applikation, die auf dem Desktop des Users läuft. Diese kann ebenfalls KM-Dateien lesen bzw. erzeugen und hat gegenüber Google Maps den Vorteil, dass eine dreidimensionale Sicht auf das Kartenmaterial ermöglicht wird. In diesem Zusammenhang wird ebenfalls deutlich, dass durch die Implementierung eigener Karten bei schlechten Satellitenbildern durchaus auch eine effektive Visualisierung ermöglicht wird (Abbildung 28). In Google Maps kann dieses ebenfalls realisiert werden. ---- {{wiki:thesis:web_2.0_science:32_fundorte.jpg?700|}} ---- Abbildung 28: Markierung von Fundorten in Uruk ---- Ein weiteres Feature ist die Markierung und Beschreibung von Polygonzügen. Dabei wird ein bestimmter Bereich auf der Karte zusammengefasst und mit Informationen versehen. In einer Datenbank hinterlegt, können diese Informationen miteinander in Verbindung gesetzt werden. Es besteht die Möglichkeit, einzelne Koordinaten diesen Feldern zuzuordnen bzw. zu bestimmen (Abbildung 29). ---- {{wiki:thesis:web_2.0_science:33_fundorte.jpg?700|}} ---- Abbildung 29: Beispiel für die Bezeichnung bzw. Markierung eines Weges in Nimrud ---- {{wiki:thesis:web_2.0_science:34_topographie.jpg?700|}} ---- Abbildung 30: Einbeziehung von topographischen Merkmalen Eine weitere Möglichkeit der Visualisierung ist die Einbeziehung von Höheninformation in die Satellitenbilder. Damit können Ruinen sehr deutlich in ihrem räumlichen Bezug gesehen und dargestellt werden. Somit kann man feststellen, das Nimrud wahrscheinlich auf einer Erhöhung gelegen hat (Abbildung 30). Darüber hinaus können dreidimensionale Modelle z.B. in Form von Ruinen oder Rekonstruktionen in die Karten eingebunden werden. Bei diesem Prozess werden Polygonmodelle anhand von Grabungsplänen und Rekonstruktionen angefertigt. Diese werden (wie oben beschrieben) über ein Google eigenes Tool (Sketchup) in den Earth Client eingebunden und ebenfalls als KML abgespeichert (Abbildung 31-32). Der Datenaustausch läuft nach Upload der Daten auf den KML-Server und Generierung des Loadfiles ohne Probleme. Auch die Flickr Implementierung in der Testanwendung führte zu guten Ergebnissen. Dabei wird ein „Link“ im Tag des KML-Files angegeben, der auf einen Flickr-Account „297268074“ referenziert und von diesem ein Bild „107/297268074 _b53f8f3feb_t.jpg“ lädt. Anschließend werden nur noch die Größe und Bezeichnung angegeben. ur12 Wie in Abbildung 33 zu sehen, ist durch die Kombination von Overlays und 3D Modellen eine fast perfekte Visualisierung von Ausgrabungsorten möglich. Diese können in Google Earth editiert und als KML abgespeichert werden. Danach müssen die Daten aber per Hand auf einen Server geladen werden, denn zurzeit ist keine Uploadfunktion von im kostenfreien Client erstellten Geodaten zum eigenen Publishing-Server möglich. ---- {{wiki:thesis:web_2.0_science:35_polygonmodel.jpg?700|}} ---- Abbildung 31 Polygonmodel in Sketchup ---- {{wiki:thesis:web_2.0_science:36_polygonmodel.jpg?700|}} ---- Abbildung 32: fertige 3D Rekonstruktion der Ziggurat von Ur in Google Earth ---- {{wiki:thesis:web_2.0_science:37_komplett.jpg?700|}} ---- Abbildung 33: Kombinierter Einsatz von Overlays, 3D Rekonstruktionen und Flickr ====5.5 Zusammenfassung==== Google Earth und Maps müssen nicht getrennt voneinander betrachtet werden. In ihrer Kombination kann man die Stärken der beiden Tools vereinen und eine völlig neue Arbeit und Präsentationsumgebung schaffen. In der Google Maps Anwendung werden die Koordinaten anlegt oder über eine Upload-Funktion von in Google Earth erstellten KML-Files hochgeladen. Durch die API können alle Funktionen kostengünstig (vergleichend Google Earth Pro oder Enterprise) selbst den Bedürfnissen angepasst werden. Dagegen ist Google Earth ein weitaus besseres Präsentationsmedium in dem es mit der „Plus“ Version möglich ist, Videos von seinen Kameraflügen über projektrelevante Punkte aufzuzeichnen. Daten, die mit Google Maps auf dem Server als KML File hinterlegt wurden, können über das Load-File ganz einfach in Google Earth integriert werden. Dazu muss ein KML-Server entwickelt werden, der die Verwaltung der einzelnen Files übernimmt und die Verknüpfung zwischen Google Earth und Maps realisiert. Außerdem könne auf diesem Server auch die Verbindungen zu andern Datenbanken integriert werden. __Probleme in der Testanwendung:__ Als Fragestellung ergeben sich aus diesem Projekt die Punkte der Abhängigkeit von Google Earth/Maps und die Verwendung des google-eigenem KML Format als Datenträger. Google kann seinen Service natürlich ohne weiteres einstellen und die Benutzung von KML-Formaten untersagen. Beim Eintreten dieser (aus heutiger Sicht unwahrscheinlichen) Situation besteht die Möglichkeit, einen eigen Map-Server aufzusetzen und die KML-Files wie erwähnt in ein anderes XML-Format wie GML umzuwandeln. Als Ersatz für das GIS kann „Nasa World Wind“ Verwendung finden. Diese steht unter Open Source zur Verfügung und beinhaltet auch frei verwendbares Kartenmaterial. Somit ist die Gefahr einer Abhängigkeit von Google eher gering [48].