Die Ausgleichungsrechnung ist bei Ingenieuraufgaben im Vermessungswesen nicht mehr weg zu denken. Neben Sonderaufgaben wie bspw. der Koordinatentransformation oder der Analyse von Formen und Regelgeometrien spielt die Ausgleichung von geodätischen Netzen eine zentrale Rolle in der praktischen Ingenieurvermessung. Es gibt hierzu verschiedene Programme am Markt, die teilweise auch frei verfügbar sind. Im deutschsprachigen Raum zählen zu den kommerziellen Lösungen: CAPLAN, Geo3D, KAFKA, Neptan, NetzCG und PANDA. Als Freeware (nicht quellcodeoffen) stellt Xdesy eine Alternative zu den kostenpflichtigen Lösungen dar. Im kostenfreien OpenSource-Bereich gibt es bspw. die Programme GNU Gama und das plattformunabhängige JAG3D.

Dass es den Alleskönner nicht gibt, ist klar. Jedes Programm hat seine Stärken und Einschränkungen. Fakt ist jedoch, dass alle Ausgleichungsprogramme mit klassischen terrestrischen Beobachtungen umgehen können. Eine Auswertung von tachymetrischen Daten (Horizontalstrecken und Richtungen bzw. Schrägstrecken, Zenitwinkel und Richtungen) ist somit mit jedem Produkt möglich, sodass alle Programme für Standardaufgaben eingesetzt werden können. Ein Vergleich zwischen den Ergebnissen erscheint daher gerechtfertigt und sollte keine größeren Differenzen hervorrufen.

Genau dieser Vergleich wurde von drei Hochschulen mit jeweils unterschiedlichen Paketen durchgeführt. Die erzielten Ergebnisse wurden beim DVW-Seminar Qualitätsmanagement geodätischer Mess- und Auswerteverfahren in Hannover vorgestellt [Schwieger et al., 2010]. Abweichungen von mehreren Millimetern wurden dabei zwischen den Ergebnissen von verschiedenen Programmen festgestellt. Primär wurden beim DVW-Beitrag kommerzielle Lösungen miteinander verglichen. Für den hier vorliegenden Beitrag wurde die Liste der zu vergleichenden Programme erweitert (Tabelle 1), wobei diesmal auch freie Programme mit einbezogen wurden. Als Vergleichskriterium sollen hier lediglich die ausgeglichenen Koordinaten dienen, da diese in der Regel als Endprodukt abzugeben sind. Eine Wertung von stochastischen Größen und Zuverlässigkeitsmaßen (Standardabweichung, Redundanzanteil, geschätzter grober Fehler usw.) spielt zwar für den Sachbearbeiter während der Auswertung eine wichtige Rolle, kleine numerische Abweichungen sind dort jedoch wesentlich unkritischer. Für den Auftraggeber ist es letztlich entscheidend, dass die ausgeglichenen Koordinaten stimmen und dass sie bei gleicher Bearbeitung auch in anderen Programmen reproduzierbar sind. Schließlich sollte es schon aus rein wirtschaftlicher Sicht vermieden werden, sich von einem Produkt abhängig zu machen. Auch wird hier nicht untersucht, welche Speichermethoden (z. B. Sparse-Matrizen) und Rechenalgorithmen von den einzelnen Programmen eingesetzt werden, und wie sich diese auf die benötigte Rechenzeit auswirken.

Ein für den Anwender wichtiger Punkt ist sicherlich die graphische Bedienoberfläche (GUI), mit der er arbeiten muss. Nicht alle getesteten Produkte verfügen über eine GUI. Aber auch bei den Programmen, bei denen eine Bedienoberfläche vorhanden ist, sind enorme Unterschiede zu verzeichnen: Das Repertoire reicht von einer schlichten Oberfläche, mit der nur ein paar ausgewählte Steuerparameter gesetzt werden können, bis zum interaktiven Arbeiten direkt in einer CAD-Graphik. Weiterhin wird die Auswertung von GNSS-Daten nicht von allen Programmen unterstützt. Auch die Netzdimension, mit der ein Programm rechnen kann, ist nicht bei allen Ausgleichungspaketen identisch. So erlauben einige Programme keine echten 3D-Netze sondern liefern eine sogenannte 2D+H-Lösung, indem die Lage von der Höhe getrennt ausgewertet wird. Mathematische Abhängigkeiten (Korrelationen) zwischen den beiden Komponenten werden in diesem Fall ignoriert. Andere Pakete sind hingegen nur im Stande, räumliche Netze zu berechnen. Eine Teilspurminimierung ist darüber hinaus nicht mit allen getesteten Produkten möglich, sodass auch bei der Art der Netzausgleichung bzw. des Netzanschlusses Unterschiede zu verzeichnen sind.

Die Entwickler der getesteten Programme wurden beim Auftreten von Unstimmigkeiten in den Auswerteprozess mit eingebunden. Zum einen sollten so Anwenderfehler ausgeschlossen werden, zum anderen lieferten diese z. T. Software-spezifische Informationen, durch die sich auftretende Differenzen klären ließen.

Der direkte Vergleich wurde an einem 2D- und einem 3D-Netz vorgenommen. Beide Netze wurden den Autoren von Dr. Hans Neuner vom Geodätischen Institut Hannover zur Verfügung gestellt und bereits im Vergleich von Schwieger et al. (2010) verwendet (Abbildung 1). Dabei handelt es sich um fiktive Netze von 1.2 km Ausdehnung, für die Beobachtungen mit vorgegebenen Standardabweichungen simuliert wurden. Sie bestehen aus 12 Punkten und sind frei auszugleichen. Im 2D-Fall liegen 50 horizontale Strecken und 50 Richtungen in 12 Sätzen als Eingangsdaten vor. Beim 3D-Netz sind es 49 Schrägstrecken, 50 Zenitwinkel und ebenfalls 50 Richtungen. An allen Beobachtungen wurden etwaige Korrektionen und Reduktionen bereits angebracht. Als Beobachtungsgenauigkeit sei für die Richtungen 0.3 mgon, für die Vertikalwinkel 0.6 mgon und für die Strecken ein entfernungsabhängiger Genauigkeitsansatz von 2 mm und 2 ppm vorgegeben [Schwieger et al., 2010]. Diese Vorgaben entsprechen der Genauigkeit eines modernen Tachymeters.

Die bereits angebrachten Reduktionen berücksichtigen insbesondere die Erdkrümmung. Während Auswirkungen auf die Lagekomponente auf die gekrümmte Bezugsfläche zurückzuführen sind, resultiert der deutlich größere Einfluss k_E auf die Höhenkomponente aus den nicht parallelen Lotrichtungen. Letzterer ergibt sich näherungsweise zu [Witte & Schmidt, 2000]:

Formel 1: Erdkrümmungsreduktion

worin s die Horizontalentfernung und R der mittlere Erdradius (6371 km) ist. Bei einer Strecke von 500 m beträgt diese Korrektion bereits 2 cm und kann damit keinesfalls vernachlässigt werden. Die Handhabung dieser Effekte durch die einzelnen Programme ist durchaus unterschiedlich. Insbesondere kann der Nutzer nicht immer festlegen, ob und wie eine Reduktion anzubringen ist. Während manche Programme auf vorverarbeitete Daten angewiesen sind, arbeiten andere wiederum ausschließlich mit originären Messwerten. Bisweilen bleibt es aber dem Nutzer überlassen zu entscheiden, welche Reduktionen mit welchen Parametern angebracht werden sollen oder nicht.

Abbildung 1: Netzbild (NetzCG)

Programme mit einer 2D+H-Lösung zerlegen das Ausgleichungsproblem intern und werten Lage und Höhe getrennt voneinander aus. In einer Vorverarbeitung werden aus der Schrägstrecke und dem Vertikalwinkel die horizontale Strecke und der Höhenunterschied berechnet. Leider ist dabei nicht immer ersichtlich, wie die abgeleiteten Höhenunterschiede zustande kommen und in der Ausgleichung gewichtet werden. Die konsequente Anwendung des Fehlerfortpflanzungsgesetzes, bei der sich die individuelle A-priori-Genauigkeit jedes Höhenunterschieds aus der Strecken- und Vertikalwinkelunsicherheit ergibt, scheint nicht der Normalfall zu sein. Bei gleichen Eingangsdaten ist jedoch davon auszugehen, dass alle Programme zumindest in der Höhenausgleichung, bei der das funktionale Modell von Hause aus linear und damit sehr einfach ist, zu identischen Lösungen kommen. Da sich auch hier Differenzen in den Ergebnissen ergeben, liegt deren Ursache somit eher in der Vorverarbeitung der Daten als in der Ausgleichung selbst.

Aufgrund der z. T. unterschiedlich reduzierten Beobachtungen in der Vorverarbeitung und der differierenden stochastischen Modelle ist ein Vergleich der Programme, die eine 2D+H-Lösung anbieten, schwierig bis unmöglich. Ähnliches gilt für die Ausgleichung des Raumnetzes mit LGO, wo die Vorverarbeitung integraler Bestandteil des Konzeptes ist und nicht umgangen werden kann. Aus diesem Grund werden in diesem Beitrag nur diejenigen Lösungen miteinander verglichen, bei denen vom selben Beobachtungsmaterial ausgegangen werden kann.

Es sei an dieser Stelle betont, dass die Verwendung vorverarbeiteter Messwerte im Wesentlichen dadurch motiviert ist, eine bessere Vergleichbarkeit herzustellen. Ziel dieses Artikels soll es schließlich sein, die Ausgleichungsergebnisse zu bewerten und nicht die Art der Vorverarbeitung. Aus dem gleichen Grund erfolgte auch der Ausschluss einzelner Lösungen aus der Gegenüberstellung der Raumnetzausgleichungen, was deshalb keinesfalls als Abwertung angesehen werden darf.

Da nicht alle zur Verfügung stehenden Programme eine Teilspurminimierung erlauben, werden beim 2D-Netz alle 12 Punkte zur Datumsbildung genutzt. Beim 3D-Netz hingegen werden die Punkte 101-104 als Neupunkte und die übrigen 8 als Datumspunkte in eine freie Ausgleichung eingeführt. Zur Behebung des Rangdefektes der Normalgleichungsmatrix sind drei Zusatzbedingungen (zwei Translationen und eine Rotation) beim Lagenetz in der Ausgleichung zu berücksichtigen. Beim Raumnetz beträgt der Defekt vier [Illner, 1983].

Für diesen Vergleich wird auch auf erzielte Ergebnisse von anderen zurück gegriffen, da nicht alle Programme zur Verfügung standen. Prozessiert wurden die Netze mit CAPLAN (v2.7-15.12.2009), Geo3D⁶, Gama (v1.9.07), JAG3D (v3.1.20100907), LGO (v7.0.1), NetzCG (v2009.4.30), Netz3D (v4.0) und Xdesy (v1.9.18). Die Ergebnisse von HANNA (v01.06.1) hat Dr. Hans Neuner (Geodätisches Institut Hannover) freundlicherweise zur Verfügung gestellt. Die Ausgleichung mit KAFKA (v7.005) hat Prof. Dr. Wilhelm Benning (RWTH Aachen) vorgenommen. Neptan (v9.43) wertete Thore Overath (Vermessungsbüro Overath & Sand) aus. Die Ergebnisse von PANDA (v4.12X) stellte Karl-Heinz Steffens (GOS GmbH) zur Verfügung. Die Prozessierung mit SpatialAnalyzer (v2009.11.13) führte Christoph Herrmann (Geodätisches Institut Karlsruhe) durch. Die Nutzung von CAPLAN wurde durch Prof. Dr. Cornelia Eschelbach (Fachhochschule Frankfurt am Main) ermöglicht.

Bei den Ausgleichungsergebnissen des Lagenetzes zeigen sich weitgehend übereinstimmende Resultate (Tabellen 2 und 3). Die Abweichungen liegen im 1/10-mm-Bereich. Interessant ist, dass sich hier zwei Gruppen zu bilden scheinen. So sind die ausgeglichenen Koordinaten bspw. von CAPLAN, HANNA, JAG3D und PANDA identisch; auf der anderen Seite gibt es praktisch keine Differenzen zwischen CAPLAN, Gama, LGO, Neptan, NetzCG und Xdesy.

Eine Ursache liegt in der Verwendung unterschiedlicher Datentypen. So speichert Geo3D die Normalgleichungen bspw. nicht mit doppelter Genauigkeit ab [Benning, 2010a]. Eine weitere Ursache liegt im stochastischen Modell. So bieten die meisten Programme die Möglichkeit, für einen Beobachtungstyp (oder eine Beobachtungsgruppe) eine A-priori-Standardabweichung vorzugeben. Bei streckenabhängigen Unsicherheiten wird aus diesen Gruppenunsicherheiten erst zur Laufzeit die Gewichtung ermittelt. Im vorliegenden Fall ist die Streckengenauigkeit von der Länge der gemessenen Distanz abhängig. In NetzCG wird bspw. die Genauigkeit der Strecke nach folgender Formel berechnet [GIK, 2008]:

Formel 2: Streckengenauigkeit

worin in diesem Fall der absolute Anteil a₁ = 2 mm und der streckenabhängige Anteil a₂ = 2 ppm betragen. In JAG3D hingegen werden, wie im offengelegten Quellcode leicht nachvollzogen werden kann, die A-priori-Genauigkeiten nach dem Varianzfortpflanzungsgesetz bestimmt:

Formel 3: Streckengenauigkeit nach Fehlerfortpflanzung

Dieser Modellansatz wird auch von Niemeier (2008) vorgeschlagen. Bei einer Strecke von 500 m, wie sie im o. g. Beispiel vorkommt, ergibt sich nach (2) eine Standardabweichung von 3.0 mm für die Strecke. Durch Anwendung von (3) beträgt diese nur 2.2 mm. Der Unterschied zwischen beiden Modellen beträgt somit fast 1 mm. Um zu untersuchen, ob das abweichende stochastische Modell die Ursache für die sich ergebenen Differenzen ist, wurde das Programm JAG3D temporär modifiziert, sodass derselbe Berechnungsansatz wie in NetzCG zur Bestimmung der A-priori-Genauigkeiten der Strecken benutzt wird. Die Ergebnisse der modifizierten Version entsprachen denen, die u. a. NetzCG lieferte. Eine weitere Verifizierung konnte direkt mit dem Programmsystem CAPLAN vorgenommen werden, bei dem der Nutzer vor der Ausgleichung selbst entscheiden kann, ob Modell (2) oder (3) Anwendung finden soll.

Werden die Ergebnisse des Raumnetzes betrachtet, so sind die Differenzen zwischen den verglichenen Programmen schon deutlicher (Tabellen 4, 5 und 6). Eine echte 3D-Lösung bieten Gama, JAG3D, LGO, Netz3D, PANDA, SpatialAnalyzer und Xdesy an, wobei LGO sowie Softwarepakete, die lediglich eine 2D+H-Lösung liefern, aus o. g. Gründen vom Vergleich ausgeschlossen wurden.

Die Ergebnisse von Gama, JAG3D, Netz3D und PANDA sind äquivalent. Die geringen Unterschiede zwischen den Lösungen sind analog zum 2D-Fall im stochastischen Modell der Schrägstrecken zu suchen, was durch eine temporäre Modifizierung von Netz3D bestätigt werden konnte. Die Abweichungen von Xdesy zu den anderen Programmen ergeben sich vermutlich durch das Einführen von sieben Datumsbedingungen (drei Translationen, drei Rotationen und ein Maßstab), wie dem Report zu entnehmen ist. Auch in den abgedruckten Ergebnissen von [Boysen, 2009] ist zu erkennen, dass Xdesy bei der freien Ausgleichung sieben Zusatzbedingungen nutzt. Gama, JAG3D, Netz3D und PANDA führen lediglich die vier notwendigen Bedingungen ein, um den Defekt der Normalgleichungsmatrix zu beheben. Gleicht man das Netz mit hierarchischem Netzanschluss aus, so sind die Differenzen zwischen Xdesy und JAG3D lediglich im 1/10-mm-Bereich.

Bis auf SpatialAnalyzer verwenden alle in diesem Vergleich berücksichtigen Programme die tachymetrischen Daten als Beobachtungen im Ausgleichungsmodell und bestimmen die Unbekannten durch ein geschlossenes Gauß-Markov-Modell. Diese Vorgehensweise kann als klassische Methode betitelt werden und ist in der geodätischen Fachliteratur hinreichend gut beschrieben [vgl. Benning, 2010b; Niemeier, 2008; Jäger et al., 2005], sodass eine nähere Erläuterung an dieser Stelle entfallen kann.

SpatialAnalyzer bestimmt die Koordinaten durch das Verketten der einzelnen Standpunkte über Ähnlichkeitstransformationen. Hierzu werden aus den eigentlichen Beobachtungen zunächst Koordinaten berechnet, die sich auf den jeweiligen Standpunkt (Subsystem) beziehen. Diese werden anschließend durch eine Transformation in ein einheitliches (globales) Koordinatensystem überführt. Dem Anwender steht es dabei frei, welche Transformationsparameter pro Subsystem zu bestimmen sind. In der Geodäsie ist diese Art der Koordinatenbestimmung bzw. -transformation bspw. bei der Homogenisierung von Flurkarten bekannt. Aber auch bei der hierarchisch organisierten Kombination terrestrischer Referenzrahmen spielen verkettete Transformationen eine wesentliche Rolle [Altamimi et al., 2004]. Einige Modellansätze für verkettete 2D-Transformationen, die sich problemlos auf den räumlichen Fall übertragen lassen, sind bspw. bei [Foppe 2009] beschrieben. Bezogen auf das hier verwendete Raumnetz zeigen sich jedoch einige Schwächen bei der Umsetzung dieser Vorgehensweise in SpatialAnalyzer. Das erste offensichtliche Problem ergibt sich durch den inkonsistenten Datensatz, bei dem die Raumstrecke 908-101 fehlt. Der Punkt 101 kann somit innerhalb eines lokalen Systems nicht bestimmt werden, da nur eine Richtungsbeobachtung und ein Zenitwinkel vorliegen. Diese beiden Beobachtungen werden, obwohl sie nicht fehlerbehaftet sind, somit indirekt aus dem Datenbestand eliminiert und fließen nicht in die Ausgleichung ein. Aufgrund des fehlenden Punktes enthält das Standpunktsystem 908 darüber hinaus nur noch die Polarpunkte 907 und 909. Eine Transformation dieses Subsystems kann deshalb nicht durchgeführt werden, da SpatialAnalyzer hierfür mindestens drei Polarpunkte benötigt. Zwei weitere Punktbeobachtungen werden somit bei der finalen Lösung nicht berücksichtigt. Bedingt durch die fehlende Strecke finden also acht fehlerfreie Beobachtungen keine Berücksichtigung. Weiterhin kann eine Lagerung des Netzes nicht auf den Punkten 904-911 realisiert werden, da SpatialAnalyzer für die Transformation jedes Subsystems mindestens drei datumsgebende Punkte als identische Punkte benötigt. Diese Voraussetzung ist hier jedoch nicht erfüllt, sodass alle zwölf Punkte als Datumspunkte verwendet wurden. Allein aus diesen Gründen war bereits ein abweichendes Ergebnis gegenüber den anderen Programmen zu erwarten.

In der Lageausgleichung liefern alle Programme praktisch identische Ergebnisse, sodass diese für klassische Aufgaben bedenkenlos eingesetzt und vor allem gegeneinander ausgetauscht werden können. Auch beim Raumnetz konnten überwiegend übereinstimmende Resultate erzielt werden. Bei der Wahl für oder gegen ein Produkt können somit andere Kriterien, wie bspw. die Bedienfreundlichkeit, der Support oder mögliche Zusatzmodule herangezogen werden. Bei den Paketen, die eine 2D+H-Lösung bestimmen, wäre zu prüfen, wie die räumlichen Beobachtungen vor der eigentlichen Ausgleichung verarbeitet werden, damit abgeleitete Größen richtig bewertet und verglichen werden können.

Die bisweilen vorgenommene Trennung zwischen Lage und Höhe ist vorwiegend historisch motiviert und hauptsächlich darin begründet, dass das Bezugssystem der nivellitisch bestimmten Höhenkomponente physikalisch definiert ist. Problematisch ist dieser Ansatz hingegen bei der Einbeziehung von Zenitwinkeln, da hierbei bestehende Korrelationen zwischen Lage und Höhe vernachlässigt werden. Lediglich für annähernd horizontale Visuren, wie sie bei klassischen Netzen der Landesvermessung vorkamen, sind diese vernachlässigbar klein [Heck, 2003].

Bei kleinräumigen Ingenieurnetzen und in der Messtechnik sind dreidimensionale kartesische Koordinatensysteme hingegen Standard. Zum einen spielt das Schwerefeld aufgrund der geringen Netzausdehnung keine Rolle, und zum anderen sind aufgrund steiler Visuren resultierende Korrelationen zwischen Lage und Höhe nicht vernachlässigbar. Auch im Hinblick auf die Verwendung des Leitfadens zur Angabe der Unsicherheit beim Messen (GUM) in der Messtechnik, bei dem alle verfügbaren Informationen zur Ermittlung der Messunsicherheiten einfließen sollen [z. B. Hennes und Heister, 2007], wäre diese Modellvereinfachung kritisch zu hinterfragen.

Erfreulich ist, dass auch mit freien Produkten qualitativ adäquate Ergebnisse bei geodätischen Standardaufgaben zu erzielen sind.

Sowohl die Eingangsdaten als auch die Protokolle der Ausgleichungsprogramme, die von den Autoren getestet wurden, können hier heruntergeladen werden.

Rohdaten und Protokolle der verglichenen Ausgleichungsprogramme

Bei Dr. Hans Neuner möchten sich die Autoren ganz herzlich für die schnelle Bereitstellung der Netzdaten und die Ergebnisse vom Ausgleichungsprogramm HANNA bedanken. Weiterhin geht der Dank an Prof. Dr. Wilhelm Benning, Christoph Herrmann, Thore Overath und Karl-Heinz Steffens, die das Netz mit den Programmen KAFKA, SpatialAnalyzer, Neptan bzw. PANDA berechnet haben. Prof. Dr. Cornelia Eschelbach sei für den kurzfristig eingerichteten Zugang zu der Ausgleichungssoftware CAPLAN gedankt.

• Altamimi, Z., Sillard, P., Boucher, C. (2004), ITRF2000: From Theory to Implementation. In: Sanso, F. (Hrsg.): V Hotine-Marussi Symposium on Mathematical Geodesy: Matera, Italien, 17.-21.06.2002, Springer, Berlin.
• Benning, W. (2010a), Persönliche Mitteilung.
• Benning, W. (2010b), Statistik in Geodäsie, Geoinformation und Bauwesen. 3. Auflage, Wichmann, Heidelberg.
• Boysen, A. (2009), Beurteilung von Softwarepaketen zur Ausgleichungsrechnung. Bachelorarbeit Hochschule Neubrandenburg (zuletzt besucht: 24. August 2010).
• Geodätisches Institut (GIK) des Karlsruher Instituts für Technologie (2008), Netz2D – Theoretische Grundlagen. (zuletzt besucht: 24. August 2010).
• Heck, B. (2003), Rechenverfahren und Auswertemodelle in der Landesvermessung. 3. Auflage, Wichmann, Heidelberg.
• Hennes, M., Heister, H. (2007), Neuere Aspekte zur Definition und zum Gebrauch von Genauigkeitsmaßen in der Ingenieurgeodäsie. Allgemeine Vermessungsnachrichten (AVN), 114(11-12), 375-383.
• Foppe, K. (2009), Repetitorium zur Fehlerlehre und Statistik und Ausgleichungsrechnung. In: Foppe, K., Hoffmann, H.: Ausgleichungsrechnung mit Interpretation der Ausgleichungsergebnisse, Beiträge zum GfG-Fortbildungsseminar, 05. März 2009 in Neubrandenburg.
• Illner, I. (1983), Freie Netze und S-Transformation. Allgemeine Vermessungs-Nachrichten (AVN), 90(5), 157-170.
• Jäger, R., Müller, T., Saler, H., Schwäble, R. (2005), Klassische und robuste Ausgleichungsverfahren – Ein Leitfaden für Ausbildung und Praxis von Geodäten und Geoinformatikern. Wichmann, Heidelberg.
• Niemeier, W. (2008), Ausgleichungsrechnung – Statistische Auswertemethoden. 2. Auflage, Walter de Gruyter, Berlin.
• Schwieger, V., Foppe, K., Neuner, H. (2010), Qualitative Aspekte zu Softwarepaketen der Ausgleichungsrechnung. In: Kutterer, H., und Neuner, H.: Qualitätsmanagement geodätischer Mess- und Auswerteverfahren, Beiträge zum 93. DVW-Seminar am 10. und 11. Juni 2010 in Hannover, Schriftenreihe des DVW, Band 61.
• Witte, B., Schmidt, H. (2000), Vermessungskunde und Grundlagen der Statistik für das Bauwesen. Wittwer, Stuttgart.

Dieser Artikel wurde in der für Prof. Dr.-Ing. Dr.-Ing. E.h. Günter Schmitt vom Geodätischen Institut (GIK) des Karlsruher Instituts für Technologie (KIT) erschienenen Festschrift anlässlich seiner Verabschiedung veröffentlicht und kann wie folgt zitiert werden:

Lösler, M., Bähr, H. (2010), Vergleich der Ergebnisse verschiedener Netzausgleichungsprogramme. In: Vernetzt und ausgeglichen - Festschrift zur Verabschiedung von Prof. Dr.-Ing. Dr. E.h. Günter Schmitt. Geodätisches Institut (Hrsg.), KIT Scientific Publishing.

• ¹ Stochastisches Modell für Streckenbeobachtungen gemäß Gleichung (2) bzw. (3)
• ² Es erfolgt automatisch eine Trennung von Lage und Höhe bei räumlichen Beobachtungen.
• ³ Das stochastische Modell in Gama lautetσ_Dist = a₁ + a₂∙s^a3und entspricht für a₃ = 1 dem Modell (2).
• ⁴ Ausschließlich Raumnetze mit parallelen Lotlinien
• ⁵ Monte-Carlo-Methode mit unbekanntem Modellansatz
• ⁶ Buch-CD; W. Benning: Statistik in Geodäsie, Geoinformation und Bauwesen, Wichmann, Heidelberg, 2010

17.09.2010 von Michael Lösler