Stufe 1 des Fahrplans in doc/TODO-plan-vf-interactive.md, fertig fuer
Modus 1. Eine SPEC beschreibt eine Kette in Domaenenwerten ("links",
"winkel", "aussen", ja/nein) statt in Menue-Codes; vsp-journal uebersetzt sie
in ein Eingabe-Journal, vsp-bau-aus-spec spielt es per
vfl-journal-replay-start durch den UNVERAENDERTEN vf-linienzug-modus. Der
fertige Block traegt damit dasselbe SSG_VF_EDIT-Journal wie eine handgebaute
Kette und bleibt per Doppelklick editier- und 2D/3D-konvertierbar - kein
Journal-Konsument muss etwas von Specs wissen.
CAD-Lauf VF_SPEC_BAU: 5 OK, 0 Fehler. Je Kette status "executed",
prompts 0 (keine Live-Eingabe erreicht), eingaben_offen 0, keine
Spec-Fehler, keine Bau-Meldungen, glieder_ist == glieder_soll,
Einfuegepunkt gleich dem Kettenstart der Spec.
Neu:
- Lisp/vf_spec.lsp: Code-Tabellen, Emitter vsp-journal, Validierung
vsp-pruefen, flacher JSON-Loader, Headless-Rahmen vsp-headless-an/-aus,
Ergebnis-Record, vsp-bau-aus-spec/-liste, c:VF_SPEC_BAU. Von vf_core.lsp
NACH vf_linienzug.lsp geladen - damit sind beide Ladewege abgedeckt (Menue
und der .scr-Loader), das MNL bleibt unveraendert.
- lib/vf_spec_export.py: derselbe Emitter in Python PLUS die Umkehrung
(spec_aus_journal), erzeugt die Spec-Testdaten.
- tests/testdata/vf_spec_hundm05.json: die 5 echten Ketten als Spec,
erzeugt statt handgeschrieben.
- tests/test_vf_spec.lsp (C:TEST_VF_SPEC, in alltests.json): 7 Faelle je
Glied-Typ, 7 Validierungsfaelle, Gruppieren, und die 5 echten Ketten gegen
ihr aufgezeichnetes Journal.
- tests/test_vf_spec.py: 36 Tests (Rundlauf, Spec-Daten, Validierung,
Erwartungswert-Abgleich, Ergebnisse von VF_SPEC_BAU).
Drei Regeln, die der Uebersetzer besitzen muss - jede wuerde sonst die ganze
Replay-Queue verschieben:
- Der Menue-Code haengt am Frame: erste Sektion 4 Optionen (kein GF-Bogen,
es gibt noch keine Richtung), jede spaetere 5.
- hz steht genau EINMAL im Journal, beim ersten Segment (vfl-in-abstand
journalisiert die Richtung nur bei freier Richtungswahl).
- Nur ein HORIZONTALER Erstkoerper einer VF-Einheit stellt die Separator-/
Endpunktfragen vorab (winkel1=0 laeuft durch vfl-baue-horizontal-koerper);
ein gewinkelter wird ohne jede Frage gebaut.
Wie die Richtigkeit belegt ist - drei Implementierungen derselben Grammatik,
die einander pruefen:
- Rundlauf gegen echte Daten: journal_aus_spec(spec_aus_journal(tok)) == tok
fuer alle 5 HundM-Ketten, tokenweise numerisch verglichen. Damit ist
bewiesen, dass die Spec das Journal verlustfrei abbildet.
- Der Weg, den LISP nimmt (flaches JSON -> Spec -> Journal), ergibt separat
geprueft dieselben Journale wie das aufgezeichnete Protokoll.
- Der unabhaengige Dekoder aus lib/vf_journal_export.py verdaut alle 7
synthetischen Emitter-Ausgaben restlos, auch die zwei Zweige, die in den
echten Daten fehlen (Linie-VF, gewinkelter Erstkoerper).
- Die Erwartungswerte im LISP-Test kommen aus dem geprueften Python-Emitter;
TestLispErwartungen liest sie zurueck und vergleicht erneut. Ohne das
koennte ein Uebertragungsfehler einen falschen Erwartungswert
festschreiben und der CAD-Lauf waere gruen, obwohl der Emitter falsch
liegt.
Abweichungen von der Planung (Begruendungen in doc/TODO-plan-vf-interactive.md
Abschnitt 4.6): vsp-pruefen ruft den Emitter statt eine zweite Regelmenge zu
pflegen; das vollstaendige Journal steht nicht im Record (statt dessen
glieder_soll/glieder_ist als Desync-Detektor); Zusatzfeld segment_typ am
Glied "Linie", weil dort vfl-segment-entscheidung selbst zwischen GF und VF
waehlt; vf_ende-Werte "automatisch"/"zielpunkt-ohne-es" fuer die Faelle ohne
Frage; Praefix vsp- statt vfs- (das gehoert vf_standard.lsp).
Zusaetzlich:
- tests/test_vf_headless_statisch.py prueft jetzt auch, dass
Lisp/vf_spec.lsp UEBERHAUPT keine Eingabe-/Dialogfunktion aufruft - beim
Daten-Pfad ist die Null die Vorgabe.
- tests/testdata/mubea.json: die drei einzeln eingefuegten S-LP-Separatoren
entfernt (Fortsetzung von 699744e - die Separatoren stecken jetzt in den
Staustreckenbloecken).
Noch offen: die Uebersetzer fuer Modus 2 und 3. Modus 2 braucht laut
Fahrplan erst 2-3 echte "linienzug2"-Journale als Referenz -
tests/testdata/hundm05.json enthaelt ausschliesslich Modus-1-Ketten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Grundlage fuer reproduzierbare Nachbau-Testfaelle aus echten Projekt-
zeichnungen (HundM05).
- lib/vf_journal_export.py (neu): liest die Eingabe-Journale der VF_n-Bloecke
aus der XDATA (App SSG_VF_EDIT, Marker "linienzug") und schreibt sie als
Frage-Antwort-Protokoll im Schema von tests/testdata/linienzug_tests.json -
Gegenstueck zu vfl-entry->string, ohne ezdxf (reine Gruppencode-Lesung).
Optional --csv fuer Strecken-ID und Erwartungswerte je Kette.
- lib/extract_polylines.py (neu): LWPOLYLINE-Objekte als JSON, inkl.
OCS->Welt-Umrechnung fuer gekippte Ebenen (Handles, Segment-/Gesamtlaengen).
- lib/dxf_scan_components.py: erkennt jetzt zusaetzlich, ob ein Block ein
2D-Schema oder ein 3D-Modell ist (TYPEN_3D, ist_3d_block/darstellung_von) -
eine Anlagenzeichnung enthaelt beides. Dazu Sensor-Erfassung,
Zwillings-Zusammenfuehrung und Hoehenschaetzung aus der Umgebung.
- lib/dxf_abbild.py: gibt die erkannte Darstellung je Element mit aus.
- tests/test_vf_journal_grammatik.py (neu): prueft den Journal-Dekoder gegen
handgebaute Journale - ohne CAD und ohne die grosse DXF. Deckt die zwei
Zweige ab, die in den echten Ketten nicht vorkommen: Glied "Linie-VF" und
eine VF-Einheit mit gewinkeltem Erstkoerper (dort fragt vfl-vf-einheit
KEINE Separator-/Endpunkt-Fragen vorab, anders als beim horizontalen).
- data/polylines.md, tests/testdata/hundm05_linienzug_polylines.json:
ausgewertete Streckenzuege der Quellzeichnung.
- .gitignore: die Quellzeichnungen selbst (data/polylines.dxf 124 MB,
data/polylines.dwg, tests/HM5.dwg) bleiben draussen - eingecheckt ist die
Auswertung, nicht die Zeichnung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Konflikt in lang/de_DE.json und lang/en_GB.json aufgeloest: beide Seiten
haben nur Schluessel ergaenzt (con-*/cmd-connection-* hier, sens-* aus
origin). Beide Saetze uebernommen, Einrueckung von origin (2 Leerzeichen)
beibehalten, tro-edit-fb mit UID-Anzeige uebernommen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- lib/dxf_scan_components.py: erkennt ILS-/Omniflo-Komponenten in fremden
Projektzeichnungen und schreibt sie im Testdaten-JSON-Schema aus
- lib/dxf_abbild.py: getreue Abbildung der Bauteile einer Fremdzeichnung
(Attribute, Weltkoordinaten, Unterkomponenten) ohne Interpretation
- tests/test_hundm05.{lsp,py}, testdata/hundm05.json, conftest-Fixtures und
alltests.json-Eintrag fuer den Kreisel-Abschnitt aus ST500592_05.dxf
- menu: TEST_HUNDM05 im Testmenue, Connection_Insert/Edit in SSG_LIB.cui
- Doku: hartkodierte Pfade durch (getenv "DXFMAKRO") ersetzt
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
count_sep_scan.lsp neu als wiederverwendbare Engine (cs-zuordnung-lauf),
die automatisch vor jedem CSV-/Sivas-Export laeuft (export.lsp,
csv:run-export). Zaehlt Separator_SP/Scanner je Carrier (Kreisel/Eckrad,
VF_*, GF_*) ueber die gemeinsamen cfg/export.cfg-Muster und schreibt
ANZAHL_SEPARATOR/ANZAHL_SCANNER, so dass die Summe zur Szene passt.
Scanner ausserhalb jeder Carrier-Boundingbox ohne ZUORDNUNG werden per
Abstand dem naechsten Kreisel/Strecke zugeschlagen (ZUORDNUNG = Carrier-ID).
Ist der Abstand zum zweitnaechsten Kandidaten fast gleich (<= strittig_diff_mm,
neu in cfg/export.cfg [Sensorzuordnung]), gilt die Zuordnung als strittig:
Konsolenausgabe der ergaenzten Scanner + JSON-"warnung"-Feld mit den IDs der
strittigen Kandidaten (csv:block-to-json), das export_csv.py in der Spalte
"Warnungen" ausgibt.
Menue: ZAEHLE_SEP_SCAN-Vorlauf vor EXPORTSIVAS entfernt (laeuft jetzt
automatisch im Export); interaktiver Befehl bleibt erhalten.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Damit stimmen Elementnummer (erste Spalte) und TeileId ueberein, solange
kein Element geloescht wurde - geloeschte Elemente hinterlassen Luecken
in der TeileId-Folge statt in der Zeilennummerierung.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- compute_kreisel_touch_switches: erzeugt an jedem Beruehrpunkt zweier Kreisel
eine "ILS Weiche" (Kapsel-Geometrie, Position=Beruehrpunkt, statische Box
250x100x30 mit Laengsseite senkrecht zur Kreiselachse, Nachbarn=beide Kreisel)
- compute_strecke_kreisel_schleus: an Anfang/Ende jeder Gefaellestrecke bzw.
jedes Foerderers (ILS 2.0 Strecke) ein Aus-/Einschleuselement an der
Kollisionsposition zum naechsten BBox-Nachbar-Kreisel (Nachbarn=Kreisel+Strecke)
- TeileId zaehlt fortlaufend aus der hoechsten vorhandenen ID hoch (Weichen
zuerst, dann Schleuselemente)
- Warnung (Konsole + neue CSV-Spalte "Warnungen"), wenn eine Strecke mehr als
zwei Kreisel-BoundingBoxen beruehrt (erwartet: ein Anfang + ein Ende)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Die Omniflo-Nachbarschaftserkennung (export_neighbors.py, nur EXPORTCSV) wird
zweistufig:
- Broad-Phase ueber shapely-STRtree auf den Bounding-Boxen (Fallback: das
bisherige Raster, falls shapely fehlt).
- Narrow-Phase (KOS-Verfeinerung): zwei moegliche Nachbarn gelten nur dann als
benachbart, wenn ein Anschluss-Koordinatensystem K1-K4 des einen naeher als
omniflo_ks_toleranz_mm (neu, Default 10mm) an einem K-Punkt des anderen
liegt. Das verwirft bloss ueberlappende BBoxen ohne echten Anschluss.
Elemente ohne K1-K4 fallen auf reine BBox-Ueberschneidung zurueck.
Geraden fuehren keine echten K-Bloecke in der Zeichnung; ihre K1 (Anfang) /
K2 (Ende) werden beim Export aus Einfuegepunkt + Laenge + Rotation
synthetisiert (csv:gerade-k-kos-strings in export.lsp) und stehen damit in den
CSV-Spalten K1/K2 - wie echte KOS - und nehmen an der Kollisionspruefung teil.
Verifiziert an results/test-omnicollision: gerichtete Nachbarschaften 20 -> 14.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0_BG* im Sivasnr-Rohwert ist kein echter Sivas-Code, sondern ein Blockname-
Platzhalter fuer mehrere reale TEF-Teile (z.B. 0_BG071090 = 0_B10071 +
0_B10090 + 0_B10090, siehe SivasnrTEF im Katalog). Bisher wurde der
Platzhalter selbst als Sivasnummer gezaehlt, wodurch u.a. 0_B10071 in der
Summierung fehlte.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Baut aus export.csv ein gerichtetes Graph-Modell der Anlage und schreibt
es als .json (vollstaendig), .dot (GraphViz) und .mmd (Mermaid).
Statt der CSV-Spalte "Nachbarn" (ungerichtet, Strecken werden dort
absichtlich nicht gegeneinander getestet, und ein langer Kreisel
ueberdeckt flaechig die halbe Anlage) arbeitet das Modul mit
Anschlusspunkten: eine Kante entsteht nur, wenn ein Elementende im
Grundriss auf der Flaeche eines anderen Elements liegt.
Richtung exakt aus K1/K2 (KS_EIN/KS_AUS), sobald der Export diese
Spalten fuellt; solange sie leer sind heuristisch aus Schwerkraft
(Gefaellestrecke) bzw. dem Merkmal Antriebfahrtrichtung (Foerderer).
Jede Kante traegt die verwendete Quelle in "richtung_quelle".
Warnt zudem, wenn Insertpoint-Werte an der 24-Bit-Fixed-Point-Grenze
von csv:kos-encode (+-8388.607 Einheiten) abgeschnitten sind.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
build_variofoerderer_merkmale las noch die alten Attributnamen ohne
_mm-Suffix (HOEHE_VON, HOEHE_BIS, DELTA_H, DELTA_L) sowie SEITE/WINKEL.
Umbenannt wurden diese in *strecke-attr-front* (ssg_core.lsp) zu
HOEHE_VON_mm/HOEHE_BIS_mm/DELTA_H_mm/DELTA_L_mm bzw. aufgeteilt in
SEITE_AS/SEITE_ES und GF_WINKEL/VF_WINKEL. Da attribs.get() still den
Default "" liefert, blieben die Felder in der Merkmale-Spalte leer statt
einen Fehler zu melden - betroffen waren alle VF_n- UND GF_n-Zeilen
(beide nutzen denselben Builder). export_sivas.py war bereits nachge-
zogen, export_csv.py nicht; aufgefallen ist es nicht, weil
tests/reference/export_raw.json noch die alten Namen enthaelt.
- Attributnamen korrigiert, Alt-Namen per att()-Helper als Fallback,
damit aeltere export_raw.json-Dateien und noch nicht neu aufgebaute
Bloecke weiter Werte liefern
- Seite_AS/Seite_ES ersetzen das immer leere Seite
- VF_Winkel neu neben Winkel (= GF_WINKEL)
Geprueft gegen results/export_raw.json (neue Namen) und
tests/reference/export_raw.json (Alt-Namen); Pflichtfelder aus
tests/test_foerderer.py bleiben vorhanden.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- export_neighbors.py: kreisel_half_bboxes() teilt die Kreisel-BBox entlang
der Achse durch Antriebs-/Spannstation (AN8/SP8) in eine linke und eine
rechte Haelfte (je ca. 400mm breit, siehe [Kreisel] durchmesser_mm in
cfg/export.cfg, gespiegelt von component_defaults.json). compute_neighbor_ids
ersetzt jeden Kreisel-Eintrag in der Kollisionsgruppe durch dieses Paar
(TeileId-L/-R) statt einer einzelnen BBox - Nachbarn einer Gefaellestrecke/
eines Foerderers zeigen jetzt, welche Haelfte tatsaechlich beruehrt.
- compute_sensor_zuordnung(): ordnet jeden Separator/Scanner per BBox-
Ueberschneidung seiner Gefaellestrecke, seinem Foerderer oder einer
Kreiselhaelfte zu (Prioritaet in dieser Reihenfolge), ersetzt die
ZUORDNUNG-Attribut-Merkmale im CSV-Export bei Treffer.
- compute_scanner_nearest_separator(): sucht zusaetzlich, unabhaengig von der
Zuordnung, zu jedem Scanner den raeumlich naechstgelegenen Separator.
- ssg_id.lsp: ssg-id-collect-blocks erfasst jetzt auch Separator_SP/S-LP/
Scanner-Bloecke, damit ssg-id-check-all ihr (neues) ID-Attribut vor jedem
Export befuellt; export_csv.py bevorzugt dieses echte ID-Attribut als
TeileId und faellt nur bei leerem Attribut auf eine laufende SEP-/SCN-
Ersatznummer zurueck.
- data/ils/Scanner_2D.dwg, Scanner_3D.dwg, Separator_SP_2D.dwg: ID-ATTDEF
ergaenzt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Neues Entwickler-Tool (bin/dbg2lsp.bat + lib/dbg2lsp.py), das das manuelle
Einfuegen von dbgf/dbg/dbgreturn/dbgopen/dbgclose automatisiert:
- --method NAME: dbgf + dbg je Parameter + dbgreturn um die letzte Rumpf-Form
- --recursive: verfolgt den Aufrufgraphen ueber Dateigrenzen hinweg (Builtins
werden automatisch uebersprungen, da sie kein defun im Suchpfad haben)
- --add-open DATEI METHODE: dbgopen/dbgclose fuer einen Einstiegspunkt
(z.B. ein c:BEFEHL-Kommando), inkl. aller (exit)-Stellen
Dokumentiert in doc/dbg2lsp.md, Kurzeintrag in CLAUDE.md.
Ausserdem: set_attributs.py aus doc/tools.md und CLAUDE.md entfernt - das
Skript existiert nicht mehr in lib/.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Entfernt "Hoehe oben"/"Hoehe unten" aus Gefällestrecke JSON-Export
- "Hoehe in m" kommt jetzt konsistent aus MONTAGEHOEHE_m bei Kreisel/Variofoerderer/Gefällestrecke
- Setzt "Geruest fuer Einzelmodul" auf Default True (statt False) bei Kreisel, Eckrad, Variofoerderer, Gefällestrecke
- Eckrad-Abfrage: Default = Yes, Logik korrigiert (war invertiert)
- JSON-Key-Reihenfolge optimiert:
- Variofoerderer/ILS 2.0 Strecke: "Hoehe in m" zuerst
- Gefällestrecke/ILS 2.0 Gefällestrecke: "Hoehe in m" und "Typ" zuerst
- Kreisel: "Hoehe in m" zuerst
- Omniflo-Komponenten-Split: Teile mit "0_B"-Präfix werden als separate CSV-Zeilen ausgegeben
- Multi-Komponenten-Sivasnr (z.B. "834372002+0_BG090090") splitten
- IDs werden mit .t1, .t2, etc. ergänzt
- 0_B-Komponenten als "TEF Bogen"/"TEF Weiche" klassifiziert
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
csv:block-to-json ergaenzt fuer jeden Block einen Insertpoint-String
(Position+Rotation als Z-Quaternion, csv:kos-encode) sowie K1-K4 als
reine Positions-Strings (csv:trans-encode, 0.1 mm). KS_EIN/KS_AUS werden
auf K1/K2 gemappt, falls keine echten K1/K2 vorhanden sind. Neue CSV-
Spalten Insertpoint;K1;K2;K3;K4 in export_csv.py.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Kreisel, Eckrad, Gefaellestrecke und VarioFoerderer schreiben jetzt neben
"Geruest fuer Einzelmodul" auch die gewaehlte Geruestoption (GERUEST_TYP)
in die Merkmale. Eckrad bekommt dafuer erstmals eine eigene Gruppierung
nach Geruest-Signatur (bisher immer eine gemeinsame Zeile ohne Details);
Kreisel/Gefaellestrecke gruppieren nun ebenfalls nach Geruestoption, damit
unterschiedliche Optionen nicht mehr in einer Zeile verschwinden.
Die wiederholten (dx**2 + dy**2 [+ dz**2]) ** 0.5-Formeln fuer den
euklidischen Abstand zweier Punkte (K1-K4-Positionsbestimmung fuer
Boegen/Weichen/Weichenkoerper) sind jetzt math.dist(p1, p2) - gleiches
Ergebnis, aber weniger Code und keine Gefahr, beim manuellen Quadrieren
ein Vorzeichen/Exponenten zu vertippen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
export_csv.py und export_sivas.py enthielten je ca. 10 nahezu identische
try/except (ValueError, TypeError)-Bloecke fuer "String zu float/int mit
Fallback". Neue gemeinsame Helfer safe_float()/safe_int()
(export_blockpatterns.py) ersetzen diese Bloecke; dabei auch zwei bislang
ungeschuetzte int()/float()-Aufrufe in export_sivas.py (Kreisel-Zaehler)
abgesichert, die bei fehlerhaften Attributwerten sonst abgestuerzt waeren.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
format_csv_line() in export_csv.py/export_sivas.py hat Feldwerte per
f-String direkt in doppelte Anfuehrungszeichen gesetzt, ohne ein
eingebettetes '"' zu escapen (z.B. eine Bezeichnung mit Anfuehrungszeichen
haette die Spaltengrenze der Zeile kaputt gemacht). Neuer gemeinsamer
Helper csv_quote() (export_blockpatterns.py) verdoppelt eingebettete
Anfuehrungszeichen nach RFC 4180.
Ausserdem: export.cfg wurde bisher von vier unabhaengigen load_*-Funktionen
(load_patterns, load_neighbor_tolerance_mm, load_omniflo_cell_size_mm,
load_planquadrat_config) separat von der Platte gelesen und geparst. Neuer
gemeinsamer, gecachter load_export_cfg() in export_blockpatterns.py sorgt
dafuer, dass export.cfg pro Exportlauf nur noch einmal gelesen wird.
Dabei auch die in export_csv.py bereits genutzte, aber in export_planquadrat.py
fehlende resolve_origins()-Funktion (automatische Planquadrat-Ursprungs-
Ermittlung) ergaenzt - ohne sie war der Import von export_csv.py gebrochen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nachbarschaft wird jetzt in drei getrennten Gruppen geprueft statt global
ueber alle Elemente: Kreisel/Eckrad gegeneinander, Kreisel/Eckrad gegen
Gefaellestrecke/Foerderer/Strecke-Modul (diese drei nicht gegeneinander),
und Omniflo-Elemente gegeneinander (rasterbasiert vorgefiltert nach x/y-
Koordinate). Ersetzt die bisherige shapely-STRtree-Loesung durch reines
Python, da die shapely-Abhaengigkeit den regulaeren CSV-Export in der von
BricsCAD genutzten Python-Umgebung brechen konnte.
Neue Spalte "Fehler" markiert Elemente mit zu wenigen Partnern
("unverbunden"/"nur ein Partner") je nach TeileArt-Mindestanzahl.
Ausserdem: SSG_RUN_ALL_TESTS-Absturz nach TEST_KREISEL behoben (ssg-start/
ssg-end nutzten flache globale Variablen statt eines Stacks, wodurch
verschachtelte Aufrufe den *error*-Handler dauerhaft korrumpierten) und
FILEDIA=0 um den DXFOUT-Kommandozeilenaufruf ergaenzt.
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>
Jeder Kreisel bekommt bei der Erzeugung das neue Attribut GERUEST_EINZELMODUL
(Default false), im KreiselEdit-Dialog per Checkbox "Geruest fuer Einzelmodul"
umschaltbar. Fliesst als echter JSON-Bool ins details-Feld von EXPORTSIVAS/
EXPORTCSV und wird bei der Sivas-Gruppierung gleichartiger Kreisel beruecksichtigt.
Lokaler Stand (Modus-3 Randwert-Solver, 30/90-AS/ES, Kreisel-Attribute)
mit dem Remote-Stand (Internationalisierung ssg-text, neue Bloecke,
Sivas-Export) vereint.
Konfliktaufloesung:
- vf_linienzug.lsp: Nicht-interaktive -block-Kerne (fuer Pfad-Modi) behalten,
interaktive Abfragen (GF-Bogen, Vario-Kurve, ES-Seite) auf ssg-text
umgestellt. Kein doppelter defun mehr.
- Gefaellestrecke.lsp: 30/90-Winkelabfrage mit den i18n-Seiten-Prompts
kombiniert; gefaellestrecke-einfuegen-Aufruf mit as-/es-winkel.
- vf_core.lsp: vf-frage-element-winkel nimmt jetzt einen i18n-Header-Key
(vf-winkel-aus-header / vf-winkel-ein-header) statt festem Text.
- lang/de_DE.json + en_GB.json: neue Keys vf-winkel-aus/ein-header,
vf-winkel-90/30; gf-seite-Header ohne irrefuehrendes "_90_".
- export_sivas.py: ANZAHL_SEPARATOR/ANZAHL_SCANNER mit N_*-Fallback plus
Remote-Umsortierung; doppelte "Kreiselart"-Zeile entfernt.
- AS_Element_30_links/rechts.dwg + Separator_SP.dwg (3D): Remote-Version
(Attribut-Stand) uebernommen. Die KS_AUS-Geometrie-Korrektur der 30-Grad-
AS-Elemente wird danach in BricsCAD nachgezogen.
Offen (Folge-Commit): die Modus-Treiber in vf_linienzug.lsp
(vf-linienzug-modus / -modus2 / -modus3) sind noch nicht i18n
(ca. 110 Strings).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Gefaellestrecke (GF_N): je Zeile eine Gruppe gleichartiger Bloecke (gleiche
Hoehe/Laenge/Winkel/Separatoren/Scanner/Typ), IDs und Bezeichnung als Array
statt einer einzigen Sammelzeile mit reiner Anzahl.
VarioFoerderer (VF_N): je Compound-Block eine eigene Zeile mit vollstaendigen
Gefaelle-/Angetrieben-Teilgruppen (Laengen, Winkel, Kurven, Foerderrichtung),
da VF_N immer TYP "Streckengruppe" ist. Lose Strecke-Elemente ausserhalb
eines VF_N-Blocks bleiben weiterhin in einer gruppierten IDs-Zeile.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sivasnr-Werte mit 0_BGxxxxxx-Mustern werden jetzt ueber die neue
[container]-Config-Sektion in kommaseparierte Listen aufgeloest.
set_attributs.py kann nun explizit zwischen data/omniflo/2D und /3D
als Quellverzeichnis waehlen.