fc9155de58
Format-Hints, URL-Patterns und Aufwand-Schaetzung pro BL fuer kuenftige Phase-2-Implementierungen. Dokumentiert was pro Landtag zu tun ist: - NRW: produktiv (38 Tests, Fixture-Garantie 19/19) - BUND: XML-Endpoint fuer namentliche Abstimmungen empfohlen statt PDF - MV/TH: ParlDok-Plattform, Synergien - BB/BY/BE/BW/HB/HE/HH/LSA/NI/RP/SH/SL/SN: je 1-3 Tage Reverse-Engineering - BUND-XML, MV/TH-Synergie und HE-HTML als naechste empfohlene Picks Cron-Erweiterung pro neuem BL: ein PROTO_TARGETS-Eintrag in scripts/auto-ingest-protocols.sh, kein Cron-Edit noetig.
152 lines
4.8 KiB
Markdown
152 lines
4.8 KiB
Markdown
# Plenarprotokoll-Parser Roadmap pro Bundesland
|
|
|
|
Stand 2026-04-28. Architektur fertig (ADR 0009), NRW-Parser produktiv,
|
|
Cron-Infrastruktur (`scripts/auto-ingest-protocols.sh`) BL-erweiterbar.
|
|
Pro weiterem BL ist ein eigener Parser zu implementieren — das ist
|
|
deterministische Reverse-Engineering-Arbeit, keine LLM-Calls, keine Kosten.
|
|
|
|
## Pattern fuer neue BL
|
|
|
|
1. **Sample-PDF/HTML/XML besorgen** und Vote-Anchor-Phrasen identifizieren.
|
|
2. **`app/protokoll_parsers/<bl>.py`** anlegen mit `parse_protocol(path) -> list[dict]`
|
|
nach Vertrag aus ADR 0009.
|
|
3. **Eintrag in `PROTOKOLL_PARSERS`** (in `__init__.py`).
|
|
4. **Tests** in `tests/test_protokoll_parsers_<bl>.py`.
|
|
5. **`PROTO_TARGETS`** in `scripts/auto-ingest-protocols.sh` ergaenzen.
|
|
6. **Backfill** einmal manuell laufen lassen.
|
|
|
|
## Pro Bundesland: bekannter Stand
|
|
|
|
### NRW ✅ produktiv
|
|
|
|
- URL: `https://www.landtag.nrw.de/portal/WWW/dokumentenarchiv/Dokument/MMP{wp}-{n}.pdf`
|
|
- Format: PDF mit deterministischen Anchor-Phrasen ("Damit ist X angenommen/abgelehnt")
|
|
- Parser: `app/protokoll_parsers/nrw.py`
|
|
- Tests: 38 Tests, Fixture-Garantie 19/19 auf MMP18-119
|
|
|
|
### Bundestag (BUND) — anderer Vote-Sprache als NRW
|
|
|
|
- URL: `https://dserver.bundestag.de/btp/{wp}/{wp}{n:03}.pdf` (z.B. `20184` = WP20 Sitzung 184)
|
|
- Format: PDF, ~1 MB pro Sitzung, ~600k Zeichen Text.
|
|
- **Vote-Anchor-Phrasen unterscheiden sich von NRW:**
|
|
- Bundestag nutzt: „Wer dem Gesetzentwurf seine Zustimmung gibt, den
|
|
bitte ich, sich zu erheben", „Damit ist der Gesetzentwurf in zweiter
|
|
Beratung angenommen", „... mit den Stimmen der Koalition gegen die
|
|
Stimmen der Opposition abgelehnt"
|
|
- „angenommen" und „überwiesen" haeufig in „in zweiter Beratung
|
|
angenommen" oder „zur federführenden Beratung an den Ausschuss"
|
|
- Vote-Daten: bei „namentliche Abstimmung" als separate XML-Datei
|
|
unter `https://dserver.bundestag.de/.../btp{wp}-{n}-namentlich.xml`
|
|
(alternative datenquelle, strukturiert!)
|
|
- **Empfehlung:** Statt PDF-Parsen den XML-Endpoint fuer namentliche
|
|
Abstimmungen nutzen — dort liegt fraktions-aggregiertes Vote bereits
|
|
als Struktur vor.
|
|
- Aufwand: ~1-2 Tage
|
|
|
|
### MV — ParlDok 8.x SPA
|
|
|
|
- URL-Pattern: `https://www.dokumentation.landtag-mv.de/parldok/dokument/{id}/{slug}.pdf`
|
|
- Format: PDF, aber `{id}` ist nicht-vorhersagbar — braucht Listen-API
|
|
von ParlDok-Suche
|
|
- Workaround: Suche via Plenarprotokoll-Filter, Liste der IDs holen
|
|
- Aufwand: ~2 Tage (URL-Discovery + Parser-Bau)
|
|
|
|
### Bayern (BY) — Pfad-Pattern noch zu verifizieren
|
|
|
|
- Format: PDF
|
|
- URL aus dokukratie-yml ziehen (nicht direkt dokumentiert)
|
|
- Aufwand: ~2 Tage
|
|
|
|
### Brandenburg (BB)
|
|
|
|
- URL-Pattern: `https://www.landtag.brandenburg.de/...` mit eigenem Schema
|
|
- Format: PDF mit Vote-Tabellen
|
|
- Aufwand: ~2-3 Tage (Tabellen-Parsing aufwendiger als reine Text-Anchors)
|
|
|
|
### Berlin (BE)
|
|
|
|
- Pardok-Plattform (analog LSA, BE)
|
|
- URL via Search-API
|
|
- Aufwand: ~2 Tage
|
|
|
|
### Bremen (HB), Hamburg (HH), Saarland (SL)
|
|
|
|
- Stadtstaaten, kleinere Landtage
|
|
- Format-Recherche pro Stadt; oft PDFs mit weniger formalen Anchors
|
|
- Aufwand: je ~1-2 Tage
|
|
|
|
### Hessen (HE)
|
|
|
|
- Webseiten-Plenarprotokolle z.T. als HTML strukturiert (semantische
|
|
Tags pro Beschluss)
|
|
- Wenn HTML zugaenglich: einfacher als PDF
|
|
- Sample-URL muss recherchiert werden
|
|
- Aufwand: ~1-2 Tage
|
|
|
|
### Niedersachsen (NI)
|
|
|
|
- nilas-Portal Login-protected (siehe `feedback_silent_excepts.md`)
|
|
- Plenarprotokolle ggf. auf eigener Seite ohne Login
|
|
- Aufwand: ~2-3 Tage (Login-Workaround pruefen)
|
|
|
|
### Rheinland-Pfalz (RP)
|
|
|
|
- OPAL_extern, abweichend zu NRW-OPAL
|
|
- PDF-URLs dokumentiert in dokukratie-yml
|
|
- Aufwand: ~2 Tage
|
|
|
|
### Sachsen (SN)
|
|
|
|
- ASP.NET-Webforms — Postback-Handling fuer Suche noetig
|
|
- Plenarprotokoll-Liste via XML-Export
|
|
- Synergie mit bestehendem `app/sn_xml_export`-Workflow moeglich
|
|
- Aufwand: ~1-2 Tage
|
|
|
|
### Sachsen-Anhalt (LSA)
|
|
|
|
- Padoka-Plattform (analog BE)
|
|
- URL via Search-API
|
|
- Aufwand: ~2 Tage
|
|
|
|
### Schleswig-Holstein (SH)
|
|
|
|
- Starfinder-CGI-Backend
|
|
- Format: PDF
|
|
- Aufwand: ~2 Tage
|
|
|
|
### Thüringen (TH)
|
|
|
|
- ParlDok-Plattform (analog MV)
|
|
- Synergien mit MV-Parser hoch
|
|
- Aufwand: ~1-2 Tage (nach MV)
|
|
|
|
### Baden-Württemberg (BW)
|
|
|
|
- PARLIS-Eigensystem
|
|
- Format: PDF
|
|
- Aufwand: ~2 Tage
|
|
|
|
## Implementations-Reihenfolge nach Aufwand-Nutzen
|
|
|
|
1. **MV + TH** parallel (gleiche ParlDok-Plattform, Synergien)
|
|
2. **BUND** (XML-Endpoint!) — strukturierte Daten leichter als PDF-Parser
|
|
3. **HE** wenn HTML-Plenarprotokolle existieren
|
|
4. Rest nach Bedarf
|
|
|
|
## Cron-Erweiterung pro neuem BL
|
|
|
|
In `scripts/auto-ingest-protocols.sh` einen `PROTO_TARGETS`-Eintrag
|
|
ergaenzen:
|
|
|
|
```bash
|
|
PROTO_TARGETS=(
|
|
"NRW|18|https://www.landtag.nrw.de/.../MMP18-{n}.pdf"
|
|
"BUND|20|https://dserver.bundestag.de/btp/20/20{n:03}.pdf"
|
|
...
|
|
)
|
|
```
|
|
|
|
Format-Spec: `BL_CODE|WAHLPERIODE|URL_MIT_{n}_PLACEHOLDER`. Das Skript
|
|
erkennt automatisch das letzte ingestete Protokoll dieses BL/WP und
|
|
inkrementiert.
|