Ein Gastbeitrag von Gerd Knobling

Die Lücke zwischen Geoportal und Revit: Warum frühe Entwurfsphasen bessere digitale Grundlagen brauchen

Gibt Deukos eine einfache Antwort?

In der frühen Entwurfsphase geht es oft noch nicht um das perfekte Modell. Es geht erst einmal um Orientierung.

Wie liegt das Grundstück im Gelände? Wie hoch ist die Nachbarbebauung? Wie verläuft die Straße? Welche Dachformen, Traufhöhen, Geländesprünge oder Blickbeziehungen prägen den Ort? Und wie schnell bekomme ich daraus eine Grundlage, mit der ich im Entwurf, in Revit, Archicad, Rhino oder AutoCAD tatsächlich weiterarbeiten kann?

Genau an dieser Stelle entsteht im Alltag von Architekturbüros, Studierenden und Lehrenden häufig ein Bruch. Viele Informationen sind grundsätzlich vorhanden. Es gibt digitale Geländemodelle, 3D-Gebäudemodelle, Katasterdaten, Luftbilder, Bebauungspläne und zunehmend auch maschinenlesbare Planungsdaten. In Deutschland stehen beispielsweise LoD2-Gebäudemodelle zur Verfügung, bei denen Gebäude mit standardisierten Dachformen, tatsächlichen Firstverläufen und Grundrissen aus der amtlichen Liegenschaftskarte beschrieben werden. Die Daten werden unter anderem im CityGML-Format bereitgestellt.

Trotzdem bedeutet „Daten vorhanden“ noch lange nicht: „im Entwurf sofort nutzbar“.

Daten sind da — aber oft nicht in der Form, in der Architekten sie brauchen

Wer schon einmal versucht hat, aus Geodaten eine brauchbare Planungsgrundlage zu machen, kennt das Problem. Die Daten liegen in unterschiedlichen Formaten, Koordinatensystemen, Kachelstrukturen und Qualitätsstufen vor. Sie sind für GIS-Anwendungen, Verwaltungen, Vermessung oder Stadtmodelle sehr sinnvoll aufgebaut — aber nicht automatisch für den Architekturalltag.

Ein 3D-Stadtmodell kann im Geoportal korrekt angezeigt werden und trotzdem für Revit oder Archicad nur bedingt brauchbar sein. Ein Geländemodell kann fachlich sauber sein und trotzdem erst mühsam zugeschnitten, transformiert und vereinfacht werden müssen. Eine CityGML-Datei kann semantisch wertvoll sein, aber für einen schnellen Vorentwurf zu schwergewichtig oder zu umständlich im direkten Import.

CityGML ist als Standard genau für die Darstellung, Speicherung und den Austausch virtueller 3D-Stadtmodelle gedacht. Das ist für Stadtmodelle, digitale Zwillinge, Simulationen und GIS-Prozesse sehr stark. Die Anforderungen in der Architektur sind aber oft andere: Dort geht es darum, aus diesen Daten sehr schnell Schnitte, Ansichten, Höhenbezüge, Kontextmodelle und weiterbearbeitbare Geometrien zu gewinnen.

Die eigentliche Herausforderung liegt deshalb nicht nur in der Verfügbarkeit der Daten. Sie liegt in der Übersetzung.

Die frühe Phase braucht keine perfekte Simulation, sondern brauchbare Grundlagen

Gerade in Leistungsphase 1 und 2, bei Wettbewerben, Standortprüfungen, Bauvoranfragen oder ersten Machbarkeitsstudien ist Zeit ein kritischer Faktor. Oft muss innerhalb weniger Stunden oder Tage verstanden werden, wie ein Ort funktioniert.

Wie steht ein geplanter Baukörper im Straßenraum? Welche Höhe haben die Nachbargebäude? Wie fällt das Gelände? Welche Ansicht ist für die Bauvoranfrage wichtig? Wo brauche ich einen Schnitt? Welche Umgebung muss ich im Modell berücksichtigen?

In der Praxis wird dafür viel Arbeit aufgewendet, die nicht direkt Entwurfsarbeit ist: Daten suchen, Portale öffnen, Ausschnitte exportieren, Höhen abschätzen, Nachbargebäude nachbauen, Straßenräume konstruieren, Gelände modellieren, Dateien konvertieren. Diese Arbeit ist notwendig, aber sie ist nicht der kreative Kern des Entwurfs.

Aus meiner Sicht liegt hier ein großes Potenzial für digitale Werkzeuge. Nicht, weil sie die Planung ersetzen sollen. Sondern weil sie die vorbereitende Daten- und Zeichenarbeit reduzieren können.

Ein gutes Werkzeug für diese Phase muss daher nicht alles können. Es muss vor allem eines leisten: aus vorhandenen Daten schnell eine Grundlage machen, auf der man weiterdenken kann.

DEUKOS als Brücke zwischen Geodaten und Entwurfsarbeit

Mit DEUKOS versuche ich genau an dieser Schnittstelle anzusetzen.

Die Grundidee ist, amtliche 3D- und Geodaten nicht nur anzuzeigen, sondern daraus konkrete Planungsgrundlagen zu erzeugen: Geländeschnitte, Straßenansichten, Kontextmodelle, IFC-/3D-Exporte und CAD-Grundlagen, die in den üblichen Architekturprogrammen weiterverwendet werden können.

Der Unterschied ist für mich wichtig: Ein Viewer allein löst das Problem nur teilweise. Natürlich ist es hilfreich, einen Ort im Browser in 2D und 3D zu sehen. Aber für Architekten, Studierende und Büros entsteht der eigentliche Wert erst dann, wenn daraus ein verwendbares Ergebnis wird.

Also nicht nur: „Ich kann mir das Grundstück ansehen.“

Sondern: „Ich bekomme eine Straßenansicht als DXF.“
Oder: „Ich bekomme einen Geländeschnitt entlang meiner Linie.“
Oder: „Ich bekomme ein Umgebungsmodell, das ich in Revit, Archicad oder Rhino weiterverwenden kann.“

Das Ziel ist nicht, die Planung zu automatisieren. DEUKOS soll keine Entwurfsentscheidung treffen und keine rechtliche Prüfung ersetzen. Es soll die Grundlagenarbeit beschleunigen, damit mehr Zeit für Entwurf, Bewertung und Entscheidung bleibt.

Warum der reine Import oft nicht reicht

Ein besonders spannender Punkt ist die Schnittstelle zu BIM-Programmen. Revit unterstützt beispielsweise IFC-Import und IFC-Export auf Basis buildingSMART-bezogener Austauschstandards. IFC ist daher ein wichtiger Weg, um Modelle zwischen unterschiedlichen Programmen auszutauschen.

In der Praxis entscheidet aber nicht allein das Dateiformat über die Nutzbarkeit. Eine Datei kann formal importierbar sein und trotzdem schwierig in der weiteren Bearbeitung sein.

Typische Probleme sind:

• zu viele triangulierte Flächen,
• unklare Objektstruktur,
• schlecht auswählbare Geometrien,
• vermischte Gelände-, Straßen- und Gebäudeelemente,
• fehlende Höhenbezüge,
• oder Modelle, die zwar sichtbar sind, aber kaum sinnvoll weiterbearbeitet werden können.

Deshalb interessiert mich bei DEUKOS nicht nur die Frage: „Kann man etwas exportieren?“

Sondern eher: „Was kommt im Architekturprogramm wirklich an?“

Ist die Geometrie verständlich? Ist sie ausreichend sauber? Kann man sie auswählen, messen, schneiden, als Grundlage nutzen? Kann sie in einem Büro- oder Studienworkflow tatsächlich Zeit sparen?

Diese Fragen sind aus meiner Sicht entscheidender als der reine Nachweis, dass ein Export technisch möglich ist.

Ein möglicher Revit-Workflow über Dynamo

Ein nächster sinnvoller Schritt wäre ein ergänzender Workflow für Revit über Dynamo beziehungsweise DesignScript.

Die Idee dahinter ist nicht, einfach noch ein weiteres Exportformat anzubieten. Viel interessanter wäre ein Ablauf, bei dem DEUKOS die vorbereiteten Geodaten liefert und ein Dynamo-Script in Revit hilft, diese Daten sinnvoll zu strukturieren.

Zum Beispiel könnten Geländedaten korrekt platziert, Gebäudekontexte besser organisiert, Höhenbezüge überprüft oder bestimmte Elemente für Schnitte und Ansichten vorbereitet werden. Dynamo eignet sich für solche Aufgaben, weil es geometrische und datenbasierte Abläufe in Revit automatisierbar macht. DesignScript-Codeblöcke erlauben es zudem, wiederkehrende Operationen kompakter und nachvollziehbarer zu beschreiben.

Für mich wäre das ein sehr spannender Bereich für eine praxisnahe Zusammenarbeit mit Lehre und Studierenden. Nicht als fertige, abgeschlossene Lösung, sondern als offener Test- und Verbesserungsprozess.

Wie muss ein Modell aufgebaut sein, damit es in Revit wirklich brauchbar ist? Welche Informationen sollen als Bauteile, welche eher als Referenzgeometrie importiert werden? Was ist für Studierende im Entwurf hilfreich — und was macht das Modell nur unnötig kompliziert?

Solche Fragen lassen sich am besten nicht theoretisch beantworten, sondern durch konkrete Tests an realen Standorten.

Warum das für Studierende interessant sein kann

Für Studierende ist diese Schnittstelle besonders interessant, weil sie mehrere Themen verbindet, die in der Praxis immer wichtiger werden: Entwurf, BIM, Geodaten, Automatisierung, Datenqualität und digitale Stadtmodelle.

Gerade in der Ausbildung geht es nicht nur darum, ein bestimmtes Programm zu bedienen. Es geht auch darum zu verstehen, woher digitale Grundlagen kommen, welche Unsicherheiten sie haben und wie man sie kritisch verwendet.

Ein LoD2-Modell ist kein vermessenes Architekturmodell. Ein Geländemodell ersetzt kein Aufmaß. Ein automatisch erzeugter Schnitt ist keine fertige Planung. Aber all diese Grundlagen können helfen, einen Ort schneller zu verstehen und Entwurfsentscheidungen besser vorzubereiten.

Aus meiner Sicht wäre es deshalb sehr wertvoll, wenn Studierende solche Workflows testen, hinterfragen und verbessern. Nicht als reine Softwareanwender, sondern als kritische Planerinnen und Planer.

Mögliche Fragen wären zum Beispiel:

Wie gut lassen sich automatisch erzeugte Straßenansichten in einen Entwurfsplan integrieren?
Welche Detailtiefe ist für eine frühe Phase sinnvoll?
Wie sauber müssen Nachbargebäude modelliert sein?
Wann hilft ein 3D-Kontextmodell wirklich?
Welche Informationen fehlen in Revit nach dem Import?
Und welche Daten sind zwar technisch vorhanden, aber für den Entwurf eigentlich nicht relevant?

Gerade solche Rückmeldungen wären für die Weiterentwicklung von DEUKOS sehr wertvoll.

Hochschule als Testfeld zwischen Forschung, Lehre und Praxis

Hochschulen können an dieser Stelle eine besondere Rolle spielen. Sie sind nicht nur Orte der Ausbildung, sondern auch Räume, in denen neue Arbeitsweisen ausprobiert werden können.

Ein DEUKOS-Workflow könnte im Hochschulkontext daher auf mehreren Ebenen interessant sein: als Werkzeug für Standortanalysen, als Beispiel für die Verbindung von GIS und BIM, als Testfall für Revit-/Dynamo-Prozesse oder als Ausgangspunkt für studentische Untersuchungen zur Qualität digitaler Planungsgrundlagen.

Gerade Studiengänge im Bereich Architektur, Bauingenieurwesen, digitales Planen und Bauen bewegen sich zunehmend an dieser Schnittstelle. Die THWS bündelt beispielsweise Architektur, Bauingenieurwesen, Digitales Planen und Bauen sowie integrale Planungsansätze in ihrer Fakultät Architektur und Bauingenieurwesen. Damit liegt das Thema sehr nah an Fragen, die auch in Lehre und Forschung immer relevanter werden.

Für DEUKOS wäre ein solcher Austausch sehr wertvoll. Nicht, weil Studierende einfach „testen“ sollen, ob etwas funktioniert. Sondern weil sie mit frischem Blick sehr schnell erkennen, wo ein Workflow verständlich ist, wo er zu technisch wird und wo er im Entwurfsprozess tatsächlich hilft.

Ausblick: Von der Datei zur intelligenten Planungsgrundlage

Langfristig geht es nicht nur darum, einzelne Dateien zu exportieren. Spannend wird es dort, wo verschiedene Datenebenen zusammengeführt werden: Gelände, Gebäude, Grundstücke, Straßenraum, Nutzungen, Verschattung, Solarflächen, Schnitte, Ansichten und perspektivisch auch planungsrechtliche Informationen.

Der eigentliche Mehrwert entsteht dann nicht durch ein einzelnes Format, sondern durch die sinnvolle Kombination dieser Informationen.

Für die frühe Entwurfsphase könnte das bedeuten: Ein Standort wird nicht mehr mühsam aus vielen Quellen zusammengesetzt, sondern als verständliche, überprüfbare und weiterbearbeitbare Grundlage bereitgestellt. Der Entwerfende entscheidet weiterhin selbst. Aber er beginnt nicht mehr bei null.

Das ist der Anspruch, den ich mit DEUKOS verfolge: amtliche Geodaten so aufzubereiten, dass sie in Architektur, Lehre und Planung praktisch nutzbar werden.

Nicht als Ersatz für Vermessung.
Nicht als Ersatz für Genehmigungsplanung.
Nicht als automatische Entscheidung.

Sondern als Werkzeug für die frühe Phase: um schneller zu verstehen, besser zu prüfen und mit weniger Vorarbeit in den eigentlichen Entwurf einzusteigen.

Gerade deshalb würde ich mich freuen, wenn Studierende und Lehrende diesen Ansatz kritisch testen und mitentwickeln. Denn die entscheidende Frage ist am Ende nicht, ob Daten vorhanden sind. Die entscheidende Frage ist, ob sie im Planungsprozess wirklich helfen.