Kongruenzanalyse mit der Koordinatenmethode - Java·Applied·Geodesy·3D

Hallo zusammen,

ich habe eine Frage zur Kongruenzanalyse mit der Koordinatenmethode.

Ich habe zwei Vergleichsepochen als bewegliche Anschlusspunkte importiert, eine Tabelle mit identischen Punkten ist auch definiert und in den Einstellungen habe ich den Haken gesetzt. Die "Waschmaschine" läuft ohne Fehlermeldung durch, aber die Ergebnistabelle bei den Objektpunktpaaren bleibt leer.

Es ist die aktuelle JAG3D-Version installiert.

Ich wäre froh, wenn mir jemand einen Hinweis geben könnte, wo mein Fehler liegen könnte.

Grüße

H-1

Hallo,

Ich habe zwei Vergleichsepochen als bewegliche Anschlusspunkte importiert, eine Tabelle mit identischen Punkten ist auch definiert und in den Einstellungen habe ich den Haken gesetzt.

Die Deformationsanalyse erwartet eine freie Netzausgleichung. Die Punkte, die als stabil angesehen werden, müssten demnach als Datumspunkte definiert werden. Objektpunkte sind Neupunkte und müssen epochengetrennt importiert werden. Zusätzlich sind die Beobachtungen der jeweiligen Epoche zuzuordnen. Für deren Vergleich und Bewertung sind dann die Punktpaare zu spezifizieren.

Ich hoffe, dass hilft Dir erst einmal weiter.

Viele Grüße
Micha

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

Tags:
JAG3D, Punkte, Deformationsanalyse

Leider stockt es immer noch.

Ich habe die einfache Variante ohne Beobachtungen gewählt. Jeweils eine Koordinatendatei mit Standardabweichung als bewegliche Anschlusspunkte. Die Variante mit Datumspunkten funktioniert auch nicht.

Die Punktnummern sind unterschiedlich und werden über die Liste der identischen Objektpunktpaare definiert.

Ich möchte einen einfachen Epochenvergleich unter Berücksichtigung der unterschiedlichen Standardabweichungen der jeweiligen Epochen durchführen.

Dieses Verfahren habe ich bereits bei ähnlichen Projekten mit JaG3D erfolgreich angewendet und mich bei der Konstruktion natürlich daran orientiert. Leider klappt es diesmal nicht, im Reiter Kongruenzanalyse der Punkte sind nur leere Spalten.

Datei sieht so aus

I- 999.9996 1253.3606 306.2909 0.0003 0.0002 0.0002
II- 999.9994 1000.0003 306.2207 0.0003 0.0002 0.0002
III- 865.6639 1245.0401 308.8957 0.0003 0.0003 0.0004
IV- 1037.7492 1124.5129 281.8880 0.0002 0.0003 0.0003
V- 911.6364 1005.8581 306.0702 0.0003 0.0002 0.0002
AL1- 998.1775 1154.7834 304.6529 0.0004 0.0004 0.0003
AL2- 998.2483 1094.5009 304.6492 0.0004 0.0004 0.0003
1.1- 1006.5423 1056.2973 303.4740 0.0004 0.0004 0.0006
1.2- 1008.2489 1056.6981 295.5909 0.0004 0.0004 0.0006
2.1- 999.9552 1094.4562 303.4118 0.0004 0.0003 0.0005
2.2- 1000.9830 1094.5842 295.3600 0.0004 0.0003 0.0005
2.3- 1004.1044 1094.8993 288.3508 0.0004 0.0003 0.0005
3.1- 997.5227 1127.0250 304.2220 0.0004 0.0003 0.0005
4.1- 1000.0176 1154.9562 303.3986 0.0004 0.0003 0.0005
4.2- 1000.8910 1154.8354 295.5617 0.0004 0.0003 0.0005
4.3- 1003.8863 1154.3969 288.2319 0.0004 0.0003 0.0005
5.1- 1006.4454 1192.3248 303.0800 0.0004 0.0004 0.0006
5.2- 1007.9560 1191.8223 295.2783 0.0004 0.0004 0.0006
HPL- 1021.0820 1231.1841 305.9176 0.0003 0.0002 0.0003
HPR- 1018.6706 1023.4758 305.9157 0.0003 0.0002 0.0003

Nr. 2

I 1000.0000 1253.3604 306.2911 0.0003 0.0002 0.0002
II 999.9997 1000.0001 306.2206 0.0003 0.0002 0.0002
III 865.6632 1245.0404 308.8949 0.0003 0.0003 0.0004
IV 1037.7489 1124.5126 281.8879 0.0002 0.0002 0.0003
V 911.6365 1005.8585 306.0702 0.0003 0.0002 0.0002
AL1 998.1738 1154.7827 304.6549 0.0003 0.0003 0.0003
AL2 998.2448 1094.5008 304.6516 0.0003 0.0003 0.0003
1.1 1006.5406 1056.2961 303.4752 0.0003 0.0003 0.0005
1.2 1008.2494 1056.6968 295.5912 0.0004 0.0004 0.0006
2.1 999.9517 1094.4558 303.4133 0.0003 0.0003 0.0005
2.2 1000.9809 1094.5837 295.3606 0.0003 0.0003 0.0005
2.3 1004.1036 1094.8989 288.3513 0.0003 0.0003 0.0005
3.1 997.5182 1127.0248 304.2239 0.0003 0.0003 0.0005
4.1 1000.0138 1154.9565 303.4002 0.0003 0.0003 0.0005
4.2 1000.8894 1154.8357 295.5625 0.0003 0.0003 0.0005
4.3 1003.8858 1154.3969 288.2325 0.0003 0.0003 0.0005
5.1 1006.4428 1192.3253 303.0813 0.0003 0.0003 0.0005
5.2 1007.9546 1191.8226 295.2789 0.0003 0.0003 0.0005
HPL 1021.0822 1231.1842 305.9188 0.0003 0.0002 0.0003
HPR 1018.6711 1023.4747 305.9165 0.0003 0.0002 0.0003

Die identischen Punkte:

I I-
II II-
III III-
IV IV-
V V-
AL1 AL1-
AL2 AL2-
1.1 1.1-
1.2 1.2-
2.1 2.1-
2.2 2.2-
2.3 2.3-
3.1 3.1-
4.1 4.1-
4.2 4.2-
4.3 4.3-
5.1 5.1-
5.2 5.2-
HPL HPL-
HPR HPR-

Hallo,

Leider stockt es immer noch.

Kannst Du das Projekt (die Datenbankdateien des Projektes) temporär irgendwo (bspw. Dropbox) hochladen und zum Download breitstellen, sodass ich einen Blick drauf werfen kann?

Viele Grüße
Micha

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

Guten Abend,

ich habe die Datenbank erhalten - antworte aber hier im Forum, um den Thread nicht zu zerreißen.

Das Problem ist tatsächlich etwas tricky, muss ich gestehen. Bei der Definition der Punktpaare sind nicht-sichtbare Zeichen vorhanden. Ich habe mir die Vektoren mal direkt aus der Datenbank exportiert und angesehen. Man erhält:

[image]

Dies sieht ganz normal aus aber wenn man sich auch die nicht-sichtbaren Zeichen (wie bspw. Zeilenumbrüche) mit einblendet, dann sieht man folgendes:

[image]

Der Zeilenumbruch besteht aus den beiden Zeichen CR und LF. Ein normales Leerzeichen ist so ein gelber Punkt. Die ganzen NUL sind ein nicht-sichtbares Zeichen. Und natürlich ist bspw. 1.1 nicht identisch mit 1NUL.NUL1NUL womit das Paar nicht gefunden wird.

Um das Problem in Deinem Fall zu lösen, musste ich in JAG3D nur kurz in die jeweilige Tabellenzelle der Punktnamen (Referenzpunkt, Kontrollpunkt) klicken, um in den Editiermodus zu gelangen, und dann mit Enter diesen wieder verlassen. Editieren musste ich also nichts. Die Punkte werden dann noch einmal in der DB gespeichert ohne diese nicht-sichtbaren Zeichen. Probiere es mal für ein, zwei Punktpaare aus und führe die Berechnung dann durch. Die editierten Zeilen sollten dann auch Werte enthalten.

Wie wurden die Punktpaare importiert bzw. erstellt? Wurde hierzu eine Datei importiert und wenn ja, existiert diese Datei noch?

Viele Grüße
Micha

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

Tags:
JAG3D, Datenbank, non-printable Unicode character

Hallo Micha

vielen Dank für die schnelle Hilfe und den Tipp.

Diesen Showstopper hätte ich nie gefunden!

Mein Workflow läuft über EXCEL, dort erstelle ich die Koordinatendateien, dort erfolgt auch die Konvertierung der Punktnummern für Referenz- und Kontrollepoche über eine Verkettungsfunktion. Anschließend werden über ein VBA-Makro Textdateien erzeugt, die in JAG3D importiert werden.

Die Abseitsfalle habe ich in enger Zusammenarbeit mit meinem Standard-Windows-Editor aufgebaut. Der Schurke hat heimlich im UNICODE-Format gespeichert. Mit dem ANSI-Format klappt alles wie gewünscht.

Grüße H1

Hallo,

Diesen Showstopper hätte ich nie gefunden!

Ich musste auch etwas suchen, bis ich die Ursache hatte. Um dieses Problem zukünftig zu minimieren, habe ich eine Routine in der aktuellen JAG3D Version eingebaut, die nicht-druckbare Unicode Zeichen herausfiltert. Die aktuelle Version ist wiederum über GitHub verfügbar: JAG3D Download.

Beste Grüße
Micha

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

Tags:
JAG3D, v20241009, Unicode, Download

Hallo Micha

Hab gerade die neue Version installiert. Jetzt klemmt bei mir der Import von Textdateien, da kommt nichts an. Seit dem Showstopper ist bei mir ist jetzt alles auf streng auf ANSI eingestellt...GSI Import funktioniert wie gehabt.

Vielleicht ist bei mir was beim Download schief gelaufen. Vielleicht kann ein anderer User noch mal Feedback geben.

Guten Abend,

Jetzt klemmt bei mir der Import von Textdateien, da kommt nichts an. Seit dem Showstopper ist bei mir ist jetzt alles auf streng auf ANSI eingestellt...GSI Import funktioniert wie gehabt.

Ah, da war meine Implementierung zu streng. Du hast nur Tabulatoren als Trennzeichen, oder? Kannst Du mal bitte den folgenden Release-Kandidaten ausprobieren? JAG3Dv20241011_Windows.zip
Wenn es damit auch nicht geht, benötige ich die Datei(en) mal, die nicht gehen. Ich weiß sonst nicht, wie ich diesen Fall nachstellen soll. Formal funktioniert zumindest bei mir der Import nun ganz normal. Wenn es bei Dir auch geht, aktualisiere ich die Version auf GitHub.

Ich speichere im Übrigen alles in UTF-8 und würde dies auch empfehlen, insbesondere weil hier alle Sonderzeichen mit enthalten sind. Das Problem ist auch weniger die Kodierung, sondern mehr der Inhalt der Datei gewesen: Die Punktnamen waren hierdurch nicht identisch (auf Bitebene).
Wenn die Datei keine nicht-druckbaren Zeichen enthält, gibt es auch keine Probleme. Diese Zeichen kommen aber nicht durch die Kodierung selbst sondern wurden (unbewusst) beim Erzeugen/Schreiben eingefügt. UTF-8 bietet nur die Möglichkeit, solche Zeichen abzubilden.

Viele Grüße
Micha

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

Hallo Micha,

Testimport mit meinen Textdateien (mit TAB-Trennung) durchgeführt. Fungiert jetzt alles einwandfrei :-)

Danke für die schnelle Hilfe und Reaktion. Das ist nicht selbstverständlich.

Schönes Wochenende

Hallo Micha,

Testimport mit meinen Textdateien (mit TAB-Trennung) durchgeführt. Fungiert jetzt alles einwandfrei

Super, Danke für die Rückmeldung. Ich habe die modifizierte Version heute online gestellt: JAG3Dv20241011

Schönes Wochenende
Micha

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

Tags:
JAG3D, v20241011

RSS Feed of thread