> ## Content Index > Fetch the complete content index at: https://modelllogik.de/llms.txt > Use this file to discover other available public pages before exploring further. # Höhen in IFC — welche Zahl rechnet und welche nur erzählt - URL: https://modelllogik.de/welche-hoehe-rechnet/ - Published: 2026-10-23T12:40:01.000Z - Updated: 2026-10-23T13:12:30.000Z - Description: Ein Haus hat ein Dutzend Höhen, und eine IFC-Datei legt sie an verschiedenen Stellen ab. Schritt für Schritt: wo welche Höhe steht, welche davon ein Programm wirklich benutzt, und warum dasselbe Erdgeschoss zwei Zahlen haben kann. - Author: Andràs Marghescu - Tags: Fachartikel **Worum es geht: um die Höhe eines Gebäudes in einer IFC-Datei.** Gemeint ist nicht die Gebäudehöhe aus dem Baurecht, sondern etwas Alltäglicheres: Wie hoch liegt der Fußboden im Erdgeschoss, wie hoch die Bodenplatte, wie hoch die Decke darüber? **Das klingt einfach, und auf dem Plan ist es das auch.** Dort stehen ±0,00, OK FFB und OK RFB an jedem Schnitt, und wer Pläne liest, weiß, was sie bedeuten. In einer IFC-Datei stehen dieselben Höhen auch, aber an mehreren Stellen gleichzeitig, unter englischen Namen und mit verschiedenen Nullpunkten. Und nicht jede dieser Stellen hat dasselbe Gewicht. **Was auf dem Plan selbstverständlich ist, ist in IFC ganz schön verwickelt.** Dieser Text löst es vollständig auf, Schritt für Schritt, und zu jedem Schritt gibt es ein Bild. Kurz ist er deshalb nicht. Wer ihn bis zum Ende liest, kann vier Fragen beantworten: 1. Welche Höhen hat ein einfaches Haus, und von wo werden sie gezählt? 2. Wo legt eine IFC-Datei jede dieser Höhen ab? 3. Welche dieser Zahlen benutzt ein Programm, wenn es rechnet oder zeichnet, und welche liest es gar nicht? 4. Warum kann dasselbe Erdgeschoss in einer Datei zwei verschiedene Höhen haben, und beide sind richtig? **Zum Mitlesen gibt es eine Karte zum Ausdrucken**, zwei Seiten A4\. Vorn stehen alle Höhen dieses Textes in einer Leiter, jede viermal gezählt: gegen ±0,00, über NHN und vom Projektursprung aus, einmal auf P′ und einmal auf P. Hinten steht die Übersicht, welches Feld wo hängt und welches ein Programm benutzt. Wer sie neben den Text legt, behält die Zahlen im Blick. [Karte zum MitlesenHöhen in IFC · A4, zwei Seiten · zum Ausdruckent7\_karte\_hoehen\_zum\_mitlesen.pdf83 KBdownload-circle](https://modelllogik.de/content/files/2026/10/t7%5Fkarte%5Fhoehen%5Fzum%5Fmitlesen.pdf "Download") **Wie das geprüft wurde.** Was über die Norm gesagt wird, steht in der [Dokumentation von IFC 4.3.2](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/?ref=modelllogik.de), der im Oktober 2026 geltenden Fassung des Standards, und in der [Quelle](https://github.com/buildingSMART/IFC4.x-development?ref=modelllogik.de), aus der [buildingSMART](https://www.buildingsmart.org/?ref=modelllogik.de) diese Dokumentation erzeugt. Was über ein Programm gesagt wird, habe ich an zwei IFC-Dateien gemessen, die ich nur dafür angelegt habe: Wegwerfdateien im IFC-Format mit einem Gebäude, zwei Geschossen und frei gewählten Höhen, kein echtes Grundstück und kein echtes Projekt. Die Höhe von 500,00 Metern über dem Meer ist absichtlich so rund gewählt, dass niemand sie für eine echte hält. Gelesen hat die Dateien [IfcOpenShell](https://ifcopenshell.org/?ref=modelllogik.de), eine offene Programmbibliothek für IFC, in der Fassung 0.9.1a261019, gemessen am 23\. Oktober 2026. ## Schritt 1 · Das Problem Zuerst die Höhen, wie sie auf dem Plan stehen. Jeder, der Schnitte zeichnet, kennt die Kürzel: **OK FFB** für die Oberkante des fertigen Fußbodens, **OK RFB** für die Oberkante des Rohfußbodens, also des Rohbaus. ±0,00 liegt meist auf OK FFB im Erdgeschoss, und daneben steht, wie hoch ±0,00 über dem Meer liegt. ![Titel „Wo die Höhen im Haus liegen“, darunter „so, wie sie auf dem Plan stehen, Beispielzahlen frei gewählt, in der Höhe maßstäblich“. Links ein Schnitt durch ein zweigeschossiges Haus: Bodenplatte, darauf ein heller Streifen für den Fußbodenaufbau, zwei Wände, die Geschossdecke mit eigenem Fußbodenaufbau, oben angeschnittene Wände; im Raum das Wort Erdgeschoss. Links unten eine Geländelinie mit einem schwarzen Punkt P. Gestrichelte Linien führen von den Ebenen zu einer Liste rechts, Spalte „gegen ±0,00“: OK FFB OG (Fertigfußboden) plus 3,00; OK RFB OG (Rohdecke) plus 2,85; in Orange hervorgehoben ±0,00 gleich OK FFB EG, 0,00; OK RFB EG (Bodenplatte) minus 0,15; Vermessungspunkt P, vom Vermesser 499,55 über NHN, in Grau minus 0,45. In der Mitte rechts ein orange gerahmter Kasten: „Und wo liegt ±0,00? 500,00 m über dem amtlichen Höhenbezug (in Deutschland Normalhöhennull, NHN). Die Höhen am Haus zählen von ±0,00. P kommt vom Vermesser, in NHN.“ Unten ein Band: „So steht es auf jedem Plan. Die Frage ist, wo eine IFC-Datei OK FFB, OK RFB, ±0,00 und NHN ablegt.“](https://storage.ghost.io/c/df/a1/dfa16b2e-2024-4a5f-866f-818cf6baf53a/content/images/2026/10/t7-1_hoehen_im_haus.png) Fünf Ebenen eines einfachen Hauses, so wie sie auf dem Plan stehen: OK FFB und OK RFB je Geschoss, alle gezählt von ±0,00\. Nur der Vermessungspunkt P kommt in NHN vom Vermesser; aus ihm folgt, dass ±0,00 auf 500,00 m über NHN liegt. Das Bild zeigt einen Schnitt durch ein einfaches Haus mit zwei Geschossen, so beziffert, wie man es von einem Plan kennt. Von unten nach oben: - **Der Vermessungspunkt P im Gelände.** Ein Punkt, dessen Lage und Höhe der Vermesser kennt, etwa ein Grenzstein. Seine Höhe liefert der Vermesser über dem Meer: 499,55\. Das sind 45 Zentimeter unter ±0,00. - **OK RFB im Erdgeschoss:** die Oberkante der Bodenplatte, Beton ohne Estrich und Belag, bei −0,15. - **±0,00 = OK FFB im Erdgeschoss.** Zwischen Bodenplatte und fertigem Fußboden liegen 15 Zentimeter Fußbodenaufbau: Dämmung, Estrich, Belag. - **OK RFB im Obergeschoss:** die Oberkante der Rohdecke über dem Erdgeschoss, bei +2,85. - **OK FFB im Obergeschoss:** wieder 15 Zentimeter Aufbau darüber, also +3,00. **Die Höhen am Haus zählen alle von ±0,00\. P ist die Ausnahme:** Seine Höhe kommt vom Vermesser, und der gibt sie über dem amtlichen Höhenbezug an. Das ist in Deutschland Normalhöhennull, kurz NHN, umgangssprachlich die Höhe über dem Meer. Die −0,45 im Bild sind aus dieser Höhe zurückgerechnet. Umgekehrt legt P fest, wo ±0,00 selbst liegt: 45 Zentimeter über P, also auf 500,00 Metern über NHN. **Das Problem beginnt, wenn diese Höhen in ein IFC-Modell sollen.** Dort gibt es kein Feld, das „OK FFB“ oder „OK RFB“ heißt. Wer in einer IFC-Datei nach Höhen sucht, findet stattdessen englische Namen, und die meisten davon beginnen mit demselben Wort: - `Elevation` — die Höhe des Geschosses, als Attribut - `ElevationOfRefHeight` — die Höhe von ±0,00 über NHN - `ElevationOfTerrain` — die Geländehöhe am Gebäude - `ElevationOfSSLRelative` — OK RFB, die Oberkante des Rohfußbodens - `ElevationOfFFLRelative` — OK FFB, die Oberkante des Fertigfußbodens - `ElevationWithFlooring` — OK FFB im Raum - `RefElevation` — die ungefähre Höhe des Grundstücks über dem Meer - `OrthogonalHeight` — die Höhe des Projektursprungs über NHN - und dazu die Lage jedes Objekts, die gar keinen Höhennamen trägt Sie hängen an verschiedenen Stellen der Datei: am Projekt, am Grundstück, am Gebäude, am Geschoss, am Raum. Manche zählen von ±0,00, manche vom Meer, manche von einem Punkt, den es auf dem Plan gar nicht gibt. Und einige davon benutzt ein Programm beim Rechnen, andere liest es nicht einmal. Genau so kam die Frage in meinen Unterricht. Auszubildende wollten in ihr Modell eintragen, was sie vom Plan kennen: das Geschoss, OK RFB, OK FFB und ±0,00\. Sie standen vor einer Liste von Feldern, die fast alle „Elevation“ heißen, und fragten: **Welches Feld ist OK RFB? Welches ist OK FFB? Wo gehört ±0,00 hin, und wo die Höhe über NHN?** Dieser Text beantwortet genau das, Feld für Feld. Dafür braucht es vorher noch einen Gedanken. ## Schritt 2 · Eine Höhe braucht einen Nullpunkt Eine Höhe ist nur dann eine Angabe, wenn man weiß, von wo aus gezählt wird. „−0,15“ heißt: 15 Zentimeter unter ±0,00\. „499,85“ heißt: 499,85 Meter über NHN. Beide Zahlen meinen dieselbe Bodenplatte. Sie haben nur verschiedene Nullpunkte. **In einer IFC-Datei gibt es drei Nullpunkte für die Höhe.** Zwei davon kennt jeder aus der Planung, der dritte kommt erst mit dem Modell dazu. | Nullpunkt | Was er ist | Wer ihn festlegt | Die Bodenplatte von dort aus | | ------------------- | --------------------------- | --------------------- | ---------------------------- | | **NHN** | der amtliche Höhenbezug | die Landesvermessung | 499,85 | | **±0,00** | die Bezugshöhe des Gebäudes | der Planer | −0,15 | | **Projektursprung** | der Punkt 0/0/0 des Modells | wer das Modell anlegt | hängt davon ab, wo er liegt | **Der Projektursprung ist der neue Nullpunkt.** Jedes Modell hat einen Punkt, an dem x, y und z gleich null sind. Von dort aus misst das Programm alles, was es zeichnet. Wo dieser Punkt in der Welt liegt, legt man bei der Georeferenzierung fest, also dann, wenn man dem Modell sagt, wo es auf der Erde steht. Wie das für die Lage und die Drehung funktioniert, steht im Beitrag [Georeferenzierung in IFC — der Nordwinkel steht nicht in der Datei](https://modelllogik.de/der-winkel-steht-nicht-in-der-datei/). Hier geht es nur um die Höhe. **Ein Punkt ist etwas anderes als eine Ebene.** Auf diesem Unterschied beruht der Rest des Textes. ±0,00 ist eine *Ebene*: eine waagerechte Fläche in einer bestimmten Höhe, die durch das ganze Gebäude läuft. Sie hat eine Höhe, aber keinen bestimmten Ort. Der Projektursprung dagegen ist ein *Punkt*. Er hat eine Lage im Grundriss, x und y, und dazu eine Höhe, z. Lage und Höhe eines Punktes lassen sich getrennt festlegen. **Für die Lage im Grundriss** legt man den Projektursprung gern auf den Vermessungspunkt P, weil der Vermesser dessen Koordinaten liefert. **Für die Höhe** hat man die Wahl. Man kann die Höhe von P übernehmen, also 499,55\. Oder man lässt den Punkt, wo er ist, und hebt ihn lotrecht an, bis er die Ebene ±0,00 trifft. Diesen angehobenen Punkt nenne ich **P′**, gesprochen „P Strich“. P′ ist derselbe Punkt wie P, nur seine Höhe ist eine andere: 500,00 statt 499,55. ![Titel „P und P′: dieselbe Lage, zwei Höhen“, darunter „Beispielzahlen frei gewählt, um ±0,00 maßstäblich, NHN unterbrochen gezeichnet“. Links ein Schnitt durch das Erdgeschoss eines Hauses. Links neben dem Haus im Gelände ein schwarzer Punkt P. Eine gestrichelte orange Linie mit der Beschriftung „Ebene ±0,00“ läuft in Höhe des fertigen Fußbodens hinter dem ganzen Haus durch. Lotrecht über P liegt auf dieser Linie ein orangefarbener Punkt P′; zwischen beiden ein Maß „0,45 m“. Ganz unten, unterbrochen gezeichnet, die Linie „NHN (Höhe 0,00 über dem Meer)“; von dort führen zwei Maßpfeile nach oben, zu P mit „499,55“ und zu P′ mit „500,00“. Rechts zwei Karten. Orange: „P′ — derselbe Punkt, auf ±0,00. Lotrecht über P, in der Ebene ±0,00. Höhe: 500,00 über NHN. Dieselbe Lage wie P, nur die Höhe ist anders: P, um 0,45 m angehoben, bis er die Ebene ±0,00 trifft (OK FFB im Erdgeschoss).“ Darunter: „P — der vermessene Punkt. Im Gelände, etwa ein Grenzstein. Höhe: 499,55 über NHN. Lage und Höhe liefert der Vermesser.“ Unten ein Band: „Der Projektursprung 0/0/0 liegt entweder auf P oder auf P′. Für die Lage ist das gleich. Für die Höhe nicht: Der Unterschied sind genau die 0,45 m.“](https://storage.ghost.io/c/df/a1/dfa16b2e-2024-4a5f-866f-818cf6baf53a/content/images/2026/10/t7-5_p_und_pstrich.png) P ist der vermessene Punkt im Gelände, seine Höhe über NHN kommt vom Vermesser. ±0,00 ist eine Ebene durch das ganze Haus. P′ ist derselbe Punkt, angehoben bis in diese Ebene: dieselbe Lage, 0,45 m höher. Der Projektursprung liegt auf einem der beiden Punkte; für die Lage ist das gleich, für die Höhe nicht. Ob der Ursprung auf P liegt oder auf P′, ist für die Lage im Grundriss gleichgültig. Für die Höhe ist es der ganze Unterschied. Dazu kommt Schritt 6\. **Bis dahin liegt der Projektursprung in diesem Text auf P′, also auf ±0,00.** Dann liegt der Projektursprung genau in der Ebene ±0,00\. Jede Höhe, die vom Ursprung aus gezählt wird, ist damit zugleich eine Höhe gegen ±0,00, und es gibt vorerst nur zwei Nullpunkte, um die man sich kümmern muss. ## Schritt 3 · Wie IFC ein Gebäude ordnet Bevor es um die einzelnen Felder geht, ein kurzer Blick darauf, wie eine IFC-Datei ein Gebäude überhaupt beschreibt. **Die Gliederung.** Eine IFC-Datei ordnet ein Bauwerk wie eine Ordnerstruktur: ganz oben das Projekt, darunter das Grundstück, darunter das Gebäude, darunter die Geschosse, darunter die Räume. In IFC heißen diese Ebenen [IfcProject](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcProject.htm?ref=modelllogik.de), [IfcSite](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcSite.htm?ref=modelllogik.de), [IfcBuilding](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcBuilding.htm?ref=modelllogik.de), [IfcBuildingStorey](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcBuildingStorey.htm?ref=modelllogik.de) und [IfcSpace](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcSpace.htm?ref=modelllogik.de). Bauteile wie Wände und Decken hängen an dem Geschoss, in dem sie stehen. **Zwei Arten von Angaben.** An jedem dieser Objekte gibt es zwei Arten von Information, und der Unterschied ist für diesen Text entscheidend. - **Die Lage.** In IFC heißt sie *Platzierung* ([ObjectPlacement](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcObjectPlacement.htm?ref=modelllogik.de)). Sie sagt, wo ein Objekt im Modell sitzt, mit x, y und z, gemessen vom Projektursprung. Die Platzierung ist Geometrie: Wenn man sie ändert, bewegt sich etwas. *Lage* heißt ab hier also mehr als in Schritt 2: nicht nur x und y im Grundriss, sondern auch die Höhe z. - **Die Beschreibungen.** Das sind *Attribute*, die fest zum Objekt gehören, und *Property Sets*, Gruppen von Merkmalen, die man an ein Objekt anhängt. Wer den Unterschied zwischen beiden genauer wissen will: Er steht im Beitrag [Ein Modell lässt sich nicht attribuieren](https://modelllogik.de/attribut-und-eigenschaft/). Für diesen Text reicht: **Beschreibungen bewegen nichts.** Eine Zahl in einem Property Set kann sagen, das Geschoss liege auf −0,15, und das Geschoss liegt trotzdem dort, wo seine Platzierung es hinsetzt. Mit diesen beiden Gedanken, drei Nullpunkte und zwei Arten von Angaben, lässt sich jetzt jede Höhe aus Schritt 1 an ihren Platz in der Datei bringen. ## Schritt 4 · Wo IFC die Höhen ablegt ![Titel „Wo IFC die Höhen ablegt“, darunter „derselbe Schnitt, Projektursprung auf ±0,00, in Klammern: wo das Feld hängt“. Derselbe Hausschnitt wie in Abbildung 1. Links unten der Punkt P im Gelände, lotrecht darüber auf Höhe des Fußbodens im Erdgeschoss ein orangefarbenes Achsenkreuz, der Projektursprung. Ein orange gerahmter Kasten links: „Projektursprung, 0/0/0 des Modells, hier auf ±0,00 über P. IfcMapConversion.OrthogonalHeight = 500,00, Höhe über NHN.“, der Feldname in Orange. Im Raum: „Raum (IfcSpace), OK FFB des Raums: ElevationWithFlooring“. Rechts in der Mitte eine Legende: Orange „Lage, Platzierung, Kartenumrechnung“, Blau „Beschreibung, Attribut, Property Set“. Rechts an den Ebenen, die Platzierungen in Orange, alle übrigen Felder in Blau: OK FFB OG plus 3,00, ElevationOfFFLRelative (Pset am OG). OK RFB OG gleich Geschoss OG plus 2,85, Platzierung des Geschosses OG, z, und ElevationOfSSLRelative (Pset am OG). ±0,00 gleich OK FFB EG, ElevationOfRefHeight = 500,00 (Pset am Gebäude), ElevationOfFFLRelative = 0,00 (Pset am EG). OK RFB EG gleich Geschoss EG minus 0,15, Platzierung des Geschosses EG, z, und ElevationOfSSLRelative (Pset am EG). Unten ein Band: „Das Geschoss sitzt auf OK RFB. OK FFB steht im Property Set des Geschosses und am Raum. ±0,00 steht am Gebäude, die Höhe über NHN am Projektursprung.“](https://storage.ghost.io/c/df/a1/dfa16b2e-2024-4a5f-866f-818cf6baf53a/content/images/2026/10/t7-2_wo_ifc_die_hoehen_ablegt.png) Dieselben Ebenen in der IFC-Datei: Die Höhe über NHN steht am Projektursprung, ±0,00 am Gebäude, das Geschoss sitzt mit seiner Platzierung auf OK RFB, OK RFB und OK FFB stehen im Property Set des Geschosses, OK FFB zusätzlich am Raum. Das Bild zeigt denselben Schnitt wie in Schritt 1\. An jeder Ebene steht jetzt, in welchem Feld der IFC-Datei sie zu finden ist. Die Farben trennen die beiden Arten von Angaben aus Schritt 3: **orange die Lage**, also Platzierung und Kartenumrechnung, **blau die Beschreibungen**, also Attribute und Property Sets. Die Felder im Einzelnen, von außen nach innen: ### Die Höhe über NHN: an der Kartenumrechnung Ganz oben in der Datei, noch vor allen Gebäuden, steht die Georeferenzierung. Sie besteht aus zwei Einträgen. [IfcProjectedCRS](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcProjectedCRS.htm?ref=modelllogik.de) nennt das Koordinatensystem und den Höhenbezug, für Deutschland etwa [EPSG:7837](https://epsg.io/7837?ref=modelllogik.de) für das Höhennetz von 2016\. [IfcMapConversion](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcMapConversion.htm?ref=modelllogik.de), die *Kartenumrechnung*, sagt, wie man vom Modell auf die Karte kommt. Für die Höhe hat die Kartenumrechnung genau ein Feld: **`OrthogonalHeight`**. Darin steht, **auf welcher Höhe über dem Meer der Projektursprung liegt**, genauer: über NHN. Im Beispiel liegt der Projektursprung auf P′, und P′ liegt 500,00 Meter über NHN. Also steht dort **500,00**. Daraus folgt eine Rechnung, die für jeden Punkt im Modell gilt: > **Höhe über NHN = `OrthogonalHeight` \+ z im Modell** Die Bodenplatte liegt im Modell bei z = −0,15, also bei 500,00 − 0,15 = 499,85 über NHN. Die Dokumentation von [IfcMapConversion](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcMapConversion.htm?ref=modelllogik.de) hält dazu fest, dass die senkrechte Achse des Modells immer parallel zur senkrechten Achse der Karte bleibt. Eine Drehung des Modells ändert an der Höhe also nichts. *Ein Wort zum Namen:* `OrthogonalHeight` klingt nach der „orthometrischen Höhe“ der Vermessungsingenieure. Damit hat das Feld nichts zu tun. Es ist schlicht die Verschiebung des Ursprungs nach oben oder unten. **Und am Grundstück: eine Näherung.** Am Grundstück, dem [IfcSite](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcSite.htm?ref=modelllogik.de), gibt es noch ein Feld mit einer Höhe über dem Meer: `**RefElevation**`. Zusammen mit geografischer Länge und Breite sagt es ungefähr, wo der Ursprung des Grundstücks auf der Erde liegt. Die Norm führt diese drei Angaben nur noch, damit ältere Dateien lesbar bleiben, und nennt sie ausdrücklich eine Näherung, gut genug etwa für eine Verschattungsstudie. Für eine genaue Höhe verweist sie auf die Kartenumrechnung. Abgekündigt ist `RefElevation` nicht, aber **wer die Kartenumrechnung setzt, braucht es nicht.** Im Quelltext von IfcOpenShell und Bonsai kommt es nicht vor. ### ±0,00: am Gebäude, im Property Set Welche Höhe über NHN ±0,00 hat, steht am Gebäude, im Property Set **`Pset_BuildingCommon`**, im Merkmal **`ElevationOfRefHeight`**. Im Beispiel: **500,00**. Daneben steht `ElevationOfTerrain`, der tiefste Geländepunkt am Gebäudeumriss. Bis IFC 4 war ihr Platz ein Attribut direkt am Gebäude. Seit IFC 4.3 sind diese Attribute **abgekündigt**: Sie stehen noch im Standard, sollen aber nicht mehr benutzt werden. Ihr Platz ist seitdem das Property Set ([IfcBuilding](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcBuilding.htm?ref=modelllogik.de), [Pset\_BuildingCommon](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/Pset%5FBuildingCommon.htm?ref=modelllogik.de)). **Fällt etwas auf?** Im Beispiel steht zweimal 500,00: in der Kartenumrechnung und am Gebäude. Das ist kein Zufall. Es liegt daran, dass der Projektursprung in Schritt 2 von P nach P′ geschoben wurde, lotrecht nach oben bis in die Ebene ±0,00\. Seitdem liegt der Ursprung auf derselben Höhe wie ±0,00, und deshalb haben beide dieselbe Höhe über NHN. Hier zeigt sich, warum sich dieser Kniff lohnt: Die beiden Zahlen müssen gleich sein, und wer sie vergleicht, merkt sofort, wenn eine davon nicht stimmt. Die beiden Felder sagen trotzdem Verschiedenes. Das eine sagt, wo der Ursprung liegt, das andere, wo ±0,00 liegt. Läge der Ursprung auf P, stünde in der Kartenumrechnung 499,55 und am Gebäude weiter 500,00\. Darum geht es in Schritt 6. ### Das Geschoss: in der Platzierung, und zwar auf der Rohdecke Jedes Geschoss ist ein [IfcBuildingStorey](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcBuildingStorey.htm?ref=modelllogik.de) und hat eine Platzierung. **Deren z-Wert ist die Höhe des Geschosses.** Sie zählt vom Projektursprung. Aber wo genau sitzt ein Geschoss: auf dem Rohbau oder auf dem fertigen Fußboden? Die Antwort steht in der Dokumentation an einer Stelle, an der man sie nicht sucht, nämlich nicht beim Geschoss, sondern beim Raum. Die Erläuterung zur Höhengrafik von [IfcSpace](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcSpace.htm?ref=modelllogik.de) sagt sinngemäß: Die Höhe des Raums ist die Oberkante der Rohdecke, und sie ist gleich der Höhe des Geschosses. Auch die Geschosshöhe `GrossHeight` aus [Qto\_BuildingStoreyBaseQuantities](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/Qto%5FBuildingStoreyBaseQuantities.htm?ref=modelllogik.de) zählt von Rohdecke zu Rohdecke. **Das Geschoss sitzt also auf dem Rohbau.** Im Beispiel: Erdgeschoss bei z = −0,15, Obergeschoss bei z = +2,85. **Übersetzt heißt das: Das Geschoss in IFC liegt auf OK RFB, nicht auf OK FFB.** Wer das Erdgeschoss auf die Oberkante der Bodenplatte legt, liegt richtig, auch wenn dort −0,15 steht und nicht ±0,00. ### Roh- und Fertigfußboden: im Property Set des Geschosses Hier stehen endlich die beiden Höhen, die man vom Plan kennt. Seit IFC 4.3 gibt es dafür zwei Merkmale im Property Set [Pset\_BuildingStoreyCommon](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/Pset%5FBuildingStoreyCommon.htm?ref=modelllogik.de): - **`ElevationOfSSLRelative`** ist **OK RFB**. SSL steht für *structural slab level*, die Oberkante der tragenden Platte. Im Erdgeschoss −0,15, im Obergeschoss +2,85. - **`ElevationOfFFLRelative`** ist **OK FFB**. FFL steht für *finished floor level*, die Oberkante des fertigen Fußbodens. Im Erdgeschoss 0,00, im Obergeschoss +3,00. Beide zählen von ±0,00\. Und beide tragen in der Dokumentation denselben Satz: **Widerspricht der Wert der Geometrie, gilt die Geometrie.** Das ist der erste Hinweis darauf, was rechnet und was nicht. ### Der fertige Fußboden: auch am Raum Der fertige Fußboden gehört nach IFC eigentlich zum Raum. Am [IfcSpace](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcSpace.htm?ref=modelllogik.de) gibt es dafür das Attribut `**ElevationWithFlooring**`, die Höhe des fertigen Fußbodens in diesem Raum. Liegen in einem Raum verschiedene Beläge oder hat der Boden Gefälle, nimmt man den Mittelwert. Die Dicke des Aufbaus steht in der Mengenangabe `FinishFloorHeight` aus [Qto\_SpaceBaseQuantities](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/Qto%5FSpaceBaseQuantities.htm?ref=modelllogik.de). Die Beläge selbst können als eigene Objekte am Raum hängen. **OK FFB steht also im Property Set des Geschosses und am Raum, nicht in der Lage des Geschosses.** ### Und ein Attribut, das man besser leer lässt Bleibt ein Feld, das man nach dem Namen zuerst für die Geschosshöhe hält: das Attribut **`Elevation`** direkt am Geschoss, „die Höhe der Geschossbasis gegen ±0,00“. Ein Programm kann es schreiben und lesen, und es klingt wie genau die Zahl, die man sucht. **Die** [**Norm**](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcBuildingStorey.htm?ref=modelllogik.de) **sagt dazu zwei Dinge.** Unter dem Attribut steht ein Hinweis: Die Lage des Geschosses bestimmt die Platzierung, **der Wert von `Elevation` dient nur der Information.** Und darunter, rot hervorgehoben: **Seit IFC 4.3 ist das Attribut abgekündigt.** An seine Stelle treten die beiden Merkmale aus dem Property Set. Vermerkt ist die Abkündigung allerdings nur im Text der Dokumentation, nicht im maschinenlesbaren Schema. Das ist bei buildingSMART bekannt und als [Issue #1190](https://github.com/buildingSMART/IFC4.x-development/issues/1190?ref=modelllogik.de) offen. ### Die Übersicht Alle Felder dieses Schritts in einer Tabelle, links die Angabe vom Plan, mit dem Projektursprung auf ±0,00: | auf dem Plan | Feld in IFC | hängt an | gezählt von | Wert | | ---------------------------------- | ---------------------- | ------------------------- | --------------- | ----------- | | Höhe des Projektursprungs über NHN | OrthogonalHeight | Kartenumrechnung | NHN | 500,00 | | *(Höhe des Grundstücks, Näherung)* | RefElevation | Grundstück | Meer | nicht nötig | | ±0,00 über NHN | ElevationOfRefHeight | Gebäude, Property Set | NHN | 500,00 | | Geschoss EG = OK RFB EG | Platzierung, z | Geschoss EG | Projektursprung | −0,15 | | OK RFB EG | ElevationOfSSLRelative | Geschoss EG, Property Set | ±0,00 | −0,15 | | OK FFB EG | ElevationOfFFLRelative | Geschoss EG, Property Set | ±0,00 | 0,00 | | OK FFB im Raum | ElevationWithFlooring | Raum | ±0,00 | 0,00 | | Geschoss OG = OK RFB OG | Platzierung, z | Geschoss OG | Projektursprung | +2,85 | | OK RFB OG | ElevationOfSSLRelative | Geschoss OG, Property Set | ±0,00 | +2,85 | | OK FFB OG | ElevationOfFFLRelative | Geschoss OG, Property Set | ±0,00 | +3,00 | | *(Geschosshöhe, abgekündigt)* | Elevation | Geschoss | ±0,00 | besser leer | *Zu `ElevationWithFlooring`: Dass es von ±0,00 zählt, sagt die Erläuterung zur Höhengrafik des Raums. Die Beschreibung des Attributs selbst sagt es nicht.* ## Schritt 5 · Welche Zahl rechnet In der Tabelle stehen elf Felder. Ein Programm, das ein Modell zeichnet oder mit ihm rechnet, braucht davon nur zwei. **„Rechnen“ heißt hier:** Das Programm setzt Geometrie an die richtige Stelle, zeichnet eine Höhenkote in einen Schnitt, rechnet eine Höhe über NHN aus. **„Erzählen“ heißt:** Das Feld steht in der Datei, und wer es liest, erfährt etwas. Aber kein Bauteil bewegt sich, wenn man es ändert. Was die Norm dazu sagt, steht schon oben: Bei den Merkmalen für Roh- und Fertigfußboden gilt im Zweifel die Geometrie, das Geschossattribut dient nur der Information. Ob ein Programm sich daran hält, sagt die Norm nicht. Das habe ich gemessen. ### Der Aufbau der Messung Die erste IFC-Testdatei, **Datei A**, ist das Haus aus Schritt 1, mit dem Projektursprung auf ±0,00\. Kartenumrechnung 500,00, Geschoss EG auf −0,15, Geschoss OG auf +2,85, alle Property Sets gesetzt. Zwei Dinge sind absichtlich anders: - Beim Obergeschoss steht im Attribut `Elevation` eine **falsche Zahl**: +2,70 statt +2,85. - Es gibt ein drittes Geschoss **ohne jede Platzierung**, nur mit dem Attribut +5,85. Die Datei wurde im Schema `IFC4X3_ADD2` geschrieben, gespeichert und danach neu eingelesen. **Gelesen wird aus der geschriebenen Datei**, nicht aus dem Speicher des Programms, das sie geschrieben hat. ### Das Ergebnis Für die Höhe eines Geschosses hat IfcOpenShell eine eigene Funktion. Sie gibt zurück: | Geschoss | Platzierung z | Attribut Elevation | die Funktion liefert | | ---------------- | ------------- | ------------------ | -------------------- | | EG | −0,15 | −0,15 | **−0,15** | | OG | +2,85 | +2,70 (falsch) | **+2,85** | | ohne Platzierung | — | +5,85 | **+5,85** | **Das falsche Attribut fällt nicht auf.** Für das Obergeschoss kommt die Zahl aus der Platzierung, die +2,70 tauchen nirgends auf. Kein Hinweis, keine Warnung. Die Funktion tut, was ihre Beschreibung im Quelltext sagt: Die Höhe steht in der Platzierung, das Attribut ist der Rückfall ([ifcopenshell/util/placement.py](https://github.com/IfcOpenShell/IfcOpenShell/blob/a298d3489419a06636c5f4b423b2fc9c1ceb7c65/src/ifcopenshell-python/ifcopenshell/util/placement.py?ref=modelllogik.de#L131-L143), `get_storey_elevation`, Zeilen 131 bis 143 der installierten Fassung). **Der Rückfall greift wirklich.** Das Geschoss ohne Platzierung bekommt seine +5,85 aus dem Attribut. Es kommt also an die Reihe, aber nur, wenn sonst nichts da ist. **Und die Höhe über NHN** ergibt sich für beide Geschosse aus Kartenumrechnung plus Platzierung: 499,85 und 502,85. ### Was Bonsai damit macht [Bonsai](https://bonsaibim.org/?ref=modelllogik.de) ist ein BIM-Programm, das auf [IfcOpenShell](https://ifcopenshell.org/?ref=modelllogik.de) aufbaut. Ich habe in seinem Quelltext nachgesehen, woher es die Höhen nimmt, die es selbst erzeugt: - **Das Höhenfeld in der Geschossliste** schreibt die Platzierung, nicht das Attribut ([bonsai/bim/module/spatial/prop.py](https://github.com/IfcOpenShell/IfcOpenShell/blob/a298d3489419a06636c5f4b423b2fc9c1ceb7c65/src/bonsai/bonsai/bim/module/spatial/prop.py?ref=modelllogik.de#L97-L98), `update_elevation`, Zeilen 97 und 98 der installierten Fassung). - **Die Geschosskote in einem Schnitt** sitzt auf dem z der Platzierung ([bonsai/tool/drawing.py](https://github.com/IfcOpenShell/IfcOpenShell/blob/a298d3489419a06636c5f4b423b2fc9c1ceb7c65/src/bonsai/bonsai/tool/drawing.py?ref=modelllogik.de#L1721), Zeile 1721) und wird als „RL“ mit Vorzeichen beschriftet ([svgwriter.py](https://github.com/IfcOpenShell/IfcOpenShell/blob/a298d3489419a06636c5f4b423b2fc9c1ceb7c65/src/bonsai/bonsai/bim/module/drawing/svgwriter.py?ref=modelllogik.de#L435-L442), Zeilen 435 bis 442). *RL* steht für *reduced level*, eine Höhe gegen einen Bezugspunkt. Der Bezugspunkt ist hier der Projektursprung. - **Eine Höhe über NHN in einer Beschriftung** ist z der Platzierung plus `OrthogonalHeight` ([bonsai/bim/module/drawing/data.py](https://github.com/IfcOpenShell/IfcOpenShell/blob/a298d3489419a06636c5f4b423b2fc9c1ceb7c65/src/bonsai/bonsai/bim/module/drawing/data.py?ref=modelllogik.de#L650-L670), Zeilen 650 bis 670). - **Die Property Sets für Roh- und Fertigfußboden und das Attribut am Raum** kommen im Quelltext von Bonsai und IfcOpenShell nirgends vor. `ElevationOfRefHeight` kommt in Bonsai ebenfalls nicht vor. Für die Praxis heißt das: Die Geschosskote, die das Programm in einen Schnitt schreibt, zeigt OK RFB, weil das Geschoss dort liegt, im Beispiel „RL −0.150“. OK FFB aus dem Property Set erscheint in keiner automatisch erzeugten Kote, weil das Programm dieses Feld beim Zeichnen nicht liest. Wer im Plan beide Koten sehen will, muss die zweite selbst setzen. ![Titel „Was ein lesendes Programm mit den Höhen tut“, darunter „gemessen an IfcOpenShell, gelesen im Quelltext von Bonsai, Fassung 0.9.1a261019, 23.10.2026“. Links zwei Gruppen von Kästen. Oben, orange gerahmt und mit „RECHNET“ überschrieben: „IfcMapConversion.OrthogonalHeight, Höhe des Projektursprungs über dem Höhenbezug“ und „Platzierung des Geschosses, z-Wert des ObjectPlacement, vom Projektursprung aus“. Darunter, mit „ERZÄHLT“ überschrieben, vier blau gerahmte Kästen: „IfcBuildingStorey.Elevation, gegen ±0,00, abgekündigt seit IFC 4.3.0.0“, „Pset_BuildingStoreyCommon, ElevationOfSSLRelative, ElevationOfFFLRelative“, „Pset_BuildingCommon, ElevationOfRefHeight, ElevationOfTerrain“ und „IfcBuilding.ElevationOfRefHeight, abgekündigt seit IFC 4.3.0.0“. Rechts, mit „AUSGABE“ überschrieben, drei petrolfarben gerahmte Kästen: „Höhe über dem Bezug, in Beschriftungen: z plus OrthogonalHeight“, „Geschosskote im Schnitt, RL auf dem z der Platzierung“ und „Geschosshöhe, aus der Platzierung, sonst aus Elevation“. Durchgezogene Pfeile führen von OrthogonalHeight zur Höhe über dem Bezug und von der Platzierung zu allen drei Ausgaben. Vom Kasten Elevation führt ein gestrichelter Pfeil zur Geschosshöhe, beschriftet „nur, wenn das Geschoss keine Platzierung hat“. Die unteren drei Kästen sind mit einer Klammer zusammengefasst: „von keiner dieser Ausgaben gelesen. Volltextsuche im Quelltext beider Pakete: keine Stelle, die mit diesen Feldern rechnet“. Unten ein Band: „Die Lage rechnet. Das Attribut ist nur Rückfall, die Property Sets erzählen. Ein falscher Wert in einem erzählenden Feld fällt hier nie auf, erst im nächsten Programm, das ihn liest.“](https://storage.ghost.io/c/df/a1/dfa16b2e-2024-4a5f-866f-818cf6baf53a/content/images/2026/10/t7-3_rechnet_und_erzaehlt.png) Was ein lesendes Programm mit den Höhenfeldern tut, gemessen an IfcOpenShell und im Quelltext von Bonsai gelesen: Kartenumrechnung und Platzierung gehen in jede Rechnung ein, das Geschossattribut nur als Rückfall, die Property Sets nirgends. Das Bild fasst Schritt 5 zusammen. Links die Felder, rechts das, was ein Programm daraus macht. Nur zwei Felder führen zu einer Ausgabe: die Kartenumrechnung und die Platzierung. Das Geschossattribut führt nur dann zur Geschosshöhe, wenn keine Platzierung da ist. Die übrigen Felder führen nirgendwohin. > **Die Lage rechnet. Attribute und Property Sets erzählen.** Das heißt nicht, dass man die erzählenden Felder weglassen soll. Sie sind die Stelle, an der ein Mensch oder ein anderes Programm erfährt, wo der fertige Fußboden liegt. Es heißt nur: **Ein falscher Wert in einem erzählenden Feld fällt im eigenen Programm nie auf.** Er fällt erst im nächsten Programm auf, das ihn liest. ## Schritt 6 · Der Stolperstein: Wo liegt der Projektursprung? Bis hierher lag der Projektursprung auf ±0,00, auf dem Punkt P′. Das ist bequem, aber nicht vorgeschrieben. Viele Projekte legen den Ursprung auf den Vermessungspunkt P, weil man dort Lage und Höhe vom Vermesser bekommt. Was ändert sich dann? Dafür gibt es die zweite IFC-Testdatei, **Datei B**. Sie beschreibt dasselbe Haus am selben Ort, alle Werte richtig, nur liegt der Ursprung jetzt auf P im Gelände, 45 Zentimeter unter ±0,00. ![Titel „Wo liegt der Projektursprung?“, darunter „dasselbe Erdgeschoss, derselbe Ort, nur der Punkt 0/0/0 des Modells ist ein anderer“. Zwei gleiche Felder nebeneinander, jedes mit einem Ausschnitt: Bodenplatte, Fußbodenaufbau, zwei Wandstummel, links davon die Geländelinie mit dem Punkt P. Linkes Feld, Überschrift in Orange „Ursprung auf ±0,00 (P′)“: das Achsenkreuz 0/0/0 sitzt lotrecht über P auf Höhe des Fußbodens. Darunter: OrthogonalHeight 500,00, Platzierung des EG (z) minus 0,15, Attribut Elevation des EG minus 0,15; dann „Beide Zahlen gleich. Platzierung und Attribut zählen vom selben Punkt.“ Rechtes Feld, Überschrift in Blau „Ursprung auf dem Punkt P“: das Achsenkreuz sitzt auf P im Gelände. Darunter: OrthogonalHeight 499,55, Platzierung des EG (z) plus 0,30, Attribut Elevation des EG minus 0,15; dann „Zwei verschiedene Zahlen. Die Platzierung zählt von P, das Attribut von ±0,00. Beide sind richtig.“ Unten ein Band: „Über NHN liegt die Oberkante der Bodenplatte in beiden Fällen auf 499,85. 500,00 minus 0,15 = 499,85 und 499,55 plus 0,30 = 499,85.“](https://storage.ghost.io/c/df/a1/dfa16b2e-2024-4a5f-866f-818cf6baf53a/content/images/2026/10/t7-4_ursprung_p_oder_pstrich.png) Derselbe Ort, zwei Ursprünge: Liegt der Projektursprung auf ±0,00, haben Platzierung und Attribut dieselbe Zahl. Liegt er auf dem Vermessungspunkt P, gehen sie auseinander, und beide sind richtig. **Was sich ändert:** - **Die Kartenumrechnung.** Der Ursprung liegt jetzt tiefer, also steht in `OrthogonalHeight` die Höhe von P: **499,55**. - **Die Platzierung des Geschosses.** Sie zählt vom Ursprung, und der liegt jetzt unter dem Geschoss. Die Oberkante der Bodenplatte liegt 30 Zentimeter über P, also **+0,30**. **Was gleich bleibt:** - **Alles, was von ±0,00 zählt.** Das Attribut `Elevation` und die Property Sets sagen weiter **−0,15** für das Erdgeschoss. Sie zählen ja nicht vom Ursprung. - **Die Höhe über NHN.** 499,55 + 0,30 = 499,85\. Dieselbe Zahl wie in Datei A, auf den Millimeter. So hat es die Messung auch geliefert. **Dasselbe Erdgeschoss hat jetzt zwei Zahlen in derselben Datei: +0,30 und −0,15\. Beide sind richtig.** Sie haben nur verschiedene Nullpunkte. Liegt der Ursprung auf P′, fallen die beiden Zahlen zusammen. Liegt er auf P, gehen sie auseinander. Für ein Programm ist das kein Problem, es rechnet ohnehin nur mit der Platzierung. Für einen Menschen schon. Wer in Datei B das Geschoss anklickt, sieht in der Geschossliste +0,30 und im Attribut −0,15 und fragt sich zu Recht, welche Zahl stimmt. **Zwei Fehler lassen sich damit vorhersagen.** Beide sieht man erst in einem zweiten Programm. 1. **Ursprung auf P, aber in `OrthogonalHeight` die Höhe von ±0,00.** Dann steht dort 500,00 statt 499,55, und das ganze Modell liegt 45 Zentimeter zu hoch. Jede Platzierung stimmt, jedes Property Set stimmt. Auffallen wird es erst, wenn jemand das Modell mit einem Geländemodell oder mit Kanalhöhen zusammenlegt. 2. **Die Höhe über NHN in die Platzierung eines Geschosses geschrieben.** Wer beim Geschoss 499,85 einträgt statt −0,15, hebt es um fast 500 Meter an, weil die Kartenumrechnung die 500 Meter noch einmal dazurechnet. Dieser Fehler fällt sofort auf. Der erste nicht. ## Was ich zuerst falsch hatte Ein Fachtext, der nur Recht behält, ist Werbung. **Meine erste Antwort an die Auszubildenden war falsch.** Ich habe zuerst gesagt, IFC lege nicht fest, ob ein Geschoss auf OK RFB oder auf OK FFB sitzt, und für den Unterricht das Geschoss auf OK FFB gelegt. Die Festlegung steht in der Dokumentation, nur nicht beim Geschoss, sondern in der [Höhengrafik des Raums](https://standards.buildingsmart.org/IFC/RELEASE/IFC4%5F3/HTML/lexical/IfcSpace.htm?ref=modelllogik.de). Gefunden habe ich sie erst, nachdem ein Einwand mich zum zweiten Hinsehen gezwungen hat. ## Die Grenzen Gemessen ist eine Programmbibliothek, IfcOpenShell, an zwei IFC-Testdateien ohne Bauteile; Bonsai ist im Quelltext gelesen. Wie Allplan, Revit oder Archicad die Höhenfelder lesen und schreiben, ist nicht gemessen. Ein Programm darf das Attribut `Elevation` lesen. Tut es das statt der Platzierung, rechnet dort eben doch das Attribut, und die falsche +2,70 aus Datei A erscheint als Geschosshöhe. ## Was daraus folgt **Für den BIM-Abwicklungsplan** reicht eine Festlegung in vier Sätzen: 1. **Der Projektursprung liegt auf ±0,00, lotrecht über dem Vermessungspunkt** (P′, nicht P). Dann zählen Platzierung und Property Sets vom selben Punkt, und die Höhe über NHN ist `OrthogonalHeight` plus z. 2. **Jedes Geschoss liegt auf der Oberkante seiner Rohdecke.** So versteht es die Norm, und so liegen die gleichnamigen Geschosse im Architekturmodell und im Tragwerksmodell auf derselben Höhe. 3. **Roh- und Fertigfußboden stehen im `Pset_BuildingStoreyCommon`, ±0,00 und der Geländepunkt im `Pset_BuildingCommon`.** Den Fertigfußboden trägt man zusätzlich am Raum ein. 4. **Die abgekündigten Attribute bleiben leer, oder sie stimmen mit dem Property Set überein.** Wer sie für ältere Programme füllt, füllt sie mit denselben Werten. **Daraus werden Prüfregeln**, die keine Karte und kein zweites Programm brauchen. Man kann sie als [IDS](https://technical.buildingsmart.org/projects/information-delivery-specification-ids/?ref=modelllogik.de) formulieren, dem Prüfformat von buildingSMART, oder als kurzes Skript: - Die Platzierung jedes Geschosses ist gleich seinem `ElevationOfSSLRelative`. - `ElevationOfFFLRelative` minus `ElevationOfSSLRelative` ist der Fußbodenaufbau. - `OrthogonalHeight` ist gleich `ElevationOfRefHeight`. - Wo das Attribut `Elevation` gesetzt ist, ist es gleich der Platzierung. Die erste und die dritte Regel gelten nur, wenn der Ursprung auf P′ liegt. Ein Projekt mit dem Ursprung auf P ist genauso normgerecht, braucht dann aber andere Regeln, weil zwei Zahlen für dasselbe Geschoss im Spiel sind. **Und für jede Übergabe**, ob als Plan, als Mail oder als Protokoll, ein einziger Satz: Zu jeder Höhe gehört ein „gemessen von“. „EG −0,15“ und „EG +0,30“ können dasselbe Geschoss sein. **Gegen ±0,00, vom Projektursprung aus oder über NHN**, eines der drei gehört zu jeder Zahl. > **In IFC rechnet die Lage. Attribute und Property Sets erzählen, und wo sie der Lage widersprechen, erzählen sie falsch.** ## Glossar **±0,00, Bezugshöhe:** eine waagerechte Ebene, gegen die im Gebäude alle Höhen angegeben werden, meist die Oberkante des fertigen Fußbodens im Erdgeschoss. In IFC 4.3: `Pset_BuildingCommon.ElevationOfRefHeight`. **Abgekündigt** (englisch *deprecated*): ein Feld, das noch im Standard steht und gelesen werden kann, aber nicht mehr benutzt werden soll. **Attribut:** eine Angabe, die fest zu einer IFC-Klasse gehört, etwa der Name eines Geschosses. **`Elevation`:** im Englischen doppeldeutig, Höhe oder Ansicht. Als Attribut am Geschoss seit IFC 4.3 abgekündigt. **FFL, finished floor level:** englisch für OK FFB, die Oberkante des fertigen Fußbodens. In IFC 4.3: `ElevationOfFFLRelative`, gezählt von ±0,00. **Kartenumrechnung** (`IfcMapConversion`): der Eintrag, der sagt, wo der Projektursprung auf der Erde liegt, wie das Modell gedreht ist und wie hoch der Ursprung liegt. **Level:** im Englischen je nach Programm Geschoss, Ebene oder Höhe. IFC sagt für das Geschoss *storey*. **OK FFB, OK RFB:** Oberkante Fertigfußboden und Oberkante Rohfußboden, die beiden Höhen jedes Geschosses auf dem Plan. In IFC 4.3: `ElevationOfFFLRelative` und `ElevationOfSSLRelative`. **NHN, Normalhöhennull:** der amtliche Höhenbezug in Deutschland, die „Höhe über dem Meer“. **`OrthogonalHeight`:** Feld der Kartenumrechnung: auf welcher Höhe über NHN der Projektursprung liegt. **P, P′:** in diesem Text der vermessene Punkt im Gelände und derselbe Punkt, lotrecht angehoben bis in die Ebene ±0,00. **Platzierung** (`ObjectPlacement`): Lage und Ausrichtung eines Objekts im Modell, gemessen vom Projektursprung. Ihr z-Wert ist die Geschosshöhe, mit der ein Programm rechnet. **Projektursprung:** der Punkt 0/0/0 des Modells. **Property Set:** eine Gruppe von Merkmalen, die man an ein IFC-Objekt anhängt, etwa `Pset_BuildingStoreyCommon` an ein Geschoss. **`RefElevation`:** Attribut am Grundstück: die ungefähre Höhe seines Ursprungs über dem Meer, eine ältere Angabe neben geografischer Länge und Breite. Nicht abgekündigt, aber nicht nötig, wenn die Kartenumrechnung gesetzt ist. **RL, reduced level:** Höhe gegen einen Bezugspunkt. Welcher das ist, sagt die Abkürzung nicht. **SSL, structural slab level:** englisch für OK RFB, die Oberkante der Rohdecke. In IFC 4.3: `ElevationOfSSLRelative`, gezählt von ±0,00; zugleich die Höhe des Geschosses. **`VerticalDatum`:** der Höhenbezug der Georeferenzierung, als Schlüssel eingetragen, etwa `EPSG:7837` für das Deutsche Haupthöhennetz 2016.