[ADD] doc/json-input-lisp.md: JSON-Eingabeformate je Element (Kreisel, Einzelbloecke, VF Standard/Etage, GF Modus 1-3, VF-Linienzug Spec/Journal, Omniflo, gerade) aus tests/testdata mit Feldern, Koordinaten-Bezug und Bau-Routine - ersetzt das geloeschte tests/testdata/object_data.md; [ADD] doc/lisp_methods.md: Uebersicht der LISP-Bau-Routinen je Einheit (Befehl + skriptfaehiger Kern, Signaturen, Rueckgaben, Voraussetzungen, Einfuegeprimitiven)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 17:05:13 +02:00
parent 1250864849
commit 36b6fdb650
2 changed files with 765 additions and 0 deletions
@@ -0,0 +1,437 @@
+# JSON-Eingabe fuer den LISP-Bau
+
+Welche Objekte sich aus einer JSON-Datei an einer gegebenen x/y/z-Koordinate
+erzeugen lassen, in welchem Format sie beschrieben werden und welche
+LISP-Routine sie baut. Grundlage sind die Testdaten in `tests/testdata/*.json`
+und die Treiber in `tests/test_*.lsp`, die sie lesen.
+
+Die zugehoerigen LISP-Routinen mit Signaturen stehen in
+[lisp_methods.md](lisp_methods.md). Diese Seite ersetzt das fruehere
+`tests/testdata/object_data.md` (geloescht in Commit `e147b89`, auf das Code-
+Kommentare teilweise noch verweisen).
+
+---
+
+## 0. Uebersicht
+
+| Objekt | Erkennungsmerkmal im JSON | Bau-Routine (Produktion) | Koordinaten-Eingang | Beispiel-Datei |
+|---|---|---|---|---|
+| [Kreisel (Insert)](#1-kreisel) | `"function": "insert"`, KEIN `block` | `kreisel-insert-script` | `x`,`y`,`z` = Einfuegepunkt | `kreisel_tests.json`, `mubea.json`, `hundm05.json`, `dematic_arvato.json` |
+| [Kreisel (Connect)](#12-connect-start--und-endpunkt) | `"function": "connect"` | `kreisel-connect-script` | `start_*`, `end_*` | (nur `test_kreisel.lsp`, z.Z. kein Datensatz) |
+| [Einzelblock](#2-einzelbloecke-separator-scanner-btmt-eingangausgang-vario-bausteine) (Separator, Scanner, BTMT, Eingang/Ausgang, Vario-Bausteine) | `"function": "insert"` + `"block"` | direktes `_.INSERT` nach `ssg-ils-block-laden` | `x`,`y`,`z` + `rotation` | `mubea.json`, `hundm05.json`, `dematic_arvato.json` |
+| [VarioFoerderer Standard](#3-variofoerderer-standard-und-etage) | `test_id` beginnt mit `VF_`, `typ` fehlt oder `"standard"` | `berechne-alle-winkel` + `variofoerderer-einfuegen` + `vf-block-erstellen` | `x`,`y`,`z` = KS_EIN des AS-Elements | `mubea.json`, `foerderer_tests.json` |
+| [VarioFoerderer Etage](#3-variofoerderer-standard-und-etage) | `test_id` `VF_*` + `"typ": "etage"` | `berechne-etage` + `etage-foerderanlage-einfuegen` + `vf-block-erstellen` | wie Standard | `mubea.json` |
+| [Gefaellestrecke Modus 1](#4-gefaellestrecke) | `test_id` `GF_*` bzw. `"modus": 1` | `gefaellestrecke-einfuegen` (bzw. `gf-rebuild`) | `start_mm` = KS_EIN des AS-Elements | `mubea.json`, `gefaellestrecke_tests.json` |
+| [Gefaellestrecke Modus 2](#42-modus-2---richtung-aus-zwei-punkten) | `"modus": 2` | wie Modus 1, `deltaL`/`hz` aus zwei Punkten | `start_mm` + `linie_start_mm`/`linie_ende_mm` | `gefaellestrecke_tests.json` |
+| [Gefaellestrecke Modus 3](#43-modus-3---linienzug) | `"modus": 3` | nur ueber `test_gefaellestrecke.lsp` | `start_mm`, `ende_mm`, `bogen` | `gefaellestrecke_tests.json` |
+| [VF-Linienzug-Kette (Spec)](#5-vf-linienzug-kette-spec) | Kopf mit `spec_id`, danach `glied`/`sub` | `vsp-bau-aus-spec` (Replay durch `vf-linienzug-modus`) | `start_punkt` = Kettenanfang | `hundm05.json` |
+| [VF-Linienzug (Journal)](#6-vf-linienzug-eingabe-journal) | Kopf mit `test_id`, danach `typ` = `point_abs`/`real`/`string`/... | `vfl-journal-replay-start` + `vf-linienzug-modus` | erstes `point_abs` | `linienzug_tests.json`, `hm_recformat.json` |
+| [Omniflo Bogen/Weiche](#71-bogen-und-weiche) | `"type": "bogen"` / `"weiche"` + `sivasnr` | `_.INSERT` der `<sivasnr>.dxf` (Kern `omni:insert-dxf` fragt den Punkt interaktiv) | `x`,`y`, Z = `hoehe` | `omniflo_tests.json`, `omniflo_strecke_tests.json` |
+| [Omniflo Gerade](#72-aluprofil-gerade) | `"type": "gerade"` + `profil` | `omni:make-gerade` | `x`,`y` -> `x_ende`,`y_ende`, Z = `hoehe` | `omniflo_strecke_tests.json` |
+| [Waagrechte Foerderstrecke](#8-waagrechte-foerderstrecke-gerade---noch-ohne-bau-pfad) | `"typ": "gerade"` + `startpunkt` | **kein Bau-Pfad** (wird gemeldet und uebersprungen) | `startpunkt`, `endpunkt` | `dematic_arvato.json` |
+
+Nicht aus JSON baubar (es gibt keine Testdaten und keinen Treiber): Eckrad,
+Geruest, TEF-Foerderer-Linie, TRO-Marker, Connections, Omniflo-Ladeschleife.
+Fuer Eckrad und Geruest existiert ein skriptfaehiger Kern, siehe
+[lisp_methods.md](lisp_methods.md).
+
+### Allgemeine Regeln
+
+- **Einheiten**: Laengen und Koordinaten in **mm**, Winkel in **Grad**.
+  Fahrtrichtung `hz`: 0 = +X (Ost), 90 = +Y (Nord), 180 = -X, 270 = -Y.
+- **Z ist absolut**: `z` (bzw. Z in `start_mm`/`start_punkt`) ist die
+  Weltkoordinate des Einfuegepunkts, also die Einbauhoehe.
+- **Dimension 2D/3D**: Gebaut wird in der aktuellen Dimension
+  (`ssg-ils-dim-aktuell`: `*ssg-ils-dim*` -> `DXFM_DIM`, Default 3D).
+  Das Feld `darstellung` in `dematic_arvato.json` ist reine Dokumentation und
+  wird nicht ausgewertet; `TEST_HUNDM05_2D`/`_3D` erzwingen die Dimension.
+- **Flaches JSON**: Die meisten Dateien werden mit `ssg-load-json` gelesen
+  (zeilenweise, ein Objekt je `{`). Verschachtelte Objekte und mehrzeilige
+  Arrays darin funktionieren nicht - darum stehen z.B. die Glieder einer
+  Kette als eigene Objekte hinter ihrem Kopf-Objekt. Ausnahme:
+  `TEST_DEMATIC_ARVATO` liest mit dem rekursiven `ssg-json-laden`.
+- **Reine Doku-Felder**: `comment`, `beschreibung`, `description`, `quelle`,
+  `row`, `seq`, `gruppe`, `assigned_to`, `hoehe_unbekannt`, `darstellung`
+  sowie alle `expect_*`/`erwartung_*`-Felder werden beim Bau nicht gelesen.
+  `expect_*` pruefen die Python-Tests gegen das Ergebnis.
+- **Template-Felder** (nur `test_mubea.lsp`): `anzahl`, `delta_x`, `delta_y`
+  erzeugen aus einem Eintrag `anzahl` Kopien, jeweils um `delta_x`/`delta_y`
+  versetzt; `test_id` bekommt dann das Suffix `_01` ... `_nn`. Gilt fuer VF,
+  GF und Einzelbloecke.
+
+---
+
+## 1. Kreisel
+
+Block `KREISEL_n`, gebaut von `KreiselInsert.lsp`.
+
+### 1.1 Insert (freier Punkt)
+
+```json
+{ "id": "KR_Kreuz_Q1_0Grad", "function": "insert",
+  "x": 500, "y": 500, "z": 2500,
+  "abstand": 2000, "rotation": 0.0, "typ": "STANDARD" }
+```
+
+| Feld | Pflicht | Bedeutung | Default |
+|---|---|---|---|
+| `id` | ja (fuer den Treiber) | Kennung im Ergebnis; NICHT die Block-ID (die vergibt `ssg-id-generate`) | - |
+| `function` | ja | `"insert"`; ohne `block` = Kreisel | - |
+| `x`, `y` | ja | Einfuegepunkt. Liegt auf der Kreiselachse **einen Radius (400 mm) vor der Mitte des Antriebsrads (AN)**, also am aeussersten Punkt der AN-Seite | - |
+| `z` | ja | Einbauhoehe; wird als `hoehe` uebergeben und in das Attribut `HOEHE` geschrieben | `kreisel.default_hoehe` (2000) |
+| `abstand` | ja | Mittenabstand Antriebsrad - Spannrad | `kreisel.default_laenge` (2300) |
+| `rotation` | nein | Drehung der Achse AN -> SP, frei (kein Raster) | 0.0 |
+| `typ` | nein | `"STANDARD"` oder `"PIN"` -> Attribut `KREISELART` | `"STANDARD"` |
+
+Treiber: `kreisel:run-insert-test` (`test_kreisel.lsp`), `mubea:build-kreisel`,
+`hundm05:bau-kreisel` (auch fuer `dematic_arvato.json`).
+
+### 1.2 Connect (Start- und Endpunkt)
+
+```json
+{ "id": "K2", "function": "connect",
+  "start_x": 0, "start_y": 0, "start_z": 2000,
+  "end_x": 5000, "end_y": 0, "end_z": 2000, "typ": "STANDARD" }
+```
+
+`start_*` und `end_*` sind die aeussersten Punkte der AN- bzw. SP-Seite.
+`abstand` (= Distanz - Kreiseldurchmesser 800) und `rotation` werden daraus
+berechnet. Die Einbauhoehe kommt aus `start_z`. Nur `test_kreisel.lsp` kennt
+`connect`; die anderen Treiber bauen ausschliesslich `insert`.
+
+---
+
+## 2. Einzelbloecke (Separator, Scanner, BTMT, Eingang/Ausgang, Vario-Bausteine)
+
+Jeder Eintrag mit `"function": "insert"` UND `"block"` wird als einzelner
+Block eingefuegt, ohne Wrapper-Block und ohne Verkettung.
+
+```json
+{ "id": "HundM05_SCANNER_02", "function": "insert", "block": "Scanner",
+  "x": 4095.5, "y": 1164.1, "z": 2154, "rotation": 270 }
+```
+
+| Feld | Pflicht | Bedeutung | Default |
+|---|---|---|---|
+| `block` | ja | Blockname OHNE `_2D`/`_3D`-Suffix | - |
+| `x`, `y`, `z` | ja | Einfuegepunkt = **Basispunkt der Block-DWG** (nicht KS_EIN) | - |
+| `rotation` | nein | Drehung um Z | 0 |
+| `id` / `test_id` | nein | Kennung im Ergebnis | `SEPARATOR_<n>` bzw. Blockname |
+
+Ablauf: `ssg-ils-block-laden` loest den Namen auf `data/ils/<block>_<DIM>.dwg`
+auf (3D-Fallback), danach `_.INSERT eff pt "" "" rotation` und
+`ssg-id-generate`. **Fehlt die DWG, wird `Separator_SP` eingefuegt.**
+Treiber: `mubea:build-separator`, `hundm05:bau-sensor` (auch Dematic).
+Das Layer-Attribut `LAYER` wird dabei nicht angewendet; der Block landet auf
+dem aktuellen Layer.
+
+### In den Testdaten verwendete Blocknamen
+
+| `block` | DWG in `data/ils` | Verwendet in | Hinweis |
+|---|---|---|---|
+| `Scanner` | `Scanner_2D/_3D.dwg` | mubea, hundm05, dematic_arvato | |
+| `Separator_SP` | `Separator_SP_2D/_3D.dwg` | (Fallback) | Block von `ILS_SEPARATOR_INSERT` |
+| `S-LP` | **fehlt** | mubea, hundm05, dematic_arvato | wird zu `Separator_SP` |
+| `S-SP` | **fehlt** | dematic_arvato | wird zu `Separator_SP` |
+| `BTMT-Beladung` | `BTMT-Beladung_2D/_3D.dwg` | mubea, hundm05 | wie `ILS_BTMT_Beladung` |
+| `SC_Entladung` | `SC_Entladung_2D/_3D.dwg` | mubea, hundm05 | wie `ILS_BTMT_Entladung` |
+| `Eingang` / `Ausgang` | `Eingang_*/Ausgang_*.dwg` | mubea | Symbole wie `ILS_EINGANG_INSERT`/`ILS_AUSGANG_INSERT` |
+| `AS_Element_90_links` / `_rechts` | vorhanden | dematic_arvato | loses AS-Element (sonst Teil eines VF/GF) |
+| `ES_Element_90_rechts`, `ES_Element_30_rechts` | vorhanden | dematic_arvato | loses ES-Element |
+| `Vario_Motorstation_500mm_rechts` | vorhanden | dematic_arvato | lose Motorstation |
+| `Vario_Umlenkstation_500mm_rechts` | vorhanden | dematic_arvato | lose Umlenkstation |
+| `Vario_Kurve_rechts_30_TEF_aussen` | vorhanden | dematic_arvato | lose Vario-Kurve |
+
+Grundsaetzlich ist **jeder** Blockname aus `data/ils` erlaubt (es gibt keine
+Whitelist). Die losen AS/ES-/Vario-Bausteine bilden aber keine Kette und keinen
+`VF_n`/`GF_n`-Block - fuer eine zusammenhaengende Strecke Abschnitt 3-5 nutzen.
+
+---
+
+## 3. VarioFoerderer Standard und Etage
+
+Block `VF_n`. Eingang sind die **Gesamtmasse** der Anlage; Winkel und
+Teillaengen berechnet der Solver.
+
+```json
+{ "test_id": "VF_Schnitt_C", "richtung": "Auf",
+  "deltaL": 9110, "deltaH": 474, "winkel": 21,
+  "gf_verteilung": "manuell", "L_GF1": 2298, "seite": "links",
+  "hz": 0.0, "x": 400, "y": 14120, "z": 1554 }
+```
+
+| Feld | Pflicht | Bedeutung | Default |
+|---|---|---|---|
+| `test_id` | ja | muss mit `VF_` beginnen (steuert den Dispatcher in `test_mubea.lsp`) | - |
+| `typ` | nein | `"standard"` (AS/ES 90 Grad) oder `"etage"` (AS/ES 30 Grad, uebereinander) | `"standard"` |
+| `richtung` | ja | `"Auf"` oder `"Ab"` | - |
+| `deltaL` | ja | horizontale Gesamtlaenge inkl. AS/ES, Boegen, GF-Vor-/Nachlauf | - |
+| `deltaH` | ja | Hoehendifferenz (Betrag; Vorzeichen kommt aus `richtung`) | - |
+| `winkel` | nein | Bogenwinkel erzwingen, nur aus der Kandidatenliste (`vario.bogen_winkel`: 3, 6, 9, 12, 15, 18, 21, 27, 33, 39, 45, 51). Ist er nicht loesbar, wird NICHT gebaut | kleinster gueltiger Winkel |
+| `L_GF1` | nein (mubea) | Vorlauf-Laenge (GF vor dem Foerderer); Nachlauf = Rest von `L_GF` | - |
+| `gf_verteilung` | nein (foerderer) | `"gleichmaessig"`, `"vorne"`, `"hinten"`; in `mubea.json` nur Doku (dort zaehlt `L_GF1`) | `"gleichmaessig"` |
+| `seite` | nein | `"links"`/`"rechts"` (Seite der AS/ES-Elemente) | `"links"` |
+| `hz` | nein | Fahrtrichtung | 0.0 |
+| `x`, `y`, `z` | ja (mubea) | Startpunkt = **KS_EIN des AS-Elements**; `z` = Einbauhoehe am Anfang | - |
+
+Hinweise:
+- `foerderer_tests.json` hat statt `x/y/z` einen Kopf-Eintrag
+  `{"y_abstand": 600}`: alle Foerderer starten bei x = 0, z = 0 und werden um
+  `y_abstand` versetzt. Dieses Format kennt nur `test_foerderer.lsp`.
+- `"Ab"` mit `deltaH` < 1 ist geometrisch unmoeglich und wird abgewiesen.
+- Der Treiber schreibt nach dem Bau `vf-edit-xdata-schreiben` (Typ + `hz`),
+  damit der Block per Doppelklick editierbar ist.
+
+---
+
+## 4. Gefaellestrecke
+
+Block `GF_n`: AS-Element -> Staustrecke (skaliert) -> Separator -> ES-Element.
+Eingang ist die **horizontale Laenge**, nicht die Hoehendifferenz - die ergibt
+sich aus Laenge und Neigung.
+
+### 4.1 Modus 1 - Werteingabe
+
+```json
+{ "test_id": "GF_Mubea", "modus": 1,
+  "deltaL_mm": 9110, "hz_grad": 180.0, "winkel_grad": 2.27,
+  "start_mm": [9510, 12300, 2028],
+  "as_seite": "links", "es_seite": "links",
+  "as_winkel": "90", "es_winkel": "90" }
+```
+
+| Feld | Pflicht | Bedeutung | Default |
+|---|---|---|---|
+| `test_id` | ja | in `mubea.json` muss sie mit `GF_` beginnen | - |
+| `modus` | nein | `1` | - |
+| `deltaL_mm` | ja | horizontale Gesamtlaenge AS + Staustrecke + Separator + ES | - |
+| `winkel_grad` | nein | Neigung der Staustrecke | 3.0 |
+| `hz_grad` | nein | Fahrtrichtung | 0.0 |
+| `start_mm` | ja | `[x, y, z]` = **KS_EIN des AS-Elements**; Z = Einbauhoehe oben | - |
+| `as_seite`, `es_seite` | nein | `"links"`/`"rechts"` | `"links"` |
+| `as_winkel`, `es_winkel` | nein | `"90"` oder `"30"` (als STRING) | `"90"` |
+
+Die Staustrecke ergibt sich aus
+`L_stau = (deltaL - aus-dx - ein-dx - 300 * cos(w)) / cos(w)`
+(300 = `gefaelle.separator_breite`). Eine Ziel-Hoehe gibt es nicht.
+
+In `gefaellestrecke_tests.json` stehen `deltaL_mm`, `winkel_grad` und
+`z_start_mm` in einem gemeinsamen Kopf-Eintrag ohne `test_id` und gelten fuer
+alle Faelle der Datei.
+
+### 4.2 Modus 2 - Richtung aus zwei Punkten
+
+Wie Modus 1, aber `deltaL` und `hz` werden aus `linie_start_mm` ->
+`linie_ende_mm` berechnet (nur X/Y). `start_mm` bleibt der Einfuegepunkt und
+ist unabhaengig von der Linie.
+
+```json
+{ "test_id": "M2_hz000", "modus": 2, "start_mm": [0, -35000, 5000],
+  "linie_start_mm": [0, -35000, 0], "linie_ende_mm": [10000, -35000, 0],
+  "as_seite": "links", "es_seite": "links", "as_winkel": "90", "es_winkel": "90" }
+```
+
+### 4.3 Modus 3 - Linienzug
+
+In der Produktion nicht skriptbar (`gf-linienzug-modus` waehlt vorgezeichnete
+LINE/ARC-Objekte per Maus). `test_gefaellestrecke.lsp` zeichnet die Leitlinie
+selbst und baut sie nicht-interaktiv nach. Zwei Formen:
+
+```json
+{ "test_id": "M3_Bogen", "modus": 3,
+  "start_mm": [30000, -50000, 2000], "ende_mm": [38500, -43500, 1800],
+  "bogen": {"winkel_grad": 90, "radius_mm": 500, "seite": "links"},
+  "as_seite": "links", "es_seite": "links", "as_winkel": "90", "es_winkel": "90" }
+{ "test_id": "M3_hz270", "modus": 3, "richtung": "Sued",
+  "start_mm": [0, -50000, 5000],
+  "deltaH_quelle": "M2_hz000", "deltaL_quelle": "M2_hz000", ... }
+```
+
+`deltaH_quelle`/`deltaL_quelle` uebernehmen die Masse eines frueher gebauten
+Falls. Dieses Format ist an den Treiber gebunden. Fuer neue Anlagen besser
+eine VF-Linienzug-Spec (Abschnitt 5) mit `Linie-GF`/`GF-Bogen` verwenden.
+
+---
+
+## 5. VF-Linienzug-Kette (Spec)
+
+Beliebige Ketten aus GF-Linien, GF-Boegen, Vario-Kurven und VF-Einheiten,
+**ohne Dialog** gebaut (`VF_SPEC_BAU`, `TEST_HUNDM05`). Eine Kette = ein
+Kopf-Objekt, danach ihre Glieder (`glied`) und deren Unterknoten (`sub`) in
+Baureihenfolge. Ergebnis ist ein `VF_n`-Block mit vollem `SSG_VF_EDIT`-Journal
+(per Doppelklick editierbar).
+
+```json
+{ "spec_id": "VF_spec_LZ_01", "modus": 1,
+  "start_punkt": [4912.2, 1230.9, 2154.0], "start_hoehe": 2154.0,
+  "as": 1, "as_winkel": "90", "as_seite": "links" }
+{ "glied": "Linie-GF", "nr": 1, "dl": 2249.3, "hz": 90.0,
+  "gefaelle": "winkel", "winkel": 3.0, "ende": "nein" }
+{ "glied": "Horizontal-VF", "nr": 2, "dl": 3256.9, "gf_verteilung": "einlauf",
+  "vf_sep_vor": 0, "vf_sep_nach": 0, "vf_ende": "nein", "vf_separator": 0 }
+{ "sub": "vario-kurve", "winkel": 90, "seite": "rechts", "variante": "innen" }
+{ "sub": "motorstation" }
+{ "glied": "ES", "winkel": "90", "seite": "links" }
+```
+
+**Kopf**
+
+| Feld | Bedeutung |
+|---|---|
+| `spec_id` | Kennung der Kette |
+| `modus` | `1` (nur Modus 1 hat einen Uebersetzer) |
+| `start_punkt` | `[x, y, z]` Kettenanfang (KS_EIN des AS-Elements bzw. erstes Glied) |
+| `start_hoehe` | Einbauhoehe am Start |
+| `as` | `1` = AS-Element setzen, `0` = nicht |
+| `as_winkel` / `as_seite` | `"90"`/`"30"` bzw. `"links"`/`"rechts"` |
+
+**Glieder** (`glied`)
+
+| `glied` | wichtigste Felder |
+|---|---|
+| `Linie-GF` | `dl`, `hz` (nur beim ersten Glied der Kette), `laenge_modus` (`endpunkt`/`hoehe`/`steigend`), `ende` (`ja-mit-es`/`ja-ohne-es`/`nein`), `sep_vor`, `sep_nach`, `gefaelle` (`hoehe`/`winkel`) + `hoehe` bzw. `winkel` |
+| `GF-Bogen` | `winkel` (30/60/90), `seite` |
+| `Vario-Kurve` | als eigenes Glied (Kettenanfang) vom Uebersetzer noch NICHT unterstuetzt -> Spec-Fehler; Vario-Kurven als `sub` einer VF-Einheit angeben |
+| `Horizontal-VF` | `dl`, `eingang_hoehe`, `gf_verteilung` (`haelfte`/`einlauf`), `vf_sep_vor`, `vf_sep_nach`, `vf_ende` (`ja-mit-es`/`nein`/`automatisch`/`zielpunkt-ohne-es`), `vf_separator` (nur bei `vf_ende` = `nein`) + `sub`-Knoten |
+| `Linie-VF` | `dl`, `hoehe`, optional `winkel_idx` + `sub`-Knoten |
+| `Linie` | `dl`, `hoehe`, `segment_typ` (`GF`/`VF`), optional `winkel_idx` |
+| `ES` | `winkel` (`"90"`/`"30"`), `seite` |
+
+**Unterknoten einer VF-Einheit** (`sub`): `horizontal` (`sep_vor`, `sep_nach`),
+`vario-kurve` (`winkel`, `seite`, `variante` `aussen`/`innen`), `auf-ab`
+(`richtung` `auf`/`ab`, `hoehe`), `motorstation`, `kettenende` (`es`,
+`es_winkel`, `es_seite`).
+
+Ja/Nein-Felder (`as`, `sep_vor`, `vf_sep_vor`, `es`, ...) als `1`/`0` oder
+`"ja"`/`"nein"`; mehrwertige Felder (`ende`, `vf_ende`) nur mit den genannten
+Woertern. Vollstaendige Regeln
+(Menue-Codes je Frame, `hz` nur einmal, Verhalten bei `winkel_idx`):
+[variofoerderer.md, Abschnitt 8b](variofoerderer.md#spec-pfad-kette-aus-eingabedaten-vf_spec_bau).
+Die Spec wird nicht von Hand geschrieben, sondern mit
+`python lib/vf_spec_export.py <protokoll.json> <spec.json>` aus einer
+aufgezeichneten Kette erzeugt. Fehlerhafte Specs werden komplett abgewiesen
+(`vsp-pruefen` sammelt alle Fehler, gebaut wird dann nichts).
+
+**Andere Objekte in derselben Datei**: Neben den Ketten darf `hundm05.json`
+Kreisel (Abschnitt 1) und Einzelbloecke (Abschnitt 2) enthalten. Erkennbar
+sind sie an `function`; `vsp-gruppieren` ueberspringt sie, und
+`hundm05:bau-zusatzobjekte` baut sie nach den Ketten. `vf_spec_export.py`
+haengt sie beim Neuerzeugen unveraendert ans Dateiende.
+
+---
+
+## 6. VF-Linienzug (Eingabe-Journal)
+
+Das Rohformat hinter der Spec: die Antworten auf die Fragen des interaktiven
+Linienzug-Ablaufs, in Reihenfolge. Nur fuer Regressionstests gedacht - fuer
+neue Anlagen die Spec (Abschnitt 5) verwenden.
+
+```json
+{ "test_id": "VF_hundm05_LZ_01", "anlagetyp": "linienzug", "modus": 1, ... }
+{ "typ": "point_abs", "wert": [4912.2, 1230.9, 2154.0], "kommentar": "Startpunkt" }
+{ "typ": "real",      "wert": 2154.0,                  "kommentar": "Hoehe (Z)" }
+{ "typ": "string",    "wert": "1",                     "kommentar": "AS-Element? Ja" }
+{ "typ": "step",      "wert": "Linie-GF",              "kommentar": "Glied-Marker" }
+{ "typ": "point_rel", "dL": 2249.3, "hz": 90.0,        "kommentar": "Endpunkt" }
+{ "typ": "int",       "wert": 90,                      "kommentar": "Vario-Kurve Winkel" }
+```
+
+`typ`: `point_abs` (absoluter Punkt), `point_rel` (Abstand `dL` + Richtung
+`hz`, `hz` nur beim ersten Segment), `real`, `int`, `string` (Menue-Code als
+String), `step` (Glied-Marker, beim Replay uebersprungen). Kopf-Feld heisst
+`anlagetyp`, nicht `typ`, damit Kopf und Eingabe unterscheidbar bleiben.
+
+| Datei | Treiber |
+|---|---|
+| `linienzug_tests.json`, `linienzug_tests_stufe2.json` | `TEST_LINIENZUG`, `TEST_LINIENZUG_STUFE2` |
+| `hm_recformat.json` (5 echte HundM-Ketten, erzeugt mit `lib/vf_journal_export.py`) | `TEST_HM_RECFORMAT` (in `alltests.json` abgeschaltet) |
+
+---
+
+## 7. Omniflo
+
+### 7.1 Bogen und Weiche
+
+```json
+{ "id": "821104025", "type": "bogen", "sivasnr": "821104025",
+  "x": 219.4, "y": 223.06, "hoehe": 2000, "drehung": 0.0 }
+```
+
+| Feld | Pflicht | Bedeutung | Default |
+|---|---|---|---|
+| `type` | ja | `"bogen"` oder `"weiche"` | - |
+| `sivasnr` | ja | Sivas-Nummer = Dateiname `%DXFM_OMNIFLO%/<sivasnr>.dxf` | - |
+| `x`, `y` | ja | Einfuegepunkt (`$INSBASE` der DXF, gesetzt mit `set_einfuegepkt.py`) | - |
+| `hoehe` | nein | Z des Einfuegepunkts UND Attribut `HOEHE` | 2000 |
+| `drehung` | nein | Drehung + Attribut `DREHUNG` | 0 |
+
+Es gibt kein `z`: die Hoehe ist zugleich die Z-Koordinate. Gueltige
+Sivas-Nummern: `data/json/omniflo_boegen.json`, `omniflo_weichen.json`.
+Treiber: `omni:test-insert` (`test_omniflo.lsp`), `omnistr:insert-bogen`
+(`test_omniflo_strecke.lsp`).
+
+### 7.2 Aluprofil-Gerade
+
+```json
+{ "seq": 1, "type": "gerade", "profil": "AP110", "laenge": 1000.0,
+  "x": 2000.0, "y": 0.0, "x_ende": 3000.0, "y_ende": 0.0,
+  "drehung": 0.0, "hoehe": 2000, "id": "0003" }
+```
+
+`profil` = `"AP60"`, `"AP110"` oder `"APG110"`. Die Gerade laeuft von
+(`x`,`y`) nach (`x_ende`,`y_ende`) auf Z = `hoehe`; Laenge und Drehung folgen
+aus den Punkten (`laenge` ist nur Doku). Gebaut mit `omni:make-gerade`.
+
+---
+
+## 8. Waagrechte Foerderstrecke (`gerade`) - noch ohne Bau-Pfad
+
+```json
+{ "test_id": "GERADE_Arvato_01", "typ": "gerade", "laenge": 8313.39, "hz": 90.0,
+  "startpunkt": [2334.97, 177818.67, 0.0], "endpunkt": [2334.96, 186132.06, 0.0] }
+```
+
+Ein Antriebs-/Umlenkstation-Paar ohne Hoehendifferenz, so von
+`lib/dxf_scan_components.py` ausgegeben (ein VarioFoerderer ist bei
+`deltaH` = 0 nicht loesbar). `TEST_DEMATIC_ARVATO` meldet diese Eintraege und
+ueberspringt sie. Passende Primitive waere `insert-hz-scaled-block-by-ks`
+(`vf_etage.lsp`) mit `Staustrecke_SP_1000_mm`, siehe
+[lisp_methods.md](lisp_methods.md).
+
+---
+
+## 9. Testdaten-Dateien im Ueberblick
+
+| Datei | Inhalt | Treiber / Befehl |
+|---|---|---|
+| `kreisel_tests.json` | 8 Kreisel (`insert`) | `TEST_KREISEL` |
+| `foerderer_tests.json` | Kopf `y_abstand` + 17 VF Standard | `TEST_FOERDERER` |
+| `gefaellestrecke_tests.json` | Kopf + GF Modus 1/2/3 | `TEST_GEFAELLESTRECKE` |
+| `omniflo_tests.json` | 27 Boegen, 80 Weichen | `TEST_OMNIFLO` |
+| `omniflo_strecke_tests.json` | Streckenzug aus Geraden und Boegen | `TEST_OMNIFLO_STRECKE` |
+| `linienzug_tests.json` / `_stufe2.json` | Eingabe-Journal je einer Kette | `TEST_LINIENZUG` / `TEST_LINIENZUG_STUFE2` |
+| `hm_recformat.json` | 5 HundM-Ketten als Journal | `TEST_HM_RECFORMAT` |
+| `hundm05.json` | 5 HundM-Ketten als Spec + Kreisel, Separatoren, Scanner, BTMT | `TEST_HUNDM05`, `VF_SPEC_BAU` |
+| `mubea.json` | Gesamtanlage: Kreisel, VF Standard/Etage, GF-Template (20 Stueck), Separatoren, Scanner, BTMT, Eingang/Ausgang | `TEST_MUBEA` |
+| `dematic_arvato.json` | Vorlage aus `dxf_scan_components.py`: Kreisel, Einzelbloecke, `gerade` (Hoehen fehlen) | `TEST_DEMATIC_ARVATO` (abgeschaltet) |
+| `hundm05_linienzug_polylines.json` | Polylinien aus `extract_polylines.py` | kein Treiber (Analyse-Daten) |
+| `vfl_journal_hm05_abbruch.json` | rohes Journal (`kind`/`value`) eines abgebrochenen Baus | kein Treiber |
+
+---
+
+## 10. Eigene Anlage beschreiben - Kurzanleitung
+
+1. Kreisel als `insert` (Abschnitt 1): `x/y` am aeussersten Punkt der AN-Seite,
+   `z` = Einbauhoehe.
+2. Einfache Steig-/Fall-Strecken mit fester Form als VF Standard/Etage
+   (Abschnitt 3) bzw. Gefaellestrecke Modus 1 (Abschnitt 4.1), Startpunkt
+   jeweils = KS_EIN des AS-Elements.
+3. Ketten mit Kurven, mehreren VF-Einheiten oder GF-Boegen als Spec
+   (Abschnitt 5) - am einfachsten eine Kette einmal interaktiv bauen, mit
+   `lib/vf_journal_export.py` + `lib/vf_spec_export.py` als Spec exportieren
+   und Startpunkt/Laengen anpassen.
+4. Separatoren, Scanner, BTMT-Stationen, Eingang/Ausgang als Einzelblock
+   (Abschnitt 2).
+5. Aus Kreisel, Einzelbloecken und Specs gemischt baut derzeit nur der
+   HundM05-Treiber (`TEST_HUNDM05`); fuer VF Standard/Etage + GF zusammen mit
+   Kreiseln den Mubea-Treiber (`TEST_MUBEA`) als Vorlage nehmen.