<\/p>\n
Google Earth in Ihrer eigenen Anwendung – angezeigt in einem ganz normalen Formular, das Sie nach Belieben mit Steuerelementen bestücken können, um durch die Gegend zu schwirren, Orte zu suchen, Details anzuzeigen oder gar Grafiken oder Texte unterzubringen Ja, das geht. Wir zeigen, wie es funktioniert und was Sie beim Einsatz des benötigten ActiveX-Steuerelements beachten müssen.<\/b><\/p>\n
Vor einiger Zeit haben wir gezeigt, wie Sie Google Earth aus Access heraus automatisieren. Mithilfe der COM-Schnittstelle lassen sich Orte anfliegen, Daten auslesen, Ortsmarken setzen und vieles mehr. Auch mit den neueren Versionen der Software funktioniert diese Lösung nach wie vor. Die damals geäußerte Mutmaßung, Google werde im Laufe der Zeit das Objektmodell erweitern, hat sich aber leider nicht bestätigt. Stattdessen gibt es seit einigen Monaten ein Browser-Plugin von Google Earth, das Sie als ActiveX-Steuerelement in Access-Formulare einbinden und fernsteuern können.<\/p>\n
Die Beispieldatenbank zum Beitrag Google Earth ferngesteuert<\/b> (Shortlink 457) öffnet Google Earth im Webbrowser und steuert es über die Automationsschnittstelle fern. Eine solche Lösung lässt sich vielseitig einsetzen, um etwa Orte zu Kundendaten anzuzeigen. Das große Handicap der Lösung besteht jedoch darin, dass die zwei separaten Anwendungen – Access und Google Earth – viel Platz benötigen und ein sinnvolles Arbeiten somit eigentlich nur mit zwei Monitoren möglich ist.<\/p>\n
Im Frühsommer erschien die erste Beta des Google Earth-Plugins V 4.3 – die Versionsnummer lehnt sich jeweils an die Version der Standalone-Anwendung an. Dabei handelt es sich um ein Steuerelement, das für den Einsatz in Webseiten gedacht ist und ähnlich arbeitet, wie die Satellitenansicht von Google-Maps. Während jene aber ein statisches 2D-Erscheinungsbild liefert, lässt sich die 3D-Weltkugel oder -karte im Plugin über Maus und Tastatur in gleicher Weise bewegen wie in der Google Earth-Anwendung.<\/p>\n
Installation<\/b><\/p>\n
Gerät man auf eine Webseite wie [1], die das Plugin eingebaut hat, so ist zunächst nichts Weltbewegendes zu sehen. Stattdessen fordert eine Grafik mit hinterlegtem Link dazu auf, das Plugin herunterzuladen. Tatsächlich ist dies die einzige Möglichkeit, das Plugin zu installieren; eine direkte Download-URL gibt es nicht.<\/p>\n
Der Grund hierfür ist, dass Google eine kleine Setup.exe <\/b>zwischenschaltet, die erst überprüft, ob sich eine Version des Plugins bereits auf dem System befindet und ob es sich um eine möglicherweise veraltete Version handelt. Nur diese Setup.exe <\/b>kennt den Ort des aktuellen Pakets im Web, das dann im Folgenden automatisch heruntergeladen und installiert wird. <\/p>\n
Nach einem Refresh der Webseite zeigt sich Google Earth im Plugin-Fenster. Im Internet-Explorer erscheint zuvor wahrscheinlich in der Meldungsleiste die Nachfrage, ob man das ActiveX-Steuerelement zulassen will. Diese Nachfrage führt auch schon zur Erkenntnis, dass es sich bei dem Plugin nur um ein ActiveX-Steuerelement handeln kann und nicht etwa um ein JavaScript-Gebäude wie bei Google-Maps.<\/p>\n
Technik<\/b><\/p>\n
Das ActiveX-Steuerelement selbst übernimmt nur einen kleinen Teil der Arbeit. Im Hintergrund werkelt eine vollständige Installation von Google Earth (geplugin.exe<\/b>), die aber gegenüber der Standalone-Anwendung modifiziert ist. Das ActiveX-Control fungiert lediglich als Host für die eigentliche Anwendung.<\/p>\n
Diese Arbeitsteilung ist nötig, damit das Plugin unabhängig von Browser und Plattform eingesetzt werden kann. So kommt etwa im Firefox ein anderes Plugin zum Einsatz, welches auf QWidgets statt ActiveX basiert. Auch dieses verwendet jedoch die gleiche Google Earth-Engine im Hintergrund.<\/p>\n
Die Aufgabe des Plugins besteht also darin, die Interaktion zum Benutzer und zur Webseite (JavaScript) sicherzustellen sowie die 3D-Daten der Engine per DirectX zu rendern. Damit es per Scriptsprache steuerbar ist, muss es wohl eine Schnittstelle enthalten, die Anweisungen an die Google Earth-Engine weiterleitet. Für ein ActiveX-Control ist das die eingebaute Typbibliothek, welche sich in die Verweise eines VBA-Projekts einbinden lassen können sollte.<\/p>\n
Wo aber befindet sich das ActiveX-Steuerelement Beim Stöbern durch die Verzeichnisse der Plugin-Installation – standardmäßig C:\\Programme\\Google\\Google Earth Plugin <\/b>– findet man einen Zweig IE<\/b>, der die Datei plugin_ax.dll <\/b>enthält. Und die ist das gesuchte ActiveX-Steuerelement.<\/p>\n
Plugin im Access-Formular<\/b><\/p>\n
Was als ActiveX-Control in Webseiten funktioniert, das sollte man auch in Access-Formularen im Entwurf über das Menü Einfügen | ActiveX-Steuerelement… <\/b>verwenden können. Die Frage ist nur, wie das Steuerelement wohl heißt. Den Ausdruck Google…<\/b> sucht man in der Liste der Steuerelemente vergeblich – das Control nennt sich etwas kryptisch GEPluginCoClass Object<\/b>.<\/p>\n
Das Einfügen ins Formular erfolgt problemlos. Das Steuerelement zeigt sich im Entwurf als weiße Fläche mit dem Schriftzug ATL 8.0<\/b>, was lediglich den Schluss zulässt, dass es wahrscheinlich mit Visual Studio C++ 2005 entwickelt wurde.<\/p>\n
Wer das Formular nun öffnet, wird zunächst enttäuscht. Das Steuerelement zeigt lediglich eine schwarze Fläche ohne Erdkugel. So einfach scheint es Google uns offenbar nicht machen zu wollen. Tatsächlich benötigt das Control erst Initialisierungscode, bevor es das tut, was wir von ihm erwarten.<\/p>\n
Da die Schnittstelle des Controls in keiner Weise dokumentiert ist, da es schließlich für die Verwendung in Webseiten vorgesehen ist, die es über von Google eingeklinkte komplizierte JavaScripts steuert, hat das Ausklamüsern eines funktionierenden Initialisierungscodes speziell für die neue, Anfang April erschienene Version 5 etwas Kopfzerbrechen bereitet – dazu später mehr.<\/p>\n
Lizenzfragen<\/b><\/p>\n
An dieser Stelle muss darauf hingewiesen werden, dass der Einsatz des Controls unter Access nicht ganz im Sinne von Google ist. Es gibt eine Webseite [2], die Terms of Service, mit ausführlichen Informationen darüber, unter welchen Umständen Google Earth verwendet werden kann und darf.<\/p>\n
Das dort angesprochene Google Earth API [3] besteht aus einem umfangreichen Satz von JavaScripts, die nach Angabe eines Keys von den Google-Servern nachgeladen werden und damit in eigene Webseiten integriert werden können.<\/p>\n
Diesen Key bekommt man aber nur nach Registrierung des APIs bei Google, wenn auch kostenlos. Ein Key ist dabei immer einer bestimmten Domain oder einem Unterverzeichnis derselben zugeordnet. Über diese Kombination kann Google dann Nutzungsstatistiken erheben, und das ist wohl der Gegenwert, den Google für die freie Verwendung des Systems erwarten.<\/p>\n
Nun braucht man unter Access aber kein JavaScript zur Steuerung des Plugins und damit entfällt auch die sonst notwendige Angabe eines Keys. Die Daten, welche die Google Earth-Engine von den Servern zieht, können damit nicht mehr dem Nutzer zugeordnet werden. Schlimmstenfalls ist die IP des Rechners bekannt. <\/p>\n
Auch wenn für diese Situation keine klaren Handlungsanweisungen in den Terms of Service zu finden sind, kann man davon ausgehen, dass eine kommerzielle Nutzung ausgeschlossen ist. Google bietet jedoch eine Enterprise-Lizenz für Google Earth an, die gegebenenfalls zu erwerben wäre. Wie viel das kostet, ist offenbar Verhandlungssache, denn konkrete Preisangaben sucht man vergeblich.<\/p>\n
Es ist also grundsätzlich wichtig, sich die Lizenzbestimmungen genauer anzusehen und selbst zu entscheiden, wie und unter welchen Umständen man das Plugin einsetzen möchte und darf.<\/p>\n
Objektmodell<\/b><\/p>\n
Wenn ein ActiveX-Steuerelement in ein Formular oder einen Bericht eingebaut wird, dann setzt Access bekanntlich automatisch einen Verweis auf die zuständige Objektbibliothek. Für das Google Earth-Steuerelement lautet der Name der Bibliothek GEPlugin<\/b>. Öffnen Sie einfach den VBA-Objektkatalog (F2 <\/b>im VBA-Editor) und wählen Sie diesen Eintrag aus dem linken oberen Kombinationsfeld aus.<\/p>\n
War die KML-Bibliothek (Earthlib 1.0<\/b>) für Google Earth so, wie sie im erwähnten Beitrag vorgestellt wurde, noch recht überschaubar, wird man hier von der Fülle der Schnittstellen und Methoden der GEPlugin-Library geradezu erschlagen.<\/p>\n
Die Funktionalität erstreckt sich über Dutzende Klassen mit zahllosen Methoden und Eigenschaften. Das ist einerseits erfreulich, verspricht es doch ausgefeilte Steuerungsmöglichkeiten des Plugins, andererseits verwirrend, weil es keinerlei Dokumentation für das Objektmodell gibt.<\/p>\n
Das jedoch ist auch nicht ganz richtig, wie sich herausstellte. Das Objektmodell ist eng an das des JavaScript-APIs gekoppelt, welches Sie sich unter [3] zu Gemüte führen können. Sowohl die Klassenbezeichnungen als auch die Methodennamen sind weitgehend identisch mit jenen im API.<\/p>\n
Ihr besonderes Augenmerk sollte lediglich solchen Methodennamen gelten, die einen abschließenden Unterstrich aufweisen. Hier handelt es sich ausnahmslos um Funktionen, die spezifisch für das ActiveX-Plugin und nicht dokumentiert sind.<\/p>\n
Das komplette Objektmodell von Google Earth zu erläutern, würde diesen Beitrag sprengen. Dazu brauchte man gut und gerne ein ganzes Buch. Daher der Verweis auf die API-Dokumentation [3] und auch auf die KML-Referenz [4], die im Gegensatz zum API genauer erklärt, wie die einzelnen Objekte einzusetzen und zu kombinieren sind.<\/p>\n
Wer im Aufbau von KML-Dateien bewandert ist, einem Google Earth-spezifischen XML-Schema, der wird das Objektmodell schneller verstehen. Die in der Beispieldatenbank GoogleEarther5.mdb <\/b>enthaltenen Routinen sollten darüber hinaus hinreichend Ausgangsmaterial für die weitere Programmierung und Erforschung des Steuerelements enthalten.<\/p>\n
Plugin vs. Google Earth-Automatisierung <\/b><\/p>\n
Eingangs wurde bereits der größte Vorzug genannt: Man braucht mit dem Plugin nicht mehr zwei Anwendungen, die sich den Monitor teilen oder gar Umschalten notwendig machen, sondern hat nur noch ein Access-Formular vor sich. Das enthaltene GE-Steuerelement lässt sich, je nach Anforderungen, auch per Code auf beliebige Abmessungen bringen (Width<\/b>, Height<\/b>).<\/p>\n
Was im ferngesteuerten Google Earth nur mit Verrenkungen möglich war, etwa das Setzen von Ortsmarken oder das Zeichnen von Polygonen, lässt sich nun per Objektmodell erledigen. Früher musste zu diesem Zweck erst langwierig ein XML-String zusammengesetzt werden. Nun bildet sich dessen Hierarchie in Klassen und Eigenschaften ab, die man setzen sowie ab- und aufrufen kann.<\/p>\n
Der absolute Clou ist jedoch die Möglichkeit, auf Ereignisse des Steuerelements zu reagieren. Das ist mit der Fernsteuerlösung schlicht unmöglich. Sowohl die Erdoberfläche wie auch jedes angelegte Objekt auf ihr ruft Mausereignisse hervor, die abgefangen und behandelt werden können. Ein Klick auf eine gesetzte Ortsmarke ruft eben ein Click<\/b>-Ereignis hervor, das Bewegen der Maus über die Oberfläche zeitigt MouseMove<\/b>-Ereignisse und der Fortschritt des Renderns löst ein Frame<\/b>-Ereignis aus.<\/p>\n
Und schließlich lässt sich ein Screenshot des Plugins in einem Formular auch leichter bewerkstelligen als in einer Fremdanwendung.<\/p>\n
Plugin-Demo<\/b><\/p>\n
Die neue Anwendung GoogleEarther5.mdb <\/b>orientiert sich zunächst an jener des eingangs erwähnten Beitrags. Sie finden hier ein gleichartiges Kundenformular, das die Kunden der Nordwind-Datenbank anzeigt. Statt des seinerzeit eingesetzten MSForms<\/b>-Bildsteuerelements kommt nun aber das Google Earth-Steuerelement ins Spiel, das im Current<\/b>-Ereignis unmittelbar zur Adresse des Kundendatensatzes navigiert.<\/p>\n
Daneben gibt es noch ein Formular namens frmGEPlugin<\/b>, das einige der möglichen Features des Steuerelements demonstrieren soll. Beim Start der Datenbank wird aber zunächst automatisch das Formular frmStart <\/b>geladen. Es hat die Aufgabe zu ermitteln, ob das Plugin überhaupt schon in korrekter Version auf dem Rechner installiert ist. Sollte das der Fall sein, dann schließt es sich sang-und klanglos wieder, bevor es überhaupt sichtbar wurde.<\/p>\n
Andernfalls meldet es, wie die notwendige Installation erfolgen kann (siehe Bild 1). Die Anwendung erwartet zwingend die neue Version 5 (April 2009), weil die Objektbibliothek nicht mehr kompatibel zur Version 4 (Mai 2008) ist. Sollten Sie bereits irgendwann Version 4 installiert haben, so ist es ratsam, diese zuerst über die Systemsteuerung zu deinstallieren, bevor die neue Version aufgespielt wird. Der Startcode im Formular ist ziemlich simpel:<\/p>\n
![\"frmStart.png\"](\"..\/fileadmin\/_temp_\/2009_03\/GoogleEarth2-web-images\/frmStart_opt.jpeg\")
<\/p>\n
Bild 1: Das Startformular erscheint, falls das Plugin nicht in der entsprechenden Version installiert ist.<\/span><\/b><\/p>\n Hier wird über late binding <\/b>versucht, eine Instanz des Plugins zu erhalten. Dazu bedarf es noch gar keines im Formular enthaltenen ActiveX-Steuerelements, das ohnehin zur Fehlermeldung Dieses Formular enthält kein Steuerelement<\/b> beim Öffnen führen würde.<\/p>\n Lässt sich eine Instanz erstellen, dann ist das Plugin offensichtlich installiert. Im nächsten Schritt erfolgt jedoch noch eine Überprüfung auf die passende Version, was diese Zeilen erreichen:<\/p>\n Das Objekt GEPluginCoClass <\/b>kennt eine Funktion getPluginVersion<\/b>, welche die Dateiversionsnummer der plugin_ax.dll <\/b>zurückgibt – aktuell etwa 5.0.11655.6079<\/b>. Wichtig ist nur die erste Zahl, die die Hauptversion wiedergibt und daher einfach mit Val() <\/b>ermittelt wird. Waren die Tests erfolgreich, dann öffnet der weitere Code das Formular frmGEPlugin<\/b>.<\/p>\n Bis dieses sichtbar geladen ist, dürfte aber noch einige Zeit verstreichen, die mit einem in die Beispieldatenbank integrierten Meldungsformular überbrückt wird.<\/p>\n Diese Zeit benötigt das Plugin nämlich für seine Initialisierung. Machen Sie sich bewusst, dass dazu im Hintergrund ein komplettes Google Earth geladen werden muss, welches in Gestalt der geplugin.exe <\/b>im Hauptverzeichnis des Plugins zu finden ist. Die Initialisierung geht zwar schneller vonstatten als bei der Standalone-Version, auf 5-10 Sekunden müssen Sie sich aber schon einrichten.<\/p>\n Interessant ist der Sachverhalt, dass nach Schließen des Formulars frmGEPlugin <\/b>und erneutem Öffnen die Initialisierung blitzschnell abläuft. Sie müssen also nicht befürchten, dass bei jedem Öffnen des Formulars eine Wartepause einzulegen ist. Einfache Erklärung: Ein Schließen des Plugins führt noch nicht automatisch zum Beenden der Engine geplugin.exe <\/b>im Hintergrund. Eine neue Instanz des Plugins kann daher schnell auf den noch bestehenden Prozess zugreifen. Das zeigt sich auch darin, dass bei erneutem Öffnen nicht etwa wieder die Erdkugel erscheint, wie in Bild 2, sondern der zuletzt im Plugin angezeigte Ort.<\/p>\n Bild 2: Demoformular zum Google Earth-Plugin <\/span><\/b><\/p>\n Das Entladen der geplugin.exe <\/b>geschieht nach meinen Erfahrungen erst nach ca. 30-40 Sekunden. Einfluss hat man darauf nicht. Die geplugin.exe <\/b>arbeitet also in der Art eines autonomen zeitgesteuerten Services. Das Demo-Formular (siehe Bild 2) enthält zahlreiche Steuerelemente, über die auf das Plugin eingewirkt werden kann. <\/p>\n Dabei enthält die Formularklasse nur relativ wenig Code. Der größte Teil ist nämlich in die Klasse clsGEPlugin <\/b>ausgelagert, die einen Wrapper für das Steuerelement darstellt. Ein solches Klassenmodul ist empfehlenswert, weil die direkte Programmierung des Controls doch etwas aufwendig ist. Einmal erstellt, kann es in beliebige Anwendungen integriert werden und hält den restlichen benötigten Code in Grenzen.<\/p>\n In der aktuellen Ausbaustufe der Wrapper-Klasse ist nicht viel mehr als das Notwendigste implementiert. Einige umfangreichere Prozeduren verdeutlichen zusätzlich, wie über das Objektmodell in Anlehnung an das KML-Schema neue Objekte auf die Erdoberfläche gebracht werden können.<\/p>\n <\/p>\n Sie können die Klasse aber für Ihre Zwecke gern aufbohren. Anregungen dazu bietet die API-Dokumentation [3] genügend. Im Folgenden sollen einige der Prozeduren der Wrapper-Klasse näher beleuchtet werden.<\/p>\n Wrapper clsGEPlugin<\/b><\/p>\n Damit eine Instanz der Klasse mit einem GEPlugin <\/b>in einem Formular kommunizieren kann, besitzt es eine Objektreferenz in Form der Variablen objGE<\/b>. Sie ist modulweit gültig und das entscheidende Objekt der Klasse. Sie wird über die Klasseneigenschaft GEObject <\/b>gesetzt:<\/p>\n Nennt sich das Steuerelement im Formular etwa ctlGEPlugin <\/b>und die Instanz des Wrappers objGEC<\/b>, dann lautet eine Zuweisung so:<\/p>\n Damit ist freilich noch nichts gewonnen. Das zunächst schwarze Plugin füllt sich erst mit Leben, nachdem die Prozedur InitializeGE <\/b>aufgerufen wurde. Der Trick bei der Initialisierung des Steuerelements ist das Timing, mit welchem bestimmte Methoden abgesetzt und abgefragt werden. <\/p>\n Die erste benötigte Methode lautet:<\/p>\n Ohne diese Anweisung geschieht rein gar nichts. Ebenso obligatorisch ist die folgende Initialisierungsmethode objGE.SetMainDatabase<\/b>. Sie ist in Version 5 neu und gibt einige Rätsel wegen der enthaltenen Parameter auf:<\/p>\n Hier war zunächst vermutet worden, dass Google nunmehr irgendwelche Zugangsschranken eingebaut hätte, denn egal, was für die (unbekannten) Parameter eingesetzt wurde, der Methodenaufruf löste immer einen Fehler aus.<\/p>\n Tatsächlich ist aber nicht der Inhalt der Parameter dafür verantwortlich, sondern der Zustand der Engine im Hintergrund. Diese nimmt die Methode offenbar erst ab einem unklaren Zustand entgegen, dafür dann jedoch erfreulicherweise mit schnöden Leerstrings als Parameter. Der Erfolg des Aufrufs wird daher in einer Zeitschleife abgefragt.<\/p>\n Auch dann ist das Steuerelement aber noch nicht bereit. Erst, wenn die Funktion objGE.testEarthFullyInitialized_ <\/b>den Wert 0 <\/b>zurückgibt, können weitere Methoden an das Steuerelement abgesetzt werden. Versucht man das schon früher, dann wird man regelmäßig mit der Fehlermeldung Die Methode … des Objekts _GePluginCoClass schlug fehl<\/b> konfrontiert.<\/p>\n Im Anschluss setzt InitializeGE <\/b>noch einige Eigenschaften des Plugins wie etwa die Sichtbarkeit:<\/p>\n Unterbleibt dies, ist im Steuerelement nämlich ebenso nichts zu sehen. Setzen Sie später setVisibility <\/b>auf 0<\/b>, dann wird die Erdkugel wiederum ausgeblendet.<\/p>\n Es wurde erwähnt, dass das Steuerelement auch Ereignisse auslösen kann. Das geschieht jedoch nicht standardmäßig. Jedes Ereignis muss grundsätzlich erst aktiviert werden:<\/p>\n Hier wird angewiesen, dass die Erdkugel beim Überfahren mit der Maus Ereignisse ausgeben soll. Das entspricht etwa dem, was Sie auch schon von Access kennen: Ein Steuerelement erzeugt erst dann ein MouseMove<\/b>-Ereignis, wenn dessen Eigenschaft OnMouseMove <\/b>auf den String-Wert [Event Procedure] <\/b>gesetzt wurde. Ein anderes nützliches Ereignis ist dieses:<\/p>\n Das aktiviert die Fortschrittsereignisse beim Rendern der Erdoberfläche. Um den prozentualen Fortschritt zu erhalten, muss dazu allerdings noch eine Eigenschaft in der ausgelösten Ereignisprozedur abgefragt werden:<\/p>\n Übrigens zeigt sich während des gesamten Initialisierungsvorgangs optional die oben erwähnte Wartemeldung. Verantwortlich dafür ist das Formular frmMsg<\/b>, welches von der Routine anfangs geöffnet wird. <\/p>\n Nachdem InitializeGE <\/b>durchlaufen ist, sollte im Plugin-Fenster die Weltkugel erscheinen. Das Plugin ist nun bereit, um weitere Anweisungen entgegenzunehmen.<\/p>\n Anfliegen<\/b><\/p>\n Kümmern wir uns nun darum, wie man einen beliebigen Ort der Erde ansteuern kann. Die einfachste Variante besteht in der Übergabe von Breiten- und Längengrad an die Funktion GotoLoc <\/b>der Wrapper-Klasse.<\/p>\n Welcher Ausschnitt der Erde im Plugin-Fenster zu sehen ist, das bestimmt eine Kamera, welche als KmlCameraCoClass <\/b>ihre Entsprechung im Objektmodell findet. Leider kann man nicht einfach die Parameter Latitude <\/b>und Longitude <\/b>dieser Kamera einstellen. Genau genommen gibt es noch nicht mal eine öffentlich zugreifbare Kamera, sondern nur ein Kopieobjekt über das View<\/b>-Objekt des Plugins:<\/p>\n Die Eigenschaften dieses Objekts können nun gesetzt werden:<\/p>\n Da es sich bislang nur um ein Objekt im Speicher handelt, steuert das Setzen dieser Eigenschaften noch nicht die Plugin-Kamera selbst. Das muss man explizit veranlassen, indem die Kamerakopie dem Plugin zugewiesen wird:<\/p>\n Adressen finden<\/b><\/p>\n Nun werden Längen- und Breitengrad einer Adresse meist nicht bekannt sein. In der Google Earth-Standalone-Anwendung gibt es das SearchController<\/b>-Objekt, über das man aus einem Adresstext die Koordinaten eines Feature-Objekts ermitteln kann – Google Earth bedient sich dabei offenbar des gleichen Servers wie Google Maps.<\/p>\n Dieses Objekt fehlt dem Plugin leider. Suchanfragen zum Ermitteln eines Ortes müssen deshalb anderweitig gehalten werden. Zum Glück bietet Google einen freien Webservice an, der genau das übernimmt: den Google Geocoding Service <\/b>[6]. Um ihn abzufragen, braucht es nur wenige Zeilen VBA-Code, der im Wrapper-Modul in der Prozedur GetAddressCoord <\/b>untergebracht ist.<\/p>\n Der Vorgang besteht darin, an die Service-URL ein paar Parameter in Textform anzuhängen, sie abzuschicken und auf das zurückgesandte Ergebnis zu lauschen, welches die Koordinaten in wählbarem Format präsentiert. Eine komplette Anfrage sieht etwa so aus:<\/p>\n Der output<\/b>-Parameter lässt die Wahl zwischen den Formaten xml<\/b>, kml<\/b>, csv <\/b>und json <\/b>für die Rückgabe zu. Für VBA dürfte ein kommaseparierter Rückgabe-String (csv<\/b>) wegen der einfachen Weiterverarbeitung die günstigste Alternative darstellen. Zu beachten ist noch: Leer- und Sonderzeichen sind im Adressen-String nicht erlaubt oder setzen die Erkennungsgenauigkeit herab. Statt Leerzeichen sollten Plus-Zeichen (+) verwendet und Umlaute wie in HTML maskiert werden. Aus ä<\/b> wird ä<\/b>. Allerdings ist der Service meist intelligent genug, auch solche kleineren Unpässlichkeiten zu identifizieren und zu umschiffen.<\/p>\n Technisch läuft die Kommunikation mit dem Service über die MSXML-Bibliothek und ein XMLHTTP<\/b>-Objekt ab. Dafür ist nicht mal ein Verweis nötig:<\/p>\n Die Rückgabe, nun in strResult<\/b> gespeichert, besteht aus vier kommagetrennten Teilen:<\/p>\n Teil 3 und 4 entsprechen dem Breiten- und Längengrad im Double-Format. Teil 1 ist der Service-Rückgabestatus, wobei nur der Wert 200 <\/b>interessiert, welcher Gültigkeit signalisiert. Der zweite Teil muss aber ebenso beachtet werden. Er kann die Werte 0 <\/b>bis 9 <\/b>annehmen, die für verschiedene Erkennungsgenauigkeiten stehen. Die 8<\/b> im Beispiel etwa kennzeichnet Genauigkeit auf Adressebene, also inklusive Hausnummer. Eine 6<\/b> hätte bedeutet, dass zwar der Straßenname, nicht aber die Hausnummer identifiziert werden konnte. Über diesen Wert kann also im VBA-Code als Kriterium festgelegt werden, ab welcher Genauigkeit man die zurückgegebenen Koordinaten als gültig betrachten will.<\/p>\n Sind die Koordinaten nun bekannt, so können sie der oben beschriebenen Prozedur GotoLoc <\/b>übergeben werden, worauf das Plugin zum entsprechenden Erdteil schwenkt.<\/p>\n Kippen, rotieren, drehen<\/b><\/p>\n Normal zeigt das Plugin einen Ausschnitt aus der Vogelperspektive an. Damit kann man aber leider die Geländeformationen noch nicht erkennen, was ja gerade Google Earth von anderen Satellitenbildern abhebt.<\/p>\n Also muss der Winkel zur Erdoberfläche verändert werden, was komfortabel mit Maus und Tastatur geschehen kann, wenn das Plugin-Fenster den Fokus besitzt: Umschalttaste + Mausrad<\/b>.<\/p>\n Andere Tasten plus Mausrad <\/b>verändern andere Ansichtsparameter: Strg<\/b> etwa lässt die Ansicht im Sinne des Kompass drehen. Statt des Mausrads können auch die Pfeiltasten in Kombination mit Umschalt <\/b>und Strg <\/b>verwendet werden.<\/p>\n Selbstverständlich lässt sich das auch über VBA steuern. Im Wrapper lautet die passende Prozedur dazu SetViewMode<\/b>. ähnlich wie im Code oben zu GotoLoc<\/b> wird hier eine Kopie der Standardkamera erhalten, modifiziert und wieder zugewiesen. Nur werden nun nicht die Eigenschaften Latitude<\/b>, Longitude <\/b>oder Altitude <\/b>gesetzt, sondern Tilt <\/b>(Kippen), Roll <\/b>(Drehen) und Heading <\/b>(Horizontale Neigung):<\/p>\n Das in Bild 3 dargestellte Demoformular frmGEPlugin <\/b>steuert diese Parameter über Schaltflächen, deren Eigenschaft Makro wiederholen <\/b>auf Ja <\/b>eingestellt ist. Damit wird der Ereigniscode OnClick <\/b>endlos wiederholt, solange Sie die Schaltflächen gedrückt halten, was im Falle der Drehen-Schaltfläche etwa zu fortgesetztem Rotieren um den Ort im Mittelpunkt der Kamera führt.<\/p>\n Bild 3: Das Erscheinungsbild des GE-Plugins im Demoformular kann per Code gesteuert werden.<\/span><\/b><\/p>\n Layer steuern<\/b><\/p>\n Über Checkboxen des Formulars frmGEPlugin <\/b>können bestimmte Features im Plugin ein- oder ausgeblendet werden (siehe Bild 3). Ist etwa Straßen<\/b> aktiviert, dann rendert das Plugin die Linienzüge für Straßen und deren Bezeichnungen, ist Grenzen, Gebiete, Namen<\/b> gesetzt, dann werden Ortsnamen und Grenzlinien sichtbar. Diese Elemente werden nicht direkt auf die Erdoberfläche gezeichnet, sondern als transparente Layerschichten darüber. Jeder Layer hat einen anderen Namen oder eine andere ID. <\/p>\n Straßen können Sie per Code so einblenden:<\/p>\n Als ID <\/b>für den Straßen-Layer wird hier objGE.LAYER_ROADS <\/b>übergeben und mit 1 <\/b>aktiviert; eine 0 <\/b>würde die Straßen wieder ausblenden. In diesem Fall bietet das Plugin, quasi als Service, eine Funktion an, welche die ID <\/b>zurückgibt. Dieser String lautet in Wirklichkeit so:<\/p>\n Anders sieht es für jene Layer aus, für die es keine Funktion gibt. Ortsnamen erscheinen etwa dann, wenn als Layer-ID die GUID 54a2ff5a-c7b3-11dc-bdad-dd553d8c9902<\/b> übergeben wird.<\/p>\n Leider gibt es keine Auflistung aller Layer und der zugehörigen GUIDs. Deshalb wurde in die Wrapperklasse die Prozedur EnumFeatures <\/b>aufgenommen, welche alle augenblicklich existierenden Features des Plugins ausgeben und in einer Textdatei speichern kann. Dabei ist zwischen zwei Grundebenen zu unterscheiden: objGE.getLayerRoot <\/b>gibt alle Features von Layern zurück, während objGE.getFeatures <\/b>die Auflistung aller benutzerdefiniert erstellten Objekte enthält – etwa Ortsmarken, wie später noch erläutert wird. Der Textdatei können Sie dann entnehmen, welchem benannten Layer welche GUID zugeordnet ist.<\/p>\n Die Liste ist übrigens hierarchisch. Unter Roads <\/b>finden sich Untereinträge etwa für TeleAtlas Thailand Roads<\/b> mit der entsprechenden ID<\/b>. Über diese könnten Sie dann zum Beispiel die Straßenansicht für Thailand separat steuern. Es spielt keine Rolle, an welcher Stelle der Hierarchie sich der Layer befindet. Die an enableLayerById <\/b>übergebene GUID <\/b>ist einzig für die Identifikation verantwortlich.<\/p>\n Objekte bauen<\/b><\/b><\/p>\n Bisher wurden einige Grundfunktionen besprochen, über die das Plugin verfügt, die weitgehend auch per Automation der Standalone-Version zu erreichen sind. Ein großer Vorzug des Plugins aber ist die objektorientierte Weise, in der interaktive Objekte auf der Erdoberfläche erzeugt werden können. In der Wrapperklasse sind – lediglich als Beispiele – Routinen enthalten, um Ortsmarken, Polygone und Diagramme zu kreieren. Der Fantasie sind hier keine Grenzen gesetzt, und wenn man einen Blick in die KML-Referenz riskiert, wird man gewahr, welche komplexen weiteren Gestaltungsmöglichkeiten sich hier offenbaren. Die Wrapperklasse hat in dieser Richtung am meisten Ausbaupotenzial. Denkbar sind etwa noch HTML-Links, Balloons (Sprechblasen), Bilder, die auf oder über der Erdoberfläche liegen, 3D-Modelle und vieles mehr.<\/p>\n Ausgangspunkte für all diese Objekte sind jene Methoden der GEPluginCoClass<\/b>, die mit create… <\/b>beginnen. Inspizieren Sie hierzu einfach den VBA-Objektkatalog (F2). Da eine komplette Beschreibung des teilweise doch recht komplexen Codes den Rahmen dieses Beitrags sprengen würde, sollen hier nur zwei Objekte in Ausschnitten erläutert werden: Ortsmarken und Diagramme. Wie andere Objekte – im Earth-Sprachgebrauch Features – erstellt werden, das ergibt sich übrigens aus den Beispielen, die Google auf der API-Webseite bereitgestellt hat. Die dort angeführten JavaScript-Codes lassen sich fast 1:1 in VBA übersetzen.<\/p>\n Ortsmarken setzen<\/b><\/p>\n Ortsmarken sind nicht nur jene Labels mit dem birnenförmigen Symbol, das Sie vielleicht schon aus Google-Maps kennen. Fast alle Objekte und selbst Linien benötigen einen Container, der sie beherbergt, und das sind die Ortsmarken oder Placemarks<\/b>. Den Anfang beim Erstellen eines grafischen Objekts auf der Erdoberfläche macht also immer ein Placemark<\/b>:<\/p>\n Der Parameter NameID <\/b>ist optional und kann auch durch einen Leerstring ersetzt werden. Dann aber ist das Objekt später nicht mehr identifizierbar. Solange Sie das erstellte Objekt unberührt lassen möchten, ist das tatsächlich ohne Belang. Sobald aber ein Objekt wieder per Code gelöscht werden soll oder man ein Klickereignis auf eine Ortsmarke zuordnen möchte, wird ein eindeutiges Identifizierungsmerkmal benötigt. Dass diese übergebene ID tatsächlich eindeutig ist, erkennen Sie daran, dass ein Fehler ausgelöst wird, wenn Sie ein Objekt mehr als einmal mit der gleichen Kennzeichnung anzulegen versuchen. Machen Sie den Test und erzeugen Sie im Formular frmGEPlugin <\/b>oder frmKunden <\/b>zum gleichen Datensatz wiederholt einen Marker über die entsprechende Schaltfläche. Es wird nur einmal klappen und dann nur noch Fehlermeldungen auslösen, weil die referentielle Integrität verletzt wurde.<\/p>\n Übrigens kann nicht nur der Methode createPlacemark <\/b>eine ID <\/b>übergeben werden, sondern grundsätzlich allen per create…<\/b>-Methode erzeugten Objekten, wie Punkten, Linien, Icons und sogar Style<\/b>-Eigenschaften. Brauchen wird man das allerdings in den seltensten Fällen.<\/p>\n Zurück zum Placemark<\/b>. Eigentlich ist das ein abstraktes Objekt, das noch keinen Inhalt hat. Man kann es zwar an Koordinaten setzen, es weiß aber noch nicht, was es anzeigen soll, und erscheint darum transparent. Das ändert sich aber bereits, wenn Sie ihm einen Text verpassen, was über die Methode setName <\/b>geschieht:<\/p>\n Die Beschreibung erschiene nun als Label auf der Erde. Es fehlt dazu allerdings noch ein Vorgang. Das Placemark <\/b>muss erst an die Liste der Google Earth-Features angehängt werden. Das entspricht etwa dem Hinzufügen zur Liste Meine Orte<\/b> der Standalone-Anwendung. Die Features-Auflistung erhält man im Objektmodell über die getFeatures<\/b>-Methode des Plugins:<\/p>\n Leider reichen auch diese vier Zeilen Code noch nicht aus, um die Ortsmarke tatsächlich einzublenden. Denn das Placemark<\/b>-Objekt kennt keine Eigenschaften wie Latitude <\/b>und Longitude<\/b>, die ihm sagen würden, wo genau auf der Erdoberfläche es zu erscheinen hat. Darum kommt hier ein Hilfsobjekt ins Spiel, das Koordinaten aufnehmen kann: ein KmlPointCoClass<\/b>, mithin ein Punkt. Das erzeugt man zunächst über die passende create…<\/b>-Methode, setzt die Koordinaten und weist es anschließend dem Placemark <\/b>über dessen getGeometry<\/b>-Methode zu:<\/p>\n Nun endlich erscheint die Ortsmarke im Plugin-Fenster. Vielleicht irritiert es Sie, dass sie als Symbol ein blaues Rechteck mit Kreuzchen anzeigt. Das ist das Vorgabesymbol, wenn kein anderes Icon spezifiziert wurde. Aber das lässt sich leicht ändern. Wie so oft im GE-Objektmodell gibt es hierfür jedoch keine Icon-Eigenschaft, die man setzen könnte, sondern es muss erst ein Icon-Objekt erstellt und der Ortsmarke zugewiesen werden:<\/p>\n IconURL <\/b>ist der Pfad zur Bilddatei, die vorzugsweise im png<\/b>-Format daherkommen sollte, weil dieses Transparenz unterstützt. Nun wird es interessant: Was ist unter Pfad zu verstehen Das Plugin kommuniziert ja nur über Internet mit dem Datenserver. Der Versuch, etwa einen Pfad zu übergeben wie c:\\eigene dateien\\bilder\\icon.png<\/b>, schlägt folgerichtig fehl, was sich schlicht in einem transparenten Symbol manifestiert. Haben Sie eine Bilddatei hingegen auf Ihren Webserver hochgeladen, dann lässt sich diese URL problemlos verwenden:<\/p>\n „Das ist ja uncool!“, werden Sie denken, denn erst alle möglichen Bilddateien auf einen Webserver hochzuladen, ist sicher keine besonders einfallsreiche Lösung. Es gibt glücklicherweise einen Ausweg. Wenn Sie sich die Unterverzeichnisse der Plugin-Installation näher ansehen, dann werden Sie einen Zweig \\res <\/b>entdecken, der wieder Unterverzeichnisse wie \\paddle<\/b>, \\pushpin <\/b>oder \\shapes <\/b>enthält. Darin befinden sich .png<\/b>-Dateien. Wofür sollte das Plugin die brauchen, wenn nicht für seine Ortsmarken Und richtig, der Versuch, ein solches Verzeichnis anzugeben, führt zum Erfolg:<\/p>\n Sie können ebenso gut ein neues Unterverzeichnis unter \\res <\/b>anlegen und dort benutzerdefinierte .png<\/b>-Dateien speichern. Auf diese Weise können beliebige Grafiken im Plugin angezeigt werden.<\/p>\n Da die Abmessungen nicht limitiert sind und etwa auch Bilder der Auflösung 300 x 300 Pixel möglich sind, eröffnet das ganz neue Möglichkeiten. Im späteren Absatz zu Diagrammen wird von dieser Technik Gebrauch gemacht.<\/p>\n Zurück zum Icon<\/b>-Objekt, das nun erstellt, aber noch nicht dem Placemark <\/b>zugeordnet wurde. Das geht auch nicht direkt, weil das Placemark<\/b>-Objekt keine entsprechende Methode aufweist. Leider ist das Objektmodell an dieser Stelle weit verschachtelt und es müssen glatt noch zwei Zwischenobjekte her, die das Icon aufnehmen können: das KmlStyleCoClass<\/b>– und das KmlStyleMapCoClass<\/b>-Objekt.<\/p>\n Dem Style<\/b>-Objekt wird das Icon zugewiesen, das Style<\/b>-Objekt dem Stylemap<\/b>-Objekt und dieses schließlich dem Placemark<\/b>-Objekt. Warum so kompliziert<\/p>\n Der Grund liegt darin, dass diese beiden Zwischenobjekte noch viele weitere Eigenschaften haben, über die man das Aussehen des Icons steuern kann – etwa die Größe (setScale<\/b>), aber auch ausgefallenere Eigenschaften wie seinen Winkel zur Erdoberfläche. Ziehen Sie hier auch die API-Dokumentation zurate.<\/p>\n Das Stylemap<\/b>-Objekt wiederum kann zwei unterschiedliche Styles mit unterschiedlichen Icons und Eigenschaften aufnehmen. Der eine für das normale Aussehen, der andere für den Highlight<\/b>-State, der eintritt, wenn die Ortsmarke mit der Maus überfahren, also quasi aktiviert wird. Im Beispiel wurde aber über die setStyle<\/b>-Methode beiden Zuständen der gleiche Style <\/b>zugewiesen.<\/p>\n Abschließend nochmals der Hinweis, dass Sie all diese Programmierwege keineswegs über Experimente und den Objektkatalog herausbekommen müssen. Aus dem Google Earth-API [3] und Beispielen geht alles Notwendige hervor.<\/p>\n Diagramm erzeugen<\/b><\/p>\n Wie wäre es, wenn Sie im Google Earth-Plugin für verschiedene Orte Diagramme anzeigen könnten, die etwa die Umsätze der ansässigen Kunden verdeutlichen<\/p>\n Wie das zu realisieren ist, können Sie sich möglicherweise nach den Ausführungen zum Placemark<\/b>-Objekt und dessen Icon denken. Es wird nur eine Grafikdatei mit dem Diagramm benötigt, die der Ortsmarke zugewiesen werden muss. Als Demonstration enthält die Wrapperklasse dazu die Prozedur CreateChart<\/b>.<\/p>\n Wie, um alles in der Welt, kann aber Access ein solches Diagramm als Bilddatei erzeugen Gar nicht, würde ich sagen, falls Sie nicht schweres API-Geschütz auffahren wollen. <\/p>\n Doch Google wäre nicht Google, hielte es nicht auch für diesen Zweck ein passendes API bereit. Der freie Chart-Webservice [5] erstellt mit wenigen Parameterangaben eine solche .png<\/b>-Diagrammgrafik. Sie haben die Wahl unter verschiedensten Diagrammtypen und Erscheinungsbildern.<\/p>\n ähnlich wie beim besprochenen Geocoding-Service werden die Steuerparameter inklusive der Daten als Strings an die Service-URL angehängt. Auch hier kommt MSXML als Kommunikationsschnittstelle zum Einsatz, jedoch in erweiterter Form, weil die Rückgabe nicht als String erfolgt, sondern als Dateistream-Objekt. Um aus diesem Stream eine Bilddatei zu machen, kommt man um eine weitere Bibliothek nicht herum. In der Beispieldatenbank findet sich das Modul mdlGDIPlus<\/b>, welches von der gdiplus<\/b>-Bibliothek von Windows XP oder Vista Gebrauch macht. Die Prozedur SaveStreamToPNG <\/b>des Moduls verwandelt den http<\/b>-Stream in eine .png<\/b>-Datei:<\/p>\n Der Pfad für die Bilddatei wird dabei wie folgt zusammengesetzt. Zuerst wird der Ort der Plugin-Installation über die Wrapper-eigene Funktion GEPluginPath <\/b>ermittelt.<\/p>\n Daran wird das Ressourcenverzeichnis res\\user <\/b>angehängt. Das Plugin kann nur auf Verzeichnisse unterhalb des \\res<\/b>-Zweigs zugreifen. Das \\user<\/b>-Unterverzeichnis wurde von der Wrapperklasse schon beim Initialisieren automatisch angelegt. Als Dateiname wird die ID <\/b>der Ortsmarke, welche das Diagramm identifizieren soll, übergeben. Damit haben wir alles beisammen, um im weiteren Schritt eine Ortsmarke anzulegen und ihr als Icon das soeben erstellte Diagrammbild zuzuweisen:<\/p>\n Wie das im Ergebnis aussieht, können Sie in Bild 4 begutachten.<\/p>\n Bild 4: Umsatz-Tortendiagramm als Ortsmarke im Google Earth-Steuerelement<\/span><\/b><\/p>\n Kundenformular, Version II<\/b><\/p>\n Das hier gezeigte Diagramm, das über die Schaltfläche Umsatz-Chart <\/b>des Kundenformulars (siehe Bild 5) zustande kam, hat nur begrenzte Aussagekraft.<\/p>\n Bild 5: Das Kundenformular im neuen Gewand und mit neuen Möglichkeiten<\/span><\/b><\/p>\n Mit etwas mehr Gestaltung, was zusätzliche Parameter für den Chart-Service voraussetzt, kann man aber durchaus komplexe Grafiken erzeugen.<\/p>\n Die Daten für das Diagramm kommen übrigens aus einer Abfrage analog der qry_UmsatzJahr <\/b>der Datenbank. Wie die Daten aus dieser Abfrage via Recordset in die Repräsentation für den Chart-Service überführt werden, erfahren Sie in der Prozedur cmdChart_Click <\/b>des Formulars.<\/p>\n Wenn Sie rein zufällig auf das Diagramm im Plugin klicken, dann verschwindet es wieder. Das ist nicht etwa sein Standardverhalten, sondern zum Spaß so in die Formularklasse einprogrammiert und demonstriert, wie Sie mit Events umgehen können.<\/p>\n Ausgelöst wird das Ereignis von der Wrapperklasse, die das Ereignis PlacemarkEvent <\/b>bereitstellt:<\/p>\n Das Ereignis übergibt als Parameter jenen Identifikator in NameID<\/b>, den Sie beim Erstellen der Diagramm-Ortsmarke verwendet haben. Hier wird deutlich, warum die Vergabe einer eindeutigen ID <\/b>wichtig ist. Sie können nun ermitteln, auf welches Objekt geklickt wurde. Im Folgenden wird dann die Prozedur RemoveFeature <\/b>der Wrapperklasse aufgerufen, die das Objekt mit der entsprechenden ID <\/b>wieder löscht.<\/p>\n Dafür, also zum Löschen eines Feature-Elements, gibt es im Objektmodell keine einfache Methode. Die einzig dargebotene Löschmethode ist diese:<\/p>\n Für obj <\/b>ist dabei direkt etwa ein Placemark<\/b>-Objekt zu übergeben. Nur gibt es leider keine Funktion, die über die ID eines Objekts dieses selbst zurückgeben würde, also etwas ähnliches wie im HTML-DOM-Modell die Methode GetElementByID<\/b>. Stattdessen müssen in einer Schleife alle Feature-Objekte des Plugins durchlaufen und ihre Namen mit NameID <\/b>verglichen werden, bis es zur Übereinstimmung kommt. Dafür ist die Hilfsroutine GetObjectByID<\/b> des Wrappers zuständig.<\/p>\n Damit das Kundenformular die gleichen Möglichkeiten bietet, wie jenes aus dem oben erwähnten Beitrag, musste natürlich auch die Screenshot<\/b>-Funktion eingebaut werden. Über die Schaltfläche Schnappschussfoto <\/b>wird ein Abbild des Plugins erzeugt und wahlweise in einer Bilddatei gespeichert. Dazu wird die Funktion GetPicture <\/b>der Wrapperklasse aufgerufen. Man muss ihr als Parameter eine Referenz auf das Formular übergeben, welches das Plugin enthält. Grund dafür ist, dass das Plugin keine Funktion für das Fenster-Handle bereitstellt, sodass Sie in der etwas umständlichen Hilfsroutine GetPluginWindow <\/b>erst durch API-Enumeration der Kindfenster des Formulars zum ActiveX-Fenster gelangen. Ohne Fenster-Handle des Steuerelements kein Screenshot!<\/p>\n Zusammenfassung und Ausblick<\/b><\/p>\n Wenn Sie Lösungen analog der bereitgestellten Demo für Ihre Anwendung vorsehen möchten, dann sind aus der Beispieldatenbank folgende Elemente zu importieren:<\/p>\n Die Klasse clsGEPlugin<\/b>, die Module mdlGDIPlus<\/b>, mdlTools <\/b>und das Formular frmMsg<\/b>. Optional kann auch das Startformular frmStart <\/b>integriert werden. Ein Verweis auf die GEPlugin Type Library <\/b>muss zudem gesetzt werden.<\/p>\n Eine Garantie, dass der Code der Elemente ewig funktionieren wird, kann nicht gegeben werden. Möglicherweise erfährt das Objektmodell in zukünftigen Versionen des Plugins weitere änderungen, so wie dies vor einigen Wochen mit dem Update von Version 4 auf 5 geschah. In den KML<\/b>-Foren von Google wird bereits ähnliches von zuständigen Entwicklern angedroht. Das gilt ebenso für die bisher freien Google-Services GeoCoding<\/b>– und Chart-API<\/b>. Wir versuchen, Sie auf dem Laufenden zu halten, falls sich hier Abweichungen einschleichen.<\/p>\n Literaturhinweise<\/p>\n [1] Download des Plugins: http:\/\/earth-api-samples.googlecode.com\/svn\/trunk\/demos\/helloearth\/index.html<\/p>\n [2] Lizenzbestimmungen zum Plugin: http:\/\/code.google.com\/intl\/de\/apis\/maps\/terms.html<\/p>\n [3] Google Earth-API: http:\/\/code.google.com\/intl\/de\/apis\/earth\/documentation\/reference\/index.html<\/p>\n [4] KML-Referenz: http:\/\/code.google.com\/intl\/de\/apis\/kml\/documentation\/kmlreference.html<\/p>\n [5] Chart-API: http:\/\/code.google.com\/intl\/de\/apis\/chart\/basics.html<\/p>\n [6] Geocoding-API: http:\/\/code.google.com\/intl\/de\/apis\/maps\/documentation\/services.html#Geocoding_Direct<\/p>\n Enthaltene Beispieldateien:<\/p>\n GoogleEarther5c.mdb<\/p>\nDim objGE As Object\r\nSet objGE = µ\r\nCreateObject("GEPluginCoClass.GEPluginCoClass")<\/pre>\nstrVersion = objGE.getPluginVersion\r\nIf Val(strVersion) < 5 Then...<\/pre>\n
![\"frmDemo1.png\"](\"..\/fileadmin\/_temp_\/2009_03\/GoogleEarth2-web-images\/frmDemo1_opt.jpeg\")
<\/p>\nProperty Set GEObject(obj As GEPluginCoClass)\r\nSet objGE = obj\r\nEnd Property<\/pre>\n
Set objGEC.GEObject = Me!ctlGEPlugin.Object<\/pre>\n
objGE.start_("")<\/pre>\nSub setMainDatabase_(mainDatabaseURL As String, µ\r\n userName As String, password As String)<\/pre>\n
objGE.GetWindow.setVisibility 1<\/pre>\n
objGE.getGlobe.onMousemoveEventEnabled 1<\/pre>\n
objGE.onFrameendEventEnabled 1<\/pre>\n
Debug.Print objGE.getStreamingPercent<\/pre>\n
Dim objCam As KmlCameraCoClass\r\n Set objCam = objGE.getView.copyAsCamera(1)<\/pre>\n
objCam.setLatitude <Breitengrad, Double>\r\n objCam.setLongitude <Längengrad, Double>\r\n objCam.setAltitude <Höhe über Erdboden, Double><\/pre>\n
objGE.getView.setAbstractView objCam<\/pre>\n
http:\/\/maps.google.de\/maps\/geoq= Bundesallee+89,12161+Berlin,+Germany &output=csv<\/pre>\n
strRequest = "http:\/\/maps.google.de\/maps\/geoq... "\r\n Set oHTTP = CreateObject("MSXML2.XMLHTTP")\r\n oHTTP.Open "GET", strRequest, False\r\n oHTTP.send\r\n If oHTTP.status = 200 Then strResult = µ\r\n oHTTP.responseText<\/pre>\n 200, 8, 50.5421799, 7.2519273<\/pre>\n
objCam.setTilt <Kippwinkel in Grad>\r\n objCam.setRoll <Drehwinkel in Grad>\r\n objCam.setHeadingt <Neigung in Grad><\/pre>\n
![\"frmDemo2.png\"](\"..\/fileadmin\/_temp_\/2009_03\/GoogleEarth2-web-images\/frmDemo2_opt.jpeg\")
<\/p>\n objGE.getLayerRoot.enableLayerById(objGE.LAYER_µ\r\n ROADS , 1)<\/pre>\n
4ddec456-c7b3-11dc-aaa5-dd553d8c9902<\/pre>\n
Dim objPlacemark As KmlPlacemarkCoClass\r\n Set objPlacemark = objGE.CreatePlacemark(NameID)<\/pre>\n
objPlacemark.setName Description <Beschreibung><\/pre>\n
objGE.getFeatures.appendChild objPlacemark<\/pre>\n
Dim objPT As KmlPointCoClass\r\n Set objPT = objGE.createPoint("")\r\n objPT .setLongitude <Double-Wert>\r\n objPT .setLatitude <Double-Wert>\r\n objPlacemark.setGeometry objPT<\/pre>\n Dim objIcon As KmlIconCoClass\r\n Set objIcon = objGE.createIcon("")\r\n objIcon.setHref <IconURL><\/pre>\n objIcon.setHref µ\r\n "http:\/\/www.moss-soft.de\/public\/red24.png"<\/pre>\n
objIcon.setHref "paddle\/7.png"<\/pre>\n
Dim objStyle As KmlStyleCoClass\r\n Dim objStylemap As KmlStyleMapCoClass\r\n Set objStyle = objGE.createStyle("")\r\n Set objStylemap = objGE.createStyleMap("")\r\n objStyle.getIconStyle.setIcon oIcon\r\n objStylemap .setStyle objStyle, objStyle\r\n objPlacemark.setStyleSelector objStylemap<\/pre>\n SaveStreamToPNG oHTTP.responseStream, µ\r\n GEPluginPath & "res\\user\\" & NameID & ".png")<\/pre>\n
CreatePlacemark NameID, Lat, Lon, µ\r\n Title, "user\\" & NameID & ".png"<\/pre>\n
![\"diagram.png\"](\"..\/fileadmin\/_temp_\/2009_03\/GoogleEarth2-web-images\/diagram_opt.jpeg\")
<\/p>\n![\"frmKunden.png\"](\"..\/fileadmin\/_temp_\/2009_03\/GoogleEarth2-web-images\/frmKunden_opt.jpeg\")
<\/p>\n Private Sub objGEC_PlacemarkEvent(ByVal NameID µ\r\n As String, ByVal EventName As String)\r\n Debug.Print µ\r\n "Placemark '" & NameID & "' > " & EventName\r\n objGEC.RemoveFeature NameID\r\n End Sub<\/pre>\n
objGE.getFeatures.removeChild obj<\/pre>\n
Downloads zu diesem Beitrag<\/h3>\n