GIS, UNIGIS und andere Kleinigkeiten

In der Aufgabe 7-1 des dritten UNIGIS-Moduls geht es ums Digitalisieren. Meine Digitalisier-Erfahrung beschränkte sich bisher auf ein Forschungspraktikum an der Uni, in dem ich mit ArcView 3.1 Waldflächen von der Pixelkarte 1:25'000 digitalisieren musste. Schon damals fand ich diese Arbeit schrecklich und musste mich gehörig zusammenreissen. Digitalisieren ist wahrscheinlich die mühsamste GIS-Tätigkeit, die ich bis jetzt kennengelernt habe; eine Arbeit, die viel Präzision und Ausdauer erfordert.
Bei dieser Aufgabe ging es darum, von einem Luftbild verschiedene Landnutzungskategorien (Acker, Wald, Gebäude etc.) zu erfassen und anschliessend eine Flächenbilanz zu erstellen. Da ich keine Lust hatte, die Editier-Tutorials von Geomedia abzuarbeiten, stürzte ich mich direkt ins Abenteuer. Anfangs musste mein Monitor den einen oder anderen Fluch ertragen. Als ich allerdings die ziemlich umfangreichen Editiermöglichkeiten von Geomedia einmal einigermassen im Griff hatte, ging das ganze doch recht flüssig vonstatten. Diese Tools sind ziemlich intelligent und ersparen einem so manchen Klick. Schlussendlich habe ich die Landnutzung dann doch noch erfasst und damit die Aufgabe abgeschlossen, aber ich hoffe wirklich, dass ich in Zukunft so wenig wie möglich mit Digitalisieren zu tun habe!

Im Abschnitt "Extending ArcObjects" der ArcObjects Documentation Library gibt es ein Beispiel, wie man eine ArcCatalog-Ansicht im ArcMap-TOC implementiert (Kapitel 4: "Creating Cartography" => "CatalogView Example"). Das Beispiel ist gut dokumentiert und der Quellcode liegt in VB und C++ vor. Nun schien mir dieses Beispiel eine sehr nützliche Erweiterung zu sein. Also habe ich es in C# und .NET nachgebaut. Das ganze funktioniert problemlos:



Das Beispiel ist sehr einfach und besteht nur aus zwei Klassen: gxApplication (implementiert das IGxApplication-Interface) und CatalogView (implementiert das IContentsView-Interface und wird in der Kategorie "ESRI Contents Views" registriert). Der Quellcode ist in zwei Files abgelegt: gxApplication.cs und CatalogView.cs.

Wegen diverser Einschränkungen auf dem GIS-Terminalserver an meinem Arbeitsplatz, kann ich mit ArcObjects entwickelte .NET-Komponenten nicht automatisch im COM-System registrieren und damit für ArcGIS zugänglich machen. Dasselbe gilt natürlich auch für selber entwickelte COM-Objekte, auch die können nicht registriert werden. Die Registrierung von .NET-Komponenten im COM-System läuft unter dem Stichwort "COM to .NET Interoperability". Grob gesagt müssen dazu folgende Schritte ausgeführt werden:

1) Jeder Klasse in der DLL, die für das COM-System sichtbar sein soll, muss im Code eine eindeutige ID, die sogenannte GUID, zugewiesen werden. Die GUID kann mit dem GUID-Tool erzeugt werden. Das GUID-Tool ist Teil der ArcGIS-Installation und wahrscheinlich auch in der Visual Studio-IDE enthalten. Die Zuordnung erfolgt im Code mit folgenden Anweisungen:

	[ClassInterface(ClassInterfaceType.None)]

	[Guid("7CF958B9-0F0C-4CFF-B8C8-0DC6528071FA")]

	public class BerechneLaenge: ICommand

2) Um dem COM-System die neue DLL bekanntzumachen, müssen verschiedene Einträge in der Windows-Registry vorgenommen werden. Der eigentlich dafür vorgesehene Teilschlüssel der Registry (HKEY_CLASSES_ROOT) ist auf dem GIS-Server schreibgeschützt. Stattdessen muss die Registrierung im Teilschlüssel HKEY_CURRENT_USER\Software\Classes vorgenommen werden. Das heisst aber auch, dass die DLL dann nur für den Benutzer verfügbar ist, der die Registrierung vorgenommen hat. Wenn ein anderer Benutzer die DLL auch benutzen will, muss er sie ebenfalls noch registrieren.

3) Die Registrierung geschieht mit einem Registry-File, in dem alle notwendigen Einträge zusammengefasst sind. Die Erstellung des Grundgerüsts für dieses Registry-File geschieht mit Regasm.exe. Regasm steht für "Register Assembly" und ist Teil des .NET-Frameworks:

	RegAsm.exe /codebase /reg:MyRegFile.reg MyDLL.dll

4) Im so entstandenen Registry-File muss jedes Auftreten von "HKEY_CLASSES_ROOT" mit "HKEY_CURRENT_USER\Software\Classes" ersetzt werden (Suchen/Ersetzen in einem Editor).

5) Der Pfad in jedem Codebase-Wert muss auf das Verzeichnis gesetzt werden, in dem die DLL liegt und in dem sie später auch ausgeführt wird.

6) Jedes ITool, ICommand oder andere ArcObjects-Interface, das in ArcGIS verwendet werden soll, muss in einer oder mehreren sogenannten "Command Category" registriert werden. Einen Überblick über alle auf dem jeweiligen System vorhandenen Categories zeigt der OLEViewer oder der "Component Category Manager" (ist Teil der ArcGIS-Installation). Z.B. sind alle ArcMap-Commands in der Kategorie "ESRI Mx Commands", alle ArcMap-Toolbars in der Kategorie "ESRI Mx CommandBars", alle ArcMap-Extensions in der Kategorie "ESRI Mx Extensions" etc. ESRI hat dazu eine Übersicht über alle Commands, Menus und Toolbars in ArcMap und deren Kategorien und GUIDs zusammengestellt. Jede Kategorie weist wiederum eine eindeutige GUID auf, die aus der erwähnten Übersicht oder via den OLEViewer ermittelt werden kann. Der Registry-Schlüssel für die Category-Registrierung sieht etwa so aus (alle drei Zeilen gehören auf eine):

[HKEY_CURRENT_USER\Software\Classes\
CLSID\{Klassen-GUID}\
Implemented Categories\{Kategorien-GUID}]

Die erste GUID ist diejenige der betroffenen Klasse (Command, Toolbar etc.), die zweite GUID diejenige der Kategorie, in dem die Klasse registriert werden soll. Mit dem oben erwähnten Regasm-Befehl wird gleichzeitig auch für jede Klasse ein Registry-Schlüssel angelegt, der die Klasse in der Kategorie ".NET Category" registriert. Dies muss also nicht mehr manuell erledigt werden.

7) COM braucht allerdings noch weitere Infos über eine DLL, damit alles klappt. Diese Informationen werden in einer Type Library gespeichert. Die "Type Library" kann mit dem Programm TypeLibraryExporter.exe erzeugt werden, welches Teil des Buches "COM and .NET Interoperability" ist. Der Sourcecode kann auf der Buch-Homepage heruntergeladen werden. Das Programm kann einfach kompiliert und ausgeführt werden. Anschliessend müssen nur noch Pfad und Dateiname der DLL eingegeben und die Frage nach der Registrierung für COM mit Nein beantwortet werden. Danach wird das TLB-File erzeugt. Dieses gehört dann in das gleiche Verzeichnis wie die DLL.

8) Die Type Library selbst muss auch noch in der Registry registriert werden. Die Vorlage dazu:

[HKEY_CURRENT_USER\Software\Classes\TypeLib\{TLB-GUID}]

[HKEY_CURRENT_USER\Software\Classes\TypeLib\{TLB-GUID}\1.0]

[HKEY_CURRENT_USER\Software\Classes\TypeLib\{TLB-GUID}\1.0\0]

[HKEY_CURRENT_USER\Software\Classes\TypeLib\{TLB-GUID}\1.0\0\win32]
@="E:\\Pfad\\zur\\TLB.tbl"

[HKEY_CURRENT_USER\Software\Classes\TypeLib\{TLB-GUID}\1.0\FLAGS] 
@="0"

TLB-GUID steht für die GUID der TLB (im OLEViewer unter File\View TypeLib auffindbar) und die Versionsnummern (1.0 etc.) sollten mit denjenigen Versionsnummern übereinstimmen, die man der DLL in der IDE zuweist.

9) Das durch diese Schritte entstandene Registry-File muss nun nur noch ausgeführt werden und dann ist die DLL im COM-System registriert.

10) Die Überprüfung, ob alles geklappt hat, kann auf folgende Arten vorgenommen werden:

• Mit regedit nachschauen, ob alle relevanten Einträge in der Registry auch wirklich vorgenommen wurden.
• Im OLEViewer nachschauen, ob alle Klassen in den richtigen Kategorien auftauchen.
• In ArcGIS kontrollieren, ob die Komponenten an den richtigen Orten auftauchen.

Diese Vorgehensweise ist sicherlich nicht gerade unkompliziert oder elegant, aber sie in der aktuellen Konfiguration doch die simpelste Lösung!

Nützliche Tools:

• OLE Viewer: ein sehr nützliches Werkzeug zur Betrachtung des COM-Systems.
• GUID-Tool: erzeugt eindeutige GUID (Teil der ArcGIS-Installation oder in Visual Studio enthalten).
• Ildasm: zeigt den Inhalt von .NET Assemblies an.
• .NET Reflector: bietet eine ganze Reihe von Betrachtungs- und Analysefunktionen für das .NET-Framework.
• SharpDevelop: eine Open Source-IDE für das .NET-Framework. SharpDevelop wurde selber auf dem .NET-Framework implementiert.

Nützliche Dokumentationen:

• COM and .NET Interoperability: Dieses Buch deckt so ziemlich jeden Aspekt des Themas ab. Zudem ist das Buch kostenlos verfügbar!
• ESRI Developer Network: EDN enthält etliche Ressourcen zum Thema ArcObjects und .NET.
• MSDN: Microsofts Dokumentation des Themas.

Teil des UNIGIS-Curriculums ist ja bekannterweise auch die Teilnahme an einer Summer School. Ich muss gestehen, dass ich beim Durchsehen der UNIGIS-Informationen vor der Anmeldung diesen Punkt des Studienganges überlesen habe. Daher war ich bei den einführenden Studientagen etwas überrascht, von einer Summer School zu hören. Der Begriff Summer School ist mir bisher das eine oder andere Mal beiläufig begegnet, ich habe mich aber bis zu UNIGIS noch nie damit beschäftigt. Allerdings ist die Aussicht, sich eine Woche lang mit anderen GIS-Interessierten zu treffen und zu arbeiten, sehr interessant. Bis jetzt habe ich mich allerdings nur sehr sporadisch um das Thema gekümmert und mir mal zwei Summer Schools notiert: zum einen die Vespucci Summer School und die Summer School der englischen Society of Cartographers. Der Vespucci-Anlass ist auf jeden Fall anrechenbar, beim anderen müsste ich das zuerst noch abklären. Es gibt auf jeden Fall noch viele weitere Summer Schools, aber -- wie gesagt -- ich habe auch noch nicht richtig danach gesucht. Brennend interessieren würde mich auch die XML Summer School in Oxford, allerdings ist da der geforderte GIS- und Geoinformationsbezug kaum herzustellen.

Was mich erstaunt hat, ist die Tatsache, dass so eine Summer School nur sehr wenig anrechenbare Leistung bringt. Im Curriculum ist für die Summer School ein Umfang von 6 ECTS-Punkten vorgegeben. Die Teilnahme an einer Woche Vespucci Summer School bringt aber nur gerade 2 ECTS-Punkte! Da ich nicht meine ganzen Ferien an einer Summer School verbringen will, werde ich wohl oder übel gezwungen sein, mir die fehlenden ECTS-Punkte mit weiteren optionalen Elementen (ESRI Virtual Campus-Kurse, optionale UNIGIS-Module) zu beschaffen.

Nun ist bereits das zweite UNIGIS-Modul -- Räumliche Daten und Strukturen -- zu Ende. Als Teil meiner Evaluation hier meine Bilanz dazu:

Das Modul hat meiner Meinung nach wichtige Konzepte und Grundlagen des Themas räumliche Daten aufgegriffen. Das begann bei der Modellierung von Daten allgemein mit ER-Diagrammen und UML (hier hätte ich gerne noch etwas mehr Tiefgang gehabt, aber das soll ja in einem der folgenden Module noch kommen), ging über die verschiedenen räumlichen Datenmodelle (Vektor, Raster, TIN, Hybrid) bis zum zukunftsträchtigen Thema 3D-GIS, wobei hier allerdings ein ziemliches Wirrwarr um die Bedeutung von 3D herrscht (2+1D, 2.5D etc.). Auch das komplexe Thema der Topologie wurde angeschnitten. Diese Datenmodelle kannte ich bereits schon aus der Praxis, die theoretischen Konzepte dahinter sind mir bisher nur selten begegnet. Hier konnte ich doch einige Lücken schliessen.

Ich hatte den Eindruck, dass es bei diesem Modul relativ viel zu lesen gab, was mir allerdings sehr recht war, da ich dann nach einem Arbeitstag vor dem Bildschirm, nicht auch noch zuhause vor dem UNIGIS-Bildschirm arbeiten musste. Aber dies wird sich in den weiteren Modulen sicher auch wieder ändern. Mit Geomedia habe ich in diesem Modul wenig bis gar nichts zu tun gehabt. Wir mussten sehr viele Sachen "von Hand" erledigen (Berechnung einer Poylgonfläche, Polygon-Tabellen, Quadtrees etc.). Dagegen ist auch gar nichts einzuwenden und ich habe das sogar gern gemacht, aber das Fehlen jeglicher Arbeit mit Geomedia hat die Kenntnisse, die ich mir in Modul erworben hatte, wieder zünftig einrosten lassen, so dass ich mich da wieder reinarbeiten muss.

Die zeitliche Einteilung bei diesem Modul war -- trotz einer Woche Ferien und dem Ende des Buchhaltungsjahres beim TTC Brügg -- generell kein Problem. Ich konnte in dieses Modul relativ viel Vorwissen mitbringen, so dass ich oft den Eindruck hatte, die einzelnen Lektionen seien doch etwas gar kurz gewesen. Die UNIGIS-Vorgabe, sich für eine Lektion grössere Zeitblöcke (halber Tag, 3-4 Stunden) zu reservieren, war für mich in diesem Modul nicht realistisch. Einzelne Lektionen hatte ich relativ zügig abgehakt. Aber auch das wird sich in Zukunft sicher wieder ändern...

Ein Problem noch am Rande: Bisher habe ich meistens an den Abenden Zeit für UNIGIS reserviert. Das will ich auch beibehalten. Allerdings sind die Abende nicht mehr wie noch vor der Umstellung auf die Sommerzeit dunkel und düster sondern hell und -- wenn es das Wetter erlaubt -- warm, so dass ich schon das ein oder andere Mal der Versuchung eines UNIGIS-freien Abends auf der Terrasse oder sonstwo draussen erlegen bin. Da bin ich mal gespannt, wie ich meine UNIGIS-Motivation während der WM oder im Hochsommer aufrechterhalten kann :-)