Warning: include_once(/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php): failed to open stream: No such file or directory in /var/www/html/fields/cgp08/local/config.php on line 4

Warning: include_once(): Failed opening '/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php' for inclusion (include_path='.:/opt/php/lib/php') in /var/www/html/fields/cgp08/local/config.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/fields/cgp08/local/config.php:4) in /var/www/html/pmwiki-2.2.86/pmwiki.php on line 1250
Computergrafik-Praktikum Sommersemester 2008 - Main - Gruppe Google Earth

Dokumentation der Google Earth-Komponente

Marc Ermshaus, JI Yue Ming

Einleitung

Im Rahmen des Computergrafikpraktikums 2008 "Visualisierung von Immatrikulationsdaten" ist die Google Earth-Komponente eine der vier Darstellungsformen. In Abgrenzung zum Säulendiagramm, dem Tortendiagramm und der Google Maps-Karte ist es Aufgabe der Google Earth-Komponente, einen geographischen Überblick darüber zu geben, aus welchen Ländern der Welt Studierende den Weg an die Universität Osnabrück gefunden haben.

Zur Präsentation der Daten dient die direkt im Browser als Plugin ausführbare Version der bekannten Google Earth-Software, die einen frei dreh- und zoombaren Globus zur Verfügung stellt.

Das Plugin wurde am 2. Juni 2008 veröffentlicht und ist derzeit nur für Windows verfügbar. Es kann über die Google Earth API-Seite heruntergeladen werden.

Benutzerdokumentation

Auf dem Google Earth-Globus wird das Resultat der aktuellen Filtereinstellungen immer so dargestellt, als wäre nach dem Herkunftsland gruppiert worden.

Steuerung und Zoomstufen

Die Verwendung der Google Earth-Komponente ist äußerst unkompliziert. Beim ersten Aufruf des zugehörigen Registerreiters wird das Plugin gestartet und es beginnt eine kurze Kamerafahrt auf Deutschland zu. Während dieses Flugs sind erst die Kontinente zu sehen, beim weiteren Absinken geht die Darstellung in Landesgrenzen über.

Zoomstufe: sehr weit
Zoomstufe: weit

Die Anwendung wechselt abhängig von der Höhe des Betrachters den Detailgrad der angezeigten Informationen. Je geringer der Abstand zur Erde, desto mehr Details.

Zoomstufe: nah
Zoomstufe: sehr nah

Drehen am Mausrad ist der einfachste Weg, die Zoomstufe zu verändern. Doch auch über die Tasten Plus/Minus und Bild auf/Bild ab kann die Höhe angepasst werden.

Zur direkten Anwahl eines bestimmten Detaillevels dient die Auswahlbox rechts unten im Benutzerinterface. Es gibt vier Stufen, die von "sehr weit" nach "sehr nah" folgende Details anzeigen:

sehr weit
Statt Ländern werden "Kontinente" angezeigt. Die Zahl der Studierenden eines Kontinents ist die Summe aller Studierenden der Länder dieses Kontinents.
weit
Hier werden nur die Landesgrenzen angezeigt. Die geeignete Stufe für den globalen Länderüberblick.
nah
Zusätzlich zu den Landesgrenzen erscheinen (anklickbare) Landesflaggen und ein Kürzel des Landes.
sehr nah
Das Kürzel wird zum vollen Landesnamen, die Anzahl der Studierenden wird dahinter in Klammern gesetzt.

Das Google Earth-Plugin reagiert übrigens erst dann auf einen neuen Befehl zur Änderung der Kameraposition, wenn sich die Kamera nicht mehr bewegt.

Nach dem Zoomen wird es Zeit für einen Rundflug. Mit der Box links unten im Benutzerinterface kann die Kamera auf ein Land zentriert werden.

Infofenster

Beim Klick auf eine Landesflagge erscheint ein Infofenster mit weiteren Informationen über das entsprechende Land.

Infofenster: Großbritannien

Farbsymbolik

Die Einfärbung der Landesfläche ist ein schneller Hinweis darauf, ob verhältnismäßig viele oder wenige Studierende aus einem Land stammen.

Die Auswahl der Farben funktioniert so:

  • Für jede neue Abfrage wird zuerst das Land ermittelt, aus dem die meisten Studierenden kommen. Dieses Land bildet den Maximalwert und steht für 100 %.
  • Für jedes weitere Land wird nun die jeweilige Studierendenzahl in einen Prozentanteil dieses Maximalwerts umgerechnet. Ein Beispiel: Aus Deutschland kommen die maximale Anzahl von 100 Studierenden (= 100 %). Aus Österreich kommen 25 Studierende, was 25 % entspricht.
  • Dieser Prozentwert wird schließlich einem Farbbereich auf der Farbskala zugewiesen. 0 % befindet sich ganz links im grünen Bereich, 100 % ganz rechts im rot-violetten. Die übrigen Prozentzahlen werden gleichmäßig dazwischen verteilt.
Farbschema für die Einfärbung der Länderpolygone

Kommen aus einem Land für eine Auswahl gar keine Studierenden, verbleibt es als weißer Fleck auf der Landkarte.

Beschreibung des Entwicklungsablaufs

Beschränkung der Darstellung auf wesentliche Informationen

Beim Ausprobieren und Abwägen verschiedener Wege, Studierendendaten auf dem Globus darzustellen, wurde deutlich, dass es für eine übersichtliche Datenvisualisierung nötig sein würde, auf einen großen Teil der Möglichkeiten von Google Earth zu verzichten und zu versuchen, lediglich das notwendige Minimum relevanter Informationen abzubilden. Deshalb werden in der vorliegenden Version der Anwendung gar keine Standarddaten von Google Earth mehr auf dem Globus dargestellt, sondern nur noch die eigenen, bei Initialisierung hinzugefügten Länderpolygone vor einer dunkelblauen Hintergrundgrafik. Außerdem wurde eine Untergrenze für die Zoomstufe definiert, da sich ab einer gewissen Kamerahöhe beim weiteren Hereinzoomen kein Mehrwert an Übersicht oder Information mehr ergeben kann.

Dieser Ansatz der größtmöglichen Vereinfachung findet sich auch in der Gestaltung der Flex-GUI. Sie stellt lediglich die Möglichkeiten bereit, den Globus zu einem Land zu drehen und eine bestimmte Zoomstufe direkt auszuwählen.

Es war keine leichte Entscheidung, zum Wohle der Übersicht das Google Earth-Plugin darauf zu beschränken, eine dreh- und zoombare blaue Kugel mit ein paar Polygonen zu zeichnen, statt hochauflösender, dreidimensionaler Gebirgszüge, australischer Wüsten und dem Amazonas-Delta, aber es war im Sinne der Projektkonzeption richtig, völlig auf diese für die Visualisierung wenig bedeutsamen Elemente zu verzichten.

Dasselbe Gleichgewicht zwischen Informationsmenge und Übersichtlichkeit musste auch bei Darstellung der Länder gefunden werden. Während auf dem afrikanischen Kontinent, auf dem die Staaten groß und relativ gleichmäßig verteilt sind, weitere Angaben auf dem Globus Platz gefunden hätten, wurde dieselbe Informationsmenge bei den flächenmäßig kleinen europäischen Staaten, die aber für die Statistik wesentlich interessanter sind, schnell unübersichtlich.

Die Darstellungsweise der Studierendenzahlen war kein Anlass zu längerer Diskussion. Die Daten werden in Prozentanteile (an dem Land mit der höchsten Studierendenzahl der aktiven Auswahl) umgerechnet, die bereichsweise über eine Skala von 15 Farben kodiert werden. Die jeweilige farbliche Entsprechung des Prozentanteils eines Landes wird dann den zu diesem Land gehörenden Polygonen als Hintergrundfarbe zugewiesen. So lässt sich über die Farbgebung immer ein Eindruck gewinnen, aus welchen Ländern verhältnismäßig viele oder verhältnismäßig wenige Menschen in Osnabrück studierten oder studieren. Größe oder Einwohnerzahl eines Landes spielen dabei keine Rolle, es werden lediglich die absoluten Zahlenwerte zueinander in Beziehung gesetzt.

Ermittlung und Verarbeitung benötigter Daten

Bereits früh im Entwicklungsprozess wurde entschieden, die Liste der in den Stammdaten enthaltenen Staaten mit einer neu zu schaffenden Liste von Länderpolygonen zu verknüpfen, um eine Schnittstelle für die Präsentation der Datenbankdaten auf dem Globus zu schaffen. Daraus ergaben sich die beiden Aufgaben, eine geeignete Liste vorgefertigter Definitionsdaten für Ländergrenzen zu finden und diese den Staatseinträgen aus den Stammdaten zuzuweisen.

Die zur Erfüllung der ersten Aufgabe nötige Suche gestaltete sich wie erwartet als unbequem, aber dann als überraschend erfolgreich. Die Polygondaten der Landesgrenzen sollten aktuell und detailliert genug für eine ordentliche Darstellung sein, dabei aber ausreichend schnell vom Server an den Client übertragbar sein. Da die Google Earth-Software als eigenständige Anwendung schon seit einiger Zeit existiert und das Hinzufügen eigener geographischer Daten in einem maschinenlesbaren Format (KML, siehe unten) erlaubt, das auch vom Google Earth-Plugin gelesen werden kann, konnte auf Definitionsdaten des Projekts "Thematic Mapping" zurückgegriffen werden, die die gewünschten Bedingungen erfüllen und die frei verwendet werden dürfen. (Mehr dazu im Abschnitt "Datenquellen".)

Die zweite Aufgabe, die neu gefundenen Daten mit der Staatenliste aus den Stammdaten zu verknüpfen, erforderte nicht nur an dieser Stelle eine Menge Handarbeit. Die Stammdaten verfügen über einen Länderschlüssel, der in den Kommentaren zur Stammdatenbank als "interne ID des Staates" bezeichnet wird und der keinem bei längerer Suche entdeckten Kodierungsstandard gut genug entspricht, um eine automatische Weiterverarbeitung zuzulassen. Bei den Polygondaten der Ländergrenzen war eine Zuordnung von Hand ohnehin erforderlich, da sie keinen brauchbaren Schlüssel enthielten. Aber auch später, als es darum ging, die Staatenliste um eine weitere Spalte mit einem anderen Kodierungsschema zu ergänzen, konnten die Zuweisungen nicht automatisch erfolgen.

Weiterhin enthält die Stammdatentabelle (DIM_STAATEN) etliche Ländereinträge, die definitiv veraltet sind und weiterhin ein halbes Dutzend Einträge, die auf unterschiedliche Weise ausdrücken, dass die Herkunft eines Studierenden unbekannt ist oder keinem anderen Eintrag sinnvoll zugeordnet werden kann. Deshalb wurden alle Einträge dieser Stammdatentabelle mit Einträgen aus einer neu erstellten, bereinigten Tabelle assoziiert, die nur die aktuell existierenden Ländereinträge mit Verknüpfungen zu zugehörigen Polygondaten enthält. Diese sind es, die auf dem Google Earth-Globus dargestellt werden sollen.

Um eine bessere Verwaltbarkeit der Daten sowie höhere Flexibilität bei sich verändernden Landesgrenzen zu erreichen und weil sich die gefundenen Polygondaten dazu anboten, wurde eine zusätzliche Tabelle erstellt, die eine Liste von Gebieten und den zugehörigen Polygondaten enthält. Jedes Gebiet ist mit einem Eintrag der Ländertabelle verbunden und wird auf dem Globus als Teil dieses Landes dargestellt. Jedem Land können auf diese Weise mehr als ein Gebiet zugeordnet werden. Ob diese Trennung letztlich wirklich hilfreich ist, wird sich zeigen.

Die Idee, eine bereinigte Ländertabelle mit genau den aktuell enthaltenen Einträgen (alle aktiven Länder, ein Eintrag "Sonstige" pro Kontinent, ein Eintrag "Sonstige" für die Gesamtwelt) zu schaffen, wurde nicht sofort vollständig umgesetzt. Viele Schwierigkeiten wurden erst spät offenbar, und es wirkte anfangs intuitiver, die neu hinzugefügten Polygon- und Länderdaten über den bereits bestehenden Primärschlüssel (DIM_STAATEN.STA_ID) der Stammdatentabelle zuzuordnen und nicht umgekehrt jede Zeile der Stammdatentabelle mit einer Zeile einer neu hinzugefügten Ländertabelle zu verknüpfen.

Nachdem die neue Ländertabelle schließlich in Gebrauch war, wurde von Hand eine Spalte hinzugefügt, die die Landeskennung jedes Eintrags in einem international standardisierten Kodierungsschema enthält. Anhand dieser Spalte wurde es verhältnismäßig einfach, Metadaten wie die Hauptstädte oder Bevölkerungszahlen einzutragen. (Siehe Abschnitt "Datenpflege".)

Integration des Google Earth-Plugins in die Flex-Anwendung

Beim Versuch, die Google Earth-Komponente wie andere Komponenten als Registerreiter in die Flex-Anwendung zu integrieren, traten einige Schwierigkeiten auf. Da es sich beim Google Earth-Plugin um eine noch neue Technologie handelt, existierte während der Entwicklungszeit keine direkte Schnittstelle zwischen Flex und der Plugin-API. Das Plugin selbst konnte deshalb nicht direkt innerhalb der Flex-GUI dargestellt werden, sondern musste in einem HTML-Layer an der richtigen Stelle über das Flash-Plugin gelegt werden, in dem die Flex-GUI ausgeführt wird. Das verwendete Grundgerüst für diese Umsetzung entstammt dem Blogeintrag "Google Earth + Flex Source Code" von Andrew Trice in der Beispielumsetzung von Johannes Emden. Obwohl diese Form der Umsetzung zum Entwicklungszeitpunkt die einzig praktikable zu sein schien, galt es weitere Probleme zu beheben.

Zwar wurde das Plugin im Rahmen der HTML-Seite oberhalb der Flex-GUI dargestellt, der Inhalt der Infofenster, die beim Klicken auf die Landesflaggen erscheinen, jedoch unterhalb der Flex-GUI. Die Infofenster enthielten also anfangs keine Informationen über das angeklickte Land, sondern schnitten gewissermaßen ein Loch in die Darstellung des Google Earth-Plugins und zeigten den dahinterliegenden Teil der Flex-GUI. Es dauerte einige Zeit, das Problem überhaupt korrekt zu beschreiben. Die Abfolge der Ebenenüberdeckungen ist nicht unbedingt logisch und der hinter dem Plugin liegende Teil der Flex-GUI war zudem durchgängig schwarz gefärbt. Deshalb wurde zuerst nach einer fehlerhaften oder nicht gesetzten Einstellung in der Google Earth-API gesucht und erst danach, um es ausschließen zu können, die Möglichkeit der Überlagerung des HTML-Inhalts der Infofenster durch das Flash-Plugin überprüft. Die seltsame Lösung bestand schließlich unter anderem darin, die Hintergrundeigenschaften des eingebetteten Flash-Plugins auf HTML-Ebene auf "durchsichtig" zu setzen. Dazu musste die (undurchsichtige) Hintergrundgestaltung der Flex-Anwendung in den <body>-Tag der HTML-Seite verschoben werden, was unter anderem zur Entstehung des Designs des initialen Ladebildschirms führte.

Eine ähnliche, jedoch ungleich schneller gelöste Schwierigkeit bestand darin, das Google Earth-Plugin über die Flex-GUI ein- und ausblenden zu können. Die Ansätze, den das Plugin beherbergenden HTML-Layer nicht darstellen zu lassen (CSS-Eigenschaft display) oder auf der Z-Achse hinter das Flash-Plugin zu legen (CSS-Eigenschaft z-index), hatten keinen Auswirkungen oder führten zum Absturz des Plugins. Durch Setzen der Breite des HTML-Layers auf den Wert '0' konnte die gewünschte Funktion zur Ausblendung des Plugins jedoch realisiert werden.

Steuerung des Google Earth-Plugins

Parallel zu den übrigen Aufgaben fand über den Gesamtzeitraum eine stetige Weiterentwicklung derjenigen Projektteile statt, die die Steuerung des Google Earth-Plugins auf Clientseite übernehmen. Insgesamt wurde in diesem Bereich die meiste Zeit investiert, da mit ActionScript/Flex, JavaScript, der Google Earth-API, dem KML-Format und (bei seltenen Problemen) HTML/CSS einige Technologien zum Einsatz kamen, die teilweise erlernt werden mussten und deren Gewichtung nicht immer auf Anhieb korrekt einzuschätzen war.

Ohne ins Detail zu gehen, sollen an dieser Stelle die für die Entwicklung der Google Earth-Komponente spezifischen Technologien vorgestellt werden:

JavaScript
Bei JavaScript handelt es sich um eine Java sehr ähnliche Scriptsprache, die vor allem innerhalb von Webbrowsern zur dynamischen Veränderung des angezeigten (X)HTML-Dokuments eingesetzt wird (Document Object Model Scripting). Die Google Earth-API ist derzeit nur über JavaScript ansprechbar, stellt jedoch ebenfalls eine Art hierarchisches Document Object Model bereit. JavaScript verbindet die Flex-GUI und das Google Earth-Plugin und erfüllt in der Google Earth-Komponente eine wichtige Funktion.
Google Earth-API
Die von Google bereitgestellte Programmschnittstelle zur Beeinflussung der Darstellung des Google Earth-Plugins. Sie verwaltet die auf dem Globus darzustellenden Objekte und deren Eigenschaften in einer hierarchischen Struktur, die in weiten Teilen eine objektorientierte Nachbildung der Struktur eines KML-Dokuments ist. Änderungen dieser Objekthierarchie wirken sich in der Regel unverzüglich auf die Darstellung des Globus aus.
Keyhole Markup Language (KML)
Ein im Rahmen der Entwicklung von Google Earth entstandenes XML-Schema zur hierarchisierbaren Speicherung (Ordner-Konzept) von Angaben zu geographischen Orten und von geographischen Visualisierungen in Form von Grafiken oder Polygonen. Daten im KML-Format können vom Google Earth-Plugin direkt geladen und der bestehenden Objektstruktur hinzugefügt werden. Das KML-Format ist der geeignete Weg, größere Datenmengen ans Google Earth-Plugin zu übergeben.

Die Arbeit mit der Google Earth-API benötigte einige Einarbeitungszeit, da die von Google bereitgestellte API-Referenz in weiten Teilen zu knapp formuliert ist und beim Lesen vieler Einträge kaum Rückschlüsse auf den größeren Zusammenhang möglich sind. Ein Beispiel für die Menge an Informationen, die üblicherweise im Abschnitt "Detailed Description" zu finden sind:

The KmlPlacemark is a feature with associated Geometry. (Google Earth-API, KmlPlacemark)

Als beste Herangehensweise im Umgang mit der Objektstruktur stellte sich deshalb schnell das Probieren heraus. Da JavaScript im Umgang mit Datentypen wenig strikt ist und die Google Earth-API-Referenz in der Regel nur den Interface-Typ einer Methodenrückgabe auflistet, wurde es häufig notwendig, die getType()-Methode eines erhaltenen Objekts aufzurufen, um herauszubekommen, ob eine JavaScript-Funktion überhaupt den richtigen Objekttyp liefert und an der richtigen Stelle der Objektstruktur arbeitet.

Beim Hinzufügen der Polygondaten und Ländermarkierungen aus der Datenbank stellte sich der Weg über die Objektstruktur schließlich als zu langsam heraus. Die Objekte konnten nicht im JavaScript-Model erzeugt und dann in die Objektstruktur des Google Earth-Plugins übertragen werden. Dieser Ansatz hatte zwar den Vorteil, dass eine Referenz auf das dem Plugin hinzugefügte Objekt im JavaScript behalten werden konnte, die für das Ändern der Polygonfarbe oder das Ein- und Ausblenden von Objekten bei Zoomänderungen gebraucht wird. Doch ab einer gewissen, sehr geringen Anzahl gleichzeitig hinzugefügter Objekte stellte das Plugin nicht mehr alle auf dem Globus dar. Es wurde daher nötig, die Polygondaten und sonstigen Marker ins KML-Format umzuformen und diese KML-Zeichenketten insgesamt ans Plugin zu übergeben. Die entsprechenden Methoden zur Umformung wurden in den Flex-Teil ausgelagert, sodass im JavaScript-Teil nur noch die fertige Zeichenkette ans Plugin weitergereicht werden muss. Allerdings gelingt es auf diese Weise nicht, im JavaScript-Model die Referenzen auf die dargestellten Objekte zu erhalten. Diese müssen bei Datenübergabe im KML-Format nachträglich aus der Objektstruktur des Google Earth-Models gewonnen werden. (Die entsprechende Methode befindet sich als Beispiel im Anhang.)

Da die vom JavaScript-Teil zu leistenden Aufgaben mit der Zeit wuchsen, wurde schließlich die bisherige Sammlung von Einzelfunktionen aufgegeben und zur Steuerung des Google Earth-Plugins im JavaScript eine eigene Model-Controller-Objektstruktur aufgebaut. Die aktuelle Version des Controllers verarbeitet zehn verschiedene aus dem Flex-Teil abgeschickte Events und fünf verschiedene Events, die vom Google Earth-Plugin über Callbacks ausgelöst werden. Im Model werden alle zwischen Flex und dem Google Earth-Plugin zu synchronisierenden allgemeinen Statusdaten (etwa die Zoomstufe) gehalten und außerdem eine Liste von Länderobjekten, die zwischengespeicherte, gerade nicht dargestellte Daten jedes Landes enthalten sowie Referenzen auf alle zu diesem Land gehörenden auf dem Globus angezeigten Polygone und Markierungen.

Datenbank-Backend

Datenbankaufbau

Tabelle GE_COUNTRYINFO

ID
Eindeutiger Primärschlüssel. Jeder Eintrag aus der Stammdatentabelle DIM_STAATEN soll auf eine ID aus dieser Tabelle verweisen. Dieser Wert wird auch dazu verwendet, im JavaScript-Model das entsprechende Land zu referenzieren. Um dabei eine konstante Lookup-Zeit beim Ermitteln eines Landobjekts anhand seiner ID zu gewährleisten, wird der Wert des ID-Feldes als Index im Lookup-Array gesetzt. Um den Speicherverbrauch des Lookup-Arrays gering zu halten, sollten daher große ID-Werte vermieden werden.
ISO3166A2
Hilfsspalte zur Ermittlung von Landesinformationen nach dem ISO 3166-Standard (ALPHA-2), siehe Beschreibung der Spalte FIPS10. Die Werte dieser Spalte werden in der entsprechenden Zoomstufe als Landeskürzel auf dem Globus dargestellt.
FIPS10
Hilfsspalte zur Ermittlung von Landesinformationen nach dem FIPS 10-Standard. Tabellen mit Informationen über Länder enthalten in der Regel eine Indexspalte, die ein Land einem Schlüssel eines bestimmten Kodierungsschemas (z. B. ISO 3166) zuordnet. Indem in der hier vorliegenden Tabelle mit jedem Land die entsprechenden Schlüssel verschiedener Kodierungsschemen assoziiert werden, kann das Einlesen von Landesdaten in die Datenbank automatisiert werden. Das hilfreichste Kodierungsschema ist das im World Factbook verwendete FIPS 10-Schema, für das eine Tabelle mit Entsprechungen in anderen Schemen existiert. Demnach besteht die entscheidende, nicht automatisierbare Zuordnung in der Verknüpfung der ID-Spalte mit der FIPS10-Spalte. Die Inhalte aller weiteren Spalten können sukzessive anhand der FIPS 10-Kennung ermittelt werden.
STA_ID
Vermutlich obsolet, aber vorsichtshalber noch nicht entfernt. Die Zuordnung von Länderkennungen aus den Stammdaten zu Einträgen in dieser Tabelle findet in Tabelle DIM_STAATEN statt. Der Inhalt dieser Spalte sollte nicht verwendet werden.
STA_NID
Von der Datenbank-Gruppe zur Beschleunigung von SQL-Queries angelegt. (Bei einem Datenupdate muss sicherlich auch diese Spalte an den entsprechenden Stellen angepasst werden, falls sich in DIM_STAATEN.STA_AIKZ etwas ändert. Die Spalte sollte jedoch im Zweifel auch problemlos neu zu erstellen sein, wenn jedem Eintrag aus GE_COUNTRYINFO genau ein aktiver Eintrag aus DIM_STAATEN zugewiesen ist. Siehe auch Abschnitt "Datenupdate".)
IS_COUNTRY
Bestimmt, ob eine Zeile als Land aufgefasst und dargestellt werden soll. Da die Länderangaben aus den Stammdaten nicht immer eindeutig auf ein Land verweisen, enthält die Tabelle GE_COUNTRYINFO sechs Einträge für Angaben, die entweder einem Kontinent oder nur der Welt insgesamt zugeordnet werden können. Für diese Fälle ist der Wert dieser Spalte '0', für alle anderen '1'. Allgemein gilt: Steht für einen Eintrag in dieser Spalte der Wert '1', kann der Eintrag als Land mit Flagge und mindestens einer Region auf dem Globus angezeigt werden.
NAME
Der auf dem Globus darzustellende Landesname. Diese Spalte enthält die gebräuchlichen deutschen Landesbezeichnungen (z. B. "Großbritannien" statt "Vereinigtes Königreich").
NAME_US
Hilfsspalte zur Ermittlung von Landesinformationen, siehe Beschreibung der Spalte FIPS10. Im World Factbook wird in Tabellen zumeist nur der Landesname, nicht die FIPS 10-Kennung verwendet. Diese Spalte lässt sich jedoch aus der FIPS10-Spalte ableiten.
CONTINENT_ID
Ordnet ein Land einem Kontinent (GE_CONTINENTINFO.ID) zu. Die Werte wurden aus den Stammdaten übernommen.
CENTER
Definiert den "Mittelpunkt" (die Position, an der die Landesflagge auf dem Globus gezeichnet werden soll) eines Landes. (KmlCoordinate)
CAPITAL
Die Landeshauptstadt.
POPULATION
Die Einwohnerzahl des Landes.
AREA
Die Landesfläche in km2.
GDP_PER_CAPITA
Das Bruttoinlandsprodukt pro Einwohner.
OFFICIAL_LANGUAGES
Offizielle Landessprachen.

Tabelle GE_CONTINENTINFO

ID
Eindeutiger Primärschlüssel. Hier dürfen nur die Zahlen 1 bis 5 verwendet werden, da die ID im Quellcode als Arrayindex verwendet wird.
STA_ERDTEIL
Der diesem Erdteil entsprechende Kontinentschlüssel aus der Stammdatentabelle DIM_STAATEN.
NAME
Der Name des Kontinents.
CENTER
Der "Mittelpunkt" des Kontinents (derjenige Punkt, an dem das Placemark auf dem Globus platziert wird). (KmlCoordinate)

Tabelle GE_MAPREGIONS

ID
Eindeutiger Primärschlüssel, wird gegenwärtig von keiner anderen Tabelle referenziert.
COUNTRY_ID
Das Land, dem das Gebiet angehört.
BOUNDARIES
Die Grenzen des Gebiets. (KmlPolygonList)
COMMENT
Da die Polygondaten allein wenig Aussagekraft besitzen, kann in dieses Feld etwa der Name des Gebiets eingetragen werden. Das Feld dient ausschließlich zu Informationszwecken und hat für die Funktionalität keine Bedeutung. (Da die aktuellen Inhalte dieser Spalte ebenfalls aus der unter "Datenquellen" angegebenen KML-Datei stammen, ist es zufällig möglich, die Spalte BOUNDARIES über die Inhalte der Spalte COMMENT zu füllen. Dies könnte sich unter gewissen Umständen bei einem späteren Update als nützlich erweisen: Falls sich in einer kommenden Version des World Borders Dataset die bestehenden Gebietsbezeichnungen nicht ändern, sondern lediglich neue hinzukommen, könnte der Datenbankinhalt automatisch aktualisiert werden. Es könnte sich also lohnen, die Inhalte dieser Spalte nicht zu verändern.)

Speicherformate

Bei jeder Initialisierung der Anwendung werden die Definitionsdaten aller Landesgrenzen vom Server an den Client geschickt. Um das Datenvolumen zu reduzieren, werden die Polygondaten in der Datenbank nicht im KML-Format gespeichert, sondern in einem optimierten Mikroformat, das in diesem Abschnitt definiert wird. Nach der Übertragung werden die Daten im Client wieder ins KML-Format umgeformt.

Die angegebenen Formatangaben müssen exakt so verwendet werden, wie es hier beschrieben wird. Falsch gesetzte oder überzählige Leerzeichen, Semikolons oder Pipes (|) führen fast sicher zu Fehlern, Zeilenumbrüche sind generell nicht vorgesehen. Vor allem Felder vom Typ KmlPolygonList sollten daher möglichst nicht von Hand editiert werden.

Die Angabe von Koordinatenpaaren richtet sich durchgehend nach der im KML-Format üblichen Abfolge longitude,latitude (Längengrad, Breitengrad).

Mit der Java-Klasse cgp.helper.googleearth.KmlParser können wohlgeformte KML-Dokumente passender Struktur ins Datenbankformat überführt werden.

KmlCoordinate

Eine geographische Koordinate im Format longitude,latitude (Längengrad, Breitengrad).

Formal:

 c := "long,lat"

Beispiel:

 0.0,5.0

KmlLinearRing

Ein geschlossener Ring aus durch jeweils genau ein Leerzeichen voneinander abgetrennten Einträgen im Format KmlCoordinate. Der Ring wird geschlossen, indem als letztes Koordinatenpaar wiederum das erste hinzugefügt wird.

Formal:

 r := "c1 c2 ... cn c1"

Beispiel:

 0.0,0.0 0.0,5.0 5.0,5.0 0.0,0.0

KmlPolygon

Polygone bestehen aus einem äußeren KmlLinearRing und beliebig vielen (auch keinen) inneren Ringen, die Aussparungen in der Polygonfläche definieren. Die Aussparungen werden für Länder benötigt, die andere Länder komplett umschließen (etwa im Fall von Südafrika und Lesotho). Innere Polygone werden durch das Präfix "i:" gekennzeichnet und durch Semikolons vom äußeren Ring und voneinander abgregrenzt.

Formal:

 p := "r1[;i:r2;...;i:rn]"

Beispiel:

 0.0,0.0 0.0,5.0 5.0,5.0 0.0,0.0;i:1.0,2.0 2.0,3.0 1.0,3.0 1.0,2.0

KmlPolygonList

Eine Liste von durch Pipes (|) voneinander abgegrenzten Einträgen im Format KmlPolygon.

Formal:

 l := "p1[|p2|...|pn]"

Beispiel:

 0.0,0.0 0.0,5.0 5.0,5.0 0.0,0.0|6.0,6.0 8.0,6.0 8.0,8.0 6.0,6.0

Datenupdate und Datenpflege

Der einzige Verbindungspunkt zwischen den Stammdaten und den Google Earth-Daten besteht über die Spalte DIM_STAATEN.STA_GE_COUNTRYINFO_ID, die den Stammdaten hinzugefügt wurde, um jede dort enthaltene Staaten-ID einem Eintrag aus der Tabelle GE_COUNTRYINFO zuzuordnen. Falls die Tabelle DIM_STAATEN während des Updates überschrieben wird, muss die Assoziation zwischen den Spalten STA_ID und STA_GE_COUNTRYINFO_ID vorher gesichert und nachher wieder hinzugefügt werden.

(Siehe außerdem die Erläuterungen zur Spalte GE_COUNTRYINFO.STA_NID.)

Darüber hinaus ist nach einem Datenupdate lediglich darauf zu achten, dass die folgenden Bedingungen erfüllt sind:

Hinweis: Ein Eintrag aus DIM_STAATEN ist dann aktiv, wenn das Feld STA_AIKZ auf 'A' steht.

  • Jeder Eintrag der Tabelle DIM_STAATEN soll einem Eintrag aus GE_COUNTRYINFO zugewiesen sein.
  • Jedem Eintrag der Tabelle GE_COUNTRYINFO (mit Ausnahme der Sammeleinträge für "sonstige" Fälle) soll genau ein in DIM_STAATEN als aktiv gekennzeichneter Eintrag zugewiesen sein. (Das bedeutet anschaulich, dass so viele Länder auf dem Globus dargestellt werden sollen, wie in DIM_STAATEN als aktiv gekennzeichnet sind.)

Von diesen Regeln abweichende Einträge lassen sich über SQL-Abfragen finden und von Hand bearbeiten. Zwei Fallbeispiele:

Angenommen, die Demokratische Arabische Republik Sahara ist nach einem Datenupdate in der Tabelle DIM_STAATEN als aktiver Eintrag enthalten. Dieser Eintrag muss nun einem Eintrag aus GE_COUNTRYINFO zugewiesen werden, um die eben aufgestellten Bedingungen zu erfüllen. Dazu muss dort ein neuer Eintrag eingefügt werden, da bereits jeder Eintrag aus GE_COUNTRYINFO mit einem aktiven Eintrag aus DIM_STAATEN assoziiert ist. Das Hinzufügen des neuen Westsahara-Eintrags ist glücklicherweise verhältnismäßig einfach, da ein passender eigenständiger Gebietseintrag in GE_MAPREGIONS existiert, dessen COUNTRY_ID lediglich von "Marokko" auf die neue "Westsahara"-ID geändert werden muss. (Zudem muss eine entsprechende Flagge im Ordner "./googleEarth/flags/" der Client-Anwendung hinzugefügt werden. Der Dateiname entspricht der FIPS 10-ID des Landes. Siehe Abschnitt "Datenquellen".)

Wenn sich der Inselstaat Nauru an Neuseeland angliedert, steht er nach dem nächsten Datenupdate als inaktiv in DIM_STAATEN. Eine passende Abfrage würde ergeben, dass dem GE_COUNTRYINFO-Eintrag für "Nauru" kein aktiver Eintrag aus DIM_STAATEN mehr zugeordnet ist. Die Verknüpfungen der Nauru-Einträge in DIM_STAATEN und GE_MAPREGIONS müssten nun auf "Neuseeland" geändert werden, die Nauru-Zeile aus GE_COUNTRYINFO müsste entfernt werden. (Zum Aktualisieren der Landesflaggen siehe erstes Beispiel.)

Sollten die vorhandenen Polygondaten in GE_MAPREGIONS nicht mehr ausreichen, um eine Änderung der poltischen Grenzen nachzuvollziehen (falls sich etwa Bayern für unabhängig erklärt), müssen die Polygondaten entweder von Hand bearbeitet oder es muss ein aktualisierter Satz gefunden werden. Letzteres ist potentiell problematisch, da die Zuordnungen der Gebiete zu genau den Ländern, die in GE_COUNTRYINFO enthalten sind, nicht automatisiert werden können, wenn die Polygondaten nicht mit verwertbaren Schlüsseln versehen sind. (Siehe die Erläuterungen zur Spalte GE_MAPREGIONS.COMMENT für weitere Gedanken.)

Die Landesinformationen können problemlos anhand der Kodierungsschlüssel in der Tabelle GE_COUNTRYINFO aktualisiert werden. Im Serverprojekt liegen etliche Hilfsklassen, die als Beispiel dienen. Vor allem die "Rank Order Pages" aus dem World Factbook sind eine ergiebige, leicht zu verarbeitende Quelle. (Der Schlüssel GE_COUNTRYINFO.NAME_US ist besonders hilfreich.)

Datenquellen

World Borders Dataset, Bjørn Sandvik
Die geographischen Koordinaten zur Definition der Landesgrenzen wurden durch Weiterverarbeiten der Ausgabe der Thematic Mapping Engine gewonnen. Diese Ausgabe basiert auf dem World Borders Dataset, das von Bjørn Sandvik auf Grundlage frei zugänglicher Daten definiert wurde. Die Verwendung des World Borders Dataset unterliegt einer Creative Commons-Lizenz (CC-BY-SA, v3.0). Da die Daten nicht modifiziert, sondern lediglich umformatiert wurden, wird auf erneute Bereitstellung im Sinne dieser Lizenz verzichtet.
The World Factbook, Central Intelligence Agency
Der Großteil der dargestellten Landesinformationen sowie die Landesflaggen sind der Onlineversion des von der US-amerikanischen Central Intelligence Agency herausgegebenen World Factbook entnommen. Die Inhalte dürfen frei verwendet werden (public domain).
Wikipedia, Wikimedia Foundation
Die dargestellten Landesnamen, Hauptstädte und Landessprachen entstammen der deutschsprachigen Version der Wikipedia.

Anhang

GEController.prototype.flexOnKmlReceived

/**
 * Flex-Callback. Nimmt eine Zeichenkette im KML-Format entgegen und laesst
 * diese vom Google Earth-Plugin verarbeiten. Erzeugt daraufhin Entsprechungen
 * der hinzugefuegten Objekte im JavaScript-Model.
 *
 * Vgl. ./src/cgprakt08/util/googleEarth/KmlBuilder.as fuer genaues Format der
 * zu uebergebenden Zeichenkette. 
 *
 * @param data Zeichenkette im KML-Format
 */
GEController.prototype.flexOnKmlReceived = function(data)
{
	// m_ge   : Instanz des Google Earth-Plugins
	// folder : Root-Element der uebergebenen KML-Daten
	var folder = this.m_ge.parseKml(data);
	var i = 0;
 
	if (folder.getId() == "countryObjects")
	{
		// In diesem Paket sind Laenderdaten uebergeben worden.
 
		var placemarks = folder.getFeatures().getChildNodes();
 
		// Ein solches Paket enthaelt Zweiergruppen von Landesmarker (Flagge)
		// und zugehoerigem Landespolygon. Beide Objekte sollen von derselben 
		// GEPolygonData()-Instanz referenziert werden.
		var marker = true;
 
		var countryObject;
 
		// Fuer jeden Eintrag innerhalb der Folder...
		for (i = 0; i < placemarks.getLength(); i++)
		{
			var placemark = placemarks.item(i);
 
			if (marker)
			{
				countryObject = new GEPolygonData();
 
				// Definiert Ereignisse fuer den Landesmarker. Die angegebenen
				// Callback-Funktionen rufen wiederum eine Funktion dieses
				// Controllers auf. (Instanzmethoden lassen sich nicht direkt
				// als Callbacks verwenden.)
				google.earth.addEventListener(placemark, 'mouseover',
						geGoogleOnPlacemarkMouseOver);
				google.earth.addEventListener(placemark, 'mouseout',
						geGoogleOnPlacemarkMouseOut);
 
				countryObject.setReferencePlacemark(placemark);
			}
			else
			{
				// Das Description-Feld des Polygons wird zweckentfremdet, um
				// zusaetzliche Daten zu uebergeben.
				var parts = placemark.getDescription().split(";");
				placemark.setDescription("");
 
				countryObject.setId(placemark.getId());
				countryObject.setReference(placemark);
				countryObject.setContinentId(parts[0]);
				countryObject.setName(parts[1]);
				countryObject.setShortName(parts[2]);
 
				this.m_model.polygonData.addItem(countryObject);
			}
 
			marker = !marker;
		}
	}
	else if (folder.getId() == "continentMarkers")
	{
		// In diesem Paket sind Kontinent-Daten uebergeben worden.
 
		var placemarks = folder.getFeatures().getChildNodes();
 
		for (i = 0; i < placemarks.getLength(); i++)
		{
			var placemark = placemarks.item(i);
			this.m_model.continentPlacemarks.push(new Array(placemark.getId(),
					placemark));
		}
	}
 
	// Hier werden die in der KML-Zeichenkette definierten Objekte tatsaechlich
	// ins Model des Plugins eingefuegt.
	this.m_ge.getFeatures().appendChild(folder);
}


Page last modified on September 20, 2008, at 05:15 PM