Workflow zur Erstellung von Trainingsdaten für die KI-Gebäudeerkennung
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 119 | |
| Autor | ||
| Mitwirkende | ||
| 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 | 10.5446/67667 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
14
45
50
55
67
69
72
75
78
87
95
00:00
Demoszene <Programmierung>Instanz <Informatik>BildanalyseProzess <Physik>BildanalyseChipkarteGeoinformationDemoszene <Programmierung>QR-CodeOrdnung <Mathematik>Notebook-ComputerMustererkennungDemo <Programm>WellenpaketRechenschieberCoxeter-GruppeVorlesung/KonferenzBesprechung/InterviewComputeranimation
02:33
Gebiet <Mathematik>Ordnung <Mathematik>Baum <Mathematik>
03:21
Gebiet <Mathematik>Ordnung <Mathematik>Physikalische Größe
04:07
Scrum <Vorgehensmodell>IBMOrdnung <Mathematik>Gebiet <Mathematik>StreuungsdiagrammDienst <Informatik>Große VereinheitlichungSoftwareScrum <Vorgehensmodell>DatenbankPunktwolkeLeistung <Physik>MultiplikationsoperatorService providerKartesische KoordinatenMailing-ListeComputersicherheitSoftwareentwicklerNotebook-ComputerGüte der AnpassungComputeranimation
08:24
RechenschieberMengeMereologieGruppenoperationMetrisches SystemGenerator <Informatik>Computeranimation
09:07
PixelDigitales GeländemodellASCIIMeterMatchingPunktwolkeDigitales GeländemodellPixelDiskrepanzBitmap-GraphikFlächentheorieMultiplikationsoperatorRechter WinkelGeradeDigitalisierungTypentheorieZweiBildgebendes VerfahrenProdukt <Mathematik>NormalvektorCoxeter-GruppeKünstliches LebenGenerator <Informatik>Auflösung <Mathematik>DatensatzCASE <Informatik>FontTesselationMereologieEndliche ModelltheorieXMLUMLComputeranimation
12:59
BerechnungResamplingWertevorratDigitales GeländemodellASCIIMeterFeuchteleitungMereologieFlächeninhaltNormalvektorGraphfärbungSpannweite <Stochastik>RechenbuchVersionsverwaltungFlächentheorieAuflösung <Mathematik>DifferenteBerechnungAuflösungsvermögenParkettierungWertevorratComputeranimation
14:34
PostgreSQLDiskrepanzFilterung <Stochastik>IBMDetektionObjekterkennungErweiterungObjektverfolgungModelltheorieWINDOWS <Programm>Pascal-ZahlendreieckDrahtloses lokales NetzPixelGleitendes MittelXMLACCESS <Programm>DatensatzGebiet <Mathematik>WellenpaketProjektive EbeneAggregatzustandNichtlinearer OperatorGamecontrollerPunktProzess <Informatik>ResultanteNotebook-ComputerKoordinatenQuaderBildgebendes VerfahrenPlotterDatenmodellWeb-ApplikationObjekterkennungMikroarchitekturOffice-PaketPolygonIkosaederBasis <Mathematik>Objekt <Kategorie>DokumentenserverDatenbankBildschirmfensterOverhead <Kommunikationstechnik>Endliche ModelltheorieDifferenteCodeWürfelDateiformatGenerator <Informatik>FlächentheorieMathematikFlächeninhaltAuswahlaxiomAlgorithmische ProgrammierspracheWiderspruchsfreiheitCASE <Informatik>Zentrische StreckungMereologieFehlermeldungSchnittmengeTypentheorieMultiplikationsoperatorPhysikalisches SystemMapping <Computergraphik>GraphfärbungBitSoftwaretestDatenfeldProgrammierungProgrammverifikationDiskrepanzWidgetTrennschärfe <Statistik>WINDOWS <Programm>SIMPL <Programmiersprache>PAPVektor <Datentyp>Geodätische LinieiPadApp <Programm>WEBMomentenproblemStreuungsdiagrammDetektionKanal <Bildverarbeitung>DatentypInkonsistenzSichtbarkeitsverfahrenComputeranimation
22:58
IBMGebiet <Mathematik>XMLDatensatzSchaltnetzTaskBildgebendes VerfahrenBildschirmfensterWellenpaketGreen-FunktionWINDOWS <Programm>Computeranimation
24:13
RechenschieberWorld Wide WebCodeFramework <Informatik>Äußere Algebra eines ModulsModelltheorieDesktopSoftwareMultiplikationOpen InnovationPatch <Software>PixelDemoszene <Programmierung>PolygonInternetPixelAbteilung <Mathematik>WINDOWS <Programm>CodeE-MailPAPInformationsmodellierungInkonsistenzDatensatzVerdeckungsrechnungRepository <Informatik>EindringerkennungProzess <Informatik>CASE <Informatik>MultiplikationsoperatorDatenfeldObjekt <Kategorie>MereologieAutorisierungOverhead <Kommunikationstechnik>Algorithmische ProgrammierspracheOffice-PaketInternetworkingObjekterkennungWellenpaketPunktwolkeComputerarchitekturResultanteProjektive EbeneVersionsverwaltungTesselationDifferenteVariablePatch <Software>TopologieDemo <Programm>Endliche ModelltheorieAuswahlaxiomBildgebendes VerfahrenMomentenproblemFehlermeldungÜberlagerung <Mathematik>SchaltnetzBasis <Mathematik>LeistungsbewertungMathematikRahmenproblemTrennschärfe <Statistik>PlastikkarteBildschirmfensterGenerator <Informatik>DokumentenserverWeb-ApplikationYouTubeComputeranimation
31:33
IBMCodeKernel <Informatik>HTTPDemoszene <Programmierung>ZählenMinimumMaximumBrowserACCESS <Programm>LOLA <Programm>Laden <Datenverarbeitung>Patch <Software>UploadingLDAPDetektionFramework <Informatik>URLServerGeodateninfrastrukturZeichenketteRetrievalspracheMedianwertTyp <Informatik>Formation <Mathematik>Proxy ServerFinite-Elemente-MethodeRechenschieberGebiet <Mathematik>FehlermeldungHackerKomponente <Software>ZugriffDatenbankServerParkettierungPlug inSkriptspracheParametersystemObjekt <Kategorie>PunktTesselationAuswahlaxiomElektronische PublikationFlächeninhaltBildgebendes VerfahrenBitMultiplikationsoperatorExpertensystemBildschirmfensterGüte der AnpassungNotebook-ComputerGenerator <Informatik>WellenpaketProjektive EbeneZusammenhängender GraphMetadatenMereologieComputerarchitekturStandardabweichungMathematikQuellcodeMomentenproblemQuaderInterface <Schaltung>Computeranimation
39:55
Wurm <Informatik>ModelltheorieOpen InnovationDatenaustauschSoftwaretestWidgetInteraktives FernsehenBitGenerator <Informatik>DigitalisierungURLResultanteBildgebendes VerfahrenVerschlingungSchnittmengeProzess <Informatik>TesselationIterationAlgorithmische ProgrammierspracheVersionsverwaltungEndliche ModelltheorieFehlermeldungAggregatzustandWiderspruchsfreiheitDifferenteOrdnung <Mathematik>Open SourceLeistungsbewertungWellenpaketObjekt <Kategorie>MathematikEinsNotebook-ComputerOffene MengeMetadatenDatenbankInterface <Schaltung>MultiplikationsoperatorOffice-PaketFokalpunktAutomatische HandlungsplanungGeradePunktSoftwareentwicklerQR-CodeTaskFehlerschrankeEinflussgrößeWeb-ApplikationKomponente <Software>iPadJavaScriptInkonsistenzSoftwareApp <Programm>Open InnovationWEBQuelle <Physik>EigenwertproblemPriorität <Informatik>PostgreSQLGeoinformationGeodätische Liniet-TestLinieDatensatzVersion <Informatik>InformationsmodellierungComputeranimationVorlesung/Konferenz
48:08
Kartesische KoordinatenCoxeter-GruppeWellenpaketResultanteOffene MengeRegulator <Mathematik>Bildgebendes VerfahrenAbstandWärmeausdehnungEndliche ModelltheorieEinflussgrößeStellenringSystemaufrufDienst <Informatik>ProgrammverifikationAggregatzustandPunktwolkeCodeSoftwareLeistungsbewertungOverlay-NetzFehlermeldungHilfesystemCoprozessorGenerator <Informatik>PolygonTypentheorieOpen SourceMathematikZustandsmaschinePortal <Internet>Deskriptive StatistikKanalkapazitätRichtungDokumentenserverE-MailVerschlingungVisualisierungMultiplikationsoperatorProzess <Informatik>Projektive EbeneWeb-SeiteAutorisierungProgrammierungWärmeübergangGraphikprozessorDifferenteURLGoogle Street ViewQR-CodeMengePAPKapazität <Mathematik>InformationsmodellierungÜbertragDatensatzStreuungsdiagrammProzess <Physik>Keller <Informatik>Bucket <Informatik>BefehlsprozessorKomponente <Software>VorverarbeitungRepository <Informatik>Computeranimation
56:21
Computeranimation
Transkript: Deutsch(automatisch erzeugt)
00:07
Ja, guten Morgen. Schön, dass ihr alle da seid. Heute werden uns Uwe Breitkopf und Jonas Bostelmann etwas erzählen zum Workflow zur Erstellung von Trainingsdaten für die KI-Gebäudeerkennung.
00:21
Bei Fragen bitte hier über den QR-Code gehen, damit wir die sammeln können. Danke. Ja, vielen Dank. Ich freue mich, dass wir hier vortragen dürfen und dass so großes Interesse hier besteht an unserem Thema. Genau, mein Name ist Jonas. Ich fange jetzt mit einer kleinen Einleitung an. Wer gestern schon den Vortrag gesehen hat, der erkennt ein paar Folien vielleicht wieder.
00:44
Aber es sind auch ein paar neue Folien dabei. Danach macht Uwe dann noch mit ein paar Folien weiter. Da geht es dann um unsere Trainingsdaten, wie sich das weiterentwickelt hat, die Erstellung dieser Daten. Und am Ende gibt es noch ein bisschen und auch zwischendrin schon mal ein bisschen Demo hands-on,
01:02
wie das Ganze mit QGIS zum Beispiel und mit Jupiternodebooks umgesetzt wurde. Genau, erstmal noch mal zur Einleitung für alle, die vielleicht gestern nicht dabei waren. Warum beschäftigen wir uns beim LGN, beim Landesamt für Landesvermessung und Geoinformation in Niedersachsen überhaupt mit KI?
01:21
Wir haben da einen gesetzlichen Auftrag. Wir müssen nämlich das Liegenschaftskataster führen. Und da sind die Gebäude ein Teil davon. Also einfach die Gebäude in einer Karte, in den amtlichen Karten. Die müssen irgendwie erfasst werden. Und genau, heutzutage ist alles online verfügbar. Wir können jederzeit auf unseren Smartphone, auf die Karten irgendwie zugreifen.
01:43
Wir haben eine viel höhere Anforderung an die Aktualität als vielleicht noch vor 10, 20 Jahren, wo die ganzen Prozesse damals alle entstanden sind. Deswegen wollen wir die Daten schneller aktualisieren. Das Problem ist, wenn man das manuell macht, ist das sehr aufwendig, nicht wirtschaftlich. Macht auch keinen Spaß, da immer die Luftbilder durchzugucken, die Gebäude zu suchen.
02:05
Das sind ziemlich viele Luftbilder, die wir da in Niedersachsen jedes Jahr neu durchgucken müssen. Deswegen bietet es sich da an, irgendwie eine KI zu trainieren und dort automatisierte Bildanalyse laufen zu lassen. Das ist so die Idee, warum wir damit gestartet haben mit dem Vorhaben.
02:22
Also eine Bildanalyse zur Instanzsegmentierung, um dort in den Luftbildern die Gebäude zu erkennen. Genau, jetzt kommen ein paar neue Folien, ein bisschen Ergebnisse. Sollen so ein bisschen zeigen, dass das ganz gut funktioniert. Ich habe mal verschiedene Gebiete aus Niedersachsen rausgesucht.
02:41
Das ist hier direkt an der Küste, irgendwo hinterm Deich. Da werden alle Gebäude gefunden, sieht auch ganz ordentlich aus. Also das ist alles jetzt automatisch von der KI segmentiert. In der Heide, da sieht es so aus, da stehen auch manchmal Gebäude, die wurden gefunden. Das ist beispielsweise städtisches Gebiet, das stimmt nicht, kleiner Fehler.
03:04
Das ist glaube ich im Harz irgendwo, wo man höhere, ein bisschen mehr Erhebung hat, unterschiedliche Geländehöhen. Da funktioniert es mittlerweile auch ganz gut. Da werden auch alle Gebäude gefunden. Bäume werden dann mittlerweile nicht mehr so viele gefunden, aber Gebäude stehen schon noch.
03:24
Genau, das ist irgendwie ein kleiner Fehlerteufel in den Folien. Also das ist jetzt ein bisschen ländliches Gebiet. Dort in den ganzen Dörfern werden alle Gebäude gefunden. Das ist jetzt das städtische Gebiet in Hannover, wo wir auch herkommen. Da werden natürlich viel mehr Gebäude gefunden. Das sieht dann in etwa so aus.
03:42
Hier ist mal ein Unterschied, kleine Gebäude, große Gebäude. Das ist glaube ich hier das VW-Werk in Hannover und da so ein paar Gärten mit kleinen Hütten. Die werden auch alle erstaunlich gut erkannt. Da gab es glaube ich gestern auch eine Frage dazu, wie das so sich verhält mit unterschiedlichen Dacharten, Dachstrukturen, ob das gut funktioniert.
04:04
Und ja, das geht erstaunlich gut, egal wie das Gebäude aussieht. Auch so etwas, ein bisschen komplexer, Herausforderung. Aber tatsächlich so zumindest die Flächen, wo ist Dach und wo ist kein Dach, kann mittlerweile ganz gut unterschieden werden.
04:25
Manche Gebiete sehen dann komplett anders aus, ein bisschen neueres Gebiet. Da funktioniert das auch ganz gut. Das ist jetzt vielleicht auch ein bisschen einfacher für die KI als vorher. Das ist so ein bisschen älteres Gebäude, aber auch gar nicht ganz so alt.
04:43
Hier ist die Marienburg bei Hannover in der Nähe. Auch die wurde erkannt, das funktioniert ganz gut. Wer hat das Ganze gebaut? Wie hat das angefangen bei uns? Seit 2020 arbeiten wir an dem Thema, haben am Anfang mit IBM zusammen das gemacht.
05:02
Haben uns da ein bisschen Kompetenz eingekauft, als wir die selber noch nicht hatten. Hatten da Entwicklerunterstützung, haben mit Cloud angefangen, mit agilem Arbeiten überhaupt, online zusammenarbeiten. Das war dann auch Anfang 2020 ganz praktisch, als Corona kam, dass wir irgendwie alle in der Cloud weiterarbeiten konnten an dem Projekt.
05:21
Das haben wir da alles als Landesamt, als Behörde überhaupt erst mal gelernt, wie das funktioniert. Dann haben wir gemerkt, es geht aber auch nicht ohne eigene Kompetenz und haben ein eigenes Team gegründet. Haben neue Leute eingestellt, haben Bestandspersonal geschult. Ich war auch schon Bestandspersonal in dem Moment, weil ich drei Monate, Ende 2019, beim LGN angefangen habe.
05:43
Habe dann auch noch eine Ausbildung zum Product Owner gemacht und habe dann das Projekt als Product Owner mit übernommen. Oder beziehungsweise bin da Product Owner in dem Team geworden. Genau, das Team sieht man da. Wir sind auch fast alle da, bis auf Bürger, der ist im Urlaub gerade. Janina, Scrum Master, ist nicht mitgekommen und Laura, Team Coach, ist auch nicht dabei.
06:05
Aber ansonsten sieht man da noch mal alle Gesichter und Namen. Eine Person fehlt noch. Wir haben auch noch eine Stellenausschreibung offen gerade und Lukas ist auf dem Foto noch nicht dabei. Genau, wir arbeiten agil nach Scrum, haben immer vier Wochen Sprints.
06:20
Und ganz wichtig ist auch bei unserer Arbeit, habe ich gestern auch schon gesagt, dass wir ganz eng mit den Nutzenden zusammenarbeiten. Also die, die unsere Anwendung, die daraus entsteht aus dieser KI-Gebäudeerkennung, die die nutzen sollen. Mit denen sprechen wir jede Woche. Wenn die Änderungswünsche haben, werden die auch meistens dann schon in den nächsten ein, zwei Tagen umgesetzt.
06:43
Zumindest in der Entwicklungsumgebung. Ja, das ist eine sehr wichtige und sinnvolle Zusammenarbeit mit dieser Gruppe. Ja, das betone ich immer gerne wieder, weil man das oft eben auch gerade so bei so KI-Projekten mit irgendwelchen externen Dienstleistern.
07:02
Oft habe ich das Gefühl, kommt das ein bisschen kurz, dass man die Leute, die am Ende mit der Software arbeiten sollen, dass man die auch wirklich schon in den Entwicklungsprozess mit einbezieht. Das ist, finde ich, eine sehr wichtige Sache und da haben wir sehr gute Erfahrungen mit gemacht. Genau, wir machen das Ganze im DevSecOps-Ansatz in der Cloud.
07:23
Also wir als Team sind halt für Entwicklung, für Security und für Betrieb komplett verantwortlich. Das machen wir alles. Da haben wir die Kompetenz im Team dazu. Wir haben die entsprechenden Tools dafür. Wir können, also haben ja gute Grafikkarten, gute Laptops, gute Tools, mit denen wir zusammenarbeiten können.
07:40
Ja, die Laptops müssen bald mal erneuert werden. Dann brauchen wir ein bisschen mehr GPU-Power und so zum Trainieren der Netze. Ja, aber auch dadurch, dass wir in der Cloud arbeiten können, das ist für eine Behörde ja auch nicht normal. Das ist bei uns zum Glück mittlerweile echt gut, dass wir da uns, wenn wir eine neue VM brauchen oder eine neue Datenbank oder neue Cloud-Ressourcen, können wir uns das einfach relativ problemlos dazu buchen.
08:05
Da muss man nicht irgendeinen Beschaffungsantrag machen oder in irgendeine IT-Firma sich wenden oder beim Dienstleister das beantragen. Das geht bei uns relativ gut und automatisch. Ich glaube, ich muss auch langsam mit meinen zehn Minuten zum Ende kommen.
08:23
Genau, da unten sieht man nochmal die Zeitleister. Und jetzt, das ist jetzt auch schon die Überleitung zu Uwe's Teil gleich. Das ist nochmal das Beispiel. Da sieht man jetzt auch noch so ein paar Metriken gerade, dass wir das gemessen haben. Da sieht man, wie sich jetzt im Laufe der Zeit die Generationen verbessert haben,
08:41
wie das immer besser geworden ist. Und dazu hören wir jetzt von Uwe, wie das so dazu gekommen ist und was wir da alles gemacht haben, wodurch das besser geworden ist. Jo, kannst du das einmal rübernehmen? Das irritiert mich. So, gut.
09:05
Ja, da der Workflow relativ kurz ist für eine Demo, wollte ich halt auch noch ein paar Folien zeigen und mache jetzt einmal einen Rückblick, wie sich eben unsere Generationen über die Zeit verändert haben.
09:22
Und ja, Vorstellung skippe ich jetzt auch mal. Und ich fange direkt an mit einer Datenübersicht. Mit welchen Daten arbeiten wir eigentlich? Ja, Bilddaten kennt man, normale Ortofotos. Hier sehen wir ein Beispiel aus Cuxhaven. Die sind bei uns in 2 km Kacheln verfügbar und 20 cm Bodenauflösung.
09:44
Und eben in rot-grün-blau und Infrarot-Kanälen. Wir haben bis Jahrgang 2020 normale Ortofotos. Die sind eben auf das digitale Geländemodell entzerrt. Und das sieht man in den Bildern dann teilweise hier bei dem höheren Gebäude,
10:03
dass man Fassaden sieht und dass das so ein bisschen wegkippt. Und seit dem Bildflugjahrgang 2021 werden bei uns TrueDops produziert. Und die werden auf eine andere Oberfläche, nämlich auf das Bedom, entzerrt.
10:22
Da komme ich gleich noch dazu. Und man sieht schon, dass das natürlich viel besser geeignet ist für eine KI-Gebäudeerkennung, wenn man eben an den Umrissen interessiert ist. Und ja, seit 2021 sind die Daten auch frei verfügbar.
10:41
Bei den Höhendaten ist das leider noch nicht der Fall, aber das kommt jetzt mit dem zweiten Teil der HVD-Richtlinie. Und bei den Höhendaten, die wir nutzen, haben wir zum einen die digitalen Oberflächenmodelle. Und hier haben wir anfangs mit Daten vom Airborne Laser Scanning gearbeitet, also Punktwolken.
11:04
Und die wandeln wir dann aber durch Rasterisierung in ein Oberflächenmodell. Das sieht man hier in der oberen Zeile. Links die Punktwolke und rechts eben das gerasterte DOM bzw. Englisch DSM. Und hier ist noch wichtig, dass die zu einem anderen Zeitpunkt erfasst wurden
11:24
als die Bilddaten, mit denen wir arbeiten. Also da ist schon mal eine zeitliche Diskrepanz drin. Den zweiten Typ an Höhendaten, den wir seitdem wir sie zur Verfügung haben auch verwenden, sind die B-DOMs, bildbasierte digitale Oberflächenmodelle.
11:44
Die werden eben in der TrueDop-Produktion verwendet. Die entstehen durch fotogrammetrisches Matching der Luftbilder, wo dann letztendlich jedem Pixel einen Höhenwert zugewiesen wird. Und die werden eben verwendet oder auch gebraucht für die TrueDop-Produktion.
12:03
Und man kann das in der mittleren Reihe sehen. Das Beispiel ist hier übrigens auch wieder aus Cuxhaven. Dass die Ränder so ein bisschen frisselig sind. Und in manchen Bereichen, wie zum Beispiel hier im Schatten oder auch im Bereich von Vegetation, sieht man auch teilweise Artefakte.
12:21
Und das sieht man dann auch manchmal in den Luftbildern, dass da die Ränder irgendwie so ein bisschen komisch aussehen. Aber das ist halt den Daten geschuldet. Dann verwenden wir noch das digitale Geländemodell. Das kommt in einer Ein-Mal-Ein-Kilometer-Kachelung und ein Meter Bodenauflösung.
12:41
Das wird aus den LiDAR-Daten erzeugt oder aus den ALS-Daten erzeugt. Aber wir verwenden das eben in der Form. Es kommt im wunderschönen XYZ-ASCII-Format daher, sehr handlich. Wir wandeln das aber in Geotips, weil das dann etwas einfacher ist, damit zu arbeiten.
13:00
Ja, und ich möchte noch ganz kurz auf eine Sache hinweisen. Wenn man sich jetzt hier die Farbskalen ansieht, ich habe vergessen, ein M, also für Meter, dahinter zu schreiben, dann sieht man im oberen Bereich minus 1 bis 25. Das ist eben an der Küste Cuxhaven. Und im unteren Teil sieht man eine Talsperre im Harz. Das geht von 270 bis 370 Meter.
13:22
Und ja, wenn man eben mit solchen numerischen Werten arbeitet, dann ist vielleicht eine Art der Normalisierung wichtig. Und deswegen kommen wir eben zum normalisierten Oberflächenmodell, dem N-DOM. Oder wir verwenden eher die englische Variante NDSM. Die Berechnung ist super easy. DOM minus DGM gleich N-DOM.
13:43
Aber es gibt dann doch ein paar kleine Herausforderungen. Eben unterschiedliche Kachelungen. Dann unterschiedliche Auflösungen. Wir machen das so, dass wir immer auf die höchste Auflösung ressemblen. Außerdem schneiden wir das dann noch auf einen festen Wertebereich aus und wandeln es in 8-Bit, weil es einfacher ist, damit zu arbeiten.
14:04
Und für die Prozessierung hier nehmen wir zum Beispiel Agro-Workflows, was Kollegen gestern vorgestellt haben. Und wenn man sich jetzt nochmal diese Beispiele ansieht, dann haben wir jetzt oben eben das NDSM, was aus den Laser-Scan-Daten erzeugt wurde. Ja, auch im Bereich des Harz.
14:21
Und im N-DOM reichen diese Werte dann eben von 0 bis 30 Meter. Und im Bereich von Cuxhaven eben auch. Also wir können das Ganze an der Küste einsetzen. Oder auch im Hochgebirge. Dann haben wir noch unsere Vektordaten. Da verwenden wir eben Alkes Gebäudeumrisse aus dem Kataster.
14:42
Das sind Polygone im UTM-Landeskoordinatensystem. Die erhalten wir aus, die werden bei uns in Hannover eben irgendwie aus allen Katasterämtern zusammengebracht in eine große Datenbank geschrieben. Und wir bekommen davon einen Export. Und den importieren wir dann wieder in unsere Datenbank einmal wöchentlich.
15:04
Das passiert auch zum Teil mit Agro. Und ja, die Alkes-Daten sollen bei uns die Grundlage für die Trainingsdaten bilden. Und das ist jetzt in gewisser Weise ein Widerspruch. Weil Alkes ist natürlich auch der Datensatz, den wir updaten wollen.
15:21
Also hier drin wollen wir ja Fehler oder Änderungen halt finden. Aber trotzdem wollen wir Alkes als Trainingsdaten verwenden. Und deswegen ist die Annahme hier, dass Alkes korrekt ist. Dabei ergeben sich dann ein paar Herausforderungen. Also zum einen ist das Alkes-Daten-Modell irgendwie nicht...
15:41
Ja, es gibt sehr viele verschiedene Typen. Und man muss zum Beispiel unterscheiden zwischen Bauwerk und Gebäuden. Und bei den Gebäuden muss man auch gucken, an welchen Typen sind wir eigentlich fürs Training interessiert. Wollen wir Biogasanlagen mitdetektieren oder nicht? Also darüber muss man sich Gedanken machen, was halt alles dann in den Trainingsdaten ist.
16:01
Das kann die KI dann halt auch später finden oder eben auch nicht. Dann haben wir eine zeitliche Diskrepanz. Und das ist hier in dem Beispiel mal dargestellt. Oben haben wir einen Dopp von 2020. Und die Alkes-Daten dort sind per Filter... Also das Änderungsdatum ist hier auf zwei Jahre später gestellt.
16:20
Und wir sehen, dass manche Gebäude hier zum Beispiel ja noch nicht erfasst sind in Alkes. Auch zwei Jahre später noch nicht. Und andere, wie zum Beispiel hier dieses oder dieses, da ist gerade die Baustelle sichtbar. Und in dem anderen Beispiel ist noch gar nichts im Luftbild sichtbar.
16:41
Und dann ist es schon in Alkes. Also wir haben halt eigentlich keine Möglichkeit zu wissen, wann Alkes genau zum Bild passt. Also das kann man automatisch nicht gut ermitteln. Also man muss eigentlich draufgucken. Das ist jetzt natürlich ein Extrembeispiel, weil es ein Neubaugebiet ist. Das ist natürlich nicht überall so. Aber wenn man sich das flächig anguckt, dann gibt es doch mehr Änderungen als man denkt.
17:05
Genau, also wir haben eben Inkonsistenzen zu den Bild- und Höhendaten. Außerdem haben wir in Alkes eine Kleinteiligkeit. Also solche Objekte wie zum Beispiel einen Hauseingang oder Balkone oder Garagen. Das sind halt alles irgendwie so kleine Objekte.
17:21
Man weiß nie so genau, gehören die jetzt zu dem Gebäude oder wo ist das Gebäude? Also zu welchem Objekt gehören die? Damit muss man sich halt auch auseinandersetzen. Und wir haben geometrische Differenzen. Wir sehen im Luftbild natürlich die Dachfläche. Und in Alkes ist der Grundriss erfasst.
17:43
Und wenn wir einen Dachüberstand haben, dann können wir das eben nicht sehen. Jetzt komme ich zu dem KI-Modell, was in Generationen 1 und 2 verwendet wurde. Das haben wir so quasi vom Projektpartner übernommen.
18:01
Das war ein zweistufiges Verfahren, was hier eingesetzt wurde. Die Wahl dafür hatte ja Performancegründe. Das Ganze sollte vor allem auf einer CPU-Architektur laufen. Und man wollte eben eine schnelle Objekterkennung haben mit YOLO. Und anschließend die in dem Bereich, wo Objekte erkannt wurden,
18:22
eine binäre Segmentierung durchführen, die halt sehr kostspielig ist oder sehr lange dauert. Wir sehen jetzt hier auch nochmal die beiden Repositories verlinkt, für die Object Detection und die Segmentierung. Und Screenshots daraus. Also das sind, sag ich mal, General Purpose, Computer Vision, Repos und nichts mit Geodaten.
18:47
Dieses waren halt die Grundlage für die Arbeiten. Und es wurde halt angepasst, dass wir dort zum Beispiel nicht nur RGB-Daten reinkriegen,
19:01
sondern auch Höhen-Daten. Und das wurde halt vor allem durch den Projektpartner gemacht und teilweise auch durch Teamkolleginnen. Wie sahen die Trainingsdaten aus? Da hatten wir für die Object Detection so Sliding Windows nannten wir das. Das sind kleine Bildausschnitte.
19:21
Also wir schieben ein sich überlappendes Fenster über die Original Dops und schneiden einen Datenwürfel aus und speichern den als Compressed Numpy Array ab. Die Labels sind dann einfach die Bildkoordinaten der Bounding-Boxen der Alkes-Objekte.
19:43
Und die kamen im Pascal-Wock-Format. Für die Segmentierung hatten wir ein etwas anderes Trainingsdatenformat. Das ist jetzt aber hier unerheblich. Wie sah das Ganze aus, als wir das Projekt für uns als Team übernommen haben?
20:02
Also wir haben den Code dann sozusagen in den eigenen Betrieb genommen und versucht zu verstehen und zu verwenden. Und das war hier der Stand. Und man hatte gerade Vorjahr, oder das war eigentlich auch in den ersten Code Sprints, die wir dann zusammen mit dem Projektpartner hatten,
20:20
da wurde ein neues Object Detection Modell eingeführt. Das war gerade total neu, State of the Art. Also das Paper war wirklich gerade im Januar, glaube ich, erschienen und im Februar wurde das dann schon angefangen zu implementieren. Außerdem sollten eben zusätzliche Kanäle Verbesserungen bringen. Aber die Ergebnisse sahen halt irgendwie nicht so doll aus.
20:44
Und dann war die Frage, woran liegt das? Und wir haben uns dann auf die Suche begeben und uns nochmal detailliert angeschaut, wie sehen dann die Trainingsdaten aus, die da erzeugt wurden. Und das stellte sich halt raus, das sehen wir hier in dem Plot, dass einfach falsche Annahmen gemacht wurden bei der automatischen Erstellung der Trainingsdaten.
21:02
Also es war ein Filter einfach falsch gesetzt. Und der Punkt ist hier einfach, visuelle Kontrolle ist wichtig. Man sollte immer in der Lage sein, Trainingsdaten anzuschauen. Und das ist jetzt hier einfach ein simpler Matplotlib Plot, eben von diesem NumPay Array und den dazugehörigen Bounding Box Koordinaten.
21:22
Daraufhin hat dann eine sehr detaillierte Prüfung der Trainingsdaten Pipeline stattgefunden. Und wir haben die dann eigentlich nochmal komplett neu geschrieben. Und haben dann neue Trainingsdaten generiert in verschiedenen Teilen von Niedersachsen.
21:41
Und wir haben aber immer noch das Problem, dass wir eben diese zeitliche Diskrepanz zwischen Bilddaten, Höhendaten und Alkesdaten haben. Und dafür haben wir uns dann ein kleines Tool gebaut, das sogenannte Verification Tool. Im Moment läuft es bei mir nur lokal, aber das lief bei uns im Cluster als kleine Web App.
22:03
Und das hier ist ein Jupyter Notebook. Das sieht jetzt nicht so ganz aus wie ein Jupyter Notebook, wie man es eigentlich kennt. Aber das Ganze wird hier gerendert von einem Programm namens Voila. Das heißt, ich habe ein Jupyter Notebook. In dem habe ich per iPad Widgets einfach ein paar Felder, hier eben um Daten auszuwählen.
22:27
Und ein paar kleine Buttons. Und ein Matplotlib Widgets, wo eben die Daten hier geplottet werden. Und hier werden jetzt aus der Cloud direkt für die Daten, die wir generiert haben,
22:43
diese Sliding Windows angezeigt. Und wir sehen die dazugehörigen Bounding Box Koordinaten. Man kann hier dann auch noch so ein bisschen rumspielen mit irgendwie Color Maps und kann das NDSM so ein bisschen skalieren. Und hier war jetzt die Aufgabe, einfach diese kleinen Fenster durchzuschauen
23:03
und zu gucken, ob Bilddaten, Höhendaten und diese Labels zusammenpassen. Und wenn das der Fall ist, dann hat man hier das Ganze eben mit grün bestätigt. Und das wurde dann bei uns in die Datenbank geschrieben. Und da, mit diesem Prozess, haben wir einige Tausend von diesen Sliding Windows geprüft
23:26
und haben uns einen Trainingsdatensatz erschaffen, wo wir wussten, welche von diesen Fenstern wir verwenden können. Und im Laufe der Zeit haben wir dann auch noch die TrueDops bekommen.
23:43
Und die haben wir dann auch hiermit verwendet. Hier sieht man auch nochmal, das ist jetzt das TrueDop in Kombination mit dem ALS NDSM.
24:00
Und man sieht halt hier oben fehlt eben in dem Leiter NDSM eben das Haus. Das heißt, auch in Kombination mit den TrueDops war es nötig, diese Daten zu prüfen. So, was hat das Ganze gebracht? Das sehen wir jetzt hier.
24:20
Also, die Modelle sind deutlich besser geworden durch die Verwendung der geprüften Trainingsdaten. Wir haben dann zusätzlich noch viel geändert. Die ganze Architektur haben wir eigentlich nochmal komplett über den Haufen geworfen und deutlich vereinfacht. Wir haben den Trainings- und Inferencing-Code angepasst.
24:41
Beim Trainings-Code vor allem das so umgebaut, dass wir es eben auch auf anderen Clouds als der von unserem Projektpartner benutzen können. Deswegen seitdem trainieren wir auf Code.de bzw. EOLab. Und wir hatten das dann nach ca. einem Jahr, also so im Sommer 2022, war das Ganze dann soweit produktiv einsatzbar,
25:03
dass wir für ganz Niedersachsen Ergebnisse generieren konnten. Die Ergebnisse hier sehen etwas besser aus, als sie eigentlich sind. Die sind durch Simplifizierung der Linien halt etwas verschönert worden. Die eigentlichen Ergebnisse sehen halt so frisselig aus, wie man es halt kennt von Segmentierungen.
25:23
Insgesamt war dieses ganze zweistufige Verfahren aber ein sehr komplexer Prozess, weil wir eben diese zwei unterschiedlichen KI-Modelle hatten, liefen auch in unterschiedlichen TensorFlow-Versionen. Das heißt auch im Inferencing musste dieser Prozess halt immer zweistufig ablaufen. Erst die Objekterkennung, da musste man sich irgendwelche ID's merken, die dann später weitergeben an die Segmentierung
25:43
und dann am Ende eben die gefundenen Objekte segmentieren. Ja, dann kam das Framefield-Learning daher bzw. wir hatten das Paper schon länger irgendwie im Blick.
26:00
Wir hatten das schon mal gesehen. So im November 2022 haben wir das zum ersten Mal ausprobiert mit eigenen Daten. Und das sah sehr vielversprechend aus, aber erst im Dezember 2022 hat sich die Lizenz hier durch Magic, oder wir haben auch einmal eine E-Mail hingeschrieben und irgendwie hat sich dann plötzlich die Lizenz geändert
26:24
und dann konnten wir es halt verwenden. Ich will jetzt hier auch nicht auf das Verfahren eingehen. Die Autoren haben hier in dem Repo ein YouTube-Video verlinkt, wo sie das genau erklären. Aber es ist eben eine Segmentierung und wir kriegen aber am Ende Polygone raus und nicht nur eine Segmentierungsmaske.
26:43
Ja, und wie ich eben schon gesagt habe, das Modell, was die Autoren bereitstellen, also das Beste von den Modellen, die sie trainiert hatten, das haben wir dann auch auf unsere Daten angewendet. Man sieht, dass die Ergebnisse auch schon sehr vielversprechend aussahen.
27:07
Allerdings hat das immer noch mehr Fehler generiert als unsere Generation 2, weil hier eben nur die RGB-Daten verwendet wurden und die Höhendaten doch irgendwie sehr hilfreich sind, wenn man Gebäude erkennen möchte.
27:22
Wir haben dann uns Ziele gesetzt, wie wir das umbauen und unter anderem, dass wir halt 5-Kanal-Daten dort reinkriegen, also Höhendaten auch und eigene Trainingsdaten nutzen können. Generation 4 war dann nach ca. zwei Monaten Arbeit, haben wir das Ganze halt umgebaut,
27:48
sodass 5-Kanal-Daten reingesteckt werden konnten und wir das mit eigenen Daten trainieren konnten. Und da haben wir als erstes diese geprüften Sliding Windows, die wir eben vorher gesehen haben, reingesteckt.
28:02
Und das hat funktioniert, wir haben uns gefreut, man konnte trainieren, es hat ein Modell ergeben, wir konnten das Modell dann auch anwenden, Influencing und damit schöne Ergebnisse erzeugen, die wir jetzt hier zum Beispiel sehen. Aber es hat leider doch noch ziemlich viele Fehler produziert und wir hatten jetzt das Problem,
28:23
dass wir eben in diesen Trainingsdaten, in diesen Sliding Windows einfach noch viele Fehler drin hatten, weil da zum Beispiel, wenn da eine Verdeckung ist durch Vegetation, wenn da ein Baum ist und da steht irgendein Gebäude drunter, dann ist das ja nicht falsch, aber wir sehen es eben von oben nicht. Und solche Sachen wurden halt nicht editiert, weil wir es nur visuell geprüft hatten.
28:46
Und weil wir halt eben keine echte Referenz hatten, hatten wir auch keine Möglichkeit, diese Fehler zu quantifizieren oder quantisieren. Und wir hatten bis dato auch noch keine vernünftigen Evaluationsmethoden, also da haben gestern die beiden Kollegen ja auch gezeigt, wie wir das jetzt machen, da haben wir ja auch eigene Tools für mittlerweile.
29:06
Genau, und dann haben wir eben gesagt, wir müssen doch noch mal ran und Trainingsdaten generieren und haben uns dann überlegt, was sind so die Anforderungen für so einen Label-Workflow oder was für Trainingsdaten wollen wir generieren und wie.
29:24
Alke sollte hier natürlich wieder die Grundlage sein. Und wir wollten dann aber das TrueDop in Kombination mit dem Bedom-NDSM verwenden, auch wenn die Höhenqualität teilweise etwas schlechter war als das ALS-NDSM. Aber man hat halt den Vorteil, dass Bilddaten und Höhendaten einfach zusammen passen, weil es aus dem gleichen Datensatz kommt.
29:48
Wir wollten den manuellen Bearbeitungsaufwand gering halten, deswegen eine schlaue Vorauswahl treffen. Und editiert werden sollten Labels eben nur bei Inkonsistenzen.
30:00
Dann war die Frage, was für eine Kachelgröße macht man, labeln wir ganze Bilder aus und da haben wir uns dagegen entschieden und haben gesagt, wir machen lieber viele kleine Kacheln, die dann weit verteilt sind über Niedersachsen und möglichst viel von der Variabilität abdecken, die wir halt dem KI-Modell antrainieren wollen. Wir haben dann für eine Kachelgröße von 2000x2000 Pixel eben vorgesehen
30:25
und diese Kacheln nennen wir dann Ground-Truth-Kacheln oder Ground-Truth-Patches. Oder manchmal sagen wir auch Teils dazu, also bitte nicht verwirrt sein. Aber da komme ich gleich nochmal zu.
30:40
Dann war die Frage, macht man das in einer Web-App oder in einer spezialisierten Desktop-Software? Und hier ist die Wahl auf QGIS gefallen, weil das alles mitbringt, was wir brauchen, um Daten zu labeln oder Polygone zu bearbeiten. Dann sollte ja Multi-User-Fähigkeit irgendwie auch ein bisschen möglich sein,
31:00
dass wir zumindest teamintern mit mehreren Leuten daran arbeiten können. Aber es hat sich dann im Laufe der Zeit auch ergeben, dass wir Unterstützung bekommen können von Kolleginnen aus anderen Abteilungen bei uns im Amt. Und deswegen musste das Ganze dann auch noch auf Amtsrechnern lauffähig sein und sollte auch in einer einigermaßen sicheren Architektur laufen.
31:24
Ja, und jetzt komme ich zum eigentlichen Demo-Teil. Und hoffe, das Internet funktioniert. Das hatten wir eben. Gut, was sehen wir hier? Ja, wieder ein Jupyter Notebook.
31:42
Aber diesmal sieht es auch wirklich aus wie ein Jupyter Notebook. Also hier oben ist auch ein bisschen Sourcecode. Wir sehen eine Kachelung. Das sind eben die TrueDop-Kacheln, die wir verfügbar haben. In rot sehen wir nochmal die Kacheln, die für die Generation 2 als Trainingsgebiete verwendet wurden.
32:05
Und diese kleinen grünen Flecken hier, das sind eben unsere Ground Truth-Kacheln, die wir bearbeitet haben. Und dieses kleine Tool kann man jetzt einsetzen. Man kann jetzt irgendwo in diese Bilder klicken. Und dort, wo ich geklickt habe, wird dann eben ein Fenster aufgebaut.
32:23
Man kann hier theoretisch die Fenstergröße auch ändern. Aber wir bleiben mal bei unserer Standardfenstergröße. Und dann klick ich hier einen Knopf und es passiert nichts, weil wir haben keine Alkesdaten. Ich bin halt auch schon in Hamburg, aber kein Problem.
32:41
Etwas weiter südlich geht das Ganze. Und jetzt werden die Alkesdaten aus der Datenbank geladen. Und das Bild wird aus dem Cross direkt hier reingestreamt. Und ja, ich betrachte das eben jetzt und überlege mir, möchte ich diese Kachel hier in unseren Kachelpool aufnehmen oder nicht? Und hier ist eben das Ziel, dass die Änderungen zwischen Bild und Alkes möglichst gering sind.
33:05
Und ich muss mir natürlich überlegen, ist das, was dort abgebildet ist, möchte ich das in den Trainingsdaten haben? Also wenn ich zum Beispiel merke, unsere KI detektiert bestimmte Bauernhöfe irgendwie schlecht, dann würde ich halt solche vielleicht nochmal in den Pool mit aufnehmen.
33:24
Diese Kachel gefällt mir jetzt nicht so gut, deswegen gehe ich hier nochmal rüber. Hier ist ein ganz schönes Gebiet. Genau, und das sieht mir jetzt so okay aus.
33:41
Und das speichere ich jetzt in die Datenbank. Und man sieht jetzt, ist hier ein grünes Kästchen entstanden. Also das wurde jetzt in die Datenbank geschrieben. Und wir sehen auch gleich, dass es verfügbar ist. Also das ist jetzt dieser Vorauswahl-Part und das haben wir teamintern verwendet, um eben diesen Kachelpool zu befüllen.
34:04
Und jetzt ist die Frage, wie soll das Labeling ablaufen? Da soll eben QGIS verwendet werden. Jetzt bin ich hier in meiner QGIS-Oberfläche und ich sehe nochmal diese Kacheln.
34:20
Manche davon sind grün, also die meisten sind grün. Das steht jetzt hier für, die wurden schon bearbeitet. Aber hier sehen wir eine kleine blaue, die ist noch nicht bearbeitet. Hier ist ein Status unbearbeitet. Und jetzt ist die Frage, wie bekomme ich diese Daten dafür, also die Bilddaten und Algesdaten hier in meinen QGIS rein,
34:43
ohne dass ich Zugriff habe auf die Datenbank? Und da kommt ein kleiner Microservice zum Einsatz. Der Dal Loy. Der Name ist ein kleiner Insider, weil wir von unserem Projektpartner auch eine Komponente damals hatten in der alten Architektur, die so hieß.
35:02
Also ohne das Loy. Und die war eben für Datenbankzugriffe zuständig. Ja, hier gibt es dann verschiedene Endpunkte. Und wichtig ist jetzt, man kann hier auch in dieser Swagger-UI ausprobieren, wie man das eben kennt. Und hier ist halt ein Endpunkt Teil Selection. Mit dem kann ich mir jetzt aus diesem Pool, wenn ich das aufrufe, bekomme ich eben diese Meta-Information, die wir eben gesehen haben, zurück.
35:30
Und zwar wird, wenn ich keine Parameter übergebe, random aus dem Pool der unbearbeiteten Bilder etwas gezogen. Ich habe jetzt hier auch einen Parameter gesetzt, dass der Status nicht gesetzt wird.
35:43
Normalerweise wird der Status gesetzt. So, ich kann mir jetzt hier nochmal eben diese Kachel notieren. Kopiere ich mir das mal. Dann haben wir nämlich noch einen zweiten Endpunkt, der wichtig ist für das, was wir gleich sehen. Nämlich, man kann hier den Kachelnamen übergeben.
36:02
Und wenn ich das jetzt ausführe, dann dauert es ein wenig länger. Geht. Okay, was bekommen wir hier zurück? Eine Datei, und zwar eine ZIP-Datei. Und wie kriegen wir das jetzt in Qgis? Ja, durch Python, durch ein paar kleine Skripte.
36:24
Und das schreit eigentlich förmlich nach einem Plugin. Aber ja, dazu ist es leider nicht gekommen, aus Zeitgründen. Und wenn so ein Provisorium einmal in der Welt ist, dann bleibt es halt irgendwie dabei.
36:43
Aber es ist ein One-Click-Plugin, und es gibt noch ein anderes One-Click-Plugin. Und wenn wir das ausführen, wird eben genau das gemacht, was ich eben demonstriert habe in der API. Es wird eine Kachel random ausgewählt. Und diese ZIP-Datei wird entgegengenommen. Sie wird bei mir lokal exportiert.
37:04
Und diese enthält die Bilddaten, und zwar den Ausschnitt, der auch vom COS direkt ausgeschnitten wurde. Und zusätzlich das NDSM und die ALKES-Daten. Und das Ganze wird hier gleich auf editieren gesetzt, sodass ich sofort loslegen kann mit der Arbeit.
37:21
Wir wollen jetzt aber noch mal die Kachel, die ich eben hier ausgewählt habe, die möchte ich jetzt gerne bearbeiten. Deswegen mache ich hier einen kleinen Hack. Das dürfen natürlich andere Leute nicht machen.
37:41
Aber ich möchte diese Kachel jetzt gerne bearbeiten, deswegen füge ich das hier einmal ein. Und wenn ich das ausführe, bekomme ich die Kachel, die wir eben gesehen haben. Und jetzt kann ich diese eben editieren. Und dafür kann ich halt alles nutzen, was QGIS hergibt.
38:02
Ich kann hier auch zum Beispiel Punktfang nutzen. Also wenn ich jetzt hier irgendwie was dran digitalisieren möchte, dann kann ich das machen. Ja, dieses Objekt hat mir jetzt nicht gefallen. Das will ich wieder wegmachen. Aber hier sehen wir zum Beispiel etwas, das wollen wir natürlich entfernen.
38:26
Und ja, das hier passt vielleicht auch nicht so gut. Ich will jetzt hier nicht zu pinglich sein. Ist ja auch schon kurz vor Mittag. Deswegen beende ich das Ganze jetzt hier mal.
38:42
Und füge jetzt ein zweites Skript aus. Und das Ganze nimmt jetzt dieses Geo-Package, was da im Hintergrund verwendet wird, und gibt mir eine Fehlermeldung. Weil leider QGIS eine Log-Datei auf das Geo-Package hat. Und der Server merkt dann halt, da stimmt irgendwas nicht.
39:05
Die Wahl für Geo-Package war an der Stelle irgendwie blöd. Das würden wir dann in Zukunft anders machen. Oder vielleicht gibt es auch Expertinnen hier, die mir sagen können, wie man eben diesen Log entfernt. Aber wenn man das Skript jetzt noch ein zweites Mal ausführt, dann passt das Ganze.
39:27
Und die Kachel ist jetzt auf grün gewechselt. Und wir haben die jetzt in unserem Kachelpool drin. Und ja, das war jetzt der Label-Workflow. Und so habe ich sehr schnell von Alkes-Daten, die ich mir angeguckt habe, kurz
39:41
etwas editiert habe, hin zu Daten, die wir jetzt als Ground-Truth-Daten benutzen können. Gut, dann machen wir hier noch mal eben weiter.
40:00
Genau, das haben wir eben gesehen. Ja, hier ist noch mal eben kurz der Ablauf. Das war eben die Vorauswahl, also es wird das Bild geladen. Das wird übrigens hier mit dem T-Tiler als Mini-WMS reingestreamt in diese Jupter-Oberfläche. Und der Datenbankzugriff erfolgt hier über Postgres. Und abgespeichert werden eben nur die Metadaten zum Bild, also die URL zum Bild hier.
40:26
Und ja, im Label-Workflow haben wir eben aus diesem Kachelpool eine Kachel ausgewählt mit den Metadaten. Die URL davon war dann eben bekannt. Dann wurden die NDSM und DOB-Daten geladen. Das Ganze über diese kleine Fast-API und in QGIS dargestellt und
40:45
danach wieder zurückgeschrieben in die Label-Datenbank oder in die Ground-Truth-Datenbank. Da haben wir dann eine Extra-Tabelle für. Gut, ja, das wäre jetzt eben unsere Generation 5.
41:03
Auf der Zeitleiste von Jonas hat man das irgendwie auch zweimal gesehen. Also Generation 5 heißt halt einfach mit den neuen Daten trainiert. Das haben wir erstmals im September gemacht, aber da noch mit einem kleineren Datensatz. Und das hier ist jetzt eigentlich Generation 5.2 und dazwischen gab es auch noch x andere Versionen.
41:23
Aber trotzdem sage ich jetzt hier Generation 5 dazu. Und ja, mit diesem Label-Workflow haben wir mit einer kleinen Crowd von Teammitgliedern und Kolleginnen aus der Linie. Und ich glaube, Studenten hatten wir auch noch zwei, haben wir eben mehr als 1000 von diesen Kacheln hier gelabelt.
41:46
Und aus diesem Pool von 1000 Kacheln können wir jetzt Trainingsdaten generieren, indem wir halt einfach random sagen, okay, wir wollen 80 Prozent dafür fürs Training einsetzen und 20 Prozent, also dann circa 200, lassen wir für die Evaluierung übrig.
42:05
Und das ist dann auch der Datensatz, den die Kollegen gestern vorgestellt haben. Die 193 Kacheln, die dann für die unabhängige Bewertung verwendet wurden. Und dadurch ist es halt auch möglich, dass wir die nachträglich ältere Modelle halt evaluieren.
42:25
Zumindest die, die wir noch verfügbar haben. Und das ist eben Generation 2, Generation 1 gibt es nicht mehr. Ja, Generation 5 ist auf jeden Fall das beste Modell bisher. Wir haben noch viele Änderungen und kleine Fehler, Änderungen gemacht und kleine Fehler entfernt.
42:44
Und man muss natürlich sagen, die Ground Truth ist nicht fehlerfrei. Mittlerweile ist die KI eigentlich besser als die Ground Truth, muss man sagen, vor allem bei kleinen Objekten, weil die kleinen Objekte in Alkes nicht erfasst sind und auch die Leute, die gelabelt haben, jetzt nicht jeden kleinen Schuppen dann erfasst haben.
43:00
Man kann das iterativ noch so ein bisschen nachbessern, indem man die einzelnen Kacheln nochmal evaluiert. Und dadurch halt eben Kacheln entfernt, wo dann doch noch grobe Fehler drin sind. Abschließend lässt sich sagen, die Verbesserung von KI-Modellen geht eben über eine Verbesserung der Trainingsdaten.
43:28
Also auch ein neues Modell oder eine neue Version von einem Verfahren, das man einsetzt, wird einem nicht ein besseres KI-Modell liefern, wenn die Trainingsdaten zu schlecht sind.
43:41
Das Aufbereiten von solchen Trainingsdaten ist sehr aufwendig, das sollte man nicht unterschätzen. Das Training an sich ist nur die Spitze des Eisbergs, die Aufbereitung ist halt alles, was darunter kommt. Um den Labelaufwand gering zu halten, denn Labeln macht keinen Spaß, das wissen wir alle,
44:02
sollte man vorhandenes nutzen und da kann man eben Alkes verwenden. Man könnte den Workflow, den ich eben gezeigt habe, aber auch zum Beispiel mit OSM-Daten durchführen. Wenn man Daten aus verschiedenen Quellen verwendet, dann kann es natürlich sein oder dann ist es auch sehr wahrscheinlich, dass es da Inkonsistenzen gibt und die sollte man versuchen irgendwie zu entfernen.
44:20
Man sollte zumindest eine visuelle Prüfung durchführen und schlechte Beispiele dann eventuell aussortieren. Weil alles, was an Fehlern in den Daten ist, lernt die KI halt auch mit und das sieht man dann auch in den Ergebnissen. Eine Ground Truth erfordert manuelles Editieren. Ja, noch schöner wäre natürlich, wenn man ja wirklich echte Daten hätte,
44:43
wo man vor Ort jede Kachel irgendwie einmal hinfährt und sich anschaut, wie sieht denn das eigentlich aus. Aber als Ground Truth kann man das eben auch schon bezeichnen, wenn man solche Daten manuell editiert hat. Und dabei kann Crowdsourcing helfen, aber das Ganze muss halt organisiert werden.
45:02
Fosstools sind da natürlich der Motor für alles und Jupyter Notebooks verwenden wir eben hier für Prototypen, aber auch für allgemeine Prozessierung, Vorprozessierung, Nachprozessierung, dies das. Wenn man ja ein bisschen Interaktivität möchte und wie ich jetzt keinen JavaScript kann,
45:23
dann kann man den Notebooks auch noch etwas Interaktivität hinzufügen durch iPad Widgets oder iPad Leaflet, wie wir eben gesehen haben und man kann das Ganze sogar mit Voila als eigene Web App rendern. Für komplexere Labelaufgaben würde ich dann aber eher QGIS vorziehen und da kann man eben Microservices verwenden, um Daten in die Oberfläche reinzubekommen.
45:45
Und damit bin ich durch und ja, danke für das Interesse und ich bin offen für Fragen. Vielen Dank für den interessanten Vortrag. Dann fangen wir mit den Fragen an.
46:02
Habt ihr getestet, ab wie viel Prozent Fehler im Trainingsdatensatz das Modell anfängt deutlich schlechter zu performen? Nein. Stehen die erfassten Daten öffentlich zur Verfügung, um zum Beispiel OSM zu verbessern? Welchen Einsatzzweck hat die Erfassung von Gebäudedaten für die Behörden?
46:24
Darf ich darauf antworten? Genau. Also hinter dem QR-Code gibt es einen Link, da sind für die Stadt Oldenburg alle 78.000 Gebäude, haben wir da glaube ich gefunden, die sind mit Creative Commons Zero Lizenz stehen die zur Verfügung. Da würde ich mich freuen oder wir würden uns freuen, wenn sich das mal die OSM Community anguckt,
46:42
ob die damit arbeiten können. Also von der Lizenz haben wir gerade den Vortrag gehört dazu. Also da ist Creative Commons Zero ja dann gar kein Problem mehr. Da könnt ihr mitmachen, was ihr wollt, ist auch mit OSM kompatibel. Ansonsten ja, ich habe die Fragen schon mitverfolgt, deswegen kann ich vielleicht auch nochmal allgemein dazu antworten, ob wir die Trainingsdaten, das Modell oder die Ergebnisse zur Verfügung stellen.
47:05
Also erste Priorität hat bei uns erstmal die Digitalisierung der Vorgänge bei uns in unserem Landesamt. Wir wollen erstmal die Alkesdaten verbessern und das hat erstmal Priorität, da fokussieren wir uns drauf. Wir werden dann wahrscheinlich, das ist zumindest auch unser Ziel, zuerst dann die Ergebnisse auch
47:24
unter Open Data Lizenz kompatibel für OSM nutzbar veröffentlichen. Dann denke ich auch irgendwann mal die Modelle, Trainingsdaten, Source Code, das ist schon unser Plan zur Zeit ist da einfach unser Fokus nicht drauf. Wir sind halt eine Behörde für Geodaten und Landesvermessung oder Geoinformation und Landesvermessung.
47:43
Wir sind keine Softwareentwickler, das muss man auch sagen. Das ist nicht unsere Aufgabe Software zu entwickeln und das haben wir auch gerade erst in den letzten Jahren gelernt, das einigermaßen professionell anzugehen. Deswegen werden da wahrscheinlich zuerst die Geodaten öffentlich verfügbar werden
48:04
und dann nach und nach die Softwarekomponenten unter Open Source Lizenz. Möchtest du noch was ergänzen zu dem Thema? Ja, also ich sag mal, der Code ist schon eine extreme Maßanfertigung auf unsere Infrastruktur.
48:23
Also wir nutzen halt, das haben wir eben auch in der Vorverarbeitung gesehen, halt viele Komponenten und darauf ist eben auch der Trainings Code zum Beispiel angepasst. Also ich weiß nicht, ob der Öffentlichkeit so viel helfen würde, wenn wir den jetzt einfach veröffentlichen. Und das Repo ist hier an sich auch Open Source, nur halt unsere Änderungen sind da noch nicht drin.
48:41
Aber ja, da kann man in Zukunft drüber nachdenken, nur das Ding ist mit Open Source natürlich auch, es ist ja nicht nur den Code irgendwo hin dumpen, sondern man muss das Ganze ja dann irgendwie auch maintainen und da weiß ich nicht, ob wir da die Kapazitäten für haben, weil natürlich auch in Zukunft neue Projekte kommen. Wir wollen ja alles mit KI machen heutzutage.
49:01
Habt ihr die Ergebnis-Polygonen auch in Generation 3 vereinfacht für die Visualisierungen? Nein, Generation 3 ist quasi das Modell, was die Autoren von diesem Paper auch auf ihrer GitHub-Seite veröffentlichen. Und wie gesagt, man hat ja gesehen, das erzeugt schon sehr gute Ergebnisse,
49:23
aber es hat halt hier und da mal Probleme, dass mal ein Stück Straße oder so was oder eine Einfahrt oder so was mit erfasst ist, wo dann halt die Höhendaten helfen können. Aber die Höhendaten muss man natürlich auch erstmal vorverarbeiten und die muss man dann natürlich auch genauso vorverarbeiten, wie wir es halt machen.
49:43
Ansonsten hilft es einem dann auch nicht beim Influencing. Sind Dachüberstände ein Problem, weil sie Mauern überragen? Ja, Dachüberstände sind generell ein Problem. Das haben wir jetzt aber in den Daten nicht korrigiert. Also in dieser Ground Truth ist es nicht korrigiert. Die Arbeit wollten wir uns nicht machen.
50:01
Und das Netz lernt das irgendwie so ein bisschen mit. Also manchmal hat man Ergebnisse, die irgendwie ein bisschen nach innen versetzt sind. Aber das ist natürlich dann nur, wie sagt man, Glaskugel lesen, weil die KI kann natürlich von oben nur das Dach sehen. Also als Mensch können wir es ja auch nicht sehen, ob da jetzt ein Dachüberstand ist oder nicht. Aber irgendwie bei bestimmten Dachtypen sind die Polygone mal ein bisschen nach innen versetzt.
50:23
Also ein bisschen was scheint die KI dann da gelernt zu haben. Aber ob es richtig ist oder nicht, das weiß man halt an der Stelle nicht. Und wir wissen es auch über die Referenz nicht. Es ist aber auch für unsere Anwendung. Wir wollen ja eben nur Änderungen in ALKES erkennen. Dafür ist es eben nicht notwendig.
50:41
Wann wird es soweit sein, dass eure Daten die amtlich vermessenen ALKES-Daten ersetzen? Nee, ersetzen denke ich nicht, aber ergänzen. Also es gibt vielleicht Anwendungen, wo es ganz stark auf Aktualität drauf ankommt. Da will man möglichst schnell wissen, wo sind überall Gebäude. Ich denke jetzt an den Ausbau erneuerbarer Energien. Da gibt es immer Abstandsregelungen zu oder sowas.
51:01
Da geht es dann bestimmt um Aktualität. Da wird man dann vielleicht eher mal unsere Ergebnisse einsetzen. Aber wenn es dann um eine ganz genaue präzise Vermessung geht, dann muss man eben doch noch mal hinfahren. Und dann müssen da Vermessungsingenieure nachmessen. Das denke ich wird immer so fit for purpose. Also je nachdem, was man gerade braucht. Entweder braucht man eine genaue Vor-Ort-Vermessung terrestrisch, lokal mit einem Messtrupp.
51:22
Oder man braucht ganz hohe Aktualität durch KI. So wird sich das, denke ich, ergänzen, die beiden Datensätze in Zukunft. Übertragen Infirens eure Modelle auf andere Bundesländer oder Länder? Ja, das ist eine sehr schöne Frage. Da nochmal der Aufruf an alle Bundesländer und Städte und Kommunen,
51:42
wer auch immer, die KI nutzen will, gerne mal bei uns melden. Wir sind da sehr interessiert dran. Wir haben das alles so gebaut, dass es überall einsetzbar ist. Wir haben das auch schon mit einigen Städten und Ländern getestet. Das funktioniert auch auf anderen Daten sehr gut. Also die Übertragbarkeit des Modells ist sehr gut. Liegt vielleicht auch daran, weil wir in Niedersachsen selber ja schon eine starke Inhumogenität der Daten eigentlich haben.
52:05
Weil auch das Bildflugprogramm geht auch über Monate. Da sind unterschiedliche Firmen, unterschiedliche Kameras im Einsatz. Also deswegen hat die KI schon eigentlich eine Menge an unterschiedlichen Daten gesehen. Ja, deswegen funktioniert das ganz gut. Wir müssen auch noch ein bisschen mit der Skalierung dran arbeiten,
52:24
dass das Ganze schön in der Cloud auf vielen GPUs gleichzeitig läuft. Da brauchen wir auch noch ein bisschen Unterstützung. Da suchen wir gerade noch einen Softwarearchitekten, der Spaß dran hat, richtig viele GPUs gleichzeitig in der Cloud zum Glühen zu bringen.
52:41
Und da unsere KI laufen zu lassen. Genau, die Stellenausschreibung ist hinter dem QR-Code, falls ihr mal Interesse habt. Muss ich einfach noch mal sagen. Ich möchte dazu noch mal ganz kurz was sagen. Ein großes Hindernis dabei ist halt die Datenverfügbarkeit. Wie kann man auf die Daten zugreifen? In anderen Bundesländern haben wir halt oft Datenportale,
53:01
wo man sich erstmal durchklicken muss. Und dann wird irgendwie nach drei Stunden ein Download-Link generiert, den man per E-Mail bekommt oder sowas in der Art. Wir haben jetzt unsere Daten hier alle in der Cloud. Die BDOM-Daten sind zwar noch nicht öffentlich, aber wenn sie öffentlich sind, dann können wir halt über die auch zum Beispiel über einen Stack direkt darauf zugreifen.
53:22
Und wenn andere Bundesländer das auch so hätten, dass man direkt auf die Daten zugreifen kann, dann könnten wir sofort jedes Bundesland influenzen. Also in Niedersachsen ist ja recht groß. Mit einer GPU, wo man drei Prozesse gleichzeitig laufen lässt, können wir etwas mehr als eine Woche einmal in Niedersachsen durchjagen.
53:45
Also das ist schon möglich, wenn wir größere Ressourcen hätten oder noch mehr parallelisieren und auf CPU das Ganze laufen lassen, dann dauert es eben länger. Aber wir haben die Daten direkt in der Cloud und müssen nicht uns irgendwelche Daten noch vorher runterladen
54:00
oder in irgendwelche Buckets hochladen. Wir haben alle verfügbar. Wir können auf jedes Bild in Niedersachsen einfach per URL zugreifen. Und das ist halt ein super Vorteil. Und das wäre schön, wenn andere Bundesländer das auch so hätten irgendwann mal. Und eine Nachfrage wieder zur Open Source. Ist euer Verification-Tool open source? Wenn ja, unter welcher Lizenz und wo kann man es runterladen?
54:23
Nee, es ist leider nicht open source. Wer hat die Trainingsdaten geprüft? Ihr selbst oder ein Dienstleister? Wir selbst, also durch, ja, eben jeder von diesen Kacheln
54:41
wurde durch einen menschlichen Bearbeiter bearbeitet oder Bearbeiterin. Ja, es ist jetzt kein Vier-Augen-Prinzip. Also in den Daten sind auch Fehler. Wir wissen auch, dass da Fehler drin sind. Aber wir können eben durch Evaluierung von diesen Kacheln ja, eben grobe Fehler nochmal versuchen zu finden
55:02
und können diese Kacheln dann einfach aussortieren. Und das haben wir halt auch schon gemacht. Und die Methoden dafür haben die Kollegen ja gestern gezeigt. Wäre spannend. Ist vielleicht für dieses Projekt hier nicht so relevant.
55:25
Aber das könnte man auf jeden Fall im Hinterkopf behalten. Ja, beziehungsweise eigentlich, man braucht ja nicht eine bessere Ground Truth als das, was man in den Bildern sieht. Weil da hat die KI sowieso keine Chance, das zu erkennen, was man nicht von oben sieht. Also Ground Truth ist einfach nur das,
55:40
was will man als Ergebnis eigentlich haben am Ende. Was empfindet man als Mensch, als richtig? Und was braucht man für die Anwendung? Und da hilft es einem eigentlich nichts, wenn man sieht, dass da ein ganz großer Dachüberstand ist. Weil die Wahrheit, die Ground Truth, ist halt das, was man von oben sieht. Und nicht das, was man von der Straße aussieht. Das ist immer so ein bisschen ein Missverständnis.
56:01
Also würde auch, glaube ich, nicht helfen, wenn man wirklich vor Ort hinfährt und das Mauerwerk noch mal ganz genau einmisst. Weil das ist eben nicht die Ground Truth dann. Ja, damit sind wir dann über die Zeit schon drüber. Vielen Dank fürs Kommen, für die Fragen und für den Vortrag.
Empfehlungen
Serie mit 79 Medien