Dann kommen wir zum zweiten Vortrag in dieser zweiten Session. Wir begrüßen Hannes Neuschmidt, der kommt tatsächlich hier von der TU Hamburg und wird uns was erzählen, wie man Radar-Daten benutzt, um Gebäudeschäden zu detektieren.

Ein Applaus. Moin, wie gesagt, ich bin tatsächlich von hier. Das Forschungsprojekt, das ich heute vorstelle, kommt allerdings nicht ursprünglich

von der TU, aber dazu zeige ich nochmal mehr. Es geht darum, wie wir ein Open Source Simulationsprogramm benutzen, das im Titel RACER heißt, ursprünglich vom DLR, um eben Gebäudeschäden zu erkennen. Ich bin hier Student an der Universität, ich habe mal an der Uni Hamburg vorher studiert. Der Grund ist in rechnergestützten Naturwissenschaften und Ingenieurwesen.

Und ich war letztes Jahr, für ein halbes Jahr, in Japan an der Tokyo University und da kommt dieses Forschungsprojekt auch her, über das ich heute spreche. Andere Leute, die daran beteiligt sind, sind einmal mein Betreuer hier von der Uni, vom Institut für Hochfrequenstechnik, da kommt so ein bisschen der Radar-Hintergrund

her, Kai Hübner, und vom DLR der ursprüngliche Autor von diesem Simulationsprogramm, Herr Dr. Stefan Auer, der sehr freundlicherweise irgendwann in meinem Laufe meiner Masterarbeit dazugekommen ist und mich jetzt sehr aktiv auch unterstützt bei meiner Forschung und von der Tokyo University Frau Ece Yeho, die dieses Forschungsprojekt eigentlich

hauptsächlich trägt in ihrer Doktorarbeit, in der sie Methoden zur Erkennung von Gebäudeschäden entwickelt, indem sie eben RACER benutzt. Und wir haben auch einen Bachelorstudenten, Yuda Izuki, der in seiner Bachelorarbeit einmal den kompletten Fall von vorne bis hinten an zwei Beispielen an dem Erdbeben

der Türkei letztes Jahr und in Japan mal durchgeführt hat, um zu gucken, wie gut die Methoden sind. Die beiden zuständigen Professoren sind Herr Shinichi Koshimura von der Tokyo University und Alexander Köppin von hier. Nun, wir stellen uns vor, wir haben folgendes Problem. Wir haben irgendwie ein Erdbeben gehabt und jetzt ist eine Menge kaputt und wir

wissen gerne, wo ist was kaputt, damit wir effektiv unsere Ressourcen verteilen können und erst respons entscheiden können, wo das hin muss. Also dafür brauchen wir über den Überblick, welche Gebäude sind eigentlich kaputt, wo sind die Gebäude kaputt, wie groß ist der Schaden insgesamt? Und um das effektiv zu machen, möchten wir möglichst schnell ein Ergebnis

haben und auf dem großen Gebiet sehen können, wie der Schaden ist. Nun ist es so, dass auch heutzutage häufig noch diese Daten erfasst werden, indem tatsächlich jemand da hingeht und guckt, wo ist was kaputt, wir können das hier mappen. Das hat aber natürlich ein paar Nachteile, insbesondere geht es nicht unbedingt besonders schnell und zweitens gerade nach einer Naturkatastrophe

kann das einfach gefährlich sein, sich in solche Gebiete zu begeben. Also besser ist es, wenn wir einen Satelliten haben, von dem aus wir sehen können, was wir da tun. Dann haben wir eine große Fläche. Wir können vielleicht auf so einem Bild ganz gut erkennen, wo ist denn hier ein Gebäude komplett zerstört worden? Wo ist ein Gebäude stark beschädigt worden, aber steht noch?

Aber auch normale, sagen wir mal optische Satellitendaten haben da ihre Schwächen, zum Beispiel Wolken. Es kann sein, dass wir einfach nicht sehen und in so einem Fall von einem Erdbeben durch möchten wir aber so schnell es irgendwie geht reagieren. Wir wollen also gerne das erste Bild nehmen, das wir bekommen können. Und das erste Bild, das wir bekommen können, sieht normalerweise so aus.

Mit Radar Daten haben wir einfach bestimmte Vorteile gegenüber den optischen in diesem speziellen Anwendungsfall, denn so ein Radarsensor ist ein aktiver Sensor, der kann also auch nachts wunderbar senden und empfangen. Und außerdem kann man mit Mikrowellen durch Wolken durchgucken. Das heißt, wir haben dieses Problem der Bevölkerung einfach nicht.

Hat allerdings auch ein paar Nachteile mit den Radar Daten, denn wenn man jetzt mal sich diese beiden Bilder hier anguckt, können Sie mir vielleicht sagen, auf welchem Bild können Sie leichter erkennen, wo das Gebäude zerstört worden ist? Mit den Radar Daten ist das nicht immer so ganz einfach. Und das ist sowohl für uns Menschen so als auch für Maschinen. Und ein paar Gründe dafür sind die folgenden. Einmal muss man, um so ein Radarbild zu machen, weil das fundamental

eine Entfernungsmessung ist, muss man seitlich gucken, damit man irgendwie groß was sieht. Dadurch entsteht natürlich ein Schatten. Also man hat kein Bild von oben herab und in diesem Schatten können Dinge sein, die auf dem Bild einfach nicht vorhanden sind. Außerdem auch dieser Entfernungsmessung geschuldet ist es so, dass so ein Radarbild einfach nicht genauso aussieht

wie ein optisches Bild. Verschiedene Effekte sorgen einfach dafür, dass es schwieriger zu interpretieren ist. Und deswegen lohnt es sich, Methoden zu entwickeln, um das effektiv automatisch machen zu können. Ich gebe jetzt keine ganze Lektur über SA, aber um sich das mal vorzustellen, haben wir hier eine Beispielszene. Das ist ein Kernkraftwerk in Nordjapan,

das nicht so weit weg von dem Epizentrum eines Erdbebens 2011 stand. Das handelt sich allerdings nicht um das bekannte Kernkraftwerk Fukushima, das damals also schwer beschädigt worden ist, sondern um eins, das sehr ähnlich ist mit dem entscheidenden Unterschied, dass die Seemauer ein Stück höher gebaut worden ist. Und da dieses Kernkraftwerk in Onagawa tatsächlich

das Erdbeben ziemlich unbescheidet überstanden hat und auch den Tsunami. Grundsätzlich ist es nun so, um davon so ein Saalbild zu machen, fliegen wir mit dem Satelliten oder das ging ja auch mit dem Flugzeug oder anderen anderen Plattformen, aber in unserem Fall mit dem Satelliten dran vorbei und senden also immer Pulse von verschiedenen Positionen

auf unserem Flugpfad und basteln uns aus den Reflektionen, die wir dadurch messen, eben dann so ein zweidimensionales Bild zusammen. Das sieht dann so aus, das ist hier die gleiche Szene, ein bisschen andere Perspektive, aber man sieht vielleicht die zwei Türme ganz gut auch auf dem Radarbild. Und die Flugrichtung ist jetzt hier unsere horizontale Achse und die Entfernungsmessung geschieht dann quasi natürlich von der Höhe in Richtung unten

und daraus kann man dann eben so ein zweidimensionales Bodenbild berechnen. Wenn wir das jetzt anwenden wollen auf unser Problem in der Schadenserkennung, wir wollen gerne eigentlich ein Machine Learning Modell haben, das also automatisch uns genau sagt, wo es was kaputt gegangen.

Da haben wir zwei Standard Anwendungsfälle. Das eine ist Schadenserkennung, wo wir wirklich unser Modell nur auf Gebäuden trainieren, sagen, das ist kaputt, das ist nicht kaputt. Und das gibt uns dann aus einem reinen Nachherbild die Gebäude, die tatsächlich zerstört worden sind. Das hat den Vorteil, dass wir da in Falle eines Erdbebens

also wirklich nur ein Bild von hinterher brauchen. Das andere ist Veränderungserkennung. Da bräuchten wir ein Bild zum Vergleichen vorher und nachher, um damit das Modell eben sagen kann, okay, hier hat sich groß was verändert, vielleicht ist das Gebäude da kaputt gegangen. So es ist nun aber leider so, dass wir hochauflösende Radar Daten nicht unbedingt haben.

Also deswegen ist dieses Problem der Veränderungserkennung nicht immer ganz einfach lösbar, denn so hochauflösende Bilder kriegen wir nur, wenn wir den Satelliten oder den Sensor länger auf ein bestimmtes Ziel ausrichten, das uns halt interessiert. Dafür muss man also vorher wissen, welches Gebiet uns interessiert. Und wenn man nicht weiß, wo das Erdbeben passieren wird,

hat man vielleicht also kein Vorherbild mit hoher Auflösung. Und außerdem, wie vorhin schon einmal erwähnt, wir wollen ja immer möglichst so schnell wie möglich reagieren, das erste Bild nehmen, was wir haben. Und das kann halt dann sein, dass es nicht dem Vorherbild entspricht, in dem es ein anderer Satellit ist, ein anderer Sensor, andere Auflösung, vielleicht guckt er aus einer anderen Richtung. Das macht das alles nicht so einfach, so einen Vergleich herzustellen zwischen den Bildern.

Genau, also flächenabdeckendes Saar gibt es hier von Sentinel zum Beispiel, hat aber dann eben nicht unbedingt die Auflösung, die man gerne hätte. Da wird es dann schon deutlich schwieriger zu erkennen, wo da was kaputt gegangen ist. Warum benutzen wir also Simulationen? Im Prinzip nehmen wir den Simulator für unsere Zwecke,

um dieses Datenproblem zu lösen, das wir haben. In dem Fall der Schadenserkennung können wir also eine Menge Trainingsaufnahmen quasi von zerstörten und nicht zerstörten Gebäuden generieren. Einfach dadurch, dass im Simulator ich alles kontrollieren kann, von wo gucke ich, was ist die Auflösung und so weiter. Da habe ich volle Kontrolle drüber.

Und wenn ich mir jetzt ein Datenset irgendwie zusammen sammle aus vorherigen Events, dann kann es sein, dass, sagen wir mal, 90 Prozent alle aus 45 Grad Einfallswinkel gucken oder so. Also dadurch ist mein Datenset nicht unbedingt so, wie ich es gerne hätte. Und besonders spannend ist auch die Anwendung in der Veränderungserkennung, weil da können wir uns tatsächlich ein Vorherbild generieren, wenn wir keins haben.

Also wir nehmen das Nachherbild, gucken, wo habe ich hergeguckt? Was ist die Auflösung? Was sind die anderen Parameter? Und dann generiere ich mir durch den Simulator ein Vorherbild von der gleichen Szene. In beiden Fällen ist man natürlich und da ist ein bisschen der Knackpunkt davon abhängig, dass man irgendwie ein 3D Modell hat von dem, was man da gerne simulieren wollte.

Das kann je nachdem, wie hoch die Ansprüche sind an das Bild, dass man daraus kriegen will, ein relativ einfaches Höhenmodell einfach sein. Aber je besser das 3D Modell, desto besser wird dann am Ende auch die Simulation. Der Simulator, den wir benutzen, nennt sich Racer. Das ist ein Projekt, das ursprünglich von Stefan Auer entwickelt wurde

in seiner Doktorarbeit im DLR und an der TU München. Wer sich da besonders für interessiert, genau dieses Paper beschreibt das im Detail. Aber was daran auch interessant ist, so für die Open Source Community, ist, dass er ein sehr historisch existierendes, schon lange existierendes

Open Source Projekt genommen hat, nämlich den Persistence of Vision Ray Tracer und den so verändert hat, dass wir damit Radarbilder tatsächlich machen können. Puffray ist ursprünglich eigentlich dafür gemacht worden, aus bestimmten 3D Modellen optisch fotorealistische Bilder zu generieren. Also es ist ein ganz normaler, sagen wir mal, Ray Tracer, der aber schon seit vielen Jahren existiert.

Und ja, Dr. Auer hat dann eben dieses Projekt genommen, den Source Code genommen, den so verändert, dass wir die entsprechenden Reflektionsdaten daraus generieren können, aus diesem Ray Tracing, die wir benötigen, um das Sabel zu simulieren und hat dann sein eigenes Projekt dann auch wieder verfügbar gemacht

und dann erfreien die Zinsen. Wir gehen mal durch, wie das so mit so einer Simulation funktioniert. Wir haben hier wieder die gleiche Szene. Das ist unser Kernkraftwerk. Davon brauchen wir jetzt also ein 3D Modell. Das könnte so aussehen, zum Beispiel das hier ist ein Leiter-Scan von der Gegend, aber angereichert mit jetzt genaueren Gebäudemodellen,

die man halt da kombiniert hat, um ein besseres Modell zu bekommen. Man kann viele Sachen auch mit einem einfachen Höhenmodell machen. Aber natürlich, je besser das 3D Modell, desto genauer wird die Simulation. Jetzt haben wir das 3D Modell. Jetzt lassen wir unseren Ray Tracer darauf mal laufen.

Moment, genau, geht nicht, denn Poffray hat sein eigenes Format. Wir müssen also erst mal so ein normales CAD-Modell erst mal in das Poff-Format umwandeln. Das ist so eine große Textdatei, in der dann all die Dreiecke, die in dem Modell drin sind, alle beschrieben sind. Und auch die anderen Informationen über den Sensor und über die Oberfläche von dem Modell werden alles in dieser einen Datei festgelegt.

So das ist so, wie Poffray das immer schon gemacht hat. Und Racer baut halt quasi darauf auf und macht das dann auch. Man sieht jetzt hier an diesem Beispiel ganz gut, weil wir einen Satelliten haben, der aus einer Richtung sendet und empfängt, haben Lichtquelle und Kamera quasi immer die gleiche Position. Zumindest für den einfachen Safer, den wir hier betrachten.

Dann machen wir das, dann kriegen wir so eine große Tabelle mit den Reflexionsdaten, wo es was passiert. Zusätzlich zu dem, was ich jetzt hier aufgelistet habe, kriegen wir tatsächlich auch die normalen kathesischen XYZ-Koordinaten von dem Event. Also wir wissen nicht nur, was der Sensor sieht, wo das entstanden ist, sondern auch wo das tatsächlich entstanden ist.

So eine Reflexion, das kann ganz nützlich sein. Ich hatte vorhin schon mal erwähnt, dass so optische Effekte einfach in Saarbildern auftreten und die kann man ganz gut analysieren mit diesen Simulationsdaten, weil wir tatsächlich wissen, okay, wo erscheint es in dem Bild und wo kommt es eigentlich tatsächlich her? Wenn man dann seine Reflexionsdaten hat, dann geht man aktuell durch so ein Matlab-Interface

und gibt dann da seine Daten ein. Und erst an diesem Punkt entscheidet sich so etwas wie die Auflösung, unsere Simulation ist erst mal mit einer sehr engen Auflösung, die eigentlich nur durch was wir an Pixeln quasi vorgegeben haben, begrenzt ist. Aber hier können wir in Weltauflösungen, Metern in diesem Beispiel

sagen, okay, vielleicht haben wir hier 30 Zentimeter, mal 30 Zentimeter kacheln. Und so kann man das dann eben auch anpassen an ein Vorherbild, wenn man denn nur eins hat. Genau, dann läuft die Simulation und dann kriegt man hinterher hoffentlich ein schönes Saarbild und kann dann eben diverse Sachen damit machen.

Bei unserem Forschungsprojekt ist es nun so, dass ich persönlich mich beschäftige mit dieser Simulation, denn es gibt ein paar Dinge, die daran noch verbessert werden können. Was ich eben vorgestellt habe, ist der Zustand, wie RACER existiert, wie er auch offen zugänglich momentan verfügbar ist. Aber es gibt eben ein paar Schwierigkeiten damit, die wir gerne behandeln möchten. Und der Teil, sich dann modell zu überlegen,

dass gut beschädigte Gebäude erkennen kann, das ist Aufgabe meiner Kollegin. Welche Schwierigkeiten haben wir? Einmal ist es so, dass die Reflektionen zwar geometrisch sehr genau dargestellt werden, tatsächlich von RACER mit so einem Modell, eben abhängig davon, wie gut das Modell ist.

Allerdings sind die Helligkeitswerte nicht unbedingt physikalisch. Das hängt damit zusammen, wie dieser Ray Tracer, Puff Ray, Reflektionen simuliert. Das ist ein relativ einfaches Modell, das sieht zwar ganz gut aus, wenn man sich das so als optisches Bild anguckt, aber man kann eben jetzt schlecht sich darauf verlassen, dass die Helligkeit eines bestimmten Pixels in dem echten Bild so ähnlich ist.

Also die Verteilung passt, aber die tatsächliche Helligkeit ist nicht unbedingt nutzbar, um dadurch zu erkennen, ob ein Gebäude nun beschädigt ist oder nicht in unserem Fall. Und der Rest dieser Probleme, womit ich mich tatsächlich in meiner Arbeit direkt beschäftigt habe, hängt alles damit zusammen, wie dieses Programm nutzbar ist für unseren Zweck.

Also es ist nicht so einfach, so eine GUI, die wir da haben, zu automatisieren. Man muss da sich Hände durchklicken. Grundsätzlich ist es so, dass RACER eine Reflektionsdatei hat, die es dann bei jedem Run wieder überschreibt. Das heißt, man hat immer nur genau ein Bild und muss es dann erst mal sichern.

Es dauert eine ganze Weile, weil Puff Ray als altes Projekt komplett an die CPU gebunden ist. Und wer heutzutage sich mit modernen Spielen beschäftigt, weiß, dass Ray Tracing wirklich, dafür gibt es heutzutage richtige Hardware. Das ist ein typisches Problem, dass man

so parallel wie möglich durchführen kann, weil jeder einzelne Ray, wo man also ein Sample hat für die Reflektion in dem 3D Modell, ist völlig unabhängig von allen anderen. Das lässt sich also wunderbar auf Grafikkarten machen. Aber leider ist Puff Ray dafür nicht ausgelegt. Außerdem erbt man mit Puff Ray einfach eine sehr große C++ Procode Base,

die so nach meinen Experimenten sich auf unterschiedlichen Betriebssystemen auch unterschiedlich gut kompilieren lässt. Also alles möglich. Aber das Leben ist nicht immer einfach. Und am Ende haben wir eben eine Abhängigkeit von Matlab, die das Ganze nicht ganz so frei macht, wie es eigentlich sein könnte. Es gibt zwar auch in der aktuellen Version ein kompiliertes Matlab Artifakt quasi.

Das heißt, man kann das auch ohne Lizenz anwenden, aber dann kann man da nichts groß dran verändern. Was ich also gemacht habe, ist in so gemeiner Masterarbeit und diesem Forschungsprojekt in Japan das Backend einmal komplett neu zu implementieren. So die Grundidee war dabei, Puff Ray ist ein super Ray Tracer, den ich jetzt nicht mal eben nachbilden kann. Aber für unsere Simulation benutzen wir nur einen kleinen Bruchteil davon.

Wir benutzen wirklich hauptsächlich den grundlegenden Algorithmus und der ist für Ray Tracing gar nicht so kompliziert. Wichtig war es eben, das auf ein Fundament zu setzen, dass auf einer GPU laufen kann, wo ich dann alle meine Rays parallel durchführen kann. Andererseits wollte ich aber die Kompatibilität mit Racer

so weit wie möglich erhalten, weil das tatsächlich in diesem Bereich von relativ vielen Forschungsgruppen schon benutzt wird. Es wäre also nett, wenn man ja weiter mit den gleichen Daten und so weiter und den gleichen Pipelines arbeiten kann, aber dann möglichst mit einem moderneren Backend. Und außerdem habe ich für das Fundament zumindest einen Teil,

also der, der wirklich aus diesen Daten das Endbild erstellt, einmal in Julia neu implementiert, sodass man dann ohne, dass man durch Matlab gehen muss, ohne dass man durch diese grafische Interface gehen muss, quasi automatisch einmal das Ganze durchlaufen kann. Und um mal zu vergleichen, am Ende wollen wir ja möglichst

die gleichen Daten benutzen. Jetzt mit meinem neuen Projekt ist es allerdings so, dass wir ohne diese Puff-Datei auskommen. Also wir müssen nicht unser Modell, das in den meisten Fällen in einem normalen CAD-Format irgendwie vorgelegen hat oder sich zumindest dahin leicht übertragen lässt. Als zum Beispiel OBJ-Datei kann man jetzt direkt verwenden,

also anstatt das erst mal in dieses andere Format übertragen zu müssen, was manchmal ein bisschen schwierig geworden ist. Dafür gibt es zum Beispiel kein gutes Programm, das irgendwie unter Linux vernünftig läuft. Ansonsten die ganzen Parameter kann man jetzt über die über die Command Line Flex übertragen. Das ist quasi genau das Gleiche, was ich über die Datei vorher gemacht habe. Ich mache es nur jetzt halt mit einem anderen Interface.

Und dadurch kann man hierfür relativ leicht einen Skript schreiben, das einfach sagt, nimm mal die gleichen Parameter, gib mir mal Contributions-Dateien mit verschiedenen Namen, damit sie nicht immer wieder überschrieben werden. Genau. Und dann machen wir das gleiche Bild irgendwie aus 50 verschiedenen Kamerapositionen oder so. Dadurch kann man relativ leichten Datenset machen.

Und ein anderes Projekt, an dem ich in diesem Kontext arbeite, ist quasi das existierende Racer, das aktuell auf GitHub liegt und also zugänglich ist, für die Öffentlichkeit ein bisschen zu modernisieren. Da hat lange niemand mehr dran das gemacht. Das ist ein bisschen alter Forschungscode, so mit den Tücken, die damit verbunden sind.

Also das wurde zwar damals intensiv verifiziert in der Forschung, aber halt sehr händisch. Also es gibt nicht irgendwie groß automatische Tests oder Versionskontrolle oder also Dinge, die vielleicht nett wären, wenn man sich traut, da mal was anzufassen und was zu ändern als Community. Ich arbeite also daran, das jetzt mal auf den Stand zu bringen, dass man da seine eigenen Sachen vielleicht einbringen kann

und damit auch meine Änderung da eben eingebaut werden kann. Und da bin ich auch Herrn Stefan Auer sehr dankbar, dass er mich dabei aktiv unterstützt. Also ich bin zwar der Einzige, der jetzt aktiv irgendwie was entwickelt, aber ich kriege von ihm also Zugang zu all diesen Sachen und insbesondere auch Einblick in weiteren Code,

den das DLR im Moment hat, der aber eben nicht frei verfügbar ist. Besonders interessant, was wir uns jetzt gerade anschauen, ist, können wir diese Simulationen so machen, dass sie halt mit Geokoordinaten dann auch wieder rauskommen. Also wenn man ein Modell hat, so ein Höhenmodell mit Geokoordinaten, wäre es doch nett, wenn das Saabelt auch Geokoordinaten hat. Und das DLR hat das. Man muss es nur halt jetzt in das Open Source Projekt eingliedern,

damit man das auch benutzen kann. Ja, vielen Dank, dass Sie zugehört haben. Genau, wenn Sie das interessiert. Auf GitHub, wie gesagt, liegt aktuell die alte Version. Meine Version ist jetzt noch nicht veröffentlicht, aber da ich meine Masterarbeit demnächst abgebe, wird es dann wohl auch passieren.

Ja, vielen Dank. Spannend. Ich gehe einfach mal direkt hier drauf ein. Welchen Vorteil hat RACER gegenüber INSA bei der Erkennung von Oberflächenbewegungen?

Es sind zwei verschiedene Sachen. Also RACER betrachtet INSA aktuell gar nicht. Es gibt eine Menge Aspekte von SA, die wir nicht können. Es ist nur so, dass ich RACER im Nachhinein benutzen kann auf irgendeinem Modell, das ich halt habe. Also ich könnte INSA benutzen, um mir ein 3D-Modell zu machen,

um zu gucken, wie hat sich die Oberfläche verändert. Aber die Idee ist, ich habe jetzt als Stadt oder als Ort, der vielleicht in einem Gebiet liegt, das möglicherweise von einem Erdbeben oder irgendeiner anderen Katastrophe getroffen werden könnte. Also ich muss ein vorliegendes Modell haben. Und dann kann ich RACER benutzen,

um mir nachträglich Bilder dafür zu machen. INSA ist natürlich toll, wenn ich es habe, aber ich habe da genau diese Probleme einfach von der Datenverfügbarkeit. Also wenn ich ein super auflösendes INSA-Bild habe von vorher, hinterher, dann brauche ich RACER nicht. Aber die Situation haben wir einfach nicht. Könnte man diese Simulation theoretisch auch

für optische Daten erweitern beziehungsweise umbauen? Kann man. Es ist tatsächlich so, dass optische Daten aus dem Bild aktuell auch schon einfach rausfallen, weil Puffray das automatisch tut. Puffray macht optische Bilder. Es ist auch so, dass das DLR, wie gesagt, weitere Sachen damit gemacht hat. Und dazu gehört auch eine optische Simulation.

Also man kann dann zum Beispiel vergleichen, welche Pixel auf einem Bild gehören bei einem SAR-Bild und beim optischen Bild zu dem gleichen Objekt. Also das ist was, was sich auf Pixel-Basis nicht so einfach machen lässt, wenn man aus verschiedenen Richtungen guckt. Genau, also kann man und ist auch schon passiert, ist nur aktuell noch nicht verfügbar quasi.

Wie lange dauert es in der Regel vom Start der Aufnahme, bis die Information bei den Einsatzkräften oder der CATS-Stelle ankommt? Das ist eine sehr gute Frage. Und da habe ich tatsächlich überhaupt keine Ahnung. Also ich vermute, das ist auch abhängig davon, ob man jetzt in Japan ist oder in Deutschland. Also da kann ich nichts zu sagen, leider.

Jetzt habe ich noch eine Frage. Wurde das wirklich, also wird das aktiv eingesetzt? Nein, also das ist noch nicht so. Also es gibt so ähnliche Projekte, um so Schadenserkennung zu machen aus SAR-Bildern. Ich glaube, das wird tatsächlich auch eingesetzt. Aber da nimmt man halt, wenn man denn hat, echte SAR-Bilder. Also das ist jetzt ein Forschungsprojekt, um diese Fähigkeit herzustellen quasi.

Das ist nichts, was aktiv benutzt würde. Aber natürlich also den Effekt, dass man aus Satellitenbildern guckt, wo ist Schaden entstanden, das passiert. In den seltensten Fällen wird das bisher die Methode sein, um den Schaden zu mappen. Aber mindestens in Japan,

also ist das nicht nur diese Forschungsgruppe, das ist ein großes Projekt, an dem gearbeitet wird. Da wird viel damit gearbeitet, auch in optischen Daten zu klassifizieren. Aber da hat man halt immer dieses Delay, das man eigentlich nicht gerne hätte, wenn nicht gerade Himmel toll ist und der Satellit genau da, wo man ihn braucht. Cool. Gibt es Fragen im Raum?

Nein, sieht nichts aus. Dann noch mal einen schönen Applaus. Und hier geht es im Falle nach weiter.