in diesem Zusammenhang stellt sich jetzt eine weitere Frage, vielleicht weiß jemand, wie ich das lösen kann:
Wenn ich eine Liste nach bestimmten Kriterien durchsuche und erhalte mehrere Ergebnisse. Ich will aber nur mit der ersten gefundenen Lösung weiterarbeiten und alle anderen vernachlässigen.
Wie kann ich das ausdrücken?
Vielen Dank für die Hilfe!
Durchlauf durch Liste und Vergleich der Einträge
Vielleicht möchtest du es einfach mal selber versuchenMichi_J hat geschrieben:kann ich auch die Suche trotzdem fertig laufen lassen, aber nur den ersten gefundenen Eintrag in eine andere Liste schreiben? Wie würde das funktionieren?
Ich glaube mit dem Index, oder?
Das Leben ist wie ein Tennisball.
-
BlackJack
@Michi_J: Falls die Frage tatsächlich lautet "Wie greife ich auf das erste Element einer Liste zu?", solltest Du vielleicht nochmal ein Grundlagentutorial durcharbeiten.
(zum Glück)ich hab mich jetzt mal damit beschäftigt, wie ich diese Nachbarschaftsbeziehung auf die Reihe kriegen könnte.
Nachfolgend auch mein Code, ich weiß er wird noch fehlerhaft sein... Vielleicht kann mir ja jemand einen weiteren Denkanstoß geben.
ist das ganze so sehr abwägig? Jedenfalls stürzt mein Computer bei jedem Durchlauf ab, von dem her eher schon...
Vielleicht kann mir ja wirklich jemand wieder weiterhelfen (wie schon so oft...)
Danke!
Nachfolgend auch mein Code, ich weiß er wird noch fehlerhaft sein... Vielleicht kann mir ja jemand einen weiteren Denkanstoß geben.
Code: Alles auswählen
while (not(in_o_n_doppelt_o()) and not(in_o_n_doppelt_n())):
#mit den Funktionen in_o_n_doppelt_o und in_o_n_doppelt_n soll überprüft werden, ob ein Owner oder Neighbour zweimal vorkommt. Wenn jeder Eintrag nur noch einmal auftritt, so ist das Abbruchkriterium erfüllt.
#nun soll verglichen werden: e2 sind die Nachbarn von e1 und werden in eine Nachbarliste eingelesen.
for e1 in Endliste4:
for e2 in Endliste4:
if e1[1][0][1][1] == e2[1][0][1][1] and e1[1][1][1][1] == e2[1][1][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
if e1[1][0][1][1] == e2[1][2][1][1] and e1[1][1][1][1] == e2[1][3][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
if e1[1][0][1][1] == e2[1][4][1][1] and e1[1][1][1][1] == e2[1][5][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
if e1[1][2][1][1] == e2[1][2][1][1] and e1[1][3][1][1] == e2[1][3][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
if e1[1][2][1][1] == e2[1][0][1][1] and e1[1][3][1][1] == e2[1][1][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
if e1[1][2][1][1] == e2[1][4][1][1] and e1[1][3][1][1] == e2[1][5][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
if e1[1][4][1][1] == e2[1][4][1][1] and e1[1][5][1][1] == e2[1][5][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
if e1[1][4][1][1] == e2[1][0][1][1] and e1[1][5][1][1] == e2[1][1][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
if e1[1][4][1][1] == e2[1][2][1][1] and e1[1][5][1][1] == e2[1][3][1][1] and e1[0] <> e2[0]:
neighbour.append(e2)
#nun greife ich mir ein erstes Element raus und füge es der Liste owner_neighbour hinzu.
erster_Nachbar=neighbour[0]
n=random.choice(neighbour)
Paar1 = (e1[0], erster_Nachbar[0])
owner_neighbour.append(Paar1)
#nun gehe ich durch die Liste durch und vergleiche die Einträge, wenn die Bedingungen erfüllt sind, so fügt er das Elementepaar zur Liste owner_neighbour hinzu.
#das random.choice habe ich dafür benötigt, dass er im nächsten Durchlauf andere Nachbarn zum Vergleich heranzieht...
for m in owner_neighbour:
if not (m == (e1, n) or m == (n, e1)):
Paar = (e1[0], n[0])
owner_neighbour.append(Paar)
Vielleicht kann mir ja wirklich jemand wieder weiterhelfen (wie schon so oft...)
Danke!
-
BlackJack
@Michi_J: Das sieht alles sehr unverständlich und unwartbar aus.
`in_o_n_doppelt_o()`/`in_o_n_doppelt_o()`!? Das sind furchtbare Namen. Genau wie `Endliste4` oder `e1`/`e2`. Namen sollen dem Leser den Sinn des Wertes, der sich dahinter verbirgt, verraten. Wer weiss nach einem Jahr noch wofür ``e2[1][0][1][1]`` steht? Und wofür die ganzen Zwischenergebnisse bei dieser verschachtelten Indexierung!?
Bei den beiden Funktionen am Anfang, die ja anscheinend etwas überprüfen -- wie kommen die an die Daten die sie überprüfen? Es werden ja gar keine Argumente übergeben. Steht der Quelltext, den Du da zeigst, etwa auf Modulebene? Und suggeriert die 4 in `Endliste4`, dass da noch viel mehr Quelltext auf Modulebene davor steht? Das gehört in Funktionen. Und zwar aufgeteilt auf mehrere, so dass man nicht anfangen muss so endgültig klingende Namen wie `Endliste` durchzunummerieren.
Kann `e2` bei den ganzen ``if``\s eigentlich mehr als einmal an `neighbour` angehängt werden? Wenn grundsätzlich nur eine der Bedingungen zutreffen kann, sollte man das auch mit ``elif`` kenntlich machen, beziehungsweise könnte man dann auch ein einzelnes ``if`` daraus machen, bei dem die ganzen Bedingungen mit ``or`` verknüpft sind.
Den Vergleich mit ``<>`` sollte man übrigens nicht mehr verwenden, das ist "deprecated" und ist bei Python 3.x nicht mehr möglich.
Wenn es abstürzt, ist es natürlich keine Lösung. Aber auch sonst denke ich, ist der Weg nicht besonders gut. Wenn Du da per Zufall einen Nachbarn aussuchst und die Anzahl der "schlechten" Nachbarn für einen Weg hoch ist, dann läuft das "ewig", weil die Wahrscheinlichkeit einen schlechten Nachbarn zu erwischen, recht hoch ist. Und dann kann man ja beim Zufall auch nicht sicher sein, dass ein "schlechter" Nachbar nicht mehrfach in den Durchgängen ausgewählt wird -- da verfolgt man dann Wege, von denen man eigentlich schon wissen könnte, dass die nicht zum Ziel führen.
Es läuft IMHO letztlich auf eine Überarbeitung des Entwurfs hinaus. Das Ganze ordentlich auf Funktionen und Klassen verteilen. Ein bisschen Graphentheorie und Backtracking wurden ja auch schon mehrfach genannt. Wenn es viele Dreiecke gibt, also mehr als 500 möglich sind, würde ich den Stapel beim Backtracking selbst verwalten, weil Rekursion in CPython da an seine Grenzen stösst.
`in_o_n_doppelt_o()`/`in_o_n_doppelt_o()`!? Das sind furchtbare Namen. Genau wie `Endliste4` oder `e1`/`e2`. Namen sollen dem Leser den Sinn des Wertes, der sich dahinter verbirgt, verraten. Wer weiss nach einem Jahr noch wofür ``e2[1][0][1][1]`` steht? Und wofür die ganzen Zwischenergebnisse bei dieser verschachtelten Indexierung!?
Bei den beiden Funktionen am Anfang, die ja anscheinend etwas überprüfen -- wie kommen die an die Daten die sie überprüfen? Es werden ja gar keine Argumente übergeben. Steht der Quelltext, den Du da zeigst, etwa auf Modulebene? Und suggeriert die 4 in `Endliste4`, dass da noch viel mehr Quelltext auf Modulebene davor steht? Das gehört in Funktionen. Und zwar aufgeteilt auf mehrere, so dass man nicht anfangen muss so endgültig klingende Namen wie `Endliste` durchzunummerieren.
Kann `e2` bei den ganzen ``if``\s eigentlich mehr als einmal an `neighbour` angehängt werden? Wenn grundsätzlich nur eine der Bedingungen zutreffen kann, sollte man das auch mit ``elif`` kenntlich machen, beziehungsweise könnte man dann auch ein einzelnes ``if`` daraus machen, bei dem die ganzen Bedingungen mit ``or`` verknüpft sind.
Den Vergleich mit ``<>`` sollte man übrigens nicht mehr verwenden, das ist "deprecated" und ist bei Python 3.x nicht mehr möglich.
Wenn es abstürzt, ist es natürlich keine Lösung. Aber auch sonst denke ich, ist der Weg nicht besonders gut. Wenn Du da per Zufall einen Nachbarn aussuchst und die Anzahl der "schlechten" Nachbarn für einen Weg hoch ist, dann läuft das "ewig", weil die Wahrscheinlichkeit einen schlechten Nachbarn zu erwischen, recht hoch ist. Und dann kann man ja beim Zufall auch nicht sicher sein, dass ein "schlechter" Nachbar nicht mehrfach in den Durchgängen ausgewählt wird -- da verfolgt man dann Wege, von denen man eigentlich schon wissen könnte, dass die nicht zum Ziel führen.
Es läuft IMHO letztlich auf eine Überarbeitung des Entwurfs hinaus. Das Ganze ordentlich auf Funktionen und Klassen verteilen. Ein bisschen Graphentheorie und Backtracking wurden ja auch schon mehrfach genannt. Wenn es viele Dreiecke gibt, also mehr als 500 möglich sind, würde ich den Stapel beim Backtracking selbst verwalten, weil Rekursion in CPython da an seine Grenzen stösst.
und :K ich bin eh schon am verzweifeln - keine Ahnung.
Ich hab zwar geschaut, ob ich etwas zur Graphentheorie finde und Netzdurchlauf. Man findet auch einiges, allerdings verstehe ich die Sachen nicht so wirklich.
Tut mir leid
Ich will jetzt mal ehrlich sein, aber bitte versteh mich nicht falsch, dass ist nicht böse gemeint.
Also, ich habe das Gefühl, dass es ein sehr steiniger Weg wird, die Aufgabenstellung vom Anfang hier mit dir zu lösen. Ich vermute du hast dich ein wenig übernommen.
Und ich glaube, so lange du noch vor grundlegenden Problemen stehst, werden nur wenig Leute dazu bereit sein, dich an die Hand zu nehmen und dir das Schritt für Schritt zu erklären.
Deine Aufgabe übersteigt die Komplexität einer for-Schleife, und wenn man so etwas angeht, sollte man entweder die Theoretischen Grundlagen dafür haben, oder die Sprache können. Wenn es bei beidem fehlt, wird das problematisch.
Es gibt ja bestimmt schon Lösungen, die du für dein Programm nutzen kannst, aber wärst du in der Lage sie als solche zu erkennen?
Mein Tipp wäre, gehe einen Schritt zurück, und versuche mit Zettel und Stift erst mal das Problem zu verstehen und (in Pseudocode oder so) zu lösen. Wenn du das drauf hast, dann versuch dich an der Umsetzung in Sprache X, dass ist dann nur noch Fleißarbeit.
Also, ich habe das Gefühl, dass es ein sehr steiniger Weg wird, die Aufgabenstellung vom Anfang hier mit dir zu lösen. Ich vermute du hast dich ein wenig übernommen.
Und ich glaube, so lange du noch vor grundlegenden Problemen stehst, werden nur wenig Leute dazu bereit sein, dich an die Hand zu nehmen und dir das Schritt für Schritt zu erklären.
Deine Aufgabe übersteigt die Komplexität einer for-Schleife, und wenn man so etwas angeht, sollte man entweder die Theoretischen Grundlagen dafür haben, oder die Sprache können. Wenn es bei beidem fehlt, wird das problematisch.
Es gibt ja bestimmt schon Lösungen, die du für dein Programm nutzen kannst, aber wärst du in der Lage sie als solche zu erkennen?
Mein Tipp wäre, gehe einen Schritt zurück, und versuche mit Zettel und Stift erst mal das Problem zu verstehen und (in Pseudocode oder so) zu lösen. Wenn du das drauf hast, dann versuch dich an der Umsetzung in Sprache X, dass ist dann nur noch Fleißarbeit.
-
BlackJack
@Michi_J: Ich habe mir den Ausgangsbeitrag noch einmal angeschaut und bin ein wenig skeptisch was die `owner`- und `neighbour`-Listen angeht. Durch die beschriebene Umnummerierung sind das beides einfach Listen mit aufsteigenden ganzen Zahlen. `owner` beginnt bei 1 und `neighbour` bei 2. Das heisst die braucht man gar nicht während der Wegsuche erstellen, sondern kann das jederzeit machen wenn man weiss wieviele Dreiecke es insgesamt auf dem Weg geben wird. Soll das wirklich so sein!?
Und was soll in `internal_faces`? Die IDs der Punkte von welcher Linie? Es gibt ja zwei und die haben nach Aufgabenbeschreibung unterschiedliche FIDs für die Punkte.
Ansonsten würde ich als ersten Schritt mal überlegen wie man die gegebene Liste in einen Objektgraphen mit Exemplaren von geeigneten Datentypen überführt. So auf Anhieb sehe ich da vorerst die Klassen `Point`, `Line`, und `Triangle`. Am besten als Wertklassen, also welche die nach dem Erstellen ihren "Basis"-Zustand nicht mehr ändern, und die `__cmp__()` (beziehungsweise `__eq__()`) und `__hash__()` entsprechend implementiert haben, so dass man Exemplare miteinander vergleichen kann und in `dict`\s als Schlüssel und in `set`\s als Elemente verwenden kann.
Punkte brauchen als Attribute die FID und die Koordinaten. Linien die FID und zwei Punkte. Und Dreiecke die FID und die Linien. Und im Laufe des Algorithmus zum Suchen eines Wegs noch die angrenzenden Dreiecke.
Wenn man die Klassen hat, kann man sich daran machen die gegebene Liste in den Objektgraphen zu überführen.
Das könnte man in drei Schritten machen, welche die Liste jeweils einmal linear durchlaufen: 1. Punkte erzeugen, 2. Linien erzeugen, 3. Dreiecke erzeugen.
Bei den ersten beiden Schritten könnte man eine Abbildung von Koordinaten auf Punkte bzw. Koordinatenpaare auf Linien erstellen und daraus dann jeweils eine Abbildung von Punkten auf Punkte mit den selben Koordinaten bzw. Linien auf Linien mit den selben Koordinatenpaaren. So bekommt man effizient die Nachbardreiecke heraus, ohne mit verschachtelten Schleifen auf quadratische Laufzeit zu kommen.
Auf den Objektgraphen kann man dann einen Backtracking-Algorithmus loslassen, der einen Weg durch die Dreiecke sucht und als Ergebnis eine Liste mit den Dreiecken in der Wegreihenfolge ausspuckt.
Diese Liste muss man am Ende noch in die geforderten Ausgabelisten überführen.
Und was soll in `internal_faces`? Die IDs der Punkte von welcher Linie? Es gibt ja zwei und die haben nach Aufgabenbeschreibung unterschiedliche FIDs für die Punkte.
Ansonsten würde ich als ersten Schritt mal überlegen wie man die gegebene Liste in einen Objektgraphen mit Exemplaren von geeigneten Datentypen überführt. So auf Anhieb sehe ich da vorerst die Klassen `Point`, `Line`, und `Triangle`. Am besten als Wertklassen, also welche die nach dem Erstellen ihren "Basis"-Zustand nicht mehr ändern, und die `__cmp__()` (beziehungsweise `__eq__()`) und `__hash__()` entsprechend implementiert haben, so dass man Exemplare miteinander vergleichen kann und in `dict`\s als Schlüssel und in `set`\s als Elemente verwenden kann.
Punkte brauchen als Attribute die FID und die Koordinaten. Linien die FID und zwei Punkte. Und Dreiecke die FID und die Linien. Und im Laufe des Algorithmus zum Suchen eines Wegs noch die angrenzenden Dreiecke.
Wenn man die Klassen hat, kann man sich daran machen die gegebene Liste in den Objektgraphen zu überführen.
Das könnte man in drei Schritten machen, welche die Liste jeweils einmal linear durchlaufen: 1. Punkte erzeugen, 2. Linien erzeugen, 3. Dreiecke erzeugen.
Bei den ersten beiden Schritten könnte man eine Abbildung von Koordinaten auf Punkte bzw. Koordinatenpaare auf Linien erstellen und daraus dann jeweils eine Abbildung von Punkten auf Punkte mit den selben Koordinaten bzw. Linien auf Linien mit den selben Koordinatenpaaren. So bekommt man effizient die Nachbardreiecke heraus, ohne mit verschachtelten Schleifen auf quadratische Laufzeit zu kommen.
Auf den Objektgraphen kann man dann einen Backtracking-Algorithmus loslassen, der einen Weg durch die Dreiecke sucht und als Ergebnis eine Liste mit den Dreiecken in der Wegreihenfolge ausspuckt.
Diese Liste muss man am Ende noch in die geforderten Ausgabelisten überführen.
Danke für deine Anregungen. Mit den Objektklassen hab ich noch wenig Erfahrung, ich werd aber versuchen, etwas zu "basteln". Dann kann ich dich wieder fragen. Das mit den internal_faces ist eine Zusatzaufgabe, die anschließend zu erledigen ist.
Dass die owner und neighbour aufsteigend nummeriert sind, ist nur zufällig, das muss nicht so sein und sie sind auch nicht einfach durchzunummerieren. Leider nicht
Aber danke nochmals für deine Anregungen.
PS: kann es sein dass mein Problem eine Art Salesman-Problem ist?
Dass die owner und neighbour aufsteigend nummeriert sind, ist nur zufällig, das muss nicht so sein und sie sind auch nicht einfach durchzunummerieren. Leider nicht
Aber danke nochmals für deine Anregungen.
PS: kann es sein dass mein Problem eine Art Salesman-Problem ist?
-
BlackJack
@Michi_J: So wie Du das beschrieben hast sind die beiden Listen immer Zahlenfolgen von 0 bis n-1 bzw. 1 bis n mit n = Anzahl der Dreiecke.
Brauchst Du denn die FIDs der einzelnen Elemente ausser der Punkte später noch? Dann muss man die natürlich in den Objekten speichern. Ich bin bei der bisherigen Problembeschreibung davon ausgegangen, dass man die bis auf bei den Punkten einfach wegwerfen kann.
Das ist quasi ein Sonderfall vom Traveling Salesman Problem bei dem die Kantengewichtung bei allen Kanten 0 ist. Der Weg ist also egal, Hauptsache es werden alle Knoten genau einmal besucht. Das ist dann ein Hamiltonkreis. Der wurde hier IIRC auch schon von jemandem erwähnt.
Die Suche nach dem Weg ist IMHO bisher hier die komplizierteste Teilaufgabe -- insbesondere die Umformung von einer rekursiven in eine iterative Lösung. Da könnte dann schonmal eine Funktion mit 25--50 Zeilen anfallen. Länger sollten Funtkionen in der Regel nicht werden, lokale Funktionen nicht mitgezählt. Ansonsten kann man das Problem oft in kleinere Teilprobleme zerlegen. Zum Beispiel die Umwandlung in einen Objektgraphen in 3-4 Schritten, kann man auch in 4-5 Funktionen aufteilen. Eine die die Unterfunktionen für die 3-4 Schritte aufruft. Ich hatte das ja schon grob skizziert. Eine `create_mesh()`-Funktion könnte in drei Schritten Punkte, Linien, und Dreiecke aus der Eingabeliste erzeugen und dann die Dreiecke mit gemeinsamen Linien einander bekannt machen. Die Hauptfunktion dafür könnte zum Beispiel so aussehen:
Nehmen wir als Teilproblem da mal das Verbinden der Dreiecke mit gemeinsamen Linien heraus. Ganz naiv könnte man das so formulieren: Für jedes Dreieck A prüfe für jedes Dreieck B, das nicht mit A identisch ist, ob A eine gemeinsame Linie mit B hat. Wenn ja, verbinde A mit B und B mit A. Das lässt sich in Code fast "wörtlich" so hinschreiben:
Die Aufgaben zu überprüfen ob ein Dreieck eine gemeinsame Linie mit einem anderen hat, und die Verbindung zu vermerken, sind wieder in anderen Funktionen bzw. Methoden gelöst. Das ist eine sehr wichtige Fähigkeit beim Programmieren: Probleme solange in Teilprobleme zerlegen zu können, bis sie wirklich einfach und oft mit nur ein paar Zeilen Quelltext zu lösen sind.
Brauchst Du denn die FIDs der einzelnen Elemente ausser der Punkte später noch? Dann muss man die natürlich in den Objekten speichern. Ich bin bei der bisherigen Problembeschreibung davon ausgegangen, dass man die bis auf bei den Punkten einfach wegwerfen kann.
Das ist quasi ein Sonderfall vom Traveling Salesman Problem bei dem die Kantengewichtung bei allen Kanten 0 ist. Der Weg ist also egal, Hauptsache es werden alle Knoten genau einmal besucht. Das ist dann ein Hamiltonkreis. Der wurde hier IIRC auch schon von jemandem erwähnt.
Die Suche nach dem Weg ist IMHO bisher hier die komplizierteste Teilaufgabe -- insbesondere die Umformung von einer rekursiven in eine iterative Lösung. Da könnte dann schonmal eine Funktion mit 25--50 Zeilen anfallen. Länger sollten Funtkionen in der Regel nicht werden, lokale Funktionen nicht mitgezählt. Ansonsten kann man das Problem oft in kleinere Teilprobleme zerlegen. Zum Beispiel die Umwandlung in einen Objektgraphen in 3-4 Schritten, kann man auch in 4-5 Funktionen aufteilen. Eine die die Unterfunktionen für die 3-4 Schritte aufruft. Ich hatte das ja schon grob skizziert. Eine `create_mesh()`-Funktion könnte in drei Schritten Punkte, Linien, und Dreiecke aus der Eingabeliste erzeugen und dann die Dreiecke mit gemeinsamen Linien einander bekannt machen. Die Hauptfunktion dafür könnte zum Beispiel so aussehen:
Code: Alles auswählen
def create_mesh(data):
point_id2point = create_points(data)
line_id2line = create_lines(data, point_id2point)
triangles = create_triangles(data, line_id2line)
connect_triangles(triangles)
return trianglesCode: Alles auswählen
def connect_triangles(triangles):
for triangle_a in triangles:
for triangle_b in triangles:
if (triangle_a is not triangle_b
and triangle_a.has_shared_line_with(triangle_b)):
triangle_a.add_neighbour(triangle_b)
triangle_b.add_neighbour(triangle_a)Das bedeutet auch, dass ich eine Funktion schreiben soll, in der eben verglichen wird, ob die beiden Dreiecke benachbart sind. Das hatte ich vorher in ein den Quellcode einfach so implementiert, ohne Funktion (die ganzen if-Abfragen)
und: ja, die FID brauch ich nachher noch
vielen herzlichen Dank, dass du mir hilfst!
und: ja, die FID brauch ich nachher noch
vielen herzlichen Dank, dass du mir hilfst!
-
BlackJack
@Michi_J: Das ist wenn man objektorientiert denkt eine Frage die man an ein Dreieck stellen kann, ob ein anderes Dreieck benachbart ist.
Und da könnte man das wieder sehr einfach formulieren: Zwei Dreiecke teilen sich eine Linie wenn für irgendein Paar `(a, b)`, mit `a` aus den Linien des Dreiecks, das man befragt und `b` aus den Linien des anderen Dreiecks, ``a == b`` gilt. In Quelltext könnte das so aussehen:
Die Aufgabe zwei Linien auf Gleichheit zu überprüfen, würde wieder woanders gelöst; nämlich in einer Methode auf den Linien-Objekten (`__cmp__()` oder `__eq__()`).
Und da könnte man das wieder sehr einfach formulieren: Zwei Dreiecke teilen sich eine Linie wenn für irgendein Paar `(a, b)`, mit `a` aus den Linien des Dreiecks, das man befragt und `b` aus den Linien des anderen Dreiecks, ``a == b`` gilt. In Quelltext könnte das so aussehen:
Code: Alles auswählen
class Triangle(object):
# ...
def has_shared_line_with(self, other):
return any(a == b for a in self.lines for b in other.lines)mein erster Schritt ist aber dann schon der, dass ich mir 3 Listen (Dreiecke, Linien, Punkte), wo folgende Informationen gespeichert sind:
Dreiecke: FID-Dreiecke
Linien: FID-Linie und FID-Dreieck (zu welchem sie gehören)
Punkte: FID-Punkt und FID-Linie (zu welcher sie gehören)
entspricht dies dann den 3 Klassen oder ist das wieder etwas anderes?
Dreiecke: FID-Dreiecke
Linien: FID-Linie und FID-Dreieck (zu welchem sie gehören)
Punkte: FID-Punkt und FID-Linie (zu welcher sie gehören)
entspricht dies dann den 3 Klassen oder ist das wieder etwas anderes?
Also, nachfolgend meine 3 Listen:
a) Dreiecksliste (mit der FID der Dreiecke) - ich habe 17 Dreiecke
Bsp (2, [[4, [-44125.5, 251484.5, 453.01429999999999]], [5, [-45625.5, 249824.5, 424.90600000000001]]]) ==
(FID_Linie, [[FID_Koordinate1, [X, Y, Z]], [FID_Koordinate2, [X, Y, Z]]])
a) Dreiecksliste (mit der FID der Dreiecke) - ich habe 17 Dreiecke
- [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17]
- [(0, 1), (1, 15), (2, 0), (3, 12), (4, 15), (5, 3), (6, 15), (7, 12), (8, 9), (9, 12), (10, 3), (11, 4), (12, 2), (13, 3), (14, 2), (15, 16), (16, 1), (17, 2), (18, 0), (19, 1), (20, 0), (21, 17), (22, 13), (23, 17), (24, 17), (25, 9), (26, 9), (27, 10), (28, 4), (29, 14), (30, 4), (31, 5), (32, 5), (33, 6), (34, 5), (35, 16), (36, 13), (37, 16), (38,
, (39, 13), (40, 10), (41, 10), (42, 11), (43, 11), (44, 11), (45, 14), (46, 6), (47, 14), (48, 6), (49, 7), (50, 7), (51, 7), (52, , (53, ]
Bsp (2, [[4, [-44125.5, 251484.5, 453.01429999999999]], [5, [-45625.5, 249824.5, 424.90600000000001]]]) ==
(FID_Linie, [[FID_Koordinate1, [X, Y, Z]], [FID_Koordinate2, [X, Y, Z]]])
- [(2, [[4, [-44125.5, 251484.5, 453.01429999999999]], [5, [-45625.5, 249824.5, 424.90600000000001]]]), (18, [[36, [-45625.5, 249824.5, 424.90600000000001]], [37, [-47255.5, 254754.5, 408.16120000000001]]]), (20, [[40, [-47255.5, 254754.5, 408.16120000000001]], [41, [-44125.5, 251484.5, 453.01429999999999]]]), (0, [[0, [-45625.5, 249824.5, 424.90600000000001]], [1, [-46505.5, 249454.5, 423.92090000000002]]]), (16, [[32, [-46505.5, 249454.5, 423.92090000000002]], [33, [-47255.5, 254754.5, 408.16120000000001]]]), (19, [[38, [-45625.5, 249824.5, 424.90600000000001]], [39, [-47255.5, 254754.5, 408.16120000000001]]]), (12, [[24, [-46505.5, 249454.5, 423.92090000000002]], [25, [-47265.5, 254754.5, 408.0419]]]), (14, [[28, [-47265.5, 254754.5, 408.0419]], [29, [-47255.5, 254754.5, 408.16120000000001]]]), (17, [[34, [-46505.5, 249454.5, 423.92090000000002]], [35, [-47255.5, 254754.5, 408.16120000000001]]]), (5, [[10, [-46505.5, 249454.5, 423.92090000000002]], [11, [-48415.5, 254624.5, 399.47649999999999]]]), (10, [[20, [-48415.5, 254624.5, 399.47649999999999]], [21, [-47265.5, 254754.5, 408.0419]]]), (13, [[26, [-46505.5, 249454.5, 423.92090000000002]], [27, [-47265.5, 254754.5, 408.0419]]]), (11, [[22, [-48415.5, 254624.5, 399.47649999999999]], [23, [-47265.5, 254754.5, 408.0419]]]), (28, [[56, [-48415.5, 254624.5, 399.47649999999999]], [57, [-47265.5, 254764.5, 408.0222]]]), (30, [[60, [-47265.5, 254764.5, 408.0222]], [61, [-47265.5, 254754.5, 408.0419]]]), (31, [[62, [-47265.5, 254764.5, 408.0222]], [63, [-47265.5, 254754.5, 408.0419]]]), (32, [[64, [-47265.5, 254764.5, 408.0222]], [65, [-47255.5, 254764.5, 408.096]]]), (34, [[68, [-47255.5, 254764.5, 408.096]], [69, [-47265.5, 254754.5, 408.0419]]]), (33, [[66, [-47265.5, 254764.5, 408.0222]], [67, [-47255.5, 254764.5, 408.096]]]), (46, [[92, [-47265.5, 254764.5, 408.0222]], [93, [-49255.5, 258014.5, 431.06569999999999]]]), (48, [[96, [-49255.5, 258014.5, 431.06569999999999]], [97, [-47255.5, 254764.5, 408.096]]]), (49, [[98, [-49255.5, 258014.5, 431.06569999999999]], [99, [-47255.5, 254764.5, 408.096]]]), (50, [[100, [-49255.5, 258014.5, 431.06569999999999]], [101, [-43915.5, 258794.5, 414.2158]]]), (51, [[102, [-43915.5, 258794.5, 414.2158]], [103, [-47255.5, 254764.5, 408.096]]]), (38, [[76, [-45435.5, 254754.5, 408.15609999999998]], [77, [-47255.5, 254764.5, 408.096]]]), (52, [[104, [-43915.5, 258794.5, 414.2158]], [105, [-47255.5, 254764.5, 408.096]]]), (53, [[106, [-43915.5, 258794.5, 414.2158]], [107, [-45435.5, 254754.5, 408.15609999999998]]]), (8, [[16, [-48415.5, 254624.5, 399.47649999999999]], [17, [-49995.5, 254754.5, 402.4579]]]), (25, [[50, [-49995.5, 254754.5, 402.4579]], [51, [-49995.5, 254764.5, 402.11309999999997]]]), (26, [[52, [-49995.5, 254764.5, 402.11309999999997]], [53, [-48415.5, 254624.5, 399.47649999999999]]]), (27, [[54, [-49995.5, 254764.5, 402.11309999999997]], [55, [-48415.5, 254624.5, 399.47649999999999]]]), (40, [[80, [-49995.5, 254764.5, 402.11309999999997]], [81, [-49995.5, 257504.5, 398.87670000000003]]]), (41, [[82, [-49995.5, 257504.5, 398.87670000000003]], [83, [-48415.5, 254624.5, 399.47649999999999]]]), (42, [[84, [-49995.5, 257504.5, 398.87670000000003]], [85, [-48415.5, 254624.5, 399.47649999999999]]]), (43, [[86, [-49995.5, 257504.5, 398.87670000000003]], [87, [-49255.5, 258014.5, 431.06569999999999]]]), (44, [[88, [-49255.5, 258014.5, 431.06569999999999]], [89, [-48415.5, 254624.5, 399.47649999999999]]]), (3, [[6, [-48415.5, 254624.5, 399.47649999999999]], [7, [-49995.5, 249994.5, 409.14229999999998]]]), (7, [[14, [-49995.5, 249994.5, 409.14229999999998]], [15, [-49995.5, 254754.5, 402.4579]]]), (9, [[18, [-48415.5, 254624.5, 399.47649999999999]], [19, [-49995.5, 254754.5, 402.4579]]]), (22, [[44, [-45435.5, 254754.5, 408.15609999999998]], [45, [-47255.5, 254754.5, 408.16120000000001]]]), (36, [[72, [-47255.5, 254754.5, 408.16120000000001]], [73, [-47255.5, 254764.5, 408.096]]]), (39, [[78, [-45435.5, 254754.5, 408.15609999999998]], [79, [-47255.5, 254764.5, 408.096]]]), (29, [[58, [-48415.5, 254624.5, 399.47649999999999]], [59, [-47265.5, 254764.5, 408.0222]]]), (45, [[90, [-49255.5, 258014.5, 431.06569999999999]], [91, [-48415.5, 254624.5, 399.47649999999999]]]), (47, [[94, [-47265.5, 254764.5, 408.0222]], [95, [-49255.5, 258014.5, 431.06569999999999]]]), (1, [[2, [-46505.5, 249454.5, 423.92090000000002]], [3, [-49995.5, 249994.5, 409.14229999999998]]]), (4, [[8, [-48415.5, 254624.5, 399.47649999999999]], [9, [-49995.5, 249994.5, 409.14229999999998]]]), (6, [[12, [-46505.5, 249454.5, 423.92090000000002]], [13, [-48415.5, 254624.5, 399.47649999999999]]]), (15, [[30, [-47265.5, 254754.5, 408.0419]], [31, [-47255.5, 254754.5, 408.16120000000001]]]), (35, [[70, [-47255.5, 254764.5, 408.096]], [71, [-47265.5, 254754.5, 408.0419]]]), (37, [[74, [-47255.5, 254754.5, 408.16120000000001]], [75, [-47255.5, 254764.5, 408.096]]]), (21, [[42, [-47255.5, 254754.5, 408.16120000000001]], [43, [-44125.5, 251484.5, 453.01429999999999]]]), (23, [[46, [-45435.5, 254754.5, 408.15609999999998]], [47, [-47255.5, 254754.5, 408.16120000000001]]]), (24, [[48, [-45435.5, 254754.5, 408.15609999999998]], [49, [-44125.5, 251484.5, 453.01429999999999]]])]