RM Rudolf Müller Events GmbHEin Weg wird breiter, eine Pflasterfläche größer, eine Mulde kleiner. Für Landschaftsarchitekten sind solche Änderungen Alltag. Für den Überflutungsnachweis können sie jedoch bedeuten, Flächen neu zu ermitteln und Berechnungen erneut anzustoßen. Nic Züchner hat an einem realen Dresdner Projekt untersucht, was passiert, wenn Entwurf, Starkregendaten und Entwässerungsberechnung nicht mehr getrennt voneinander laufen. Sein BIM-Modell zeigt nach einer Planänderung, ob der vorhandene Rückhalteraum noch reicht.
Die Bilder von überfluteten Straßenzügen und vollgelaufenen Kellern nach extremen Starkregenereignissen prägten die Nachrichten des Sommers. Der Klimawandel führt zu einer signifikanten Zunahme von Extremwetterereignissen. Das stellt auch Planer vor die Aufgabe, Städte resilienter und nachhaltiger zu gestalten. Doch während der Hoch- und Infrastrukturbau bei der Digitalisierung mittels Building Information Modeling (BIM) voranschreitet, ist die Landschaftsarchitektur noch nicht wirklich digital integriert. Lediglich 15 Prozent der Landschaftsarchitekturbüros in Deutschland nutzen BIM regelmäßig, während es in der Architektur 29 Prozent sind
Freianlagen müssen Wasser aufnehmen, zurückhalten oder gezielt ableiten können. Der Überflutungsnachweis soll zeigen, ob Regenwasser bei einem starken Ereignis schadlos auf dem Grundstück zurückgehalten werden kann. In der Praxis ist dieser Nachweis oft vom Entwurf getrennt. Flächen werden geplant, verändert und neu aufgeteilt. Die Berechnung läuft in Tabellen, separaten Programmen oder bei spezialisierten Ingenieurbüros. Ändert sich der Entwurf, müssen Flächenwerte, Oberflächenarten und Einzugsgebiete erneut geprüft und übertragen werden. Wenn Planstand und Berechnungsgrundlage auseinanderlaufen, wird aus einer kleinen Änderung schnell ein Abstimmungsproblem.
Hier setzt Nic Züchner an. In seiner Masterarbeit an der TU Dresden hat der Architekt untersucht, wie komplexe Klimadaten des Deutschen Wetterdienstes (DWD) direkt in den digitalen Entwurfsprozess integriert werden können, um bereits in frühen Phasen präzise Aussagen über das Regenwassermanagement treffen zu können. Konkret geht es in seiner Arbeit um den Überflutungsnachweis in der Landschaftsarchitektur und wie er sich mit Hilfe eines BIM-gestützten Prozesses zuverlässig und automatisiert an alle Planänderungen anpassen lässt.
2026 zeichnete buildingSMART Deutschland die Arbeit „BIM in der Landschaftsarchitektur“ als BIM Champion in der Kategorie „Arbeiten von Studenten und Auszubildenden“ aus. Die Arbeit zeigt keinen fertigen Standardprozess für die breite Praxis. Sie zeigt aber sehr konkret, wie der Überflutungsnachweis näher an den Entwurf rücken kann.
Kleine Planänderung, große Wirkung
Das Problem beginnt bei einer alltäglichen Frage: Was passiert, wenn sich im Entwurf eine Fläche ändert? Vielleicht wird ein Weg breiter, vielleicht wechselt das Material, vielleicht verschiebt sich die Grenze eines Platzes. Für die Zeichnung ist das eine normale Planänderung. Für die Entwässerungsplanung ist sie mehr: Eine größere oder stärker versiegelte Fläche kann mehr Regenwasser erzeugen. Damit ändern sich die Flächen, mit denen der Überflutungsnachweis rechnet.
Hinzu kommt die Schnittstelle zwischen Landschaftsarchitektur und Wasserwirtschaft. Der Überflutungsnachweis wird häufig an Fachplaner oder Ingenieurbüros übergeben. Damit müssen alle Beteiligten mit denselben Flächen, Einzugsgebieten und Annahmen arbeiten. Unterschiedliche Planstände, unklare Flächenabgrenzungen oder nachträglich geänderte Materialien können dazu führen, Landschaftsarchitekt und Entwässerungsplaner nicht mehr mit denselben Flächen rechnen.
Züchners Ausgangsfrage lautet deshalb: Warum sollten Daten aus einem digitalen Entwurf erst manuell herausgezogen, übertragen und neu berechnet werden, wenn das Modell diese Zusammenhänge selbst herstellen kann?
Ein reales Projekt offenbart die Schwachstelle
Für seine Untersuchung nutzte Züchner ein reales Referenzprojekt: die Freianlagen einer studentischen Wohneinrichtung an der Strehlener Straße 20 in Dresden. STORCH.LANDSCHAFTSARCHITEKTUR hatte das knapp 5.200 Quadratmeter große Grundstück bereits in Vectorworks geplant. Der Planungsstand entsprach der Leistungsphase 3. Das ist die Phase, in der aus dem groben Konzept ein koordinierter, technisch durchgearbeiteter BIM-Entwurf mit belastbaren Mengen, Kosten und Fachmodellen entsteht. Eine Entwässerungsplanung und ein klassisch erstellter Überflutungsnachweis lagen gleichfalls vor.
Schon diese Unterlagen zeigten das Datenproblem. Für den ursprünglichen Nachweis waren relevante Flächen erfasst und mit Abflussbeiwerten versehen worden. Es fehlte jedoch eine eindeutige Unterteilung in Einzugsräume. Damit war nur eingeschränkt nachvollziehbar, welche Fläche ihr Regenwasser tatsächlich zu welcher Entwässerungsanlage führt. Zudem entsprach die Flächeneinteilung teilweise nicht mehr dem betrachteten Lageplan.
Das Beispiel zeigt sehr greifbar, was passieren kann, wenn Zeichnung und Nachweis nicht dieselbe Datenbasis verwenden: Der aktuelle Entwurf und die Zahlen, mit denen gerechnet wird, können auseinanderlaufen.
Nic ZüchnerDie Fläche wird zur Rechengröße
Züchner überführte das Projekt in ein BIM-Fachmodell und gab den relevanten Flächen zusätzliche Informationen. Eine Fläche war damit nicht mehr nur eine gezeichnete Kontur. Das Modell wusste, zu welchem Einzugsgebiet sie gehört, welche Oberflächenart geplant ist, wie groß sie ist und welcher Abflussbeiwert dafür angesetzt werden muss.
Aus der Geometrie liest Vectorworks die Flächengröße automatisch aus. Über die hinterlegte Flächenart ordnet das System den entsprechenden Abflussbeiwert zu. Daraus berechnet es, welcher Teil des Niederschlags tatsächlich abfließt. Gleichzeitig lässt sich festlegen, zu welcher Rinne, Mulde oder Rigole die jeweilige Fläche entwässert.
In klassischen oder weniger stark verknüpften Arbeitsabläufen landen solche Werte häufig in getrennten Tabellen, Plananhängen oder Berechnungsblättern. Im Versuchsmodell entstehen sie direkt aus der Geometrie, auf die sich auch der Entwurf bezieht. Ändert der Planer die Fläche, ändert sich damit auch die Grundlage der Berechnung.
Auch der Starkregen wird Teil des Modells
Zum Überflutungsnachweis gehört jedoch nicht nur die Grundstücksfläche. Der Planer muss auch wissen, mit welchem Regenereignis er für den jeweiligen Standort rechnen muss. Dafür nutzt die Entwässerungsplanung die regionalisierten Starkregendaten des Deutschen Wetterdienstes. Die KOSTRA-DWD-Daten liefern für unterschiedliche Standorte, Regendauern und statistische Wiederkehrintervalle die benötigten Niederschlagswerte.
Züchner bereitete diese Daten zunächst in QGIS auf, einer Open-Source-Software für geografische Daten. Anschließend integrierte er sie georeferenziert in Vectorworks. Die Vorbereitung ist aufwendig, weil verschiedene Dauerstufen und Datensätze zusammengeführt werden müssen. Danach liegen die benötigten Niederschlagsdaten aber strukturiert im Modell vor.
Damit verbindet das Fachmodell drei Informationswelten, die in der Praxis oft getrennt bleiben: den aktuellen Entwurf, die Eigenschaften seiner Flächen und die für den Standort maßgebenden Starkregendaten. Die erneute manuelle Erfassung oder Übertragung zwischen verschiedenen Softwarelösungen entfällt nicht vollständig, wird aber deutlich reduziert.
Ändern, aktualisieren, neu rechnen
Der praktische Unterschied zeigt sich bei einer Planänderung. Wird ein Einzugsraum größer oder kleiner, verändert der Planer die Geometrie. Wird aus einer Pflasterfläche eine andere Oberflächenart, ändert er die hinterlegte Eigenschaft. Auch Länge oder Größe einer Versickerungsanlage lassen sich anpassen.
Anschließend aktualisiert der Nutzer die zugehörige Berechnungstabelle. Das Modell berechnet davon abhängige Werte neu, unter anderem abflusswirksame Flächen, maßgebende Niederschlagswerte, Dimensionierung der Entwässerungsanlage und erforderliches Rückhaltevolumen. Der Planer kann danach beurteilen, ob die Anlage noch ausreicht oder ob Entwässerung, Höhenplanung oder Freiraumgestaltung angepasst werden müssen.
Wichtig ist dabei die Grenze des Prototyps: Die Berechnung läuft noch nicht vollständig selbstständig im Hintergrund. Der Anwender muss die Tabelle öffnen und aktiv aktualisieren. Trotzdem entfällt ein wesentlicher Teil der bisherigen Kette: Flächenwerte müssen nicht erneut aus dem Plan abgelesen und in eine separate Berechnung übertragen werden, und die bereits integrierten Niederschlagsdaten müssen nicht für jede Variante neu erfasst werden.
Wenn die Mindestgröße nicht reicht
Besonders anschaulich wird der Ansatz bei der Rigole, also einem unterirdischen Speicher, in dem Regenwasser gesammelt wird und anschließend versickern kann. Für ein betrachtetes Einzugsgebiet ermittelte das Modell zunächst eine erforderliche Mindestlänge von 7,28 Metern. Daraus ergab sich ein Speichervolumen von 29,80 Kubikmetern.
Auf den ersten Blick hätte die Anlage damit ausreichend dimensioniert wirken können. Züchners Modell verknüpfte die Rigole jedoch zusätzlich mit dem oberirdischen Rückhalteraum, in dem überschüssiges Wasser bei einem außergewöhnlichen Regenereignis schadlos zwischengespeichert werden kann. Dabei zeigte sich: Mit der zunächst berechneten Dimensionierung würde das erforderliche Rückhaltevolumen den verfügbaren Raum um 15 Prozent überschreiten.
Züchner vergrößerte die untersuchte Rigole deshalb auf 8,50 Meter. Für ein Starkregenereignis mit einer statistischen Wiederkehrzeit von 30 Jahren berechnete das Modell danach 36,17 Kubikmeter notwendiges Rückhaltevolumen. Tatsächlich zur Verfügung standen rund 38,80 Kubikmeter. Der vorhandene Rückhalteraum wäre damit zu etwa 93 Prozent ausgeschöpft, würde in diesem Szenario aber ausreichen.
Die Rechnung beantwortet damit eine konkrete Entwurfsfrage: Reicht das Zusammenspiel aus unterirdischem Speicher und oberirdischem Freiraum für den betrachteten Starkregenfall?
Vom Nachweis zum Variantenwerkzeug
Damit verändert sich auch die Rolle des Überflutungsnachweises. Im klassischen Ablauf entsteht häufig ein berechnetes Volumen. Bei ebenen Flächen wird die potenziell überflutete Fläche nach den für die Masterarbeit geführten Expertengesprächen vielfach nur abgeschätzt. Änderungen der Planung können anschließend eine neue Berechnung notwendig machen.
Züchners Modell verbindet den Nachweis stärker mit dem Entwurf. Die Fläche des Grundstücks wurde in mehrere Einzugsgebiete aufgeteilt und verschiedenen Entwässerungssystemen zugeordnet: einer Rigole, einer Mulde und mehreren Rinnen. Ändert sich die Größe oder Art einer Fläche oder die Dimensionierung einer Anlage, passen sich nach Aktualisierung der Berechnungstabelle auch die damit verbundenen Werte an.
Damit kann der Planer Varianten prüfen, ohne Entwurf und Starkregennachweis jedes Mal voneinander zu trennen: Was passiert, wenn eine Fläche stärker versiegelt wird? Wie verändert sich der Rückhalteraum, wenn eine Mulde kleiner ausfällt? Reicht ein Hochbord, um Wasser vorübergehend auf einer Fläche zu halten? Solche Fragen lassen sich früher im Entwurf stellen und mit den Modelldaten verknüpfen.
Das macht den eigentlichen Wert der Arbeit aus. Der Überflutungsnachweis wird nicht einfach digitalisiert. Er rückt näher an den Moment, in dem planerische Entscheidungen fallen.
Warum die Studie kein fertiger Produktworkflow ist
Die Arbeit bleibt eine Machbarkeitsstudie. Sie kann nicht zeigen, dass der BIM-gestützte Nachweis exakt dasselbe Ergebnis liefert wie der vorhandene klassische Nachweis. Dafür waren die Ausgangsbedingungen zu unterschiedlich. Der ursprüngliche Überflutungsnachweis betrachtete ausschließlich die Rigole; die angeschlossenen Flächen waren nicht in dieselben eindeutigen Einzugsräume gegliedert, die Züchner für seine Untersuchung aufbaute.
Züchner ließ die neu entwickelten Berechnungen zusätzlich von der Ingenieurgesellschaft für Stadthydrologie ifs kontrollieren. Die externe Prüfung bestätigte den rechnerischen Ansatz grundsätzlich und unterstrich die praktische Umsetzbarkeit. Zugleich bleibt fachliche Kontrolle notwendig. Ein BIM-Modell ersetzt weder wasserwirtschaftliche Expertise noch eine Plausibilitätsprüfung der Ergebnisse.
Auch die digitalen Werkzeuge sind noch nicht durchgehend auf diesen Anwendungsfall vorbereitet. Für die Rigole nutzte Züchner das Werkzeug für eine gerade Straße, weil es Länge, Breite und Höhe auslesbar bereitstellt. Für eine Mulde musste er einen eigenen Volumenkörper erzeugen; einzelne Werte wurden manuell übertragen.
Beim offenen Datenaustausch zeigen sich ebenfalls Grenzen. Für bestimmte Informationen des Überflutungsnachweises fehlen standardisierte Eigenschaftensets im IFC-Format. Deshalb musste die Arbeit eigene Custom Property Sets definieren. Bei der Kontrolle des IFC-Exports in Solibri wurde zudem eine sehr kleine Infiltrationsrate auf null gerundet. Solche Details entscheiden darüber, ob Daten zuverlässig zwischen Fachmodellen, Prüfsoftware und weiteren Beteiligten ausgetauscht werden können.
Was die Arbeit für die Landschaftsarchitektur zeigt
BIM ist in der Landschaftsarchitektur noch nicht so etabliert wie im Hochbau. Die Masterarbeit nennt 15 Prozent der Landschaftsarchitekturbüros in Deutschland, die BIM regelmäßig nutzen; in der Architektur sind es 29 Prozent. Zugleich steigt der Druck, Freianlagen klimaresilienter zu planen und Starkregenrisiken früher zu berücksichtigen.
Züchners Arbeit zeigt, wie ein konkreter Anwendungsfall dafür aussehen kann. Sie bleibt nah an einem realen Projekt, nutzt vorhandene Planungssoftware und macht zugleich sichtbar, wo Softwarehersteller und Standardisierung nacharbeiten müssen. Für eine breite Anwendung bräuchte es spezialisierte Werkzeuge für Einzugsräume, Mulden, Rigolen und Rückhaltevolumen sowie einheitlichere Datenstrukturen für Regenwassermanagement und Überflutungsnachweis.
Der wichtigste Beitrag liegt aber nicht in einem einzelnen Tool. Die Arbeit zeigt, dass Klimaanpassung nicht erst als nachträglicher Prüfpunkt verstanden werden muss. Wenn Entwurf, Flächeninformationen und Starkregendaten auf derselben Datenbasis arbeiten, kann der Überflutungsnachweis in den Planungsprozess hineinrücken. Dann entscheidet er nicht erst am Ende, ob ein Entwurf rechnerisch funktioniert. Er kann während des Entwerfens zeigen, welche Variante robuster ist.

:quality(80))
:quality(80))
:quality(80))
:quality(80))
:quality(80))
:quality(80))
:quality(80))