Erstellung eines LiDAR-Moduls für ArcMap anhand von VBA ... · Erstellung eines LiDAR-Moduls für...

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

Programmpakets lautet „FELIS-Analyst“.

Schlagwörter: LiDAR, ArcMap, ArcGIS, Geografisches Informationssystem, ArcOb-

jects, Visual Basic for Application

Abstract

A thesis on how to create a LiDAR software module for ArcMap is presented. The the-

sis shows the creation of a program that offers several possibilities to process and visu-

alize LiDAR data, by using on the one hand already existent tools and scripts and on the

other hand individually created code. Most of the work was done in “Visual Basic for

Application” and “ArcObject”. The developed software includes several functional

modules for example an ASCII-Importer, a module to calculate digital elevation models

and also several options to select and georeference LiDAR raw data. The working title

of this program package is “FELIS-Analyst”.

Keywords: LiDAR, ArcMap, ArcGIS. Geographic Information System, ArcObjects,

Visual Basic for Application

Inhaltsverzeichnis 3

Inhaltsverzeichnis

Kurzfassung ..................................................................................................................... 2

Abstract ............................................................................................................................ 2

Inhaltsverzeichnis ........................................................................................................... 3

Abbildungsverzeichnis .................................................................................................... 5

Tabellenverzeichnis ........................................................................................................ 6

Codeverzeichnis .............................................................................................................. 7

Abkürzungsverzeichnis .................................................................................................. 8

Vorwort ............................................................................................................................ 9

1 Überblick ............................................................................................................ 10

2 Ziele ..................................................................................................................... 12

3 Stand der Technik ............................................................................................. 13

3.1 Software ............................................................................................................... 13

3.2 LiDAR-Technik allgemein .................................................................................. 14

4 Eingeschlagener Realisierungsweg .................................................................. 18

4.1 Die COM-Technologie in ArcObjects ................................................................. 19

4.2 Integration und Adaption bestehender Skripte .................................................... 24

4.3 Nutzung von Werkzeugen der Toolbox .............................................................. 25

4.4 Erstellung eigener Skripte ................................................................................... 27

4.5 Die Erstellung der Benutzeroberfläche ............................................................... 28

5 Der FELIS-Analyst ............................................................................................ 32

5.1 Der Rohdaten-Importer ....................................................................................... 33

5.2 Normalisieren von Rohdaten ............................................................................... 43

5.3 Verschmelzen von Rohdaten ............................................................................... 45

5.4 Georeferenzierungsoptionen für Rohdaten und digitale Höhenmodelle ............. 46

5.4.1 Rohdaten .............................................................................................................. 47

5.4.2 Digitale Höhenmodelle – DOM, DGM, nDOM .................................................. 52

5.5 Selektion von Rohdaten ....................................................................................... 53

5.6 Berechnung digitaler Höhenmodelle ................................................................... 55

5.6.1 DOM .................................................................................................................... 56

Inhaltsverzeichnis 4

5.6.2 DGM .................................................................................................................... 61

5.6.3 nDOM .................................................................................................................. 73

5.7 Analysetools ........................................................................................................ 75

5.7.1 Erstellung eines „Aspect-Images“ ....................................................................... 76

5.7.2 Erstellung eines „Slope-Images“ ......................................................................... 77

5.7.3 Erstellung eines „Hillshade-Images“ ................................................................... 77

5.7.4 Erstellung von Höhenlinien ................................................................................. 78

5.7.5 Export zu Google Earth ....................................................................................... 79

5.8 Extraktionstools ................................................................................................... 79

5.9 Hilfefunktionen .................................................................................................... 80

6 Die Weiterentwicklung - Geplante Module für den FELIS-Analyst ............ 82

6.1 3D-Visualisierung ................................................................................................ 82

6.2 Extraktion von Gebäuden .................................................................................... 83

6.3 Extraktion von Waldbeständen ............................................................................ 83

6.4 „Solarzellen-Modul“ ............................................................................................ 84

6.5 Erweiterungen der Schnittstellen ......................................................................... 85

7 Zusammenfassung und Resümee ..................................................................... 86

Anhang A: Details zur „Spline-Interpolation“ .......................................................... 87

Anhang B: Tutorial for FELIS-Analyst Version 1.0 ................................................. 88

Anhang C: Hard- und Softwarevoraussetzungen .................................................... 110

Glossar ......................................................................................................................... 111

Literaturverzeichnis ................................................................................................... 112

Erklärung .................................................................................................................... 113

Stichwortverzeichnis ................................................................................................... 114

Abbildungsverzeichnis 5

Abbildungsverzeichnis Abb. 1: Screenshot aus der Software Fusion des US Forest Service .............................. 11

Abb. 2: Eine LiDAR – 3D-Punktwolke (Darstellung aus TreeVis) ............................... 15

Abb. 3: Ein Laserstrahl trifft auf ein Blatt und wird teilweise reflektiert ....................... 16

Abb. 4: Drei mögliche Wege eines Laserstrahls ............................................................. 17

Abb. 5: Illustration Beispielprogramm. .......................................................................... 19

Abb. 6: Die Zusammenhänge zwischen den Klassen. .................................................... 21

Abb. 7: Beispiel für zwei Interfaces der Klasse Baum ................................................... 22

Abb. 8: Interface Symbole .............................................................................................. 23

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. 22: Überblick Selektionstool .................................................................................. 54

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

Dateiformaten (LAS, XYZ-ASCII, Point-„Shapefile“, Microstation dgn, Auto-

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.


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


(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)


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


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.


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


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-


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.


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


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.


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-


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-


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

Private Sub fr_CommandButton1_Click()

'define input and output variables

Dim str_extension1

Str_extension1 = create.hill.txt_extension

Dim InRaster As String

Dim outRaster As String

InRaster = create_hill.txt_inputraster_hill

outRaster = create_hill.txt_outputfolder_hill & "\" & create_hill.txt_Filename & str_extension1

Dim z As Double

z = CDbl(create_hill.Txt_z)

Dim InAzimuth As Double

Dim InAltitude As Double

InAzimuth = CDbl(create_hill.txt_azimuth.Text)

InAltitude = CDbl(create_hill.txt_altitude.Text)

' create the geoprocessor

Dim gp As Object

Set gp = CreateObject("esriGeoprocessing.GPDispatch.1")

'call the hillshade tool from the spatial analyst toolbox

Call gp.HillShade_sa(InRaster, outRaster, InAzimuth, InAltitude, str_shadow, z)

'unload and hide the form

create_hill.Hide

Unload create_hill

End Sub

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.


„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

Zuordnung: Inraster = create_hill.txt_inputraster_hill

Das bedeutet, dass das Skript der Variablen „InRaster“ den Inhalt des Textfeldes

„txt_inputraster_hill“ aus dem Anwenderformular mit dem Namen „create_hill“ zu-

weist. Ähnlich wird auch bei den anderen Variablen vorgegangen.

Nachdem alle Variablen definiert sind, erfolgt die Initialisierung des Geoprocessors.

Dies erfolgt mit den immer gleich bleibenden zwei Zeilen:

Dim gp As Object


Nach diesen zwei Zeilen ist der Geoprozessor gestartet und alle Tools der Toolbox kön-

nen aufgerufen werden. Der Aufruf der Toolbox erfolgt durch Verwendung der Zeile:

Call gp.HillShade_sa(Inraster, outRaster, InAzimuth, InAltitude, str_shadow, z)

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?


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


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).


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).


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.


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


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.


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:

Call ExtractPathName(„C:\Beispiel\Beispiel2\Beispiel3.asc“)

Dann würde der Code anhand der VBA-Funktion Split den angegebenen Pfad

„C:\Beispiel\Beispiel2\Beispiel3.asc“ an jedem „\“ trennen und die jeweiligen Teilstü-

cke in die Variable x abspeichern. Demnach wäre x(0) = „C:“ , x(1) = „\Beispiel“, x(2)

= „\Beispiel2“ und x(3) = „\Beispiel3.asc“.


Anschließend folgt die Beseitigung des letzten Gliedes anhand der Zeile:

ReDim Preserve x(0 To UBound(x) - 1)

Der Befehl erhält alle x-Teile von 0 bis zum oberen Ende (in unserem Fall = 3) minus 1.

Anschließend wird mit der letzten Zeile das fehlende „\“ wieder ergänzt und das Ergeb-

nis als String ausgegeben.

Dieser Code wird verwendet, um nach der Definition des „Input-ASCII-Files“ die

„working destination“ automatisch zu bestimmen. Weitere ähnliche Skripte sorgen z.B.

dafür, die erste Linie der eingehenden ASCII-Datei in das Vorschaufenster (Preview) zu

laden oder auch um den Pfad der ausgehenden Datei automatisch zu bestimmen.

Das Import-Skript:

Das Import-Skript besteht wiederum aus diversen kleinen Einheiten, die nacheinander

durchlaufen werden. Abb. 15 zeigt einen Überblick.

Abb. 15 ist jedoch nicht vollständig. Einige kleinere Teile des Codes werden nicht er-

wähnt. Dazu gehören u.a. Teile, die die Statusleiste im Formular updaten, sowie Code-

teile, die für das Erscheinen von Fehlermeldungen zuständig sind.

Oben wurde erwähnt, dass unterschiedliche Module für den Import existieren und die

Anzahl der zusätzlichen Attribute im Rohdatensatz entscheidend ist für die Wahl des

Moduls. Alle diese Module besitzen einen identischen Aufbau, der einzige Unterschied

liegt darin, dass bei den Modulen für Rohdaten mit zusätzlichen Attributen jeweils zu-

Abb. 15: Das Import-Skript im schematischen Überblick


sätzliche Variablen und dazu passende Spalten in den „Shapefiles“ erstellt werden müs-

sen. Im Abschnitt „Geschichte“ des Importmoduls wird auf diese Problematik noch

einmal kurz eingegangen.

1. Definition der Eingangsparameter

Ganz zu Beginn des Import-Skripts stehen die Erstellung der Variablen und das Füllen

der Variablen mit Inhalten. Dabei werden sowohl Variablen erstellt, welchen die Einga-

ben des Anwenderformulars zugewiesen werden, als auch Variablen (i.d.R. Arrays), die

später dazu dienen werden, die aus der ASCII-Datei gelieferten LiDAR-Rohdaten auf-

zunehmen.

Zu erwähnen ist hier, dass die Wahl der richtigen Art von Variablen allgemein von

größter Bedeutung ist. Während es sich bei den Variablen, welche die Formulareinga-

ben aufnehmen sollen, in der Regel um einfache Variablen eines bestimmten Datentyps

handelt (häufig „string“ (z.B. für alle Dateipfade) aber auch numerische Datentypen wie

„double“ (z.B. für die Definition von Zellgrößen etc.)), müssen die Variablen, die die

Rohdaten aufnehmen sollen, als Array gespeichert sein. Ein Array entspricht einer Mat-

rix mit vom Anwender definiertem Ausmaß. In einen Array kann eine vom Anwender

vorgegebene Menge an Einträgen gespeichert werden. Auf die einzelnen Einträge kann

dann in der Regel durch eine laufende Nummerierung zugegriffen werden. So entspricht

z.B. der fünfte Eintrag in einem Array mit Namen x dem Begriff x(4). Die 4 zwischen

den Klammern ergibt sich daraus, dass der erste Eintrag in der Regel durch x(0) defi-

niert ist.

2. Laden der Textdatei

Nachdem alle nötigen Variablen erstellt und definiert wurden, erfolgt das Laden der

Textdatei. Dazu wird zu allererst der Zugriff auf die Textdatei durch einen VBA-Befehl

erstellt. Dann liegt die Textdatei geöffnet vor und kann verarbeitet werden. Das Skript

liest anschließend jede Zeile der Textdatei einzeln, splittet den Inhalt der Zeile auf und

speichert die Teile in die jeweils passenden Arrays / Variablen. Das ganze läuft in einer

Schleife bis zum Ende der ASCII-Datei. Code 4 zeigt den dazu passenden Quellcode in

VBA.

Dieser Code eignet sich auch dazu, einige der Problematiken, die während der Entwick-

lung des Skripts auftauchten, anzusprechen. Während der ersten Testläufe mit dem ur-

sprünglichen Skript stellte sich heraus, dass es zu Problemen beim Import kam, wenn

die zu importierende ASCII-Datei nicht einer ganz speziellen Formatierung entsprach.

Z.B. stellte es ein Problem dar, wenn die Zeilen der ASCII-Datei mit einem Leerzeichen


begannen oder auch wenn die Dezimalzahlen durch einen Punkt anstatt eines Kommas

getrennt wurden.

start:

Dim tester As Boolean

Do Until objFile.AtEndOfStream

iMaxNum = iMaxNum + 1

a = objFile.ReadLine

D = Replace(a, ".", ",")

c = Trim(D)

b = Split(c, str_separator)

tester = IsNumeric(b(0))

If tester = False Then GoTo start

xCoor(iMaxNum) = CDbl(b(0))

yCoor(iMaxNum) = CDbl(b(1))

zCoor(iMaxNum) = CDbl(b(2))

Loop

Code 4: Beladen der Arrays mit dem „Input-ASCII-File“ durch eine Schleife.

Diese Probleme werden nun im obigen Codebeispiel durch die Zeilen:

a = objFile.ReadLine

D = Replace(a, ".", ",")

c = Trim(D)

b = Split(c, str_separator)

gelöst. Diese vier Zeilen laden zuerst eine Linie der Textdatei (a = objFile.ReadLine) in die

Variable a. Anschließend werden in der Variable a alle Punkte durch ein Komma ersetzt

und das Ergebnis in der Variablen D gespeichert (D = Replace(a, ".", ",")). Anschließend

werden mit der „Trim“ Funktion etwaige Leerzeichen vor und nach dem eigentlichen

Inhalt jeder Zeile gelöscht und in die Variable c gespeichert (c = Trim(D)). Danach wird

abschließend jede Zeile in seine verschiedenen Bestandteile aufgespalten. Dabei wird

die Funktion „Split“ aus VBA angewendet. Die Zeile b=Split(c, str_separator) bedeutet,

dass der Inhalt der Variablen c immer dort aufgespaltet wird, wo die Funktion auf den

Inhalt der Variablen „str_separator“ trifft. Dieser Inhalt wird zu Beginn im Formular mit

der Option „Lines of ASCII Files are separated by ____“ festgelegt. Wenn dort z.B.


„Komma“ ausgewählt wurde, wird die in C gespeicherte Zeile bei jedem „ , “ aufgespal-

tet und die Ergebnisse werden in die Variable b gespeichert, die gleichzeitig ein Array

ist.

Im nächsten Teilbereich der Schleife wird überprüft, ob die in b geladenen Inhalte nu-

merisch sind oder nicht. Da LiDAR-Daten immer numerisch sein sollten, geht das

Skript davon aus, dass es sich wenn die Inhalte nicht numerisch um einen Teil des Hea-

ders der ASCII-Datei oder sonstige unerwünschte Informationen handelt. Ist dies der

Fall, wird die Zeile nicht in den Array geschrieben, der später ins „Shapefile“ geladen

wird, sondern die Schleife überspringt den dritten Teil des Codes und beginnt von vorne

mit der nächsten Zeile.

Ist der Inhalt jedoch numerisch, so wird dieser Inhalt durch die Zeilen

xCoor(iMaxNum) = CDbl(b(0))

yCoor(iMaxNum) = CDbl(b(1))

zCoor(iMaxNum) = CDbl(b(2))

in den jeweiligen Array geschrieben. Dabei wird der erste abgespaltene Bereich als x-

Koordinate, der zweite als y-Koordinate und der dritte als Höhen- oder z-Wert abge-

speichert.

3. Erstellung des „Shapefiles“

Im nächsten Schritt wird das Punkt-„Shapefile“ erstellt, welches die in den Arrays

xCoor, yCoor und zCoor gespeicherten Daten aufnehmen soll. Hierzu wird ein externes

Unterskript aufgerufen. In diesem Skript wird eine Rohversion des Punkt-“Shapefiles“

erstellt. Das „Shapefile“ hat an diesem Punkt noch keinerlei Inhalte. Noch vor Aufrufen

des Unterskripts zur Erstellung des leeren „Shapefiles“ sollten die Felder, die später

dem leeren „Shapefile“ angehängt werden, definiert werden. Dies geschieht mit den

folgenden Zeilen:

Dim pXCoor As IFieldEdit

Set pXCoor = New Field

With pXCoor

.Name = "XCoor"

.Type = esriFieldTypeDouble

End With

Dim pYCoor As IFieldEdit

Set pYCoor = New Field

With pYCoor

.Name = "YCoor"


End With (1/2)


Dim pZCoor As IFieldEdit

Set pZCoor = New Field

With pZCoor

.Name = "ZCoor"


End With (2/2)

Code 5: Vorbereitung der Felder für das neu erstellte „Shapefile“

Nach diesen Zeilen existieren die Felder „pXCoor“, „pYCoor“ und „pZCoor“. Diese

werden dann später dem neu erstellten leeren „Shapefile“ angehängt (mit dem Befehl:

„pFClassOutput.AddField pXCoor“ usw. – wobei hier pFClassOutput für das eben neu

erstellte leere „Shapefile“ steht).

4. Erstellung der Indizes und Beladung des „Shapefiles“

Direkt anschließend werden für die neu angehängten Felder Indizes erstellt. Dies ge-

schieht um den Beladungsprozess zu beschleunigen. Eine weitere Maßnahme den Bela-

dungsprozess zu beschleunigen ist die Verwendung eines sogenannten „insert cursor“.

Dieser „insert cursor“ ist in der Lage, die in den Arrays gespeicherten Inhalte schnell in

die eben angehängten Felder des leeren „Shapefiles“ zu schreiben. Gleichzeitig ermög-

licht seine Verwendung die Definition der Geometrie innerhalb des „Shapefiles“.

An dieser Stelle wird etwas weiter ausgeholt: Die Definition der Geometrie ist von zent-

raler Bedeutung, da ArcMap Daten nur darstellen kann, wenn die Koordinaten des je-

weiligen Objekts bekannt sind. Ein leeres „Shapefile“ wird in ArcMap zunächst einmal

gar nicht im View-Fenster dargestellt. Werden nun Daten in die Attributtabelle des

„Shapefiles“ geladen, kann man diese zwar in der Attributtabelle sehen, im View wird

dennoch noch nichts dargestellt. Grund hierfür ist, dass ArcMap erst noch mitgeteilt

werden muss, welche der Spalten in der Attributtabelle die Werte für die x- und y-

Koordinaten enthalten. Für die komplett richtige Projektion ist auch noch das richtige

Bezugssystem von Bedeutung (siehe Kapitel 5.4).

Nachdem für alle Zeilen mit einem Loop die x- und y-Koordinaten definiert wurden,

folgt das Beladen des „Shapefiles“ mit den folgenden Zeilen:


For i = import_raw_ascii.txt_startline.Text To iMaxNum

With pPoint

.x = xCoor(i)

.Y = yCoor(i)

End With

Set pInsertFeatureBuffer.Shape = pPoint

pInsertFeatureBuffer.Value(indexX) = xCoor(i)

pInsertFeatureBuffer.Value(indexY) = yCoor(i)

pInsertFeatureBuffer.Value(indexZ) = zCoor(i)

Code 6: Beladen des „Shapefiles“

Das eigentliche Beladen findet durch die drei letzten Zeilen statt. Der Bereich davor

definiert, welche Felder die x- und die y-Koordinate des neu erstellten Punktes enthalten

(jede geladene Zeile entspricht einem neu erstellten Punkt = pPoint).

Zusätzlich noch anzumerken ist, dass in dieser Schleife wiederum eine Eingabe aus dem

Anwenderformular seinen Eingang ins Skript findet. In der Zeile “For i = im-

port_raw_ascii.txt_startline.Text to iMaxNum” steht der Bereich “ im-

port_raw_ascii.txt_startline.Text“ für die Eingabe des Anwenders in Formularbereich

„Start Import in line __“.

Nach dem Beladen des „Shapefiles“ ist der eigentliche Import abgeschlossen. Abschlie-

ßend wird dann automatisch ein weiteres Skript innerhalb des Moduls geladen, welches

das eben beladene „Shapefile“ zum aktuellen „View“ hinzufügt. Abb. 16 zeigt ArcMap

nach einem erfolgreichen Import einer Rohdatendatei.

Geschichte

Abb. 16: Ansicht nach erfolgreichem Import


Ursprünglich sollte die Importfunktion des FELIS-Analyst nicht nur das ASCII-Format

sondern auch noch diverse andere Formate u.a. das .las und binäre Formate wie das

TreesVis-eigene Format .rwb unterstützen. Im Laufe der Planungen stellte sich heraus,

dass der Import von .las Daten in ArcMap bzw. durch den 3D-Analyst bereits unters-

tützt wird und deswegen nicht unbedingt notwendig ist.

Der Import von komplexen binären Dateien (die in C erstellt wurden) wird durch die

Eigenarten der Programmiersprache VBA stark erschwert. Der Zugriff auf binäre Datei-

en sowie das korrekte Lesen selbiger gestaltet sich sehr kompliziert. Dennoch wurde

zum Abschluss der Arbeit intensiv an einem binären Importer für das rwb-Format prog-

rammiert. Der Importer stand bei Abgabe der vorliegenden Arbeit bereits kurz vor der

Fertigstellung. Der Fokus lag dennoch zunächst auf einem voll funktionsfähigen ASCII-

Importer. Alle Planungen bezüglich weiterer Dateiformate und Konvertierungsprog-

ramme wurden zu Beginn des Projekts zurückgestellt.

Die Entwicklung des ASCII-Importers baut auf einem bereits vorhandenen Skript auf,

welches auf der ESRI Webseite ArcScripts Home frei verfügbar ist. Ganz zu Beginn

wurde dieses Skript in ein einfaches Formular eingebettet. Nachdem diese Kombination

aus selbsterstelltem Anwenderformular und fertigem Skript funktionsfähig waren, wur-

de der Importer nach und nach erweitert.

Grund für die Weiterentwicklungen waren diverse Probleme mit dem Format der einzu-

lesenden Dateien. Wie bereits erwähnt, mussten die Rohdaten exakt einer bestimmten

Formatierung entsprechen, war dies nicht der Fall, brach der Import mit einer Fehler-

meldung ab oder geriet in eine Endlosschleife. Beispiele solcher Probleme waren:

1. Punkt als Dezimaltrennzeichen anstatt Komma

2. Leerzeichen am Anfang bzw. Ende jeder Zeile

3. Vorhandensein eines Headers

4. Textdatei endet ohne Leerzeile oder mit mehreren Leerzeilen

5. Rohdaten bestehen aus mehr Attributen als nur x, y, z

6. Anderes Trennzeichen als Leerzeichen

Die Punkte 1. und 2. wurden bereits mit Code 4 besprochen. Durch Veränderung des

Codes zum Lesen und Schreiben der Textdatei in Variablen wurden die Probleme beho-

ben. Das dritte genannte Problem wurde durch mehrere Änderungen behoben. Zum Ei-

nen wurde innerhalb des Codes durch die ebenfalls bereits oben besprochene Prüfung,

ob die gelesenen Variablen numerisch sind oder nicht, sichergestellt, dass das Skript

nicht abbricht. Zum Anderen wurde die Preview-Funktion ergänzt.


Die Preview-Funktion im Anwenderformular ist aber nicht nur hierfür hilfreich, sondern

auch um festzustellen, durch welches Trennzeichen die einzelnen Werte in der Rohda-

tendatei getrennt sind.

Der Punkt 5. stellte eine etwas größere Herausforderung dar. Da eine variable Anzahl an

Attributen das gesamte Skript an diversen Stellen massiv beeinflussen würde, wurde

eine eher einfache Lösung gewählt: Für 1 – 7 zusätzliche Attribute gibt es jeweils ein

eigenes Modul. Jedes dieser Module ist identisch, bis auf die Aspekte, die die zusätzli-

chen Attribute tangieren. So werden z.B. bei drei zusätzlichen Attributen auch drei zu-

sätzliche Felder erstellt, drei zusätzliche Indizes geschaffen usw.. Ein einzelnes Modul,

welches sich variabel an die Anzahl zusätzlicher Attribute anpasst wäre grundsätzlich

sicher möglich, wurde aber beim aktuellen Wissensstand und der zur Verfügung stehen-

den Zeit als nicht rational empfunden.

Das einzige Problem, das bisher noch nicht gelöst werden konnte, ist, dass das Skript in

eine Endlosschleife gerät, wenn das einzulesende ASCII-File nicht mit einer einzelnen

Leerzeile endet. Da die VBA-interne Funktion zur Erkennung des Dateiendes nur mit

dieser Voraussetzung in der Lage ist das Ende auch tatsächlich zu erkennen, muss dieser

Mangel zum jetzigen Zeitpunkt hingenommen werden.

5.2 Normalisieren von Rohdaten

Zweck

Unter der Normalisierung von Rohdaten versteht man das Abziehen des Geländemo-

dells von der Rohdatenpunktewolke. Ein Beispiel hilft, diesen Satz zu verstehen: Ange-

nommen im Schwarzwald wurde eine Laserbefliegung durchgeführt: Ergebnis wären

Laserpunkte, die Höhenwerte von 500m und höher aufweisen, da das Gelände des

Schwarzwaldes dementsprechend hoch über Niveau Null (NN) verläuft. Aus diesen

Höhenwerten können nur schwer direkte Informationen abgeleitet werden. Es ist un-

möglich, allein aus dem Höhenwert eines einzelnen Laserpunktes bereits Schlüsse auf

seine Herkunft (Bodenpunkt, Gebäude, Vegetation) zu ziehen. Nur in Relation mit den

anderen Punkten ist dies möglich.

Für manche Algorithmen und auch für das intuitive Verständnis der Rohdaten kann es

hilfreich sein, wenn die Laserpunkte nicht ihren absoluten Höhenwert über NN aufzei-

gen sondern die Höhe über dem vorhandenen Boden. Um diese Höhen zu berechnen

wird ein Digitales Geländemodell (DGM) benötigt. Das Geländemodell beinhaltet i.d.R.

in einer kontinuierlichen Rasterdatei die Höhe über NN des Bodens an jedem Punkt.

Wird diese Höhe nun von der absoluten Höhe des Laserpunkts über NN abgezogen so

bleibt der Höhenwert des Laserpunkts über dem Boden (Abb. 17).


Aufbau

Das Skript zur Normalisierung von Rohdaten wurde selbst entwickelt. Es kommen meh-

rere Tools aus der Toolbox von ArcMap zum Einsatz. Abb. 18 zeigt das Anwenderfor-

mular zum Skript. Eingangsdaten sind ein „Shapefile“ mit der Laserpunktwolke sowie

ein DGM, welches dasselbe Gebiet abdecken muss wie die Punktewolke. Zusätzlich

muss der Anwender noch einen Pfad und einen Dateinamen für die ausgehende Datei

angeben.

Nach Klicken des OK-Buttons wird das Skript zur Normalisierung von Rohdaten aufge-

rufen. Das Skript besteht aus vier hintereinander ablaufenden Prozessen. Als erstes wird

das „Extract Values to Points“-Tool verwendet. Dieses erstellt in der Attributtabelle des

„Shapefiles“, welches die Laserpunkte beinhaltet, eine neue Spalte. Anschließend füllt

das Tool die Spalte mit Werten aus dem zu Beginn definierten DGM. Für jeden Laser-

Abb. 17: Berechnung eines normalisierten Laserpunktes

Abb. 18: Anwenderformular für die Normalisierung von Rohdaten


punkt wird exakt der Wert in die Attributtabelle geschrieben, den der Pixel (des DGM-

Rasters), an dem sich der Laserpunkt befindet, beinhaltet.

Die neue Spalte in der Attributtabelle enthält also demnach den jeweiligen Höhenwert

des Bodens über NN an der Stelle, an der sich der Laserpunkt befindet.

Als nächster Schritt wird nun eine weitere Spalte in der Attributtabelle erstellt. Dazu

wird das „Add Field“-Tool verwendet. Diese neu erstellte Spalte ist zunächst leer und

wird im nächsten Schritt gefüllt.

Hierfür wird das „Calculate Field“-Tool verwendet. Dieses Tool ermöglicht es, per

SQL-Editor, eine Formel zusammenzustellen, nach der die neu erstellte Spalte gefüllt

wird. Die verwendete Formel ist eine einfache Subtraktion des Höhenwertes des Bodens

über NN (durch das „Extract Values to Points“-Tool in die Attributtabelle des „Shapefi-

les“ übernommen) von der absoluten Höhe des jeweiligen Laserpunkts über NN (z-Wert

jedes Punktes aus der Spalte „ZCoor“).

Abschließend wird die nicht mehr benötigte Spalte mit den Höhenwerten des Bodens

über NN mit dem Tool „Delete Field“ beseitigt.

Geschichte

Das Modul zur Normalisierung von Rohdaten war eines der letzten Module, welches im

Rahmen dieser Arbeit erstellt wurde. Nachdem einige Tools bereits in anderen Modulen

Verwendung gefunden hatten, war die Umsetzung problemlos möglich.

5.3 Verschmelzen von Rohdaten

Zweck

Rohdaten werden häufig in mehreren Datensätzen geliefert. Oft ist das gesamte Beflie-

gungsgebiet unterteilt in quadratische Kacheln und oft sind die einzelnen Kacheln

nochmal vorsortiert in LP- und FP-Punkte. Bei der Berechnung von Höhenmodellen

und anderen Prozeduren innerhalb des FELIS-Analysts kann es sinnvoll sein, mehrere

Rohdatensätze zusammenzufassen. Diese Funktion steht in ArcMap mit dem Tool

„Merge“ bereits zur Verfügung. Hiermit können mehrere „Shapefiles“ zu einer neuen

Datei zusammengefasst werden.

Aufbau

Prinzipiell wird bei der Verschmelzung von Rohdaten nur das eben bereits erwähnte

„Merge“-Tool verwendet. Dennoch besitzt das Modul ein paar zusätzliche Codeteile.

Die Definition und Zuordnung der eingehenden Variablen gestaltete sich in diesem Mo-

dul etwas komplizierter als bei anderen Modulen, die nur ein Tool aus ArcMap verwen-

den (siehe z.B. Kapitel 5.4).


Wie in Abb. 19 zu sehen ist müssen zuerst die eingehenden „Shapefiles“ zur „Listbox“

hinzugefügt werden. Danach muss noch eine Ausgangsdatei definiert werden und das

Modul ist startbereit.

Problematisch war vor allem, dass die Anzahl an eingehenden „Shapefiles“ undefiniert

ist und damit nicht vorab alle Eingangsvariablen fix definiert werden können. Die Lö-

sung innerhalb des Moduls für dieses Problem lag in der Verwendung eines Arrays und

diverser If-Syntaxen. Auf Details soll an dieser Stelle nicht eingegangen werden.

Geschichte

Das Modul war ähnlich wie das Modul zur Normalisierung von Rohdaten eines der letz-

ten, das in den FELIS-Analyst implementiert wurde. Die Umsetzung war relativ prob-

lemlos möglich. Zu Beginn stellte die Visualisierung der eingehenden „Shapefiles“ mit

Hilfe einer „Listbox“ eine kleine Hürde dar, da die „Listbox“ nicht gleichzeitig zur

Definition der eingehenden Variablen in das Tool dienen konnte.

5.4 Georeferenzierungsoptionen für Rohdaten und digitale

Höhenmodelle

Als nächstes funktionsfähiges Modul sollen die Georeferenzierungsoptionen sowohl für

Rohdaten (=„Shapefiles“) als auch Höhenmodelle (=Rasterdateien) besprochen werden.

Das Skript ist relativ simpel aufgebaut und ein typisches Beispiel für die Verwendung

eines Tools der ArcMap-Toolbox innerhalb des FELIS-Analysts. Aufgrund der Tatsa-

che, dass noch einige andere Module einen ähnlichen Skriptaufbau besitzen, sollen die

Georeferenzierungsoptionen der Rohdaten an dieser Stelle exemplarisch ausführlich

erläutert werden.

Abb. 19: Anwenderformular zum Verschmelzen von Rohdaten


5.4.1 Rohdaten

Zweck

Der Zweck des Moduls Georeferenzierungsoptionen für Rohdaten, welches unter dem

Menüpunkt „Raw Data � Georeferencing“ zu erreichen ist, besteht darin, den impor-

tierten Rohdaten ein geografisches Bezugssystem zuzuweisen.

Dies ist unbedingt notwendig, um eine korrekte Visualisierung der Rohdaten zu gewähr-

leisten. Nach dem Import der Rohdaten ist die Visualisierung zwar bereits möglich, da

ArcMap mitgeteilt wurde, in welchen Spalten die x- und y-Koordinaten jedes Punktes

liegen. Die korrekte Darstellung dieser Punkte kann allerdings nur erfolgen, wenn Arc-

Map zusätzlich weiß, auf welches Bezugssystem sich diese Koordinaten beziehen.

Im Lieferumfang von ArcMap ist eine umfangreiche Sammlung an Bezugssystemen

enthalten, die man unter „X:\Installationspfad\ArcGIS\Coordinate Systems\“ finden

kann.

Grundsätzlich muss beachtet werden, dass alle Daten, die während eines Projektes in-

nerhalb des GIS Verwendung finden, ein korrektes Bezugssystem (Koordinatensystem

und Höhensystem) besitzen, da die Daten ansonsten nicht richtig projiziert werden.

Aufbau

Wie bereits in der Einleitung angedeutet wurde, soll auf den Aufbau dieses Skripts im

Detail eingegangen werden, da der Aufbau exemplarisch für einige andere Module ist.

Der Fokus soll hierbei auf dem Skriptbereich liegen, der nach Klicken des „OK“-

Buttons im Anwenderformular aufgerufen wird.

Das Formular selbst und das dahinter stehende Skript ist relativ einfach aufgebaut und

soll nicht näher besprochen werden. Code 7 illustriert das zu besprechende Skript, Abb.

20 zeigt das Anwenderformular, welches ebenfalls zur Erläuterung des Codes herange-

zogen werden wird.

Abb. 20: Anwenderformular Georeferenzierung von Rohdaten


Private Sub Georeference_RawData_ClickOK()

'error messages

If txt_Input_Georef_FC = "" Then GoTo fehler

If txt_Input_Georef_Coordinate_FC = "" Then GoTo fehler

On Error GoTo fehler2

' create the geoprocessor

Dim gp As Object


' create and define in- and output variables

Dim str_input1 As String

Dim str_cs As String

str_input1 = txt_Input_Georef_FC

str_cs = txt_Input_Georef_Coordinate_FC

' call the defineprojection tool from the toolbox

Call gp.defineprojection(str_input1, str_cs)

' unload and hide the form

GeoreferenzierungRawData.Hide

Unload GeoreferenzierungRawData

GoTo ende

'error messages

fehler:

msgbox "Some input is missing"

GoTo ende

fehler2:

msgbox "Your inputs are not correct - projection not successful"

ende:

Code 7: Das Georeferenzierungs-Tool für Rohdaten

Das Skript in Code 7 beginnt mit der Definition von Fehlermeldungen, die an das An-

wenderformular angelehnt sind. Die ersten zwei Zeilen des Codes

If txt_Input_Georef_FC = "" Then GoTo fehler

If txt_Input_Georef_Coordinate_FC = "" Then GoTo fehler

stellen sicher, dass, wenn eines der beiden Felder im Anwenderformular leer bleibt und

der Anwender dennoch “OK” klickt, das Skript an die Stelle „fehler:“ springt und der

Anwender eine Benachrichtigung in einem Pop-Up-Fenster zu lesen bekommt, welches


ihn darauf hinweist, dass eine notwendige Eingabe fehlt („Some input is missing“). Die

dritte Zeile innerhalb des ersten Skriptblockes

On Error GoTo fehler2

funktioniert prinzipiell gleich nur ist die Definition „On Error“ keine konkrete Bedin-

gung, sondern kann innerhalb von VBA als Stellvertreter für jeglichen Fehler eingesetzt

werden. In Umgangssprache übersetzt bedeutet diese Zeile also:

„Wenn irgendein Fehler auftritt während das Skript läuft, spring an die Stelle „fehler2““

An der Stelle „fehler2“ wird wiederum das Öffnen eines Pop-Ups veranlasst, das den

Anwender darauf hinweist, dass das eingehende „Shapefile“ nicht korrekt projiziert

wurde („Your inputs are not correct, projection not successful“).

Nach der Definition der Fehlermeldungen wird der Geoprozessor aktiviert. Wie bereits

in Kapitel 4.3 erwähnt, ist dies eine notwendige Voraussetzung, um die Tools der Tool-

box innerhalb von ArcMap zu nutzen.

Im nächsten Schritt werden die Variablen, die für die Verwendung des Georeferenzie-

rungstool benötigt werden, erstellt und definiert. Die Zeilen

Dim str_input1 As String

Dim str_cs As String

str_input1 = txt_Input_Georef_FC

str_cs = txt_Input_Georef_Coordinate_FC

erstellen zwei Variablen mit Namen “str_input1” und “str_cs” in der Formatierung

“string”, also Text. Dann werden den Variablen Inhalte zugewiesen. Dabei wird die

Variable str_input1 dem Eingabefeld des Anwenderformulars mit dem Titel „Input Fea-

ture Class / Shapefile“ (Abb. 20) zugewiesen. Dieses Eingabefeld trägt innerhalb des

Formulars den Namen „txt_Input_Georef_FC“. Der zweiten Variablen wird de-

mentsprechend das zweite Eingabefeld mit dem Titel „Define Coordinate System“ zu-

gewiesen.

Nun wird mit der Zeile

Call gp.defineprojection(str_input1, str_cs)

das Tool aufgerufen. In Klammern stehen dabei die notwendigen Inputs für das Tool,

welche gerade eben durch die Variablen festgelegt wurden. Das Tool wird nun dem

definierten eingehenden „Shapefile“ das ausgewählte Lagekoordinatensystem / geogra-

fisches Bezugssystem zuweisen. In ArcMap ist jedes Lagekoordinatensystem bereits mit

einem dazu passenden Höhensystem verknüpft. Das Höhensystem kann in diesem Fall

nicht frei gewählt werden.


Im letzten Schritt wird das Anwenderformular zuerst unsichtbar gemacht und dann

deaktiviert, d.h. aus dem Speicher des Rechners entfernt. Die dafür notwendigen Zeilen

lauten

GeoreferenzierungRawData.Hide

Unload GeoreferenzierungRawData

GeoreferenzierungRawData ist hierbei der Name des Formulars. Hiernach folgt der

Sprung zum Ende des Skripts und das Skript wird mit der Zeile

End Sub

beendet.

Dieser Aufbau wird sich bei allen Modulen, die ausschließlich ein Tool aus der Toolbox

aufrufen und keine weiteren Skriptteile enthalten wiederholen. Die hiervon betroffenen

Module sind:

1. Georeferencing (DOM, DGM, nDOM)

2. Create Aspect Image

3. Create Slope Image

4. Create Hillshade Image

5. Calculate DOM

6. Calculate nDOM

7. Export to TreesVis

8. Export to Google Earth

Bei all diesen Modulen wird demnach auf eine nähere Erläuterung dieses Aufbaus ver-

zichtet.

Geschichte

Die Georeferenzierungsoptionen wurden in der Planung des FELIS-Analysts als wichti-

ger Bestandteil eines LiDAR-Moduls für ArcMap angesehen. Da die entsprechenden

Tools in ArcMap bereits vorhanden sind, war eine problemlose Integration der Tools in

den FELIS-Analyst möglich. Hier, wie auch bei allen anderen direkt integrierten Tools,

liegt der Fokus darauf, dem Anwender möglichst alle hilfreichen Tools für die Verarbei-

tung von LiDAR-Daten innerhalb nur eines Menüs zur Verfügung zu stellen. Eigene

Weiterentwicklungen sind in diesen Fällen nicht notwendig und die Entstehungsge-

schichte dementsprechend kurz.


Hintergrundinformationen

Das Thema Höhen- und Koordinatensysteme ist im Bereich der Geodäsie und Vermes-

sung ein sehr weitläufiges, kompliziertes und wichtiges Thema. Ein korrekt gewähltes

Bezugssystem ist die Voraussetzung für eine fehlerfreie Projektion. Ein falsch gewähl-

tes Bezugssystem führt zu Fehlern in Analysen und Planungen. Besonders problema-

tisch ist, dass diese Fehler oftmals nicht einfach zu erkennen sind, da die Geodaten oft

intern zueinander richtig liegen und nur der Bezug zur umgebenden Welt nicht korrekt

ist.

In ArcMap ist jedes Koordinatensystem, welches zu erst einmal das 2D-Bezugssystem

festlegt, mit einem Höhensystem verknüpft. Ein Höhensystem kann nicht unabhängig

vom Koordinatensystem festgelegt werden.

Im Allgemeinen beziehen sich Höhensysteme immer auf einen festen Bezugspunkt, ein

sogenanntes Datum. Ein Datum trägt oft seinen Standort im Namen, wie z.B. das „Pots-

damer Datum“ welches eines der in Deutschland gültigen Daten ist. Ausgehend von

solch einem Referenzpunkt bzw. Datum wird dann per Nivellement ein in der Regel

nationales Höhensystem erstellt. Dabei werden über das gesamte Land amtliche Höhen-

festpunkte eingerichtet. Der Höhenbezug wird normalerweise über den Meeresspiegel

hergestellt, daher befinden sich viele Referenzpunkte an Küsten

(http://de.wikipedia.org/wiki/Höhe_über_dem_Meeresspiegel).

Da der Meeresspiegel durch Ebbe und Flut beeinflusst wird, kann der Höhenbezug nur

durch Messung des „Mittelwassers“ – ein über Jahre gemessener Mittelstand des Pegels

– hergestellt werden (http://de.wikipedia.org/wiki/Mittelwasser).

Die Höhendifferenz zwischen unterschiedlichen Höhensystemen beträgt in der Regel

einige Zentimeter, kann aber auch bis zu mehreren Metern betragen. Die Umrechnung

von einem Höhensystem in ein anderes ist oft problematisch und ungenau. Zusätzlich

sind die Unterschiede in unterschiedlichen Höhen oft verschieden, da verschiedene Hö-

hensysteme sich häufig auf verschiedene Bezugskörper (wie z.B. Geoid, Quasigeoid

oder Telleroid) beziehen und auf unterschiedliche Art und Weisen berechnet wurden.

Unter anderem spricht man z.B. von geometrischen und physikalischen Höhensystemen

(IIG, 2009).

„Man spricht von geometrischen Höhen, wenn die Figur der Erde durch eine rein geo-

metrisch definierte Fläche, beispielweise ein Rotationsellipsoid angenähert wird.“ Die

Höhen misst man dann längs des geradlinigen Lots auf die Bezugsfläche (IIG, 2009).

Hinter dem Begriff „physikalisches Höhensystem“ steht der Gedanke, dass horizontal

beurteilte Flächen eine konstante Höhe aufweisen (z.B. eine Wasserwaage, die im Lot

steht). Davon abgeleitet kann man sagen, dass zwischen zwei Punkten gleicher Höhe


kein Wasser fließen kann. Demnach bestimmt die Fließrichtung des Wassers was oben

und was unten ist.

Aus diesen beiden Grundvorstellungen leiten sich eine Vielzahl an verschiedenen Mög-

lichkeiten für die Erschaffung von Höhensystemen ab. Die Abhandlungen und Erkenn-

tnisse über diese Thematik füllen Bücher und sollen an dieser Stelle nicht weiter behan-

delt werden (IIG, 2009)

Ähnlich sieht es bei der Frage nach den Grundlagen der Lagekoordinatensysteme aus.

Hier ist die zentralste Frage, wie man eine unregelmäßig geformte Kugel in eine planare

2D-Darstellung überführen kann. Verschiedene Formen der Projektion, wie z.B. Zylin-

derprojektionen, Kegelprojektionen oder Azimutalprojektionen, weisen jeweils unter-

schiedliche Vor- und Nachteile auf. Je nachdem, welches Gebiet der Erde dargestellt

werden soll, kann sich die eine oder andere Methode als vorteilhaft erweisen.

5.4.2 Digitale Höhenmodelle – DOM, DGM, nDOM

Zweck

Der Zweck des Moduls Georeferenzierungsoptionen für digitale Höhenmodelle, wel-

ches unter dem Menüpunkt „DSM / DTM / nDSM � Georeferencing“ zu erreichen ist

entspricht dem des Moduls „Georeferenzierungsoptionen für Rohdaten“.

Da ArcMap für die Übertragung von Bezugssystemen auf „Shapefiles“ und Rasterdaten

zwei unterschiedliche Tools verwendet, mussten für diesen Zweck ebenfalls zwei unter-

schiedliche Module kreiert werden.

Aufbau

Der Aufbau des Skripts zur Georeferenzierung von digitalen Höhenmodellen

(=Rasterdaten) entspricht weitestgehend dem in Kapitel 5.4.1. beschriebenen Skriptauf-

bau. Der einzige Unterschied liegt darin, dass die eingehende Datei kein „Shapefile“

sondern eine Bilddatei (=Rasterdatei) ist. Das beeinflusst allerdings nicht das Haupt-

skript, welches nach Klicken des „OK“-Buttons ausgeführt wird, sondern nur die Skrip-

te, die um das Anwenderformular herum programmiert wurden.

Geschichte

Siehe Kapitel 5.2.1.


5.5 Selektion von Rohdaten

Zweck

Die Selektion von Rohdaten kann in vielerlei Situationen hilfreich sein. Ist die Struktur

der Rohdaten bekannt, können z.B. durch die Selektion von Rohdaten falsche Punkte –

etwa eine durch einen Vogel verursachte Reflektion – beseitigt oder markiert werden.

Ein anderes Beispiel für die Verwendung der Selektionsoption ist, wenn in einem Bei-

spieldatensatz in flachem Gelände oder in einem normalisierten Rohdatensatz alle Bäu-

me (bzw. alle Laserpunkte, die Teil dieser Bäume sind) über einer gewissen Höhe mar-

kiert werden sollen.

Grundsätzlich ist die Selektionsfunktion von ArcMap eines der mächtigsten Tools in der

großen Palette an Werkzeugen. Per SQL-Abfrage lassen sich vielfältige Abfragen kreie-

ren und die Möglichkeiten sind beinahe unbegrenzt. Das hier vorgestellte Modul be-

schränkt sich auf die komfortable Selektion der Rohdatenpunkte anhand des z-Werts

(Höhenwert). Für spezifischere problemorientierte Abfragen sollte der Anwender direkt

das Selektionstool von ArcMap nutzen, da es unmöglich ist sämtliche Fragestellungen

vorauszuahnen. Die Selektionsoption von ArcMap wird auch in anderen Modulen des

FELIS-Analyst, wie z.B. im Algorithmus des DGM-Berechnungsmodul, verwendet.

Das Tool, welches in Abb. 21 illustriert ist, bietet 3 Selektionsmöglichkeiten an:

1. Selektion aller Punkte über x Meter Höhe

2. Selektion aller Punkte unter x Meter Höhe

3. Selektion aller Punkte zwischen x und y Meter Höhe

Der Anwender kann außerdem festlegen, ob er die Selektion in ein neues „Shapefile“

speichern möchte oder ob er die entsprechenden Punkte nur markieren will.

Abb. 21: Das Rohdaten-Selektionstool


Aufbau

Das Modul ist ausgehend vom Formular in drei unterschiedliche Skripte unterteilt. Je

nachdem, welche der drei Selektionsmöglichkeiten gewählt wird, wird eines der Skripte

gestartet.

Der Anwender muss in jedem der drei Fälle ein Input-„Shapefile“, die Spalte mit den z-

Werten sowie einen Namen für die Selektion angeben. Zusätzlich hat er optional die

Möglichkeit, einen Namen für ein neues „Shapefile“ einzugeben, in welches dann die

durchgeführte Selektion gespeichert wird. Wird kein Name für ein neues“ Shapefile“

eingegeben, so werden die Punkte, die Teil der Abfragemenge sind, im eingehenden

„Shapefile“ nur markiert.

Die drei unterschiedlichen Skripte sind beinahe identisch. Nur der jeweilige SQL-

Ausdruck, der beim Aufruf des Selektions-Tools verwendet wird, sowie der Code, der

diesen Ausdruck schafft, unterscheiden sich.

Abb. 22 zeigt einen Überblick über die einzelnen Schritte innerhalb der Skripte und

zeigt gleichzeitig kurze Codebeispiele.

Abb. 22: Überblick über das Selektionstool


Zu Beginn stehen wiederum wie bei den Georeferenzierungstools die Fehlermeldungen,

die auf fehlende Eingaben hinweisen. Darauf folgend werden die benötigten Eingangs-

variablen für die später angewandten Tools erstellt und definiert. Dieser Teil ist in die-

sem Skript von entscheidender Bedeutung, da auch der SQL-Ausdruck, welcher später

im Selektionstool für die korrekte Selektion der gewünschten Punkte führt, in einer Va-

riablen steckt.

Einige Variablen setzen sich aus mehreren Formulareingaben zusammen. Zusätzlich

wird, wie auch im Codebeispiel zu sehen, die „ExtractPathName“-Funktion aufgerufen,

die bereits beim ASCII-Importer angewandt wurde.

Anschließend erfolgt die bereits bekannte Erstellung des Geoprozessors, der das Aufru-

fen von Tools aus der Toolbox ermöglicht.

Daraufhin wird basierend auf das Eingangs-„Shapefile“ und dem Eingabefeld, in dem

der Anwender den Namen der Selektion wählt, ein „Feature Layer“ erstellt, der die Se-

lektion temporär abspeichern kann. Dieser „Feature Layer“ ist keine permanente Datei.

Werden die Inhalte nicht in ein neues „Shapefile“ gespeichert, gehen sie beim Schließen

des Programms verloren. Die Erstellung dieses „Feature Layers“ ist zwingend erforder-

lich um das Selektionstool verwenden zu können.

Letzteres wird im nächsten Schritt aufgerufen und die Selektion wird durchgeführt. Zum

Schluss entscheidet dann das Skript je nachdem, ob der Anwender dies wünscht oder

nicht, ob die Selektionsabfrage in ein neues „Shapefile“ gespeichert wird oder nicht.

Geschichte

Die Entwicklungsgeschichte dieses Tools lässt sich ebenfalls kurzfassen. Die Idee zu

diesem Tool entwickelte sich aus der Tatsache, dass im institutseigenen LiDAR-

Programm TreesVis ebenfalls Module zur Selektion von Rohdaten existieren. Die Um-

setzung war weitestgehend problemlos möglich, einzig der oben beschriebene Zwi-

schenschritt (Erstellung des „Feature Layers“) brachte zu Beginn einige Probleme mit

sich, die aber mit Hilfe der Informationen, die innerhalb von ArcMap zum Selektions-

tool bereitgestellt wurden, gelöst werden konnten.

5.6 Berechnung digitaler Höhenmodelle

Die Berechnung digitaler Höhenmodelle ist ein zentraler Aspekt in der LiDAR-

Forschung. Digitale Höhenmodelle werden in fast allen Analysen und Verarbeitungs-

schritten von LiDAR-Daten zwingend benötigt. Dementsprechend wichtig sind auch die

Module, die zur Berechnung dieser Modelle dienen. Im Allgemeinen wird zwischen

drei unterschiedlichen digitalen Höhenmodellen unterschieden:


1. Das digitale Oberflächenmodell (DOM – Englisch: Digital Surface Model –

DSM)

2. Das digitale Geländemodell (DGM – Englisch: Digital Terrain Model – DTM)

3. Das normalisierte digitale Oberflächenmodell (Englisch: nDSM)

Das DOM zeigt die Erdoberfläche mit all seinen Objekten - die Formen von Vegetation,

Häusern, Straßen, Leitungen etc. werden dargestellt. Das DGM zeigt im Idealfall nur

den Grund. Er zeigt das Relief des Geländes ohne die darauf stehenden Objekte. Es ist

weitaus schwieriger aus einer Rohdatenpunktwolke ein DGM zu gewinnen als ein

DOM, da die gesamten Objekte auf der Oberfläche durch Reflektionen Laserpunkte

entstehen lassen, die für die Berechnung des DGMs aber nicht benutzt werden dürfen.

Das nDOM wiederum lässt sich durch ein einfaches Abziehen des DGMs vom DOM

erstellen. Mehr Details hierzu in den jeweiligen Abschnitten.

5.6.1 DOM

Zweck

Wie bereits in den einleitenden Worten angedeutet, sind digitale Höhenmodelle allge-

mein von zentraler Bedeutung für fast alle Analysen, die auf LiDAR-Daten beruhen.

Abb. 23: Schema: DOM: Darstellung des DOM in der „getreckten“ Ansicht (ohne Stufen –

vgl. Abb. 24)


Das DOM ist insbesondere für alle Fragen, die Objekte auf der Erdoberfläche betreffen,

von großem Interesse. Beispiele hierfür wären z.B. die Erstellung von 3D-

Stadtansichten, die Extraktion von Gebäuden, die Extraktion von Waldbeständen, oder

die Extraktion von Einzelbäumen. Auch komplexere Fragestellungen wie z.B. die Un-

terscheidung von Laub- und Nadelbäumen oder auch die Identifikation von Waldschä-

den finden ihren Ausgangspunkt bei DOMs.

Um ein DOM zu gewinnen, muss das Modul aus der Rohdaten-Punktwolke eine konti-

nuierliche Rasterdatei erstellen (schematisch dargestellt in Abb. 23 und 24). Dabei kann

man die Laserpunkte als Stützpunkte ansehen, während die dazwischenliegenden Leer-

flächen durch einen Algorithmus interpoliert werden. Ergebnis ist dann eine Bilddatei,

Abb. 24: Schema DOM: oberes Bild – Darstellung einer Punktewolke, unteres Bild - Dar-

stellung des DOM in schematischer Darstellung mit Höhenklassen


deren Pixelwerte den Erhebungen des jeweiligen geografischen Punktes über NN ent-

sprechen.

Wichtig zu erwähnen ist an dieser Stelle, dass bei der Berechnung von DOM und DGM

auf die korrekten Eingangsdateien geachtet werden muss. Da ein DOM die Oberfläche

abbilden soll, ist es unbedingt notwendig, dass in der eingehenden Datei die First Pulse-

Laserpunkte enthalten sind (siehe Abb. 4). Bei der DOM Berechnung können prinzipiell

alle gesammelten Laserpunkte – also First Pulse, Last Pulse und dazwischen liegende

Reflektionen – berücksichtigt werden. Für manche Zwecke kann ein DOM, welches

nur aus First Pulse-Punkten berechnet wurde, ebenfalls von Interesse sein.

Oben wurde bereits erwähnt, dass ein DOM die Oberfläche abbilden soll. Bei der Trans-

formation der Punktewolke in eine kontinuierliche Oberfläche stehen hierfür einige ver-

schiedene Möglichkeiten zur Verfügung. Zum Einen ist es möglich, die Punkte direkt zu

verbinden. Das führt zu einer unnatürlichen, scharfkantigen Oberfläche. Zum Anderen

ist es möglich, die Zwischenräume zwischen den Punkten sanft zu interpolieren und

damit eine natürlichere Darstellung zu erreichen. Das „Topo-to-Raster“-Tool, welches

im FELIS-Analyst integriert ist, wendet die zweite Variante an. Abb. 25 illustriert das

geschilderte Problem anhand eines Baumes.

Aufbau

Der Aufbau des DOM-Berechnungsmoduls entspricht im Wesentlichen der in Kapitel

5.2.1 besprochenen Skriptstruktur. Das bedeutet, es wird wiederum direkt ein einzelnes

Abb. 25: DOM – Überführung der Rohdaten in eine Oberfläche. Links: Exakte Interpolation – Rechts: Sanfte Interpolation


Tool aus der Toolbox von ArcMap vom Skript aufgerufen und verwendet. Dennoch gibt

es einige Unterschiede, wie ein Blick auf das Formular (Abb. 26) bereits vermuten lässt.

Der Hauptunterschied besteht darin, dass die Inputs für das Tool etwas komplexer sind

als in Kapitel 5.4.1. Der Anwender muss unter anderem das Feld innerhalb der Attribut-

tabelle des eingehenden „Shapefiles“ bestimmten, in dem sich die zu interpolierenden

Werte befinden. Wurde der Rohdatensatz mit dem FELIS-Analyst importiert, so ist dies

immer das Feld mit dem Namen „ZCoor“. Zusätzlich legt der Anwender auch die Zell-

größe fest, was gleichzusetzen ist mit der Pixelgröße der Bilddatei. D.h. eine Zellgröße

von 2 m bedeutet, dass ein Pixel in dem erstellten Bild 2m der abgebildeten Realität

entsprechen.

Da das Tool, je nachdem welcher Dateiname für die ausgehende Bilddatei gewählt wird,

automatisch das entsprechende Bildformat zuweist (wählt man z.B. C:\output.tif so wird

eine .tiff-Datei erstellt, bei c:\output.jpg wird eine .jpg-Datei erstellt usw.), wurde das

Anwenderformular so angepasst, dass der Anwender den Pfad und den Dateinamen frei

wählen kann, sich dann aber für eines der angebotenen Bildformate entscheiden muss.

Das Skript setzt die drei Teilstücke dann wieder als eine Variable zusammen und lässt

diese in das ArcMap-Tool eingehen.

Abb. 27 zeigt, wie das verwendete Tool mit Namen „Topo to Raster“ aussieht, wenn es

aus der Toolbox heraus gestartet wird. Der Vergleich von Abb. 26 und Abb. 27 zeigt

sofort, dass die vom Anwender vorzunehmenden Angaben drastisch reduziert wurden.

Viele der Eingaben im ursprünglichen Tool sind optional und werden nicht benötigt.

Abb. 26: Das Formular des Moduls zur Berechnung von DOMs


Andere zentrale Entscheidungen wie z.B. der „type“ des eingehenden „Shapefiles“ wur-

den bereits im Skript festgelegt und dem Anwender somit abgenommen.

Bei den optionalen Einstellmöglichkeiten wurden durchgehend die Standardeinstellun-

gen verwendet, da diese normalerweise befriedigende Resultate liefern. So werden z.B.

bei den Optionen „Smallest/Largest z value to be used in interpolation“ die Werte auf

höchster eingehender Wert + 20% bzw. niedrigster eingehender Wert -20% festgelegt.

Werte, die über diese Grenze hinausgehen, werden während der Interpolation nicht

verwendet. Die Option „Margin in cells“ legt fest, wie viele Zellen über die Grenze der

eingehenden Punktewolke hinaus die Oberfläche interpoliert werden soll. Standardein-

stellung ist hier 20. Es gibt noch einige weitere Einstellmöglichkeiten, die sich vor al-

lem mit hydrologischen Fragestellungen beschäftigen. Auf diese wird hier nicht weiter

eingegangen. Die Hilfefunktion innerhalb des „Topo-to-Raster“-Tools, welches direkt

aus der Toolbox gestartet werden kann, erklärt diese ausführlich.

Das Tool ist innerhalb des FELIS-Analyst so angepasst, dass es für die Berechnung von

DOMs im Normalfall ideal ist. Direkte Veränderungen des Algorithmus sind nicht mög-

Abb. 27 Ausschnitt des „Topo to Raster“ – Tools in ArcMap


lich, da ArcMap die Quellcodes seiner Tools nicht veröffentlicht. Dennoch haben sich

die Ergebnisse des „Topo to Raster“-Tools in verschiedenen Tests als befriedigend he-

rausgestellt.

Geschichte

Während der Entwicklung des DOM-Berechnungsmoduls gab es zu Beginn einige klei-

nere Probleme bei der Zusammensetzung der Inputs, die aber schnell gelöst werden

konnten. Ansonsten war die Integration des „Topo to Raster“- Tools mit den vordefi-

nierten Einstellungen problemlos.

5.6.2 DGM

Zweck

Die Berechnung eines DGMs aus einem LiDAR-Rohdatensatz stellt die grundlegendste

Aufgabe in fast allen Forschungsbereichen der LiDAR-Forschung dar. Das DGM fließt

in allen wissenschaftlichen Feldern, die mit terrestrischen LiDAR-Daten arbeiten, in fast

alle Analysen ein. Ein DGM ermöglicht z.B. die genaue Berechnung von hydrologi-

schen Abflusslinien oder die automatische Erfassung von Wegenetzen – auch in bewal-

detem Gebiet. Die Berechnung des nDOM ist ebenfalls nur mit Hilfe des DGMs mög-

lich.

Für die exakte Berechnung eines DGMs muss der Rohdatensatz gefiltert werden. Durch

einen Algorithmus müssen alle Punkte, die nicht zum Boden gehören, entfernt werden.

Für den Aufbau des Filteralgorithmus gibt es mittlerweile verschiedene Ansätze, die

wissenschaftlich diskutiert werden. Nach Meng (2008) lassen sich die momentan ver-

fügbaren Methoden in zwei große Gruppen unterteilen: Zum Einen die „neighbourhood-

based„-Ansätze und zum Anderen die Ansätze, welche sich mit dem „directional filte-

ring“ beschäftigen.

Nach Evans und Hudak (2007) sind funktionsfähige Algorithmen heutzutage vor allem

in kommerziellen Softwarepaketen bzw. in der internen Software von Befliegungsfir-

men anzutreffen. Bei den Befliegungsfirmen besteht die Gefahr, dass ein Bodenpunkte-

datensatz „überfiltert“ sein kann und für die jeweiligen wissenschaftlichen Fragestel-

lungen nicht mehr geeignet ist. U. a. aus diesen Gründen entwickelten Evans und Hudak

einen eigenen Algorithmus zur Klassifizierung von LiDAR-Rohdaten.

Der Code des Programms, in dem der Algorithmus zu tragen kommt wurde zusammen

mit dem in 2007 veröffentlichen Artikel bereitgestellt. Dieses ursprünglich in der Prog-

rammiersprache „eml“ geschriebene Programm für ArcView wurde als Vorlage für das

hier besprochene DGM-Berechnungs-Modul für ArcMap verwendet.

Zweck des Programms besteht darin aus einem eingehenden LP-Rohdatensatz ein mög-

lichst exaktes DGM zu berechnen. Abb. 28 zeigt eine stark vereinfachte schematische


Darstellung der Schritte innerhalb von ArcMap anhand einer kleinen Testfläche mit

wahren Daten und dazu vergleichend ein DOM desselben Gebiets, das sich deutlich

vom DGM unterscheidet, da hier Vegetation und andere Objekte deutlich zu erkennen

sind, während beim DGM nur noch das nackte Gelände zu sehen ist.

Aufbau

Der Aufbau des DGM-Berechnungs-Moduls ist komplex. Es soll deswegen unterteilt

werden in verschiedene Bereiche. Der erste Bereich widmet sich dem Kern des Moduls,

dem Algorithmus zur Klassifizierung des eingehenden Punkt-“Shapefiles“. Anschlie-

ßend soll noch auf einige Ergänzungen eingegangen werden, die das Modul im Laufe

der Zeit erfahren hat und jetzt ebenfalls Teil des Moduls sind.

A) Der Klassifizierungsalgorithmus

Überblick

Abb. 29 zeigt ein nach Evans und Hudak (2007) angefertigtes Schema des DGM-

Berechnungs-Programm, welches gleich zu Beginn steht, um ein besseres Verständnis

der nachfolgenden Erläuterungen des Algorithmus zu ermöglichen.

Grundsätzlich besteht das Programm aus einer Schleife, welche auf drei verschiedenen

Skalierungsebenen nacheinander wiederholt wird. Die Schleife wird in jeder Skalie-

Abb. 28: Vergleich DOM – DGM. DGM zeigt nur den nackten Boden, DOM zeigt Vegetation

und Objekte auf der Oberfläche als weisse „Wölkchen“.


rungsebene maximal 20-mal wiederholt. Die Schleife wird in Abb. 29 durch den mint-

grün hinterlegten Kasten illustriert.

Die Schleife kann innerhalb jeder Skalierungsebene auch vor der 20sten Wiederholung

verlassen werden, wenn die ausgehende Datei des letzten Rechenvorgangs eine be-

stimmte Bedingung erfüllt, die durch den Punkt „convergence“ symbolisiert ist.

Die drei Skalierungsebenen unterscheiden sich darin, dass sie differierende Werte für

die Eingangsvariablen der Schleife festlegen.

Das Eingangsvariablen t und λ

Diese Eingangsvariablen sind zum Einen die vom Anwender festgelegte Zellgröße λ

und zum Anderen der „curvature treshold value“ t, der ebenfalls zu Beginn vom An-

wender gewählt wird. λ wird in der Skalierungsebene I mit dem Faktor 0.5 multipliziert

in der Skalierungsebene II mit dem Wert 1 und in der Skalierungsebene III mit dem

Wert 1.5. Der „curvature treshold value“ ist in der Skalierungsebene I gleich dem vom

Anwender festgelegten Wert t. In der Skalierungsebene II beträgt er t2 = t + 0.1 und in

der Skalierungsebene III t3 = t2 + 0.1.

Auf diese beiden Variablen sollte zum besseren Verständnis noch etwas weiter einge-

gangen werden: Der hier verwendete Algorithmus ist grundsätzlich ein „neighbour-

hood-based“ Ansatz. Das bedeutet jeder Punkt wird mit seinen Nachbarn verglichen und

Abb. 29: Das DGM – Modul im Überblick


auf Grund der Beziehungen zu seinen Nachbarn als Bodenpunkt oder nicht Bodenpunkt

klassifiziert. Hierbei spielt der „curvature treshold value“ eine Rolle. Er beschreibt diese

Beziehung zwischen einem bestimmten Punkt und seinen Nachbarn, genauer gesagt den

Schwellenwert der Krümmung der interpolierten Fläche zwischen den zwei Punkten.

Liegt der Punkt tendenziell höher als seine umliegenden Nachbarn, wird er als Nicht-

Bodenpunkt klassifiziert. Der „curvature treshold value“ legt numerisch fest, was „ten-

denziell höher“ bedeutet. In steilem Gelände können relativ nahe beieinander liegende

Punkte einen relativ großen Höhenunterschied besitzen und dennoch beides Boden-

punkte sein. Um Fehlklassifizierungen zu vermeiden, kann der Anwender den „curvatu-

re treshold value“ an sein jeweiliges Testgebiet anpassen (Im Anwenderformular stehen

drei Werte zur Auswahl: 0.2, 0.3 und 0.4)

Zusätzlich ist es offensichtlich, dass die Größe des jeweiligen Gebiets innerhalb derer

Punkte mit ihren Nachbarn verglichen werden eine große Rolle spielt. Diese wird inner-

halb des verwendeten Algorithmus maßgeblich durch die Zellgröße λ der resultieren-

den Rasterdatei beeinflusst.

An dieser Stelle soll nun ein Sprung zur in Abb. 29 grün hinterlegten Schleife stattfin-

den, bei deren Beschreibung, die Bedeutung von t und λ noch klarer werden sollte.

Die Klassifizierungsschleife

In der Klassifizierungsschleife werden nacheinander die in Abb. 29 sichtbaren Schritte

durchgeführt. Das eingehende Punkt-„Shapefile“, welches eine Rohdatenpunktwolke

beinhaltet wird zuerst durch eine „Thin Plate Spline (TPS)“-Interpolation in eine Ras-

terdatei überführt. Bei der Interpolation werden jeweils die 12 nächsten Nachbarn eines

jeden Punktes einbezogen und der Interpolationswert ist dabei der z-Wert der im „Sha-

pefile“ gespeicherten Punkte. Diese Interpolation wird sowohl durch t als auch durch λ

beeinflusst. Der „curvature treshold value“ beeinflusst, auf welche Art die Zwischen-

räume zwischen den einzelnen Punkten gefüllt werden und λ legt die Pixelgröße des

berechneten Bildes fest. Für mehr Informationen zur Spline-Interpolation siehe Anhang

A.

Nach der Interpolation läuft ein Kernel über die Rasterdatei. Der Kernel hat eine Größe

von 3 x 3 Pixeln. Die Pixelgröße wurde vom Anwender durch λ festgelegt und vom

Algorithmus, wie oben beschrieben in den unterschiedlichen Skalierungsebenen durch

jeweils einen unterschiedlichen Faktor verändert. Der Kernel berechnet den Mittelwert

jedes Pixels und seiner 8 umliegenden Pixel und speichert das Ergebnis wiederum in

einer Bilddatei.

Im nächsten Schritt wird das ursprüngliche Punkt-„Shapefile“ und die Rasterdatei des 3

x 3 Kernels übereinander gelegt. Anschließend wird das Punkt-„Shapefile“ wie eine Art

„Ausstecherform“ benutzt. Dabei wird innerhalb des „Shapefiles“ eine neue Spalte in

der Attributtabelle erstellt, welche die jeweiligen Pixelwerte (des 3 x 3 Kernel Raster-


bildes) der Pixel enthält, an deren Stelle sich der jeweilige Punkt befindet. Diese Pixel-

werte sind logischerweise ebenfalls z-Werte. Nun ist die Grundlage für die Klassifizie-

rung zu Boden und Nicht-Bodenpunkte geschaffen. Die Klassifizierung findet nach der

Formel

If Z(s) > c THEN classify as nonground

statt. Wobei hier Z(s) dem ursprünglichen z-Wert des Punkt-“Shapefiles“ (welches die

Rohdaten enthält) entspricht und c gleichzusetzen ist mit dem Pixelwert, der durch den

Kernel berechnet wurde plus dem t-Wert der aktuellen Skalierungsebene.

Innerhalb des verwendeten Codes wurde diese Formel umgekehrt: anstatt die Nicht-

Bodenpunkte zu eliminieren (Selektion und Löschen der Punkte) wurde der Weg ge-

wählt, die Bodenpunkte beizubehalten (Selektion und Kopie in neues „Shapefile“). Da-

raus ergibt sich dann die Formel:

If Z(s) < c then classifiy as ground (and copy to new file)

Dieser Weg wurde gewählt, da er zum Einen Vorteile in der Rechengeschwindigkeit

aufweist und zum Anderen die ausgehende Datei direkt als Eingang für den darauf fol-

genden Prozess verwendet werden kann.

Code 8 zeigt den entsprechenden Code innerhalb des DGM-Berechnungs-Moduls.

' Process: Select Layer By Attribute...

Call gp.SelectLayerByAttribute_management(Ende_Round1, "NEW_SELECTION", """ZCOOR"" <( ""RASTERVA-

LU"" + t)")

' Process: Copy Features...

Call gp.CopyFeatures_management(Ende_Round1, Output_Feature_Class, "", "0", "0", "0")

Code 8: Selektion und Kopierfunktion führen die Punktklassifizierung durch

Nachdem die Klassifizierung der Punkte durch Kopieren der Punkte, die als Boden-

punkte klassifiziert wurden, in ein neues „Shapefile“ abgeschlossen wurde, folgt die

Entscheidung, ob die Skalierungsebene beendet werden kann oder nicht.

Die drei Skalierungsebenen

Diese Entscheidung wird in Abb. 29 durch den Bereich „Convergence“ symbolisiert.

Der darin enthaltende „convergence treshold value“ j beträgt in unserem Projekt 0.1.

Das bedeutet, dass die Skalierungsebene beendet werden kann, wenn weniger als 0.10

% der Punkte aus der letzten Iteration als Nicht-Bodenpunkte klassifiziert wurden. Bei

diesem sehr geringen Wert ist davon auszugehen, dass bei den bestehenden Werten der

Eingangsvariablen keine weiteren Punkte mehr sinnvoll als Nicht-Bodenpunkte elimi-

niert werden können.


Ist dieser Wert erreicht, erfolgt der Sprung zur nächsten Skalierungsebene, welche eine

Vergrößerung der Zellgröße und des „curvature treshold value“ t mit sich bringt. Die

Änderung der beiden Variablen sorgt dafür, dass wieder mehr Punkte als Nicht-

Bodenpunkte erkannt werden und die Iterationen von vorne beginnen können.

Nachdem in Skalierungsebene III der „convergence treshold value“ j erreicht wurde,

wird aus den übriggebliebenen Punkten mit dem „Topo to Raster“-Tool das resultieren-

de DGM berechnet.

B) Das Anwenderformular und ergänzende Codeteile

Löschen der temporären „Shapefiles“

Nach der Berechnung des DGMs durch das „Topo to Raster“-Tool wird vom Skript ein

kleines Unterskript aufgerufen, welches, sofern der Anwender dies im Anwenderformu-

lar (Abb. 29) gewünscht hat, alle während der DGM-Berechnung entstandenen temporä-

ren Files, die nun nicht mehr benötigt werden, löscht.

Beseitigen der überflüssigen Layer von der aktuellen Ansicht

Durch dasselbe Skript werden alle Rasterdateien und „Shapefiles“, die während der Be-

rechnung des DGMs automatisch dem View hinzugefügt wurden, wieder entfernt. Das

Unterskript wird, wenn es vom Anwender aktiviert wurde, am Ende des oben bespro-

chenen Algorithmus automatisch aufgerufen.

Präiterative Reduktion der Punktzahl in großen Datensätzen

Wie Abb. 30 zeigt, gibt es im Anwenderformular der DGM Berechnung eine Option zur

präiterativen Beseitigung von Punkten („Use preiterative elimination of points“). Wird

diese Funktion aktiviert, erscheint nach Klicken des „OK“-Buttons ein Pop-Up-Fenster

(Abb. 31), welches zusätzliche Eingaben fordert. Auf diese Funktion soll anhand von

Code 9 noch etwas näher eingegangen werden.

' call Point Statistics tool from toolbox

Call gp.PointStatistics_sa(in_point, "ZCoor", out_raster, cs_preit, unit_and_size, "MINIMUM")

' call Extract Values to Points...

Call gp.ExtractValuesToPoints_sa(in_point, out_raster, out_point, "NONE", "VALUE_ONLY")

' call Select by attributes from toolbox

Call gp.Select_analysis(out_point, result, "( ""ZCOOR"" - 0.3) < ""RASTERVALU""")

' hide und unload the form

calc_DGM_preiteration.Hide (1/2)


Unload calc_DGM_preiteration

' call the first round of the DGM calculation

Call round1_preit

End Sub (2/2)

Code 9: Teil des Skripts zur präiterativen Elimination von Punkten

Der Sinn dieser Funktion besteht darin dem Anwender die Möglichkeit zu geben bereits

vor Beginn des Klassifizierungsalgorithmus eine größere Anzahl an Punkten des Rohda-

tensatzes zu eliminieren und damit den Klassifizierungsvorgang zu beschleunigen. Dies

kann insbesondere bei großen Rohdatenmengen von Vorteil sein.

Code 9 zeigt den entscheidenden Teil des Skripts: Zu Beginn wird das Tool „Point Sta-

tistics“ aus der Toolbox eingesetzt um eine Rasterdatei zu erstellen, welche in jeder Flä-

che a den Wert desjenigen Punktes innerhalb des Pixels annimmt, der eine minimale

Höhe aufweist (Abb. 32). Die Größe der Fläche a wird durch die vom Anwender festge-

legten „Neighbourhood settings“ bestimmt. Die darin angegebene Fläche plus die dazu-

gehörende Einheit (Wahl zwischen Karteneinheiten (z. B. m, km, etc.) und Pixeln) lie-

fern alle nötigen Angaben.

Abb. 30: Das Anwenderformular zur DGM Berechnung


Anschließend wird mit dem Tool „Extract Values to Points“ jedem Punkt des Eingangs-

„Shapefiles“ der Pixelwert (der jeweiligen Fläche a) seiner jeweiligen Position in einer

neuen Spalte in der Attributstabelle zugewiesen. Hiernach folgt der Vergleich zwischen

dem ursprünglichen z-Wert und dem Pixelwert, der gleichzeitig dem z-Wert des nied-

rigsten Punktes innerhalb des Pixels entspricht. Mit dem Select-Tool werden anschlie-

ßend nur die Punkte selektiert, die in einem kleinen Bereich (dieser Bereich entspricht

dem „Buffer“ im Anwenderformulars) um den Pixelwert herum liegen (z.B. Pixelwert +

0.3m). Diese Punkte werden in ein neues „Shapefile“ kopiert und gehen dann wieder in

den normalen Klassifizierungsalgorithmus ein.

Abb. 31: Präiterative Eliminierung von Punkten

Abb. 32:“ Point Statistics Tool“ - Arbeitsweise


Im Beispiel in Abb. 32 würden auf diesem Wege bereits 7 der 10 Punkte eliminiert wer-

den. Es muss aber erwähnt sein, dass diese Methode natürlich auch die Gefahr von stär-

keren Ungenauigkeiten und einer verringerten Auflösung des DGM in sich birgt. Es

muss daher je nach Untersuchungsziel und Datensatz entschieden werden, ob die Funk-

tion der präiterativen Elimination von Punkten genutzt werden soll oder nicht.

Die Verwendung von Gebäude Polygonen

Nach einigen Testläufen mit unterschiedlichen Datensätzen zeigte sich, dass der bis zu

diesem Zeitpunkt bestehende Algorithmus in bewaldeten Gebieten gute Ergebnisse lie-

ferte. Allerdings wurde in urbanen Gebieten deutlich, dass das Skript noch Probleme hat

Gebäude vollständig heraus zu rechnen. Um dieser Problematik gerecht zu werden,

wurde als letzte Ergänzung des DGM-Berechnungs-Modul eine Option zur Verwen-

dung von Gebäude Polygonen hinzugefügt. Diese Option (siehe Abb. 30) ermöglicht es

die Rohdatenpunkte, die Reflektionen auf Gebäuden darstellen, bereits vor Start des

DGM-Algorithmus zu entfernen. Hierfür wird ein Polygon-“Shapefile“ mit den Grund-

rissen der jeweiligen Gebäude benötigt. Diese Grundrisse werden dann als eine Art

Schablone / Ausstecher-Form benutzt, um die betroffenen Punkte aus der Rohdaten-

punktewolke auszuschneiden und zu löschen.

Geschichte

Die Notwendigkeit und Bedeutung eines DGM-Berechnungsmoduls war von Beginn

der Planung des FELIS-Analysts an klar. Da der Entwurf eines komplett eigenständigen

Ansatzes zur Extraktion der Bodenpunkte aufgrund der knapp bemessenen Zeit unrea-

listisch war, lag es nahe sich nach bereits vorhandenen Ansätzen umzusehen. Der An-

satz von Evans und Hudak erschien für die gesetzten Ziele optimal zu sein. Der frei ver-

fügbare eml-Code sowie die Tatsache, dass das Programm für ein ESRI-Produkt ge-

schrieben wurde, verminderten den Programmieraufwand enorm.

Zum besseren Verständnis des Codes und der Arbeitsweise des Programms wurden zu

Beginn alle Schritte einer einzelnen Iteration manuell durchgeführt. Anschließend wur-

den diese manuellen Schritte im Model-Builder von ArcMap zu einem automatisch ab-

laufenden Model zusammengefasst.

Dieses Model war - exportiert zu VB-Script - die Grundlage für das DGM-Modul in

der heute vorliegenden Form. Nach diversen Anpassungen und Entwurf eines Anwen-

derformulars war eine erste Version funktionsfähig. Während der Arbeit mit dieser ers-

ten Version wurden vier gravierende Mängel festgestellt:


1. Der Anwender wurde nicht über den aktuellen Stand der Berechnung aufgeklärt

2. Die Berechnung von DGMs für größere Flächen war enorm zeitintensiv

3. Der Algorithmus hatte Probleme mit sehr flachen Testgebieten

4. Der Algorithmus zeigte Schwächen in Gebieten mit Gebäuden

Das erste Problem wurde durch Hinzufügen einer ausführlichen Statusanzeige erfolg-

reich beseitigt. Der Anwender wird nun darüber informiert in welcher Skalierungsebene

er sich befindet, die wievielte Iteration aktuell läuft und wie viele Punkte in der letzten

Iteration eliminiert wurden.

Das zweite Problem wurde durch Einfügen der eben besprochenen Funktion zur präite-

rativen Eliminierung von Punkten angegangen. Diese Verbesserung zeigte auch Wir-

kung und konnte die Rechendauer teilweise um bis zu 85% verringern. Allerdings bet-

rug die Restzeit z.B. für ein Gebiet mit der Ausdehnung von 1 x 1 km und 300 000

Rohdatenpunkte immer noch 30 min.

Die Funktion zur präiterativen Eliminierung von Punkten zeigte auch positive Auswir-

kungen auf das dritte genannte Problem. Allerdings konnte dieses Problem bis heute

noch nicht vollständig gelöst werden. In Datensätzen, in denen die Vegetation an man-

chen Stellen so dicht ist, dass keine direkten Bodenpunkte mehr erfasst wurden und de-

mentsprechend auch keine Laserpunkte vorhanden sind konnte der Algorithmus größere

Fläche nicht korrekt interpolieren. Grundsätzlich stellt sich hier aber auch die Frage, ob

das ein Problem des Algorithmus ist oder ein Problem, dass sich aus der Qualität der

Daten ergibt. Vergleiche mit der LiDAR-Software TreesVis haben gezeigt, dass auch

hier an denselben Stellen Probleme auftraten, obwohl TreesVis deutlich mehr Möglich-

keiten bietet den Algorithmus an die jeweiligen Geländebegebenheiten anzupassen.

In einigen Testgebieten, die ebenfalls sehr flach waren, die Dichte der Bodenpunkte

aber höher war, arbeitete der Algorithmus des FELIS-Analyst gut.

Das vierte genannte Problem wurde als letztes mit Einführung der Option „Verwendung

von Gebäudepolygonen“ beseitigt. Wenn der Anwender ein Polygon-“Shapefile“ mit

der Lage der Gebäude besitzt, kann er dies verwenden, um die betroffenen Rohdaten-

punkte bereits vor Berechnung des DGMs zu entfernen. Oftmals stehen dem Anwender

z.B. Katasterdateien des jeweiligen Testgebietes zur Verfügung. Als Alternative ist auch

die Digitalisierung der deutlich sichtbaren Gebäude aus dem DOM denkbar. Außerdem

ist auch der Einsatz des von D. Montwe geschriebenen Moduls zur Extraktion von Ge-

bäudegrundrissen möglich, welches ebenfalls in den FELIS-Analyst integriert wurde.


Hintergrundinformationen

Es gibt mehrere verschiedene Ansätze, um aus der Originalpunktewolke der LiDAR-

Befliegung die Bodenpunkte zu extrahieren. Pfeifer (2008) unterteilt die Ansätze in Me-

thoden die sich mit

a) Block Minimum Filtern

b) Oberflächenbasierte Filtern

c) Progressive Verdichtung

d) Auf Segmentierung basierende Filtern

auseinandersetzen.

a) Block Minimum Filter

Bei den Block Minimum Filtern handelt es sich um ein einfaches System. Über die vor-

handene Laserpunktwolke wird ein Gitternetz mit quadratischen Maschen gelegt. Inner-

halb von jedem Quadrat wird der Punkt mit dem minimalen Höhenwert bestimmt. Die-

ser Punkt wird beibehalten und alle anderen Punkte werden verworfen. Aus allen beibe-

haltenen Punkten wird zuletzt eine Oberfläche interpoliert, die dann das DGM darstellt.

Dieser Filter kann in relativ flachem Gelände vernünftige Resultate liefern. Sobald das

Gelände bewegt ist, versagt er, da dann Punkte, die auf Grund der Tatsache, dass sie

sich ein Stück weiter oben am Hang befinden verworfen werden.

b) Oberflächenbasierte Filter: Beispiel „Robuste Filter“

Bei oberflächenbasierten Filtern wird zu Beginn der Filterung eine Oberfläche berech-

net, bei der alle Punkte gleich gewichtet sind. Diese Oberfläche liegt dann mitten in der

Punktwolke. Dabei liegen Bodenpunkte normalerweise unterhalb dieser Oberfläche und

Vegetationspunkte bzw. Reflektionen anderer Objekte oberhalb der Oberfläche.

Basierend auf dieser Erkenntnis werden nun alle Laserpunkte nach Abstand und Rich-

tung zur Oberfläche gewichtet. Punkte unterhalb der Oberfläche werden stärker gewich-

tet, Punkte oberhalb der Oberfläche schwächer bzw. ab einem bestimmten Abstand

komplett verworfen.

Nach der Gewichtung erfolgt wiederum eine Interpolation, die eine neue Oberfläche

zum Resultat hat. Mit dieser neuen Oberfläche beginnt der Prozess von vorne. Die

Oberfläche wandert im Laufe der Iterationen immer weiter nach unten und spiegelt im

Idealfall zum Schluss das Gelände wieder.


Oberflächenbasierte Filter liefern bei einem ausgewogenen Verhältnis von Boden zu

Vegetationspunkte gute Resultate. Die Ergebnisse und die Geschwindigkeit des Filter-

algorithmus können durch hierarchische Strukturen verbessert werden.

Unter hierarchischen Strukturen versteht man z.B. das kontinuierliche Verkleinern der

Zellgröße bei der interpolierten Oberfläche. Die Verwendung von eher großen Zellgrö-

ßen zu Beginn beschleunigt die Filterung. Eine andere hierarchische Struktur wäre die

Verwendung von Pufferbereichen. D.h. nach der Berechnung eines groben ersten

DGMs werden nur noch Punkte in die weitere Filterung einbezogen, die sich in einem

bestimmten Puffer um diese Oberfläche befinden. Alle anderen werden verworfen. Die-

ser Pufferbereich wird dann in jeder Iteration verkleinert.

c) Progressive Verdichtung: Beispiel TIN Verdichtung

Das Prinzip der progressiven Verdichtung beruht darauf, dass zu Beginn der Filterung

einige Punkte gewählt werden, die aller Voraussicht nach Bodenpunkte sind. Diese

Punkte werden zu einem Netz aus Dreiecken zusammengeschlossen. Zu Beginn ist die-

ses Netz relativ weitmaschig. Anschließend werden nach und nach benachbarte Punkte

in das Netz eingeschlossen, wenn sie bestimmte Parameter bezüglich Abstand und Rich-

tung erfüllen und das Netz wird dichter. Der Filter arbeitet ebenfalls iterativ.

d) Auf Segmentierung basierende Filter

Segmentierung bedeutet in diesem Fall, dass man versucht verschiedene Rohdatengrup-

pen aus der Gesamtheit zu extrahieren. Man erstellt kleinere Untereinheiten, die gleiche

Merkmale aufweisen. Die Hauptidee besteht darin, dass überall in der Punktewolke

kleine Oberflächen berechnet werden, die bestimmte Strukturen aufweisen. Diese klei-

nen Oberflächen entstehen an einer sogenannten „Quellregion“ („seed region“) und

wachsen dann iterativ an. Anschließend werden diese Oberflächen klassifiziert.

Fazit

Alle beschriebenen Ansätze haben Vor- und Nachteile, die auch stark von den Eigen-

schaften des Geländes sowie der Datenqualität abhängen. Grundsätzlich gibt es keinen

Filteralgorithmus, der zu hundert Prozent zufriedenstellend arbeitet und ohne weitere

manuelle Verbesserungen zu idealen Ergebnissen führt. Es hat sich gezeigt, dass Algo-

rithmen allgemein verbessert werden können, wenn sogenannte Bruchkanten im Gelän-

de berücksichtigt werden. Unter Bruchkanten versteht man abrupte Änderungen des

Geländes, die im Allgemeinen von Algorithmen nur schwer erkannt werden können,

insbesondere wenn der eigentliche Zweck des Algorithmus darin besteht eine interpo-


lierte Oberfläche als Endergebnis zu haben. Erste Ansätze, die Algorithmen zur Erken-

nung von Bruchkanten mit Filteralgorithmen zur Extraktion von Bodenpunkten verbin-

den, scheinen vielversprechend zu sein.

5.6.3 nDOM

Zweck

Das normalisierte digitale Oberflächenmodell stellt eine interessante Kombination aus

DOM und DGM dar. Durch das Subtrahieren der Höhenwerte, die in einem DGM ge-

speichert sind von den Höhenwerten eines DOMs, welches dieselbe Fläche bedeckt,

entsteht ein normalisiertes Oberflächenmodell. Das Resultat dieser Rechenoperation ist

ein Oberflächenmodell, aus dem sich die Höhen von Objekten direkt abfragen lassen.

Dies ist logisch, da das DGM die Höhe des Bodens wiederspiegelt und das DOM die

Höhe der auf dem Boden existierenden Objekte. Kurzes Beispiel: Der Waldboden an

einer bestimmten Position im Schwarzwald hat eine Höhe von 822m über NN. Die Spit-

ze des Baumes, der exakt an dieser Position steht hat die Höhe 845m über NN. Wenn

man nun die im DGM gespeicherte Höhe des Waldbodens von der im DOM gespeicher-

ten Höhe der Baumspitze subtrahiert erhält man die Höhe des Baumes, welche in die-

sem Fall 23m betragen würde. Das nDOM enthält demnach keine absoluten Höhen, mit

Bezug auf Meeresniveau sondern relative Höhen, die sich eben auf die Erhebungen

oberhalb des Reliefs beziehen.

Ähnlich wie bei den zwei anderen bereits besprochenen digitalen Höhenmodellen sind

die Verwendungsmöglichkeiten eines nDOMs sehr vielfältig. Durch das direkte Extra-

hieren von Objekthöhen können z.B. Waldbestände klassifiziert werden (in bewirtschaf-

teten Wäldern zeichnen sich zusammengehörende Bestände heute vielmals noch durch

ähnliche Oberhöhen aus), Höhen von Gebäuden bestimmt werden und vieles anderes

mehr. Auch in weiterführenden Analysen, wie z.B. der Bestimmung von Holzvolumen

in Beständen kann das nDOM eine wichtige Eingangsgröße sein.

Aufbau

Der Aufbau des Moduls zur Berechnung des nDOM knüpft wiederum an das in Kapitel

5.4.1 ausführlich besprochene Skript an. Das verwendete Tool führt eine Subtraktion

des DGMs vom DOM durch. Abb. 33 zeigt das Anwenderformular des Moduls. Auch

hier gibt es – identisch wie bei der DOM und DGM Berechnung – die dreigeteilte Defi-

nition des zu berechnenden ausgehenden Bildes. Da auf diese Besonderheit bisher nur

kurz eingegangen wurde, soll Code 10 die Auswirkungen dieses Formularaufbaus erläu-

tern. Alle anderen Teile sollten bereits erwähnt und erklärt worden sein.


Dim str_extension1 As String

If cb_fileformat = "ESRI GRID" Then str_extension1 = ""

If cb_fileformat = "TIFF" Then str_extension1 = ".tif"

If cb_fileformat = "IMAGINE FILE" Then str_extension1 = ".img"

' creates the geoprcessor

Dim gp As Object


'create and define in- and output variables

Dim inRaster1 As String

Dim inRaster2 As String

Dim outRaster As String

inRaster1 = txt_Calc_nDOM_input_DOM.Text

inRaster2 = txt_Calc_nDOM_input_DGM

outRaster = txt_Calc_nDOM_output & "\" & txt_Filename_nDOM.Text & str_extension1

Call gp.Minus_sa(inRaster1, inRaster2, outRaster)

Code 10: Teil des Skripts zur Berechnung von nDOMs.

Die Folgen der dreigeteilten Definition des zu berechnenden Bildes finden sich vor al-

lem in den folgenden Zeilen

If cb_fileformat = "ESRI GRID" Then str_extension1 = ""

If cb_fileformat = "TIFF" Then str_extension1 = ".tif"

If cb_fileformat = "IMAGINE FILE" Then str_extension1 = ".img"

Diese drei if-Syntaxen definieren, je nachdem welches Bildformat vom Anwender im

Formular ausgewählt wurde (das entsprechende Drop-Down-Menü trägt den Namen

cb_fileformat), den Inhalt der Variable str_extension1 mit „.img“, „.tif“ oder „“. Die

Variable str_extension1 fließt dann in der Zeile

outRaster = txt_Calc_nDOM_output & "\" & txt_Filename_nDOM.Text & str_extension1

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)


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


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.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


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



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


Geschichte


Abb. 35: Beispiel für ein berechnetes „Hillshade-Image“.


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


Geschichte


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.


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


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.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:


• 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


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


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


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


will be directly in the correct folder where the coordinate systems are stored, or you

have to browse for the folder:

X:\YourInstallationPath\ArcGIS\Coordinate Systems\

In this location you will find the “DHDN 3 Degree Gauss Zone 3.prj” we use in our

example in the folder: \Projected Coordinate Systems\National Grids\. After you found

the suiting coordinate system select it and press “OK ”.

Then press “OK ” again in the form, and the projection will be added to the shapefile.

After this, your shapefile has a defined projection. If you want to check if the tool

worked properly, you can perform a “right-click” on the shapefile, choose “properties”

and in the section “source” you can have a look at the defined projection of the file.

Repeat this step with the other three files.

Step 4: Merging Raw Data Shapefiles

Until now you have four different raw data shapefiles. Now we will reduce the number

to two. Two of the datasets consist of first pulse (FP) raw data and the other two of last

pulse (LP) raw data. It is quite common that raw data is delivered separated in FP and

LP datasets. Since our datasets are separated in LP and FP and additionally in ground

and vegetation points we will now merge the ground and vegetation points of the LP

and the FP datasets. As a result we will have one file containing all FP–points and one

containing all LP-points. To do this we select “Raw Data” �� “Merge” from the FA

menu. A new window will appear (Fig. 5).

�

Fig. 4: Georeferencing


In the appearing userform we will have to define the datasets we want to merge by se-

lecting them from the drop down menu “Input Feature Datasets” or using the -

button next to the field. We press the “+”-button to add the dataset to the list of fea-

tures to be merges. In our case we will add the two FP-files to the list. So we select

“fp_ground” and “fp_vegetation”. As last step we define an “Output-Feature” in the

bottom field for example: “D:\Tutorial\fp_all.shp”. Finally we press “OK ” and the two

shapefiles will be merged to one new file.

The whole procedure might take a few minutes since the shapefiles we merge are pretty

big (about 70MB each).

Repeat this step with the LP-datasets.

Step 5: Selection of Raw Data Points

To select raw data points we choose “Raw Data” �� “Selection” from the FA menu.

This will bring up the window illustrated in Fig. 6. As you can see three types of selec-

tion are possible. One can select all points above a certain height, below a certain height

and between two heights.

�

Fig. 5: Merge Raw Data


In our example we use the option “above _____ m height”. As “Input file ” we define

the “fp_all.shp”. For “field containing z-values” we select “ZCoor”. Also we have to

define a name for our selection because the selected points will be saved in a tempo-

rary layer file which needs a name. Optionally we can define a name for an output-

shapefile (“Output file ”). If we define a name our selection will be saved in a new sha-

pefile. If we leave this line blank the selection will only be saved temporarily. In our

case we leave the line blank since our example has no further meaning for the tutorial

and we just want to present how this tool works.

�

Fig. 6: Raw Data Selection

Fig. 7: ArcMap after the Selection


So as our last input we enter the number “530” in the “above _____ m height” line and

press the “Select” button next to this line. After this we close the “Selection” window

and Fig. 7 shows the results of our selection. All points over 530m height lay in one

specific area on the right border of the picture. Press the -button in the “tools”-toolbar

of ArcMap to clear the selection.

Step 6: DTM Calculation

In this next step we will calculate a DTM model. To reach the “DTM Calculation”-

module we select “calculation” �� “calculate DTM ” from the FA menu (Fig.7). A

new window will appear. As already explained in the diploma thesis it is recommenda-

ble to use a “last pulse” – raw data set to calculate the DTM. Normally all ground points

should be “last pulse” points, although of course not all “last pulse” points are ground

points. To get rid of the “last pulse” points that are no ground points we have to use the

DTM calculation tool (as seen in Fig.8).

The input file (“Input Feature Data”) will be the “lp_all.shp” file. The field contain-

ing the z-Values will be “ZCoor”. As curvature threshold we will choose “0.3”. And

for cell size we select “1”m. For output file we have to select any folder, a filename and

an extension. We will create a tiff file in our example. As final steps in the first form,

we will check the marks next to “Delete intermediate files” and “use preiterative eli-

mination of points”.

Since our dataset contains more than 700 000 points, what is a quite big number within

ArcMap, the DTM calculation will take quite a while. To speed it up a bit, we will make

use of the “preiterative elimination of points”. We can see the second form, dealing

with this function in Fig. 7. In our case we select a size of 2 by 2 cells and a buffer of

0.5. Those inputs are rather moderate, since we don’t want to lose too many points in

Fig. 7: FA menu - DTM


the first step. As explained in the diploma thesis the “preiterative elimination of points”

will find the minimum value in each 2 by 2 cells and will only keep those values/points

that are within 0.5m (= “buffer ”) above this value. All other values/points will be de-

leted. After this process the DTM algorithm starts. We can start the whole process by

clicking “OK ” first in the DTM calculation form and then in the “preiterative elimina-

tion of points” form. After this ArcMap might look like if it crashed, but it should be

working in the background. The whole calculation will take up to two hours, depending

on the speed of your computer. As soon as the process “preiterative elimination of

points” has ended you will see the process of the calculation in the “progress” box of

the DTM calculation form. The whole calculation has three scale domains and in each

scale domain up to 20 iterations. Although most of the time the algorithm will jump to

the next scale domain earlier (have a look at the percentage number, as soon as 99.99%

is reached, the algorithm will jump to the next scale domain). Fig. 9 illustrates ArcMap

after the calculation process.

�

Fig. 8: DTM Calculation forms


A more typical way of illustrating a DTM is to “stretch” it - that means without classes.

To display a DTM stretched we have to perform a right-click on the DTM_1m entry in

the “Layers” list and select “Properties”. Then we have to choose “Symbology” and

select stretched in the list on the left side (Fig. 10). Fig. 11 displays the just calculated

DTM in the stretched view. In the stretched view you can see a lot more details.

Fig. 9: After the DTM calculation process (DTM in classified view)

Fig. 10: select stretched view for DTM


Step 7: DSM Calculation

The DSM calculation is a lot easier than the DTM calculation as you can already see by

looking at the form in Fig. 12. You only have to define the input-shapefile, the field

containing the z-Value and a cell size. After this the tool will calculate a DSM. For this

calculation a simple “topo to raster”-interpolation is sufficient. To reach the “DSM Cal-

culation”-module we choose “Calculation” �� “calculate DSM” from the FA menu

(Fig. 12). This will lead to a new form.

Fig. 11: DTM in stretched view

�

Fig. 12: The DSM form


Here we will have to use the file “import_rawdata_fp.shp” as “Input Feature Data”.

Since the DSM should display all objects on top of the ground, we use first pulse-points

(normally the first reflections of the laser beam represent points that are part of objects

that stand on the ground). In our case we should also choose a “cell size” of 1 m to fit

the already calculated DTM. The field containing the z-Values is again the “zCoor”

field. At last we define an output folder a filename and for file extension we select “tiff”

(output files have to be defined almost every time; we won’t repeat this explanation for

all modules/tools).

After this we are ready to press “OK ”. The calculation might take some seconds, but

should be a lot faster than the DTM calculation.

Fig. 13 shows ArcMap after the calculation. You can see a lot of similarities to the

DTM but there are also slight differences. Those differences will be even clearer in the

stretched view of the DSM illustrated in Fig. 14. To stress the differences between DSM

and DTM Fig. 15 shows a direct comparison of the two files. All the little clouds in the

DSM represent Objects – in our case vegetation – on top of the ground surface.

Fig. 13: The DOM in the classified view after the Calculation


Step 8: nDSM Calculation

The calculation of the nDSM is even simpler than the DSM calculation. To calculate an

nDSM we need a DTM and a DSM of the same area. Then we simply subtract the DTM

from the DSM. To do this we will load the DSM module by choosing “Calculation” ��

Fig. 14: DOM in stretched view

Fig. 15: DOM / DGM in comparison


“Calculate DSM” from the FA menu (Fig. 16). In the new window we only have to

choose an “input DSM” (our just calculated “dsm_1m.tif”) an “input DTM ” (our just

calculated “dtm_1m.tif”) and an output filename, folder and format type.

After this we press “OK ” and the nDSM will be calculated. Fig. 17 shows the resulting

nDSM. The nDSM illustrates the heights of all Objects in the area - the brighter the area

the higher the objects.

�

Fig. 16: Calculate nDOM form

Fig. 17: the nDSM in stretched view


Step 9: Create Aspect Image

With step 9 we will now enter the analysis tools. To reach the “Create Aspect Image”-

module we will have to select “Analysis” �� “Create Aspect Image” from the FA

menu, this will lead to a new window (Fig. 18).

The aspect image will calculate the direction of each slope. So it will be possible to find

areas that are sunnier than others, because they are heading towards southwest – and are

therefore getting a huge amount of sun every day. This information might give possibili-

ties to guess the vegetation at these sunny locations. In Fig. 19 you can see an aspect

image with adapted layer settings. All directions but South and Southwest were colored

in blue, while the “sunny” directions were colored reddish. For this result we chose the

earlier calculated DTM as “Input Raster”.

�

Fig. 18: Create Aspect Image form

Fig. 19: Aspect Image with adapted layer settings


You might switch between the DTM and the aspect image to have a better imagination.

Of course it also possible to use a DSM for input. The resulting aspect image will be

rather coarse with few continuous aspect areas – this is obvious since vegetation goes up

and down within meters and without any regularities. Using a DSM for input can be

interesting for extracting roofs of buildings that are heading towards South. Those roofs

might be interesting for solar collectors.

Step 10: Create Slope Image

To reach the “Create Slope Image”-module we have to select “Analysis” �� “Create

Slope Image” in the FA menu, then a new window will appear (Fig. 21). The create

slope-tool will create an image in which each pixel will have the value of the fall of

each position. So the image will tell us how steep the slope at every position is.

Fig. 22 shows the slope image of the DTM we calculated earlier. All the green areas in

the image are rather flat while the redder it gets the steeper it is. It might be interesting

to mention that outlines of houses would appear in a red line, since the walls normally

have a slope fall of 90°.

To reach the result in Fig. 22 we have to define an input-file, which in our case would

be the earlier calculated DTM file. You also have to choose if you want to have the re-

sult in “Degrees” or “Percentage Rise”. And finally you have the option to define a z-

�

Fig. 21: The Create Slope Image form


value. The z-value allows you to generalize the result. If you select a z-value of 2 the

resulting image will have pixels with x = 2 pixel and y = 2 pixel of the input file. This

will lead to a coarser and rougher result, but in case of Slope fall values this might be

wanted.

As you can see in Fig. 22 some of the paths and forest roads are well recognizable in the

slope image.

Step 11: Create Hillshade Image

To reach the “Create Hillshade Image”-module we will have to select “Analysis” ��

“Create Hillshade Image” in the FA menu - then a new window will appear (Fig. 23).

The hillshade image can be helpful to create more detailed views of the calculated ele-

vation models. The shadows and differing light intensities will result in a more natural

view of the models. To create a hillshade image as seen in Fig. 24 we have to define

several inputs: First of all an “Input Raster” from which we want to create the hill-

shade image. In our case we will again select the earlier calculated DTM file. Next up

we have to define an “Azimuth angle of the light source”. In our example we choose

180° what means South, North would be 0°/360°. The “Altitude angle of light source”

defines how high over the ground the light source is situated. We chose 60° here. This

Fig. 22: Slope Image of our DTM file


would be about the settings for the sun on a Middle European summer day at around

noon. Again we can define a z-value; it has the same meaning as already described in

the “Slope Image” module. As a last input we have to define whether we want to calcu-

late shadows or not. If not, only the differing light intensities will be visible in the re-

sulting image and the effects of shadows won’t be considered. In our case we select to

calculate the shadows. Fig. 24 shows the results of our inputs. The hillshade image

shows a lot more details in comparison to the DTM.

�

Fig. 23: The Create Hillshade form

Fig. 24: The Hillshade Image created from a DTM


Step 12: Create Contour Lines

To reach the “Create Contour Lines”-module we will have to select “Analysis” ��

“Create Contour Lines” in the FA menu - then a new window will appear (Fig. 25).

As “Input Raster” we define the DTM again, since the contour lines are most common

to illustrate the change of height in a terrain without any objects on top of it. As “Con-

tour Interval” we select 10. Here you can use any natural number you like. Unit is map

units. In the field “Base Contour” you can select a starting point for the contour lines.

In our case we leave this field blank. And again you can define the already known “z-

factor”.

After you made all your inputs and press “OK ”, ArcMap will calculate the Contour

Lines and save them into a shapefile. In Fig. 26 you can see the contour lines over the

DTM. As you can see the lines fit the color ramp of the DTM really well.

�

Fig. 25: The Create Contour Lines Form


Step 13: Export to Google Earth

To reach the “Export to Google Earth”-module we will have to select “Analysis” ��

“Export to Google Earth” in the FA menu - then a new window will appear (Fig. 27).

In the form you can select from all active Layers in the view and additionally from

layerfiles on your disc for “Input File ”. The only further field you have to fill out is the

“Scale” field. All other fields are optional. Find more information on those inputs in the

online help. Use the “?”-Button to get there. The tool will save a .kmz-file that will

visualize the extents of the chosen Layer in Google Earth.

Fig. 26: Contour Lines over DGM, additionally added the Heights and a color ramp using the

“Properties” � “Symbology” dialogue. The red areas represent higher areas.


Step 14: Georeference digital elevation models

To georeference digital elevation models we have to choose “DSM / DTM / nDSM” ��

“Georeferencing” from the FA menu - then a new window will appear (Fig. 28). For

all further details please have a look at Step 3. The two modules are identical besides

the fact that in Step 3 the input file is a shapefile and in Step 13 it is a rasterfile.

�

Fig. 27: Export to Google Earth form

�

Fig. 28: Georeference digital elevation models form


Step 15: Export to TreesVis

To export digital elevation models to TreesVis we have to choose “DSM / DTM /

nDSM” �� “Export to TreesVis” from the FA menu - then a new window will appear

(Fig. 29).

Here we simply have to define the elevation model we want to export. The model will

then be exported to an ASCII-Info-GRID. This format can be read by the LiDAR-

Software TreesVis. You can also open this file type with a normal windows editor. Fig.

30 shows the DSM file of the earlier calculation opened in TreesVis.

�

Fig. 29: Export to TreesVis form

Fig. 30: The exported DSM in the TreesVis 3D View


Step 16: Normalize Raw Data

After we calculated a DTM we will be able to normalize our raw data. After this process

the height-values of each LiDAR-point will represent its actual height above the ground

(not above NN).

To normalize raw data we have to choose “Raw Data” �� “Normalize Raw Data”

from the FA menu - then a new window will appear (Fig. 31).

Here we will have to define an input-raw dataset and an input DTM-file that covers the

same areas as the raw dataset. For “Input Feature Data” we select the “fp_all”-

shapefile and for “Input DTM ” we will choose the earlier calculated “dtm_1m” .tiff-

file. As last step we have to define a path and a filename for an output feature class or

shapefile – for example “D:\Tutorial\fp_all_normalized.shp”. After this we are ready to

start the normalization process by clicking “OK ”. The normalization of the Raw Data

will take several minutes, since our dataset is rather big for ArcMap. The “progress”-

box will keep you up to date with the actual progress of the script. After the script has

finished you will find an additional field within the attribute table of the new created

“fp_all_normalized”-shapefile containing the normalized z-values. Since the new z-

values are calculated by subtracting the earlier calculated DTM from the Raw Dataset it

might happen that some of the values are negative due to little calculation errors and

rounding in the DTM-calculation process.

�

Fig. 31: Normalie Raw Data

Anhang C: Hard- und Softwarevoraussetzungen 110

Anhang C: Hard- und Softwarevoraussetzungen

Der FELIS-Analyst wurde auf einem Fujitsu-Siemens Amilo Notebook (Model: PI

3540) programmiert und getestet. Technische Daten des Notebooks:

Prozessor: Intel Core 2 Duo P8600 (2,40 GHz)

Arbeitsspeicher: 4096 MB, DDR2-800

Grafikchip: Nvidia Geforce 9300M GS, 256 MB

Betriebssystem: Windows VISTA Home Premium

Eine wichtige Voraussetzung um die Funktionsfähigkeit des FELIS-Analysts zu garan-

tieren, ist der korrekt gewählte Dezimalseparator in den Regionseinstellungen des Be-

triebssystems. Dieser muss auf Komma eingestellt sein (deutsche Einstellungen).

Es wurde versucht innerhalb des Programms ein Skript zu implementieren, das die Ein-

gaben des Anwenders automatisch - abhängig von den Einstellungen in der System-

steuerung – korrigiert, dennoch empfiehlt es sich von vorneherein diese Einstellungen

zu verwenden.

Zusätzlich sollte der Anwender grundsätzlich vollen Lese- und Schreibezugriff auf das

jeweilige Ziellaufwerk für die ausgehenden Dateien besitzen.

ArcGIS bzw. ArcMap wurde in der Version 9.3 mit einer ArcEditor-Lizenz verwendet.

Für die Nutzung der im Rahmen dieser Arbeit erstellten Module ist teilweise eine Spati-

al-Analyst-Lizenz nötig. Für die Module im Menü „Extraction“ wird der Spatial-

Analyst, der 3D-Analyst sowie eine ArcINFO-Lizenz benötigt.

Glossar 111

Glossar

ASCII: Ein Dateiformat für Textdateien mit einer 7bit-Zeichenkodierung.

DGM (engl. DTM): Unter einem DGM bzw. DTM versteht man ein „Digitales Gelän-

demodell“ (Digital Terrain Model). Dieses Modell zeichnet das Relief des Geländes

nach. Dabei werden alle Objekte, die auf dem Grund stehen herausgerechnet und nur

der plane Boden wird abgebildet. DGMs liegen oftmals als Rasterdateien vor.

DOM (eng. DSM): Unter einem DOM bzw. DSM versteht man ein „Digitales Oberflä-

chenmodell“ (Digital Surface Model). Dieses Modell bildet die Erdoberfläche inclusive

aller Objekte darauf ab. DOMs liegen ebenfalls i.d.R. als Rasterdatei vor.

Kernel: Eine mathematische Rechenoperation innerhalb eines Rasterbildes. Ein Kernel

ist eine Matrix aus einer ungeraden Anzahl an Bestandteilen. Diese Matrix (z.B. ein

Gitter von 3 x 3 Pixeln) läuft über das Rasterbild und berechnet den jeweils in der Mitte

des Kernel liegenden Pixel des Rasterbildes neu. Dabei werden die Werte der umlie-

genden Pixel innerhalb der Matrix für die Berechnung verwendet (z.B. Mittelwert oder

Lokales Minimum, Maximum etc.).

nDOM (eng. nDSM): Unter einem nDOM bzw. nDSM versteht man ein „normalisier-

tes Digitales Oberflächenmodell“ (normalized Digital Surface Model). Normalisiert

bedeutet, dass die in der Rasterdatei abgespeicherten Höhenwerte der Objekte den tat-

sächlichen Höhen der Objekte vor Ort entsprechen. In einem nDOM sind also die relati-

ven Höhen zum Erdboden angegeben und nicht die absoluten Höhen über Niveau Null.

Ein nDOM wird berechnet, indem man das DGM vom DOM abzieht.

Rasterdatei (eng. rasterfile): Eine Rasterdatei ist ein aus Pixeln (Quadrate gleicher

Flächengröße) aufgebautes Bild.

Rohdaten (engl. raw data): Rohdaten nennt man die 3D-Punktewolken, die aus einer

Laserscannerbefliegung oder einem terrestrischen Laserscan resultieren und in ver-

schiedenen Dateiformaten gespeichert sein können.

Shapefile: Ein „Shapefile“ ist ein kombiniertes Dateiformat für die Speicherung von

Geodaten, das von der Firma ESRI entwickelt wurde. Ein „Shapefile“ besteht immer

mindestens aus 3 Dateien und kann aber auch bis zu 9 Dateien enthalten. Ein „Shapefi-

le“ kann immer nur Daten eines Geometrietyps (Punkte, Linien oder Polygone) enthal-

ten.

Skript (eng. Script): Der Begriff wird in dieser Arbeit als Synonym für ein kleines

Programm, bzw. eine funktionsfähige Untereinheit eines Programms verwendet.

Literaturverzeichnis 112

Literaturverzeichnis

Liebig, W. (2007): ArcGis – ArcView 9 Programmierung - Einführung in VBA und

Arcobjects

Razavi, A. H. (2002): ArcGIS Developer’s Guide for VBA

Zhao, X. (2002): ASCII-Importer fast (VBA Skript).

Evans, J. S. und Hudak, A.T (2007): A Multiscale Curvature Alorithm for Classifying

Discrete Return LiDAR in Forested Environments; Transactions on Geoscience and

Remote Sensing, Vol. 45. No. 4, April 2007, S.1029 - 1038

Meng, X.; Wang; L., Silvan-Cardenas, J.; Currit, N. (2008): A multi-directional

ground filtering algorithm for airborne LiDAR. ISPRS Journal of Photogrammetry &

Remote Sensing, S.1-8, doi: 10.1016/j.isprsjprs.2008.09.001

Okagawa, M. (2002): Algorithm of Muliple Filter to Extract DOM from LiDAR Data

Pfeifer, N. (2008): DSM / DTM Filtering (Material vom Vortrag auf der „International

School on LiDAR Technology 2008, IIT Kanpur, Indien)

Montwe, D. (2009): Programmierung von Werkzeugen zur automatisierten Objekter-

kennung aus LiDAR-Daten. Realisiert in ArcGIS mittels VBA. Hausarbeit am Institut

für Fernerkundung und Landschaftsinformationssysteme, Universität Freiburg.

IGG (Institut für Geodäsie und Geoinformation), Rheinische Friedrich-Wilhelms

Universität Bonn (2009): Manuskripte – online unter: http://www.geod.uni-

bonn.de/apmg/publikationen/manuskripte.php (Datum des letzten Zugriffs: 16.11.2009)

Yousef, A. und Weinacker, H. (2009): Unterlagen zum VBA-Kurs der Abteilung FE-

LIS.

Internetseiten:

ArcScripts Home

http://arcscripts.esri.com/ (Datum des letzten Zugriffs: 16.11.2009)

Wikipedia:

http://de.wikipedia.org/wiki/Mittelwasser (Datum des letzten Zugriffs: 18.10.2009)

http://de.wikipedia.org/wiki/Höhe_über_dem_Meeresspiegel (Datum des letzten Zu-

griffs: 20.10.2009)

Erklärung 113

Erklärung

Hiermit erkläre ich, dass ich die vorliegende Diplomarbeit selbständig angefertigt habe.

Es wurden nur die in der Arbeit ausdrücklich benannten Quellen und Hilfsmittel be-

nutzt. Wörtlich oder sinngemäß übernommenes Gedankengut habe ich als solches kenn-

tlich gemacht.

Ort, Datum Unterschrift

Stichwortverzeichnis

ALS 8, 14

ArcObjects 1, 2, 13, 18, 19, 20, 24, 25, 87

ASCII-Importer 25

COM-Technologie 18, 19

DGM 3, 4, 6, 43, 44, 53, 56, 61, 62, 67, 69, 71, 73, 74, 79, 112

digitale Höhenmodelle 12

Digitale Höhenmodelle 52, 56

DOM 2, 3, 4, 6, 56, 58, 71, 73, 74, 85, 112

DSM 8, 29, 30, 50, 52, 56, 58, 59, 61, 62, 73, 74, 75, 77, 84, 114

DTM 8, 28, 30, 34, 50, 52, 56, 58, 61, 62, 63, 65, 66, 67, 69, 70, 73, 74, 75, 78

Eigenschaften 20, 21, 22, 23, 24

First Pulse 8, 15, 16

Georeferenzierung 47

Klasse 20, 21, 22, 23, 24

Last Pulse 8, 15, 16

LiDAR Analyst 11, 13

LP360 13, 14, 83

Model Builder 18

nDOM 3, 4, 6, 73, 75, 112

nDSM 8, 30, 50, 52, 56, 61, 73, 74, 75

Punktewolke 13, 15

Rohdaten 10, 12, 13, 14, 30, 33, 34, 36, 37, 42, 46, 47, 48, 52, 53, 55, 58, 62, 65, 83, 112

TLS 8, 14

Toolbox 26

Unterklasse 21

VBA 30

Date post:	12-Mar-2019
Category:	Documents
Upload:	doannga
View:	224 times
Download:	0 times

Erstellung eines LiDAR-Moduls für ArcMap anhand von VBA ... · Erstellung eines LiDAR-Moduls für...

Documents