Erstellung eines LiDAR-Moduls für ArcMap anhand von VBA & ArcObjects Diplomarbeit Im Studiengang Forstwissenschaften der Fakultät für Forst- und Umweltwissenschaften an der Universität Freiburg Fabian Ewald Faßnacht Erstprüferin: Prof. Dr. Barbara Koch Zweitprüfer: Prof. Dr. Dieter Pelz Wissenschaftl. Betreuung: Dr. Ing. Holger Weinacker Bearbeitungszeitraum: 21. Mai 2009 bis 21. November 2009 Freiburg, November 2009
115
Embed
Erstellung eines LiDAR-Moduls für ArcMap anhand von VBA ... · Erstellung eines LiDAR-Moduls für ArcMap anhand von VBA & ArcObjects Diplomarbeit Im Studiengang Forstwissenschaften
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Erstellung eines LiDAR-Moduls für ArcMap
anhand von VBA & ArcObjects
Diplomarbeit
Im Studiengang Forstwissenschaften der Fakultät für Forst- und
Umweltwissenschaften an der Universität Freiburg
Fabian Ewald Faßnacht
Erstprüferin: Prof. Dr. Barbara Koch Zweitprüfer: Prof. Dr. Dieter Pelz Wissenschaftl. Betreuung: Dr. Ing. Holger Weinacker
Bearbeitungszeitraum: 21. Mai 2009 bis 21. November 2009
Freiburg, November 2009
Kurzfassung 2
Kurzfassung
Gegenstand der hier vorgelegten Diplomarbeit ist die Erstellung eines Programms zur
Verarbeitung von Laserdaten für das Programm ArcMap von ESRI. Die Arbeit zeigt,
wie anhand von bereits vorhandenen Werkzeugen und Skripten sowie durch eigenent-
wickelte Programmteile eine in ArcMap integrierte Software zur Bearbeitung und Vi-
sualisierung von LiDAR-Daten erstellt wurde. Dabei kamen vor allem „Visual Basic for
Application“ (VBA) sowie ArcObjects zum Einsatz. Die entwickelte Software umfasst
mehrere funktionsfähige Module wie z.B. ein „ASCII-Importer“, ein Modul zur Be-
rechnung von digitalen Oberflächenmodellen sowie verschiedene Möglichkeiten zur
Selektion von Rohdatensätzen und Georeferenzierung selbiger. Der Arbeitstitel des
Abb. 9: Menüstruktur des FELIS-Analyst). .................................................................... 29
Abb. 10: Eine mögliche Erweiterung der Hauptmenüpunkts „Analysis“ des FELIS-Analyst ................................................................................................................ 31
Abb. 11: Eine mögliche Erweiterung des Hauptmenüs des FELIS-Analyst .................. 31
Abb. 12: Vorstellung des FELIS-Analyst: Schema. ....................................................... 32
Abb. 13: Die grafische Schnittstelle des Rohdaten-Importer ......................................... 33
Abb. 14: Rohdaten-Importer: Das Formular und seine Zusammenhänge. ..................... 34
Abb. 15: Das Import Skript im schematischen Überblick .............................................. 36
Abb. 16: Ansicht nach erfolgreichem Import ................................................................. 41
Abb. 17: Berechnung eines normalisierten Laserpunktes .............................................. 44
Abb. 18: Anwenderformular für die Normalisierung von Rohdaten .............................. 44
Abb. 19: Anwenderformular zum Verschmelzen von Rohdaten .................................... 46
Abb. 20: Anwenderformular Georeferenzierung von Rohdaten .................................... 47
Abb. 21: Das Rohdaten Selektionstool ........................................................................... 53
Abb. 23: Schema: DOM: Darstellung des DOM in der „getreckten“ Ansicht .............. 56
Abb. 24: Schema DOM: oberes Bild – Darstellung einer Punktewolke, unteres Bild - Darstellung des DOM in schematischer Darstellung mit Höhenklassen .......... 57
Abb. 25: DOM – Überführung der Rohdaten in eine Oberfläche. Links: Exakte Interpolation – Rechts: Sanfte Interpolation ....................................................... 58
Abb. 26: Das Formular des Moduls zur Berechnung von DOMs .................................. 59
Abb. 27 Ausschnitt des „Topo to Raster“ – Tools in ArcMap ....................................... 60
Abb. 28: Vergleich DOM – DGM.. ................................................................................ 62
Abb. 29: Das DGM – Modul im Überblick .................................................................... 63
Abb. 30: Das Anwenderformular zur DGM Berechnung ............................................... 67
Abb. 31: Präiterative Eliminierung von Punkten ............................................................ 68
Abb. 32: Point Statistics Tool - Arbeitsweise ................................................................. 68
Abb. 33: Das nDOM Berechnungsformular ................................................................... 75
Abb. 34: Beispiel eines berechneten „Aspect-Images“ .................................................. 76
Abb. 35: Beispiel für ein berechnetes „Hillshade-Image“. ............................................. 78
Abb. 36: Beispiel für berechnete Höhenlinien. ............................................................... 79
Tabellenverzeichnis 6
Abb. 37: Der FA erweitert um das Menü „Extraction“ mit den Tools zur Extraktion von Wald, Gebäudegrundrissen, Vegetation, Baumspitzen und Waldstrukturen .................................................................................................... 80
Abb. 38: Der Hilfe-Button im Anwenderformular zur Normalisierung von Rohdaten. ............................................................................................................ 81
Abb. 39: Die Online Hilfe des FELIS-Analyst ............................................................... 81
Tabellenverzeichnis Tab. 1: Beispiel eines LiDAR-Rohdatensatzes im ASCII-Format. [PositionE] =
Position Easting (Rechtswert), [PositionN] = P. Northing (Hochwert), [PositionH] = P. Height (Höhe). ......................................................................... 16
Codeverzeichnis 7
Codeverzeichnis Code 1: Ändern der Eigenschaft „Durchforstung“ durch Erstellung eines Objekts
im IGeneral Interface und anschließender Zuordnung des Objekts zur Klasse Baum, welche den Zugriff auf die Eigenschaft „Durchf“ ermöglicht. ............... 24
Code 2: Einbindung des Hillshade-Tools in den FELIS-Analyst unter Verwendung des Geoprozessors von ESRI. ............................................................................. 26
Code 3: Extraktion der „working destination“. .............................................................. 35
Code 4: Beladen der Arrays mit dem „Input-ASCII-File“ durch eine Schleife. ............ 38
Code 5: Vorbereitung der Felder für das neu erstellte "Shapefile" ................................ 40
Code 6: Beladen des „Shapefiles“ .................................................................................. 41
Code 7: Das Georeferenzierungs-Tool für Rohdaten ..................................................... 48
Code 8: Selektion und Kopierfunktion führen die Punktklassifizierung durch .............. 65
Code 9: Teil des Skripts zur präiterativen Elimination von Punkten ............................. 67
Code 10: Teil des Skripts zur Berechnung von nDOMs. ............................................... 74
Abkürzungsverzeichnis 8
Abkürzungsverzeichnis
ALS Airborne Laser Scanning
ASCII American Standard Code for Information Interchange
COM Component Object Model (Copyright by Microsoft)
DGM Digitales Geländemodell
DOM Digitales Oberflächenmodell
DSM Digital Surface Model
DTM Digital Terrain Model
ESRI Environmental Systems Research Institute
FELIS (Abteilung für) Fernerkundung und Landschaftsinformationssysteme
FP First Pulse
GIS Geografisches Informationssystem (Geographic Information System)
GPS Global Positioning System
INS Inertial Navigation System
LiDAR Light Detection and Ranging
LP Last Pulse
nDOM normalisiertes digitales Oberflächenmodell
nDSM Normalized Digital Surface Model
NN Niveau Null
SQL Structured Query Language
TLS Terrestrial Laser Scanning
UML Unified Modeling Language
VBA Visual Basic for Application
Vorwort 9
Vorwort
An erster Stelle möchte ich meinen Eltern danken für die Unterstützung in den letzten
Jahren, die mir dieses wunderbare Studium ermöglicht hat, das jetzt mit dieser Arbeit
ein Ende findet. Dann möchte ich Lisa danken, für alles und vor allem dafür, dass es
wunderbar ist einen Menschen zu haben, der grundsätzlich auch die andere Seite sieht.
Im Laufe der Entstehung dieser Arbeit sind mir Viele hilfreich zur Seite gestanden:
Holger Weinacker, der mit viel Elan und einem nie versiegenden Quell an neuen Ideen
erheblich dazu beigetragen hat, dass diese Arbeit so entstehen konnte, wie sie heute
vorliegt. Ahmad Youssef, der mit einer bemerkenswerten Geduld und freundlicher Aus-
dauer dafür gesorgt hat, dass sämtliche Fragen, die man über Visual Basic haben kann
eine Antwort finden. Schließlich Frau Professor Koch, die seit mehreren Jahren dafür
sorgt, dass man sich als Hiwi an der Abteilung FELIS immer willkommen fühlt und mir
das Vertrauen entgegenbrachte in Warschau einen LiDAR-Kurs mitgestalten zu dürfen.
Und nicht zu vergessen meine Schwester Annika, die durch akribisches Korrekturlesen
dafür gesorgt hat, dass sich die Gesamtsumme an Kommafehlern drastisch reduziert hat.
Es bleibt zu hoffen, dass der FELIS-Analyst mit dem Abschluss der aktuellen Diplom-
arbeiten erst seinen Anfang gemacht hat und dass dieses Projekt im Laufe der nächsten
Jahre – trotz der Widrigkeiten, die die Umstellung auf das Bachelorsystem mit sich
brachte – weiter bestehen und wachsen wird.
1 Überblick 10
1 Überblick
Die Verwendung von LiDAR (Light Detection and Ranging)-Daten für die topografi-
sche Kartografie und zur Erstellung digitaler Höhenmodelle rückte in den letzten Jahren
immer stärker in das Interesse von Wissenschaft und Wirtschaft. Die Verbindung von
hochgenauen GPS-Einheiten, die durch Bodeneinheiten korrigiert werden, einem soge-
nannten „Inertial Navigation System“ und exakten Lasermessgeräten ist im Begriff, die
bisher üblichen Aufnahmeverfahren zu revolutionieren. Die Kombination der genannten
Komponenten ermöglicht es, die exakte Lage der Reflektionen von Laserimpulsen, die
vom Lasermessgerät ausgesendet werden, digital festzuhalten.
Resultate solcher Laserbefliegungen sind LiDAR-Rohdaten, die auch oft als 3D-
Punktewolken bezeichnet werden. Diese können in verschiedenen Dateiformaten und
mit unterschiedlichen Mengen an Information vorliegen. Im Allgemeinen enthalten Li-
DAR-Rohdaten immer zumindest einen Rechtswert, einen Hochwert und eine Höhe.
Man spricht auch von einem xyz-Format. Diese Werte liefern die exakte Position eines
jeden einzelnen Punktes, sofern man das geografische Bezugs- und Höhensystem kennt.
Die Genauigkeit und Auflösung von LiDAR ist bereits heute in einem sehr bemerkens-
werten Bereich angelangt und rechtfertigt die intensive Forschung in diesem Gebiet der
Fernerkundung. In manchen Testgebieten lag der Fehler in der Lagegenauigkeit bei un-
ter 10cm, die Auflösung kann bis zu mehr als hundert Punkte pro m² betragen.
Ein Hauptproblem der aktuellen Entwicklungen, sowohl in der Wissenschaft als auch in
der LiDAR-Industrie ist das Fehlen eines einheitlichen Dateiformats, sowie die Tatsa-
che, dass eine große Vielfalt an unterschiedlicher Software zur Bearbeitung und zur
Prozessierung von Laserdaten entstanden sind, welche untereinander häufig nicht kom-
patibel sind und von den einzelnen Entwicklern jeweils entsprechend ihren konkreten
Problemstellungen entwickelt wurden. Diese Entwicklung hemmt den Austausch, denn
die Programmierung komplexer Schnittstellen nimmt viel Zeit in Anspruch.
Bezüglich des Dateiformats wurden in den letzten Jahren immer mehr Übereinkünfte
getroffen. Zum heutigen Zeitpunkt scheint es wahrscheinlich, dass das so genannte
LAS-Format sich auf lange Sicht durchsetzen wird. Dieses binäre Format findet sich in
immer mehr Schnittstellen von LiDAR Software und auch die Produkte der Firma ESRI
unterstützen das Format. Dennoch liegen auch heute noch viele Rohdaten im ASCII
Format vor und die Zukunft wird zeigen, welche und wie viele Formate sich durchset-
zen werden.
Ein Blick auf die Situation auf dem Softwaremarkt zeigt, dass es für Außenstehende
nicht einfach ist, sich für ein bestimmtes Produkt zu entscheiden. Man stößt sowohl auf
1 Überblick 11
Freeware, wie das von der amerikanischen Forstbehörde (US Forest Service) entwickel-
te „Fusion“ (vgl. Abb. 1), als auch auf an Universitäten entwickelte, teilweise bereits
sehr weit fortgeschrittene Produkte wie TreesVis, das – gleich wie die vorliegende Dip-
lomarbeit - am FELIS-Institut der Universität Freiburg entstanden ist und immer noch
weiterentwickelt wird. Das Problem, dass diese beiden genannten Softwareprodukte
gemein haben ist die Tatsache, dass der Nutzer sich auf ein vollkommen neues Soft-
wareprodukt einlassen muss. Das bringt eine aufwändige Einarbeitung in die entspre-
chende Benutzeroberfläche und die Funktionsweisen der Programme mit sich.
Dieses Problem kann umgangen werden, indem man bereits vorhandene, vielfach ge-
nutzte Software um ein LiDAR-Modul erweitert. Typischstes Beispiel sind Erweiterun-
gen für die Softwareprodukte von ESRI – insbesondere ArcMap. Das wohl bisher er-
folgreichste Beispiel hierfür ist der LiDAR Analyst der Firma VLC.
Zusammenfassend lässt sich sagen, dass das Potential der LiDAR-Technik zum heuti-
gen Zeitpunkt noch lange nicht ausgeschöpft ist. Die Zahl der Anwendungsbeispiele
wächst täglich und die Entwicklung wird in den nächsten Jahren weiterhin stetig voran-
schreiten. Das große Potential dieser Technik zeigt sich auch in Plänen der großen Welt-
raumagenturen LiDAR-Satelliten ins All zu senden. Genannt werden sollten an dieser
Stelle das CALIPSO-Programm der NASA, sowie das Programm „Living Planet“ der
Esa, die beide ernsthafte Pläne für meteorologische LiDAR-Satelliten enthalten.
Abb. 1: Screenshot aus der Software Fusion des US Forest Service
2 Ziele 12
2 Ziele
Die Abteilung FELIS an der forstlichen Fakultät der Universität Freiburg blickt mitt-
lerweile bereits auf eine mehrjährige Zeitspanne im Forschungsbereich LiDAR zurück.
Es wurde viel Zeit und Aufwand in die Entwicklung der institutseigenen LiDAR-
Software TreesVis gesteckt. Das dabei gesammelte Know-how soll nun auf eine weitere
Software-Plattform übertragen werden. Der Schritt, die bisher gewonnenen Erkenntnis-
se und Entwicklungen im Bereich der Verarbeitung von Laserdaten einem größeren
Anwenderspektrum anbieten zu können, ist konsequent und logisch.
Die vorliegende Diplomarbeit stellt gewissermaßen den Startschuss für diese neue Ent-
wicklung dar. Vor diesem Hintergrund ergeben sich einige primäre Ziele, die im Rah-
men dieser Arbeit umgesetzt werden sollen:
• Erstellung einer übersichtlichen, einfach erweiterbaren und klar strukturierten
Benutzeroberfläche, die ein intuitives Arbeiten ermöglicht und die Einarbei-
tungszeit minimiert.
• Die Planung der einzelnen Bereiche, die durch das Modul abgedeckt werden sol-
len. Dazu gehören u.a.
- Import von Rohdaten und digitalen Höhenmodellen
- Bearbeitungsmöglichkeiten der Rohdaten und Höhenmodelle (u.a.
Geo-referenzieren, Selektionstools, Filtertools)
- Die Berechnung von digitalen Höhenmodellen aus Rohdaten
- Verschiedene Analysetools wie z.B. Funktionen die das Erstellen von
Hangausrichtungs- („Aspect“), Hangneigungs- („Slope“) und Schat-
tierungs-Bilder („Hillshade“) ermöglichen.
• Schließlich die Programmierung der ersten zentralen Funktionen des LiDAR-
Moduls
Die Ziele sind also nicht eindeutig eingegrenzt. Grundsätzlich sollen die Möglich-
keiten zur späteren Weiterentwicklung des Moduls möglichst groß bleiben. Die Ar-
beiten im Rahmen der Diplomarbeit sollen, wie bereits erwähnt, vor allem eine gute
Grundlage für die zukünftige konsequente Weiterentwicklung schaffen.
3 Stand der Technik 13
3 Stand der Technik
Dieses Kapitel ist in zwei Bereiche gegliedert. Zum Einen soll ein kurzer Überblick
über die aktuell erhältliche Software, die denselben Ansatz wie das in dieser Diplomar-
beit vorgestellte Programm verfolgen, gegeben werden zum Anderen soll der aktuelle
Stand der Laserscanner-Technik allgemein dargestellt werden.
3.1 Software
Die Liste der LiDAR-Erweiterungen für ArcMap sind sehr überschaubar. Recherchen
haben im Wesentlichen nur zwei prominente Vertreter als Resultat: Der LiDAR Analyst
der Firma VLS sowie das Programm LP360 der Firma Q Coherent Software. Andere
Software wie z.B. der LiDAR Explorer von Prologic Software konnten mit den beiden
erstgenannten Produkten nicht mithalten.
Die beiden Programme LP360 und LiDAR Analyst zeigen sowohl einige Gemeinsam-
keiten als auch diverse Unterschiede. Q Coherent legt bei ihrem Softwareprodukt gro-
ßen Wert auf eine ideale Visualisierung der LiDAR-Rohdaten, und weist eine komfor-
table und mächtige Importfunktion auf, die das Einlesen von X,Y,Z-Daten im ASCII -
Format schnell und unkompliziert ermöglicht. Auch der Export zu unterschiedlichsten
CAD(.dxf)) ist problemlos möglich. Schwachpunkt der Software sind die stark eingeg-
renzten Funktionen was Verarbeitung und Analyse der Rohdaten angeht. Das Programm
bietet einige Klassifizierungs- und Editierungsoptionen, die aber keine konkreten An-
wendungen, wie z.B. das Extrahieren von Gebäuden oder Waldbeständen oder auch die
Berechnung digitaler Höhenmodelle einschließen. Nach Aussagen des Herstellers be-
steht für den Anwender die Möglichkeit solche Funktionen durch das Entwickeln eige-
ner Algorithmen und das Einbinden selbiger über eine Schnittstelle nachträglich zu in-
tegrieren.
Gemeinsamkeiten finden sich beim LiDAR Analyst und LP360 zum Einen in ihrer 3D-
Darstellung und zum Anderen in der Wahl ihres Dateiformats. Beide Programme grei-
fen auf das oben bereits erwähnte .las-Format zurück, das die vermutlich größten Zu-
kunftschancen im LiDAR-Bereich aufweist. Die 3D-Darstellung der beiden Programme
wiederum hat einen jeweils anderen Fokus. Während bei LP360 die Rohdaten von größ-
tem Interesse sind und die Rohdaten-Punktewolke in der 3D-Ansicht sichtbar werden,
sind es beim LiDAR Analyst hauptsächlich die aus den Rohdaten extrahierten Objekte,
die in der 3D-Sicht visualisiert werden.
3 Stand der Technik 14
Damit kommen wir bereits zu den Funktionen, die den LiDAR Analyst deutlich vom
LP360 unterscheiden. Der LiDAR Analyst bietet eine Vielzahl an konkreten Anwen-
dungen, die unter anderem das Extrahieren von Gebäuden, das Berechnen von Digitalen
Geländemodellen sowie eine Funktion zum Extrahieren von Einzelbäumen oder Wald-
beständen umfassen. Ebenso vorhanden sind diverse Filter und Editiermöglichkeiten für
die Rohdatensätze. Zum Import der Rohdaten steht ebenfalls – ähnlich wie bei LP360 –
ein ASCII zu .las-Importer zur Verfügung. Zusätzlich sollte erwähnt sein, dass die Fir-
ma VLS zusätzlich zum LiDAR Analyst noch eine Reihe weiterer Softwareprodukte
anbietet, die ebenfalls Berührungspunkte zur LiDAR-Technik aufweisen.
An dieser Stelle wird nun noch ein kleiner Überblick über die LiDAR-Technik im All-
gemeinen gegeben.
3.2 LiDAR-Technik allgemein
Bei der LiDAR-Technik handel es sich um ein aktives Fernerkundungssystem. Man
kann grundsätzlich zwischen ALS und TLS-Systemen unterscheiden. Bei ALS-
Systemen handelt es sich um sogenannte „Airborne Laser Scanning“-Systeme, die wie
der Name bereits vermuten lässt aus einer Kombination eines Luftfahrzeuges (in der
Regel Kleinflugzeug oder Helikopter) und einer Laserscannereinheit besteht. Beim
TLS-System hingegen werden die Laserscanner auf der Erdoberfläche eingesetzt (Ter-
restrial Laser Scanning).
Bei ALS-Systemen spielt zusätzlich die Navigationseinheit des Luftfahrzeugs die ent-
scheidende Rolle. Diese besteht aus einem hochgenauen, durch Bodeneinheiten korri-
gierten GPS und einem INS („Inertial Navigation System“). Ein deutscher Begriff für
das INS ist auch Trägheitsnavigation. Das INS ist in der Lage unabhängig von der äu-
ßeren Umgebung Geschwindigkeit und Position des Luftfahrzeugs zwischen den GPS-
Signalen zu interpolieren. Das INS wird benötigt, da das GPS nur in einem bestimmten
Zeitrhythmus (z.B. im Sekundentakt) die Position des Flugzeugs bestimmt. Das INS
berechnet die Lage des Flugzeugs zwischen den GPS-Signalen anhand von Kippwin-
kel, Drehwinkel, Neigungswinkel und der Geschwindigkeit des Luftfahrzeugs. In Ver-
bindung mit den absoluten 3D-Positionen, die das GPS liefert, lässt sich so durchgehend
die exakte Position des Luftfahrzeugs bestimmen. Diese verschiedenen Winkel sind
außerdem unbedingt notwendig, um aus der Laufzeit des Laserimpulses die 3D-Lage
der Reflektion zu bestimmen.
Während des Scans wird also ein „Laserstrahl“ vom Scanner an die Erdoberfläche (bzw.
in Richtung des abzutastenden Objekts – LiDAR wird z.B. auch in der Meteorologie
eingesetzt) abgesendet und das reflektierte Echo an einem Empfänger wieder aufge-
nommen. Anhand der Laufzeit und der vom INS gemessenen Winkel lässt sich die Ent-
fernung des Punktes, an dem die Reflektion erfolgte mit einer sehr hohen Genauigkeit
3 Stand der Technik 15
(besser 0,1 m) erfassen. Mit den zusätzlichen Messungen der hochgenauen GPS-
Einheiten, wird es möglich, die 3D-Lage des Punktes mit hoher Genauigkeit zu bestim-
men. Das Resultat eines solchen Scans sind 3D-Punktewolken (Abb.2). Die Dichte die-
ser Punktewolken kann heutzutage bei neuesten Befliegungsmethoden mit teilweise
überlappenden Befliegungsstreifen bis zu über 100 Punkte / m² betragen.
Die in der Befliegung gesammelten Daten werden in der Regel vom Befliegungsunter-
nehmen vorverarbeitet und dem Kunden dann in einem bestimmten Dateiformat (oft
ASCII) geliefert. Die Vorverarbeitung umfasst häufig das Herausfiltern von fehlerhaften
Punkten (wie z.B. durch Vögel verursachte Reflektionen) sowie die Unterteilung der
Punkte in First Pulse und Last Pulse-Punkte – dazu mehr unten.
Wie bereits angedeutet, bestehen die gesammelten Informationen zu jedem Punkt min-
destens aus den Lagekoordinaten (Hoch- und Rechtswert) sowie einem Höhenwert
(Tab. 1). Zusätzlich zu diesen Werten werden heutzutage oftmals Attribute wie Intensi-
tät, Neigungswinkel, Kippwinkel, Signallänge, Signalamplitude und einige andere mehr
aufgenommen. Diese zusätzlichen Informationen vergrößern die Auswertemöglichkei-
ten der LiDAR-Daten im Hinblick auf die jeweiligen fachspezifischen Fragestellungen.
Eine weitere wichtige Eigenschaft von LiDAR-Systemen ist die Tatsache, dass ein La-
serstrahl häufig nicht nur ein einzelnes Echo liefert, sondern mehrere. Dies lässt sich
besonders anschaulich in bewaldeten Regionen erklären: In einem Waldgebiet ist die
Wahrscheinlichkeit relativ hoch, dass ein vom Luftfahrzeug ausgesendeter Laserstrahl
zuerst auf die Vegetationsschicht trifft, z.B. ein Blatt. An dieser Stelle wird nun ein Teil
des Strahls reflektiert und der Empfänger im Flugzeug registriert ein erstes Echo. Der
andere Teil des Strahls bewegt sich weiter in Richtung Bodenoberfläche. Im Idealfall
erreicht der Laserstrahl schlussendlich den Boden und wird hier nun vollständig reflek-
tiert und der Empfänger erhält das letzte Echo – dazwischen können noch mehrere zu-
Abb. 2: Eine LiDAR – 3D-Punktwolke (Darstellung aus TreeVis)
3 Stand der Technik 16
sätzliche Reflektionen mit anderen Blättern oder Zweigen stattfinden. Grund für dieses
Verhalten des Laserimpulses ist die Tatsache, dass jeder der ausgesendeten Impulse
einen gewissen Durchmesser (der ausgesendete Laserstrahl breitet sich in einer Kegel-
form aus) besitzt. Wird nun z.B. ein Blatt vom Impuls nur gestreift so läuft der andere
Teil weiter am Blatt vorbei (Abb. 3).
Die eben beschriebene erste Reflektion führt zu sogenannten „First Pulse“-Punkten (FP-
Punkte). Die Punkte aus der letzten Reflektion werden „Last Pulse“-Punkte (LP-Punkte)
genannt (Abb. 4). Grundsätzlich muss aber ein LP-Punkt nicht immer an der Boden-
oberfläche liegen. Es gibt auch viele Fälle in denen der Laserstrahl nicht bis zum Boden
vordringen kann, sondern bereits an einem der Hindernisse seine komplette Intensität
verloren hat. Die FP-Punkte hingegen beschreiben immer den Punkt, an dem der Laser-
strahl zum ersten Mal reflektiert wurde, das kann sowohl die Bodenoberfläche sein
(wenn keine Hindernisse vorhanden sind), als auch ein Vogel (was dann natürlich in
vielen Auswertungen zu Fehlern führen kann, wenn diese Punkte nicht aus dem Daten-
Tab. 1: Beispiel eines LiDAR-Rohdatensatzes im ASCII-Format. [PositionE] = Position Eas-ting (Rechtswert), [PositionN] = P. Northing (Hochwert), [PositionH] = P. Height (Höhe).
Abb. 3: Ein Laserstrahl trifft auf ein Blatt und wird teilweise reflektiert
3 Stand der Technik 17
satz gefiltert werden) oder ein anderes Hindernis wie eine Stromleitung oder eben Vege-
tation (Bäume, Büsche etc.).
Die Anwendungsmöglichkeiten der LiDAR-Technik sind vielfältig und werden voraus-
sichtlich in den nächsten Jahren noch wachsen. Heute wird sie bereits in der 3D-
Stadtmodellierung, zum automatischen Erkennen von Brücken und Stromleitungen, in
der Meteorologie sowie zur Erstellung hochgenauer digitaler Höhenmodelle eingesetzt.
Abb. 4: Drei mögliche Wege eines Laserstrahls: 1.) LP = FP – Strahl trifft direkt auf den Boden 2.) Strahl trifft nach 3 Reflektionen in der Baumkrone auf den Boden 3.) Strahl wird in der dritten Reflektion in der Krone vollständig reflektiert und trifft nicht auf den Boden
4 Eingeschlagener Realisierungsweg 18
4 Eingeschlagener Realisierungsweg
Die Realisierung des Projekts „Erstellung eines LiDAR-Moduls für ArcMap“ wurde
anhand unterschiedlicher Methoden umgesetzt. Wichtigster Punkt dabei war die in
ArcMap integrierte ArcObjects-Technologie, die basierend auf der sogenannten COM-
Technologie von Microsoft umfangreiche Möglichkeiten zur Eigenentwicklung inner-
halb von ArcMap und ArcCatalog ermöglicht. Die COM-Technologie (Component Ob-
ject Model) ist grundsätzlich mit den meisten gängigen Programmiersprachen wie C,
C++, VB usw. kompatibel und ermöglicht den Zugriff auf die internen Funktionen der
jeweiligen Software, die mit der COM-Technologie ausgestattet wurde.
Mit einem einfachen Beispiel wird die COM-Technologie erläutert: Gegeben ist ein
LiDAR-Rohdatensatz als „Shapefile“, der vereinzelte fehlerhafte Punkte mit Höhenwer-
ten über 5000 m enthält. Da der Rohdatensatz in 20 Teile zerlegt ist wäre es umständ-
lich alle Punkte manuell mit den dazu nötigen Schritten auszusortieren. Die manuellen
Schritte umfassen eine Selektion in der Attributtabelle der jeweiligen „Shapefiles“, das
Löschen selbiger und das Speichern des veränderten „Shapefiles“.
Für jede der genannten Schritte existiert innerhalb von ArcMap eine Routi-
ne/Anwendung, mit deren Hilfe die jeweilige Aufgabe erfüllt werden kann. Die COM-
Technologie ermöglicht es, über eine Programmiersprache nacheinander automatisch
auf diese Routinen zuzugreifen und die Prozesse hintereinander ablaufen zu lassen. Die
Routinen liegen in der Regel als dll- oder exe-Datei vor und laufen dementsprechend
selbstständig ab – nur die jeweiligen Eingangs- und Ausgangsdaten müssen definiert
werden.
Dementsprechend könnte man nun für unser Beispiel ein kleines VBA-Programm
schreiben, in dem der Anwender nur das Eingangs-„Shapefile“ definieren muss und
dann alle darauffolgende Schritte automatisch ablaufen, ohne dass die jeweiligen Routi-
nen von ArcMap manuell aufgerufen werden müssen.
Das erstellte Programm würde nach dem „OK“-Mausklick zuerst eine Selektion durch-
führen, die ausgewählten Einträge in der Attributtabelle löschen und das dabei entste-
hende Shapefile speichern bzw. in einer neuen Datei speichern.
Abb. 5 veranschaulicht die nacheinander geschalteten Routinen innerhalb von ArcMap
anhand eines Diagramms, welches im Model Builder erstellt wurde. Der „Model Buil-
der“ erlaubt grundsätzlich ebenfalls das Hintereinanderschalten mehrerer Routinen, al-
lerdings ist mit dem Model Builder keine komfortable Einbindung des erstellten Scripts
in ein Anwenderformular möglich, und auch die variable Definition von Eingangs- und
Ausgangsdateien ist nicht möglich.
4 Eingeschlagener Realisierungsweg 19
Jede der angewendeten Routinen ist als eine orangefarbene Box dargestellt – die Ellip-
soide repräsentieren Eingangs- und Ausgangsdateien.
Das hier vorgestellte Beispiel ist unvollständig, da an dieser Stelle nur Routinen ver-
wendet werden, die auch als Tools in der Toolbox von ArcMap vorliegen. Andere Rou-
tinen, wie z.B. das Entfernen eines Layers von der aktuellen Sicht in ArcMap oder auch
das Aktualisieren der aktuellen Sicht, sind Funktionen, die in ArcMap direkt per
„Rechtsklick“ zu erreichen sind, aber in der Toolbox nicht existieren.
Mit der COM-Technologie kann man auch auf all diese Funktionen von ArcMap zugrei-
fen. Grundsätzlich ist es möglich jegliche Handlung, die in ArcMap möglich ist, anhand
von einer Programmiersprache zu automatisieren.
Ganz allgemein könnte man die COM-Technologie als eine Art „Bauklötzchensystem“
bezeichnen – alle Einzelbausteine werden geliefert und können dann selbst zusammen-
gebaut werden, um neue Konstruktionen zu erschaffen.
4.1 Die COM-Technologie in ArcObjects
Unabhängigkeit von Programmiersprachen:
Bereits in der Einleitung wurde erwähnt, dass die COM-Technologie mit prinzipiell
allen Programmiersprachen funktioniert. Die COM-Technologie ist damit unabhängig
von der Programmiersprache. Unabhängigkeit bedeutet in diesem Fall, dass erstens alle
Komponenten von ArcMap / ArcCatalog durch jede Programmiersprache aufgerufen
werden können und zusätzlich, dass alle Komponenten funktionsfähig sind, unabhängig
von der Programmiersprache in der sie ursprünglich verfasst wurden.
Um dies zu erreichen, müssen die jeweiligen Komponenten zwei Anforderungen erfül-
len: Erstens müssen sie unabhängig von der jeweiligen Programmiersprache, in der sie
geschrieben wurden, definiert werden (was hier durch die Definition als COM-Klasse
Abb. 5: Illustration Beispielprogramm. Orangene Boxen = Routinen (hier werden die Daten verarbeitet), blaue und grüne Ellipsoide stellen Eingangs- und Ausgangsdaten dar
4 Eingeschlagener Realisierungsweg 20
realisiert wird) und zweitens müssen sie sich an gewisse binäre Standards halten, die
spezifizieren, wie auf die Komponente zugegriffen werden kann.
Die Struktur der Komponenten:
Die Komponenten im COM-System von ArcMap / ArcCatalog sind unterteilt in drei
verschiedene Kategorien: Klassen, Unterklassen und Eigenschaften. Zusätzlich gibt es
sogenannte „Methoden“, die definieren, was man mit den jeweiligen Klassen und Un-
terklassen tun kann, sowie „Ereignisse“, die festlegen, wie mit den Klassen und Unterk-
lassen zu verfahren ist, wenn ein eben solches Ereignis eintritt.
„Die Programmierung mit Klassen und ihren Funktionen (Eigenschaften, Methoden und
Ereignisse) nennt man Objekt-orientierte Programmierung.“ (Liebig 2007, S.108)
Objekt-orientierte Programmierung arbeitet, wie der Name bereits sagt, mit Objekten.
Beschäftigt man sich z.B. mit dem Thema „Kraftfahrzeuge“ so wäre z.B. ein VW Polo
ein Objekt dieses Themas. Um mehr Struktur in die zahlreichen Objekte hineinzubrin-
gen werden Klassen geschaffen. Im Beispiel Kraftfahrzeuge würde es dann z.B. eine
Klasse „PKW“, eine Klasse „LKW“ und eine Klasse „motorisierte Zweiräder“ geben.
Jede Klasse hat dann wiederum einige Eigenschaften und Methoden (und Funktionen),
die auf alle Objekte innerhalb der Klasse angewendet bzw. abgefragt werden können.
Ein Beispiel hierfür wäre die Fahrzeugfarbe oder die PS-Zahl.
Ein weiterer wichtiger Begriff ist das sogenannte „Objekt-Modell“ welches die Zusam-
menhänge zwischen den Klassen und ihren Funktionen definiert. ArcObjects ist dem-
nach das Objekt-Modell der Firma ESRI. Man könnte das Objekt-Modell als eine Art
Übersicht für das oben beschriebene „Bauklötzchensystem“ bezeichnen. Es zeigt wel-
che Klötzchen aufeinander passen, was für Eigenschaften die Klötzchen haben (z.B.
Farbe, Koordinatensystem etc.), was für Funktionen sie haben und wie sie auf bestimm-
te Ereignisse reagieren.
Das Objekt-Modell ist im Falle von ESRI in ca. 30 Postern zusammengefasst, die mit
der Software geliefert werden und auf denen mehr oder weniger komplexe Diagramme
zu sehen sind. Zusätzlich gibt es eine umfangreiche Hilfedatei für Entwickler, die zu
allen Komponenten Informationen und oftmals auch Skriptbeispiele liefert.
In den eben genannten Postern werden die Zusammenhänge zwischen den verschiede-
nen Klassen (es existieren auch noch verschiedene Typen von Klassen) durch spezielle
Symbole ausgedrückt. Abb. 6 (nach Liebig 2007, S.113) illustriert diese Symbole. Diese
Symbole wurden von ESRI nicht einfach erfunden, sondern sie bauen auf dem soge-
nannten UML („Unified Modeling Language“)-Standard auf.
Dabei steht das Dreieck für eine Hierarchie zwischen den Klassen, in unserem Beispiel
(Abb. 6) bedeutet dies, dass der Baum zur übergeordneten Klasse der Pflanzen gehört
und eine Unterklasse der Pflanzen darstellt. Die Unterklassen erben die Methoden, Ei-
4 Eingeschlagener Realisierungsweg 21
genschaften und Ereignisse (=Interfaces) der übergeordneten Klasse. Daher bezeichnet
man diese Beziehung auch als „Vererbung“
Die Raute steht für „Hat ein …“. In unserem Beispiel bedeutet dies: „Der Baum hat ein
Vogelnest“. Beide Objekte können aber auch unabhängig voneinander existieren.
Die ausgefüllte Raute steht für „Ist zusammengesetzt aus…“. In unserem Beispiel be-
deutet dies: „Der Baum ist (u.a.) zusammengesetzt aus mehreren Blättern“. Beide Ob-
jekte können unabhängig voneinander nicht existieren. Der Stern zeigt an, dass der
Baum mehrere der Objekte besitzt.
Die gestrichelte Linie steht für „Erzeugt…“. In unserem Beispiel bedeutet dies: „Der
Baum erzeugt Sauerstoff“.
Die einfache Linie signalisiert einen allgemeinen Zusammenhang zwischen zwei Klas-
sen. Ein Baum wird mit dem Begriff „Natur“ in Verbindung gebracht.
Zusätzlich zu den Zusammenhängen zwischen den Klassen untereinander gibt es noch
die sogenannten „Interfaces“, welche die Eigenschaften und Methoden einer Klasse in
logische Gruppen einteilen. Wenn z.B. eine Eigenschaft des Baumes geändert werden
soll, so muss man über die Klasse Baum auf ein Interface zugreifen. Abb. 7 zeigt ein
Beispiel für zwei Interfaces, die für die Klasse Baum existieren könnten.
Abb. 6: Die Zusammenhänge zwischen den Klassen in den grauen Boxen sind durch die oben links beschriebenen Symbole definiert.
4 Eingeschlagener Realisierungsweg 22
In diesem Fall könnten die Eigenschaften Baumart und Durchforstung, sowie die Me-
thode „umarmen“ nur über das Interface IGeneral und die Eigenschaften BHD, Höhe
und Formzahl nur über das Interface IMaße erreicht werden. Dabei könnte man die
Eigenschaften Baumart, BHD, Höhe und Formzahl nur lesen (vgl. Abb. 8) und keinen
neuen Wert zuweisen, da diese Werte durch den Anwender nicht verändert werden kön-
nen (Das Wachstum des Baumes – also der BHD und die Höhe – kann von uns nicht
direkt verändert werden). Dahingegen kann die Eigenschaft Durchforstung („Durchf.“)
verändert werden (ja / true � Baum wird als Durchforstungsbaum ausgewiesen, nein /
false � Baum bleibt im Bestand).
Abb. 8 zeigt in einer Übersicht zusammengefasst, was die Symbole der Interfaces je-
weils ausdrücken. Weiterer Erklärung bedarf es wohl nur beim Symbol „nur schreiben
(put by reference)“. Trägt eine Eigenschaft dieses Symbol, so besteht ein Verweis zum
aktuellen Objekt. Das bedeutet, dass wenn das Objekt, zu dem der Verweis besteht ge-
ändert wird, sich auch die Eigenschaft mit dem Symbol ändert.
Folgendes Beispiel verdeutlicht diesen Sachverhalt: Es wurde ein Skript erstellt welches
auf Knopfdruck einen Marker mit einer Beschriftung erstellt. Dabei ist die Eigenschaft
„Farbe der Beschriftung“ mit der Eigenschaft „Farbe des Markers“ verknüpft. Wenn
nun die Farbe des Markers verändert wird, wird sich die Farbe der Beschriftung automa-
tisch ebenfalls verändern. Allerdings besteht keine Möglichkeit nur die Farbe der Be-
schriftung zu verändern, da hierfür nur ein Lesezugriff definiert ist.
Abb. 7: Beispiel für zwei Interfaces der Klasse Baum. Über das Interface IGeneral können auf die Eigenschaften Baumart und Durchforstung sowie die Methode umarmen zugegriffen werden. Über das Interface IMaße auf die Eigenschaften BHD, Höhe und Formzahl. Siehe Abb. 8 für die Bedeutung der Symbole
4 Eingeschlagener Realisierungsweg 23
Zugriff auf Klassen / Eigenschaften / Methoden
Um Zugriff auf eine bestimmte Klasse oder ein Interface zu erhalten, muss immer zuerst
ein Objekt erstellt werden, welches dann der Klasse zugeordnet wird. Grundsätzlich gilt,
dass innerhalb einer „Abstract Class“ (einer der in ArcObject verfügbaren Klassenty-
pen) keine Objekte direkt erstellt werden können. Um also auf eine Abstract Class und
ihre Interfaces zugreifen zu können, muss zuerst ein Objekt in einer „Class“ oder „Co-
Class“ (die zwei anderen in ArcObject verfügbaren Klassentypen) erstellt werden, wel-
che mit der Abstract Class in Verbindung stehen. In unserem Beispiel in Abb. 6 würde
das bedeuten, dass zuerst ein Objekt innerhalb der Klasse „Baum“ erstellt werden müss-
te, um auf die Methoden und Eigenschaften der Abstract Class „Pflanzen“ Zugriff zu
erhalten.
Zusätzlich muss in der Regel zuallererst im Code der Zugriff auf ArcMap selbst und
anschließend auf das aktuell geladene Dokument hergestellt werden. Wobei der Zugriff
auf ArcMap automatisch geschieht und nicht mehr in den jeweiligen Code integriert
werden muss.
Folgendes Beispiel soll den Sachverhalt illustrieren: Es soll ein Zugriff auf die Klasse
Baum erfolgen und die Eigenschaft „Durchforstung“ soll von „nein“ auf „ja“ gesetzt
werden. Ein Code, der diese Aufgabe löst, kann folgendermaßen implementiert werden:
Abb. 8: Interface Symbole. Die illustrierten Symbole geben Aufschluss darüber welche Be-standteile der Interfaces auf welche Art und Weise genutzt werden können.
4 Eingeschlagener Realisierungsweg 24
Sub Durchforstung()
Dim DurchfBaum As IGeneral
‘Erstellung eines IGeneral Objekts
Set DurchfBaum = new Baum
‘Das erstellte Objekt wird der Klasse Baum zugewiesen und hat somit Zugriff auf alle Eigenschaften der Klasse
DurchfBaum.Durchf = true
‘Nun ist es möglich auf die Eigenschaft „Durchf“ des General-Interfaces zuzugreifen und den Wert ändern
End Sub
Code 1: Ändern der Eigenschaft „Durchforstung“ durch Erstellung eines Objekts im IGeneral Interface und anschließender Zuordnung des Objekts zur Klasse Baum, welche den Zugriff auf die Eigenschaft „Durchf“ ermöglicht.
Diese Informationen über ArcObjects und die COM-Technologie geben nur einen sehr
kurzen und groben Überblick. Eine ausführliche Erklärung der Funktionen und Ar-
beitsweisen innerhalb dieser beiden Technologien würde den Rahmen dieser Arbeit bei
Weitem sprengen. Es existiert eine große Anzahl an Literatur, die sich ausführlich mit
dem Thema COM und ArcObjects beschäftigt und einen tieferen Einblick in das Thema
ermöglicht (Vgl. unter anderen Liebig, W. (2007), Razavi, A. H. (2002)).
4.2 Integration und Adaption bestehender Skripte
Zur Erstellung der unterschiedlichen Module, innerhalb des hier vorgestellten Prog-
rammpakets „FELIS-Analyst“ wurden drei unterschiedliche Vorgehensweisen ange-
wendet. Zum einen wurde die Integration und Adaption bereits bestehender Skripte
(4.2), als zweites die Verwendung von Werkzeugen aus der Toolbox (4.3) und schließ-
lich das Erstellen komplett eigener Skripte (4.4) praktiziert. Zur weiteren Veranschauli-
chung der Vorgehensweise wird für jede der drei Möglichkeiten ein Beispiel aus dem
FELIS-Analyst kurz beschrieben.
Ein Beispiel für die Integration und Adaption eines bestehenden Skriptes stellt im FE-
LIS-Analyst der ASCII-Importer dar. Das Kernstück des Importers stammt aus einem
Skript (Xiaodong ZHAO, 2002), das auf der offiziellen ESRI-Homepage heruntergela-
den wurde – die Seite http://arcscripts.esri.com/ bietet allen ESRI Anwendern die Mög-
lichkeit, selbstentwickelte Skripte zu veröffentlichen und somit der ESRI-
Anwendergemeinde kostenlos zur Verfügung zu stellen. Das ursprüngliche Skript liefer-
te nur die Kernfunktionen des Imports – konkret das Umwandeln einer ASCII-Datei in
einem speziellen Format (x, y, z durch Leerzeichen getrennt, ohne Dateikopf („Hea-
der“)) zu einem ArcGIS Punkt-„Shapefile“. Um den Anforderungen eines ASCII-
4 Eingeschlagener Realisierungsweg 25
Importers im Rahmen unseres Projekts gerecht zu werden, mussten einige Details im
Skript ergänzt und umgeschrieben werden. Zusätzlich musste ein anwenderfreundliches
Formular inklusive einer Vorschaufunktion für die ASCII-Datei („Preview“) erstellt
werden.
Wichtige Veränderungspunkte waren:
1. Das Trennzeichen sollte frei wählbar sein: Leerzeichen, Strichpunkt, Komma,
Tab
2. Ein Header in der Textdatei sollte durch die Wahl der ersten zu importierenden
Zeile umgangen werden können
3. Eine Vorschaufunktion, um Punkt 2 möglichst komfortabel zu ermöglichen
4. Es sollte sichergestellt sein, dass auch ASCII-Dateien mit zusätzlichen Attribu-
ten (neben Rechts-, Hochwert, Höhe) importiert werden können
Auf welche Art und Weise diese Veränderungen/Ergänzungen umgesetzt wurden, wird
hier nicht näher besprochen. In der Beschreibung der einzelnen Module des FELIS-
Analyst findet man zusätzliche Informationen. Grundsätzlich kann jedes Skript mit Hil-
fe von VBA und auch ArcObjects verändert werden.
Die Methode bereits bestehende Skripte zu verwenden und diese nach Bedarf anzupas-
sen hat sich sehr bewährt, da das Erstellen komplett neuer Skripte – insbesondere in
ArcObjects oft sehr zeitintensiv ist und bereits die Einarbeitung in die grundlegenden
Zusammenhänge der einzelnen Klassen und CoKlassen in ArcObjects einen großen Teil
der für diese Arbeit zur Verfügung stehenden Zeit in Anspruch genommen hätte.
4.3 Nutzung von Werkzeugen der Toolbox
Eine weitere Möglichkeit die Funktionspalette des FELIS-Analyst zu erweitern besteht
darin, bereits vorhandene Tools der ArcMap-Toolbox in das Programm zu integrieren.
Diverse Tools, insbesondere Tools des Spatial- und 3D–Analyst, eignen sich auch zur
Analyse von LiDAR-Daten bzw. zur Auswertung der aus LiDAR-Daten berechneten
digitalen Höhenmodelle. Die Einbindung dieser Tools erspart dem Anwender die Suche
nach den Tools in der Vielzahl an Toolboxen, die in ArcMap zur Verfügung stehen und
zusätzlich stellt man sicher, dass der Anwender tatsächlich alle Möglichkeiten, die ihm
zur Analyse von LiDAR-Daten zur Verfügung stehen, auch nutzen kann. Anwender, die
im Umgang mit ArcMap weniger geübt sind, könnten ansonsten in die Situation gera-
ten, dass sie sich der Existenz dieser Tools nicht bewusst sind und deshalb nicht nutzen.
Die Einbindung von Tools aus der Toolbox in den FELIS-Analyst verläuft immer nach
einem ähnlichen Schema. Zuerst muss ein Anwenderformular erstellt werden, welches
inhaltlich dem Anwenderformular entspricht, das beim Starten des Tools aus der Tool-
4 Eingeschlagener Realisierungsweg 26
box geöffnet wird. Anschließend erfolgt das Einbinden des Skripts in das Formular. Die
Skripte folgen immer demselben Muster, welches in Code 2 veranschaulicht wird. Code
2 zeigt das Skript, welches nach Klicken des „OK“-Buttons im Anwenderformular des
Hillshade-Tools (innerhalb des FA) aufgerufen wird. (Skript wurde zur Vereinfachung
Code 2: Einbindung des Hillshade-Tools in den FELIS-Analyst unter Verwendung des Geopro-zessors von ESRI. Nach Definition der Eingangs- und Ausgangsvariablen wird das Hillshade-Tool mit dem Schlüsselwort „Call gp.Hillshade_sa“ und in Klammer gesetzten Eingangspara-metern aufgerufen.
etwas gekürzt). Zuerst werden in einem Skript die Eingangs- und Ausgangsvariablen
erstellt und ihnen Inhalte zugewiesen. Die Inhalte in obigem Beispiel stammen aus dem
Anwenderformular, welches sich nach Wahl des „Hillshade“-Tools im FELIS-Analyst
öffnet.
4 Eingeschlagener Realisierungsweg 27
„InRaster“ und „OutRaster“ sind eingehende bzw. ausgehende Bilddateien für das Hill-
shade-Tool. Die Inhalte für diese Variablen liefern die zwei Textboxen des Formulars,
in die der Anwender zum Einen die eingehende und zum Anderen die ausgehende Bild-
datei durch Eingabe definiert. Das Skript greift dann auf diese Textboxen zu und ordnet
deren Inhalt den Variablen zu. Z.B.: Für die Variable InRaster hat das Skript folgende
Dabei ist der Aufbau dieser Zeile grundsätzlich immer derselbe. Zuerst das Schlüssel-
wort „Call“, anschließend gp.NameDesTools(Input, Output, Parameter1, Parameter2,
…, ParameterX). Wobei „gp“ dem eben erstellten Geoprozessor entspricht.
Auf diese Art und Weise wurden die Tools des Untermenüs “Analysis” - „Create As-
pect Image“, „Create Slope Image“, „Create Hill Shade Image“ und „Export to Google
Earth (KML)” - in den FELIS-Analyst eingebunden.
Diese Vorgehensweise wird auch innerhalb eigen erstellter Skripte in Verbindung mit
anderen Strukturen genutzt.
4.4 Erstellung eigener Skripte
Das erfolgreiche Erstellen eigener Skripte ist von einigen Faktoren abhängig. Folgende
Fragestellungen sollten vor Beginn der Programmierung geklärt sein:
1. Was soll mit dem Skript erreicht werden?
2. Gibt es bereits Lösungen von anderen Entwicklern, wenn ja, was sollte anders
gemacht werden?
3. Welche Funktionen von ArcMap und ArcCatalog werden benötigt, um die ge-
setzten Ziele zu erreichen?
4. Werden Funktionen benötigt, die weder durch Tools noch durch sonstige direkt
anwählbare Funktionen von ArcMap und ArcCatalog zur Verfügung stehen?
4 Eingeschlagener Realisierungsweg 28
Sind diese Fragen für das jeweilige Problem geklärt, kann die Planung des Skripts fort-
gesetzt werden. An dieser Stelle soll wiederum ein Beispiel aus dem FELIS-Analyst
angeführt werden: Das Skript zur Berechnung von digitalen Geländemodellen (DGM,
engl. Digital Terrain Model) wurde auf Basis eines Artikels von Evans und Hudak
(Evans, J. S.; Hudak, A.T, 2007) komplett selbst programmiert. Der Artikel beschreibt
die Vorgehensweise, die die Autoren anwandten, um aus einem LiDAR-Rohdatensatz
digitale Geländemodelle zu berechnen. Der von den Autoren verwendete Algorithmus
wird unten im Kapitel 5.6.2 ausführlich besprochen. In diesem Kapitel liegt der Fokus
darauf zu erklären mit welcher Methodik der Algorithmus in ArcMap integriert wurde:
Zu Beginn wurden alle im Artikel beschriebenen Schritte manuell in ArcMap nachvoll-
zogen. Nach und nach wurden die jeweiligen Funktionen und Tools bestimmt, die nötig
waren, um die beschriebenen Vorgänge nachzustellen. Nachdem alle Teilschritte der
Vorgehensweise, die auch in einem für ArcView in der Programmiersprache „eml“ ge-
schriebenen Programm vorlagen, verstanden waren, wurden die Schritte in VBA prog-
rammiert.
Hauptunterschied bei der Erstellung eigener Skripte im Vergleich zu den bisher be-
schriebenen Vorgehensweisen ist die fehlende Grundstruktur, die selbstständig prog-
rammiert werden muss. Im Falle des DGM–Moduls des FELIS-Analysts bot der ge-
nannte Artikel eine große Hilfestellung.
4.5 Die Erstellung der Benutzeroberfläche
Eine Benutzeroberfläche sollte immer einige grundlegende Prinzipien erfüllen. Dazu
gehören:
1. Übersichtlichkeit
2. Eine Struktur, die intuitives Arbeiten ermöglicht
3. Keine Überladung der Menüstrukturen
4. Hierarchischer Aufbau
Es ist relativ einfach, diese grundlegenden Faktoren zu bestimmen, die Umsetzung ist
umso schwerer. Grundsätzlich steht man immer dem Problem gegenüber, dass der Kreis
der Anwender unterschiedliche Wahrnehmungen und Ansprüche an die Benutzerober-
fläche besitzt. Die Wahrnehmung und auch das Verständnis der Benutzeroberfläche und
der angebotenen Programmfunktionen sind stark abhängig von der Erfahrung und dem
Wissen des Benutzers. Das beginnt bei einfachen Problematiken wie der Kenntnis von
Fachtermini. Ist dem Anwender nicht bewusst, dass die Abkürzung DSM für „Digital
Surface Model“ steht, so wird er mit dem Menüpunkt „Calculate DSM“ nichts anzufan-
gen wissen. Gleichzeitig spielen auch noch ganz andere psychologische Faktoren eine
4 Eingeschlagener Realisierungsweg 29
Rolle. Mancher Anwender reagiert positiv auf verschiedene grafische Reize und Bilder
innerhalb der Menüstruktur, andere Anwender empfinden dies eher als störend und
überflüssig. Vermutlich ist es nicht möglich eine Benutzeroberfläche zu erstellen, die
die Ansprüche jedes Einzelnen vollkommen erfüllt. Dennoch sollte das Ziel sein, zu-
mindest so vielen Benutzern wie möglich eine angenehme Arbeitsoberfläche zu präsen-
tieren.
Im Falle des FELIS-Analyst wurde versucht eine Menüstruktur zu erstellen, die sich gut
in die dem Anwender vermutlich bereits bekannte ArcMap-Umgebung eingliedert. An-
dere Erweiterungen, wie z.B. der Spatial-Analyst oder der 3D-Analyst wurden als Vor-
bild herangezogen. Abb. 9 zeigt eine Übersicht über die Menüstruktur des FELIS-
Analyst.
Es wurde davon ausgegangen, dass der Anwender grundlegende Kenntnisse über Li-
DAR-Daten bereits besitzt, da in der Regel nur sehr wenige fachfremde Anwender mit
einem Programm wie dem FELIS-Analyst arbeiten werden. Der Aufbau des Menüs
folgt einer logischen hierarchischen Struktur. Ganz am Anfang hat der Anwender einen
Rohdatensatz im ASCII-Format. Um diesen innerhalb von ArcMap zu verwenden, öff-
Abb. 9: Menüstruktur des FELIS-Analyst: 5 Hauptmenüpunkte, die jeweils weitere Unter-punkte aufweisen (in der Darstellung sind die Unterpunkte jeweils durch schwarze Linien mit den Hauptmenüpunkten verbunden).
4 Eingeschlagener Realisierungsweg 30
net er den Rohdaten-Importer, den er über den ersten Menüpunkt „Raw Data“ und dann
„Import“ erreicht. Nach erfolgreichem Import findet er ebenfalls unter dem ersten Me-
nüpunkt Möglichkeiten die importierten Rohdaten zu georeferenzieren und durch Selek-
tion zu verändern.
Dann folgt der nächste Schritt: Die Berechnung digitaler Höhenmodelle – DOM, DGM
und nDOM – aus den Rohdaten. Dieser Vorgang findet oft nach dem Import der Rohda-
ten statt. Diese Optionen stehen im zweiten Menüpunkt „Calculation“ zur Verfügung.
Nach erfolgreicher Berechnung der digitalen Höhenmodelle ist der Anwender nun in
der Lage mit den Analyse-Tools des dritten Menüpunktes erste Auswertungen der Hö-
henmodelle vorzunehmen. Der vierte Menüpunkt ist prinzipiell auf einer Hierarchieebe-
ne mit dem Dritten. Er bietet die Möglichkeit, die erstellten Modelle zu georeferenzie-
ren (sofern nicht bereits die Rohdaten referenziert waren) und die Modelle in ein
TreesVis-kompatibles Format zu exportieren.
Im letzten Menüpunkt finden sich Links zu einem Tutorial, Lizenzinformationen sowie
die FELIS-Analyst Hilfedatei.
Es muss an dieser Stelle gesagt werden, dass die bisher erstellte Struktur nur den aktuel-
len Stand des Programms wiederspiegelt. Da mit der Zeit immer mehr Module in den
FELIS-Analyst einfließen sollen wird sich vermutlich auch die Menüstruktur weiter-
entwickeln müssen.
Aufgrund der Tatsache, dass die Erstellung von Anwenderformularen und auch die Ers-
tellung von Menüs in der Programmierumgebung von VBA sehr unkompliziert und
unproblematisch ist, sollte das aber keine Hindernisse in der Weiterentwicklung des
Programms hervorrufen.
Da voraussichtlich vor allem der Hauptmenüpunkt „Analysis“ in Zukunft stetig wach-
sen wird, bieten sich zwei Alternativen an, diesem Prozess innerhalb der Menüstruktur
gerecht zu werden:
1. Der Hauptmenüpunkt „Analysis“ wird durch ein weiteres Untermenü ergänzt
(Abb. 10).
2. Es werden weitere Hauptmenüpunkte ergänzt (Abb. 11).
4 Eingeschlagener Realisierungsweg 31
Abb. 10: Eine mögliche Erweiterung der Hauptmenüpunkts „Analysis“ des FELIS-Analyst
Abb. 11: Eine mögliche Erweiterung des Hauptmenüs des FELIS-Analyst
5 Der FELIS-Analyst 32
5 Der FELIS-Analyst
In diesem Kapitel werden die einzelnen bereits funktionsfähigen Teilbereiche des FE-
LIS-Analysts vorgestellt. Dabei wird ein klar definiertes Schema für jedes der einzelnen
Skripte eingehalten, um einen strukturierten Überblick zu gewährleisten - Abb. 12 zeigt
dieses Schema.
Zu Beginn wird auf den eigentlichen Zweck des Skriptes eingegangen. Dabei wird ge-
nau beschrieben, was das Skript leisten kann, wo seine Grenzen liegen und warum es
für dieses Projekt von Bedeutung ist. Im zweiten Bereich, der auf den Aufbau des
Skripts eingeht, werden die einzelnen Funktionseinheiten des Skripts beleuchtet. In der
Regel bestehen fast alle Skripte aus mehreren Untereinheiten, die jeweils eine bestimm-
te Funktion erfüllen. Dies soll detailliert dargestellt werden. Flussdiagramme und
Schemata sollen bei komplexeren Skripten zum Verständnis beitragen. Als dritter und
letzter Punkt soll dann die jeweilige Entstehungsgeschichte kurz diskutiert werden. Was
für Probleme wurden während der Programmierung aufgeworfen, wurden sie gelöst und
mit welchen Mitteln? Gab es während der Entwicklung zentrale Änderungen im Skript?
Abb. 12: Alle unten stehenden Erklärungen der Skripte folgen dem abgebildeten Schema. Zu Beginn wird der Zweck des Skripts erläutert, dann wird auf den Aufbau des Skripts einge-gangen und schließlich folgt ein kurzer Abriss über die Entwicklungsgeschichte des Skripts. In wenigen Fällen ergänzt um Hintergrundinformationen zum Thema.
5 Der FELIS-Analyst 33
Dieses festgelegte Schema soll dazu führen, dass das Verständnis der einzelnen Skripte
auf die bestmöglichste Art und Weise garantiert werden kann. Dies ist von zentraler
Bedeutung, da der Anwender auf diesem Weg den persönlichen Nutzen des FELIS-
Analyst optimieren kann und zusätzlich die Grundlage für eventuelle Weiterentwick-
lungen geschaffen wird.
Bei einigen wenigen Skripten wurde die Gliederung durch einen Punkt „Hintergrundin-
formationen“ ergänzt, welcher theoretische Ergänzungen zum jeweiligen Thema liefert.
5.1 Der Rohdaten-Importer
Zweck
Der Zweck des Rohdaten-Importers liegt, wie der Name bereits sagt, im Import von
Rohdaten – genauer gesagt von Rohdaten im ASCII-Format.
Das ASCII-Format ist eine ursprünglich 7-bit-Zeichenkodierung, die demnach 2^7 =
128 unterschiedliche Zeichen darstellen kann. ASCII-Dateien werden auch oft mit .txt-
Dateien gleichgesetzt, da diese einfachen Textdateien ebenfalls häufig im ASCII-
Format gespeichert sind. Da die 128 Zeichen nur für einen normalen Schreibmaschinen-
satz an Zeichen reichen und spezielle Buchstaben wie z.B. Umlaute - wie sie u.a. in der
deutschen oder auch norwegischen Sprache üblich sind - damit nicht abgedeckt werden
können, gibt es heutzutage auch einige 8-bit-Zeichensätze, die auf dem ASCII-Format
basieren. Da im LiDAR-Bereich in der Regel keine Umlaute benötigt werden, können
diese Umstände vernachlässigt werden.
Abb. 13: Die grafische Schnittstelle des Rohdaten Importer
5 Der FELIS-Analyst 34
Der Rohdaten-Importer wandelt die im ASCII-Format gespeicherten Rohdaten in ein
ESRI Punkt–„Shapefile“ um. Dieser Vorgang bildet die Grundlage für alle weiteren
Schritte im FELIS-Analyst. Abb. 13 zeigt das Anwenderformular, welches nach Aufruf
des Importer im Menü erscheint. Dazu mehr im nächsten Abschnitt
Aufbau
Der Importer ist zusammen mit dem DGM-Berechnungs-Tool bis dato das komplexeste
der verwendeten Skripte im FELIS-Analyst. Der Aufbau lässt sich in zwei Bereiche
einteilen:
1. Ein Skript, welches rund um das Anwenderformular aufgebaut ist.
2. Ein weiteres Skript bzw. Modul, welches eigenständig ist und den Import nach
Klicken von „OK“ durchführt.
Das Anwenderformular:
Zuerst soll auf einige Details des ersten Bereichs eingegangen werden. Abb. 14 zeigt ein
Schema des Anwenderformulars und die darin enthaltenen Zusammenhänge. Besonders
interessant dabei ist, dass bereits die bloße Auswahl des „Input ASCII Files“ zwei wei-
tere Bereiche des Formulars beeinflusst: Zum Einen wird nach Auswahl des „Input-
files“ die sogenannte „working destination“ automatisch festgelegt, zum Anderen wird
Abb. 14: Rohdaten Importer: Das Formular und seine Zusammenhänge. Grüne Bereiche wer-den vom Anwender definiert, rote Bereiche vom Skript selbstständig ausgefüllt. Alle Zeilen die mit einem roten Kästchen markiert sind, liefern Eingangsparameter für das „Import Script“ welches nach Klicken des „OK“ – Buttons aufgerufen wird.
5 Der FELIS-Analyst 35
die erste Zeile der gewählten ASCII-Datei im Bereich „Preview“ (Vorschau) dargestellt.
Durch Klicken des Buttons „next“ kann der Anwender weitere nachfolgende Linien des
ASCII-Datei in den „Preview“ hinzufügen. Dies ist wichtig, um z.B. das Ende eines
etwaigen Dateikopfs („Header“) zu bestimmen, und dieses Ende dann als Eingabe für
den Bereich „Start Import in Line __ „ zu nutzen. Alle anderen Bereiche müssen durch
den Anwender spezifiziert werden und die Eingaben werden dann durch Klicken des
„OK“-Buttons vom Skript verarbeitet und an das Import-Skript, welches dem zweiten
Punkt in der obigen Gliederung entspricht, weitergeleitet.
Nach Klicken des „OK“-Buttons wird nun ein eigenständiges Modul innerhalb des
VBA-Projektes aufgerufen. Die Wahl, welches Modul gestartet wird, ist abhängig von
der Eingabe beim Bereich „My ASCII Files consists of x,y, z values and __ additional
values“. Je nachdem, wie viele zusätzliche Werte im Rohdatensatz in jeder Linie vor-
handen sind, wird entschieden welches Modul gestartet wird. Bevor der Fokus vollstän-
dig auf diese Module gelegt wird, soll an dieser Stelle noch ein Codebeispiel zum weite-
ren Verständnis der Skripte, die rund um das Anwenderformular programmiert wurden,
beitragen:
Function ExtractPathName(str_import_ascii_path) As String
' Returns the path from a filespec
Dim x As Variant
x = Split(str_import_ascii_path, "\")
ReDim Preserve x(0 To UBound(x) - 1)
ExtractPathName = Join(x, "\") & "\"
End Function
Code 3: Extraktion der „working destination“. Der in der Variable „str_import_ascii_path“ gespeicherte Pfad wird zuerst aufgeteilt und anschließend ohne den Dateinamen wieder zu-sammengesetzt. Daraus ergibt sich der gesuchte Pfad (= “working destination“)
Code 3 stellt eine Funktion dar, die aus einem vollständen Pfad zu einer Datei den Da-
teinamen beseitigt und somit nur den Pfad extrahiert. In Code 3 bedeutet das: Ange-
nommen die Funktion wird mit der folgenden Zeile aufgerufen:
in die Variable outRaster ein. Die Variable outRaster setzt sich aus dem im Formular
definierten Pfad, dem Dateinamen und eben der Erweiterung zusammen. Im Aufruf des
Tools, welches die eigentliche Berechnung durchführt, findet sich die Variable dann an
der Stelle des ausgehenden Bildes („outRaster“).
Call gp.Minus_sa(inRaster1, inRaster2, outRaster)
Der Aufbau des Tools in Umgangssprache übersetzt lautet gp.minus_sa(eingehende
Bilddatei Nr. 1 = DOM, eingehende Bilddatei Nr. 2 = DGM, resultierende (Output)
5 Der FELIS-Analyst 75
Bilddatei = nDOM). Die zwei eingehenden Bilddateien sind, wie in Code 8 zu erkennen
ist, mit den jeweiligen Feldern im Anwenderformular verknüpft.
Die Auflösung der resultierenden Bilddatei ergibt sich aus der Auflösung der eingehen-
den Bilddatei mit der niedrigeren Auflösung.
Geschichte
Wie auch bereits bei den beiden anderen Modulen zur Berechnung von digitalen Hö-
henmodellen war es auf Grund der großen Bedeutung selbiger im vorneherein klar, dass
das Modul Teil des FELIS-Analyst sein muss. Beim nDOM war die Entwicklung sehr
einfach, da die Berechnung des nDOM durch eine simple Subtraktion zweier Rasterda-
teien zu bewerkstelligen ist und diese Funktion standardmäßig in ArcMap zur Verfü-
gung steht.
5.7 Analysetools
Der Bereich der Analysetools innerhalb des FELIS-Analysts wurde geschaffen, um dem
Anwender nach der Berechnung der digitalen Höhenmodelle Möglichkeiten zu bieten,
diese weiterzuverarbeiten. Die in diesem Kapitel erläuterten Module beruhen alle auf in
ArcMap zur Verfügung stehende Tools. In der Weiterentwicklung des FELIS-Analysts
soll dieser Bereich stark ausgebaut werden. Die meisten, der in Kapitel 6 beschriebenen
geplanten Erweiterungen beziehen sich auf diesen Teil des Programms. An dieser Stelle
besprochen werden die Module:
1. Erstellung eines „Aspect-Images“
2. Erstellung eines „Slope-Images“
Abb. 33: Das nDOM Berechnungsformular
5 Der FELIS-Analyst 76
3. Erstellung eines „Hillshade-Images“
4. Erstellung von Höhenlinien
5. Der Export zu einem Google Earth kompatiblen Formats
5.7.1 Erstellung eines „Aspect-Images“
Zweck
Das „Aspect-Image“ berechnet auf Grundlage einer Rasterdatei die verschiedenen Rich-
tungen der Hangneigungen im Bild. Der Pixelwert innerhalb jeden Bildes gibt den Wert
des Kompasses in Grad an. Diese Funktion kann z.B. von großem Interesse sein, wenn
anhand eines DOMs, auf dem Hausdächer zu sehen sind, jene Dächer bestimmt werden
sollen, die aufgrund ihrer Südwestausrichtung ideal für den Einsatz von Solarkollekto-
ren geeignet sind.
Aufbau
Der Aufbau ist identisch mit dem des in Kapitel 5.4.1 besprochenen Skriptes.
Geschichte
Die Integration dieses Tools in den FELIS-Analysts wurde unter anderem durch die
Analyse der Struktur des LiDAR Analysts der Firma VLC angestoßen. Die in Kapitel
5.5 besprochenen Tools sind dort allesamt auch zu finden.
Die Entwicklung des Moduls verlief aufgrund des einfach aufgebauten Tools problem-
los.
Abb. 34: Beispiel eines berechneten „Aspect-Images“
5 Der FELIS-Analyst 77
5.7.2 Erstellung eines „Slope-Images“
Zweck
Das „Slope-Image“ berechnet auf Grundlage einer Rasterdatei die maximale Ände-
rungsrate zwischen einem Pixel und den benachbarten Pixeln. Es liefert damit als die
Hangneigung innerhalb jeden Pixels. Die Werte werden in Grad angegeben und reichen
von 0 bis 90°.
Das „Slope-Image“ kann z.B. hilfreich sein um den jeweiligen Charakter von DGMs
deutlicher hervorzuheben: Je geringer der Wert im „Slope-Image“ eines DGMs desto
flacher ist das Gelände. Auf ein DOM angewendet kann das resultierende Bild helfen,
um bestimmte Objekte auf der Erdoberfläche besser zu identifizieren. So werden z.B.
Häuser durch Linien aus Pixeln mit sehr hohen Werten umrandet, da die Steigung vom
Boden zum Ende der Hauswand hin i.d.R. 90° betragen sollte
Aufbau
Der Aufbau ist identisch mit dem des in Kapitel 5.4.1 besprochenen Skriptes.
Geschichte
Siehe „Aspect-Image“
5.7.3 Erstellung eines „Hillshade-Images“
Zweck
Das „Hillshade-Image“ erstellt ebenfalls basierend auf einer Rasterdatei ein Bild, wel-
ches die Beleuchtung des Eingangsbildes durch eine punktuelle Lichtquelle simuliert.
Das bedeutet, es werden Lichtintensitäten und auf Wunsch Schattenwürfe berechnet, die
dem Bild ein natürlicheres Aussehen verleihen. Das kann bei einem DGM z.B. dazu
führen das mehr Details wie Wege oder kleinere Verwerfungen erkennbar werden. Der
Anwender kann für die Lichtquelle einen Richtungs- und Höhenwinkel eingeben. Zu-
sätzlich muss er angeben, ob Schatten innerhalb des berechneten Bildes dargestellt wer-
den, andernfalls werden nur die Belichtungsintensitäten berücksichtigt. Als letztes muss
der Anwender einen z-Faktor festlegen. Dieser z-Faktor steht für das Verhältnis zwi-
schen Zellgröße des Eingangsbildes und des resultierenden Bildes. Ein z-Faktor von 2
würde bedeuten, dass wenn das Eingangsbild eine Auflösung von 1m hat, das resultie-
rende Bild mit einer Auflösung von 2m berechnet werden würde.
Aufbau
Der Aufbau ist identisch mit dem des in Kapitel 5.4.1 besprochenen Skriptes.
5 Der FELIS-Analyst 78
Geschichte
Während der Implementierung des Moduls kam es zu Beginn zu kleineren Problemen,
da einige der Angaben im Anwenderformular optional sind. Diese wurden durch kleine
Änderungen im Skript schnell behoben.
5.7.4 Erstellung von Höhenlinien
Zweck
Die Erstellung von Höhenlinien ist eine in der Geografie weit verbreitete Methode um
die Höhenunterschiede innerhalb einer topografischen 2D-Darstellung zu illustrieren.
Innerhalb des FELIS-Analysts helfen die Höhenlinien z.B. die Höhenunterschiede in-
nerhalb eines DGMs darzustellen. Das ist insbesondere deswegen interessant, da in den
Darstellungen von ArcMap die unterschiedlichen Farbdarstellungen für unterschiedliche
Höhenwerte standardmäßig relativ zu der Spanne der Höhenwerte dargestellt werden.
D.h. es kann sein, dass ein DGM, welches Höhenwerte zwischen 100 und 110 m dar-
stellt, genau gleich aussieht wie ein DGM, das Höhenwerte zwischen 1000 und 1100 m
darstellt. Höhenlinien können helfen solche Verwechslungen eindeutig zu vermeiden.
Aufbau
Der Aufbau ist identisch mit dem des in Kapitel 5.4.1 besprochenen Skriptes.
Geschichte
Siehe „Aspect-Image“
Abb. 35: Beispiel für ein berechnetes „Hillshade-Image“.
5 Der FELIS-Analyst 79
5.7.5 Export zu Google Earth
Zweck
Wie der Name bereits sagt, ermöglicht diese Funktion Daten aus ArcMap zu exportieren
und diese anschließend in Google Earth zu visualisieren. Die Daten müssen als Layer-
dateien vorliegen (.lyr-Dateien). Diese Funktion kann z.B. hilfreich sein um aus Li-
DAR-Daten extrahierte Gebäude oder andere Objekte in einem größeren Kontext zu
visualisieren.
Aufbau
Der Aufbau ist identisch mit dem des in Kapitel 5.4.1 besprochenen Skriptes.
Geschichte
Siehe „Aspect-Image“
5.8 Extraktionstools
Im Rahmen einer 6-wöchigen Hausarbeit erstellte David Montwe eine umfangreiche
Sammlung an Extraktionstools für den FA. Die Arbeitsweise der Tools wurde bisher
nicht wissenschaftlich überprüft, aber sie bieten eine ideale Ausgangssituation für die
zukünftige Weiterentwicklung.
Abb. 36: Beispiel für berechnete Höhenlinien. Im Hintergrund ist ein Digitales Geländemodell zu sehen. Die Höhenlinien wurden zusätzlich mit einer Farbskalierung und einem Label, wel-ches die Höhe angibt, versehen.
5 Der FELIS-Analyst 80
Die Sammlung umfasst folgende Tools:
1. Extraktion von Waldgebieten
2. Extraktion von Gebäudegrundrisse
3. Extraktion von Baumspitzen
4. Extraktion von Vegetation in urbanem Gebiet
5. Extraktion von Waldstrukturen (Beständen)
Abb. 34 zeigt den FA um ein Hauptmenü „Extraction“ erweitert, welches die eben be-
schriebenen Tools beinhaltet. Damit wurde der in Abb. 11 vorgeschlagene Weg zur Er-
weiterung des FA eingeschlagen. Genauere Informationen zu den genannten Tools fin-
den sich bei Montwe (2009).
Für die Verwendung der genannten Tools ist eine ArcInfo-Lizenz mit aktiviertem Spati-
al- und 3D-Analyst Voraussetzung.
5.9 Hilfefunktionen
Zur Vervollständigung des Softwarepakets wurde am Ende des Projekts eine Hilfedatei
im HTML-Format erstellt. Die Hilfedatei kann für jedes Modul individuell durch einen
Hilfe-Button (illustriert in Abb. 38) direkt aus dem jeweiligen Anwenderformular ge-
startet werden. Zusätzlich besteht die Möglichkeit über das Menü „Help“ im FELIS-
Analyst mit dem Eintrag „Help“ auf alle Hilfetexte für alle Module zuzugreifen. Der
Aufruf des Eintrags leitet auf eine Internetseite, auf der sämtliche Hilfetexte in einer
Gliederung aufgeführt sind (Abb. 39). Ebenfalls über das Menü „Help“ lassen sich über
den Eintrag „License“ Informationen zur aktuell geladenen Lizenz aufrufen. Als letzten
Punkt bietet das Menü mit dem Eintrag „Tutorial“ einen Verweis auf eine Internetseite,
auf der sowohl ein Tutorial im .pdf-Format als auch eine .zip-Datei mit einem Beispiel-
datensatz zur Verfügung steht. Das Tutorial findet sich auch im Anhang B dieses Tex-
tes, der Beispieldatensatz findet sich auf der beigefügten CD-ROM.
Abb. 37: Der FA erweitert um das Menü „Extraction“ mit den Tools zur Extraktion von Wald, Gebäudegrundrissen, Vegetation, Baumspitzen und Waldstrukturen
5 Der FELIS-Analyst 81
Abb. 38: Der Hilfe-Button im Anwenderformular zur Normalisierung von Rohdaten.
Abb. 39: Die Online Hilfe des FELIS-Analyst
6 Die Weiterentwicklung - Geplante Module für den FELIS-Analyst 82
6 Die Weiterentwicklung - Geplante Module für den
FELIS-Analyst
In diesem Kapitel sollen die bereits geplanten Erweiterungen für den FELIS-Analyst
kurz vorgestellt werden. Ideen für Erweiterungen lassen sich aus den unterschiedlich-
sten Quellen ableiten. Zum Einen sind wiederum die bereits bestehende LiDAR-
Erweiterungen für ArcMap LP360 und der LiDAR Analyst zu nennen, zum Anderen
geben auch die institutseigene Software TreesVis, sowie andere LiDAR Software wie
Fusion Impulse für Weiterentwicklungen. Zusätzlich ist auch die forstliche Ausrichtung
der Abteilung FELIS zu berücksichtigen, die natürlich die Weiterentwicklung des FE-
LIS-Analysts ebenfalls beeinflussen wird.
Im Folgenden finden sich Ideen, die theoretisch in ArcMap bzw. zumindest im Zusam-
menhang mit weiterer ESRI-Software umzusetzen sein müssten und den Funktionsum-
fang und damit auch den Nutzen des FELIS-Analysts drastisch erweitern würden.
6.1 3D-Visualisierung
Inspiriert von TreesVis wäre eine 3D-Visualisierung sowohl der Rohdaten als auch der
Geländemodelle denkbar. Die Umsetzung müsste vermutlich innerhalb von ArcScene
stattfinden. Grundsätzlich sind alle Visualisierungsthematiken sehr komplex und stellen
oftmals hohe Ansprüche an die Programmierung, um Funktion und Performance zu ver-
einbaren.
3D-Visualisierung von Punktewolken, die aus mehreren Millionen Punkten bestehen
sind enorm rechenintensiv und können nur dargestellt werden, wenn Wege gefunden
werden immer nur einen Teil der Daten zu verarbeiten. Ob dies mit den ESRI-
Produkten in einer mit TreesVis vergleichbaren Art und Weise möglich ist, wird die
Zukunft zeigen.
Die Chancen, die eine Visualisierung in 3D bietet, liegen auf der Hand: Evaluierungen
von Analyseresultaten sind in 3D genauer zu realisieren, da oftmals bereits das Auge
Fehler erkennen kann, wenn die Daten entsprechend visualisiert werden. Zusätzlich
bietet eine 3D-Darstellung einen enormen Zugewinn an Attraktivität bezüglich jeglicher
Form von Präsentation. Sowohl Planungsvorhaben, als auch die Präsentation von For-
schungsergebnissen werden plastischer und für Experten wie Laien deutlich greifbarer.
6 Die Weiterentwicklung - Geplante Module für den FELIS-Analyst 83
6.2 Extraktion von Gebäuden
Die Extraktion von Gebäuden ist in der LiDAR-Forschung ein zentrales Thema. Die
daraus abgeleiteten 3D-Stadtmodelle sind insbesondere in großen Städten in vielerlei
Hinsicht gern gesehene und hilfreiche Planungshilfen: Die Auswirkungen eines geplan-
ten Neubaus werden durch Stadtmodelle schnell sichtbar. So kann sichergestellt werden,
dass die für die jeweilige Stadt typische Struktur und die Aussicht auf Wahrzeichen wie
Kirchen, Denkmäler etc. nicht verbaut wird.
Zusätzlich können - wie bereits bei der 3D-Visualisierung angesprochen – 3D-
Stadtmodelle helfen bei geplanten Bauprojekten unschlüssige Entscheidungsträger zu
überzeugen. Die Möglichkeit das neu gebaute Objekt in der den Entscheidungsträgern
bekannten Umgebung darzustellen kann helfen etwaige Zweifel auszuräumen.
Technisch umsetzbar ist die automatische Extraktion von Gebäuden vor allem durch die
für Gebäude typische Struktur. Gebäude stehen oft auf einem relativ flachen Grund und
die Wände verlaufen vertikal nach oben. Dazu kommen oftmals symmetrische Dach-
strukturen und für Gebäude typische Flächengrößen und Höhen. Anhand dieser Parame-
ter ist es möglich aus einem DOM anhand eines Algorithmus entweder die Umrandun-
gen oder sogar die 3D-Modelle der Gebäude zu extrahieren.
Aktuell wird im Rahmen einer Doktorarbeit an der Abteilung FELIS ausführlich an die-
sem Thema gearbeitet. Das Integrieren des dabei entwickelten Know-How in den FE-
LIS-Analyst könnte in absehbarer Zeit realisiert werden.
Die Gebäudegrundrisse können beim aktuellen Stand des FA bereits anhand eines von
David Montwe entwickelten Skripts extrahiert werden.
6.3 Extraktion von Waldbeständen
Die Extraktion von Waldbeständen ist ebenfalls ein häufig anzutreffendes Forschungs-
gebiet innerhalb der LiDAR-Szene, genauer gesagt der forstlichen LiDAR-Szene. Dabei
kann die Extraktion von Waldbeständen unterteilt werden in:
1. Die Extraktion von Wald allgemein im Vergleich zu Stadt, Offenland und Ge-
wässer (im aktuellen Stand des FA bereits im Menü „Extraction“ vorhanden).
2. Die Extraktion einzelner voneinander abgegrenzter Bestände innerhalb eines zu-
sammenhängenden Waldes
Die Extraktion von Wald allgemein ist gleichzeitig auch die Vorstufe für den zweiten
genannten Punkt. Die Extraktion einzelner Bestände kann anhand unterschiedlicher Pa-
rameter stattfinden. Beispiele hierfür sind:
6 Die Weiterentwicklung - Geplante Module für den FELIS-Analyst 84
• Trennung nach unterschiedlichen Höhenstufen
• Trennung nach Nadel / Laubwald
• Trennung nach Baumarten
• Trennung nach geografischen Grenzen, wie z.B. Waldwege, Flüsse, Bäche, etc.
Die technische Umsetzung der jeweiligen Extraktionsverfahren ist sehr unterschiedlich.
So ist die Trennung nach unterschiedlichen Höhenstufen vermutlich die einfachste. An-
hand des nDOMs werden die Waldflächen mit einem Algorithmus systematisch abge-
tastet und Flächen, die ähnliche Baumhöhen zeigen und zusammenhängend sind, wer-
den zu Beständen zusammengefasst.
Die Trennung von Laub und Nadelwald kann z.B. durch den Vergleich von zwei DOMs
erreicht werden – ein LP-DOM und ein FP-DOM. Zieht man das LP-DOM vom FP-
DOM ab so werden die Bereiche, in denen Nadelwald vorliegt, Werte gegen 0 besitzen
(da hier zwischen FP- und LP-DOM aufgrund der Dichte der Nadeln kaum Unterschie-
de bestehen) wohingegen Bereiche, in denen Laubwald vorliegt deutlich höhere Werte
aufweisen (da das FP-DOM deutlich höher ist als das LP-DOM, welches in den weniger
dichten Laubbäumen mehr Boden- und Zwischenpunkte in die Interpolation einbezie-
hen wird) .
Die genannten Beispiele zeigen, dass zu Beginn jeder technischen Umsetzung die Frage
steht, anhand welcher durch LiDAR-Daten gelieferten Parameter die jeweilige Frages-
tellung gelöst werden kann. Die Umsetzung selbst ist dann oftmals noch weitaus komp-
lexer und die Grenzen, die ArcMap durch seine gegebenen Funktionen vorgibt, setzen
oftmals ein großes Maß an Kreativität und Ausdauer voraus.
6.4 „Solarzellen-Modul“
Zeitgleich mit der hier vorliegenden Arbeit wird am FELIS-Institut im Rahmen einer
weiteren Diplomarbeit ein Modul zur automatischen Erfassung von Dächern, die für die
Montage von Solarzellen geeignet sind, entwickelt.
Das Modul berechnet anhand von Tageszeit und geografischer Position den Sonnen-
stand über das gesamte Jahr. Zusätzlich erfasst das Modul die Ausrichtung und Neigung
der Hausdächer innerhalb des Testgebietes.
Mit diesen beiden Komponenten in Verbindung mit meteorologischen Statistiken (Son-
nenstunden pro Jahr an der jeweiligen Position) lassen sich die für Solarzellen geeigne-
ten Dachschrägen extrahieren.
Ein solches Modul kann dazu beitragen den Ausbau der erneuerbaren Energien voran-
zutreiben. Städte und Gemeinde könnten Karten veröffentlichen, die die geeigneten Dä-
cher zeigen und damit unwissende oder kritische Bürger davon überzeugen, dass sich
6 Die Weiterentwicklung - Geplante Module für den FELIS-Analyst 85
der Ausbau lohnt. In Zusammenarbeit mit handwerklichen Betrieben könnten finanziel-
le Fördermaßnahmen diese Entwicklung zusätzlich beschleunigen.
6.5 Erweiterungen der Schnittstellen
Wie bereits bei der Besprechung des ASCII-Importers angedeutet wurde, waren bei der
ursprünglichen Planung des FELIS-Analysts Import und Exportfunktionen für mehrere
Dateiformate vorgesehen. Zusätzlich sollte ein Konvertierungsprogramm den problem-
losen Wechsel zwischen verschiedenen Formaten ermöglichen.
Da im Rahmen dieser Arbeit eine generelle Grundlage geschaffen werden sollte, die
nicht nur den Bereich Import und Export abdeckt, finden sich diese Ziele nun im Kapi-
tel der geplanten Weiterentwicklungen. Insbesondere die Unterstützung des .las Format
sollte angestrebt und auch der problemlose Austausch des FELIS-Analysts mit TreesVis
muss vorangetrieben werden.
7 Zusammenfassung und Resümee 86
7 Zusammenfassung und Resümee
Im Rahmen dieser Arbeit wurde eine LiDAR-Erweiterung für ArcMap anhand von Vi-
sual Basic und ArcObjects erstellt. Die Erweiterung mit Namen FELIS-Analyst ist in
einem ArcMap-Dokument (.mxd) gespeichert und kann bisher nicht durch eine separate
Installation in das Programm ArcMap selbst eingebunden werden. Für diese Art von
Einbindung müssten andere, komplexere Programmiersprachen wie z.B. C++ herange-
zogen werden.
Der FELIS-Analyst bietet in der aktuellen Version einen voll funktionsfähigen ASCII-
Importer, Module zur Berechnung von digitalen Oberflächenmodellen sowie einige ein-
fache Analyse- und Exportfunktionen.
Für die Erstellung des FELIS-Analysts wurden zum Teil bereits vorhandene Tools von
ArcMap sowie frei verfügbare Skripte verwendet. Zusätzlich wurden einige Programm-
teile komplett eigenständig programmiert. Die in ihren Grundzügen leicht erlernbare
Kombination aus Visual Basic und des auf der COM-Technologie von Microsoft basie-
rende ArcObjects ermöglichte eine schnelle Umsetzung vieler Ziele, auch ohne Vor-
kenntnisse im Bereich Programmierung.
Das Ziel, eine Grundlage für ein in ArcMap integriertes LiDAR-Software zu erschaffen,
wurde erreicht. Es ist erstaunlich, dass viele grundlegende Forderungen, die zu Beginn
der Arbeit an ein leistungsstarkes und benutzerfreundliches LiDAR-Modul gestellt wur-
den, innerhalb der recht kurzen Zeitspanne umgesetzt werden konnten. Der FELIS-
Analyst befindet sich allerdings immer noch in der Entwicklungsphase und kann noch
nicht kommerziell vermarktet werden. Dennoch könnte das Projekt – bei konsequenter
Weiterentwicklung – stetig an Bedeutung gewinnen. Der Markt für Softwareprodukte
dieser Art ist noch nicht vollständig abgedeckt und insbesondere der forstliche Bereich
bietet große Chancen.
Anhang A: Details zur „Spline-Interpolation“ 87
Anhang A: Details zur „Spline-Interpolation“ .
How Spline works
The basic form of the minimum curvature Spline interpolation imposes the following two conditions on the interpolant:
• The surface must pass exactly through the data points.
• The surface must have minimum curvature—the cumulative sum of the squares of the second derivative terms of the surface taken over each point on the surface must be a minimum.
The basic minimum curvature technique is also referred to as thin plate interpolation. It ensures a smooth (continuous and differen-
tiable) surface, together with continuous first-derivative surfaces. Rapid changes in gradient or slope (the first derivative) can occur
in the vicinity of the data points; hence, this model is not suitable for estimating second derivative (curvature).
The basic interpolation technique can be applied by using a value of zero for the {weight} argument to the Spline function.
The REGULARIZED option modifies the minimization criteria so third-derivative terms are incorporated into the minimization
criteria. The {weight} argument specifies the weight attached to the third-derivative terms during minimization, referred to as tau in
the literature. Higher values of this term lead to smoother surfaces. Values between 0 and 0.5 are suitable. Using the REGULA-
RIZED option ensures a smooth surface together with smooth first-derivative surfaces. This technique is useful if the second deriva-
tive of the interpolated surface needs to be computed.
The TENSION option modifies the minimization criteria so first-derivative terms are incorporated into the minimization criteria.
The {weight} argument specifies the weight attached to the first-derivative terms during minimization, referred to as phi in the
literature. A weight of zero results in the basic thin plate Spline interpolation. Using a larger value of weight reduces the stiffness of
the plate, and in the limit as phi approaches infinity, the surface approximates the shape of a membrane, or rubber sheets, passing
through the points. The interpolated surface is smooth. First derivatives are continuous but not smooth.
The Spline function uses the following formula for the surface interpolation:
where:
j = 1, 2, ..., N
N is the number of points.
λj are coefficients found by the solution of a system of linear equations.
rj is the distance from the point (x,y) to the jth point.
T(x,y) and R(r) are defined differently, depending on the selected option.
For the REGULARIZED option:
T(x,y) = a1 + a2x + a3y
and for the TENSION option:
T(x,y) = a1
where:
and are the parameters entered at the command line.
r is the distance between the point and the sample.
is the modified Bessel function.
c is a constant equal to 0.577215.
are coefficients found by the solution of a system of linear equations.
For computational purposes, the entire space of the output raster is divided into blocks or regions equal in size. The number of
regions in x and in y directions are the same, and they are rectangular in shape. The number of regions is determined by dividing the
total amount of points in input point dataset by the value specified for the number of points. For data less uniformly distributed, the
regions may contain a significantly different number of points, with the value for the number of points being only the rough aver-
age. If in any region, the number of points is smaller than eight, the region is expanded until it contains a minimum of eight points.
Quelle: ArcGIS Desktop Help
Anhang B: Tutorial for FELIS-Analyst Version 1.0 88
Anhang B: Tutorial for FELIS-Analyst Version 1.0
Introduction
This tutorial will help the reader to understand and use all functions of the FELIS-
Analyst in the Version 1.0. All steps follow a logical and hierarchic structure. This tu-
torial should be seen as an addition to the diploma thesis “Erstellung eines LiDAR
Moduls in ArcMap anhand von VBA und ArcObjects”. The example dataset used in this
tutorial is delivered with your version of the FELIS-Analyst.
Step 1: Starting the FELIS-Analyst
In the first step you will start the FELIS-Analyst (FA). Since the FA is not a stand-alone
program but included in an .mxd-file you will have to open the file “FE-
LIS_Analyst.mxd” with a double click or by selecting “File” ���� “open” in the main
window of ArcMap. Fig. 1 shows ArcMap after you loaded the just mentioned file. The
FA menu is marked with the red rectangle. Click on this menu and select “Raw Data”
���� “Import” to reach step 2.
Fig. 1: ArcMap after starting FELIS_Analyst.mxd
Anhang B: Tutorial for FELIS-Analyst Version 1.0 89
Step 2: Import of Raw Data
The import of raw data is a very important step. After you clicked the “Import” -button
in the menu a new window will appear – illustrated in Fig. 2.
In Fig. 2 the form is already filled out. To reach this point we will first of all have to
press the browse-button with the little sign, next to the input-line titled “Input AS-
CII file ”. A new dialogue will pop up. Within this dialogue we browse to our input-file
with the name “34205325_fp_ground.asc” select it and click “OK” . After this, the lines
“Working destination” and also the first line in the “Preview” will be added automati-
cally. To add more lines to the “Preview” we can press the “next” button on the bottom
of the form.
In the “Preview” we can see that our data consists of three numbers – x, y and z-values.
Therefore we choose “0 additional values” in the input line “My ASCII file consists of
X,Y,Z values and __ additional values”. We can also see in the “Preview” that the
three number are separated by space. So we choose “space” in the input-line “The lines
of my ASCII file are separated by ________”. At last one has to define a name for the
resulting shapefile in the line “Output filename” for example “fp_ground”.
After this we press “OK”.
Now the import of the raw data will start. Depending on the speed of your computer and
the size of the imported file this may take a few seconds to several minutes. After the
�
Fig. 2: The import function of the FA
Anhang B: Tutorial for FELIS-Analyst Version 1.0 90
import has finished, ArcMap will prompt a message that says “Import was successful”.
Fig. 3 shows ArcMap after the successful import. The color of your points may differ
from the one in the picture. The color is selected randomly by ArcMap.
After this we repeat the whole procedure with the three other input-files:
“34205325_fp_vegetation.asc”, “34205325_lp_ground.asc” and
“34205325_lp_vegetation”. All datasets will be needed in later calculation procedures.
Step 3: Georeference Raw Data Points.
In the next step we will choose a coordinate system for our just imported raw data
points. This procedure is rather simple. To do this we select “Raw Data” ���� “Georefe-
rencing” from the FA menu. After this a new window will appear. As we can see in
Fig. 4 we only have to define two inputs. First we have to define the shapefile that we
want to georeference. This is the just created point-shapefile named “fp_ground.shp”
and second we have to define a coordinate system.
To define the shapefile we press the -button next to the “Input Feature Class /
Shapefile” line, browse to our file, select it and press “ok” or we use the drop down
menu to select one of the shapefiles that are actually loaded in the view. Then we
choose the coordinate system by clicking the -button next to the “Define Coordi-
nate System” line. Depending on the installation path of your version of ArcMap you
Fig. 3: ArcMap after the import of your first file
Anhang B: Tutorial for FELIS-Analyst Version 1.0 91
will be directly in the correct folder where the coordinate systems are stored, or you