wir hatten schon einmal das Thema in 2023 und ich bin nach Jahren der Untätigkeit hier wieder dran.

Kannst du mir das Beispiel von Wetzel zukommen lassen, dass ich mir das noch einmal näher betrachten kann?

Gern als fertiges Jag3D Projekt und auch die Rohmessdaten und GNSS Fest-/Neupunkte.

Noch eine weitere Frage:
Wie werden die Basislinien verarbeitet? In WGS84 DeltaY,DeltaX,DeltaZ oder als lokal kartesische Koordinaten Nord,Ost,Höhe?

Bsp. WGS84 DeltaY,DeltaX,DeltaZ:
0082 0101 -20206.6154 18466.4881 -10908.0587
0082 0101 -20206.6140 18466.4930 -10908.0494
0082 0101 -20206.6143 18466.4906 -10908.0561
0082 0101 -20206.6165 18466.4898 -10908.0568

Bsp. lokal kartesische Koordinaten:
0082 0101 -17534.0441 -23682.5053 -31.1746
0082 0101 -17534.0385 -23682.5009 -31.1831
0082 0101 -17534.0328 -23682.5009 -31.1806
0082 0101 -17534.0249 -23682.5110 -31.1401

LG
Stefan

kannst du bitte prüfen, ob hier ein Bug im Programm vorliegt.
Ich rechne eine 3D Netzausgleichung. Wenn ich die Datumsgebenden Neupunkte zu Bewegliche Anschlusspunkte verschiebe,

dann UTM einstelle,

kommt diese Fehlermeldung.

Ich habe folgende Messelemente verwendet.

Das kann ja eigentlich nicht sein?

LG
Stefan

I hope you are doing well.

First of all, I would like to thank you for the excellent software you have developed. JAG3D has been a great help to me in my research, and I really appreciate the work and effort that you have put into developing it.

I am currently working with JAG3D 2026 and I would like to obtain the actual matrices used internally during the least-squares adjustment.

Specifically, I am looking for the design/Jacobian matrix 𝐴,the weight matrix 𝑃 and, if possible, the normal equation matrix 𝑁.

I am not looking for the posterior variance-covariance matrix of the adjusted parameters. I need the actual 𝐴 and 𝑃 matrices used during the adjustment, with the same row and column ordering as used internally by JAG3D.

Is there a way to export these matrices from JAG3D 2026, or are they stored somewhere in the HSQLDB project database?

If they are not stored in the database, could you please point me to the Java class or method in the source code where these matrices are formed? I would like to extract them for further analysis as part of my research.

Thank you very much for your time and for developing JAG3D.

Best regards,

Nemanja

Came upon this bug when importing GSI data measured by total station:

1. import GSI data sorted by station id
2. measurements used for free station are carried into measurements carried out on previous station
3. i have to delete these measurements for every station

Please see attached images and GSI data https://drive.google.com/drive/folders/19NUl75OcbtaFzidkIbQlelMgv3sgqLp5?usp=sharing

Thanks.

Martin

first of all, apologies about this long post.

I'm working on an application that inserts a gyrotheodolite-derived azimuth (final result including its combined standard uncertainty u_Az) as an additional direction observation into an existing JAG3D project (observation group type "Direction", with the orientation unknown disabled so that the value acts as an absolute azimuth). The goal is to simulate how much a network (or a tunnel traverse chain) is tensioned or relaxed by this single additional observation.

What I'm not sure about is how JAG3D should, internally, most sensibly handle the two limiting cases:

1) σ of the gyro direction observation → 0 (essentially a "hard constraint"):
- Does this effectively only fix the azimuth relationship between the start and end point, while both points otherwise remain free (translation, connection to the rest of the network)? Or is there, in practice/in the source code, a different treatment (e.g. one of the two points effectively behaving like a datum point)?
- Is there a known numerical lower bound for σ below which the normal equation system becomes unstable/singular? I'm currently only guarding this with a small floor (e.g. 1e-12), but I'm not sure if that matches the approach you'd recommend.

2) σ as a real, finite value (derived from an uncertainty budget combining several components):
- During the adjustment, how is the "tension" from this one direction observation distributed across the other observations connected to the start/end points? Does it depend purely on the weight/redundancy of the overall configuration, or is there any preferential treatment of the start point vs. the end point?

3) For the specific use case (gyro azimuth lines along a tunnel drive, some with and some without a forced connection to known points): from your perspective, what would be the methodically cleanest way to introduce such an observation – a highly weighted pseudo-observation with a very small σ, a real observation with a realistic σ, or rather a true constraint equation/datum point construction instead of a weighted observation?

Thank you very much in advance for your input!

Best regards