Georeferenzierung in IFC — der Nordwinkel steht nicht in der Datei

Worum es geht: die Georeferenzierung eines IFC-Modells — die Angabe, wo ein Gebäude auf der Erde steht und wie es dort gedreht ist. Ohne sie ist ein Modell ein Körper ohne Ort; mit ihr lässt es sich mit Katasterdaten, Geländemodellen und den Fachmodellen anderer Beteiligter zusammenlegen.

IFC führt diese Angabe an zwei Stellen, und sie beantworten verschiedene Fragen. IfcProjectedCRS benennt das Koordinatenreferenzsystem, in dem gerechnet wird — in diesem Projekt EPSG:25832 (ETRS89 / UTM-Zone 32N) mit dem Höhenbezug EPSG:7837 (DHHN2016). IfcMapConversion trägt die Umrechnung vom Projektsystem in dieses Koordinatensystem: den Rechts- und Hochwert des Bezugspunktes, die Höhe, den Maßstab — und die Drehung zwischen den Achsen des Modells und denen der Karte. Beide Einträge stehen seit IFC4 im Schema und tragen die Georeferenzierung auch in IFC 4.3.

Die beiden Systeme gehören als EPSG-Schlüssel in die Datei, nicht als Klartextbezeichnung. Mit EPSG:25832 kann ein Leseprogramm rechnen; mit „UTM 32" kann es raten. Und die Höhe braucht einen eigenen Schlüssel, weil sie ein eigenes Bezugssystem hat — ein Koordinatensystem für die Lage beschreibt die Höhe nicht mit.

Um die Drehung geht es hier, und nur um sie. Nicht um den Bezugspunkt, nicht um die Höhe, nicht um die Wahl des Koordinatensystems. Um das eine Feld, in dem steht, wie das Modell gegenüber der Karte verdreht liegt.

Zwei Programme zeigen für dieselbe IFC-Datei entgegengesetzte Nordwinkel. Das eine sagt +5,35 Grad, das andere −5,35 Grad, beide unter der Beschriftung Grid North, beide aus denselben zwei Zahlen gerechnet. Und keines von beiden rechnet falsch.

Das ist kein Kuriosum, sondern der Kern einer Sache, die im Alltag Geld kostet: Der Nordwinkel, den eine Oberfläche anzeigt, steht so gar nicht in der Datei. In der Datei steht ein Richtungsvektor. Der Winkel entsteht erst beim Hinsehen — und jede Anwendung rechnet ihn nach ihrer eigenen Verabredung aus.

Gemessen habe ich an Wegwerf-Testdateien, nicht am Referenzprojekt: ein Geländeausschnitt und ein kleiner Prüfkörper, deren Verschiebungswerte frei gewählt sind, damit man die Ergebnisse ohne Rücksicht auf ein bestimmtes Grundstück nachrechnen kann. Was hier steht, gilt für die Werkzeugfassungen vom 2026-09-10 und für keine anderen.

Warum überhaupt eine eigene Messung? Weil ich in einem früheren Beitrag geschrieben habe, wie man eine Verortung prüft — die Datei in ein fremdes Programm laden und auf der Karte nachsehen —, und weil diese Antwort zwar richtig ist, aber zwei Schwächen hat. Sie kommt spät: Wer sie ernst nimmt, prüft erst, wenn er ohnehin überträgt. Und sie beweist weniger, als sie zu beweisen scheint. Beides habe ich am eigenen Bestand gelernt, auf die unangenehme Art.

Die beiden Zahlen, im Klartext

Bevor es technisch wird: Die zwei Zahlen sind einfacher, als ihre Namen vermuten lassen. Wer sie einmal vor Augen hat, braucht den Rest dieses Textes nur noch zum Nachrechnen.

Stellen Sie sich in den Nullpunkt Ihres Modells und schauen Sie nach Osten. Das ist die Ausgangslage: Die Ostachse der Karte zeigt geradeaus, die Nordachse nach links. Jetzt drehen Sie sich um den Betrag, um den Ihr Modell gegenüber der Karte verdreht steht. Wohin Sie danach blicken, ist die Projekt-Ost-Achse — und genau diese Blickrichtung steht in der Datei.

Sie steht dort als zwei Anteile. Der eine sagt, wie weit Ihr Blick noch nach Osten zeigt. Der andere sagt, wie weit er nach Norden abweicht. In der Datei heißen die beiden XAxisAbscissa und XAxisOrdinate — und diese zwei Wörter schrecken mehr, als sie bedeuten. Die Abszisse ist die waagerechte Zahl, die Ordinate die senkrechte. Wer in der Schule je einen Punkt in ein Koordinatenkreuz eingetragen hat, hat beide benutzt: erst nach rechts, dann nach oben. Genau das steht hier — nur heißt „rechts" auf der Karte Osten und „oben" Norden. Mehr ist es nicht: zwei Anteile einer Blickrichtung, zusammen immer genau einen Schritt lang.

Und daran hängt auch, warum es überhaupt zwei Zahlen sind und nicht eine. Beschrieben wird ein Vektor — ein Pfeil mit einer Richtung und einer Länge. Einen Pfeil beschreibt man, indem man sagt, wie weit er nach rechts und wie weit er nach oben reicht; mehr braucht es nicht, um seine Spitze zu finden. Genau dafür sind Abszisse und Ordinate die Namen. Ein Winkel bräuchte dagegen erst zwei Verabredungen: wo die Null liegt, und in welche Richtung gezählt wird. Der Pfeil braucht keine. Das ist der Grund, aus dem in der Datei ein Vektor steht — und der Grund, aus dem der angezeigte Winkel gleich Ärger machen wird.

Hier sitzt nun die Verwechslung, die den ganzen Vorzeichenstreit trägt. Man liest „die Zahl ist negativ" und denkt an eine Richtung. Es ist aber keine Richtung, sondern ein Anteil. Die Ausgangslage und vier Fälle daneben — man sieht es sofort:

Sehen Sie die dritte Spalte an: In jedem Paar tragen links und rechts dasselbe. Der Ost-Anteil beginnt bei 1 und sinkt, je weiter Sie sich vom Ausgangsblick fortdrehen; über die Vierteldrehung hinaus wird er negativ. Die Drehrichtung unterscheidet er kein einziges Mal.

Der Ost-Anteil sagt, wie weit Sie sich gedreht haben. Bis zu einer Vierteldrehung blicken Sie noch nach vorn, dann ist er positiv. Darüber hinaus blicken Sie zurück, und er wird negativ. Was er nicht sagt: ob Sie sich nach links oder nach rechts gedreht haben. Beide Wege enden bei derselben Ost-West-Stellung.

Der Nord-Anteil sagt, wohin. Links landen Sie nördlich, rechts südlich. Nur diese eine Zahl unterscheidet die beiden Drehrichtungen — und deshalb steckt das Vorzeichen der Drehung allein in ihr.

Die Achse selbst ändert sich dabei nie. Die Ostachse zeigt nach Osten, immer. Negativ wird nicht die Achse, sondern der Anteil, und das heißt nichts weiter als: Sie blicken inzwischen nach hinten. Über eine volle Umdrehung ist der Ost-Anteil deshalb die halbe Zeit negativ — bei jeder Blickrichtung, die nach Westen weist. Das ist kein Sonderfall, den man abfangen müsste, sondern der Normalbetrieb eines Pfeils. Wer statt des Pfeils einen Winkel überträgt, muss genau hier anfangen zu erklären; wer die zwei Zahlen überträgt, muss gar nichts erklären.

Zwei Einschränkungen, damit das später nicht kippt. Gedreht wird hier die Achse in der Welt — nicht die Zahl, die jemand in ein Werkzeug eintippt. Dass beides gegenläufig gezählt wird, ist genau der Streit, um den es in diesem Text geht. Und die 120 Grad aus der Tabelle sind keine Ausnahme: Ein Gebäude kann in jeder Richtung zum Gitter stehen. Im Beispiel dieses Textes sind es 5,35 Grad — der Ost-Anteil ist dort 0,99564.

Was zu merken bleibt, ist ein Satz:

Die Abszisse sagt, um wie viel gedreht wurde. Die Ordinate sagt, in welche Richtung.

Den ganzen Ablauf — gerade drehen, verankern, zurückdrehen, die vier Quadranten — gibt es als Animation in gut anderthalb Minuten: Georeferenzierung in IFC 4.3 als YouTube-Short.

Warum der Winkel nicht in der Datei steht

IFC beschreibt Richtungen nicht als Winkel, sondern als Vektoren. Das zieht sich durch das ganze Schema, und es hat einen guten Grund: Ein Vektor braucht keine Verabredung darüber, wo Null liegt und in welche Richtung positiv zählt.

Für die Verortung sind zwei Stellen einschlägig, und sie sind verschieden gebaut.

IfcMapConversion trägt die Felder XAxisAbscissa und XAxisOrdinate. Die IFC4-Dokumentation beschreibt sie als die Komponenten eines Vektors entlang der Ost- und der Nordachse, der die Lage der lokalen x-Achse des Ingenieur-Koordinatensystems angibt; die Abbildung führt vom lokalen System in das Kartensystem. Anders gesagt: Wo liegt Projekt-Ost, ausgedrückt in Kartenachsen?

TrueNorth dagegen hängt am Repräsentationskontext und ist ein IfcDirection mit zwei Verhältniswerten. Es beantwortet eine andere Frage, und es tut das über eine andere Bezugsachse.

Beide Angaben sind Richtungen. Keine von beiden ist eine Drehung. Und in beiden Fällen zeigt die Oberfläche etwas an, das nicht in der Datei steht: einen Winkel.

Der Weg dorthin ist kurze Rechenarbeit — und genau dort sitzt die Verabredung. In der Bibliothek, auf der Bonsai aufsetzt, stehen beide Richtungen im Quelltext ausgeschrieben:

xaxis2angle(x, y)  =  degrees(atan2(y, x)) * -1
angle2xaxis(a)     =  ( cos(a) , -sin(a) )

Das * -1 ist die ganze Geschichte. Die zugehörige Dokumentation sagt auch, warum es dort steht: Der Vektor beantwortet „wo ist Projekt-Ost, wenn Gitternord nach oben zeigt", der Winkel dagegen „wie drehe ich Projektnord auf Gitternord". Das eine ist eine Achsrichtung, das andere die Drehung, die sie erzeugt. Beide sind zueinander invers, also unterscheiden sie sich im Vorzeichen — zwangsläufig, nicht zufällig.

Für TrueNorth benutzt dieselbe Bibliothek ein eigenes Paar, das auf die y-Achse bezogen ist. Zwei Felder, beide werden in Oberflächen als „Nordwinkel" angeboten, beide aus einem Vektor gerechnet — und keines der beiden zählt wie das andere.

Eine Datei kann damit zwei Nordangaben tragen, und sie beantworten verschiedene Fragen. Die Kartentransformation sagt, wie das Projektsystem zum Gitternord des Koordinatensystems steht; TrueNorth sagt, wo der geografische Norden liegt. Beide fallen nur auf dem Mittelmeridian einer Zone zusammen — überall sonst trennt sie die Meridiankonvergenz, in Mitteleuropa je nach Lage bis in den Bereich eines halben Grades. Wer beide Felder füllt, füllt sie also nicht mit demselben Wert, und wer sie über ihre Winkelanzeigen vergleicht, vergleicht zwei Konventionen an zwei verschiedenen Achsen. Nachgemessen habe ich das nicht. Belegt ist die unterschiedliche Bezugsachse im Quelltext, nicht das Verhalten der Anzeigen.

Der Aufbau

Die Prüfkörper. Ein Geländeausschnitt aus einem GIS, nordlagerichtig geschnitten, und ein kleines Testmodell. Beide sind Wegwerfstücke; die Ost-, Nord- und Höhenwerte der Kartentransformation sind frei gewählt.

Die Werkzeuge. Blender 5.2.0 LTS mit Bonsai 0.8.5, darunter IfcOpenShell 0.8.5 und Python 3.13.13. Als zweites, unabhängiges Programm IfcLite 1.41.0 in der Fassung vom 10. September 2026 — ein IFC-Betrachter, der eine Datei allein anhand ihrer Georeferenzierungs-Einträge auf einer Karte verortet.

Die Regel für alle Messwerte: Gelesen wird aus der geschriebenen Datei, nicht aus der Rückgabe einer Programmierschnittstelle. Wer die Schnittstelle fragt, misst die Schnittstelle. Die Vektorwerte in diesem Text stammen aus der IFCMAPCONVERSION-Zeile im Klartext oder aus einem zweiten, unabhängigen Einlesen derselben Datei.

Was gemessen wird, sind drei Dinge: wie ein eingetippter Winkel als Vektor in der Datei landet; was zwei verschiedene Programme aus demselben Vektor machen; und ob sich eine Verortung prüfen lässt, ohne sie anzusehen.

Die Messungen

Die Winkelreihe. Fünf Werte nacheinander in die Georeferenzierung eingetragen, jedes Mal gespeichert, jedes Mal die geschriebene Zeile zurückgelesen.

Der unmittelbar gerechnete Winkel liefert in jeder Zeile das Gegenvorzeichen des eingetragenen — auch bei 90 Grad, wo nichts mehr in einer Rundung verschwinden kann. Die Vektorlänge ist überall exakt 1; gemessen wird also tatsächlich eine Richtung und nicht ein Maßstab.

Zwei Programme, dieselbe Datei. Nimmt man die Datei mit dem Vektor 0,99564 / +0,09324 und legt beide Anzeigen nebeneinander:

Beide Anzeigen sind vertretbar, und das ist der Punkt. Das eine Programm gibt die gespeicherte Achsrichtung wieder, das andere die Drehung, die aus ihr folgt. Beide Definitionen stehen dokumentiert. In der Oberfläche steht bei beiden nur „Grid North". Welche der zwei Fragen gerade beantwortet wird, sieht man der Zahl nicht an — und der Datei erst recht nicht, denn dort steht sie ja nicht.

Was folgt daraus für die Übergabe? Der Satz, der diesen Text trägt:

Wer einen Winkel überträgt, überträgt eine Konvention mit. Wer den Vektor überträgt, überträgt die Sache.

Ein Nordwinkel in einer Mail, in einem Abwicklungsplan oder in einem Besprechungsprotokoll ist ohne die Angabe, welches Programm ihn angezeigt hat, nicht auswertbar. Die beiden Zahlen des Vektors sind es immer.

Ein Teil des Problems entsteht überhaupt erst an der Eingabemaske. Verbreitete Autorenwerkzeuge lassen einen Winkel eintragen, nicht die beiden Zahlen — aus eigener Arbeit kenne ich das von Allplan 2026. Wer dort eine Georeferenzierung setzt, tippt genau die Größe ein, die in der Datei gar nicht steht, und übernimmt dabei, ohne es zu bemerken, die Zählrichtung des Programms, das gerade vor ihm steht. Die Verabredung wird nicht erst beim Lesen übernommen, sondern schon beim Schreiben. Das ist kein Mangel: Ein Winkel ist die Größe, die ein Planer im Kopf hat, und eine Oberfläche, die danach fragt, ist gut gebaut. Sie kann nur nicht mitliefern, wie sie ihn zählt.

Es geht auch anders, und beide hier geprüften Programme können es: Bonsai und IfcLite bieten beide Eingabewege an — ein Feld für den Winkel und daneben zwei Felder für Abszisse und Ordinate. Nur deshalb ließ sich der Mechanismus hier überhaupt aufdecken. Für Bonsai zeigt der Quelltext, dass es dieselbe Größe in zwei Ansichten ist: Wer den Winkel ändert, löst angle2xaxis aus, und die beiden Zahlen werden neu geschrieben; wer die beiden Zahlen ändert, löst xaxis2angle aus, und der Winkel wird neu geschrieben. Zwei Eingabewege, ein Wert — und dazwischen das Vorzeichen.

Wer die Wahl hat, trägt die beiden Zahlen ein. Der Winkel ist bequemer und bringt eine Verabredung mit; der Vektor ist unbequemer und bringt nichts mit. Und wer die Wahl nicht hat, weiß nach diesem Text wenigstens, was sein Programm mit der eingetippten Zahl macht — nachsehen lässt es sich in der geschriebenen Datei, in einer einzigen Zeile.

Der Kontrollversuch — und was ein Kartenbild nicht beweist

Bis hierher ist geklärt, wie der Winkel entsteht. Offen ist die praktische Frage: Welcher Vektor gehört in eine bestimmte Datei?

Die naheliegende Antwort lautet: der, bei dem das Gebäude auf der Karte richtig liegt. Sie ist richtig und trotzdem eine Falle, denn das Kartenbild zeigt zwei Unbekannte auf einmal — die Drehung der Geometrie im Projektsystem und die Drehung der Kartentransformation. Sichtbar ist nur ihre Summe.

Ich habe das auf die harte Tour gelernt. Zwei Fassungen derselben Geländedatei, einmal mit positivem, einmal mit negativem Ordinatenwert, beide in den Kartenbetrachter geladen: Eine lag im Flurstück, die andere nicht. Das sah nach einer Antwort aus. Es war keine — denn in beiden Fassungen war unbekannt, wie das Gelände im Projektsystem lag.

Der Versuch, der es entscheidet, hält die zweite Größe fest. Der Geländeausschnitt wird nordlagerichtig aus dem GIS geschnitten. Im Modell wird er um −5,35 Grad gedreht, damit die Grundstücksgrenzen auf den Achsen liegen und sich bequem konstruieren lässt. Danach steht die Geometriedrehung fest, und erst jetzt sagt die Karte etwas.

Am Ergebnis abgelesen — nicht am Bild geschätzt, sondern aus der Datei:

Die beiden Vektoren sind Spiegelbilder, und ihre Drehungen heben sich auf. Das Gelände liegt in der Welt so, wie das GIS es geliefert hat.

Und hier lauert die Falle, an der man sich verheddert, obwohl man alles richtig macht: Um das zu erzeugen, wird in beide Felder derselbe Zahlenwert mit demselben Vorzeichen eingetragen — in die Objektdrehung −5,35 und in das Winkelfeld der Georeferenzierung ebenfalls −5,35. Wer erwartet, zum Ausgleichen das Vorzeichen wechseln zu müssen, trägt +5,35 ein und verdoppelt die Drehung auf 10,7 Grad. Der Grund ist der von oben: Die beiden Felder zählen gegenläufig.

Die Probe, die ohne Karte auskommt

Aus dem Kontrollversuch fällt eine Regel, die allgemeiner ist als er selbst:

Eine Georeferenzierung ist nicht dann richtig, wenn eine bestimmte Zahl darin steht, sondern wenn sie die Drehung der Geometrie aufhebt.

Das Vorzeichen der Kartentransformation ist keine Eigenschaft des Grundstücks. Es hängt daran, wie das Modell im Projektsystem liegt. Wer nur die Zahl aus einer fremden Dokumentation abschreibt, schreibt die Hälfte ab.

Und daraus wird eine Prüfung, die man an der Datei fahren kann, ohne Karte, ohne zweites Programm und ohne einen einzigen Winkel:

Die x-Achse der Platzierung des Geländekörpers und die x-Achse der IfcMapConversion müssen Spiegelbilder sein — gleiche Abszisse, entgegengesetzte Ordinate. Ihre Drehungen ergeben in Summe null.

Vier Zahlen, ein Vergleich. Kein atan2, kein Vorzeichenstreit, keine Konvention.

Wie man an die vier Zahlen kommt. Das eine Paar ist leicht zu haben: IfcMapConversion steht in einer IFC-Datei im STEP-Format als eine einzige Zeile, auffindbar in jedem Texteditor über die Suche nach IFCMAPCONVERSION; die beiden Zahlenwerte vor dem Maßstab am Ende sind Abszisse und Ordinate. Das zweite Paar ist unbequemer, denn es steckt in der Platzierung des Geländekörpers, und die ist eine Kette aus Verweisen. Wer einen Betrachter hat, der die Platzierung eines Objekts ausgibt, liest es dort ab; sonst sind es rund zehn Zeilen mit einer IFC-Bibliothek. Das ist der einzige unbequeme Teil dieser Prüfung — und er lässt sich einmal einrichten und danach auf jede Datei anwenden.

Am vorhandenen Bestand gefahren, über fünf Dateien desselben Vorhabens:

Vier von fünf fallen durch. Die beiden früheren Fassungen aus einem anderen Grund als die erste: Ihre Geometrie ist gar nicht gedreht, also kippt sie jede Drehung ungleich null. Und genau eine dieser beiden hatte im Kartenbild überzeugend ausgesehen.

Ein Nebenbefund derselben Runde: In keiner der geprüften Dateien ist das Feld Scale gesetzt. Für den vollen Grad der Georeferenzierung gehört es dazu; ob ein Leseprogramm es vermisst, ist eine eigene Messung wert.

Der Befund, der gegen die eigene Dokumentation arbeitet

Der unangenehmste Teil betrifft nicht die Werkzeuge.

Meine eigene Standortdokumentation führte seit Wochen den falschen Vektor — den mit dem Vorzeichen, das die Drehung verdoppelt. Sie führte ihn nicht nur, sie schützte ihn: mit einem Merkposten des Inhalts, der Wert sehe falsch aus, sei aber richtig, und wer ihn nach der naiven Rückrechnung ändere, baue den Fehler erst ein.

Das Gegenteil traf zu. Die naive Rückrechnung entspricht dem Wortlaut der Norm. Wer den Wert geändert hätte, wäre richtig gelegen.

Wie kommt so etwas zustande? Nicht durch Nachlässigkeit, sondern durch eine Erklärung, die zur Hand war. Der Wert sah falsch aus; es ließ sich eine plausible Begründung finden, warum er trotzdem stimmt — das Werkzeug rechne eben andersherum —, und damit war die Sache erledigt. Die Begründung war sogar halb richtig: Das Werkzeug rechnet tatsächlich andersherum. Sie war nur kein Beleg dafür, dass der Wert in dieser Datei stimmt.

Eine Erklärung ist kein Beleg. Das ist der Satz, den ich aus dieser Messung mitnehme, und er hat mich einen berichtigten, bereits veröffentlichten Beitrag gekostet.

Die Grenzen

Gemessen wurde an einem Werkzeugpaar, in einer Fassung, an Testdateien. Ein anderes Autorenwerkzeug kann den Winkel anders definieren, ein anderer Betrachter ihn anders anzeigen. Der Befund lautet nicht „Programm X rechnet falsch", sondern: Zwei vertretbare Definitionen tragen dieselbe Beschriftung. Dieser Befund überträgt sich, die konkreten Vorzeichen nicht.

Die Spiegelprobe prüft, ob sich zwei Drehungen aufheben. Sie prüft nicht, ob der Betrag stimmt — 5,35 Grad statt 6,35 Grad fallen ihr nicht auf, weil beide Seiten denselben falschen Wert tragen können. Für den Betrag bleibt die Karte zuständig.

Ebenso wenig prüft sie die Verschiebung. Ein Modell kann sauber ausgerichtet und trotzdem einen Kilometer daneben liegen; dafür ist der Bezugspunkt zuständig, nicht die Drehung.

Und eine Voraussetzung trägt die Probe stillschweigend mit: Sie unterstellt, dass die Drehung der Geometrie in der Platzierung steht. Wer sie stattdessen in die Koordinaten einrechnet — sie also in die Geometrie einbackt —, bekommt eine Platzierung mit null Grad, und die Probe meldet Ruhe, während das Modell verdreht in der Welt steht. Das ist keine Schwäche der Probe, sondern derselbe Grund, aus dem die Drehung ohnehin nicht in die Geometrie gehört: Danach ist sie in der Datei nicht mehr auffindbar, und der Nordbezug ist verloren — für jede Prüfung, nicht nur für diese.

Und der Wert meines eigenen Referenzprojekts ist noch offen. Er wird neu gesetzt und dabei gemessen. Was hier steht, ist die Mechanik — nicht der Projektwert.

Was daraus für die Praxis folgt

Der Nordwinkel gehört nicht in die Datenlieferung, der Vektor gehört hinein. Wo ein Abwicklungsplan eine Drehung vorschreibt, sollte er die beiden Vektorkomponenten nennen oder die Angabe eindeutig an eine Definition binden. Eine Gradzahl ohne Programmangabe ist eine halbe Angabe.

Prüfen Sie vor der Übergabe, nicht danach. Die Spiegelprobe kostet vier Zahlen aus der Datei und einen Vergleich. Sie greift, bevor jemand anders die Datei öffnet — und das ist der einzige Zeitpunkt, zu dem ein Verortungsfehler noch billig ist.

Behandeln Sie ein Kartenbild als das, was es ist: eine Aussage über die Summe zweier Drehungen. Es ist ein ausgezeichneter Schlusstest und ein schlechter Einzelbeleg. Wer daraus auf eine Ursache schließt, ohne die Geometriedrehung zu kennen, schließt zu weit.

Und wenn eine Abweichung auftritt, sehen Sie auf den Betrag. Ist sie genau doppelt so groß wie die Projektdrehung, heben sich die beiden Drehungen nicht auf, sondern addieren sich. Dann ist ein Vorzeichen gegenläufig — und zwar in dem Feld, das Sie zuletzt angefasst haben.

Halten Sie fest, welches Programm die Zahl angezeigt hat. Zu jeder dokumentierten Drehung gehören vier Angaben: die beiden Vektorkomponenten, das Datum, das Werkzeug und seine Fassung. Das klingt nach Bürokratie und ist der Unterschied zwischen einer Angabe, die sich in zwei Jahren noch prüfen lässt, und einer, die dann neu gemessen werden muss. Ich schreibe das als jemand, der genau diesen Unterschied gerade bezahlt hat.

Wie es weitergeht

Offen bleibt dreierlei. Erstens der Wert meines Referenzprojekts, der beim Neusetzen der Georeferenzierung mitgemessen wird. Zweitens das nicht gesetzte Scale-Feld: Ob ein Leseprogramm es vermisst oder stillschweigend mit 1 rechnet, ist nachzumessen und nicht zu vermuten. Und drittens die Frage, wie andere Autorenwerkzeuge ihren Nordwinkel definieren — dafür bräuchte es mehr Hände als meine.

Was bleibt, ist ein Satz, der über die Georeferenzierung hinausreicht. In einer Datei stehen Tatsachen; auf dem Bildschirm steht eine Auslegung. Meistens fallen beide zusammen, und man merkt den Unterschied nie. Hier fallen sie auseinander, und zwar um genau ein Vorzeichen — was in der Welt draußen mehrere Meter sind.

Wie die Verortung überhaupt aufgebaut wird und warum sie an den Anfang eines Projekts gehört, steht im Beitrag Wo steht das Haus?. Warum eine Zahl aus einer Werkzeuganzeige grundsätzlich eine zweite Quelle braucht, ist der rote Faden des Messberichts zu Git als gemeinsamer Datenumgebung.