Ein BIM-Modell landet nach dem Import 500 km vom richtigen Ort entfernt. Oder es sitzt im Ursprung (0,0,0) statt in der Schweizer Landeskoordinate. Oder zwei Tools lesen dasselbe Modell und platzieren es unterschiedlich.
Das ist kein Exportfehler. Das ist ein Georeferenzierungsproblem.
Im IFC-Standard existieren seit Jahren die Entitäten und Mechanismen, um ein Modell präzise in ein geodätisches Referenzsystem einzubetten. Die zentrale Frage lautet: Welche Entität wird wann korrekt verwendet?
Hier kommt das LoGeoRef-Konzept ins Spiel. Fünf Stufen, von der Postadresse bis zur voll referenzierten Koordinatentransformation. Jede Stufe beschreibt, wie viel georäumliche Information in einer IFC-Datei steckt und über welche Entitäten sie transportiert wird.
Das klingt nach Theorie. In der Praxis entscheidet es darüber, ob Ihr Modell im Koordinatensystem des Auftraggebers landet oder im Nirgendwo.
Was ist LoGeoRef?
LoGeoRef steht für Level of Georeferencing. Das Konzept wurde 2019 von Christian Clemen und Hendrik Görne (HTW Dresden) als akademischer Vorschlag publiziert, um die Georeferenzierungsqualität in IFC-Dateien messbar zu machen. Es handelt sich nicht um einen offiziellen buildingSMART- oder ISO-Standard, sondern um eine Metrik, die sich in Fachkreisen als De-facto-Vokabular etabliert hat.
Clemen und Görne beschreiben den Zweck so: LoGeoRef soll eine gemeinsame Sprache liefern, die in BIM-Prozessen für die Beschreibung des Exchange Requirements (ER), des Employer's Information Requirements (EIR) und des BIM Execution Plan (BEP) verwendet werden kann.
Die fünf Stufen im Überblick
LoGeoRef 10: Postadresse
Die einfachste Form der Georeferenzierung. Das Modell enthält eine IfcPostalAddress, die einer IfcSite oder einem IfcBuilding zugewiesen ist. Die Adresse kann Strasse, Ort, Postleitzahl und Land umfassen.
LoGeoRef 20: Geografische Koordinaten auf IfcSite
IfcSite enthält die Attribute RefLatitude, RefLongitude und RefElevation. Die Koordinaten werden als Compound-Plane-Angle (Grad, Minuten, Sekunden, millionstel Sekunden) gespeichert.
LoGeoRef 30: IfcLocalPlacement der IfcSite
Die Position des obersten räumlichen Strukturelements (typischerweise IfcSite) wird direkt im IfcLocalPlacement abgelegt: X-, Y- und Z-Koordinaten plus Achsenrichtungen über IfcAxis2Placement3D. Voraussetzung ist, dass das Element keine Relativ-Platzierung zu einem anderen Element hat (PlacementRelTo leer).
LoGeoRef 40: WorldCoordinateSystem und TrueNorth
IfcGeometricRepresentationContext enthält WorldCoordinateSystem (WCS) und TrueNorth. Das WCS kann genutzt werden, um das Modell-Koordinatensystem relativ zum globalen Norden zu rotieren und zu verschieben.
LoGeoRef 50: IfcMapConversion und IfcProjectedCRS
Dies ist die höchste implementierte Stufe und die empfohlene Methode für eine vollständige Georeferenzierung in IFC. Zwei Entitäten arbeiten zusammen.
- • Name (z.B. CH1903+/LV95)
- • EPSG-Code (z.B. 2056)
- • Geodätischer Datum
- • Projektion und Längeneinheit
- • Eastings, Northings, OrthogonalHeight
- • XAxisAbscissa = cos(Winkel)
- • XAxisOrdinate = sin(Winkel)
- • Optionaler Scale-Faktor (Default 1.0)
IfcMapConversion verknüpft das IfcGeometricRepresentationContext mit dem IfcProjectedCRS. Das eigentliche Modell behält damit kleine, numerisch stabile Koordinaten, der Bezug zum nationalen System wird ausschliesslich über die Konversion hergestellt. LoGeoRef 50 ist die Grundvoraussetzung für eine korrekte BIM-GIS-Integration.
Erweiterungen in IFC 4.3
Mit IFC 4.3 (genauer: IFC4X3_ADD1) sind zwei zusätzliche Entitäten dazugekommen, die innerhalb von LoGeoRef 50 verwendet werden können und insbesondere für lineare Infrastruktur relevant sind.
Wann IfcRigidOperation die richtige Wahl ist
In der Praxis ist IfcRigidOperation häufig die saubere Lösung, nicht die schlechte Variante von IfcMapConversion. Sie kommuniziert explizit, dass nur ein Versatz nötig ist und keine Rotation oder Skalierung dazwischenliegt.
Voraussetzung in jedem Fall: Das Zielsystem muss zusätzlich über IfcProjectedCRS mit Name und EPSG-Code definiert sein. Ohne diese Angabe ist der Versatz nicht maschinell interpretierbar.
Vergleichstabelle der Stufen
Im Original-Paper diskutieren Clemen und Görne zusätzlich eine theoretische Stufe LoGeoRef 60 mit Ground Control Points. Sie ist nicht implementiert und spielt in der Praxis bisher keine Rolle.
Die häufigsten Fehler in der Praxis
Redundante Stufen: LoGeoRef 40 und LoGeoRef 50 gleichzeitig gesetzt, also Geo-Information sowohl im WCS als auch in der IfcMapConversion. Das erzeugt widersprüchliche Platzierungsinformationen. Welcher Mechanismus greift, hängt vom importierenden Tool ab und ist nicht vorhersagbar.
TrueNorth-Konflikt: TrueNorth in IfcGeometricRepresentationContext gesetzt und gleichzeitig eine Rotation in der IfcMapConversion. Beide Rotationen überlagern sich. Das Modell ist um den Differenzwinkel verdreht.
Vertauschte Achsen: XAxisAbscissa und XAxisOrdinate in IfcMapConversion sind vertauscht. Mathematisch korrekt gilt: XAxisAbscissa = cos(Winkel), XAxisOrdinate = sin(Winkel). Eine Verwechslung dreht das gesamte Modell um den doppelten Winkel.
Fehlender oder falscher EPSG-Code: IfcProjectedCRS enthält keinen oder einen ungültigen EPSG-Code. Das Ziel-Koordinatensystem ist damit nicht maschinell auflösbar. Für die Schweiz: EPSG 2056 (LV95).
IfcRigidOperation falsch eingesetzt: IfcRigidOperation ist die richtige Entität, wenn keine Rotation und keine Skalierung gegenüber dem Zielsystem nötig sind (siehe Abschnitt oben). Problematisch wird es, wenn ein Autorentool sie verwendet, obwohl das Modell-Koordinatensystem tatsächlich gegen Grid-Nord verdreht ist. Beim IFC4.3-Export aus Autodesk Civil 3D ist diese Konstellation aus der Praxis bekannt und in mehreren Autodesk-Support-Artikeln sowie Forenthreads dokumentiert. Da IfcRigidOperation per Spezifikation nur Translation in X, Y und Z abbildet, geht eine WCS-Verdrehung gegenüber Grid-Nord beim Export verloren, das Modell landet in nachgelagerten Viewern verschoben oder gegen Norden verdreht. Mit Civil 3D 2026 (IFC 4.3 Extension 2026-23) hat Autodesk die Konfiguration verbessert, eine Option, stattdessen IfcMapConversion mit Rotationsanteil zu erzwingen, fehlt aber weiterhin. Wer eine Verdrehung sauber abbilden muss, korrigiert die Datei aktuell nachträglich, etwa mit ifcgref oder IfcOpenShell.
Praktische Empfehlung für Schweizer Infrastrukturprojekte
Für lange Trassen, bei denen Massstabsverzerrungen eine Rolle spielen, lohnt sich die Verwendung von IfcMapConversionScaled mit separaten Skalierungsfaktoren für X, Y und Z innerhalb von LoGeoRef 50.
Quellen
Bimatic GmbH, Von der Basis zur Automation. bimatic.ch