Gruppenunsicherheit als individuelle Unsicherheit übernehmen

Nabend Micha,

ich habe immer wieder den Anwendungsfall, dass innerhalb eines Netzes Beobachtung mit doch deutlich unterschiedlicher Unsicherheit "verarbeitet" werden müssen. Bspw. verhältnismäßig wenig Datumspunkte, welche aber sehr genau und reproduzierbar beobachtet werden können, zu 100+ Objektpunkten (z. B. Reflexmarken) die aus teils stark differierenden Winkeln angemessen werden. Beim stochastischen Modell führt es dann im Allgemeinen dazu, dass die Annahmen für einige Beobachtungen zu optimistisch/pessimistisch sind, was in den globalen Varianzkomponenten meist nicht sichtbar wird, aber in den beobachtungsweisen/gruppenweisen Varianzkomponenten deutlich wird.

Bis auf die Richtungssätze lassen sich alle anderen Beobachtungstypen entsprechend gruppenweise separieren und mit jeweils unterschiedlichen Gruppen-Unsicherheiten auch verschieden behandeln. Ausgehend davon, dass sich die Datums-/Stabilpunkte unabhängig von den Neu-/Objektpunkten berechnen lassen, ergibt sich dann für die Richtungssätze folgender Workaround (-> welcher vielleicht gar keiner ist):

Berechnung des Datums-/Stabilpunkt-Netzes mit Abstimmung des stoch. Modells, manuelle Übertragung der per Gruppeneigenschaften abgestimmten a priori Unsicherheiten $\sigma_0$ aus dem Report (werden nur da mit ausgegeben) als individuelle Unsicherheit $\sigma_0$ in die Rohdaten der Richtungssätze, Hinzuschalten sämtlicher weiteren Netzpunkte und Abstimmung derer Unsicherheit über die Gruppeneigenschaften. Dies ist natürlich vor allem bei einer Vielzahl von Beobachtungen unschön und insbesondere fehleranfällig.

Ist es möglich eine Funktion einzubauen (z. B. im Kontextmenü, oder unter Vorverarbeitung), welche für die Richtungssätze die a priori Unsicherheit aus den Gruppeneigenschaften (Spalte $\sigma_0$ aus dem Report) automatisch als individuelle Unsicherheit in die Rohdaten überträgt? Ich kann natürlich jederzeit eine individuelle Unsicherheit für eine Beobachtung vorgeben (z. B. als Abgewichtung), sodass es nur sinnvoll wäre hier Angaben zu machen, wenn dort kein Wert gesetzt ist. Ich grübele gerade, ob und in welchem Fall dadurch Probleme auftreten ... :-|

Wenn Du darüber hinaus einen anderen Tip diesbezüglich hast, nehme ich den natürlich auch gerne an. ;-)

Vielen Dank & Viele Grüße
Pierre

Hallo Pierre,

ich kann den Anwendungsfall nachvollziehen, da ich diesen auch schon hatte, und es im Prinzip ähnlich wie Du gelöst habe. Das "Problem" ist, dass ich die individuellen a-priori Unsicherheiten erst bei der Ausgleichung bestimme, da ich hier sicher sein kann, dass der Nutzer alle Informationen eingegeben hat. Liegt die Strecke d0 nicht vor, versuche ich den Abstand aus Koordinaten zu bestimmen,um den streckenabhängigen Anteil zu bestimmen.

Wenn d0 vom Nutzer eingegeben wurde und bereits vor der allerersten Ausgleichung vorliegt, könnte man diese Rechnung durchführen. Ansonsten müsste man zwingend eine Ausgleichung vorher durchführen (mit reduzierten Beobachtungsmaterial), damit s0 überhaupt vorliegt.

Beide Varianten finde ich nicht so super intuitiv. Am wenigsten missverständlich erscheint mir eine Option im Ausgleichungsdialog, etwas wie "konvertierte gruppenbasierete Unsicherheiten in individuelle Unsicherheiten" (der Text müsste nur kürzer sein). Dann würden die s0 beim Speichern der Ergebnisse auch in die SQL Tabelle übertragen werden.

Alternative könntest Du Dir bereits jetzt mit einem einfachen SQL behelfen,dann müsstest Du nicht immer den Umweg über den Report gehen. Soll ich da mal einen bauen für Dich?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Micha,

Beide Varianten finde ich nicht so super intuitiv. Am wenigsten missverständlich erscheint mir eine Option im Ausgleichungsdialog, etwas wie "konvertierte gruppenbasierete Unsicherheiten in individuelle Unsicherheiten" (der Text müsste nur kürzer sein). Dann würden die s0 beim Speichern der Ergebnisse auch in die SQL Tabelle übertragen werden.

Da gebe Dir Recht, so richtig schön ist das beides nicht. Ebenfalls hatte ich schon vermutet, dass Du die a priori Unsicherheiten erst zur Laufzeit bestimmst und dass diese natürlich von d0 abhängig sind, macht die Sache auch nicht einfacher.

Problematisch ist halt, dass man die Richtungssätze nicht gruppenweise trennen kann. Anderer Gedankengang: Was ist mit einer Art sekundärer a priori Gruppenunsicherheit (in der Registerkarte Eigenschaften, oder einer eigenen Rubrik) welche sich nur auf extra gekennzeichnete Punkte (Checkbox im Rohdatenreiter) auswirkt. Dann wäre die Problematik mit d0 etc. doch außen vor.

Alternative könntest Du Dir bereits jetzt mit einem einfachen SQL behelfen,dann müsstest Du nicht immer den Umweg über den Report gehen. Soll ich da mal einen bauen für Dich?

Wenn das so einfach ist, dass ich (SQL-Noob) das auch auf die Reihe bekomme, wäre das prima :-) Aber erstmal eins nach dem Anderen ... ;-)

Viele Grüße
Pierre

Hej Pierre,

ich bin noch bis Ende der Woche unterwegs. Ich werde Dir dann mal ein SQL erstellen. Vielleicht löst der Dein spezielles Problem noch besser als eine eher allg. Lösung.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Hallo Pierre,

Wenn das so einfach ist, dass ich (SQL-Noob) das auch auf die Reihe bekomme, wäre das prima

Ich habe heute die Zeit gefunden, mal einen kurzen SQL zu bauen. Erstelle Dir einfach eine Datei und füge dort folgende Zeile ein. Speichere diese Datei mit der Endung .sql.

MERGE INTO "ObservationApriori" USING "ObservationAposteriori" ON "ObservationApriori"."id" = "ObservationAposteriori"."id" WHEN MATCHED THEN UPDATE SET "ObservationApriori"."sigma_0" = "ObservationAposteriori"."sigma_0";

Der Ausdruck ist recht simple und überträgt die Einträge der sigma_0-Spalte aus der Tabelle ObservationAposteriori in die (zufällig) gleichnamige Spalte der Tabelle ObservationApriori. Du musst also schon mindestens eine Ausgleichung durchgeführt haben, damit die Werte übertragen werden können.

Man könnte den SQL noch weiter einschränken und das Übertragen bspw. nur bei Beobachtungen vornehmen, bei denen der Zielpunkt einen bestimmten Namen hat.

Wenn Du eine Ausgleichung mit den Datumspunkten durchgeführt hast, dann kannst Du dieses Script ausführen: Projekt → SQL Script ausführen.

Hilft Dir das weiter?

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Tags:
SQL, Unsicherheit, Script, Statement

Hallo Micha,

Hilft Dir das weiter?

ja, das hilft mir weiter und funktioniert prima :-D . Für die Abstimmung des stoch. Modells läuft sowieso mindestens eine Ausgleichung vorher durch ... Darüber hinaus stimme ich Dir zu, die Lösung ist sehr elegant und schlank, schick so ein SQL-Script.

Ich danke Dir. :-)

Viele Grüße
Pierre

Hallo Pierre,

ja, das hilft mir weiter und funktioniert prima .

Super. Anbei der modifizierte Ausdruck, der das Update nur auf Beobachtungen anwendet, die eine bestimmte Zielpunktnummer haben:

MERGE INTO "ObservationApriori" 
USING "ObservationAposteriori" ON 
"ObservationApriori"."id" = "ObservationAposteriori"."id" 
AND "end_point_name" IN ('11','12')
WHEN MATCHED THEN UPDATE SET 
"ObservationApriori"."sigma_0" = "ObservationAposteriori"."sigma_0";

Die zusätzliche Bedingung ist "end_point_name" IN ('11','12'). In der Klammer sind dann alle Punktnamen aufzuführen, die zu berücksichtigen sind - im Beispiel sind es die Punkte mit den Namen 11 und 12. Statt nach bestimmten Punkten einzuschränken könnte man auch nach Namen suchen, die mit einem Prefix beginnen. Hier gibt es jetzt recht viele Möglichkeiten.

Das aber nur als Ergänzung.

Viele Grüße
Micha

--
applied-geodesy.org - OpenSource Least-Squares Adjustment Software for Geodetic Sciences

Tags:
SQL, Unsicherheit, Script, Statement

RSS Feed of thread