dxfmakros/doc/csv-export.md

# CSV-Export (EXPORTCSV) — Ablauf und Architektur

Beschreibt den kompletten Weg vom `EXPORTCSV`-Befehl in BricsCAD bis zur
fertigen CSV: welche Daten LISP sammelt, was Python daraus berechnet, und wie
die "Nachbarn"-Spalte zustande kommt. Stand: `Lisp/export.lsp`,
`lib/export_csv.py`, `lib/export_neighbors.py`.

## Ueberblick: zwei Phasen, eine JSON-Datei dazwischen

```
BricsCAD (LISP)                          Python
─────────────────                        ──────
c:EXPORTCSV
  -> csv:run-export
       -> Kopien fuer verpackte
          Separatoren einfuegen
       -> AS/ES-Marker aufbauen
       -> IDs vergeben (ssg-id-check-all)
       -> IDs in die sepliste
          eintragen
       -> Separator-/Scanner-Zuordnung
          (count_sep_scan.lsp)
       -> REGENALL
       -> csv:collect-export-blocks    export_raw.json   lib/export_csv.py::main
       -> je Block csv:block-to-json  ───────────────>     -> process_blocks
                                                              -> Nachbarschaft/
                                                                 Umlauf/Zuordnung
                                                              -> CSV schreiben
```

LISP sammelt reine Zeichnungsdaten (Position, Rotation, Attribute,
Bounding-Box, Anschluss-Koordinatensysteme) und schreibt sie als flaches
JSON-Array (`results/export_raw.json`). Python bekommt keine BricsCAD-API zur
Verfuegung — es rechnet ausschliesslich mit den Zahlen aus diesem JSON. Alles,
was "Nachbar X kennt Nachbar Y" bedeutet, wird also in Python aus Geometrie
(Bounding-Box-Ueberschneidung, Distanz, Winkel) oder aus mitgelieferten
Reihenfolge-Daten (sepliste, siehe unten) rekonstruiert — LISP selbst kennt
diese Beziehungen beim Bauen der Einzelketten nicht.

## Phase 1 (LISP): `csv:run-export` — was vor dem JSON passiert

Datei: `Lisp/export.lsp`. `c:EXPORTCSV` ruft `csv:run-export` mit
`include-bbox=T` auf (im Unterschied zu `c:EXPORTSIVAS`, das keine
Bounding-Boxen braucht).

1. **`csv:sep-proxies-erzeugen`** — Separator_SP-Symbole, die beim
   Zusammenbau von `KREISEL_n`/`ECKRAD_n`/`VF_n`/`GF_n` in die
   Compound-Blockdefinition verpackt wurden, sind fuer `(ssget "X" ...)`
   unsichtbar. Diese Funktion fuegt fuer jeden Fund eine ECHTE, temporaere
   Kopie als top-level INSERT an derselben Weltposition ein. Die Kopie
   durchlaeuft danach ID-Vergabe und Export ganz normal ueber den freien-
   Separator-Pfad (Blockname-Muster `Separator_SP*` trifft zu) und bekommt
   dadurch eine echte `vla-getboundingbox`-Box, die das verpackte Original nie
   haben koennte. Rueckgabe: Liste von Records
   `(proxy-ename wrapper-ename typ (x y z))`.
1b. **`csv:asmark-aktualisieren`** — die AS-/ES-Enden derselben Kette
   (`AS_Element*`/`ES_Element*`, Muster `pattern_schleuselement`) bekommen
   KEINE temporaere Kopie, sondern einen DAUERHAFTEN Marker — siehe eigener
   Abschnitt "Der AS/ES-Marker" unten. Beide Wege teilen sich die
   Platzierungsrechnung (`csv:nested-welt-records` liefert die Weltlage jedes
   verpackten Fundes, `csv:block-einfuegen-welt` setzt ein Objekt dorthin).
2. **`ssg-id-check-all`** — vergibt fehlende IDs (inkl. der frisch erzeugten
   Proxies) und korrigiert Duplikate. Muss NACH den Proxies laufen, sonst
   wuerden diese Kopien numerisch nie erfasst. `ssg-id-collect-blocks`
   (`ssg_id.lsp`) erfasst dafuer auch `AS_Element*`/`ES_Element*`.
3. **`csv:sep-proxies-zuordnung-setzen`** — jetzt steht die ID jedes Wrappers
   fest: die Proxy-Kopie bekommt `ZUORDNUNG = Wrapper-ID` fest zugewiesen
   (nicht geraten) und wird zusaetzlich in `*cs-sep-fix-by-handle*` vermerkt,
   damit `count_sep_scan.lsp` diesen Wert spaeter nicht per Geometrie
   ueberschreibt. Nur fuer die Separator-Kopien — AS/ES sind keine Sensoren.
3b. **`csv:asmark-ids-setzen` + `csv:sepliste-ids-setzen`** — ebenfalls erst
   jetzt moeglich: jedes Bauteil wird seinem `sepliste`-Eintrag zugeordnet und
   seine ID unter `*csv-sepliste-id-by-handle*` (Key = Wrapper-Handle)
   abgelegt; `csv:block-to-json` schreibt sie als Feld `id` in den Eintrag.
   AS/ES laufen ueber die Marker (die ihre ID schon kennen, die Zuordnung
   steht im Marker-Attribut `LFDNR`), SEP ueber die temporaeren Kopien und
   `csv:sepliste-paare` — siehe eigener Abschnitt unten. `csv:asmark-ids-setzen`
   traegt zusaetzlich die `ZUORDNUNG` (Wrapper-ID) am Marker nach; ohne sie
   faende der naechste Export den Marker nicht wieder.
4. **`omni:update-all-attribs`** — Hoehe/Drehung aller Omniflo-Elemente vor
   dem Export aktualisieren.
5. **`count_sep_scan.lsp::cs-zuordnung-lauf`** (nur bei Bedarf, siehe
   `cs-zuordnung-noetig-p`) — ordnet frei platzierte Separator/Scanner-Symbole
   per Bounding-Box-Ueberschneidung bzw. Distanz einem Kreisel/VF/GF zu und
   schreibt `ANZAHL_SEPARATOR`/`ANZAHL_SCANNER` an den Carrier.
6. **`REGENALL`** — erzwingt eine vollstaendige Regeneration der Zeichnung.
   Notwendig, weil `vla-getboundingbox` sonst in der Praxis fehlschlagen kann
   (realer Fall: ein Export ohne vorheriges REGENALL lieferte fuer ALLE 75
   Bloecke keine Bounding-Box). `csv:get-bbox` ruft zusaetzlich pro Objekt
   `vla-update` auf, das allein reichte in diesem Fall nicht aus.
7. **`csv:collect-export-blocks`** — sammelt alle relevanten top-level
   INSERTs (Kreisel, Omniflo, VF/GF-Wrapper, Separator/Scanner,
   BTMT-Stationen, Eingang/Ausgang) ueber die Blockname-Muster aus
   `cfg/export.cfg` `[blockpattern]`.
8. **`csv:block-to-json`** je Fund — siehe naechster Abschnitt.

### `csv:block-to-json` — Inhalt eines JSON-Eintrags

Pro INSERT wird ein JSON-Objekt geschrieben:

| Feld | Quelle | Bemerkung |
|---|---|---|
| `block_name`, `layer`, `handle` | direkt vom INSERT | |
| `x`, `y`, `z`, `rotation` | `(assoc 10)` / `(assoc 50)` | roher Einfuegepunkt/-winkel, KEIN `vla-getboundingbox` |
| `attribs` | alle ATTRIB-Werte | |
| `insertpoint` | `csv:kos-encode` | Position+Rotation als 24-Zeichen-Base64 (Quaternion) |
| `k1`..`k4` | `csv:get-k-kos-strings` bzw. Fallbacks | Anschluss-Koordinatensysteme, siehe unten |
| `bbox` | `csv:get-bbox` (`vla-getboundingbox`) | NUR wenn `include-bbox=T` und der Aufruf gelingt; fehlt sonst komplett im JSON |
| `warnung` | `*cs-scanner-warnung-by-handle*` | strittige Scanner-Zuordnung aus `cs-zuordnung-lauf` |
| `zuordnung_fix` | `*cs-sep-fix-by-handle*` | nur bei Proxy-Kopien: die feststehende Wrapper-ID |
| `sepliste` | `ssg-sepliste-xdata-lesen` + `*csv-sepliste-id-by-handle*` | nur bei VF_n/GF_n, siehe eigener Abschnitt |

**K1-K4 je Blocktyp:** normale ILS-Bloecke fuehren echte K1-K4-Sub-Bloecke.
Omniflo-Geraden (`AP110*`) haben keine echten K-Bloecke — K1/K2 werden aus
Laenge+Rotation synthetisiert (`csv:gerade-k-kos-strings`). VF_n/GF_n leiten
K1 (Eingang) und K2 (Ausgang) aus den eingebetteten AS_Element/ES_Element ab
(`csv:vfgf-k-kos-strings`), damit die Kreisel<->Strecke-Kollisionspruefung in
Python mit einer kleinen festen Box an der AS/ES-Position arbeiten kann statt
mit der ganzen (oft sehr langen) Wrapper-Box.

**Die `bbox` ist das einzige Feld, das `vla-getboundingbox` braucht** — alle
anderen Felder kommen aus rohen DXF-Gruppencodes oder XDATA. Ein Ausfall von
`vla-getboundingbox` zeigt sich also NICHT im ganzen JSON-Eintrag, sondern nur
im fehlenden `bbox`-Objekt. `csv:get-bbox` protokolliert einen Fehlschlag seit
Kurzem in `*csv-bbox-fail-count*`/`*csv-bbox-fail-first*`; `csv:run-export`
meldet nach dem JSON-Schreiben eine Warnung (`exp-bbox-fail`), falls das
vorkam.

### Die `sepliste` — Reihenfolge-Information einer VF_n/GF_n-Kette

Waehrend eine Gefaellestrecke (`GEFAELLESTRECKE`) oder ein VarioFoerderer
(`FOERDERANLAGE`) gebaut wird, sammelt `ssg-sepliste-sammeln`
(`Lisp/ssg_ks_insert.lsp`) alle currently frisch erzeugten `AS_Element_*`-,
`Staustrecke_Separator_SP_300_mm*`- und `ES_Element_*`-Sub-INSERTs in
Baureihenfolge und schreibt sie als XDATA (App `SSG_VF_SEP`/`SSG_GF_SEP`) auf
den fertigen Wrapper: `[(typ lfdnr x y), ...]` mit `typ` = `"AS"`/`"SEP"`/
`"ES"`, `lfdnr` 1-basiert. Das ist reine Bauabfolge, keine Weltkoordinate im
strengen Sinn — je nach Bauphase koennen einzelne Eintraege noch im
Baukoordinatensystem stehen, bevor die Kette an ihre finale Position
verschoben wurde (siehe Abschnitt "sepliste-Koordinaten" unten).

Die sepliste beschreibt NUR die Reihenfolge innerhalb einer Kette
(AS -> Sep1 -> ... -> SepN -> ES). Sie sagt nichts darueber, an welchen
Kreisel die Kette andockt — das ergibt sich erst aus der geometrischen Lage
in der fertigen Zeichnung (siehe Python-Teil).

**Wichtig:** die in einer Kette verpackten Separatoren sind KEIN doppeltes
Konzept zur sepliste — es sind dieselben physischen Symbole, nur aus zwei
Blickwinkeln: `csv:sep-proxies-erzeugen` liefert sie als echte, exportierbare
INSERT-Kopie (mit Bounding-Box und ID); die sepliste liefert dieselben
Separatoren als Eintraege mit Vorgaenger-/Nachfolger-Wissen. Python fuehrt
beides zusammen (siehe `map_separator_kette_items` unten) statt sie doppelt
zu zaehlen.

### Das Feld `id` je sepliste-Eintrag

Seit `csv:sepliste-ids-setzen` traegt JEDER Eintrag zusaetzlich die `id` des
realen Bauteils, das ihn in der Zeichnung vertritt:

```json
{"typ": "AS", "lfdnr": 1, "x": 5070.1, "y": 1199.2, "id": "0031"}
```

Das ist dieselbe ID, die die zugehoerige temporaere Kopie in ihrer eigenen
JSON-Zeile traegt — die Verbindung "Kettenglied <-> reales Teil" steht damit
schon im Export und muss in Python nicht mehr ueber Koordinaten-Naehe geraten
werden (`map_separator_kette_items`, siehe unten; solange Python das Feld noch
nicht liest, aendert sich dort nichts). Das Feld fehlt, wenn keine Kopie
erzeugt werden konnte oder deren ID-Attribut leer blieb — Altbestand und
Fehlerfaelle verhalten sich damit wie bisher.

### Der AS/ES-Marker (`ZZ_ASES_MARKER`)

Die beiden Kettenenden stecken als `AS_Element_*`/`ES_Element_*` verpackt in
der Wrapper-Blockdefinition: in der Zeichnung sind sie weder anklickbar noch
einzeln erkennbar, und `(ssget "X" ...)` findet sie nicht. `csv:asmark-*`
(`Lisp/export.lsp`) setzt darum an jedes Ende ein kleines Rechteck, das nach
dem Export in der Zeichnung STEHEN BLEIBT:

- **Sichtbarmachung** — Kantenlaenge aus `cfg/export.cfg` `[Marker]`
  `ases_groesse_mm` (Default 200 mm), mittig auf dem Einfuegepunkt des
  Schleuselements, in dessen Drehung (auch bei geneigter Kette). Layer aus
  `cfg/layer.cfg` `[allgemein]` `ases_marker` — abschaltbar wie jede andere
  Hilfsgeometrie. Die Blockdefinition wird bei Bedarf zur Laufzeit erzeugt
  (`csv:asmark-blockdef-sicherstellen`, Rechteck + ATTDEFs + `_.-BLOCK`), es
  gibt keine DWG dafuer.
- **ID-Traeger** — die Attribute (alle unsichtbar) sind
  `ID`, `ZUORDNUNG` (Wrapper-ID), `TYP` (`AS`/`ES`), `LFDNR` (sepliste-Eintrag),
  `ELEMENT` (Blockname des echten Elements, haelt die Variante 30/90,
  links/rechts, 2D/3D fest) und `ARTINR`. `ssg-id-check-all` fuellt die `ID`,
  und weil der Marker liegen bleibt, **behaelt ein AS/ES seine TeileId ueber
  Exportlaeufe hinweg** — im Unterschied zu den Separator-Kopien, die jeder
  Lauf neu erzeugt und neu nummeriert.

Der Marker ist abgeleitete Geometrie: jeder Export baut ihn neu auf (die Lage
folgt damit automatisch einer umgebauten Kette) und uebernimmt vom bisherigen
Marker nur dessen `ID`. Wiedergefunden wird er ueber (`ZUORDNUNG`, `TYP`,
`LFDNR`) — bewusst nicht ueber die Position, damit eine verschobene Kette ihre
TeileIds behaelt. Was am Ende keinem Kettenende mehr entspricht (Kette
geloescht, Eintrag entfallen), wird geloescht; Karteileichen entstehen nicht.
Ein frisch gebauter Wrapper hat beim Setzen der Marker noch keine ID — seine
Marker bekommen die `ZUORDNUNG` nach der ID-Vergabe nachgetragen und sind ab
dem naechsten Export wiederfindbar.

Im Export ist der Marker eine eigene Zeile (`pattern_ases_marker` in
`cfg/export.cfg`) und liefert die `id` des AS-/ES-Eintrags in der `sepliste`.

**Zuordnung Eintrag -> Kopie (`csv:sepliste-paare`).** Verglichen wird nur
innerhalb desselben Typmarkers (`AS`/`ES`/`SEP`) und EXKLUSIV: alle Paare
eines Typs werden nach Abstand sortiert, das kuerzeste zuerst genommen, danach
sind Eintrag UND Kopie verbraucht. Zwei Gruende gegen das naheliegende "je
Eintrag die naechste Kopie":

- waehlen zwei Eintraege dieselbe Kopie, bleibt eine Kopie ohne Eintrag und
  ein Eintrag ohne ID (genau dieses Muster verursacht in Python die
  Separatoren ohne `Nachbarn`/`TrackIds`);
- EIN fehlerhafter Koordinatenwert in der sepliste (bekannter Fall: gespiegeltes
  `x` bei `lfdnr=2`) verschiebt so keine anderen Zuordnungen mehr — alle
  uebrigen Eintraege finden ihre Kopie ueber den kurzen Abstand zuerst, der
  fehlerhafte bekommt den Rest zugeteilt. Liegt dieser Rest weiter als
  `csv:sepliste-abstand-warnung-mm` (500 mm) entfernt, meldet der Export das
  (`exp-sepliste-abstand`), ohne die Zuordnung zu verwerfen.

Die Sortierung ist eine strikte Totalordnung (Abstand, dann `lfdnr`, dann
Index) — `vl-sort` wirft Elemente weg, die unter der Vergleichsfunktion gleich
sind, zwei Paare mit identischem Abstand wuerden sonst zu einem verschmelzen.
Getestet in `tests/test_unit.lsp` (`csv:sepliste-paare/*`, zeichnungsfrei).

## Phase 2 (Python): `lib/export_csv.py::process_blocks`

Aufruf: `python export_csv.py <export_raw.json> <data_dir> <output.csv>`.
`main()` laedt das JSON, den Omniflo-Katalog (Boegen/Weichen) und ruft
`process_blocks(blocks, lookup)` auf, das die eigentliche Item-Liste baut.

CSV-Spalten (Header, siehe `format_csv_line`/`main`):

```text
Elementnummer;TeileArt;TeileId;Bezeichnung;Planquadrat;Anzahl;Position;Boundingbox;
Insertpoint;K1;K2;K3;K4;Nachbarn;TrackIds;Fehler;Warnungen;Merkmale
```

- **Position** = Mittenkoordinate x, y, z; **Boundingbox** = Ausdehnung
  (Laenge, Breite, Hoehe) in x, y, z — beide aus `csv:get-bbox`
  (`vla-getboundingbox`), siehe Phase 1.
- **Insertpoint** = KOS-String (24-Zeichen Base64, Position+Rotation als
  Quaternion, `csv:kos-encode`) des Block-Einfuegepunkts selbst.
- **K1-K4** = Positions-Strings der im Block enthaltenen Koordinatensysteme
  K1..K4 (12-Zeichen Base64, nur Position, `csv:trans-encode`) — nur bei
  Omniflo Bogen/Weiche/Gerade und VF_n/GF_n (K1/K2 aus AS/ES) vorhanden,
  sonst leer.
- **Fehler** = `"unverbunden"` (keine Partner, aber mindestens einer noetig),
  `"nur ein Partner"` (ein Partner, aber mindestens zwei noetig) oder leer.
  Kreisel/Eckrad/Omniflo brauchen mindestens einen Partner,
  Gefaellestrecke/Foerderer/Strecke-Modul mindestens zwei
  (`export_neighbors.MIN_PARTNER`).
- **Elementnummer** wird NICHT aus der TeileId uebernommen, sondern am Ende
  neu von 1 an vergeben, nachdem alle Zeilen aufsteigend nach TeileId
  sortiert wurden (`teileid_sort_key` in `process_blocks`). Ohne geloeschte
  Elemente stimmen Elementnummer und TeileId dadurch ueberein; geloeschte
  Elemente hinterlassen Luecken nur in der TeileId-Folge. Zeilen ohne
  numerische TeileId (Omniflo-Sum-Zeile, SEP-/SCN-Fallback-IDs ohne
  ID-Attribut) behalten stabil ihre bisherige Reihenfolge und stehen danach.

### Beispiel: Kreisel mit 2 Separatoren + VarioFoerderer mit 2 Separatoren

Ausgangslage in der Zeichnung: ein kleiner Kreisel (`KREISEL_1`, ID `0010`)
mit zwei frei aufgesetzten Separatoren auf seiner Bahn, daran andockend ein
`VF_1` mit einer Kette AS -> Separator -> Separator -> ES (IDs `0021`-`0024`).

**Ausschnitt `export_raw.json`** (von `csv:collect-export-blocks` /
`csv:block-to-json` geschrieben, hier gekuerzt auf die fuer dieses Beispiel
relevanten Felder):

```json
[
  {
    "block_name": "KREISEL_1",
    "layer": "ILS_Kreisel",
    "handle": "2A1",
    "x": 10000.0, "y": 5000.0, "z": 0.0, "rotation": 0.0,
    "attribs": {"ID": "0010", "DREHRICHTUNG": "UZS", "ABSTAND": "800"},
    "insertpoint": "AAB3QAAATkAAAAAA...",
    "bbox": {"min": [9200.0, 4200.0, 0.0], "max": [10800.0, 5800.0, 0.0]}
  },
  {
    "block_name": "Separator_SP_300mm",
    "layer": "ILS_Sensor",
    "handle": "2A5",
    "x": 10800.0, "y": 5000.0, "z": 0.0, "rotation": 0.0,
    "attribs": {"ID": "0011"},
    "insertpoint": "AAD4QAAATkAAAAAA..."
  },
  {
    "block_name": "Separator_SP_300mm",
    "layer": "ILS_Sensor",
    "handle": "2A9",
    "x": 10000.0, "y": 5800.0, "z": 0.0, "rotation": 90.0,
    "attribs": {"ID": "0012"},
    "insertpoint": "AAB3QAAAxEAAAAAA..."
  },
  {
    "block_name": "VF_1",
    "layer": "ILS_Foerderer",
    "handle": "2B0",
    "x": 10800.0, "y": 5000.0, "z": 0.0, "rotation": 0.0,
    "attribs": {"ID": "0021", "Bezeichnung": ""},
    "insertpoint": "AAD4QAAATkAAAAAA...",
    "k1": "AAD4QAAATkAAAAAA...",
    "k2": "AAAAQwAATkAAAAAA...",
    "bbox": {"min": [10800.0, 4850.0, 0.0], "max": [13000.0, 5150.0, 300.0]},
    "sepliste": [
      {"typ": "AS",  "lfdnr": 1, "x": 10800.0, "y": 5000.0, "id": "0025"},
      {"typ": "SEP", "lfdnr": 2, "x": 11600.0, "y": 5000.0, "id": "0022"},
      {"typ": "SEP", "lfdnr": 3, "x": 12300.0, "y": 5000.0, "id": "0023"},
      {"typ": "ES",  "lfdnr": 4, "x": 13000.0, "y": 5000.0, "id": "0026"}
    ]
  },
  {
    "block_name": "Separator_SP_300mm",
    "layer": "ILS_Sensor",
    "handle": "2B4",
    "x": 11600.0, "y": 5000.0, "z": 0.0, "rotation": 0.0,
    "attribs": {"ID": "0022"}
  },
  {
    "block_name": "Separator_SP_300mm",
    "layer": "ILS_Sensor",
    "handle": "2B8",
    "x": 12300.0, "y": 5000.0, "z": 0.0, "rotation": 0.0,
    "attribs": {"ID": "0023"}
  }
]
```

Die beiden Separatoren `0022`/`0023` sind hier die ECHTEN, top-level
exportierten Separator-Bloecke (identisch mit den `SEP`-Eintraegen der
`sepliste` von `VF_1` — siehe "Die `sepliste`" oben: kein doppeltes Konzept,
zwei Blickwinkel auf dieselben Symbole).

**Resultierende CSV-Zeilen** (Header + betroffene Zeilen, Spalten
`Insertpoint`/`K3`/`K4`/`Merkmale` fuer die Lesbarkeit gekuerzt):

```text
Elementnummer;TeileArt;TeileId;Bezeichnung;Planquadrat;Anzahl;Position;Boundingbox;Insertpoint;K1;K2;K3;K4;Nachbarn;TrackIds;Fehler;Warnungen;Merkmale
1;"ILS 2.0 Kreisel";"0010";"Kreisel :1";"B/3";1;"10000.0, 5000.0, 0.0";"1600.0, 1600.0, 0.0";"...";"";"";"";"";"0011, 0012, 0021";"0011, 0012, 0021, 0022, 0023, 0024";"";"";{"Abstand":"800"}
2;"ILS 2.0 Separator";"0011";"Separator :1";"B/3";1;"10800.0, 5000.0, 0.0";"210.0, 150.0, 14.0";"...";"";"";"";"";"0010, 0012";"";"";"";{"Zuordnung":"0010"}
3;"ILS 2.0 Separator";"0012";"Separator :2";"B/3";1;"10000.0, 5800.0, 0.0";"150.0, 210.0, 14.0";"...";"";"";"";"";"0011, 0021";"";"";"";{"Zuordnung":"0010"}
4;"ILS 2.0 VarioFoerderer";"0021";"VarioFoerderer :1";"B/3";1;"11900.0, 5000.0, 0.0";"2200.0, 300.0, 300.0";"...";"...";"...";"";"";"0010, 0024";"0021, 0022, 0023, 0024";"";"";{}
5;"ILS 2.0 Separator";"0022";"Separator :3";"C/4";1;"11600.0, 5000.0, 0.0";"210.0, 150.0, 14.0";"...";"";"";"";"";"";"";"";"";{"Zuordnung":"0021"}
6;"ILS 2.0 Separator";"0023";"Separator :4";"C/4";1;"12300.0, 5000.0, 0.0";"210.0, 150.0, 14.0";"...";"";"";"";"";"";"";"";"";{"Zuordnung":"0021"}
```

Zu beachten:

- Der Kreisel (`0010`) traegt in `TrackIds` den KOMPLETTEN Umlauf inkl. der
  VF-Kettenenden (`0021`=AS, `0024`=ES, aus `compute_kreisel_umlauf`), waehrend
  seine `Nachbarn`-Spalte nur die unmittelbaren Umlauf-Nachbarn zeigt.
- `VF_1` (`0021`) bekommt seine eigene `TrackIds`-Spalte
  (`write_separatorliste_merkmale`) aus der `sepliste`: AS -> SEP -> SEP -> ES
  in Baureihenfolge, unabhaengig vom Kreisel-Umlauf.
- Die AS/ES-Enden (`0021`=AS, `0024`=ES) sind hier synthetische Zeilen aus
  `build_strecke_schleus_items` (Zeilentyp "ILS Ausschleuselement"/
  "ILS Einschleuselement") — in diesem gekuerzten Beispiel nicht einzeln
  aufgefuehrt, aber ihre TeileIds tauchen in `TrackIds` beider Seiten auf.
- Die Separatoren 3 und 5 (`0012`/`0022`) unterscheiden sich nur durch ihre
  `Zuordnung`: `0012` haengt am Kreisel, `0022`/`0023` an der VF-Kette — beide
  Faelle laufen ueber denselben `pattern_separator`-Blocktyp.

### 1. Blöcke klassifizieren

Eine grosse Schleife über alle rohen JSON-Blöcke ordnet jeden Block anhand
der `cfg/export.cfg [blockpattern]`-Muster einer TeileArt zu (Kreisel,
Eckrad, Omniflo Bogen/Weiche/Gerade, VF-Strecke, Gefaellestrecke,
Strecke-Modul, Separator, Scanner, BTMT Be-/Entladung, Eingang/Ausgang) und
baut daraus ein
Item-dict mit `teileart`, `teileid`, `bezeichnung`, `planquadrat`,
`merkmale` und den bbox-/KOS-Spalten (`bbox_columns`). VF_n/GF_n-Items
bekommen dabei zusaetzlich `x`/`y` (Kettenanfang, fuer die Schleuselement-
Berechnung) und `sepliste` (fuer die Ketten-Nachbarschaft) durchgereicht.

Die `bezeichnung`-Spalte von VF_n/GF_n/Kreisel/Eckrad kommt ueber
`bezeichnung_oder_fallback` NICHT nur aus der Lauf-Nummerierung
("VarioFoerderer :3", "Kreisel :2" usw.), sondern zuerst aus dem
Attribut `"Bezeichnung"` des Blocks (ATTDEF, in BricsCAD frei editierbar -
bei Kreisel z.B. ueber das "name"-Dialogfeld). Ist es leer oder fehlt es
(Altbestand ohne das Attribut), bleibt es bei der generierten
Standardbezeichnung. Damit laesst sich ein in BricsCAD umbenanntes Element
im CSV-Export wiedererkennen.

Separator/Scanner-Items ohne Bounding-Box (weil `vla-getboundingbox`
scheiterte) bekommen einen Fallback: `_fallback_separator_bbox` baut aus der
festen Symbol-Groesse (`cfg/export.cfg [Boundingbox] separator_box_*`,
Default 210x150x14mm) und der bekannten Position/Rotation eine synthetische
`_bbox`, damit der Separator trotzdem an der Nachbarschaftserkennung
teilnimmt.

#### Eingang/Ausgang — nur im CSV-Export

Die Materialfluss-Ein-/Ausgangssymbole (Bloecke `Eingang_<DIM>`/`Ausgang_<DIM>`,
eingefuegt ueber `ils-insert-station`, Befehle `ILS_EINGANG_INSERT`/
`ILS_AUSGANG_INSERT`) werden **nur im CSV-Export** als eigene Zeile gefuehrt
(TeileArt `"Eingang"`/`"Ausgang"`, Merkmale wie BTMT: ARTINR/Hoehe/Drehung).
`export_sivas.py` ueberspringt sie bewusst — ein Fluss-Symbol hat keinen
eigenen Sivas-Artikel.

Wie Separator/AS/ES nehmen sie als **freie Umlauf-Punkte**
(`KREISEL_UMLAUF_TEILEARTEN`) an der `"TrackIds"`-Spalte teil und tauchen so
auch auf einem Kreisel auf, auf dessen Bahn sie liegen. Voraussetzung fuer
eine ueber Exportlaeufe stabile TeileId ist ein `ID`-ATTDEF in den DWGs
(nachgetragen, dokumentiert in `data/ils/allocations.json`); `ssg-id-check-all`
fuellt es vor jedem Export, und `ssg-id-collect-blocks` (`Lisp/ssg_id.lsp`)
erfasst die Bloecke dafuer. Fehlt die ID (noch), greift wie bei BTMT eine
lauf-lokale Fallback-Nummer (`EIN-`/`AUS-`-Praefix).

### 2. `compute_neighbor_ids` — die generische Bounding-Box-Nachbarschaft

Datei `lib/export_neighbors.py`. Testet drei Gruppen gegeneinander (NICHT
alle Elemente gemeinsam — das waere bei grossen Omniflo-Anlagen zu teuer bzw.
fachlich falsch):

1. Kreisel/Eckrad gegen Kreisel/Eckrad. Ein echter Kreisel wird dafuer in
   eine linke und rechte Haelfte gesplittet (`kreisel_half_bboxes`) — die
   Trennlinie ist die Achse durch Antriebs- und Spannstation.
2. Kreisel/Eckrad gegen Gefaellestrecke/Foerderer/Strecke-Modul. Fuer
   GF/VF wird dabei NICHT die grosse Wrapper-Box getestet, sondern je eine
   kleine feste Box an der AS- (K1) und ES-Position (K2) — nur dort beruehrt
   eine Strecke tatsaechlich einen Kreisel.
3. Omniflo-Elemente gegen Omniflo-Elemente (Bogen/Weiche/Gerade), per
   STRtree-Broad-Phase + KOS-Verfeinerung ueber K1-K4.

Ergebnis ist die rohe `Nachbarn`-Spalte fuer Kreisel/Eckrad/GF/VF (fuer
Separator/Scanner bewusst NICHT — die werden unten anders behandelt) sowie
die `Fehler`-Spalte (`compute_neighbor_errors`: "unverbunden"/"nur ein
Partner", je nach Mindestanzahl Partner pro TeileArt).

### 3. Synthetische Zeilen an den Uebergangsstellen

Drei Arten von "Zeilen ohne eigene Zeichnungsgeometrie" werden aus der
Geometrie der bereits klassifizierten Items abgeleitet:

- **`compute_kreisel_touch_switches`** — praezise Kapsel-Geometrie (nicht nur
  Bounding-Box) findet jeden Punkt, an dem sich zwei echte Kreisel wirklich
  beruehren, und erzeugt dort eine `"ILS Weiche"`-Zeile
  (`build_kreisel_weiche_items`). Das ist der Verzweigungspunkt, an dem
  Material von einem Kreisel zum anderen wechseln kann.
- **`compute_strecke_kreisel_schleus`** — an jedem Streckenende (AS/ES,
  ueber K1/K2 bzw. als Fallback die Wrapper-Enden), das einen Kreisel
  beruehrt (siehe Schritt 2), entsteht ein `"ILS Ausschleuselement"`
  (Anfang) bzw. `"ILS Einschleuselement"` (Ende), leicht zum Kreisel hin
  versetzt (`build_strecke_schleus_items`).
- **`map_separator_kette_items`** — ordnet jedem `"SEP"`-Eintrag einer
  sepliste das dazu passende, bereits vorhandene Separator-Item zu (siehe
  naechster Abschnitt). Erzeugt bewusst KEINE eigenen Zeilen.

### 4. Der Kreisel-Umlauf — wie Nachbarn ueber einen Kreisel hinweg entstehen

`compute_kreisel_umlauf` ist der zentrale Baustein, der Ketten-Enden,
freie Punkte (Separatoren UND BTMT Beladung/Entladung) und Kreisel-Kreisel-
Weichen zu einer widerspruchsfreien Nachbarschaft zusammenfuehrt. Fuer jeden
echten Kreisel werden alle Punkte gesammelt, die dort geometrisch liegen:

- freie Punkte (`KREISEL_UMLAUF_TEILEARTEN` in `lib/export_neighbors.py`:
  Separator, BTMT Beladung, BTMT Entladung, Eingang, Ausgang — alles
  Stationen/Markierungen direkt auf der Bahn/dem Track), deren Bounding-Box
  die Kreisel-Box ueberschneidet,
- die Kreisel-Kreisel-Weichen aus Schritt 3 (in BEIDEN beteiligten
  Kreisel-Umlaeufen, da eine Weiche der gemeinsame Verzweigungspunkt ist —
  man kann von Kreisel A nach B und zurueck),
- die AS/ES-Enden andockender VF_n/GF_n-Ketten (aus der `sepliste`,
  zugeordnet zum geometrisch naechstgelegenen Kreisel).

Alle Punkte werden nach Winkel um die Kreiselachse sortiert (Richtung ueber
das `DREHRICHTUNG`-Attribut, UZS/GUZ) — das ergibt eine geschlossene,
zirkulaere Reihenfolge. Vorgaenger/Nachfolger in dieser Reihenfolge werden
zu `Nachbarn`.

Die Matching-Box eines Kreisels ist dabei die tatsaechliche, um die Drehung
korrigierte Kapsel-Bounding-Box (nicht "Laenge entlang Welt-X" angenommen) —
ein 90 Grad gedrehter, langer Kreisel haette sonst eine falsch orientierte
(zu breite/zu schmale) Box und faengt Punkte faelschlich ein oder verpasst
echte Nachbarn.

### 5. Ketteninterne Nachbarn — `compute_sep_kette` + Aufloesung

`compute_sep_kette` liest jede `sepliste` und baut daraus einen Schluessel
je Eintrag (`"<strecke_id>#<lfdnr>"`) mit `vorgaenger`/`nachfolger`
(wieder solche Schluessel, `None` am Kettenende). Das ist eine reine
Uebersetzung der LISP-Baureihenfolge — kein Rateverfahren.

**Warum die Zeilen erst NACH allen Schluesseln aufgeloest werden:** ein
Schluessel kann auf eine Zeile zeigen, die zum Zeitpunkt seiner Vergabe noch
gar nicht existiert (eine SEP in der Mitte einer Kette hat ihre AS als
Vorgaenger, aber die AS-Zeile entsteht erst in `build_strecke_schleus_items`,
das VOR der SEP-Zuordnung laeuft). Darum sammeln
`build_strecke_schleus_items` und `map_separator_kette_items` ihre Treffer
zunaechst nur in einem gemeinsamen `sep_kette_by_key`-dict
(Schluessel -> Item), OHNE die `Nachbarn`-Spalte zu setzen.
`resolve_umlauf_und_sepliste_nachbarn` loest danach in einem einzigen Schritt
sowohl die Kreisel-Umlauf-Punkte als auch die sepliste-Schluessel gegen einen
gemeinsamen Lookup (freie Separatoren nach TeileId, Weichen nach Schluessel,
sepliste-Zeilen nach Schluessel) zu echten TeileIds auf.

**`map_separator_kette_items` erzeugt keine neuen Zeilen** (Architektur-
entscheidung, siehe Docstring in `lib/export_csv.py`): der verpackte
Separator liegt durch `csv:sep-proxies-erzeugen` (Phase 1, Schritt 1) bereits
als echtes Separator-Item vor. Eine zweite, aus der sepliste erzeugte Zeile
waere derselbe physische Separator ein zweites Mal. Die Zuordnung
sepliste-Eintrag -> vorhandenes Item laeuft ueber die Wrapper-ID (Item-
Merkmal `"Zuordnung"`, von `csv:sep-proxies-zuordnung-setzen` fest gesetzt)
plus den naechstgelegenen rohen INSERT-Punkt (Item-Felder `_x`/`_y` vs. die
sepliste-Koordinate) — beide stammen aus derselben Bauphase und liegen daher
nah beieinander, auch wenn sie nicht exakt uebereinstimmen.

### Die Spalte `"TrackIds"` — Reihenfolge als eigene CSV-Spalte

Zusaetzlich zur `"Nachbarn"`-Spalte (Vorgaenger/Nachfolger je Zeile) traegt
`write_separatorliste_merkmale` (`lib/export_csv.py`) jeder VF_n/GF_n-Zeile
die eigene Spalte `"TrackIds"` (`item["trackids"]`, Top-Level-Feld wie
`"nachbarn"` — KEIN Merkmal) ein: die TeileIds von AS-Ende, Separatoren UND
ES-Ende in Baureihenfolge, kommagetrennt (z.B. `"0051, 0052, 0053, 0054,
0055"` fuer AS, zwei SEP, ES). AS/ES zaehlen mit, weil sie beim Kreisel
(siehe unten) ebenfalls Teil von dessen `TrackIds` sind — ohne sie fehlten
hier die Kettenenden. Quelle ist die rohe `sepliste` des Items (nicht
`sep_kette`, dessen dict-Reihenfolge nicht garantiert ist). Muss NACH
`map_separator_kette_items`/`build_strecke_schleus_items` laufen, weil erst
dann jeder sepliste-Schluessel (AS/SEP/ES) auf sein reales Item (TeileId)
aufgeloest ist. Beruehrt ein Streckenende geometrisch KEINEN Kreisel,
entsteht dort keine AS/ES-Zeile (`build_strecke_schleus_items`) und damit
auch keine TeileId — dieses Ende fehlt dann in `TrackIds` (kein Fehler,
sondern Folge der fehlenden Kollision).

`write_kreisel_separatorliste_merkmale` ueberträgt dasselbe Prinzip auf
echte Kreisel (`"ILS 2.0 Kreisel"`): Quelle ist hier NICHT die sepliste
(die kennt nur eine einzelne VF_n/GF_n-Kette), sondern
`compute_kreisel_umlauf` (`lib/export_neighbors.py`) — der bereits fuer die
Kreisel-`"Nachbarn"`-Spalte berechnete, zirkulaere Umlauf aller auf dem
Kreisel liegenden Punkte (freie Punkte — Separator UND BTMT Beladung/
Entladung, siehe `KREISEL_UMLAUF_TEILEARTEN` —, AS/ES-Enden andockender
VF_n/GF_n-Ketten, Kreisel-Kreisel-Weichen), sortiert nach Winkel um die
Kreiselachse in Richtung des `DREHRICHTUNG`-Attributs (UZS/GUZ). Die
zurueckgegebene Liste beginnt IMMER bei Winkel 0 Grad (Kapsel-Achsrichtung,
kleinster Winkel >= 0 Grad in Umlaufrichtung) — `write_kreisel_
separatorliste_merkmale` loest die rohen Umlauf-Schluessel (TeileId eines
freien Punkts, sep_kette-Schluessel oder Weichen-Key) auf echte TeileIds auf
und schreibt sie kommagetrennt in `item["trackids"]` auf den Kreisel selbst.
Muss darum NACH `resolve_umlauf_und_sepliste_nachbarn` (bzw. nach allen
Zeilen-Registrierungen: `build_kreisel_weiche_items`, `build_strecke_
schleus_items`, `map_separator_kette_items`) laufen.

BTMT Beladung/Entladung sind bewusst NICHT in `SENSOR_TEILEARTEN`
aufgenommen (die bleibt Separator/Scanner vorbehalten, siehe
`compute_sensor_zuordnung`/`compute_scanner_nearest_separator` in Abschnitt
6) — eine eigene Konstante `KREISEL_UMLAUF_TEILEARTEN` sammelt stattdessen
genau die TeileArten, die als frei platzierter Punkt auf einer Kreisel-Bahn
liegen koennen.

### 6. Sensor-Zuordnung, Ausgabe

`compute_sensor_zuordnung` bestimmt fuer jeden Separator/Scanner ohne
bekannte (fixierte) Zuordnung das Traegerelement (Gefaellestrecke > Foerderer
> Kreiselhaelfte, per Bounding-Box). `compute_scanner_nearest_separator`
haengt jedem Scanner den raeumlich naechsten Separator an. Am Ende werden
alle Items nach TeileId sortiert und als CSV-Zeilen ausgegeben
(`format_csv_line`).

## Warum eine Zeile keine Nachbarn hat — Diagnose-Leitfaden

| Symptom | Wahrscheinlichste Ursache |
|---|---|
| ALLE Zeilen ohne Nachbarn, auch Kreisel | `bbox`-Feld fehlt im JSON komplett (`vla-getboundingbox` scheiterte global) — pruefen, ob `csv:run-export` eine `exp-bbox-fail`-Warnung ausgegeben hat |
| Nur GF/VF ohne Nachbarn, Separatoren teils auch | `sepliste` wurde nicht ans Item durchgereicht, oder die Strecke beruehrt geometrisch keinen Kreisel (`Fehler = "unverbunden"`) |
| Ein Separator/Scanner ohne Nachbarn, Rest ok | Separator ist weder Teil einer sepliste-Kette noch nah genug an einem Kreisel (freier, isoliert platzierter Sensor) — legitimer Fall, keine Fehlkonfiguration |
| Zwei sich beruehrende Kreisel haben falsche/keine Nachbarn am Beruehrpunkt | Pruefen, ob `compute_kreisel_touch_switches` ueberhaupt eine Weiche erzeugt (Toleranz `[Nachbarschaft] toleranz_mm`) und ob sie im Kreisel-Umlauf beider Kreisel auftaucht |
| `Nachbarn` enthaelt einen Wert wie `"0026#3"` statt einer TeileId | Regression im Aufloese-Schritt — ein sep_kette-Schluessel wurde nicht durch `resolve_umlauf_und_sepliste_nachbarn` ersetzt (sollte nicht mehr vorkommen, siehe Tests `test_export_kreisel_umlauf.py`) |

Das Kollisions-/Nachbarschafts-Debugprotokoll (`cfg/export.cfg`
`[Nachbarschaft] debug_log=1`) schreibt eine `.dbg`-Datei mit jeder
Klassifikation, Gruppenzuordnung und jedem Ueberschneidungstest — der
schnellste Weg, einer fehlenden Nachbarschaft auf den Grund zu gehen.

## Relevante Tests

- `tests/test_export_kreisel_umlauf.py` — Kreisel-Kreisel-Weiche im Umlauf,
  rotationsunabhaengige Kreisel-Matching-Box, sepliste-Nachbarn-Aufloesung
  ohne rohe Schluessel in der Ausgabe, Kreisel-Umlauf-Start bei 0 Grad,
  BTMT Beladung/Entladung als freie Umlauf-Punkte, `"TrackIds"`-Spalte.
- `tests/test_export_separator_bbox.py` — feste Separator-Symbol-Box
  (Geometrie + Fallback bei fehlender `vla-getboundingbox`-Box).
- `tests/test_export_bezeichnung.py` — `"Bezeichnung"`-Spalte von
  VF_n/GF_n/Kreisel/Eckrad nutzt das Anwender-Attribut, sofern gesetzt.

Alle laufen komplett ohne BricsCAD (reine Python-Geometrie/-Logik).