Kurzfassung 2

Kurzfassung

Gegenstand der hier vorgestellten Arbeit ist eine Untersuchung von Mashups. Hierbei wird speziell auf den von Google zur Verfügung gestellten Google-Maps-Dienst eingegangen, der als Grundlage eines Mashups dienen kann. In der Seminarveranstaltung „IT-Workshop“ hat dieser Dienst in der Applikation „Basketball-Freiplatzverzeichnis“ bereits seine Anwendung gefunden. Diese Beispielapplikation ist ihrerseits eine Erweiterung des bestehenden Freiplatzangebotes der Webseite Crossover-online.de und verbessert dadurch nicht nur die visuelle Darstellung, sondern auch die Bedienbarkeit der Anwendung. Diese Applikation dient als Ausgangspunkt der Untersuchungen. Die hier vorliegende Arbeit bietet eine allgemeine Übersicht über die Stärken und Schwächen von Mashups. Darüber hinaus geht diese Untersuchung auf die speziellen Möglichkeiten ein, die Google mit seinem zur Verfügung gestellten Kartenservice und der dahinterstehenden Programmierschnittstelle bietet. Hierbei werden die Grenzen des Umsetzbaren dieser browserbasierten Anwendung aufgezeigt und mit sinnvollen Lösungsansätzen die entstandenen Problematiken gelöst.

Schlagwörter: Mashup, Google Maps, Programmierschnittstelle, Content Syndication, Aggregation 2.0

Abstract

The present research is an investigation of mashups. Therefore a special view on Google’s maps service is taken which builds the main tool for aggregation in mashups in the internet. The application “index of basketball courts” on crossover-online.de represents the basis of this exploration.

The first subject is about defining mashups and the technologies that are in use for them. After the global view on the technique of mashups, a more detailed examination of limits and problems of the Google Maps service and the corresponding application programming interface are explored. Furthermore the investigation identifies possible resolutions for the restrictions of the used technique. Keywords: Mashup, Google Maps, application programming interface, content syndi- cation, Aggregation 2.0

Inhaltsverzeichnis 3

Inhaltsverzeichnis   

Kurzfassung   2

Abstract   2

Inhaltsverzeichnis   3

Abbildungsverzeichnis   5

Tabellenverzeichnis   5

Abk  ürzungsverzeichnis  6

Zielsetzung   7

1  Grundlagen von Mashups  8

1.1  Was sind Mashups  8

1.2  Wichtigkeit von Metadaten  10

1.3  Rich Internet Application  10

1.4  Abgrenzung zu serviceorientierter Architektur  11

2  Technische Aspekte der Mashups  12

2.1  AJAX  12

2.2  Application Programming Interface (API)  13

2.3  Architekturformen von Mashups  13

2.3.1  Client-Side-Mashups  13

2.3.2  Server-Side-Mashup  14

2.4  Geeignete Mashup Programmiermodelle  15

2.5  Kommunikationsformate  15

2.5.1  Anforderungsformate  15

2.5.2  Ausgabeformate  17

3  Google Maps  19

3.1  Key-Features  19

3.2  Verwendete Technik  20

4  Mashup-Anwendung: Freiplatzverzeichnis  22

4.1  Beschreibung der Anwendung  22

4.1.1  Aufbau  22

4.1.2  Umsetzung  23

4.2  Möglichkeiten und Grenzen von Google Maps Mashups  24

Inhaltsverzeichnis 4

4.2.1  Geokodierung  24

4.2.2  Umgekehrte Geokodierung  26

4.2.3  Datenintegration mit KML  26

4.2.4  Darstellung von Overlays  29

4.2.5  Darstellung der Marker  32

5  Zusammenfassung und Ausblick  36

Quellenverzeichnis   38

Abbildungsverzeichnis   

Abbildungsverzeichnis   

Abbildung  1: Hype Cycle 2007 von Gartner  

Abbildung  2: Mashup-Matrix  

Abbildung  4: Client-Side-Mashup  

Abbildung  5: Server-Side-Mashup  

Abbildung  6: Erstellte Google Maps Anwendung  

Abbildung  7: Aufbau der Applikation  

Abbildung  8: Darstellung der Polyline  

Abbildung  9: Clusterung der Google Karte  

Tabellenverzeichnis   

Tabelle 1:  Begrenzung der Geokodierung  

Tabelle 2:  Vergleich zwischen KML und KMZ  

Tabelle 3:  Vergleich zwischen JSON und KML  

Tabelle 4:  Begrenzungen der Browser  

Abkürzungsverzeichnis 6

Abkürzungsverzeichnis

AJAX Asynchronous JavaScript and XML API Application Programming Interface ASCII American Standard Code for Information Interchange CSS Cascading Style Sheets DOM Document Object Model GIS Geographisches Infromationssystem HTML Hypertext Markup Language HTTP Hypertext Transport Protocol JSON JavaScript Object Notation KML Keyhole Markup Language MIME Multipurpose Internet Mail Extensions OGC Open Geospatial Consortium REST Representational State Transfer RIA Rich Internet Application SOA Serviceorientierte Architektur SVG Scalable Vector Graphics SWIG Simplified Wrapper and Interface Generator URL Uniform Resource Locator VML Vector Markup Language W3C World Wide Web Consortium XHTML Extensible HypeText Markup Language XML Extensible Markup Language XSLT Extensible Stylesheet Language Transformation

Zielsetzung 7

Zielsetzung

Das Ziel dieser Arbeit ist es, einen Einblick in die Technik der Mashup-Anwendungen zu geben, die mittels des Google-Maps-Service realisiert werden. Bevor jedoch die Google-Maps-Technik näher betrachtet werden kann, ist es notwendig einen allgemeinen Einblick in die Mashup-Technik zu geben. Hiernach wird der Fokus auf die Chancen und Möglichkeiten dieser Technik gelenkt, welche den wichtigsten Bestandteil dieser Arbeit darstellen. Um diese zu ermitteln, müssen die bedeutendsten Merkmale einer Google Map herausgearbeitet und untersucht werden. Diese teilen sich dabei in die Geokodierung zur Ermittlung der Geoinformationen, der Datenintegration bestehender Geodaten mittels dem Standardintegrationsformat KML, sowie die verschiedenen Darstellungsmöglichkeiten die eine Google-Maps-Anwendung bietet, auf. Die aus näherer Betrachtung ermittelten Limitierungen lassen dabei Problemstellungen entstehen, für die existierende kreative Lösungswege gefunden und aufgezeigt werden sollen. Diese Lösungswege werden dabei mit Hilfe von Google selbst oder mit Lösungsansätzen von Dritten realisiert. Aus den Beobachtungen der Problem- und Lösungswegfindung erfolgt anschließend eine Bewertung über den tatsächlichen Sinn der existierenden Problemstellung. Dabei gilt es zu beachten, dass nicht jede Problematik, die sich in einer Google Map ergibt auch sinnvoll gelöst werden kann, da die Mashup-Technik zu abhängig von der eingesetzten Browser-, Übertragungs- und Servertechnik ist.

Aus diesem Grund ist es wichtig, die Grenzen der Google-Maps-Mashup-Technik zu kennen und aus diesen sinnvolle Möglichkeiten abzuleiten, damit diese Technik ziel- orientiert eingesetzt werden kann.

1 Grundlagen von Mashups 8

1 Grundlagen von Mashups

1.1 Was sind Mashups

Der Begriff „Mashup“ stammt ursprünglich aus der Musikszene und beschreibt das Vermischen von Liedern verschiedener Musikrichtungen miteinander. Das daraus entstehende neue Lied stellt trotz seiner hörbaren Ursprungsklänge ein völlig neues Klangerlebnis dar. (vgl. Carl, 2008, S.3)

Dieser Grundgedanke des „Vermischens“ ist im Internet übernommen worden. Hierbei vermischen Mashups Daten verschiedener Inhaltsanbieter miteinander und schaffen somit neue Applikationen, die einen bis dahin nicht erreichten Mehrwert bieten können. (vgl. Alby, 2007, S.133) Der Autor Frank Schönefeld definiert in der Computerwoche Mashups, als eine Software, die „zwei oder mehrere Web-Dienstleistungen in einer neuen Anwendung (Webapplikation)“ integriert. (Schönefeld, 2007) Diese „Integration kann auf Daten-, Logik- und Darstellungsebenen“ vollzogen werden. (Ebd.) Das entscheidende Merkmal ist dabei, dass „sich Mashups durch einfache Overlays, Kombinationen und kaum zeitliche oder logische Abhängigkeiten“ auszeichnen. (Ebd.) Durch die einfache Verwendbarkeit und die leicht zu erreichenden sichtbaren Ergebnisse steigt die Anzahl der Mashup-Applikationen täglich an. Nicht zuletzt durch die zahlreichen Inhaltsanbieter und den verwendbaren Werkzeugen, wie YAHOO! Pipes (vgl. YAHOO! Pipes, 2008) oder dem Google Mashup Editor (vgl. Google Mashup Editor, 2008), ist es möglich, ohne tiefer gehende technische Kenntnisse eine Mashup-Applikation zu erstellen. Dies führt dazu, dass längst nicht mehr nur von einem Mashup-Trend gesprochen werden kann, sondern durchaus von einem Mashup-Hype. (vgl. Hassler, 2008, S.65) Dies hat auch das IT-Research und Beratungshaus Gartner analysiert und führt in ihrem jährlich erscheinenden Trendbarometer, dem sogenannten Hy- pe-Cycle, die Mashup-Technologie bereits seit dem Beginn der Web 2.0 Ära auf.

1 Grundlagen von Mashups 9

Nach dem aktuell veröffentlichten Hype-Cycle von 2007 befindet sich die Mashup-Technologie derzeit noch in der Phase der hohen, teilweise unrealistischen Erwartungen an die Technik. Trotz dieser eher kritischen Betrachtung stellt Gartner in ihrer Prognose fest, dass sich „bis 2010 […] Web-Mashups […] zum dominierenden Modell (80 Prozent) für die Erstellung zusammengesetzter Unternehmensanwendungen entwickeln“ werden. (Gartner, 2007 zit. n. Computerwoche, 2007) So sollen sich die „Mashup-Techniken […] in den nächsten fünf Jahren deutlich weiterentwickeln“. (Ebd.) Die Analyse der Gartner Group ist jedoch kein Grund, Mashups wegen der momentan eher kritisch-analysierten Phase abzuwerten. Laut Hassler sollte man sich, unabhängig von der Analyse, bereits „zum jetzigen Zeitpunkt“ damit „auseinandersetzen wie ein langfristiger Geschäftsnutzen mit einem Mashup erreicht werden kann“. (Hassler, 2008, S.67) So kann der eigene langfristige Erfolg mit dieser Technologie gesichert werden und muss sich nicht „in die Reihe der erfolglosen Anwendungen einer gerade gehypten Technologie“ stellen. (Ebd.)

1 Grundlagen von Mashups 10

1.2 Wichtigkeit von Metadaten

Metadaten stellen „Daten über Daten“ oder, konkreter definiert, „Informationen zu Daten“ dar. (IT-Wissen, 2008) Diese Informationen sind innerhalb einer Mashup-Anwendung von großer Wichtigkeit. Sie sind der „Anknüpfungspunkt für den Datenmix“ (Kang, 2007) und ermöglichen somit erst die Aggregation der verschiedenen Dienste miteinander.

Wie in der Abbildung der Mashup-Matrix ersichtlich, bilden die Knotenpunkte eine Mashup-Applikation. So entsteht aus Fotodaten und Kartendaten eine Applikation, die beispielsweise durch ein Google-Maps-Flickr-Mashup miteinander aggregiert werden kann.

1.3 Rich Internet Application

Der Begriff „Rich Internet Application“ (RIA) beschreibt ein Spektrum von Applikationen und Technologien, welche intuitive Benutzeroberflächen ähnlich einer Desktop Applikation bieten. Der einfachste Bereich wird dabei von AJAX bzw. Web 2.0 Applikationen abgedeckt, die bessere Bedien- und Ansprechbarkeit zu Standard-Webseiten hinzufügen. (vgl. Heller, 2007)

Der Internetvisionär und Verleger Tim O’Reilly sieht hierbei vor allen Dingen die Google Applikationen GMail und Google Maps als Auslöser für webbasierte Anwendungen, die mit Desktop ähnlicher Bedienung und Interaktion kombiniert werden. Diese Applikationen sind somit für ihn der erste Schritt, um das vorhandene Potential des Internets zu voll skalierbaren Applikationen hin auszubauen. (vgl., O’Reilly, 2005) Den Web 2.0 Applikationen wird auch die Mashup-Technologie zugeschrieben. (vgl. Carl, 2008, S.16) Das Baukastenprinzip der Mashup-Technik erlaubt es, eine schnellere und einfachere Integration neuer Funktionalitäten oder kompletter Anwendungen in einer bestehenden Webseite zu realisieren. Auf Basis von beispielsweise Google Maps lassen sich somit einfach und schnell anwendungsfallbezogene Lösungen erstellen, die mit weiteren Webdiensten aggregiert werden können. Gleichzeitig wird durch die An-

1 Grundlagen von Mashups 11

wendung entsprechender Mashupdienste der Mehrwert der Webseite durch die gesteigerte Interaktivität und verbesserte Bedienbarkeit erweitert.

1.4 Abgrenzung zu serviceorientierter Architektur

Die Service-orientierte Architektur (SOA) wird als „ein Softwarekonzept, bei dem einzelne Systeme, die sogenannten Services, bestimmte thematisch abgegrenzte Funktionalitäten und Daten anbieten“ beschrieben. (Carl, 2008, S.17) Diese Beschreibung kann somit auch auf die Mashup-Technologie übertragen werden. Denn vereinfacht betrachtet unterscheidet sich eine Service-orientierte Architektur nicht wesentlich von einer Mashup-Applikation. Dies bestätigt auch der Autor Denny Carl mit seiner These, dass „das ganze Web als SOA angesehen“ werden kann. (Ebd.) Hierbei spricht er zwar vom Web 2.0, jedoch definiert er auch: „ein Mashup ist demnach eine Software, die sich diverse Services der globalen SOA zunutze macht“. (Ebd.)

Die Service-orientierte Architektur besitzt jedoch einen viel komplexeren Ansatz, der weit über das Web hinausgeht. Frank Schönefeld ordnet Mashups zwar als Unterbegriff der SOA-Technologie zu, erkennt jedoch, dass „bewusst auf den komplizierten SOA-Orchestrierungsapparat“ verzichtet wird und bezeichnet die Mashup-Technologie deshalb „als eine Art SOA-Light“, speziell für das Internet. (Schönefeld, 2007) Daraus leitet er die entsprechenden Einsatzgebiete der beiden Technologien ab: Während SOA-Applikationen „komplexe Logik und Abhängigkeiten zwischen den Diensten realisieren, zeichnen sich Mashups durch einfache Overlays, Kombinationen und kaum zeitliche oder logische Abhängigkeiten aus“. (Ebd.)

2 Technische Aspekte der Mashups 12

2 Technische Aspekte der Mashups

2.1 AJAX

Der Begriff Ajax steht für Asyncronous JavaScript and XML und wurde erstmals von Jesse James Garrett in seinem Aufsatz „A New Approach to Web Applications“ im Jahr 2005 geprägt. Die akronyme Bedeutung dieser vier Worte hat AJAX jedoch längst ver-loren. Viel mehr existieren für AJAX zwei verbreitete Auffassungen, welche im Folgenden erläutert werden. (vgl. Gehtland/Galbraith, 2006, S.5) AJAX: Die Technologie

AJAX kann als eine Ansammlung von dynamisch agierenden Technologien gesehen werden, die es erlaubt, einen asynchronen Kommunikationskanal zwischen dem Browser und dem Server herzustellen. (vgl. Gehtland/Galbraith, 2006, S.5) In der Definition von AJAX wurden folgende Technologien festgehalten:

- Präsentationsform von XHTML und CSS

- Dynamische Anzeige und Interaktion mit dem Dokument Objekt Model (DOM) des Browsers

- Datenaustausch und Manipulation mittels XML und XSLT

- Asynchrone Datenabfrage unter Benutzung des XMLHttpRequest-Objekts

- JavaScript verbindet alle verwendeten Technologien (vgl. Steyer, 2007, S.12) AJAX: Die Architektur

AJAX kann „als Sammelbegriff verwendet“ werden, „für eine Architektur, die bisher mit Webseiten nicht möglich war“. (Alby, 2007, S.135) Dabei werden asynchrone Anfragen vom Browser an den Server gesendet, die serverseitige Ereignisse auslösen können, unbemerkt vom Benutzer. (vgl. Gehtland/Galbraith, 2006, S.14)

Die Mashup-Technologie verwendet ähnliche Architekturformen. Diese basieren jedoch nur zum Teil auf der hier vorgestellten AJAX-Architektur. Deshalb soll in dieser Arbeit der Begriff AJAX nur in Form einer Ansammlung von Technologien verwendet wer- den.

2  Technische Aspekte der Mashups  13

2.2  Application Programming Interface (API)  

Damit  ein Mashup die entsprechenden Daten eines Content-Providers nutzen kann, ist  

ein  Application Programming Interface (API) notwendig. Dieses ermöglicht „im Netz  

den  standardisierten Zugriff auf Daten“ eines Content-Providers, um diese selbst wei-  

terverarbeiten  zu können. (Carl, 2008, S.17) Um sinnvoll mit den Daten eines Content-  

Providers  arbeiten zu können, ist eine Öffnung der Inhalte für Dritte notwendig, da  

„Applikationen  im Web grundsätzlich geschlossene Systeme“ sind. (Carl,  

2008,  S.18) Diese können jedoch über Schnittstellen „offener gestaltet werden“ (Ebd.)  

Dazu  wird der „externe Zugriff auf Daten und Anwendungen über festgeschriebene  

Vorgehensweisen“  ermöglicht. (Ebd.)  

Eine  API bildet somit „die wichtigste Komponente einer Applikation, um Teil einer  

gr  ößeren Applikation“, wie beispielsweise einer Mashup-Applikation zu werden. (Alby,  

2007,  S.133) Bei der Verwendung existieren keinerlei Beschränkungen die Anzahl der  

verwendeten  APIs betreffend. Diese können beliebig miteinander kombiniert werden  

und  schaffen somit einen Nutzen, der von den Content-Providern in der neu entstande-  

nen  Form nicht vorgesehen war. Der Autor Tom Alby folgert daraus: „So wie der Re-  

mix  ein Teil der Social-Software-Kultur ist, so wird er es auch im Gebrauch von APIs.“  

  (Alby, 2007, S.133)  

2.3  Architekturformen von Mashups  

Die  Architektur von Mashups kann nicht klar definiert werden. Es existieren für viele  

unterschiedliche  Anwendungsfälle verschiedene Lösungsmöglichkeiten. Die Autoren  

Ed  Ort, Sean Brydon und Mark Basler haben Mashups dennoch definiert und zwei ex-  

treme  Ausprägungen festgehalten. Diese beiden Definitionen finden jedoch ausschließ-  

lich  in der JAVA-Welt ihre vollständige Gültigkeit, weshalb die nachfolgenden Ausfüh-  

rungen  dieser beiden Extremformen an die allgemeinen Techniken des Internets ange-  

passt  werden. (vgl. Ort/Brydon, 2007)  

2.3.1  Client-Side-Mashups  

In  einem Client-Side-Mashup läuft die komplette Applikation innerhalb der Browser-  

umgebung  ab. Die getätigte Eingabe eines Users über das User-Interface wird von der  

Applikationslogik  verarbeitet. Von dieser werden die benötigten Daten vom Client über  

einen  Http-Request angefordert und direkt von der API des Content-Providers verarbei-  

tet.  Das Ergebnis wird mittels eines Http-Response wieder zurückgegeben. Die Appli-  

kationslogik  verarbeitet hierauf die erhaltenen Daten und aktualisiert die Darstellung  

2 Technische Aspekte der Mashups 14

2.3.2 Server-Side-Mashup

In einem Server-Side-Mashup stellt der Client die Anfrage für die benötigten Daten an den Webserver. Dieser schickt eine der API des Content-Providers entsprechenden Anfrage über den Http-Request an die entsprechende API weiter. Der Http-Response des Content-Providers wird vom Webserver verarbeitet und für die Darstellung im Client aufbereitet. Der Client erhält die Daten des Webservers bereits in einer Form, die keine weitere Verarbeitung benötigt. Die Applikationslogik des Client muss somit nur noch für die Aktualisierung der Darstellung sorgen.

2 Technische Aspekte der Mashups 15

2.4 Geeignete Mashup Programmiermodelle

Zur Umsetzung von Mashup-Applikationen, die eine flexible und schnelle Reaktion auf neue Anforderungen benötigen, sind entsprechende Methoden der Softwareentwicklung erforderlich. Ein Oberbegriff, auf den derartige Anforderungen zutreffen, stellt das Agile Programming dar.

Das Agile Programming stellt keine vollständige Methode der Softwareentwicklung dar, sondern beinhaltet Schwerpunkte verschiedener Methoden. Dabei basiert die agile Softwareentwicklung auf der kontinuierlichen Weiterentwicklung der Software. Die Funktionsfähigkeit der Applikation stellt das oberste Ziel dar, während der Planung und Dokumentation weniger Bedeutung zugesprochen wird. Um das Ziel zu erreichen, ist vor allen Dingen eine offene Kommunikation zwischen den Projektmitgliedern notwendig, da der effektivste Lösungsweg verwendet und dies vom gesamten Projektteam mitgetragen werden soll. (vgl. Stephken, 2008) Eine populäre daraus abgeleitete Methode des Agile Programming stellt das Rapid Application Development dar. Rapid Application Development

Im Internet existieren unzählige Web 2.0 Applikationen mit der Kennzeichnung „Beta“. Dies ist auf die Rapid-Application-Development-Methode zurückzuführen. Ein prototypisches Vorgehen erlaubt es, die bisher bekannten Anforderungen möglichst schnell in funktionierenden Code umzusetzen. (vgl. Marick, 1997) So verkürzt sich die Entwicklungszeit bis zur Veröffentlichung der Seite rapide und während der Besucher bereits die vorhandene Webseite nutzen kann, wird im Hintergrund bereits an weiteren geplanten oder durch Besucher angeregten Funktionen gearbeitet. (vgl. Carl, 2008, S.18f)

2.5 Kommunikationsformate

Es existieren verschiedene Möglichkeiten, wie externe Daten angefordert und auf diese zugegriffen werden kann. Nachfolgend werden die relevantesten Formate für die Google-Maps-Mashup-Technik in ihrer Funktionsweise erläutert. Eine frei wählbare Kombination der Anforderungs- und Ausgabeformate ist problemlos möglich.

2.5.1 Anforderungsformate REST

Das am häufigsten verwendete Anforderungsformat ist REST. Ausgeschrieben stehen diese Buchstaben für REpresentational State Transfer. (vgl. Carl, 2008, S.22) Dahinter steht ein Konzept, das „im Vergleich zu ähnlichen Konzepten recht einfach“ ist und nur „auf wenigen Regeln“ basiert. (Carl, 2008, S.22)

2 Technische Aspekte der Mashups 16

Die Architektur basiert auf einem GET- und RESPONSE-Model, bei dem mittels der URL Anfragen gestellt werden. Die Antwort der Webapplikation erfolgt in einem entsprechenden Ausgabeformat. (vgl. Freedman, 2007, S.10) Aus dieser Beschreibung folgt, dass das „gesamte Web durch intensive Verlinkung der Websites untereinander eine einzige riesige REST-Anwendung“ darstellt. (Carl, 2008, S.22) Beispiel Youtube:

Über die URL werden von Youtube Daten angefragt, welche durch Parameter genauer spezifiziert werden können. Die Parameterangaben sind hierbei das Ausgabeformat „RSS“, der Suchbegriff „Mashup“ sowie die maximale Trefferanzahl von „10“. JavaScript

Im Gegensatz zu REST läuft die Benutzung der JavaScript gesteuerten API komplett innerhalb der Browser-Umgebung ab. Die externe Anwendung existiert demzufolge virtuell in der eigenen Applikation. (vgl. Carl, 2008, S.32) Dazu muss eine externe JavaScript-Datei des API Anbieters in die Anwendung einge-bunden werden. Anschließend kann auf die Objekte, Funktionen und Variablen, mit denen die externe Anwendung gesteuert wird, zugegriffen werden, als wären diese auf dem Clientrechner. Die eigene Server-Komponente muss somit keine speziellen Anforderungen besitzen, da die Verarbeitung direkt vom Browser übernommen wird. (vgl. Carl, 2008, S.32f) Beispiel Google Maps:

Die eingebundene JavaScript-Datei wird durch die beiden Google-Maps-Funktionen, GBrowserIsCompatible und GMap2, verwendet. Das zurückgegebene Objekt der GMap2-Funktion wird in der Variablen map gespeichert und kann beispielsweise die Google-Objekt-Funktion setCenter aufrufen.

2 Technische Aspekte der Mashups 17

2.5.2 Ausgabeformate XML

XML ist die Abkürzung für Extensible Markup Language und beschreibt einen „platt-formneutralen Klartextstandard auf Unicode-Basis zur Erstellung maschinen- und menschenlesbarer Dokumente“. (Steyer, 2007, S.189) XML ist wie HTML eine Auszeichnungssprache, mit der „komplex strukturierte Daten“ abgebildet werden können. (Carl, 2008, S.38) Jedoch lassen sich mit XML, ganz im Gegensatz zu HTML, nur Daten strukturieren und nicht formatieren. „Die XML-Spezifikation ist streng formal und lässt keine Ausnahmen und unklare Strukturen zu.“ (Steyer, 2007, S.190) Daraus lässt sich ableiten, dass die Verarbeitung durch eine vereinfachte Automatisierung erfolgen kann und durch die klare Struktur überaus gut als Datenaustauschformat geeignet ist. Beispielsyntax:

XML stellt dank seiner Flexibilität den bekanntesten Weg dar, um Daten zwischen Webseiten, Softwareanwendungen und Betriebssystemen auszutauschen. (vgl. Hammersly, 2003, S.180) JSON

Das Datenformat JSON (JavaScript Object Notation) ist, wie auch XML, ein reines Textformat. Die zentrale Komponente von JSON ist, wie im Namen bereits ersichtlich, JavaScript. JSON basiert auf der Verwendung eines JavaScript-Objekts, das selbst aus Objekt-, String-, Zahlen-, Array- und Boolean-Werten bestehen kann. (vgl. Carl, 2008, S.41) Beispielsyntax:

„Im Gegensatz zu XML ist der Daten-Overhead bei JSON wesentlich geringer“, da JSON eine sehr kompakte und auf ein Minimum reduzierte Syntax besitzt. (Carl, 2008, S.42) Darüber hinaus ist der Zugriff der im JSON-Format empfangenen Daten mittels

2  Technische Aspekte der Mashups  18

einfachen  Umwandelns in ein JavaScript-Objekt stark erleichtert und benötigt keine  

zus  ätzliche Bibliothek, um auf die Inhalte zuzugreifen (vgl Neuhaus, 2006, S 70)  

3 Google Maps 19

3 Google Maps

Anfang 2005 veröffentlicht Google seinen Kartenservice Google Maps. (vgl. Google Maps API, 2008) Dieser Service hat die Benutzung von Landkarten im Internet grundlegend verändert. Im Gegensatz zu bereits bestehenden Kartenanwendungen benutzt Google Maps einfaches JavaScript der damals neuesten Browser-Generation und bietet damit kurze Ladezeiten, interaktiv vergrößerbare Karten und eine einfache und durchdachte Navigation. (vgl. Crane/Pascarello, 2006, S.24) Die wichtigste Komponente der Anwendung stellt allerdings die vielseitige API dar, mit der es möglich ist, ohne großen Aufwand eine Google Map in die eigene Homepage einzubinden. (vgl. Erle, 2007, S.1) Die bis dato einmalige Kombination aller Funktionalitäten in einer Anwendung und die einfache Übertragbarkeit auf die eigene Homepage machen Google Maps zur meist genutzten und beliebtesten Mashup-Komponente im Internet. (vgl. ProgrammableWeb, 2008)

3.1 Key-Features

Nachfolgend werden die wichtigsten Funktionen von Google Maps aufgelistet, die für Mashups von Relevanz sind: Karten-Rasterung

Google geht einen ungewöhnlichen Weg bei der Darstellung der Karte. Die Welt wird hierbei in Quadrate zerstückelt. Durch diese Technik können die Quadrate bereits vorgerendert auf dem Server gespeichert und müssen nicht bei jedem Aufruf neu erstellt werden. Somit wird eine deutlich höhere Effizienz für Google als Betreiber möglich, die auch für den Anwender spürbar ist. (vgl. Savage, 2006) Navigation innerhalb der Karte

Für die Navigation integriert Google kein normales Webinterface, wie es sich bereits bis zum Erscheinen von Google Maps als Standard etabliert hatte, sondern ermöglicht die Navigation innerhalb der Karte mittels einer Drag&Drop-Funktionalität. (vgl. Erle, 2007, S.2) Verschiedenartige Sichtmodi

Durch die Technik der bereits erstellten Bildquadrate ist es Google möglich, zwischen verschiedenen Sichtmodi zu wechseln. Dabei müssen nur die angezeigten Bilder dem Modus entsprechend neu geladen werden. Google stellt derzeit (Stand 1.Juni 2008) drei Modi zur Verfügung: Landkarte, Satellit und Terrain. (vgl. Google Maps Help Center, 2008)

3 Google Maps 20

Einzelner Suchtext

Innerhalb der normalen Google-Maps-Applikation sowie bei der Benutzung der Google Maps API kann ein einzelner Suchtext zur Suche verwendet werden. (vgl. Erle, 2007, S.2) Overlays und Marker

Overlays bzw. Marker sind Objekte, die auf die Karte gelegt und mit Hilfe von Geo-Koordinaten an einen bestimmten Punkt gebunden werden. Diese Objekte stellen dabei immer einen Gegenstand dar, der nachträglich hinzugefügt wird. Dies kann innerhalb der Google Map durch Marker oder Polygone erfolgen. (vgl. Google Maps API: Overlays, 2008) KML

Bei dem XML-Format „Keyhole Markup Language“ (KML) „handelt es sich um ein Dateiformat zur Darstellung geografischer Daten in einem Earth-Browser wie beispielsweise Google Earth, Google Maps und Google Maps für Handys“. (Google Earth, 2008) Auf dem XML-Standard basierend werden Elemente und Attribute in einer Tagbasierten Struktur abgebildet. (vgl. Google Earth, 2008) Im April 2008 hat Google die Kontrolle des KML-Formats dem Open Geospatial Con-sortium übertragen. Demzufolge stellt dieses Format nun einen flexiblen und anerkannten Standard dar, der auch von Applikationen jenseits von Google verwendet werden kann. (vgl. Open Geospatial Consortium, 2008)

3.2 Verwendete Technik

Google kombiniert bei seiner Karten-Anwendung bereits existierende Standards mitei-nander. Zur Darstellung der Kartenvierecke wird HTML und CSS verwendet. (vgl. Pichler, 2006) Dabei unterstützt die Google Maps API alle A-Grade Browser, hiermit sind alle aktuellen Browser gemeint, uneingeschränkt. (vgl. YAHOO! Developer Net-work, 2008)

Die Kommunikation mit dem Server erfolgt asynchron und wurde anfangs über ein verstecktes Iframe durchgeführt. Dieses ist jedoch zwischenzeitlich von dem browserübergreifenden JavaScript-Objekt GxmlHttp abgelöst worden, das die Serverkommunikation unabhängig vom verwendeten Browser übernimmt. (vgl. Tepaße, 2006) Die Manipulation der dargestellten Karte erfolgt in JavaScript über das eingebundene GMaps-Objekt. (vgl. Google Maps API, 2008) Die dazu benötigte Google-Maps-Datei muss seit dem Release des Google AJAX API loader nicht mehr direkt integriert werden. Durch die einmalige Integration einer vordefinierten Google-URL und dem an- schließenden load-Aufruf über einen fest definierten Namespace ist die Möglichkeit

3 Google Maps 21

gegeben, mehrere Google-APIs strukturiert einzubinden, ohne diese einzeln integrieren zu müssen. (vgl. Google AJAX API, 2008) Durch dieses neue Schema erreicht die Google Maps API an verbesserter Objektstruktur innerhalb einer selbst erstellten An- wendung.

4 Mashup-Anwendung: Freiplatzverzeichnis 22

4 Mashup-Anwendung: Freiplatzverzeichnis

4.1 Beschreibung der Anwendung

Die Basketballwebseite Crossover-online.de besitzt ein Verzeichnis mit derzeit ca. 850 (Stand: 1.Juni 2008) eingetragenen Freiplätzen aus Deutschland, Österreich und der Schweiz. Das Verzeichnis wird von der Community der Webseite zusammengetragen und von dieser auch aktualisiert und ergänzt. Um den Usern eine bessere Übersicht zu bieten, ist das bestehende Verzeichnis mit Google Maps kombiniert und dadurch deutlich verbessert worden.

4.1.1 Aufbau

Nachfolgend wird der Aufbau der Applikation dargestellt, in der die Zusammenhänge der einzelnen Komponenten aufgezeigt werden.

4 Mashup-Anwendung: Freiplatzverzeichnis 23

Wie aus der Darstellung ersichtlich, ist die Architektur eine Mischform der bereits vorgestellten Mashup-Architekturen. Hierbei werden bei der Eingabe neuer Daten über das Google-JavaScript-Objekt GClientGeocoder die Geoinformationen bei der Google Maps API erfragt. Bei der Darstellung auf der Landkarte werden die Informationen über REST bei der auf PHP basierenden Freiplatz-Klasse auf dem eigenen Server angefordert. Die Rückgabe zur Darstellung erfolgt im JSON-Format. Zur Ermittlung der Geoin-formationen bestehender Datenbestände erfolgt eine serverseitige Abfrage an die API von Google.

4.1.2 Umsetzung

Bei der Umsetzung der Anwendung ist das Rapid Application Development verwendet worden, womit es möglich ist, bereits frühzeitig Erfolge ersichtlich zu machen und somit die Applikation durch Prototyping besser an die Bedürfnisse der Benutzer anzupassen. Durch dieses Vorgehen konnten die besonderen Merkmale identifiziert werden, die eine spezielle Bedeutung in einer Google-Maps-Applikation einnehmen. Diese Merk- male umfassen die Darstellung, die Datenintegration und die Geokodierung.

4 Mashup-Anwendung: Freiplatzverzeichnis 24

4.2 Möglichkeiten und Grenzen von Google Maps Mashups

Die Merkmale, die aus der erstellten Google-Maps-Anwendung ermittelten worden sind, sollen nachfolgend untersucht werden. Dabei wird aufgezeigt, welche Problemstellungen in den einzelnen Schlüsselfunktionen existieren und welche Lösungswege dafür gefunden werden können.

4.2.1 Geokodierung

Eine Google Map wird erst durch die Verknüpfung mit eigenen Daten zu einer Mashup-Applikation. Hierfür müssen die Daten mit Geoinformationen verknüpft und somit an einen lokalen Ort gebunden werden. Diese Verknüpfung nennt man Geokodierung. Lutz Maerker von der TU Dresden definiert Geokodierung wie folgt: „Die Geokodierung ist die Lokalisierung der Objekte eines Layers oder Coverages in einem bekannten Koordinatensystem“. (vgl. Maerker, 2005) Um diese Geoinformationen zu ermitteln, wird von Google ein Service angeboten. Dieser kann direkt über JavaScript oder über REST angesprochen werden. (vgl. Google Maps API: Services, 2008) Der Google-Philosophie entsprechend sind die Geodaten dabei nicht Eigentum von Google selbst, sondern stellen verfügbare Inhalte Dritten zur Verfügung. (vgl. Halici/Mayer, 2007) Erst im Juni 2006 hat Google den internationalen Geocoding-Service für Dritte zur Verwendung zugänglich gemacht und somit eine erweiterte Nutzung der Google Maps für Mashups ermöglicht. (vgl. Google Maps Mania, 2006) Trotz dieser Öffnung ist die Anzahl der Anfragen pro Tag auf 15 000 begrenzt. Hiermit soll einem Missbrauch entgegen den Nutzungsbedingungen vorgebeugt werden. (vgl. Google Maps Terms, 2008) Nachfolgend werden die genauen Angaben zur Begrenzung ermittelt:

Tabelle 1: Begrenzung der Geokodierung

(Verwendetes System: Intel Centrino M750 1,86 GHz, 2 GB RAM, Windows XP mit SP2) Zur Ermittlung der Daten kann die Geo API über das Google eigene JavaScript-Objekt GClientGeocoder direkt angesprochen werden. Das Ergebnis wird dabei mit einem sogenannten Accuracy-Wert zurückgegeben. Mit Hilfe dieses Wertes kann ermittelt werden, inwiefern die angefragte Adressangabe der gewünschten Genauigkeit entspricht. (vgl. Google Maps API: Services, 2008) Dies ist deshalb notwendig, da Google keine Vorgaben für die Anfrage der Daten macht. Vielmehr werden bei ungenauen Anfragen Näherungswerte oder alle gefundenen Ergebnisse zurückgegeben. Neben der Er- mittlung von Geodaten über das JavaScript-Objekt ist eine direkte REST-Anfrage über

4 Mashup-Anwendung: Freiplatzverzeichnis 25

HTTP möglich. Das zurückgegebene Ergebnis kann entweder als JSON-, XML- oder KML-Datei erfolgen. Wobei sich XML und KML einzig im MIME-Typ unterscheiden. (vgl. Google Maps API: Services, 2008)

Eine selbstentwickelte Lösung zur Verarbeitung der Ergebnisse stellt besondere Ansprüche. Die bereits erwähnten vielfältigen Ergebnisse, bei zu ungenauen Angaben, ergeben eine besondere Problematik, die es zu beachten gilt. Nachfolgend ist beispielhaft die Verarbeitung eines KML-Ergebnisses aufgeführt. Durch den vernachlässigbaren Unterschied zwischen XML und KML kann dabei zur Verarbeitung jede XML verarbeitende Klasse verwendet werden. Beispiel in PHP:

Die in diesem Beispiel verwendete PHP5-Erweiterung SimpleXML bietet die Möglichkeit, eine XML-konforme Datei in ein PHP-Objekt zu konvertieren, auf welches mit der in PHP üblichen Objekt-Syntax zugegriffen werden kann.

Die hier aufgezeigte Methode bietet zwar die Möglichkeit der Verarbeitung der KML-Daten, jedoch ist der Zugriff auf die Daten nur mit eigenem Aufwand zu realisieren. Dies hat auch Google erkannt und stellt seit März 2008 seine C++-Bibliothek libkml zur Verfügung. (vgl. Google Open Source Blog, 2008) Diese Bibliothek basiert auf der von Google intern benutzten Technik zum Umgang mit KML und stellt somit Möglichkeiten bereit, um KML-Dateien erstellen, verarbeiten und manipulieren zu können. Derzeit befindet sich libkml in der Version 0.2., beherrscht jedoch bereits alle grundlegenden Elemente zum Erstellen der 2.2 Version von KML. Diese Version wurde Ende April 2008 vom Open Geospatial Consortium (OGC) zum OGC-Standard erklärt und stellt daher fortan die Basis aller Geoinformationssysteme (GIS) dar. (vgl. Open Geospatial Consortium, 2008) In der Verwendung ist die Bibliothek nicht nur auf C++ beschränkt. Über SWIG, ein Softwaretool, das C und C++ Programme mit verschiedenen und höhe-

4 Mashup-Anwendung: Freiplatzverzeichnis 26

ren Programmiersprachen verknüpft, lässt sich libkml derzeit mit Phyton und Java benutzen. (vgl. SWIG, 2008) Google ist bemüht, die Verwendbarkeit des neuen OGC-Standards mit Hilfe dieser Bibliothek zu erleichtern und somit KML weiter zu etablieren. (vgl. Google Open Source Blog, 2008)

4.2.2 Umgekehrte Geokodierung

Bei der Geokodierung werden zu bestimmten Adressangaben die zugehörigen Koordinaten ermittelt. Allgemein betrachtet stellt diese Methode für den normalen Anwender einer Google Map die Hauptfunktionalität dar. Wird jedoch ein Punkt auf einer Karte festgelegt, an den Informationen gehängt werden sollen, so ist es evtl. notwendig, die entsprechende Adresse zu ermitteln. Dieser Vorgang wird als umgekehrte Geokodierung bezeichnet.

Die Google Maps API bietet offiziell keine umgekehrte Geokodierung an. Lediglich eine ungenaue Angabe in Form des Landes, in dem sich die Koordinatenangaben befinden, lässt sich seit Version 2.55 ermitteln. (vgl. Esa Google Maps API example, 2007) Dieser Problematik hat sich Nico Goeminne angenommen. Er hat herausgefunden, dass die Google Maps API mit dem GDirections-Objekt und der zugehörigen Funktion loadFromWaypoints eine Umkehr-Funktionalität besitzt. Dazu hat er eine Reverse-Geocoder-Klasse geschrieben, die eine vereinfachte Nutzung der Funktionalität bietet. (vgl. Goeminne, 2007)

Der Einsatz der Klasse funktioniert jedoch nicht für alle Koordinaten auf der Welt. (vgl. Goeminne, 2007) Nico Goeminne macht sich bei der Ermittlung der nächstliegenden Straße zu den angegebenen Koordinaten die Tatsache zu Eigen, dass Google die Straßen des Kartenmaterials mit Geopunkten versehen hat. Dies lässt sich aus der Funktionalität ableiten, die es in Google Maps ermöglicht, eine Reiseroute umzuplanen und den Reiseweg selbst nach den eigenen Wünschen zu gestalten, ohne dass die Route über nicht exisrierende Straßen verläuft. (vgl. Google Maps Help Center: Driving Directions, 2007) Dem zugehörigen Objekt dieses Features, dem GDirection-Objekt, werden die entsprechenden Koordinaten übergeben. Das Objekt ermittelt aus diesen Angaben die Straße, die sich in unmittelbarer Nähe befindet.

Die ermittelten Angaben sind nicht als sehr zuverlässig zu betrachten, da sie nur Näherungswerte darstellen. (vgl. Google Groups: Reverse Geocoding, 2007) Eine vollständige Funktion kann jedoch nur von Google selbst bereitgestellt werden, da die Datenbank entsprechend ausgelegt sein muss und der Zugriff direkt darauf erfolgen müsste

4.2.3 Datenintegration mit KML

Zur automatischen Datenintegration bietet die Google Maps API einen KML-Import an. Seit November 2006 kann innerhalb von Google Maps mit diesem Format umgegangen

4 Mashup-Anwendung: Freiplatzverzeichnis 27

werden. (vgl. Tao, 2006) Dabei werden die enthaltenen Informationen einer KML-Datei automatisch von einem JavaScript-Objekt eingelesen und in einem entsprechenden Overlay oder Marker dargestellt. (vgl. Google Earth, 2008) Das KML-Format bietet vielfältige Möglichkeiten zur Darstellung der Overlays. Die Verwendung in Google Maps unterliegt aber momentan noch einigen Beschränkungen. Folgende KML-Elemente werden von Google Maps unterstützt (Stand 24.Mai 2008): „Ortsmarken, Symbole, HTML in der Beschreibung, KMZ, Polylinien und Polygone, Stile für Polylinien und Polygone […], Netzwerk-Links […], Boden-Overlays und Bildschirm-Overlays“. (Google Earth: KML, 2008)

Neben der Begrenzung der Möglichkeiten des Formates existieren weitere Einschränkungen. Die Dateigröße ist dabei ein weiterer Faktor, der bei der Benutzung von KML als Integrationsformat beachtet werden muss. (vgl. Google Hilfegruppe, 2008) Die Größe der Datei kann mit dem komprimierten Format KMZ verringert werden. Hierbei handelt es sich um eine im ZIP-Format gepackte KML-Datei, die vom Client entpackt und anschließend von der Google Maps API als normales KML verarbeitet wird. (vgl. Google Earth: Outreach, 2008) Zwar wird mit dieser Komprimierung das Problem der begrenzten Internetbandbreite umgangen, jedoch erhöhen sich dadurch die Anforderungen an den Client, welche sich bei schwächeren Systemen negativ auswirken können.

Tabelle 2: Vergleich zwischen KML und KMZ

(Verwendetes System: Intel Centrino M750 1,86 GHz, 2 GB RAM, Windows XP mit SP2) Wie aus diesem Vergleich ersichtlich, besteht eine Gleichbehandlung zwischen KML und KMZ in der Limitierung. Denn erst nach dem Entpacken der KMZ-Datei wird das GGeoXml-Objekt ausgeführt und eine Limitierung in diesem Objekt findet statt. (vgl. Google Groups: KML, 2008) Die Dateigröße und, damit einhergehend, die Anzahl der darzustellenden Datensätze kann folglich mit KMZ nicht umgangen werden. Sie besteht bei der festen Grenze von 1 MB oder je nach Größe der darzustellenden Objekte bei 100-200 Objekten. (vgl. Google Hilfegruppe, 2008)

Soll eine KML-Datei vom eigenen Server erstellt werden, ist eine serverseitige Programmiersprache vonnöten. Google stellt die bereits erwähnte Bibliothek „libkml“ zur Verfügung. Diese ermöglicht einen vereinfachten Umgang bei der Datengenerierung in das KML-Format. (vgl. Google Open Source Blog, 2008) Durch die XML-Grundlage von KML existiert ein nicht zu vernachlässigender Daten-Overhead bei der Übertra- gung. (vgl. Peterson, 2006)

4 Mashup-Anwendung: Freiplatzverzeichnis 28

In der bisherigen Anwendung wird JSON zum Übermitteln der Daten verwendet. Nachfolgend wird ermittelt, welchen Einfluss der größere Daten-Overhead von KML, im Gegensatz zu JSON, auf die Darstellung besitzt.

Tabelle 3: Vergleich zwischen JSON und KML

Die Untersuchung ist mit Hilfe des Services von Microimages.com durchgeführt worden. (vgl. Microimages.com, 2008) Dieser ermöglicht eine Integration von KML- und JSON-Dateien in gleichem Maße. Bei der Verwendung von KML wird das limitierte GGeoXml-Objekt zur Darstellung der Datenobjekte eingesetzt. Gegensätzlich dazu ist bei JSON keine automatische Integration vorhanden, wodurch auch keine Limitierung gegeben ist.

Wie aus dem Vergleich ersichtlich, existieren deutliche Unterschiede zwischen den beiden Formaten. Der signifikanteste Unterschied ist in der Schnelligkeit der Verarbeitung bis zur Darstellung zu finden. Dies ist auch der Grund, weshalb die beiden Formate in unterschiedlichen Anwendungsfällen zum Einsatz kommen. (vgl. Peterson, 2006) Google verwendet seit Anfang 2006 anstatt XML das JSON-Format zum Übertragen der Darstellungsdaten. Dieser Wechsel ist ohne Ankündigung vollzogen worden. (vgl. Xul for thought, 2006) Anhand des folgenden PHP-Skripts wird die Benutzung von JSON verifiziert.

Aus den gemachten Beobachtungen lässt sich erkennen, dass KML für die Datenintegration in Google Maps nur bedingt geeignet ist. Vielmehr stellt es ein Austauschformat zwischen verschiedenen Anwendungen dar. Es schafft somit, wie auch XML, einen standardisierten Austausch von Daten und fördert die Interoperabilität zwischen Syste- men. Dies wird durch die Ernennung zum OCG-Standard und der libkml-Bibliothek

4 Mashup-Anwendung: Freiplatzverzeichnis 29

weiter gefördert und stärkt dadurch das Format in seiner Verbreitung. Für die Kommunikation zwischen API und Anwendung ist das schlankere JSON-Format prädestiniert. Diese Behauptung wird auch dadurch untermauert, da JSON bei der Google Maps Anwendung von Google selbst verwendet wird.

4.2.4 Darstellung von Overlays

Google Maps bietet die Möglichkeit, sogenannte Overlays auf der Karte zu platzieren. Diese können beispielsweise zur besseren Übersicht bei der Navigation als Hover-Effekt eingesetzt werden und durch Überfahren des entsprechenden Markers eingeblendet werden. Um den Overlay entsprechend darzustellen, existieren verschiedene Möglichkeiten: (vgl. Google Maps API: Overlays, 2008) Polyline

Das einfachste Objekt zum Zeichnen eines Overlays ist das Polyline-Objekt. Mit Hilfe dieses Objektes können einfache Linien gezeichnet werden. Dabei werden dem Polyline-Objekt mehrere Geopunkte übergeben und das Objekt verbindet diese auf der Karte zu einer Linie. Beispiel in JavaScript:

Mit Hilfe dieses einfachen Objektes können bereits komplexe Verbindungen errechnet werden. Die Zeichnung wird im Normalfall direkt vom Browser übernommen. Eine reale Grenze der Anzahl der Punkte, die vom Objekt auf die Karte gezeichnet werden können, besteht nicht. Jedoch ist je nach Browser und dessen Speicherverwaltung die Grenze der uneingeschränkten Benutzung unterschiedlich. In der extremen Darstellung von 49 141 Punkten auf der Landkarte, ist die Renderzeit beim Internet Explorer 7 deutlich höher als beim Firefox 2. Diese unterschiedlichen Grenzen sind, neben der unterschiedlichen Speicherverwaltung, darauf zurückzuführen, dass verschiedene Methoden bei der Zeichnung des Overlays benutzt werden. Der Internet Explorer verwendet das von Microsoft entwickelte Format Vector Markup Language (VML) zum Zeichnen von Vector-Grafiken. Die restlichen A-Grade Browser (vgl. YAHOO! Developer Network, 2008) hingegen benutzen Scalable Vector Graphics (SVG) zur Zeichnung des Objekts. (vgl. Mozilla, 2008) Diese Methode der zweidimensionalen Zeichnung ist ein offenes standardisiertes Format, das sämtliche Möglichkeiten bietet, die Vector-basierte Grafiken benötigen. Es ist vom World Wide Web Consortium (W3C) unter anderem aus dem VML-Format entwickelt worden und stellt somit eine direkte Weiterentwicklung dessen dar. (vgl. W3C, 2005) Bei älteren Browsern, die keines der beiden Formate unterstüt-

4 Mashup-Anwendung: Freiplatzverzeichnis 30

zen, werden die Punkte vom Google-Server selbst gezeichnet und als eine fertige Grafik an den Browser geschickt.

Um der bereits erwähnten Speicherproblematik entgegen zu treten, hat Google den Po-lyline-Algorithmus zur Verfügung gestellt. Dieser wandelt gegebene Koordinaten in eine Reihe von Zeichen im ASCII-Format um und besitzt somit eine deutlich geringere Größe. (vgl. Google Maps API: Encoded Polylines, 2008) Dadurch wird der Speicher des Browsers entlastet und beschleunigt das Zeichnen der Punkte. (vgl. Google Maps API: Services, 2008) Durch die offene Dokumentation des Algorithmus ist es Dritten möglich, Portierungen für andere Programmiersprachen anzubieten. So existieren fertige Polyline Encoder für Perl, PHP, Ruby und Java, die eine serverseitige Enkodierung der Geopunkte ermöglichen. Beispiel in PHP:

In dem angeführten Beispiel wird eine ca. 900KB große Datei mit den Grenzkoordinaten von Großbritannien (49 141 Koordinatenpunkte) geladen und vom Algorithmus des Polyline Encoders in einen kodierten ASCII-Zeichensatz umgewandelt. ASCII-Zeichensatz:

Dadurch verkleinert sich die Größe der Koordinatendatei auf unter 200KB. Die Darstel- lung des Polyline-Objekts auf der Karte erfolgt problemlos.

4 Mashup-Anwendung: Freiplatzverzeichnis 31

Entgegen der Begrenzung des GGeoXML-Objekts besteht somit keine explizite Grenze bei der Zeichnung durch das Polyline-Objekt. Lediglich die verwendete Technik des Clients schafft eine Limitierung, indem die Performance bei zu vielen Punkten signifikant nachlässt. Polygon

Eine Erweitung der Polyline stellt das Polygon-Objekt dar. Mit diesem Objekt ist es möglich, durch die Angabe mehrerer Koordinatenpunkte eine Region als gefüllte Fläche zu zeichnen. Im Unterschied zum Polyline-Objekt ist das Polygon-Objekt in sich geschlossen und kann nach dem Erstellen nicht durch einen weiteren Geopunkt verändert werden. (vgl. Google Maps API: Overlays, 2008)

Soll der Overlay beim Überfahren der Fläche mit der Maus gesondert gekennzeichnet werden, so ist ein entsprechendes Mouseover-Event nötig. Zwar bietet Google bereits ab der Version 2.88 ein Click-Event für Polygon-Overlays an, das nur ausgelöst wird, wenn der Klick innerhalb des Overlays erfolgt, jedoch kein entsprechendes Hover-Event. (vgl. Appleton, 2007) Somit ist eine Verbesserung der Funktionalität des gegeben Google Codes notwendig. Dieser wird um den Algorithmus von Darel Rex Finley, zur Bestimmung ob sich ein Punkt innerhalb eines komplexen Polygons befindet, erweitert. (vgl. Finley, 2007) Dafür ist es notwendig, den Algorithmus für JavaScript und Google Maps entsprechend anzupassen.

4 Mashup-Anwendung: Freiplatzverzeichnis 32

Damit der Algorithmus genutzt werden kann, muss durch einen Event-Listener jeder Punkt, den der Mauszeiger auf der Karte aktuell besitzt an die neu erstellte Funktion GPolygon.Contains zur Überprüfung übergeben werden.

Mit dieser funktionellen Erweiterung besitzt die Google-Maps-Anwendung eine Mouseover-Funktionalität für Polyline- bzw. Polygon-Overlays. Diese trägt zum Rich User Experience des Webseitenbesuchers weiter bei. Zu beachten ist hierbei, dass nur die neueste Browser-Generation, mit SVG- bzw. VML-Unterstützung, diese Erweiterung nutzen kann.

4.2.5 Darstellung der Marker

Marker sind Objekte, die wie Overlays an einen bestimmten Punkt auf der Karte gebun- den und nachträglich auf der Karte platziert werden. Jedoch stellen sie keine komplexen

4 Mashup-Anwendung: Freiplatzverzeichnis 33

Objekte, sondern nur einen bestimmten Punkt dar. Auf einer Landkarte haben Marker die Funktion, wichtige Punkte zu markieren und dadurch die eigentlich relevante Information der jeweiligen Google Map darzustellen. (vgl. Google Maps API: Overlays, 2008)

Sollen auf einer Google Map viele verschiedene Informationen über die Weltkarte verteilt angezeigt werden, ist eine Darstellung von möglichst vielen Markern notwendig. Google empfiehlt die maximale Darstellung von 200 Objekten gleichzeitig. (vgl. Google Maps API: Overlays, 2008) Der Darstellung sind somit Grenzen gesetzt. Diese werden in der bestehenden Freiplatz-Applikation umgangen, indem Oberkategorien gebildet wurden, die eine Darstellung vieler Punkte nicht notwendig machen. Diese Lösung umgeht zwar die Problematik, nutzt aber damit nicht in vollem Umfang die Stärke der Google Maps API aus.

Der Wert von 200 Markern auf der Google Map stellt lediglich einen Richtwert dar. (vgl. Google Maps API: Overlays, 2008) Deshalb wird nachfolgend ermittelt, wie hoch die tatsächliche Darstellungsgrenze ist. In dem verwendeten Algorithmus werden die Marker in einem Kreis auf der Karte abgebildet. Die Ergebnisse sind mit der Version 2.88 der Google Maps API wie folgt:

Tabelle 4: Begrenzungen der Browser

(Verwendetes System: Intel Centrino M750 1,86 GHz, 2 GB RAM, Windows XP mit SP2) Zwar sind die aufgeführten Ergebnisse von der verwendeten Hardware abhängig, lassen sich jedoch trotzdem verallgemeinert betrachten. Die ermittelte Grenze liegt somit bei der Darstellung von ca. 1000 Marker.

Um der aufgezeigten Problematik zu entgegnen und mehr als 1000 Marker problemlos auf einer Karte darstellen zu können, wird eine Clustering-Lösung notwendig. Da die Problematik nicht auf Seiten von Google selbst existiert, sondern nur seitens des Clients, bedarf es auch keiner offiziellen Lösung in der Google Maps API. Der von

4 Mashup-Anwendung: Freiplatzverzeichnis 34

Google selbst zur Verfügung gestellte GMarkerManager tangiert das Problem deshalb nur im Ansatz, indem festgelegt wird, welche Marker auf einer bestimmten Darstellungsebene angezeigt werden sollen. (vgl. Google Maps API: Overlays, 2008) Die gut funktionierende Google Maps-Community hat jedoch selbst Lösungswege gefunden: (vgl. Google Maps Groups, 2008)

Alle Cluster-Lösungen basieren dabei auf denselben Annahmen. (vgl. Google Groups: Clustering, 2008) Die dargestellte Karte wird in kleine Cluster unterteilt. Die maximal angezeigten Marker hängen hierbei von der festgelegten maximalen Anzahl ab. Geht man davon aus, dass ein Marker eine Größe von 20x34 Pixel besitzt und die Google Map 1024x786 groß ist, so können maximal (1024/20)*(768/34) =1156 Cluster und somit 1156 Marker dargestellt werden. (vgl. Clustel, 2008)

Werden von dieser maximalen Anzahl an Clustern nun jeweils 8 Cluster zu einem zusammengefasst, so ist eine Darstellung von maximal 144 Markern gegeben. Diese Anzahl ist den Vorgaben von Google und den eigenen Untersuchungen folgend als unkritisch zu betrachten. (vgl. Google Maps API: Overlays, 2008) Zusätzlich zur eigentlichen Clusterung wird die tatsächlich angezeigte Fläche beachtet, wodurch eine weitere Effizienzsteigerung zu verzeichnen ist. (vgl. Google Groups: Clustering, 2008) Die aufgezeigten Probleme der Marker-Darstellung werden dadurch zwar nicht gelöst, jedoch geschickt umgangen, ohne ein mehrfaches Anfordern von Markerdaten vom

4 Mashup-Anwendung: Freiplatzverzeichnis 35

Server notwendig zu machen. Durch weitere Verbesserungen der Google Maps API im Umgang mit Markern wäre es denkbar, zwar keine endgültige Lösung, aber eine Verschiebung der Darstellungsgrenze zu erreichen. Obwohl eine gewisse Darstellungsgrenze aufgrund der technischen Limitierung stets bestehen bleiben wird, ist diese mit zunehmender Zeit immer stärker zu vernachlässigen, da der Usability der Karte selbst Grenzen gesetzt sind, die nicht umgangen werden sollten.

5 Zusammenfassung und Ausblick 36

5 Zusammenfassung und Ausblick

Die hier vorliegende Arbeit ist eine Einführung in das Thema Google Maps Mashups und zeigt, basierend auf einer bestehenden Anwendung, die Grenzen und Möglichkeiten der Technik auf.

Zu Beginn wird eine allgemeine Einführung in die Thematik der Mashups gegeben, in der nicht nur der Begriff Mashup erklärt wird, sondern darüber hinaus auch die von Gartner analysierten Zukunftschancen der Technik. Die nachfolgende Abgrenzung zur serviceorientierten Architektur macht eine Einordnung der Thematik möglich und zeigt gleichzeitig die Stärke der Mashups. Im nächsten Kapitel sind die technischen Aspekte erläutert worden. Dieses Kapitel erstreckt sich dabei von der Technologiesammlung AJAX über die möglichen Architekturformen von Mashup-Anwendungen und den existierenden Programmiermodellen bis hin zu den Formaten, die zur Kommunikations- und Datenübertragung notwendig sind. Dabei ist nur für die Google-Maps-Mashups-Technik Relevantes berücksichtigt worden. Das folgende Kapitel stellt den vollständigen Bezug zu Google und dem für diese Arbeit relevanten Google-Maps-Service her, indem die Merkmale und Eigenschaften einer Google-Maps-Anwendung aufgezeigt worden sind. In der anschließenden Untersuchung des Google-Maps-Serivce werden eben diese Merkmale näher untersucht. Den Anfang macht dabei die zur Ermittlung von Geoinformationen zu einer bestimmten Adressangabe benutzten Geokodierung. Diese kann, wie aufgezeigt, auch mittels der umgekehrten Geokodierung die Adressangaben zu einem bestimmten Geopunkt ermitteln. Beide Verfahren unterliegen jedoch einer Quotierung und lassen nur 15 000 Abfragen pro Tag zu. Hinzu kommt, dass nur eine Abfrage pro Sekunde durchgeführt werden darf. Im darauffolgenden Kapitel wird die Datenintegration von KML thematisiert, mit der es möglich ist, Daten automatisch auf einer Google Map anzeigen zu lassen. Bei der Integration treten jedoch erneut Begrenzungen auf. Es ist nicht möglich, Daten über 1 MB Größe zu integrieren. Die maximal anzeigbaren Punkte variieren je nach eigener Informationsgröße zwischen 100-200. Ein Unterschied zwischen dem KML-Format und dem gepackten KMZ-Format kann nicht festgestellt werden, weshalb eine Begrenzung für beide Formate in gleichem Maße gilt. Das letzte wichtige Merkmal einer Google Map ist die Darstellung von Objekten auf der Karte. Dabei werden zwei verschiedene Typen spezifiziert. Der erste Typ ist das Overlay-Objekt, mit dem es möglich ist, farbige Flächen auf der Landkarte zu zeichnen. Dabei werden Wege aufgezeigt, inwiefern eine große Anzahl von Informationen effizient verarbeitet werden kann und welche Manipulationsmöglichkeiten über die Google Maps API hinaus durch einfache Erweiterung noch bestehen. Der zweite Typ ist das einfache Marker-Objekt, das die eigentliche Hauptinformation einer Karte beinhaltet. Eine Gren- ze der darstellbaren Anzahl der Marker ist ermittelt worden. Daraus lässt sich folgern,

5 Zusammenfassung und Ausblick 37

dass diese je nach verwendetem Browser variieren und somit eine flexible Lösung der Problematik erforderlich machen. Der bekannte Lösungsweg der Clusterung wird daraufhin analysiert und die eigentliche Funktionsweise der Cluster-Lösungen aufgezeigt. Die von Google zur Verfügung gestellte Google Maps API bietet vielfältige Möglichkeiten zur Nutzung und setzt selbst nur wenige Grenzen. Für jede bekannte Problematik, die nicht ausschließlich mit der technischen Limitierung zu tun hat, versucht die funktionierende Community der Google Maps Groups einen Lösungsansatz zu finden. Dies ist nur deshalb so gut möglich, da die von Google zur Verfügung gestellte Dokumentation nahezu alle Informationen der Google Maps API preisgibt. Wie am Beispiel von Nico Goeminne und seiner umgekehrten Geokodierung ersichtlich, sind dabei auch Lösungswege denkbar, die von Google überhaupt nicht angedacht wurden. Mit jeder neuen Version schafft Google somit neue Möglichkeiten, die Google-Maps-Anwendungen zu neuen Höchstleistungen zu treiben. Dabei stellt vor allen Dingen das neu integrierte Streetview alle Anwender vor eine neue Dimension der Möglichkeiten. Die Grenzen des Umsetzbaren werden wieder ein Stück weit verschoben und müssen erneut ausgetestet werden.

Quellenverzeichnis 38

Quellenverzeichnis

Alby, T. (2007): Web 2.0 - Konzepte, Anwendungen, Technologien. U.a. München: Carl Hanser Verlag.

Alexander, S. (2007): Gartner: Welche Technologietrends Unternehmen fundamental verändern werden. Zugriff am 3. Juni 2008 unter http://www.computerwoche.de/knowledge_center/software/597986/index.html. Appleton, B. (2007): Official Google Maps API Blog: v2.88: Clickable Polylines & Polygons. Zugriff am 3. Juni 2008 unter

http://googlemapsapi.blogspot.com/2007/09/v288-clickable-polylines-polygons.html. Carl, D. (2008): Das Mashup-ABC. Mashups programmieren - Grundlagen, Konzepte, Beispiele. Köln: O’Reilly Verlag. S. 3-64.

Clustel (2008): Clustel - A grid based point clusterer intended for clustering points on maps. Zugriff am 3. Juni 2008 unter http://code.google.com/p/clustel. Computerwoche (2007): Gartner: Die zehn wichtigsten strategischen Techniken für 2008. Zugriff am 3. Juni 2008 unter http://www.computerwoche.de/nachrichten/556144/index6.html. Crane, D., Pascarello, E., James, D. (2006): Ajax in Action. Greenwich, Connecticut (CT): Manning Publications.

Crossover-online (2008): Das Basketball Portal - Freiplatzverzeichnis. Zugriff am 3. Juni 2008 unter http://crossover-online.de/courts.php.

Eberhart, A., Fischer, S. (2003): Web Service - Grundlagen und praktische Umsetzung mit J2EE und .NET. U.a. München: Carl Hanser Verlag. Erle, S., Gibson, R. (2006): Google Maps Hacks. Sebastopol, California (CA): O’Reilly Media.

Esa Google Maps API example (2007): Geo. Zugriff am 3. Juni 2008 unter http://koti.mbnet.fi/ojalesa/exam/geotest.html.

Finley, D. R. (2007): Determining Whether A Point Is Inside A Complex Polygon. Zugriff am 3. Juni 2008 unter http://alienryderflex.com/polygon/. Freedman, C. (2007): YAHOO! Maps Mashups. U.a. Indianapolis, Indiana (IN): Wiley Publishing.

Gehtland, J., Galbraith, B., Almaer, D. (2006): A Web 2.0 Primer: Pragramtic Ajax. U.a Dallas, Texas (TX): The Pragmatic Bookshelf.

Quellenverzeichnis 39

Goeminne, N. (2007): Reverse Geocoder for Google Maps API Documentation. Zugriff am 3. Juni 2008 unter http://nicogoeminne.googlepages.com/documentation.html. Google AJAX API (2008): Developer’s Guide. Zugriff am 3. Juni 2008 unter http://code.google.com/apis/ajax/documentation/.

Google Code: libkml (2008): UserGuide02x - libkml. Zugriff am 3. Juni 2008 unter http://code.google.com/p/libkml/wiki/UserGuide02x. Google Earth (2008): KML. Zugriff am 3. Juni 2008 unter http://earth.google.de/kml/index.html.

Google Earth: KML (2008): KML mit Google Maps. Zugriff am 3. Juni 2008 unter http://earth.google.de/kml/mapsSupport.html.

Google Earth: Outreach (2008): Google Earth Outreach. Zugriff am 3. Juni 2008 unter http://earth.google.de/outreach/tutorial_kmz.html. Google Groups (2008): Google Maps Hilfe - Google Maps Fehlermeldungen. Zugriff am 3. Juni 2008 unter http://groups.google.com/group/Google-Maps-DE-Fehlerbehebung/browse_thread/thread/8a44f2d8a0fae665.

Google Groups: Clustering (2008): GMarkerManager. Zugriff am 3. Juni 2008 unter http://groups.google.com/group/Google-Maps-API/browse_thread/thread/b78207c5bbde9f69/e5f98aa057820e9d#e5f98aa057820e9d. Google Groups: KML (2008): big KML file to load to Google Maps. Zugriff am 3. Juni 2008 unter http://groups.google.co.in/group/Google-Maps-API/browse_thread/thread/c624c8c2ba73fd01.

Google Groups: Reverse Geocoding (2007): Reverse Geocoding using the Google Maps API only. Zugriff am 3. Juni 2008 unter http://groups.google.com/group/Google-Maps-API/browse_thread/thread/a0782c3dbceb19ee/d8c50230ad182084. Google Hilfegruppe (2008): *.kml / *.kmz Editor - Google Maps. Zugriff am 3. Juni 2008 unter http://groups.google.com/group/Google-Maps-DE/browse_thread/thread/557d3163bfed9775.

Google Maps API (2008): Google Map API Concepts. Zugriff am 3. Juni 2008 unter http://code.google.com/apis/maps/documentation/.

Google Maps API: Encoded Polylines (2008): Encoded Polyline Algorithm Format. Zugriff am 3. Juni 2008 unter

http://code.google.com/apis/maps/documentation/polylinealgorithm.html. Google Maps API: Overlays (2008): Map Overlays. Zugriff am 3. Juni 2008 unter http://code.google.com/apis/maps/documentation/overlays.html.

Quellenverzeichnis 40

Google Maps API: Services (2008): Services. Zugriff am 3. Juni 2008 unter http://code.google.com/apis/maps/documentation/services.html. Google Maps Groups (2008): Google Maps API. Zugriff am 3. Juni 2008 unter http://groups.google.com/group/Google-Maps-API.

Google Maps Help Center (2008): What is Google Maps? Zugriff am 3. Juni 2008 unter http://maps.google.com/support/bin/answer.py?answer=7060&topic=10778. Google Maps Help Center: Driving Directions (2008): How can I get driving directions using Google Maps? Zugriff am 3. Juni 2008 unter http://maps.google.com/support/bin/answer.py?answer=16531. Google Maps Mania (2008): Google Geo Developer Day. Zugriff am 3. Juni 2008 unter

http://googlemapsmania.blogspot.com/2006/06/google-geo-developer-day-post-3.html. Google Maps Terms (2008): Google Maps API Terms of Service - Google Maps API. Zugriff am 3. Juni 2008 unter http://code.google.com/apis/maps/terms.html. Google Mashup Editor (2008): Google Mashup Editor. Zugriff am 3. Juni 2008 unter http://editor.googlemashups.com.

Google Open Source Blog (2008): Introducing libkml: a library for reading, writing and manipulating KML. Zugriff am 3. Juni 2008 unter http://google-opensource.blogspot.com/2008/03/introducing-libkml-library-for-reading.html. Halici, O., Mayer, J. (2007): Master Plan - About the power of Google. Zugriff am 3. Juni 2008 unter http://masterplanthemovie.com.

Hammersley, B. (2003): Content Syndication with RSS. Sebastopol, California (CA): O’Reilly Media.

Hassler, M. (2008): Wirtschaftliche Nutzung von Mashups. Mashups programmieren -Grundlagen, Konzepte, Beispiele. Köln: O’Reilly Verlag. S. 65-87. Heller, M. (2007): The ABC’s of RIA. Zugriff am 3. Juni 2008 unter http://www.infoworld.com/article/07/08/06/32TCria_1.html. IT-Wissen (2008): IT-Wissen: Das große Online-Lexikon für Informationstechnologie: Metadaten. Zugriff am 3. Juni 2008 unter

http://www.itwissen.info/definition/lexikon/Metadaten-meta-data.html. Kang, J.-S. (2007): Mashup. Zugriff am 3. Juni 2008 unter http://www.youtube.com/watch?v=UJVke779YsQ. Koch, S. (2001): Javascript. Heidelberg: dpunkt Verlag.

Quellenverzeichnis 41

Maerker, L. (2005): Umweltinformationssysteme - Basiswissen GIS. Zugriff am 3. Juni 2008 unter

http://www.tu-dresden.de/fghgig/lehrstuhl/meuropa/lmk/uis/gis/basics.html. Marick, B. (1997): Rapid Development Review. Zugriff am 3. Juni 2008 unter http://www.testing.com/writings/reviews/mcconnell-rapid.html. Microimages.com (2008): Google Maps und WMS/WFS via TNT map. Zugriff am 3. Juni 2008 unter http://www.microimages.com/ogc/ogcclient/gmap.htm. Mozilla (2008): SVG in Firefox. Zugriff am 3. Juni 2008 unter http://developer.mozilla.org/en/docs/SVG_in_Firefox_1.5. Neuhaus, S. (2006): JSON und JSON-RPC: AJAX ohne XML. Zugriff am 3. Juni 2008 unter http://www.heise.de/ix/artikel/2006/01/070/. Open Geospatial Consortium (2008): KML. Zugriff am 3. Juni 2008 unter http://www.opengeospatial.org/standards/kml/. O’Reilly, T. (2005): What Is Web 2.0. Zugriff am 3. Juni 2008 unter http://www.oreilly.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html?page=5.

Ort, E., Brydon, S., Basler, M. (2007): Mashup-Styles, Part 1: Server-Side Mashups. Zugriff am 3. Juni 2008 unter

http://java.sun.com/developer/technicalArticles/J2EE/mashup_1/. Peterson, M. D. (2006): And The Winner of the JSON vs XML Battle Is…. Zugriff am 3. Juni 2008 unter

http://www.oreillynet.com/xml/blog/2006/12/and_the_winner_of_the_json_vs.html. Pichler, W. (2006): Google Maps für die Website - Webanwendungen mit Landkarten. Internet Professionell. München: VNU Business Publications Deutschland. Zugriff am 3. Juni 2008 unter http://www.testticker.de/praxis/netzwerke/article200606010678.aspx. ProgrammableWeb (2008): API-Directory - ProgrammableWeb. Zugriff am 3. Juni 2008 unter http://www.programmableweb.com/apis/directory/1?sort=mashups. Savage, C. (2006): cfis: Google Maps Deconstructed. Zugriff am 3. Juni 2008 unter http://cfis.savagexi.com/articles/2006/05/03/google-maps-deconstructed. Schönefeld, F. (2007): Mashups: EAI mit Web 2.0. Zugriff am 3. Juni 2008 unter http://www.computerwoche.de/produkte_technik/software/594302/index.html. Stephken, G. (2008): OpenSource Software-Entwicklung: Agile Programming. Zugriff am 3. Juni 2008 unter http://www.little-idiot.de/his/agile.htm. Steyer, R. (2006): AJAX mit PHP - beschleunigte Webapplikationen für das Web 2. München: Addison-Wesley.

Quellenverzeichnis 42

SWIG (2008): Simplified Wrapper and Interface Generator. Zugriff am 3. Juni 2008 unter http://www.swig.org.

Tao, N. (2006): Official Google Maps API Blog: KML on Google Maps. Zugriff am 3. Juni 2008 unter http://googlemapsapi.blogspot.com/2006/11/kml-on-google-maps.html. Tepaße, T. (2006): Selfhtml Forum: Wie macht es Google Maps. Zugriff am 3. Juni 2008 unter http://forum.de.selfhtml.org/archiv/2006/1/t122689. W3C (2005): Scalable Vector Graphics (SVG) Full 1.2 Specifications. Zugriff am 3. Juni 2008 unter http://www.w3.org/TR/SVG12/.

Xul for thought (2006): Google Maps Switched to JSON. Zugriff am 3. Juni 2008 unter http://xullicious.blogspot.com/2006/01/google-maps-switched-to-json.html. YAHOO! Developer Network (2008): YAHOO! UI Library: Graded Browser Support. Zugriff am 3. Juni 2008 unter http://developer.yahoo.com/yui/articles/gbs/. YAHOO! Pipes (2008): Pipes: Rewire the web. Zugriff am 3. Juni 2008 unter http://pipes.yahoo.com/pipes.