Commit e2f0384 (vor dieser Session) liess EXPORTCSV/EXPORTSIVAS auch die in
VF_n-Blockdefinitionen verpackten Separator_SP-Sensoren als eigene Zeile
exportieren (TeileArt "ILS 2.0 Separator"). tests/test_foerderer.py wurde
seitdem nicht angepasst und nahm weiter an, JEDE Zeile sei eine Vario-
Strecke - drei Tests schlugen daher fehl, sobald die CSV tatsaechlich
vorlag (39 statt 13 Zeilen: 13 Vario- + 26 Separator-Zeilen).
Neu NEBEN_TEILEARTEN = {"ILS 2.0 Separator"} plus zwei Filter-Helfer
(_vario_rows/_separator_rows). test_vario_teileart, test_merkmale_felder
und test_anzahl_csv_zeilen_entspricht_gebaut pruefen jetzt nur noch die
Vario-Zeilen (verifiziert: 13 Vario- + 26 Separator-Zeilen in der aktuellen
CSV, Summe stimmt).
Statt die Separator-Zeilen nur zu ignorieren, zwei neue, eigenstaendige
Tests:
- test_teileart_bekannt: jede Zeile ist Vario-Strecke ODER eine bekannte
Neben-TeileArt - faengt eine dritte, unerwartete Art, die die beiden
Filter sonst stillschweigend durchliessen.
- test_separator_merkmale_felder: die Separator-Merkmale haben ihr eigenes,
kleineres Pflichtfeld-Schema (Zuordnung, ARTINR) statt der Vario-Felder.
- test_separator_zuordnung_konsistent: der eigentliche Beweis, dass
csv:sep-proxies-erzeugen die Sensoren dem RICHTIGEN Wrapper zuordnet -
jede Separator-Zuordnung zeigt auf eine Vario-TeileId derselben Datei,
und je Vario-Zeile stimmt die Anzahl ihrer Separatoren mit dem eigenen
Merkmal Anzahl_Separator ueberein (test_export_ids.py prueft nur, dass
die Zuordnung ueberhaupt auf eine bekannte ID zeigt, nicht auf die
richtige). Gegengeprobt: eine verfaelschte Zuordnung wird erkannt.
Verifiziert: alle 27 Tests in test_foerderer.py gruen (vorher 3 FAILED),
Gesamtsuite 188 passed / 0 failed / 19 skipped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
17 vorbestehende Failures behoben - alles veraltete Tests, kein Produktivcode:
test_foerderer.py (3): CSV-Spalten header-basiert statt per festem Index
ansprechen. Die Export-CSV hat inzwischen 17 statt 11 Spalten (Insertpoint,
K1-K4, Warnungen kamen dazu, siehe lib/export_csv.py) - die Tests hingen an
row[10] fuer Merkmale. Neu: self.col-Lookup + _cell(row, spaltenname), robust
gegen weitere Spalten.
test_mubea.py (2): _is_gefaelle zaehlte einen zweiten GF_*-Eintrag (block
'S-LP', ein Separator mit assigned_to GF_Mubea) faelschlich als Gefaellestrecke
mit -> erwartete 40 statt 20. Jetzt: GF_* UND nicht _is_separator.
test_omniflo_strecke.py (12): Test und seine Testdaten-Datei waren auf zwei
verschiedene Datenmodelle geschrieben (Test: 12 Elemente, gerade_start/
kurve_180/gerade_ende, Felder drehung_ende/x_mitte; Datei: 7 Elemente,
gerade_unten/gerade_oben/bogen/weiche ohne diese Felder). Test komplett auf das
tatsaechliche 7-Element-Modell umgeschrieben (Struktur/Katalog/Geraden-
Geometrie); Boegen gegen omniflo_boegen.json, Weiche gegen omniflo_weichen.json.
Nicht angefasst (bewusst): 3x hundm05 (funktioniert noch nicht) und
test_omniflo.py::test_zeilen_matches_reference (inkonsistente Export-CSV +
veraltete Referenz - Analyse: export_csv.py ist konsistent 17-spaltig, die
Output-Datei stammt aus einem gemischten Lauf; Referenz per --set-as-reference
neu abnehmen, kein Code-Fix noetig).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CSV-Header hat inzwischen eine "Fehler"-Spalte (export_csv.py, zwischen
Nachbarn und Merkmale) und der Sivas-Export eine "IDs"-Spalte (export_sivas.py,
vor details) bekommen - der Test war darauf noch nicht nachgezogen und
erwartete die alten Spaltenpositionen/Header, wodurch Header- und
Merkmale/details-JSON-Pruefungen fehlschlugen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neue Spalte "Nachbarn" (kommaseparierte TeileId-Liste) in export_csv.py:
zwei Elemente gelten als benachbart, wenn ihre Bounding-Boxes (x/y-Ebene)
sich ueberschneiden. Toleranz konfigurierbar in mm ueber cfg/export.cfg
[Nachbarschaft] -> toleranz_mm, siehe lib/export_neighbors.py.
Nur EXPORTCSV betroffen, EXPORTSIVAS bleibt unveraendert.
shapely als neue Abhaengigkeit in requirements.txt ergaenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die Hoehe-Angabe steht bereits pro Element in der details-JSON-Spalte
(z.B. "Hoehe in m" aus dem MONTAGEHOEHE_m-Attribut bei VarioFoerderer/
Linienzug), die separate Top-Level-Spalte war redundant.
Nur EXPORTCSV betroffen, EXPORTSIVAS bleibt unveraendert:
- Position/Boundingbox: Bounding-Box je Block per vla-getboundingbox
(Lisp/export.lsp, csv:get-bbox), Mittelpunkt und Ausdehnung x/y/z.
- Planquadrat: aus x/y-Koordinate berechnet nach cfg/export.cfg
[Planquadrate] (Schrittweite, numerisch/alphabetisch je Achse,
alphabetische Zaehlung mit Excel-Spalten-Umlauf Z->AA), siehe
lib/export_planquadrat.py.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
test_vario_teileart erwartete noch "VarioFoerderer", obwohl export_csv.py
seit Commit bf51747 (14 Commits zuvor) bewusst "ILS 2.0 Strecke" liefert -
ein VarioFoerderer ist ein Streckentyp. Test war seither stale, unabhaengig
von den foerderer_tests.json-Aenderungen dieser Session.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
s.ayadi
m.stangl