Neues Modul KettenFoerderer.lsp: baut aus KF_UM_<winkel>, KF_LAENGE und
KF_AN_<winkel> (je KS_AUS auf KS_EIN) plus der Draufsicht KF_2D einen Block
KF_<n>. Die Bausteine werden aufgerichtet eingebaut (Rz*Rx(90)*Rz), die Hoehe
laeuft in Z; KF_2D liegt deckungsgleich mit der Kette. Der Einbauwinkel jedes
Folgebausteins wird aus der Richtung des KS_AUS seines Vorgaengers gemessen,
KF_LAENGE ueber die Einbauhoehe skaliert.
- Dialog (DCL-Vorlage, Typ als Radiobuttons), Hoehe per Zahl oder aus zwei
Punkten, Doppelklick auf KF_n oeffnet KF_EDIT mit Neuaufbau
- eigenstaendiges Attribut-Schema, Auswahllisten mit Sivas-Optionstexten in
data/json/kettenfoerderer.json
- Sivas-Export: Merkmale 350, 353-357, 359-361, 391, baugleiche Foerderer
werden zu einer Zeile zusammengefasst (Artikelnummer 6120)
- ssg_ks_insert.lsp: neue Primitiven ks-xy-winkel, ks-block-messen,
insert-block-ks-skaliert und insert-block-ks-matrix (freie 3x3-Rotation);
ensure-block-loaded nimmt Bloecke ohne Dimensionssuffix unveraendert
- Menueeintrag KettenFoerderer aktiviert, toter Dummy OMNI_KettenFoerderer
entfernt; KF_* im Export-Pattern, in der ID-Vergabe und im Dispatcher
SSG_BLOCKEDIT (vor dem Omniflo-Zweig)
- Unit-Tests tu-tests-kf fuer die reinen Rechenkerne; Modul wird in der MNL
vorgeladen, dbg-Schalter kf-zeit zur Laufzeitmessung
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Zwei Themen, die dieselben Dateien beruehren und daher zusammen gehen.
1) VF_HOEHE_m - Hoehe je VF-Segment, Sivas-Merkmale 4433-4437
Sivas erwartet je Streckengruppe bis zu fuenf Variofoerderer-Hoehen.
Neues Block-Attribut VF_HOEHE_m: kommagetrennte Liste in Metern mit 3
Nachkommastellen, Eintrag fuer Eintrag parallel zu L_VF_m/VF_WINKEL.
Je Eintrag der Mittelwert aus KS_EIN und KS_AUS DES GERADEN VF-Abschnitts.
Zwischen Umlenk- und Motorstation koennen mehrere Abschnitte liegen
(auf/ab/horizontal), jeder bekommt einen eigenen Wert.
SONDERFALL Standard/Etage: dort gibt es nur einen Motor und nur einen
geraden Abschnitt - gemessen wird die GANZE Kette (AS-KS_EIN bis
ES-KS_AUS, vf-vfhoehe-kette). Das ersetzt den Segmentwert; der Linienzug
laeuft nicht durch vf-dialog-berechnen-einfuegen und behaelt seine Liste.
WICHTIG - vollstaendige Erfassung: die VF-Segmente entstehen NICHT alle in
vfs-vf-koerper. Horizontale Zwischenstuecke, das "schon flach"-Segment und
die Modus-2/3-Fuellstuecke bauen direkt mit insert-inclined-scaled-block,
die Kette-Merge-Rekonstruktion liest sie aus bestehenden Bloecken. Ein
erster Fix nur in vfs-vf-koerper lieferte darum zu wenige Werte (realer
Befund: L_VF_m hatte drei Eintraege, VF_HOEHE_m einen). Jetzt sind alle 14
Stellen erfasst, die vfl-acc-vf-seg aufrufen - dafuer das Paar
vf-vfhoehe-merke/-schliesse, das ohne lokale Variable auskommt.
REGEL (im Code dokumentiert): Jede Stelle, die vfl-acc-vf-seg aufruft,
MUSS auch eine Hoehe erfassen - sonst verschiebt sich die Liste gegen
L_VF_m und im Export landet eine Hoehe beim falschen Foerderer.
Formatierung ueber vf-meter-3: (rtos x 2 3) allein kuerzt je nach DIMZIN
nachfolgende Nullen ("2.5" statt "2.500", "-1" statt "-1.000") - im
Testlauf real aufgetreten.
Attribut-Schema *strecke-attr-gruppe* (ssg_core.lsp) ergaenzt, sonst
verschluckt ssg-attrib-set-on den neuen Tag stillschweigend.
export_sivas.py verteilt die Liste auf VF_HOEHE_MERKMALE (4433-4437);
ueberzaehlige Abschnitte werden weggelassen statt zusammengefasst, fehlende
lassen das Merkmal ganz weg.
2) AS-Element 30 Grad: Zufuehrungsachse statt Seitenwahl
Der Startpunkt einer Kette mit AS-Element ist geometrisch keine Position,
sondern eine ACHSE: das AS sitzt an einer durchlaufenden Strecke und
schleust daraus aus, seine KS_EIN-Achse muss darauf liegen. Bisher richtete
vfl-insert-as-element das KS_AUS entlang der Kettenrichtung aus, wodurch
das KS_EIN um den Blockschwenk verdreht stand - beim 90-Grad-Element kaum
sichtbar, beim 30-Grad-Element deutlich.
Beim 30-Grad-Element wird die Seitenauswahl im AS-Gruppendialog jetzt
ausgegraut; stattdessen gibt ein zweiter Punkt die Zufuehrungsrichtung
(der Startpunkt bleibt der Sitz des Elements). Die Seite folgt aus der Lage
des naechsten Kettenpunkts zur Achse (vfl-seite-aus-lage). 90 Grad bleibt
unveraendert bei der Seitenfrage.
Der Dialog legt bei 30 Grad bewusst KEINE Seite mehr in die Pending-Queue -
sonst zog die nachfolgende Punktfrage sie als vermeintlichen Punkt heraus
und erschien gar nicht (realer Fehler beim ersten Test).
Abwaertskompatibilitaet: aeltere 30-Grad-Ketten wurden noch MIT Seitenfrage
gebaut. vfl-replay-peek-art sieht beim Replay nach, was tatsaechlich
ansteht ("PT" = Achse, "STR" = Seite) - die Modus-Wahl selbst wird nicht
journalisiert, weil sie daraus eindeutig rekonstruierbar ist.
Unit-Suite 687/687 gruen. VF-Hoehe in BricsCAD bestaetigt. Die AS-Achsenfrage
ist dort noch NICHT gelaufen, seit die Seitenauswahl ausgegraut wird.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Streckenbloecke GF_N und VF_N tragen Winkel und Seite ihres AS-/ES-
Elements bereits als Attribute des gemeinsamen Schemas (WINKEL_AS/SEITE_AS/
WINKEL_ES/SEITE_ES, *strecke-attr-front* in ssg_core.lsp). Diese Information
landet jetzt auch im details-JSON des Sivas-Exports.
Zuordnung (Sivas-Hierarchie: 4431/4432 schalten Winkel und Seite frei):
4431/4432 AS-/ES-Element vorhanden Ja/Nein
4427/4429 Winkel "30 °"/"90 °"
4428/4430 Seite links/rechts
Die Zuordnung steht vollstaendig in cfg/sivas.cfg - mit denselben sechs
Zeilen in [gefaellestrecke] und [variofoerderer], jeweils direkt hinter 2950,
was auch die Reihenfolge im details-JSON bestimmt.
Ob ein Element vorhanden ist, entscheidet ausschliesslich WINKEL_AS/WINKEL_ES:
das Schema laesst den Winkel leer, wenn keines gewaehlt wurde, waehrend
SEITE_AS/SEITE_ES mit "rechts" immer einen Vorgabewert tragen. Ohne Element
bleiben Winkel UND Seite leer, damit in Sivas keine Seite unter einem
"Nein"-Knoten haengt.
Weitere Punkte:
- sivas_mapping: neuer Dekorator @braucht_attribs. Ein so markierter
Transform wird als fn(wert, attribs) statt fn(wert) aufgerufen und sieht
damit die uebrigen Attribute des Blocks - noetig, weil die Seite vom
Winkel abhaengt. Ohne diese Klammer muessten bedingte Merkmale wieder als
Python-Code aus der Config herauswandern.
- Die Winkel-Schreibweise der Sivas-Auswahlliste ("30 °" mit Leerzeichen vor
dem Gradzeichen) steht als Tabelle [as_es_winkel_anzeige] in sivas.cfg,
Bauart wie [geruest_typ_anzeige] - weicht Sivas davon ab, ist das die
einzige Stelle zum Nachziehen.
- gefaellestrecke_signature beruecksichtigt AS/ES: zwei sonst baugleiche
Gefaellestrecken mit AS links bzw. rechts bleiben getrennte Zeilen, sonst
zeigte die gemeinsame Zeile nur die Seite des ersten Blocks.
- Altbestand ohne diese Attribute meldet "Nein" statt abzubrechen.
- Merkmalsstamm_in_Sivas.xlsx auf den aktuellen Sivas-Stand gebracht
(enthaelt neben 4427-4432 auch 4002, 7010-7013 und Klartext-Korrekturen;
4339/4383 heissen jetzt eindeutig "... Gefaellestrecke"/"... Variofoerderer").
- 12 neue Tests in tests/test_export_sivas_as_es.py, ohne BricsCAD lauffaehig.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Eckrad: eigener DCL-Dialog (eckrad_edit.dcl) beim Einfuegen und per
Doppelklick (EckradEdit); Sivas-Merkmale am Kreisel ausgerichtet
(2950, 3381, 3992 Ja/Nein); bei Sep./Scanner-Zaehlung ausgenommen
- Kreisel: eigener Name bleibt in Bezeichnung + Beschriftung erhalten
- Sivas: Kreisel/Eckrad unterschiedlicher Hoehe nicht mehr zusammengefasst
- Export: Hoehen-Attribute in Z verschobener Kreisel/Eckrad/VF/GF neu
berechnet
- GF-Edit: Einfuegehoehe aus aktueller Z-Koordinate
Eckrad fuehrte "Geruest fuer Einzelmodul"/"Geruestoption fuer
Einzelmodul" als beschreibende Klartext-Keys statt echter
Merkmalnummern - details_mit_bezeichnung() loest aber nur numerische
Keys gegen den Merkmalstamm auf, die Texte blieben im JSON unaufgeloest.
Merkmalsstamm_in_Sivas.xlsx enthaelt beide Nummern bereits (dieselben
wie bei Kreisel), jetzt in cfg/sivas.cfg uebernommen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
SSG_RUN_ALL_TESTS_EXPORT setzte *export-test-override* nicht, dadurch
landeten CSV/Sivas-Exporte trotz Automatik-Modus in DXFM_RESULTS statt in
tests/output wie die DXF/DWG-Dateien selbst - jetzt analog zu
TEST_EXPORT_ALL behoben.
EXPORTSIVAS schrieb bisher immer zusaetzlich eine "_mit_bezeichnung.csv"
(Klartext-Kopie). Neuer Schalter "Sivas Export mit Bezeichner" im Dialog
CSV_EXPORT_KONFIG (Standard aus) macht das optional.
Die Attribut->Sivas-Merkmal-Zuordnung der build_*_details-Funktionen in
export_sivas.py (Gefaellestrecke/Kreisel/Eckrad/Geruest/VarioFoerderer,
soweit nicht von der Segmentanzahl abhaengig) liegt jetzt deklarativ in
cfg/sivas.cfg statt hartcodiert im Python - neuer Loader
lib/sivas_mapping.py. Ablauflogik (Gruppierung, Automation-Summenzeile,
Segment-Zaehlung) bleibt Code. Gegen den alten Code mit synthetischen
Testblöcken verifiziert: identische Ausgabe.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
K1/K2 und Boundingbox je Export-Zeile folgen jetzt dem echten
Kettenbaustein statt seinem Stellvertreter:
- Separator (all_elements): KS + bbox des 300-mm-Trennstegs statt des
Sensor-Symbols; separator_track/group_vf_gf behalten das Symbol
- AS/ES (all_elements, group_vf_gf): KS + bbox des AS-/ES-Elements statt
des 200x200-Markers ohne K
- gemeinsamer Kern csv:ks-welt-punkte; VF/GF-Wrapper-K1/K2 = K1 des AS
bzw. K2 des ES
Gruppierter Export neu (sepliste-/XDATA-Algorithmus entfernt):
- Bausteine je Wrapper als Vektorkette K2 -> K1 ordnen (Start am AS)
- Foerdereinheit = Separator vor der Umlenkstation bis Motorstation,
alles dazwischen Gefaelleeinheit (csv:kette-einheiten, Unit-Tests)
- je Einheit ein temporaerer Proxy mit 3D-Boundingbox, K1/K2, Laenge und
Anzahl Boegen; wird nach dem Export geloescht (ausser csv_leave_proxies)
- IDs neuer Export-Objekte entlang der Kette AS -> ES aufsteigend
Weiteres:
- ssg-make-layer ohne _LAYER-Befehl fuer bestehende Layer (Konsole)
- einheitliche, zweisprachige Meldungen fuer behaltene Hilfskopien
- bin/show_exportcsv.bat: Export-CSV als Boundingbox-SVG (sps_skel)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Die Einzelteil-Proxy-Zeilen (Boegen, Streckenelemente, Umlenk-/Motorstation)
aus der letzten Session sind fuer den Normalfall zu granular. Standardmaessig
(*csv-export-alle-elemente* = nil) fasst csv:unitmark-aktualisieren sie jetzt
zu je einer "Foerdereinheit"/"Gefaelleeinheit"-Zeile pro zusammenhaengendem
VF-/GF-Abschnitt einer Kette zusammen, mit einem persistenten Rechteck-Marker
(ZZ_UNIT_MARKER, analog ZZ_ASES_MARKER) auf der Bounding-Box-Vereinigung
aller enthaltenen Elemente. Der bisherige Rohdaten-Export bleibt ueber
(csv:export-alle-elemente-an) weiterhin verfuegbar.
Einheiten-Grenzen kommen rein export-seitig aus der sepliste (SEP/AS/ES in
echter Bau-Reihenfolge) plus dem bereits vorhandenen SSG_SEP_TYP je
Separator - eine bauzeitige Markierung in vf_linienzug.lsp/vf_standard.lsp/
vf_etage.lsp waere deutlich invasiver gewesen (3 unabhaengige Baupfade ohne
gemeinsamen Einstiegspunkt). csv:sepliste-partition (Lauflaengen-Kodierung
ueber die typisierte sepliste) und csv:element-unit-zuordnung (Zuordnung der
gesammelten Elemente per Kettenrichtungs-Projektion statt der nachweislich
unzuverlaessigen csv:nested-welt-records-Listenreihenfolge) sind reine,
dateifrei getestete Funktionen.
Korrigiert nebenbei eine falsche Annahme: L_VF_m/L_GF_m zaehlen pro Segment,
nicht pro Einheit - die tatsaechliche Einheiten-Anzahl kommt nur aus der
sepliste-Typfolge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bisher tauchten nur der Wrapper selbst, verpackte Separatoren und AS/ES-
Kettenenden als eigene CSV-Zeilen auf - die uebrigen Kettenbausteine
(Boegen, gerade Foerderer-/Gefaellestrecken-Segmente, Umlenk-/Motorstation)
blieben nur in der Wrapper-Blockdefinition verpackt. csv:element-proxies-
erzeugen (analog zu csv:sep-proxies-erzeugen) fuegt fuer jeden Fund eine
temporaere Kopie ein, K1/K2 kommen aus dem EIGENEN KS_EIN/KS_AUS jedes
Elements (nicht dem Gesamt-AS/ES der Kette) und bleiben leer, wo keines
existiert (z.B. das nie tatsaechlich eingefuegte Vario_Kurve_*).
Zusaetzlicher Fix: csv:get-k-kos-strings ignorierte bisher die Skalierung
des Top-Level-Inserts - fuer Staustrecke_SP_1000_mm (das per Laenge nicht-
uniform skaliert wird) waere K2 damit falsch gewesen, unabhaengig von der
tatsaechlich gebauten Segmentlaenge.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die Materialfluss-Ein-/Ausgangssymbole (Bloecke Eingang_<DIM>/Ausgang_<DIM>,
eingefuegt ueber ils-insert-station) erscheinen jetzt NUR im CSV-Export als
eigene TeileArt-Zeile ("Eingang"/"Ausgang", Merkmale wie BTMT). Wie
Separator/AS/ES nehmen sie als freie Umlauf-Punkte (KREISEL_UMLAUF_TEILEARTEN)
an der TrackIds-Spalte teil und tauchen so auch auf Kreiseln auf, auf deren
Bahn sie liegen. Der Sivas-Export schliesst sie bewusst aus.
- cfg/export.cfg: pattern_eingang/pattern_ausgang
- Lisp/export.lsp: csv:collect-export-blocks sammelt beide Muster
- Lisp/ssg_id.lsp: ssg-id-collect-blocks erfasst sie (ssg-id-check-all fuellt
das nachgetragene ID-ATTDEF, dokumentiert in data/ils/allocations.json)
- lib/export_csv.py: Klassifikations-Zweige Eingang/Ausgang
- lib/export_neighbors.py: KREISEL_UMLAUF_TEILEARTEN um Eingang/Ausgang erweitert
- lib/export_sivas.py: Eingang/Ausgang uebersprungen (kein Sivas-Eintrag)
- Tests: test_export_eingang_ausgang.py + Kreisel-Umlauf-Test
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
details_mit_bezeichnung() liefert fuer die "*_mit_bezeichnung.csv" jetzt
{"<Nummer>": {"bezeichnung": "...", "wert": "..."}} statt eines
zusammengesetzten Schluessels "<Nummer> | <Bezeichnung>" - Merkmalnummer
bleibt dadurch ein sauberer JSON-Key, Bezeichnung/Wert sind eigene,
eindeutig benannte Felder. Die eigentliche Sivas-Import-Datei
(*_sivas.csv) ist davon nicht betroffen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- ILS 2.0 Kreisel/Strecke(VF_N)/Gefaellestrecke/Automation: details-JSON
nutzt jetzt Sivas-Merkmalnummern (z.B. "2952") statt beschreibender
Klartext-Keys, abgeglichen mit dem Merkmalstamm in
cfg/Merkmalsstamm_in_Sivas.xlsx.
- ILS 2.0 Zusatzmodul: BT-Beladung und Abwurfstationen laufen jetzt in
einer gemeinsamen Zeile (Merkmale 3501-3504) statt zwei separaten
Zeilen ohne details.
- Gefaellestrecke-Gruppe: Anzahl-Spalte bleibt fest 1, die reale
Stueckzahl der Gruppe steht im Merkmal 4311 (anders als bei Kreisel,
wo die Anzahl-Spalte die Stueckzahl traegt und 3511 fix "1" ist).
- Automation-Summenzeile: 4407 zaehlt jetzt echte Streckengruppen
(VF_N-Bloecke) statt eines 0/1-Flags, 4408 (Motoren Vario-Foerderer)
wird erstmals tatsaechlich berechnet (vorher nie inkrementiert), 4426
steht fest auf "0" (Konzept "einzelner Variofoerderer" entfaellt).
- Neues Modul lib/merkmalstamm.py: liest Merkmalnummer->Bezeichnung aus
der xlsx rein per Standard-Library (zipfile/xml.etree, keine neue
pip-Abhaengigkeit fuer den ueber export.lsp aufgeloesten Interpreter).
- export_sivas.py schreibt bei jedem Lauf zusaetzlich eine zweite Datei
"<name>_mit_bezeichnung.csv" (gleicher Inhalt, aber jeder
Merkmalnummer-Key um "<Nummer> | <Bezeichnung>" erweitert) - reine
Lesehilfe zur Pruefung, wird von Sivas nicht eingelesen.
- cfg/sivas_merkmal_zuordnung.md: Nachschlagetabelle Block-Attribut <->
Merkmalnummer je Teileart, inkl. offener Punkte (Separator-/
Scanner-Aufteilung Gefaelle-/Vario-Anteil noch Platzhalter).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
LAYER ist reine BricsCAD-Zeichnungsinformation ohne Sivas-Bedeutung.
export_csv.py (bricscad.csv) behaelt es weiterhin fuer die Zuordnung in der
Zeichnung.
Sivas kennt nur eine Sivasnr je Zeile - ARTINR (kommagetrennte Liste) wird
daher aufgesplittet. Gleiche Artikelnummern innerhalb derselben Baugruppe
werden zu einer Zeile mit Anzahl>1 zusammengefasst (wie bei Boegen/Weichen).
Jede resultierende Zeile traegt die volle LAENGE der Baugruppe.
GR_-Bloecke werden jetzt wie BTMT eigenstaendig gesammelt (LISP: neues
pattern_geruest in cfg/export.cfg, csv:collect-export-blocks,
ssg-id-collect-blocks + ID-ATTDEF in *geruest-attrib-defs*) und in beiden
Python-Exporten als eigene TeileArt-Zeile ausgegeben: ARTINR/BEZEICHNUNG/
TEILEART/LAENGE in festen Spalten, restliche Attribute (FARBE/LAYER) im
Merkmale-/details-JSON.
Dabei zwei Bugs behoben, die beim ersten echten GR_-Export sichtbar wurden:
- csv:json-escape nutzte vl-string-subst (ersetzt nur das erste Vorkommen)
statt des global ersetzenden ssg-str-replace-all - bei Attributwerten mit
mehreren Anfuehrungszeichen blieb ein Zeichen unescaped und brach die
JSON-Struktur beim Python-Parsen.
- Gradzeichen (°) in data/json/geruest.json durch "Grad" ersetzt, um das
Encoding-Risiko (cp1252 vs. UTF-8 beim LISP-Export) zu vermeiden.
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>
- 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>
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.
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>
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.
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.
y.wang
s.hensch
m.stangl
s.ayadi