Scraper SN: Sachsen (ParlDok, Wahl 2029-09-02) #26
Labels
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: tobias/gwoe-antragspruefer#26
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Wahltermin
2029-09-02 — Sachsen (SN), aktuell 8. Wahlperiode.
Backend
ParlDoksn8/1234Adapter-Strategie
ParlDok (1/2) —
ParLDokAdapterfür MV existiert bereits. SN nutzt EDAS, das laut bundeslaender.py auf ParlDok basiert. Erste Frage beim Reverse-Engineering: ist es ParlDok 8.x mit demselben JSON-API-Schema (/parldok/Fulltext/Search) oder eine ältere Version? Wenn 8.x → einfacher Registry-Eintrag mit anderembase_urlundprefix.Was zu tun ist
webapp/app/parlamente.pyimplementieren — entweder als neue Subklasse vonParlamentAdapteroder als zweiter Registry-Eintrag eines existierenden parametrisierbaren Adapters.ADAPTERS-Registry am Ende der Datei.ADAPTERS["SN"].search("Schule", limit=10)liefert echte Anträge mit Datum + Fraktionen, sortiert newest-first.Hängt mit … zusammenunten) — dieses Issue ist nur der Adapter selbst, nicht das Indexieren der Wahlprogramme oder das Frontend-aktiv-Setzen.Akzeptanzkriterien
parlamente.py::ADAPTERS["SN"]existiert und ist instanziierbarsearch(query="Schule", limit=10)liefert ≥3 echte Drucksachen mit korrektem Datum, Fraktionen, PDF-Linkget_document(drucksache)für eine reale Drucksache der laufenden WP liefert das Dokument zurückdownload_text(drucksache)extrahiert Text aus dem PDFHinweise aus dokukratie/sn.yml
Klassifikations-Korrektur: SN ist in
bundeslaender.pyalsdoku_system="ParlDok"eingetragen, aber dokukratie/sn.yml zeigt ASP.NET Webforms mit__CALLBACKID-Postbacks — das ist eine ganz andere Engine als ParlDok 8.x von MV.https://edas.landtag.sachsen.de/parlamentsdokumentation/parlamentsarchiv/suchmaske_einfach.aspxhttps://edas.landtag.sachsen.de/parlamentsdokumentation/parlamentsarchiv/trefferliste.aspx?NavSeite=1https://edas.landtag.sachsen.de/parlamentsdokumentation/parlamentsarchiv/treffer_vorgang.aspx.//form[@id="aspnetForm"]__CALLBACKID,__CALLBACKPARAM, plus die langenctl00_masterContentCallback_content_suchmaske_*-IDs (typische ASP.NET-Webforms-Field-Namen).//td[@class="dxdvItem_EDAS dx-al"].//td[@class="text"]/a[contains(text(), "Drs")].//td[@class="text"]/bbody[@onload]-Skript-TrickSynergie: Komplett eigenständig, NICHT mit MV ParlDok teilbar. Eigener
EDASAdapteroderASPNetWebFormsAdapter. Reverse-Engineering der__CALLBACKID-Postbacks ist die größte Herausforderung — ASP.NET-Webforms haben üblicherweise auch ein__VIEWSTATE-Feld, das mit jedem Request mitgeschickt werden muss.bundeslaender.py-Korrektur:
SN.doku_system="ParlDok"→ sollte"ASP.NET/EDAS"oder"Eigensystem"sein, weil keine ParlDok-Kompatibilität mit MV/HH besteht.Phase-J-Recherche-Befund (autonomer Run #59)
HAR-Trace
TEMP/edas.landtag.sachsen.de.haranalysiert. EDAS lässt sich nicht autonom adaptieren, zwei harte Hindernisse:1. Vollwertiger ASP.NET-Webforms-Postback-Flow
3-Step-Workflow:
suchmaske_einfach.aspx(status 200) — initial Form-State setzen mit gigantischem__VIEWSTATE(>5KB base64) plus alle DevExpress-Control-IDs als Hidden-Feldersuchmaske_einfach.aspx(status 0) — Click auf den Suchbutton, browser-side abgebrochen, DevExpress Callback-API mit eigenem Wire-Format.__EVENTTARGET=ctl00$masterContentCallback$content$suchmaske$tblSearch$tabSuche$panelUmSuchmaskeEinfach$suchmaskeEinfachCallback$btn_EinfSuchetrefferliste.aspx?NavSeite=1— lädt die Result-Page aus der Server-SessionDirektzugriff auf
trefferliste.aspxohne vorherige Session redirected zuEDASError.aspx?error=session. Ein autonomer Adapter müsste den vollen Postback-Flow inklusive__VIEWSTATE-Deserialisierung und DevExpress-Wire-Format simulieren — geschätzter Aufwand: 8–15h Reverse-Engineering plus laufende Wartung bei jedem Server-Update.2.
robots.txt: Disallow: /Der Sächsische Landtag verbietet ausdrücklich automatisches Crawling. Ein scrapender Adapter wäre rechtlich/ethisch fragwürdig — das ist ein qualitatives Signal, das die anderen 9 aktivierten Landtage nicht haben.
Empfehlung
Phase J vertagt. Sinnvolle Alternativen für künftige Sessions:
Die anderen drei Phase-J-Adapter aus dem autonomen Run sind erfolgreich:
0f7d35f4a8986e278d74fErledigt durch Phase J reaktiviert / Commit
19e5fe4Weg drumherum gefunden: User exportiert wöchentlich manuell aus der EDAS-Suchmaske einen XML-Dump aller Anträge (bis 2500 Treffer/Export). Datei wird unter
data/sn-edas-export.xmlins persistent volume des Containers gelegt.SNEdasXmlAdapterparst das XML lokal — keine HTTP-Calls gegen edas.landtag.sachsen.de während dessearch()/get_document()download_text()resolved die echte PDF-URL on-demand über einen einzelnen GET gegenviewer_navigation.aspx(single GET, kein Postback) und holt dann das PDF vonws.landtag.sachsen.de/images/BÜNDNISGRÜNE/Bündnisgrüneals Sachsen-spezifischer GRÜNE-EigennameLive verifiziert: 5 Klima-Anträge inkl. 8/2100 (GRÜNE Fahrradoffensive 2025), 7/2067 mit Koalitionssatz [CDU, SPD, GRÜNE].
Beide robotsignal-Probleme adressiert:
Maintenance-Hinweis: das XML enthält die ZUM EXPORT-ZEITPUNKT vorhandenen 2500 neuesten Anträge. Bei wöchentlichem Update-Rhythmus reicht das gut aus, weil ~50-100 neue Anträge/Woche entstehen. Re-Upload via
scp data/sn-edas-export.xml vserver:/opt/gwoe-antragspruefer/data/.