Warum IFC-Georeferenzierung bei Photogrammetrie-Übergaben oft der kritische Punkt ist
[Photogrammetrie](/ratgeber/photogrammetrie-leitfaden-2026) liefert aus vorhandenen oder beigestellten Bildern sehr brauchbare Grundlagen: Punktwolken, Meshes, Orthofotos, Dachflächen, Fassaden und modellierte Gebäudehüllen. Für BIM-Projekte reicht diese Geometrie allein aber nicht. Das Modell muss im richtigen räumlichen Bezug ankommen, sonst sieht es in der Zielsoftware gut aus, liegt aber an der falschen Stelle, mit falscher Ausrichtung oder mit unklarem Höhenbezug.
Genau hier entsteht die Lücke zwischen einem schönen 3D-Modell und einer belastbaren IFC-Übergabe. IFC speichert nicht nur Bauteile, sondern kann auch die Beziehung zwischen lokalem Engineering-Koordinatensystem und Kartenkoordinatensystem beschreiben. buildingSMART dokumentiert dafür unter anderem IfcMapConversion und IfcProjectedCRS. Für Planungsteams ist das entscheidend, weil CAD, Revit, GIS, Katastergrundlagen und [Punktwolken](/ratgeber/punktwolke-drohne-cad-bim) sonst nicht deckungsgleich arbeiten.
Für Voxelia ist das Thema besonders relevant, weil die Dienstleistung nicht der Drohnenflug ist. Der Kern ist die Verarbeitung vorhandener Bilddaten zu nutzbaren Planungsdaten. Wenn aus einem Bilddatensatz eine BIM-nahe Übergabe entsteht, muss deshalb klar sein, ob das Ergebnis lokal skaliert, projektbezogen verschoben, georeferenziert oder vollständig mit CRS- und Höhenbezug dokumentiert ist.
IfcMapConversion und IfcProjectedCRS: die wichtigsten Bausteine
buildingSMART beschreibt IfcMapConversion als Transformation vom lokalen Engineering-Koordinatensystem des Projekts in das [Koordinatenreferenzsystem der Karte](/ratgeber/koordinatensysteme-drohnendaten). Die Operation kombiniert Skalierung, Rotation um die Z-Achse und Translation über Eastings, Northings und OrthogonalHeight. Wichtig: IfcMapConversion übernimmt laut Spezifikation nicht die Kartenprojektion selbst; sie beschreibt die Beziehung zwischen bereits definiertem lokalem und Karten-Koordinatensystem.
IfcProjectedCRS beschreibt das Ziel-CRS, auf das sich diese Transformation bezieht. In einem 3D-Kontext fordert die IFC-Dokumentation ein zusammengesetztes CRS, aus dem geodätisches Datum und vertikales Datum eindeutig erkennbar sind. Der Name soll nach buildingSMART ein eindeutiger Identifier sein, typischerweise ein EPSG-Code. Mehrere EPSG-Codes in einem einzigen Name-String sind ausdrücklich nicht erlaubt.
Seit ISO 16739-1:2024 ist IFC 4.3 als internationale Norm in Edition 2 veröffentlicht. Das macht die saubere Georeferenzierung im BIM-Austausch noch relevanter, weil IFC nicht nur Gebäude, sondern auch Infrastruktur- und Facility-Workflows über den Lebenszyklus abdeckt.
| IFC-Baustein | Aufgabe | Was prüfen? | Praxis-Hinweis |
|---|---|---|---|
| IfcProjectedCRS.Name | Identifiziert das Ziel-Koordinatenreferenzsystem | Eindeutiger EPSG-Identifier oder WKT, keine zusammengeklebten EPSG-Listen | Für DACH-Projekte zum Beispiel projektabhängig ETRS89/UTM, LV95 oder ein eindeutig definiertes lokales System. |
| Eastings / Northings | Verschiebt den lokalen Ursprung in das Zielsystem | Passen die Werte zum Projektgebiet und zum gewählten CRS? | Falsche UTM-Zone oder vertauschte Achsen erzeugen sofort große Versätze. |
| OrthogonalHeight | Setzt die Höhe relativ zum vertikalen Datum | Ist der Höhenbezug dokumentiert und nicht nur als generisches Z in Metern übergeben? | Für Dach-, Fassaden- und Bestandsmodelle sind ellipsoidische und physikalische Höhen klar zu trennen. |
| XAxisAbscissa / XAxisOrdinate | Beschreibt die Richtung der lokalen X-Achse im Karten-Koordinatensystem | Stimmt Projekt-Nord, lokales Achsensystem und Modellrotation? | Schon kleine Rotationsfehler machen CAD-Überlagerungen und BIM-Koordination mühsam. |
| Scale | Konvertiert Einheiten zwischen lokalem System und Map-CRS | Wird Scale für Einheiten genutzt und nicht als versteckte Geometriekorrektur missbraucht? | Wenn Scale fehlt, gilt laut IFC-Dokumentation 1.0. |
Die Koordinatenlogik hinter der IFC-Übergabe
Die IfcMapConversion-Logik ist bewusst einfach gehalten: Zuerst wird gleichmäßig skaliert, dann gegen den Uhrzeigersinn um die Z-Achse rotiert, anschließend werden Eastings, Northings und OrthogonalHeight addiert. Der Rotationswinkel ergibt sich laut buildingSMART aus θ = arctan(XAxisOrdinate / XAxisAbscissa).
Für die Praxis heißt das: Ein photogrammetrisches Modell kann intern lokal und numerisch stabil bleiben, während die reale Lage sauber über Metadaten und Koordinatenoperation dokumentiert wird. Das ist oft besser als riesige Weltkoordinaten direkt in Modellgeometrie zu schreiben. Große Koordinatenwerte können in CAD- und BIM-Software Präzisions- und Darstellungsprobleme verursachen.
Für Voxelia-Übergaben ist diese Trennung zentral. Das Modell wird als planbare Geometrie aufbereitet, aber der Raumbezug wird so dokumentiert, dass Folgegewerke wissen, ob sie ein lokales Modell, ein BIM-Modell mit Shared Coordinates oder eine vollständig georeferenzierte openBIM-Übergabe erhalten.
Revit, Shared Coordinates und false origin richtig einordnen
In Revit-Workflows tauchen IFC-Georeferenzierung, Shared Coordinates und Punktwolken oft gemeinsam auf. Der zentrale Unterschied: Die Punktwolke oder das photogrammetrische Referenzmodell ist nicht automatisch ein semantisches BIM-Modell. Es dient häufig als Referenz, aus der Bauteile modelliert oder geprüft werden.
Autodesk dokumentiert für Revit explizit Projektstandort, Vermessungspunkt und gemeinsame Koordinaten. Für IFC- und Punktwolken-Übergaben bedeutet das: Der lokale Modellursprung, das Projekt-Koordinatensystem und der reale Lagebezug müssen bewusst aufeinander abgestimmt werden. Wenn ein großes geodätisches Koordinatensystem unkritisch direkt in die Geometrie geschrieben wird, entstehen in der Praxis häufig Import-, Rundungs- oder Ausrichtungsprobleme.
Der Begriff false origin beschreibt genau diese technische Strategie: Das Modell bleibt nahe an einem lokalen Ursprung, während ein Versatz und eine Rotation den Bezug zur realen Welt herstellen. Für Photogrammetrie ist das sinnvoll, weil Punktwolken und Meshes numerisch stabil bleiben und trotzdem in CAD, Revit, IFC oder GIS anschlussfähig dokumentiert werden können.
Typische Fehler bei Photogrammetrie-zu-IFC-Übergaben
Viele Probleme entstehen erst beim Zusammenspiel mehrerer Systeme: Photogrammetrie-Software, CAD, Revit, IFC-Viewer, GIS und Vermessungsgrundlagen interpretieren Ursprung, Achsen und Höhen nicht immer gleich. Deshalb sollte eine IFC-Übergabe aus Bilddaten nicht nur visuell geprüft werden, sondern mit Blick auf Import, Überlagerung und Folgeplanung.
| Risiko | Warum kritisch | Symptom | Gegenmaßnahme |
|---|---|---|---|
| IFC enthält Geometrie, aber keinen klaren CRS-Bezug | Das Modell ist visuell nutzbar, aber nicht sicher mit Kataster, CAD oder GIS verschneidbar | Modell muss in der Zielsoftware manuell geschoben und gedreht werden | CRS, Ursprung, Rotation, Maßstab und Höhenbezug bei der Übergabe dokumentieren |
| Mehrere EPSG-Codes unsauber im Name-Feld | buildingSMART erlaubt im IfcProjectedCRS.Name nur einen eindeutigen Code | Viewer oder Prüfwerkzeuge interpretieren CRS uneinheitlich | Eindeutiges compound CRS oder WKT verwenden, wenn ein einzelner EPSG-Code nicht reicht |
| Ellipsoidische Höhe wird als Bauhöhe gelesen | GNSS-Höhen und nationale Höhenbezüge sind nicht automatisch identisch | Dachhöhen, Anschlusshöhen oder Ebenen liegen systematisch falsch | Vertikalbezug separat benennen und bei Bedarf transformieren lassen |
| Große Weltkoordinaten direkt in Modellgeometrie | BIM- und CAD-Software kann bei sehr großen Koordinaten empfindlich reagieren | Importprobleme, zitternde Geometrie, Versatz oder Rundungsfehler | Lokalen Ursprung mit sauberer MapConversion oder Shared-Coordinate-Strategie nutzen |
| Photogrammetrische Referenz wird als fertiges BIM missverstanden | Punktwolke oder Mesh enthalten keine zuverlässige Bauteilsemantik | Wände, Dächer oder Öffnungen werden in Folgeprozessen falsch ausgewertet | Referenzdaten, modellierte Bauteile und Interpretationsgrenzen getrennt liefern |
So prüft Voxelia IFC-Übergaben aus vorhandenen Bilddaten
Der sinnvolle Prüfprozess beginnt nicht beim Exportformat, sondern beim Folgeworkflow. Ein Viewer-Modell, eine CAD-Unterlage, ein Revit-Referenzmodell und eine openBIM-Übergabe brauchen unterschiedliche Aussagen zu Ursprung, Maßstab, Achsen, Höhen und Qualität.
Zielsystem und Lieferzweck klären
Vor dem Processing wird festgelegt, ob IFC, Punktwolke, Mesh, Orthofoto, DXF/DWG oder eine kombinierte BIM-Übergabe benötigt wird.
Bilddaten und Referenzen prüfen
Voxelia bewertet EXIF/XMP, GNSS, GCPs, Referenzmaße, Maßstab, Checkpoints und sichtbare Geometriequalität.
Lokalen Ursprung stabil setzen
Das Modell bleibt für die Verarbeitung numerisch beherrschbar; reale Lage, Rotation und Höhe werden bewusst als Übergabe-Information geführt.
IFC- und CRS-Daten gegenprüfen
IfcProjectedCRS, IfcMapConversion, EPSG/WKT, Projekt-Nord, Höhenbezug und Einheiten werden auf Plausibilität geprüft.
Importfähigkeit praktisch denken
Die Übergabe wird so beschrieben, dass Planer wissen, ob sie Shared Coordinates, lokalen Ursprung, Punktwolkenreferenz oder modellierte Bauteile erwarten.
Grenzen transparent dokumentieren
Wenn Bilddaten nur lokale Skalierung oder visuelle Referenz erlauben, wird das klar benannt, statt eine scheinbar vermessungstaugliche IFC-Datei zu versprechen.