I had a similar issue where after reimport from a txt file the changes that I made had been imported to a different cave. So it looked like the import didnt work but the data was actually just at a different cave that I didnt check at first. When looking at the txt file after export I noticed that the fields for 'Höhle' already had incorrect values, which means the issue stems from a bug in the export process.

I also had cases where part of the data in my txt file was from one cave and another part was from another cave, even though I had only exported a single cave. After reimport each batch of data was imported to its respective cave. This led to a cave getting duplicate data without me noticing at first. I can not reproduce these issues at the moment.

Another potential source for Thomas issue could be this: If my CRP project file has multiple caves where the field 'Höhlendaten - Höhle' is not filled out, the reimport will always happen at the first cave in the list that also does not have 'Höhlendaten - Höhle' filled out.

I could not reproduce this issue. There seems to be more steps involved to reach this outcome.

Zitat von CaveRenderPro im Beitrag #34

---

Das Ergebnis aus CaveRenderPro und deinem Skript sieht bei einer Testdatei annähernd gleich aus:

---

function Standard_Formel (Azimut_vor_bereinigt, Azimut_nach_bereinigt, Azimut, SpalteL){
                            var SpalteE_raw = Math.abs(Azimut_vor_bereinigt - Azimut);
                            var SpalteE = Math.abs(SpalteE_raw - 180);
                            if (Azimut_nach_bereinigt - 180 >= 0){
                                var Azimut_nach_bereinigt2 = Azimut_nach_bereinigt - 180;
                            }else{
                                Azimut_nach_bereinigt2 = Azimut_nach_bereinigt + 180;
                            }
                            var SpalteG_raw = Math.abs(Azimut_nach_bereinigt2 - Azimut);
                            var SpalteG = Math.abs(SpalteG_raw - 180);
                            if(SpalteE === 0 || SpalteG === 0){
                                var SpalteK = 0;
                            }else if(SpalteE/SpalteG <= 1){
                                SpalteK = SpalteE/(SpalteE+SpalteG);
                            }else{
                                SpalteK = SpalteG/(SpalteE+SpalteG);
                            }
                            if(SpalteE < SpalteG){
                                SpalteL = SpalteK*Math.cos(degreeToRadians(Azimut_nach_bereinigt - Azimut))+(1 - SpalteK)*Math.cos(degreeToRadians(Azimut_vor_bereinigt - Azimut));
                            }else{
                                SpalteL = SpalteK*Math.cos(degreeToRadians(Azimut_vor_bereinigt - Azimut))+(1 - SpalteK)*Math.cos(degreeToRadians(Azimut_nach_bereinigt - Azimut));
                            }
                            return SpalteL;
                        }
 

Der Kern der Berechnung hier ist das hier: SpalteL = SpalteK*Math.cos(degreeToRadians(Azimut_nach_bereinigt - Azimut))+(1 - SpalteK)*Math.cos(degreeToRadians(Azimut_vor_bereinigt - Azimut))
Hier wird deine alte default-Lösung abgeändert als Kombination vom Kosinus beider Messzüge jeweils nach einem Prozentsatz (SpalteK) entsprechend der Abweichung in Grad der Hilfslinie von den beiden Messzügen.

Ich hoffe, wir können gemeinsam eine Lösung finden. Das Thema liegt mir am Herzen. Ich habe viel Zeit investiert.

Ich bitte um Entschuldigung. Ich habe den Fehler behoben, es sollte jetzt wieder funktionieren.
Bitte versuche es nochmal.

Ja, das liegt daran, dass ich in der Version 1.1 die @match, die vorher google.com/google.de etc waren, entfernt habe. Änderungen bei der Google Homepage hatten dazu geführt, dass mein Script nicht mehr funktioniert hat.

Sorry, mein Fehler.


Edit: Ich habe das Script nochmal umgeschrieben, sodass es auf google.com oder in der Konsole ausgeführt werden kann.

Ich habe jetzt JavaFX 21 und OpenJDK 21 installiert und teste die neue CaveRenderPro Beta-Version.

Ich habe auch festgestellt, dass mein Script in google.com nicht mehr funktioniert.

Ich habe das Script jetzt umgeschrieben, sodass es stattdessen im Browser in einem leeren Fenster in der Konsole ausgeführt werden soll.

Jochen, bitte teste auch du ein paar Höhlen von dir mit meinem aktualisierten Script

Ich verstehe nicht ganz. Du möchtest aus dem Querschnitt die Richtung der Hilfslinien im Längsschnitt berechnen?
Existiert diese Funktion bereits und man kann sie in einem zukünftigen Release testen, oder muss sie erst entwickelt werden?

Zitat

---

[...] eine Hilfslinie, die den exakt gleichen Azimut wie der nachfolgende Messzug hat, nicht den Wert 1 im Datenfeld Richtung bekommt, obwohl sie das müsste.

---

Ich denke, dieses Problem würde dann auftreten, oder nicht?

[[File:Winkelhalbierende.jpg|none|400px|400px]]

Wenn ich dich richtig verstanden habe, dann wäre in diesem Beispiel die rote Linie die Winkelhalbierende.
Eine Hilfslinie, die exakt den gleichen Azimut hat wie die Winkelhalbierende, würde mit deinem Vorschlag im Feld Richtung den Wert 1 bekommen. Das wäre natürlich falsch, da wir den Wert 0 erwarten.

Wenn wir stattdessen die blaue Linie verwenden, haben wir das Problem, dass eine Hilfslinie, die den exakt gleichen Azimut wie der nachfolgende Messzug hat, nicht den Wert 1 im Datenfeld Richtung bekommt, obwohl sie das müsste.


Es scheint mir, du möchtest eine eigene Lösung entwickeln. Ist es schwierig, mein Script von JavaScript in Java umzuschreiben oder bist du mit dem Rechenweg nicht einverstanden?

Raumschüsse Fix für CaveRenderPro - Release 1.0

Ich hatte dieses Projekt aus den Augen verloren und habe im Moment auch nicht die Motivation, hier an der "Dokumentation" weiter zu schreiben. Ist wahrscheinlich eh unnötig.
Allerdings habe ich im letzten Monat ein Script geschrieben, welches beide Formeln aus meinen Excel-Tabellen automatisch auf eine exportierte Datentabelle anwendet.

Dadurch wird enorm viel Zeit gespart im Vergleich zum manuellen Eintippen in die Tabelle. Ich würde sagen, erst jetzt sind meine Formeln wirklich sinnvoll anwendbar.

Das Script wird im Browser ausgeführt und wurde in Javascript geschrieben. Ich habe Programmieren nie wirklich traditionell gelernt, habe nie ein Tutorial gemacht, bin aber über Jahre hinweg per Copy&Paste und Herumprobieren gut genug geworden, um etwas auf die Beine zu stellen, das funktioniert.


Bevor ich nochmal eine Woche an Kleinigkeiten rumschraube, möchte ich es direkt hier zugänglich machen.

Raumschüsse Fix für CaveRenderPro


Beide Formeln der Excel-Tabellen werden fehlerfrei umgesetzt für Raumschüsse/Hilfslinien mit einem, zwei oder beliebig vielen verbundenen Messzügen. Alle Kombinationen aus Vorwärts- und Rückwärtsmessung. Alle Kombinationen aus Werten im Datenfeld Richtung der Messzüge 1 oder -1.

Werte im Datenfeld Richtung der Messzüge ungleich 1 oder -1 werden im Moment noch ignoriert. Schächte werden im Moment nicht gesondert betrachtet. Es gibt also noch Dinge, die man besser machen könnte. Auch scheint mir die Sonderfall-Formel der zweiten Excel-Tabelle mit einem extrem seltenen Fall nicht richtig klarzukommen. Da müsste man auch nochmal nachbessern.

Insgesamt führt dieses Script aber für 95% der Raumschüsse eine deutlich verbesserte Darstellung im Längsschnitt herbei. Und das in nur wenigen Sekunden.


Es würde mich freuen, Jochen, wenn du diese Funktion in CaveRenderPro aufnimmst. Dann wäre das Ganze nochmal schneller.

Heute war STRG+Z und STRG+Y wieder vertauscht. Ich hätte jetzt ein Video davon, aber die Ursache ist weiterhin unklar.

Select the text then Alt + Scrollwheel for slow rotation or Ctrl + Alt + Scrollwheel for fast rotation.

Text on a curved line is not an option yet, but I hope it will be added in the future. I placed single letters and rotated them individually to simulate this effect.

[[File:curved_text.jpg|none|300px|300px]]

Ich kenne da nur den DistoX2.

Teil 18 - So funktioniert die neue Sonderfall-Formel - Die Spalten J und K

In den Spalten J und K wird überprüft, ob der Azimut des Raumschusses in einem der beiden Winkel Alpha aus Abb. 17 liegt und für diesen Fall ein Wert ausgegeben.


Spalte J enthält die Formel =WENN(UND(H1+I1=E1;D1=-1);1;WENN(UND(H1+I1=E1);-1;0))

Diese Formel gibt 0 als Ergebnis aus, wenn der Azimut des Raumschusses nicht in dem roten Winkel Alpha aus Abb. 17 liegt.

Diese Formel gibt 1 als Ergebnis aus, wenn der Azimut des Raumschusses im roten Winkel Alpha liegt und die Klapprichtung des vorherigen Messzuges (Spalte D) gleich -1 ist.

Diese Formel gibt -1 als Ergebnis aus, wenn der Azimut des Raumschusses im roten Winkel Alpha liegt und die Klapprichtung des vorherigen Messzuges (Spalte D) gleich 1 ist.

Wenn hier 1 oder -1 ausgegeben wird handelt es sich bei diesem Teilergebnis für Winkel Beta größer gleich 90° bereits um das Endergebnis.


Spalte K enthält die Formel =WENN(UND(F1+G1=E1;D1=-1);-1;WENN(UND(F1+G1=E1);1;0))

Diese Formel gibt 0 als Ergebnis aus, wenn der Azimut des Raumschusses nicht in dem grünen Winkel Alpha aus Abb. 17 liegt.

Diese Formel gibt 1 als Ergebnis aus, wenn der Azimut des Raumschusses im grünen Winkel Alpha liegt und die Klapprichtung des vorherigen Messzuges (Spalte D) gleich 1 ist.

Diese Formel gibt -1 als Ergebnis aus, wenn der Azimut des Raumschusses im grünen Winkel Alpha liegt und die Klapprichtung des vorherigen Messzuges (Spalte D) gleich -1 ist.

Wenn hier 1 oder -1 ausgegeben wird handelt es sich bei diesem Teilergebnis für Winkel Beta größer gleich 90° bereits um das Endergebnis.


Die Teilformeln H1+I1=E1 aus Spalte J und F1+G1=E1 aus Spalte K eignen sich hervorragend, um verlässlich festzustellen, ob der Azimut des Raumschusses innerhalb eines der beiden Winkel Alpha aus Abb. 17 liegt.
Der Winkel Alpha, der in Spalte E berechnet wird, ergibt sich aus den Teilwinkeln der Spalten H und I bzw. F und G, wenn dies der Fall ist.

Skalieren geht bei diesen Symbolen tatsächlich nicht.
Also nicht direkt, aber es gibt da einen "Umweg".


Beispiel Wandsinter:
Unter Datei - Einstellungen - Symbole kannst du mit der rechten Maustaste auf Wandsinter klicken, dann NEU auswählen.
In die Felder des neuen Symbols kannst du die gleichen Werte wie bei Wandsinter rüber kopieren, dann den Wert für Größe ändern.
Die Felder Bezeichnung und Symbol müssen von bereits bestehenden Symbolen abweichen.

Hier befindet sich auch das Kästchen Drehbar, wo du ein Häkchen reinmachen musst, falls noch keins drinnen ist und du das Symbol drehen möchtest.

Ich nutze fast ausschließlich die Längsschnitt-Darstellung, weil damit alle Höhlenteile proportional korrekt dargestellt werden, während im Profil fast immer Teile der Höhle verkürzt werden, die von der Profil-Ebene abweichen.

Im Längsschnitt wird an jedem einzelnen Messpunkt quasi ein anderes Profil angesetzt, sodass alle Messstrecken mit voller Länge dargestellt werden.
Der Nutzer muss allerdings manuell einzelne Messzüge "umklappen", damit das Gesamtbild nicht falsch und verzerrt aussieht.
Dazu klickt man in der Längsschnitt-Darstellung mit der rechten Maustaste auf einen Messpunkt und wählt Richtung aus, damit die Richtung der Strecke zu diesem Messpunkt umgekehrt wird.

Um einen ganzen Gang umzuklappen, wählt man alle Messzüge (und Hilfslinien) dieses Ganges in der Datentabelle aus. Dann kann man unter Daten - Ersetzen in dem Feld Spalte "Richtung <->" auswählen und mit einem Klick auf "Ersetzen" bestätigen.

Kompliziert wird die Darstellung des Längsschnitt, wenn eine labyrinthartige Höhle sehr viele Abzweigungen aufweist, von denen viele wieder zum Hauptgang zurückführen. In so einem Fall kann man die Höhle fast nicht als Ganzes im Längsschnitt darstellen und muss sie in einzelne Abschnitte unterteilen.

Unter Grafik - Profil gibt es links unten im Höhlendaten-Dialog das Feld Azimut Profil. In diesem Feld können Sie die gewünschte Blickrichtung einstellen. Es können Werte zwischen 0 und 359 eingegeben werden.
Für eine Ansicht von W nach O wäre das der Wert 90.

Benutzen Sie gelegentlich auch die Darstellungs-Variante Grafik - Längsschnitt?

Teil 17 - So funktioniert die neue Sonderfall-Formel - Die Spalten F, G, H und I

In den Spalten F bis I werden die Winkel zwischen der Richtung (Azimut) des Raumschusses (Hilfslinie) und den vier Strecken aus Abbildung 17 berechnet.

Spalte H enthält die gleiche Formel wie in Teil 5 der neuen generellen Formel.

Spalte I enthält die gleiche Formel wie in Teil 6 der neuen generellen Formel.

Spalte F enthält die Formel =180-H1 und berechnet damit den anderen Winkel zu 180 Grad.

Das Ergebnis dieser Formel beschreibt den Winkel (in Grad) zwischen der Richtung (Azimut) des vorherigen Messzuges und der Richtung (Azimut) des Raumschusses.

Spalte G enthält die Formel =180-I1 und berechnet damit den anderen Winkel zu 180 Grad.

Das Ergebnis dieser Formel beschreibt den Winkel (in Grad) zwischen der invertierten Richtung (Azimut) des nachfolgenden Messzuges und der Richtung (Azimut) des Raumschusses.

Teil 16 - Das Grundkonzept der Sonderfall-Formel

Als Beispiel dient wieder die Situation aus Abbildung 9.
[[File:beispiel1.jpg|none|300px|300px]]
Abb. 12: Vereinfachte Grundriss-Darstellung
[[File:beispiel2.jpg|none|300px|300px]]
Abb. 13: Stark vereinfachte Grundriss-Darstellung
[[File:beispiel3.jpg|none|300px|300px]]
Abb. 14: Wenn man die Linien verlängert, ergibt sich dieses Bild. Es entstehen 4 Winkel, jeweils 2 davon sind gleich groß.
[[File:beispiel4.jpg|none|300px|300px]]
Abb. 15: Zum Vergleich hier die vereinfachte Längsschnitt-Darstellung. Daraus ergibt sich für unser Beispiel, dass sowohl für Raumschüsse, die entgegen der Richtung (Azimut) des vorherigen Messzuges verlaufen, als auch für solche, die exakt in Richtung (Azimut) des nachfolgenden Messzuges zeigen ein Wert von -1 für das Datenfeld Richtung.
[[File:beispiel5.jpg|none|300px|300px]]
Abb. 16: (Grundriss-Darstellung) Analog dazu bekommen Raumschüsse, die exakt in Richtung der dagegen um 180 Grad invertierten grünen Linien zeigen den Wert 1.
Da sich die Höhlenentstehung meist an Klüften orientiert, kann man den Nutzen dieses Modells karstmorphologisch begründen. Die mathematische Begründung, wenn sie denn richtig ist, läuft darauf hinaus, dass man mehrere Profile auf eine einzelne Betrachtungsebene klappt.
[[File:beispiel6.jpg|none|300px|300px]]
Abb. 17: Des Weiteren ergibt sich für alle Raumschüsse, die zwischen den beiden roten Messzügen liegen ein Wert von -1, sowie ein Wert von 1 für alle Raumschüsse im gegenüberliegenden Winkel. Begründet wird dies dadurch, dass sonst die Darstellung im Längsschnitt künstlich verkürzt würde. Der Winkel Alpha wird in Spalte E berechnet. Der Winkel Beta wird in Spalte L berechnet.
Die Raumschüsse, die innerhalb des Winkels Beta liegen, bekommen den Wert für das Datenfeld Richtung mit dem Cosinus berechnet.

Diese Methode eignet sich für Winkel Beta größer gleich 90°. Ein Teilergebnis, welches für alle diese Fälle bereits identisch mit dem Endergebnis ist, wird in Spalte R ausgegeben.