Automatisierte Solarbelegung mit Geospatial AI

Wie viel Solarpotenzial hat ein Dach? Die Frage klingt einfach, ist technisch aber komplex. Ein Dach besteht aus Neigungen, Ausrichtungen, Kanten, Gauben, Dachfenstern, Kaminen und bestehenden Anlagen. Dazu kommen Sicherheitsabstände und konstruktive Einschränkungen. Für eine finale Planung müssen all diese Faktoren berücksichtigt werden. Für frühe Vertriebs-, Machbarkeits-, und Screening-Prozesse kann zunächst eine vorgelagerte Frage zählen: Lässt sich aus schon vorhandenen Daten schnell und unkompliziert eine belastbare, visuell nachvollziehbare Vorplanung erzeugen?

Für diese Frage entwickelten wir einen webbasierten Prototyp: ein Tool, das aus einer Adresse automatisch Gebäudedaten lädt, Dachflächen analysiert, Hindernisse erkennt und PV-Module direkt im 3D-Modell platziert. Der folgende Beitrag beschreibt die algorithmischen Bausteine dahinter.

Der sichtbare Ablauf im Prototyp ist unkompliziert: Adresse eingeben, Gebäude laden, Dachflächen segmentieren, 3D-Modell ausrichten, PV-Module platzieren, Ergebnis direkt im Browser prüfen. Dahinter liegt eine mehrstufige Pipeline aus Geodaten, Luftbildern, Höheninformationen, Alignment-Logik und PV-Regeln. Jede dieser Ebenen liefert für sich genommen ein unvollständiges Bild. Der Kern des Prototypen liegt in ihrer Fusion zu einem konsistenten, planbaren Gebäudemodell.

Als geometrische Baseline nutzen wir 3D-Gebäudedaten (swissBUILDINGS3D). Sie liefern Dachflächen, Neigungen und räumliche Orientierung – allerdings als rein geometrische Objekte, ohne Texturen. Für ein fotorealistisches Ergebnis, in dem Nutzer:innen ihr eigenes Dach wiedererkennen, reichern wir diese Geometrie mit hochauflösenden Texturen aus swissIMAGE an. Die präzise Ausrichtung dieser Texturen auf das 3D-Modell ist dabei eine eigene technische Herausforderung, auf die wir weiter unten eingehen. Ergänzt wird das Modell um ein LiDAR-Oberflächenmodell[1] (swissSURFACE3D) für höhenbasierte Analysen sowie amtliche Solar-Eignungungsdaten (BFE Sonnendach).

Die Eignungsdaten klassifizieren jede Dachfläche in fünf Stufen. Für die automatische Belegung berücksichtigen wir nur Flächen ab Eignungsklasse 3 – geometrisch verfügbare, aber energetisch wenig sinnvolle Flächen bleiben so außen vor. Ein zusätzlicher Ausrichtungsfilter schließt Dachflächen aus, deren Orientierung für den gewünschten PV-Ertrag ungünstig ist. Belastbare Vorplanung entsteht damit erst, wenn Geometrie, Bildinformation und Solarpotenzial gemeinsam in ein Modell fließen – eine einzelne Datenquelle reicht nicht aus.

Ein unterschätzter Teil solcher Systeme ist die Dateninfrastruktur selbst. Die Pipeline verarbeitet unterschiedliche Datenformate und Geodatenrepräsentationen, sowohl textbasiert als auch binär, und überführt sie in eine einheitliche interne Struktur. Eine Ausnahme sind Gebäude an Landesgrenzen: Ihre Geometrie liegt teilweise in mehreren Datensegmenten vor. Solche Objekte erkennt die Pipeline automatisch und teilt sie korrekt auf, bevor sie weiterverarbeitet werden.

Details wie dieser entscheiden darüber, ob ein Prototyp nur mit idealen Beispielgebäuden funktioniert oder auch mit den Randfällen einer echten Geodatenlandschaft umgehen kann. 

Für eine PV-Planung reicht die Unterscheidung zwischen Dach und Nicht-Dach nicht aus. Relevant sind semantische Klassen: belegbare Dachfläche, Dachfenster, Kamin, Gaube, bestehendes PV-Modul, technischer Aufbau, nicht belegbarer Bereich, unsichere Zone.

Die Erkennung dieser Klassen stützt sich auf drei Verfahren mit unterschiedlicher Funktionsweise. Ein Segmentierungs-Foundation-Model (SAM3)[2] übernimmt den größten Teil der Arbeit – als Box-Prompt[3] für die Dachfläche, deren ungefähre Lage aus der 3D-Geometrie bereits bekannt ist, und als Text-Prompt für benannte Objektklassen, wie Kamine, Dachfenster oder bestehende Solaranlagen. Für Objekte ohne eindeutige sprachliche Benennung, etwa heterogene HVAC- und Lüftungsaufbauten auf Flachdächern, ergänzt ein klassischer, konturbasierter CV-Detektor[4] die Erkennung. Und für Fälle, in denen beide bildbasierten Verfahren an ihre Grenzen stoßen, vergleicht ein dritter Detektor die Höhenwerte des LiDAR-Oberflächenmodells gegen die erwartete, plane Dachebene und markiert jede signifikante Abweichung als potenziellen Aufbau.

Dieser dritte Detektor ist aus einem konkreten Problem entstanden: Große Gauben werden im Luftbild oft nicht als eigenständige Objekte wahrgenommen, sondern wirken wie ein Teil der Dachstruktur – für ein bildbasiertes Verfahren eine strukturell schwierige Erkennungsaufgabe. Über Höhenunterschiede lässt sich eine Gaube dagegen unabhängig von Bildqualität und Beleuchtung identifizieren, auch auf vollständig verschatteten Dachseiten. Damit entsteht ein klassischer Trade-off zwischen Sensitivität und Präzision: Ein sehr sensitiv eingestelltes System erkennt mehr potenzielle Hindernisse, produziert aber auch mehr False Positives; ein zu strenges System übersieht relevante Objekte. Widersprechen sich zwei Detektoren, priorisieren wir das geometriebasierte Signal, da es am wenigsten anfällig für Beleuchtungsartefakte ist.

Segmentierung liefert zunächst Masken – für die Planung selbst sind sie noch nicht ausreichend. Das Postprocessing bereinigt Masken, extrahiert Konturen, vereinfacht Polygone, entfernt kleine Artefakte, vermisst Flächen, leitet Sperrzonen ab, berechnet Sicherheitsabstände und markiert unsichere Bereiche. Erst dieser Schritt übersetzt ein KI-Ergebnis in eine domänenspezifische Planungslogik: Ein erkannter Kamin wird zu einer Sperrfläche mit definiertem Abstand, eine Gaube verändert die belegbare Dachgeometrie, und eine unsichere Segmentierungsmaske geht in den Review statt automatisch belegt zu werden.

Ein gutes Segmentierungsergebnis reicht nicht aus, wenn die erkannten Objekte im 3D-Modell an der falschen Stelle landen. Schon kleine Verschiebungen können dazu führen, dass Module optisch auf Wänden erscheinen, über Dachkanten hinausragen oder Hindernisse nicht sauber ausgespart werden. 

Ein Teil dieser Verschiebungen entsteht, weil 3D-Modell und Orthofoto[5] aus unterschiedlichen Datenquellen mit unterschiedlicher Genauigkeit stammen. Die horizontalen Abweichungen korrigieren wir über Contour Matching[6] zwischen den extrahierten Dachmasken und den projizierten Dachkanten des 3D-Modells, kombiniert mit einer perspektivischen Transformation[7], die Rotation, Translation und Skalierung gemeinsam schätzt. Ein früherer Schwachpunkt bei schrägen Luftbildern ließ sich beheben, indem das Alignment[8] konsequenter entlang der 3D-Geometrie berechnet wird. Eine zusätzliche Sicherheitslogik greift, wenn die zugrunde liegende Segmentierungsmaske zu unsicher ist: In diesem Fall wird das Alignment nicht erzwungen, um eine fehlerhafte Ausrichtung nicht in eine falsch platzierte Modulbelegung zu übersetzen.

Eine zweite, unabhängige Abweichung entsteht durch den Aufnahmewinkel der Orthofotos selbst – den Parallaxeneffekt. Wie wir diesen korrigieren, beschreibt der folgende Abschnitt.

Orthofotos wie swissIMAGE sind auf das Gelände entzerrt, nicht auf die Dachebene. Alles, was über dem Bodenniveau liegt, erscheint im Bild seitlich versetzt – der Versatz wächst mit der Objekthöhe und dem Abstand zum Bildzentrum (Nadir). Ein Dachfirst, der in  Wirklichkeit über der Gebäudemitte liegt, erscheint im Orthofoto deshalb verschoben. 

Zur Korrektur erkennen wir den Dachfirst sowohl im Orthofoto als auch im 3D-Modell und vergleichen ihre Position. Die relative Verschiebung zwischen beiden ist der gesuchte Parallaxeneffekt. Wir korrigieren ihn, indem wir diese Verschiebung gezielt minimieren.

Die Belegung selbst ist keine Aufgabe der Bilderkennung mehr, sondern einer zusätzlichen Regel- und Optimierungsschicht. Sie berücksichtigt geeignete Dachflächen, Ausrichtung, Neigung, Modulgröße, Modulorientierung, Randabstände, Abstände zu erkannten Hindernissen, Sperrflächen sowie konstruktiv plausible Gruppierungsmuster. 

Eine zentrale Regel betrifft die Vermeidung unrealistischer Modulgruppen: Kleine Inseln oder einzelne Module sind zwar geometrisch möglich, aber planerisch selten sinnvoll. Eine Mindestregel von 2x2 Modulen entfernt Flächen mit weniger als vier Modulen und einzelne Brücken zwischen Gruppen, wodurch das Ergebnis weniger fragmentiert ausfällt und näher an realistischen Planungsmustern liegt. Auch die Ausrichtung der Module spielt eine Rolle: Jedes Modul im Tool hat dieselbe Größe, lässt sich aber wahlweise hochkant oder quer orientieren. Einzelne querformatige Reihen können eine sinnvolle Gesamtbelegung verhindern; die passende Modulorientierung pro Fläche hilft, Fragmentierung zu reduzieren und mehr nutzbare Fläche auszuschöpfen. Perspektivisch lässt sich die Belegung um versetzte Platzierungsmuster erweitern, etwa mit 30 bis 50 Prozent versetzten Modulreihen.

Zur Bewertung der automatischen Belegung nutzen wir eine IoU-basierte Auswertung (Intersection over Union), die misst, wie stark sich automatisch erzeugte Belegung und Referenzplanung überlappen. In vielen getesteten Fällen zeigte sich eine hohe Ähnlichkeit zur Referenzplanung – eine projektbezogene Beobachtung innerhalb des getesteten Datensatzes, keine allgemeine Genauigkeitsangabe. Die größten Abweichungen entstanden durch unvollständige Segmentierung, Alignment-Probleme, konservative Abstandsvorgaben, komplexe Gauben, Flachdächer mit technischen Aufbauten und verdeckte Dachbereiche.

Die KI-gestützte Analyse – Segmentierung, Fusion, Alignment – ist rechenintensiv und läuft im Bereich mehrerer Minuten. Die Inferenz[9] läuft auf GPU-Instanzen in der Cloud; die Infrastruktur ist vollständig containerisiert und als Infrastructure as Code definiert (Terraform/AWS)[10]. 

Eine Anwendung, die bei jeder Nutzerinteraktion erneut auf diese Analyse wartet, wäre für explorative Nutzung ungeeignet. Wir trennen deshalb die einmalige KI-Analyse von der nachgelagerten Layout-Berechnung, die auf dem bereits fusionierten Modell in Sekunden läuft. Ändert ein:e Nutzer:in die Dachausrichtung, wählt eine andere Flachdach-Variante oder deaktiviert einzelne Flächen, wird ausschließlich die Layout-Berechnung neu ausgeführt. Diese Trennung ist die Voraussetzung dafür, dass aus einem KI-Analyseergebnis ein bearbeitbares Werkzeug wird: Nutzer:innen entfernen Module, passen Flächen manuell an oder ändern die Modulorientierung pro Fläche.

Aus Geodaten, Luftbildern, Höheninformationen und 3D-Geometrie entsteht ein semantisches Gebäudemodell – eine strukturierte Datengrundlage für Planung, Vertrieb und Ausführung. Darauf lassen sich perspektivisch spezialisierte KI-Agenten aufsetzen: ein Planning Agent, der Dachflächen bewertet und Modulbelegungen vorschlägt; ein Regulation Agent, der die Planung mit Modultypen, Wechselrichtern und Speichern verknüpft; ein Commercial Agent, der Angebotspositionen und Wirtschaftlichkeitsannahmen erzeugt; und ein Documentation Agent, der Nachweise und Übergabeunterlagen erstellt. Aus einer automatisierten Dachanalyse entsteht so schrittweise ein digitales Rückgrat für Planung, Vertrieb und Ausführung.

Automatisierte Solarbelegung entsteht aus dem Zusammenspiel vieler unvollständiger Bausteine. Der entscheidende technische Schritt liegt in der intelligenten Kombination dieser Quellen zu einem System, das in realen Planungsprozessen nützlich bleibt. Robuste Registrierung und ein bearbeitbares Ergebnis tragen dabei mehr zur Praxistauglichkeit bei als der Anspruch auf vollautomatische Perfektion: In der Praxis überzeugt das System, das Expert:innen schneller zu einer belastbaren Entscheidung bringt.