We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Simulation von Laserscanning mit AEOS, dem QGIS Plugin für HELIOS++

00:00

Formale Metadaten

Titel
Simulation von Laserscanning mit AEOS, dem QGIS Plugin für HELIOS++
Serientitel
Anzahl der Teile
88
Autor
Lizenz
CC-Namensnennung 4.0 International:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Das einfach zu bedienende QGIS Plugin für HELIOS++ verbindet die Vielseitigkeit des LiDAR-Simulators HELIOS++ mit der Nutzerfreundlichkeit des Geoinformationssystems QGIS. In dieser Demo-Session werden wir HELIOS++ sowie das Plugin und seine Funktionalitäten anschaulich vorstellen. Wir demonstrieren den gesamten Ablauf des virtuellen Laserscannings, von der Erstellung der Szene und Konfiguration der Aufnahmeparameter bis zur finalen Punktwolke.
Schlagwörter
ModemXMLZoomObjekt <Kategorie>PolygonUnendlichkeitPlug inKomponente <Software>Server3D-ScannerWinkelPunktwolkeSystemplattformDimension 3PortscannerC++DateiComputeranimation
Print <4->SUPERB <Programmiersprache>PixelPolygonSIMPL <Programmiersprache>Objekt <Kategorie>Computeranimation
CLOU <Programm>MagnetblasenspeicherIndexMono-FrameworkVersion <Informatik>SpieltheorieNeunMenütechnikCodeProviderWorld Wide WebSPELochkarteUnified Threat ManagementEPSSondierungBenutzeroberflächeStabLängeWorld of WarcraftPolygonRepository <Informatik>Hausdorff-RaumMeterVerschlingungBrowserDiskrepanzAnpassung <Mathematik>MomentenproblemPlug inKomponente <Software>CodeHöheVECTOR <Programm>Befehl <Informatik>DateiSystemplattformDownloadingPulsfrequenz <Technik>KonfigurationsraumGeschwindigkeitSondierung3D-ScannerComputeranimation
LIGA <Programm>SondierungMinor <Graphentheorie>SummeTARGETS <Programm>DesktopMessage Transfer AgentMaximumFrequenzPortscannerServerHöheDateiformatSondierungTrajektorie <Kinematik>Computeranimation
World of WarcraftSondierungWorld Wide WebBefehl <Informatik>LagSondierungSystemplattformMeterDiskrepanzAuswahlaxiomComputeranimation
Drahtloses vermaschtes NetzWorld of WarcraftSondierungWurm <Informatik>RSS <Informatik>TraktrixGRADEWinkelProgramm/QuellcodeComputeranimation
Typ <Informatik>SondierungWurm <Informatik>World Wide WebSondierungSystemplattformFrequenzWinkelMeterGeschwindigkeitFahne <Mathematik>AuswahlaxiomComputeranimation
World Wide WebSondierungMaximumSondierungPlug inVerschlingungPunktwolkeMomentenproblemServerComputeranimation
SondierungWorld Wide WebOvalMomentenproblemPunktwolkeFlächeLagServerTrajektorie <Kinematik>Dimension 3SondierungComputeranimation
World Wide WebFlächeAttributierte GrammatikPortscannerRichtungWinkelServerPerspektiveGradientFlächentheoriePunktPunktwolkeInformation
PunktwolkeAttributierte Grammatik
FeldgleichungTrigonometrische FunktionComputeranimation
MenütechnikCursorTrajektorie <Kinematik>RichtungSondierungComputeranimation
SondierungMeterSondierungTrajektorie <Kinematik>WinkelSystemplattformGeschwindigkeitComputeranimation
SondierungWorld Wide WebRAW-FormatSpieltheorieMomentenproblemViewerSondierungPunktwolkeComputeranimation
EIBWorld Wide WebSondierungComputeranimation
ManagementinformationssystemWorld Wide WebKooperatives InformationssystemWEBCursorTrajektorie <Kinematik>AlgorithmusPunktwolkeEin-AusgabeModularitätPlug inSkriptspracheSondierungComputeranimation
Stochastische MatrixWorld Wide WebSondierungParametersystemTyp <Informatik>Demoszene <Programmierung>IBMWurm <Informatik>HöheReiheGeschwindigkeitMeterDivergente ReiheSimulationComputeranimation
World Wide WebWurm <Informatik>XMLParametersystemMerkmalstrukturMagnettrommelspeicherSystemplattformPunktwolkeParametersystemWebcamPositionWikiPunktKlasse <Mathematik>ZahlenwertObjekt <Kategorie>VerschlingungChatten <Kommunikation>Computeranimation
3D-ScannerPunktwolkeSimulationKollaboration <Informatik>Anpassung <Mathematik>AlgorithmusBaum <Mathematik>ValidierungObjekt <Kategorie>ParametersystemReelle ZahlPunktUniformer RaumBesprechung/Interview
Besprechung/Interview
Transkript: German(automatisch erzeugt)
So, hallo und herzlich willkommen zu dieser Demo-Session an der Foskis. Der Titel dieser Demo-Session ist Simulation von Laserscanning mit EOS, dem QGIS Plugin für Helios++. Für diejenigen, die Helios++ noch nicht so gut kennen,
Helios++ ist ein Leiter-Simulator, der hier in der 3D-Geoforschungsgruppe in Heidelberg entwickelt wurde. Helios++ ist in C++ implementiert, hat aber auch Python-Anbindungen, mit denen der Simulator sich über Python ansteuern lässt, also ansteuern, kontrollieren, konfigurieren lässt.
Und in Python ist eben auch dieses QGIS Plugin geschrieben, EOS, was ich euch heute in dieser Demo-Session vorstellen werde. Vorab, fürs Verständnis, werde ich euch etwas zu der Struktur von Helios erklären. Keine Angst, QGIS eröffne ich gleich noch. Ich bin hier erstmal im GitHub-Wiki von Helios,
und wir schauen uns mal kurz an, wie so eine Simulation überhaupt definiert ist und wie man sie ausführt. Dazu gibt es nämlich eine spezielle Struktur. Es gibt vier verschiedene XML-Dateien, die für eine Simulation notwendig sind. Das sind diese vier Komponenten. Nämlich einerseits ein Scanner.
Die verschiedenen Scanner sind in der Scanner-XML-Datei definiert. Und dort steht zum Beispiel die Wellenlänge, die ein Scanner hat, all die technischen Eigenschaften und auch die verschiedenen Einstellungen, die der Scanner hat, damit die später von der Simulation aufgerufen werden können. Dann gibt es noch eine Plattform-XML.
Dort sind die verschiedenen Plattformen definiert, auf der wir den Scanner montieren können. Zum Beispiel haben wir eine Flugzeugplattform, eine Drohne oder ein Auto. Und die Unterschiede sind natürlich, wie der Scanner montiert ist, also mit welchem Versatz und mit welchem Winkel. Und außerdem, wie die Plattform sich und wie damit der Scanner sich später bewegen kann.
Ein Flugzeug bewegt sich natürlich anders und hat andere Eigenschaften, physische als ein Auto, das auf der Straße fährt. Die dritte Komponente ist die Szene. Das ist das eigentliche Objekt, was von Helios++ eingescannt wird.
Eine Szene besteht aus verschiedenen Teilen, also verschiedenen Parts, die Scene-Parts. Und jedes Scene-Parts ist quasi eine Datei. Und ein Scene-Part kann ein Geotiff sein, ein Wavefront-OBJ3D-Modell, eine Punktwolke oder ein Voxel-Modell. Und diese Scene-Parts lassen sich beliebig in einer Szene kombinieren
und als Grundmodell für die Simulation festlegen. Und wenn wir diese drei Komponenten haben, können wir dann auch eine Server definieren, die diese drei Komponenten auch zusammenschließt und dazu noch ein paar Legs definieren. Und die Legs sind die Simulationsbeine, also die verschiedenen Simulationsschritte.
Und dort ist definiert, wie der Scanner sich bewegt, wie der Scanner-Winkel sich vielleicht ändert und wie die verschiedenen Einstellungen des Scanners sich ändern. Und die Server ist das eigentliche, was später eingefügt wird in Helios,
um die Simulation auszuführen. Also die Server enthält all die Anleitungen für die Simulation. Für die folgenden Schritte, die wir heute machen werden in der Demo-Session, sind eigentlich nur die Szene und die Server wichtig. Die Scanner sind ja schon vordefiniert. Man kann neue definieren, wenn man möchte, aber das werden wir heute nicht machen.
Und die Plattformen, bei den Plattformen genauso. Aber eine Szene müssen wir selber definieren und die Server werden wir später in Helios generieren. Und für die Szene haben wir uns heute überlegt für die Demo-Session, dass wir eine kleine Simulation von, oder eine Simulation eines Laserscans
über der Stadt Heidelberg machen wollen. Und dazu müssen wir natürlich eine Szene von Heidelberg erstellen. Und die Komponenten für diese Szene, die werde ich euch jetzt mal in Qgis zeigen. Was wir dort haben, ist eine Rastadatei.
Die suche ich mal kurz. Die liegt nämlich in unserem Helios-Verzeichnis. Die wird in OIM auch liegen, wenn ihr euch Helios installiert habt. Die ist standardmäßig dabei. Genau, die sieht so aus. Heidelberg ist ungefähr hier. Und die brauchen wir, um den Untergrund festzulegen für die Simulation.
Also was ist der Boden? Sonst würden all die Laserbeams quasi einfach bis ins Unendliche durchgehen und wir wüssten nicht, wo der Untergrund ist. Als nächstes wollen wir noch die Gebäude reinladen, damit wir ein schönes Modell von Heidelberg letztendlich haben, was nicht nur ein Raster ist und nicht nur der Untergrund ist.
Und dazu habe ich etwas vorbereitet, nämlich ein Shapefile der verschiedenen Gebäude. Dieses Shapefile habe ich aus OSM geladen, danke an die OpenStreetMap-Contributor. Und ihr denkt euch vielleicht, dass es ein bisschen komisch aussieht, nämlich sind all die Polygone hier konvex. Das hat einen bestimmten Grund, den ich euch gleich noch erklären werde.
Nämlich müssen wir diese flachen Objekte natürlich irgendwie in die dritte Dimension ziehen. Und dafür habe ich ein kleines Skript vorbereitet, was ich euch jetzt im Folgenden zeigen werde. Das Skript liegt hier unter obj-create.
Und genau so sieht das aus. Natürlich wird jetzt nicht verlangt, dass ihr Python programmieren könnt, aber ich kann euch grob erzählen, was das Skript macht. Das ist ein kurzes, simples Skript, was die Eckpunkte der Polygone nimmt und für die 3D-Modelle jeweils halt unten einen Punkt
und oben einen Punkt für jeden Eckpunkt erstellt und trianguliert und dadurch ein 3D-Objekt erstellt. Leider kann die Library, die ich dafür verwende, nur konvexe Objekte triangulieren, aber für die Demonstrationszwecke sollte es auf jeden Fall reichen, aber deswegen ist mein Shapefile hier.
Deswegen sind all die Polygone konvex. Genau, nur damit ihr es Bescheid wisst. Dieses Skript werde ich jetzt ausführen, um das 3D-Modell zu generieren. Dazu habe ich hier schon den Dateipfad offen. Genau, wie heißt es? So.
Genau, das Skript führe ich aus. Während das lädt, muss ich auch einen kleinen Moment, kann ich euch schon mal die Szene zeigen, die ich vorbereitet habe. Nämlich sieht die Szenen-XML-Datei in etwa so aus. Die jeweiligen Scene-Parts sind so definiert durch diesen Part-Tag.
Davon haben wir zwei. Einmal das GeoTiff. Durch den GeoTiff-Loader wird das reingeladen und einmal das 3D-Objekt durch den OBJ-Loader. Zu Beginn können wir unsere Szene vielleicht einen Namen geben. Also eine ID Heidelberg. Und als Namen Stadt-Heidelberg.
Genau, die erste Komponente ist das GeoTiff. Das haben wir ja schon, das liegt schon in Helios bereit. Das heißt, ich muss dafür nur den Pfad reinkopieren. Dazu gehe ich in mein Helios-Verzeichnis unter Data, Scene-Parts, unter TIFF.
Und hier ist es. DMHD. Davon kopiere ich mir den Pfad und füge ihn hier in meine Szenendefinition ein. So, erstes Scene-Part ist definiert. Jetzt schaue ich mal, was das Skript macht. Nichts, alles klar, jetzt hat es erst angefangen.
Genau, aber das Skript wird jetzt ein paar Gebäude oder ein Objekt generieren, dieses 3D-Objekt. Da warten wir mal kurz ab. Aber den Pfad dieses 3D-Objekts werde ich dann hier einfügen unter Value bei dem OBJ-Loader.
Ich öffne schon mal den Ort, wo ich das später ablegen will. Nämlich hier unter Heidelberg. Ja, mal schauen. Es lädt immer noch. Verzeihung. Einen Moment. Ich schneide vielleicht kurz.
So, wie ihr seht, hat mein Skript vollständig ausgeführt. Das OBJ ist vollständig geschrieben. Es sind fast 5.000 Gebäude. Und das OBJ liegt unter Buildings. Buildings.obj. Dafür gehe ich mal wieder in den Ordner. Unter Buildings.
Und da liegt es auch. Das kopiere ich mir. Gehe wieder in meinen Helios-Pfad. Unter Data, Scene Parts, Heidelberg. Dort wollte ich sie ablegen. Und kopiere mir das rein. Und kopiere mir auch gleich den Pfad, damit ich meine Szenendefinition einfügen kann. So.
Nun ist unsere Szene definiert. Mit dieser Szene können wir gleich in EOS reingehen. Und ein paar schöne Simulationen ausführen. Aber erstmal will ich euch zeigen, wie man EOS überhaupt installiert. Damit ihr das zu Hause für euch auch machen könnt. Dafür öffne ich erstmal meinen Browser.
Und gehe hier auf das GitHub-Repo von EOS. Diesen Link werde ich euch später in der Live-Session schicken. Damit ihr es zu Hause auch machen könnt. Und in diesem Repo gehe ich auf Code. Download ZIP. Das lädt mir die gesamten Dateien hier als ZIP-Datei runter.
Und diese ZIP-Datei muss ich jetzt einfach in den Plugins-Ordner von QGIS pasten. Den findet ihr innerhalb von eurer QGIS-Installation. Genau, den kopiere ich rüber. Und extra hier das Ganze einfach in diesen Ordner.
So. Jetzt liegt innerhalb von diesem Ordner ein Sub-Ordner. Das ist wichtig, den umzubenennen und dann in den Plugins-Ordner zu ziehen. Dann kann ich die ZIP-Datei löschen,
den umschließenden Ordner löschen. Und jetzt habe ich EOS hier liegen. Damit kann QGIS was anfangen. Ich schließe erstmal noch QGIS. Man muss QGIS natürlich neu starten. Genau. Das dauert jetzt einen Moment bis QGIS eröffnet. Ich bin dann gleich wieder da.
So, wie ihr seht, hat sich QGIS jetzt geöffnet. Das Plugin ist noch nicht in der Plugin-Leiste. Erst muss ich auf diesen Plugin-Tab hier oben gehen. Auf Manage & Install Plugins. Und da finden wir es jetzt. Da muss ich noch ein Häkchen setzen. Und jetzt sollte das Plugin da sein. Genau, hier.
Hier ist es. Das ziehe ich mal rüber. Und wir müssen mehr Platz haben. Und jetzt ist EOS wirklich vollkommen installiert. Und wir können damit beginnen, ein paar Surveys zu erstellen für unsere Simulation. Also ein paar Anweisungen für Helios, die wir dann später ausführen werden. Dafür öffne ich mal EOS.
Und der erste Schritt, den wir hier machen müssen, ist unser Helios-Verzeichnis zu konfigurieren, damit EOS weiß, wo unsere Helios-Installation liegt und von wo es Helios ausführen soll und so weiter. Das ist die gleiche Installation, die ich euch vorhin schon gezeigt hatte. Helios 1.1.0.
Diesen Ordner wähle ich aus. Okay. Und so sieht das EOS-Interface aus. Ich öffne mal wieder unsere Sceneparts rein, damit wir ein bisschen Überblick behalten. Meine Rasterdatei lag unter Data, Sceneparts, TIFF. Die füge ich hinzu.
Und die Gebäude unter Data, Sceneparts, Heidelberg. Quatsch. Das lag unter Phosges. Und so. Genau, jetzt haben wir unser Gebäude drin. Unser TIFF. Also das hier ist quasi unsere Szene, die wir eingescannt haben wollen.
Wir haben uns überlegt, dass wir drei Surveys laufen lassen. Nämlich eine ALS-Survey, also luftgestütztes Laserscanning von einem Flugzeug. Dann eine ULS-Survey, das heißt UAV, also drohengestütztes Laserscanning. Und eine MLS, also auf einem Auto montiert.
Diese Surveys werden wir jetzt nacheinander erstellen und danach nacheinander ausführen. Erst einmal können wir hier in diesen Tab gehen, Survey for Generation from Vector Layer. Dort erstellen wir unsere Surveys. Wir können unsere Szene festlegen,
die wir vorhin kreiert haben. Die lag ja unter Helios 1.1.0, Data, Scenes, Heidelberg City. Genau. Und da drin lag nur eine Szene, die Stadt Heidelberg, wie wir sie vorhin definiert haben. Das stimmt also schon mal. Als Plattform wollen wir erstmal vielleicht die ALS-Survey generieren.
Deshalb wählen wir den Cirrus SR22, das ist unsere Flugzeugplattform. Und einen luftgestützten Laserscanner, da nehme ich mal den. Diese Konfiguration kann ich einlocken und zum nächsten Schritt weitergehen. Jetzt kann ich die Flughöhe definieren.
Dazu schaue ich mal oder ich überlege mal und mache vielleicht auf 1000 Metern Höhen. Und jetzt kann ich sagen, dass die Plattform die Höhe über dem TIF, das ich schon reingeladen habe, halten soll. Wenn ich das jetzt nicht machen würde, würde die Plattform auf 1000 Meter
über Null fliegen und sich nicht an das Gelände anpassen. Wenn ich jedoch den Raster hier auswähle, passt das sich an, mit einer Diskrepanz von plus minus 30 Metern. Das sieht gut aus. Für die Geschwindigkeit nehme ich mal 150 Meter pro Sekunde. Und für die Scanner-Einstellungen
öffne ich kurz unser Scanner-Blatt, damit wir uns genau anschauen können, was für Optionen wir da überhaupt haben. Das liegt unter Data, Scanners, ALS. So, den Scanner, den ich ausgewählt hatte, war ja der Laker ALS 50-2. Und wir sehen, dass
unter den möglichen Pulsfrequenzen haben wir 20.000, 60.000 und 150.000. Da nehme ich mal 60.000. Als Scan-Angle haben wir ein Maximum von 37,5. Da wähle ich auch gleich das Maximum.
Und als Frequenz auch das Maximum 90. Genau, die Frequenz war hier unten. Scan-Angle hier. So, jetzt haben wir die Einstellungen für den Scanner definiert. Dann gehen wir zum nächsten Schritt. Wir können der Server einen Namen geben. Ich nenne sie mal ALS
Heidelberg-Fosges. Und jetzt muss ich noch einen Vector-Layer aussuchen, mit dem ich die Flugbahn des Scanners definieren kann. Und da habe ich schon etwas vorbereitet. Das liegt auch schon in meiner Helios-Installation unter Fosges,
Flight Paths. Genau, ALS. Und so sieht unsere Trajektorie für unser Flugzeug aus. Das könnte ich jetzt auch on the fly machen. Ich bereite es lieber vor, damit wir ein bisschen Zeit sparen. Das ist natürlich komplett offen. Welches Dateiformat wir hier haben wollen. Hauptsache, es ist ein Vector-Layer.
Genau, ALS wähle ich aus. Und als Output-Verzeichnis erstelle ich vielleicht ein Verzeichnis unter Surveys und nenne es Fosges. Dort will ich meine Surveys abspeichern.
Diesen Haken können wir noch setzen. Der ist vielleicht wichtig, wenn wir nämlich die Höhe über dem TIF anpassen wollen, über dem Gelände, dann wird das reguläre Helios uns ganz viele Lakes definieren. Also ganz viele verschiedene Flughöhen, die zu ganz vielen verschiedenen Output-Files führen würden.
Aber wenn wir diese Checkbox aktivieren, wird für jeden dieser Features nur eine Output-Datei generiert. Das ist vielleicht gut zu wissen, nur für euch. Genau, und diese Survey generiere ich mal. Und jetzt können wir sehen, dass sie hier liegt. Wir können auch gleich raufklicken und sie öffnen. Ich suche mal ein bisschen raus.
Genau, so sieht so eine Survey-Datei aus. Hier haben wir immer die einzelnen Wegpunkte zu jedem Survey-Lag, die einzelnen Scanner-Einstellungen. Die sind jetzt in diesem Fall für jeder Lag gleich. Und die Orte, wo der Scanner liegt und welchen Scanner wir ausgewählt haben,
genau dasselbe für die Plattform und genau dasselbe für die Szene. Hätte ich davon erklärt, dass die Survey die drei anderen Elemente zusammenführt und die Anweisungen für die Simulation beinhaltet. Genau, jetzt haben wir unsere ALS-Befliegung konfiguriert.
Das Gleiche machen wir jetzt noch für ULS. Dazu ändere ich die Plattform. Wähle nochmal die Plattform XML aus. Wähle Quadrocopter-UAV. Dann wähle ich noch einen Scanner aus, natürlich einen UAV-Scanner. Diesen hier
logg wieder ein und gehe zum nächsten Schritt. Die Drohne muss natürlich viel niedriger fliegen als das Flugzeug. Ich sage mal auf 40 Metern. Auch wieder über dem Gelände, aber die Diskrepanz darf nicht so hoch sein, damit die Drohne uns nicht in ein Gebäude reinfliegt.
Also sage ich mit einer 3 Meter Diskrepanz, das ist noch in Ordnung. Für die Fluggeschwindigkeit wähle ich auch etwas viel niedrigeres. 5 Meter pro Sekunde. Für die restlichen Einstellungen schaue ich nochmal mein Scannerblatt. Der Scanner, den ich ausgewählt hatte, war
hier Regelvox One UAV. Gut, hier können wir die Pulsfrequenz jetzt ganz schön hoch stellen. Das machen wir auch gleich und nehmen 200.000. Für den Winkel nehmen wir nicht den vollen Winkel, weil wir sonst zu weit nach außen scannen.
Wir wollen ja noch eine Schneise auf dem Boden haben. Deswegen wähle ich dort 60 Grad aus für meinen Scanwinkel. Das ergänze ich auch gleich in QGIS. 60 Grad. Bei der Scanfrequenz gehe ich auch auf 60 Hertz in diesem Fall. Jetzt gehe ich weiter und muss bei dem
Surveynamen nur auf ULS statt ALS umstellen. Natürlich eine neue Traktorie noch reinladen. Dazu habe ich auch schon etwas vorbereitet. ULS, genau. Die ist hier etwas versteckt. Da muss ich mal die Symbologie ändern.
Mache ich mal rot. Ein bisschen dicker. Das ist unsere kleine ULS-Bepflegung. Das deckt natürlich einen viel kleineren Bereich als die Flugzeug Bepflegung. Aber logisch. Dann wähle ich das richtige
Shapefile noch aus. Wieder One Outfile per Feature. Und ich generiere. Die Survey können wir uns auch anschauen. Sieht genau gleich aus wie die ALS Survey. Nur mit den abgeänderten Einstellungen. Wieder der Scanner, die Szene und die Plattform hier oben. Jetzt fehlt nur noch die Survey für das MLS.
Der Scanner, der auf dem Auto angebracht ist. Dafür ändere ich nochmal die Plattform. Data Platforms. Wähle hier diese Plattform aus. Den Scanner ändere ich auch nochmal. Obwohl ich wieder den gleichen. Nächster Schritt.
Jetzt muss ich diese kleine Box markieren. Das bedeutet, dass ich will, dass der Scanner auf dem Boden entlangfährt. Das kann ich so in EOS konfigurieren und das ist eigentlich eine kleine Flag in der Survey XML, die jetzt für überall auf True gesetzt wird.
Hier ist es jetzt egal, was ich eingebe. Weil Helios das für mich alleine regelt. Das es On Ground sein soll. Bei der Geschwindigkeit gehe ich etwas hoch. Auf 15 Meter pro Sekunde. Die Pulsrequenz kann ich so lassen. Den Winkel mache ich ein bisschen weiter. Auf den Maximalwinkel.
Weil ich jetzt in der Straße bin und alles ausnutzen kann vom Scan Winkel her. Davor als ich in der Luft war, werden ganz viele Laserschüsse irgendwie komisch geworden. Aber so passt das jetzt. Die Scan Frequenz kann ich auch so lassen wie davor. Genau damit bin ich zufrieden.
Jetzt muss ich nur noch umändern auf MLS in diesem Fall. Und mir natürlich in eine neue Trajektorie reinziehen. Die habe ich auch schon vorbereitet. Genau. Wir wollen mit dem Auto einfach die Mitte der Straße langfahren. Und wir machen das dort wo wir auch unsere ULS Befliegerung haben, damit wir die Ergebnisse später schön
vergleichen können. Genau, das wähle ich noch aus. Und ich denke jetzt stimmt alles. Ich kann wieder generieren. Und mir das Ergebnis anschauen. Dieses Survey hat nur ein Lag, weil wir nur von einem Punkt zu einem anderen fahren. Von hier
bis hier. Und das war es für meine Survey Generierung. Jedes Mal wenn man eine Survey generiert, landet der Link auch hier unten in dem zweiten Teil des Plugins. Wo man die Servers ausführen kann. Und das werde ich gleich machen für die MLS Survey. Es gibt diese kleine Checkbox, die sagt aus,
dass die Punktwolke direkt in QGIS geladen werden soll. Und das wollen wir auch. Ich mache jetzt gleich einen Schnitt, nachdem ich die Servers ausgeführt habe. Da wir nicht warten wollen, bis alle Servers ausgeführt sind. Das könnte einen Moment dauern. Aber ich bin dann gleich wieder da. Ich drücke mal auf Execute.
Und wir sehen uns kürzlich, wenn unsere Punktwolken dann hoffentlich in QGIS geladen sind. So, wie ihr seht, waren unsere Simulationen erfolgreich. Wir haben hier ein paar Punktwolken liegen. Und wir haben hier einen Output-Folder, der uns ausgegeben wird, für die
letzte Simulation. Für den Moment schließe ich EOS aber, damit wir uns die Punktwolken mal ein bisschen genauer anschauen können. Also uns angucken können, was das Ergebnis jetzt eigentlich war, dieser Survey. Wir sehen, dass für die ALS-Survey drei verschiedene Punktwolken ausgegeben wurden. Für die ULS-Survey zwei und für die MLS-Survey eine. Das liegt natürlich
daran, dass, wenn ich die Trajektorien mal drüberlege, dass die ALS- Befliegung drei Schneisen hatte, die ULS-Befliegung zwei Schneisen hatte, und bei dem MLS war es nur eine. Und man kriegt eben für jeden Feature, das habe ich ja schon erwähnt, für jedes Feature eine Punktwolke
raus. Die ALS-Befliegung deckt natürlich am meisten Fläche ab. Das war ja schon davor klar. Im Moment sehen wir auch noch nicht, was der Tradeoff dafür ist, aber wenn wir gleich ein bisschen weiter reingehen, sehen wir das ganz gut. Für den Moment stelle ich die 2D-Layer aus oder toggle ich die 2D-Layer.
Das kommt meiner Erfahrung nach im 3D-Viewer manchmal zu Problemen, wenn man die noch anhat. Diesen 3D-Viewer stelle ich jetzt und ziehe ihn groß, damit wir uns das zusammen anschauen kann. Genau. Im Moment sind alle 3
Punktwolken nach deren Z-Attribut eingefärbt. Deswegen sieht man bei der ALS-Punktwolke jetzt ganz gut das Gelände und auch die einzelnen Gebäude. Genauso bei den anderen Befliegungen. Da ändere ich jetzt nochmal schnell die Symbologie,
damit wir die auch unterscheiden können. Die MLS- Server mache ich rot. Und die ULS-Server mache ich grün-blau, sagen wir mal. Noch für den zweiten Lag. Jetzt können wir hoffentlich unsere
Punktwolken unterscheiden. Und wir können auch mal in die dritte Dimension switchen. Aus dieser Perspektive sehen wir jetzt auch ganz gut, was der Trade-off ist bei dem ALS.
Wir haben natürlich eine viel größere Fläche abgedeckt, aber die Punktdichte ist viel geringer. Also hier kann man gar nicht mehr richtig die Gebäude erkennen, während wir es bei dem ULS und dem MLS schonen können. Und man kann sich vorstellen, dass bei einer Datenauswertung das ALS-Ergebnis hier ein bisschen schwierig
wäre, die Gebäude rauszulesen oder raus zu analysieren, während es bei dem ULS und dem MLS schon viel besser aussieht. Oberflächlich sind hier all die Flächen sehr gut abgedeckt, wenn wir aber einzoomen. Sehen wir aber, dass auch hier manche Bereiche besser und manche schlechter abgedeckt sind. Das ULS hat all die Dächer sehr
gut erfasst. Dafür die Hauswände nicht sehr gut. Wenn wir zum Beispiel hier schauen, hier ist es komplett leer, oder hier an diesen Wänden, während das MLS, da wo der Laser hingeschossen hat, die Wände sehr gut erfasst hat. Man könnte es jetzt bestimmt so einstellen, wenn man
den Winkel des Scanners nochmal abändert, dass die Wände besser erfasst werden und so mit dem MLS die Hauswände gut erfassen. Bei dem ULS ist das momentan nicht der Fall. Wenn wir uns jetzt mal ein paar Attribute anschauen wollen von der Punktwolke, dafür schalte ich die
alles aus, außer das MLS. Und wir können mal reinschauen, was so eine Punktwolke eigentlich mitliefert und was Helios uns auch mitliefert an Attributen. Nämlich ist momentan, wie gesagt, sind die Punktwolken nach Z eingefärbt. Ich kann jetzt aber auch mal sagen, ich will mir die GPS-Time anschauen.
Die GPS-Time ist ein Wert, der jedem Punkt zugeschrieben wird und der aussagt, zu welchem Zeitpunkt er aufgenommen wurde. Oder zu welchem Zeitpunkt das Rücksendesignal des Punktes aufgenommen wurde. Und hier erkennen wir jetzt einen schönen Gradienten. Natürlich von Anfang der Server hier bis zum Ende hier. Und wie das Auto schön gefahren ist oder gefahren sein muss.
Das virtuelle Auto. Was können wir uns noch anschauen? Wir können uns noch die Intensität anschauen. Die variiert auch ein wenig. Abhängig davon, in welchem Winkel der Punkt auf die Oberfläche getroffen ist.
Das wäre in echt jetzt viel heterogener. Das ist sehr homogen bei dieser Helios- Simulation. Und das liegt einfach daran, dass die Szene, die wir definiert haben, nicht sehr komplex ist und die Oberflächen keine verschiedenen Eigenschaften aufweisen. In der Realität
reflektiert natürlich jede Oberfläche den Laser etwas anders. Und dazu kommt das zu anderen Aufnahmen durch den Sensor und anderen Intensitätswerten. In unserem Fall ist das sehr homogen. Dazu müsste man die Szene, die Teilgenauigkeit der Szene verbessern.
Das gleiche können wir auch mal für die ULS Befliegung machen. Zum Beispiel da die GPS- Time anschauen. Wenn ihr euch erinnert, hatten wir ja zwei Befliegungen. Eine in die Richtung, eine in die Richtung. Oder andersrum, ich weiß es nicht mehr. Können wir uns mal anschauen.
Gut ist, schon nach GPS-Time eingefärbt. Und das hier noch nicht. Wenn wir den einen Streifen mal ausblenden, sehen wir, der Scanner muss
vom hellen mit den niedrigen Werten zum dunklen mit den hohen Werten geflogen sein. Und wenn wir den zweiten Strip noch aktivieren, sehen wir hier war es genauso. Von hier nach hier. Einfach nur, damit ihr ein bisschen seht, was man da noch für Informationen rausholen kann und was Helios
alles liefert. Das ganze kann ich auch mal bei der ALS-Punktwerke zeigen. Wir können uns hier das Scanner mal anschauen. Dafür zoome ich raus. Wenn wir jetzt hier mal die GPS-Time einfärben. So.
Jetzt habe ich es wieder für die zweite Symbologie gemacht. So, GPS-Time. Das gleiche für diesen Streifen. GPS-Time. Und für den letzten auch.
Jetzt können wir wieder sehr gut nachverfolgen, wie der Scanner geflogen ist. Das wissen wir ja sowieso von unseren Trajektorien, aber der Scanner muss so, so und so. Schön die Gradierung immer beachten, geflogen sein. Genau, soviel zu den Attributen der Punktwolken.
Als nächstes möchte ich euch nochmal ein Beispiel zeigen, wie man EOS verwenden kann. Nämlich ein Beispiel der Surveyplanung. Dazu können wir uns überlegen, wie wir die Service, die wir gerade ausgeführt haben, vielleicht noch verbessern können. Als Beispiel fällt mir die ULS-Survey ein, wenn ich die nochmal
einblende. Da war es ja so, dass die Hausdächer sehr gut erfasst wurden und eine sehr hohe Punktdichte hatten, während die Hauswände eher gering von der Punktdichte waren und man sie nicht so gut erkennen konnte. Das kann ich auch nochmal zeigen. Ich erstelle mal einen neuen 3D-View, in dem wir uns das anschauen können.
Genau. Wie gesagt, die Hausdächer haben viele Punkte, während die Hauswände wenig haben. Und wenn wir jetzt diese Straße oder diese Häuser gut erfassen wollen würden,
müssten wir da was ändern. Um das zu erklären, können wir uns vielleicht mal die 2D-Ansicht anschauen und die Trajektorie der ULS anschauen. Wenn wir uns überlegen, dass der Scanner so entlang geflogen ist, dann ist eigentlich klar, dass an diesen Wänden nicht viele Punkte hätten landen können. Nämlich scannt der Scanner ja
zeitlich, also wie dem Cursor folgend immer so. Und wenn er jetzt hier einfach rüberfliegt, dann treffen wenig Punkte die Wände, die hier orthogonal zu der Flugrichtung liegen. Nämlich parallel zur Scan-Richtung. Und das zu
ändern, können wir einfach eine neue Survey generieren und anhand dieser neuen Survey wieder eine Simulation ausführen. Dafür würde ich jetzt diesen Vector-Layer mit unserer Trajektorie für das ULS einfach rotieren. Erstmal muss ich was auswählen.
Jetzt rotiere ich. Und parallel entlang der Straße fliegen in beide Richtungen. Jetzt erst mal wieder EOS und konfigurieren einfach wieder die Survey. Genau die gleiche, die wir davor für das ULS hatten, bloß mit der neuen Trajektorie. Dafür wählen wir erst mal die Plattform aus.
Wieder den Quadrocopter-UAV, den Scanner, One UAV. Das Locken können wir einlocken. Jetzt haben wir hier noch die Einstellung von der MLS-Survey. Die müssen wir natürlich abändern. Und wieder über dem Gelände fliegen.
Innerhalb von 3 Metern hatten wir nicht on ground. Als Geschwindigkeit hatten wir 5 Metern pro Sekunde. Die Pulsfrequenz hat gestimmt. Die war genau gleich. Der Winkel war anders. Und so stimmt das. Jetzt ändern wir den Namen wieder. ULS, Foskis,
Revised. Und als Input-Layer für die Trajektorie ULS. Und genau so sollte es stimmen. Das Ergebnis können wir uns anschauen. Und das sieht gut aus. Die Survey landet gleich unten. Und wir können sie auch einfach gleich ausführen.
Und uns unser Ergebnis anschauen. So, wie ihr seht, war die Survey erfolgreich. Oder die Simulation war erfolgreich. Wir haben zwei neue Punktwolken in unserem Viewer. Und wir sehen wieder den Output-Part. Ehe ausschließen wir für den Moment aber erstmal, damit wir die zwei Punktwolken vergleichen können.
Erstmal die Punktwolken von der alten Survey. Mit den Punktwolken von der neuen, hoffentlich optimierten Survey. Dazu verändere ich die Symbologie der neuen Punktwolken. Damit sie etwas hervorstechen. Und dann öffnen wir gleich einen 3D-Viewer.
Genau. Der 3D-View. So, jetzt seht ihr hoffentlich die zwei Punktwolken und könnt sie unterscheiden. Ich schalte noch die 2D-Layer aus. Genau. Was wir als erstes sehen, ist
das... die Gebäude verändert haben. Das sollte natürlich nicht passieren. Das tut mir leid. Das liegt daran, dass ich noch selber simuliert habe vorhin und sich dadurch das Modell verändert hat. Ist aber für diesen Anwendungsfall nicht relevant. Was wir auf jeden Fall sehen, ist, dass die
Seitenwände viel besser erfasst wurden von der neuen Survey. Unsere Survey-Optimierung hat also funktioniert. Davor waren es einzelne Streifen. Und jetzt können wir sie sehr gut erkennen, die Wände auf beiden Seiten. Um das zu erklären, wechsle ich nochmal in den 2D-Viewer und schalte unsere Layer wieder ein.
Und wenn wir uns jetzt überlegen, dass der Scanner entlang der Trajektorien fliegt und der Scanner so entlang scannt, wie mein Cursor sich jetzt bewegt, ist es natürlich klar, dass viel mehr Punkte diese Wand treffen, als wenn er so fliegt und nur einmal kurz vorbeifliegt an dieser Wand, weil die Wand natürlich orthogonal zur Flugrichtung liegt. Jetzt,
wo wir parallel zur Straße fliegen, haben wir eine viel bessere Möglichkeit, diese Wände mit dem LiDAR-Scanner zu erfassen. Wie ihr hoffentlich seht, erleichtert Helios Post Plus die Survey-Optimierung enorm.
Das ist natürlich ein sehr vereinfachter Anwendungsfall, aber wenn wir dieses Feature nicht gehabt hätten, müssten wir rausgehen, neu aufnehmen, wieder zurückkommen und die Ergebnisse anschauen und so weiter. In der Realität wären die Anwendungsfelder natürlich viel komplexer. Ihr fragt euch vielleicht, was jetzt der Vorteil ist,
wenn man simuliert, anstatt einfach ein generische Flugplanungssoftware zu verwenden. Und der Vorteil ist, dass ich die Ergebnisse, die mir ausgespuckt werden, direkt auch mit Algorithmen testen kann oder mit den Algorithmen testen kann, die ich auch auf die realen Daten anwenden will. Und so kann ich sehen, oh, ist meine
Qualität genug, der Punkt, wo sehe ich genug und funktionieren die Algorithmen, die ich anwenden will, mit dieser Aufnahmequalität, so wie ich will, dass sie funktionieren. Die Daten können also direkt auf Fitness-For-Us getestet werden.
Es gibt auch noch andere LiDAR-Simulatoren da draußen und deswegen will ich kurz dazu etwas sagen, was Helios unserer Meinung nach besser macht als andere LiDAR-Simulatoren. Helios hat sehr schnelle Laufzeiten, da wir ein gutes Tradeoff zwischen Realismus und Rechenkomplexität erreicht haben. Außerdem
ist Helios extrem flexibel. Ich meine, ihr habt es jetzt wahrscheinlich schon gesehen. Ich steuere Helios gerade aus QGIS an über Python-Anbindungen und durch diese Python-Anbindungen kann ich Helios natürlich aus allen möglichen Bereichen ansteuern, aus der Kommandozeile, aus kleinen Skripten und Helios ist dadurch extrem variabel.
Auch durch die Modularität von Helios, all die verschiedenen XMLs, die ich euch vorhin gezeigt habe, die erscheinen vielleicht am Anfang ein bisschen kompliziert und ein bisschen unnötig. Sie ermöglichen das einfache Austauschen von Survey-Komponenten on the fly und dadurch konnte ich jetzt einfach eine neue Survey immer wieder generieren und alles andere
gleich lassen. Das macht Helios++ am Ende sehr leicht bedienbar. Helios ist außerdem Open Source, was natürlich auch immer gut ist. Auf das QGIS-Plugin, das jetzt gerade noch
entwickelt wird, sind wir auch sehr stolz oder das finden wir auch sehr cool, nämlich ermöglicht das Plugin eigentlich, dass wir den Input in Helios, genauso wie den Output visualisieren können und so an jedem Schritt eine Visualisation haben, was die ganze Sache sehr viel bedienungsfreundlicher macht, unserer Meinung nach.
Und falls ihr euch schon immer gefragt habt, wie ihr das Punktwolken- Feature für QGIS testen könnt, haben wir jetzt eine Lösung für euch. Ihr könnt euch einfach EOS installieren und Helios installieren und eure eigenen Punktwolken generieren, die ihr dann in QGIS anschauen könnt. Zu allerletzt möchte ich euch noch ein weiteres Feature von EOS
präsentieren, nämlich das Feature der Data Generation, das ihr hier findet. Dieses Feature erlaubt es, eine Reihe von Simulationen auszuführen, mit zufälligen Parametern, die von dem Python-Code zufällig ausgewählt werden. Dafür setze
ich einen Surveynamen, zum Beispiel ALS Series und gehe in den Data Generation Configurator. Dort kann ich erstmal auswählen, wie viele Surveys ich laufen lassen will. Ich kann zum Beispiel sagen, ich möchte 20 Surveys laufen lassen. Dann wähle ich wieder eine Szene aus. Da kann ich natürlich wieder
meine gleiche Szene auswählen. Also ich möchte 20 Surveys ausführen, über der Stadt Heidelberg, mit, jetzt will ich meine Scanner-XML aus und jetzt kommt der Unterschied, jetzt kann ich mehrere Scanner auswählen, also ich kann sagen, ich nehme 3 oder 4 verschiedene Scanner,
also 20 Surveys über Heidelberg, mit diesen 4 verschiedenen Scannern, zwischen 1000 und 1500 Metern über dem Boden und mit einer Fluggeschwindigkeit von 200 bis 250 Metern pro Sekunde.
Hier kann ich jetzt noch verschiedene Vector-Layer auswählen, also könnte ich zum Beispiel alle 3, die ich gerade drin habe und wenn ich jetzt auf Execute Data Generation drücke, führt das mir 20 Surveys aus, mit zufälligen Parametern, also jeweils einen zufälligen Scanner, zufällige Einstellungen für den Scanner, eine zufällige Geschwindigkeit in der
Range, die ich angegeben habe, und eine zufällige Höhe in der Range, die ich angegeben habe. Und das ist ein sehr nützliches Feature, wenn man vielleicht einfach mal rumprobieren will und gucken will, welche Flughöhe am besten ist. Man führt einfach viele aus und schaut sich die Ergebnisse an und vergleicht sie und genau, ein etwas aufwändigerer Weg der Survey-Optimierung,
aber auch auf jeden Fall ein Weg und einfach ein cooles Feature, was ich euch noch zeigen wollte. So, das war's auch eigentlich von meiner Seite. Ich hoffe, ihr hattet Spaß und ich hoffe, ihr konntet gut mitkommen. Wenn nicht oder wenn ihr noch irgendwelche Fragen habt, sehen wir uns ja gleich noch live bei der Foskis und ich freue mich drauf. Bis gleich.
So, das war der Vortrag, die Demo-Session zu Helios++ mit dem AOS-Plugin. Wir befinden uns jetzt in der Q&A-Session. Es tröpfeln auch schon die ersten Fragen ein und eine von den Fragen
bezieht sich auf die Punktdichte. Wo sieht man denn diese Punktdichte? Hanna und Mark sind zugeschalten. Bitte schön. Also, hallo an alle nochmal. Genau, zur ersten Frage, die Punktdichte,
das Feature haben wir noch nicht eingebaut in AOS. Die kann man sich vielleicht selber überlegen, wenn man sich den Extend von der Punktwolke anschaut und sich anschaut, wie viele Punkte insgesamt drin sind. Also, das wäre so ein basic, ungenauer Workaround, aber können wir uns auf jeden Fall noch überlegen
als Feature, das fänden wir auch cool. Und ich glaube, der zweite Teil von der Frage bezog sich noch auf die verschiedenen Klassen, die in der Punktwolke mitgeliefert werden. Und dafür habe ich das Wiki mal aufgemacht. Ich hoffe, ihr seht das hier. genau, da gehe ich hier auf Output.
Quatsch. Hanna, kannst du mir vielleicht helfen? Wo gehe ich da hin? Genau, bei Scene einmal. Da ist es generell so, dass wir haben einen Parameter die Hit Object ID. Das ist, wenn wir in der Scene die einzelnen Parts haben, dann wird
generell quasi jeder Part bekommt eine eigene ID. Also, in unserem Fall hatten wir ja nur zwei Objekte. Das waren einmal alle Gebäude zusammen und einmal das Terrain. Und die hätten dann unterschiedliche Object ID. Das ist die eine Art von Klassifikation, die wir sozusagen in der Szene haben. Es kann aber auch noch weiterführend sein. Nämlich haben wir bei den
OBJ-Files, und wir haben das auch implementiert für alle anderen Formate, noch Materials dabei, also so ein Material Datei, wo wir auch wichtige Parameter, um die Intensität von der Punktwolke zu berechnen, spezifizieren. Aber da haben wir eben auch ein Parameter Helios Classification.
Vielleicht kannst du aber kurz nach dem Begriff im Wiki suchen, Mark. Der müsste auch auf der Seite sein. Und dann kann eben in dem Material-File, das ist genau das Format, was eben im Object-Wave-Front Format definiert ist, können wir diesen Helios spezifischen Parameter Helios Classification
angeben und da einfach Zahlenwerte zuweisen. Zum Beispiel anhand der Lars-Festification, um dann auch für so Klassifikations-Fragestellungen, dass man zum Beispiel Bodengebäude, Bäume, sowas eine einzelne Klasse gibt. Vielleicht noch zu der
Frage zu den Punkten. Genau, für unsere Zuschauer ist es interessanter, wenn ich die Fragen stelle. Daher die weiterführende Frage war, wie viele Klassen hat die Punktwolke? Das hast du jetzt schon teilweise beantwortet. Wie ist das denn
damit? Kann man diese Klassen auch grafisch in QGIS modellieren oder eingeben? Wie geht das dann? Genau, die Klassen würden in der Punktwolke einfach erscheinen, als ein Punktwolkenattribut.
Das kann man in einem 3D-Viewer, so wie Mark das auch gezeigt hatte, in der Demo-Session über das Punktwolkenattribut auswählen. Genauso wie die GPS-Time oder die Intensity. Dann eine weitere Frage. Wurde die Simulation bereits für Befliegungsplanungen
genutzt? Es geht sich vor allem darauf, wie produktiv ist das schon einsetzbar? Da muss ich endlich verweisen. Ja, wir hatten zumindest schon verschiedene Publikationen dazu, die sich mit den Fragestellungen beschäftigt haben. Ich glaube, wir haben im Wiki auch eine Seite
rechts in Overview unten mit Research Using Helios und da könnte man mal nachschauen. Da müssten so Anwendungsfälle auch schon behandelt worden sein.
Eine weitere Frage, die noch eingetroffen ist. Werden auch Unsicherheiten zu den Punkten simuliert? Wenn ja, was fließt alles ein? Strecken, Winkel, Unsicherheit, Unsicherheit der Aufnahmeposition? Also es werden auf jeden Fall Unsicherheiten mit einbezogen.
Es gibt auch ein Randomness Seed, der man eingeben kann, sodass man die gleiche Unsicherheit wieder bekommen kann. Ich weiß nicht genau, welche Parameter alle mit einfließen. Hanna, kannst du wieder einspielen? Genau, wir haben einmal in den Scanners, also Scanner XML,
wenn wir jetzt mal im Wiki auf die Scannerseite gehen, ein Parameter der Accuracy, der eben für die Distanz Messung von dem Laserscanner eine Genauigkeit angibt, wo wir dann eben mehr Rauschen haben, wenn diese Genauigkeit geringer ist. Dann haben wir unter
Platforms auch noch die Möglichkeit Platform Noise zu spezifizieren. Ich weiß gar nicht, ob das hier ist. Oder sonst auch unter Aerosources and Randomness Control. Genau.
Das heißt, dass man quasi Unsicherheit in der Position und Ausrichtung von der Platform auch simulieren kann. Genau über die Syntax, wie hier beschrieben ist.
Johannes, bist du noch da? Ich glaube, man hat dich kurz nicht gehört.
Ich muss die Frage nochmal wiederholen. Meine Webcam ist gerade ausgefallen. Es war keine Frage, es war nur der Hinweis für die Zuschauer, die Astrid hat im Chat den Link zum Wiki und zum Jetup Repository gepostet. Da ist das auch noch nachlesbar.
Bezüglich der Unsicherheiten hätte ich noch eine Frage. Und zwar, wenn wir mit einem terrestrischen Laserscanner arbeiten, welche Einstellungen sind da am sinnvollsten?
Wie ist da der Workflow von Aufnehmen der Punktwolke oder Planung aufnehmen und Verarbeitung im Anschluss? Könnt ihr das nochmal zusammenfassen? Meinst du jetzt bezogen
auf ein virtuelles Laserscanning oder in der Realität? Realität. Also wie man da diesen Workflow gestaltet. Konkrete Anwendungsfälle. Wir haben einen terrestrischen Laserscanner, einen Airborne Laserscanner zur Verfügung und eine fotokametrische Drohne.
Wie ist der Workflow? Da gebe ich wieder hinter dich ab. Ich war selber noch nie im Feld und kenne es gar nicht so gut aus. Also geht es jetzt dann darum, wie wir jetzt Helios dafür nutzen würden? Genau.
Es wäre dann wahrscheinlich so ein Anwendungsfall von wir wollen ins Gelände und wir wollen möglichst optimale Aufnahmeparameter um irgendwie eine Punktwolke, also die wir für unsere Analysen gut nutzen können,
die uns aber gleichzeitig auch möglichst viel Zeit im Gelände sozusagen einsparen. Also mit dem geringsten Aufwand die besten Punktwolken generieren sozusagen. Da wäre es halt wichtig, dass wir davor wissen, für was wollen wir die Punktwolken verwenden. Vielleicht haben wir schon einen Algorithmus parat. Und dann können wir eben
die Simulation erst mal in Helios++ durchführen, unsere Algorithmen darauf laufen lassen und dann schauen, wie gut es funktioniert, eventuell noch Anpassungen treffen, bevor wir dann tatsächlich ins Gelände gehen. Also wir können dann zum Beispiel vergleichen, welche Scanner Einstellungen wir benutzen,
vielleicht sogar, welcher Scanner überhaupt am sinnvollsten ist, wenn wir da nicht schon ehe eingeschränkt sind. Und zum Beispiel auch sehen, ob wir überhaupt terrestrisches Laserscanning brauchen oder ob wir das mit drohengestürztem Laserscanning schon gut aufnehmen können. Das wären so verschiedene
Fragestellungen. Und eine Idee wäre dann ganz viele Simulationen mit viel variierten Parametern durchlaufen zu lassen und dann zu mit Punktwolkenanalysen zu schauen, welche sich am besten eignen. Vielen Dank. Bei uns ist tatsächlich der
Anwendungsfall mit Laserscanning sehr oft. Und daher ist das für uns sehr interessant. Vor allem, da wir sehr viel Indoor Laserscanning nutzen. Wie würdet ihr da diesen Workflow gestalten, dass mit Bahnarchitekt vom Architekt
einen Bestandsplan, den wir haben, in 2D oder so, um dann von da in das 3D-Punktmodell zu kommen, um das möglichst effizient zu gestalten. Also ihr habt nur den 2D-Plan, ihr habt noch keine Aufnahme in der Realität durchgeführt?
Wir haben vorher welche Aufnahmen in der Realität wir durchgeführt haben, ist unterschiedlich. Also teilweise haben wir Anschlusspunkte an das Festpunktnetz, also georeferenziert.
Aber das wir quasi, wir kommen in eine Firma oder in ein Gebäude rein, wollen direkt loslegen, aber müssen, wollen ja im Büro das planen und simulieren, dass wir möglichst wenig Zeit verschwenden. Also da könnte ich mir gut vorstellen, dass man über so
ein 3D-Modellierungssoftware, wie zum Beispiel Blender geht, oder auch ähnliche Programme, die da auch oft verwendet werden, weil man wahrscheinlich aus so einem Plan gerade bei Indoor-Szenen schon recht gut auch eine 3D-Szene generieren kann. Aus den bekannten Punkten oder
es kommt natürlich darauf an, was für Objekte dort sind. Genau, dann ist wahrscheinlich die Szenenerstellung erstmal das quasi wichtige und dann kann man Helios dazu nutzen, wo man zum Beispiel die Scan-Position braucht, um eben den gesamten Innenraum abzudecken. Wir haben auch einen
Plugin, Blender to Helios, glaube ich, heißt das, mit der man eine Blender-Szene dann direkt umwandeln kann in so eine Helios XML-Datei. Vielen Dank. Es kam jetzt noch eine weitere Frage rein. Wurden die simulierte Punktwolke mit empirischen Daten
verglichen? Wenn ja, wie sieht die Übereinstimmung aus? Ja, das haben wir zum Teil schon gemacht. Ich habe dazu mal was geforscht, da war das im Forstbereich,
wo ich eben Bäume modelliert habe mit Boxen-Modellen und dann auch immer ALS oder ULS-Bepflegungen, also Reale als Referenz genutzt habe und dann verschiedene Baumparameter vergleichen habe. Das ist natürlich noch ein bisschen indirekterer Weg und relativ viel Komplexität. Und wir haben auch noch kleinere Experimente,
unter anderem auch in Planung, um so was zu validieren. Alles klar, vielen Dank. Jetzt noch eine konkrete Anwendungsfrage.
Wie viele hättet ihr Interesse an einer realen Durchführung im Feld so ein Workflow mal zu testen? Oder habt ihr da bereits
Geräte von der Uni zur Verfügung und macht das sowieso? Ja, also wir haben an unserem Institut sowohl terrestrische Laserscanner als auch für die drohengestützten Laserscanner oder
kompatiblen Laserscanner. Und genau machen daher auch immer wieder so Validierungen oder haben zumindest die Möglichkeit, reale Daten aufzunehmen und auch zu vergleichen. Aber wir sind generell immer sehr offen für auch Kollaborationen.
Also kontaktiert uns gern. Ich denke, jetzt sind wir am Ende unserer Session.