Adapter-Capabilities: Vergleichsmatrix

Stand: 2026-04-10. Automatisch aus parlamente.py + bundeslaender.py extrahiert.

Übersicht

16 Bundesländer + Bundestag, alle aktiv.

BL	Adapter	WP	Suche	Fuzzy	Typ-Filter	API
BUND	BundestagAdapter	21	Server (DIP REST) + Title-Filter	Nein	Server (`f.drucksachetyp`)	REST JSON
NRW	NRWAdapter	18	Server (HTML-Form) + AND-Filter	Nein	Server (`dokTyp`)	HTML POST
LSA	PortalaAdapter	8	Server (eUI) + Title-Filter	Nein	Server (`ETYPF=Antrag`)	eUI 2-Step
BE	PortalaAdapter	19	Server (eUI, 730d-Fenster) + Title-Filter	Nein	Client-only	eUI 2-Step
BB	PortalaAdapter	8	Server (eUI) + Title-Filter	Nein	Server (`ETYPF=Antrag`)	eUI 2-Step
RP	PortalaAdapter	18	Server (eUI) + Title-Filter	Nein	Server (`ETYPF=Antrag`)	eUI 2-Step
MV	ParLDokAdapter	8	Server (ParlDok JSON) + Typ-Filter	Nein	Client (`type=="Antrag"`)	REST JSON
HH	ParLDokAdapter	23	Server (ParlDok JSON) + Typ-Filter	Nein	Client (`type=="Antrag"`)	REST JSON
TH	ParLDokAdapter	8	Server (ParlDok JSON) + Typ-Filter	Nein	Client (Substring `"Antrag"` in type)	REST JSON
SH	StarFinderCGI	20	Server (CGI, `dtyp=antrag`) + Title-Filter	Nein	Server (`dtyp`)	Legacy CGI
HE	StarWebHEAdapter	21	Server (eUI, VTDRS) + Title+Typ-Filter	Nein	Client (`"antrag"` in typ)	eUI 2-Step
HB	PARiSHBAdapter	21	Server (PARiS-Servlet) + Typ-Filter	Nein (Thesaurus only)	Client (`"antrag"` in typ)	HTML POST
BW	PARLISAdapter	17	Server (eUI, async Polling) + Title-Filter	Nein	Server (`lines.l4=Antrag`)	eUI async
BY	BayernAdapter	19	Server-Volltext (Solr) + Typ-Filter	Ja (Solr)	Client (`typ=="antrag"`)	HTML Scraping
SL	SaarlandAdapter	17	Server-Volltext (Umbraco) + Typ-Filter	Umbraco-Relevanz	Client (`DocumentType`)	REST JSON
SN	SNEdasXmlAdapter	8	Statisch (manueller XML-Export) + Title-Filter	Nein	N/A	XML Import

Such-Architekturen

Volltext-Suche server-seitig

Nur BY (TYPO3-Solr) und SL (Umbraco) bieten echte Volltextsuche über den gesamten Dokumentkorpus. Alle anderen filtern entweder nur den Titel client-seitig oder nutzen eingeschränkte Server-Filter (WP + Datum).

Client-seitige Title-Filterung

Die Mehrheit (portala/eUI, ParlDok, StarFinder, BUND) holt einen breiten Satz von Treffern nach WP/Datum/Typ und filtert dann im Python-Code per all(t in title.lower() for t in query_terms). Das bedeutet:

Nur Titel-Matches — Inhalte der Drucksachen werden nicht durchsucht
AND-Logik — alle Suchbegriffe müssen im Titel vorkommen
Keine Fuzzy-Toleranz — Tippfehler oder Synonym-Drift werden nicht abgefangen
Performance ok — max. 1000-1500 Treffer pro Request (via chunksize)

Sonderfälle

BL	Besonderheit
SN	Kein Scraping möglich (`robots.txt`); manueller wöchentlicher XML-Export aus EDAS
BE	`document_type=None` weil Berlin's ETYPF andere Values nutzt; 730-Tage-Fenster als Workaround
TH	Anträge heißen "Antrag gemäß § 79 GO" → Substring-Match statt Exact-Match; `kinds=["Drucksache", "Vorlage"]`
BW	Async 2-Step mit Search-ID-Polling (2-15 Versuche × 2s Pause), JSON-in-HTML-Comments
HE	Perl-Data::Dumper in HTML-Comments, Hex-Escape-Decoding (`\x{e9}` → `é`)
NI	❌ Nicht implementiert — NILAS-StarWeb braucht Session-Cookie, HAR-Capture nötig

Historien-Tiefe (ältere WPs)

Alle Adapter sind aktuell auf eine feste Wahlperiode konfiguriert. Keiner unterstützt Queries über mehrere WPs hinweg. Ältere Drucksachen aus früheren WPs sind nicht abrufbar ohne Adapter-Rekonfiguration.

Für eine künftige Multi-WP-Suche müsste pro Adapter geprüft werden, ob das Backend WP-übergreifende Queries unterstützt:

API-Typ	Multi-WP möglich?
portala/eUI	Ja (WP-Term aus dem JSON-Tree weglassen)
ParlDok	Ja (`facet_lp` weglassen)
StarFinder/PARiS	Ja (WP-Param weglassen)
TYPO3-Solr (BY)	Ja (`wahlperiodeid[]` weglassen)
DIP-API (BUND)	Ja (`f.wahlperiode` weglassen)
Umbraco (SL)	Ja (`Filter.Periods=[]`)
EDAS-XML (SN)	Nur innerhalb des exportierten Datenbestands

Fehlende Adapter

BL	Status	Blocker
NI (Niedersachsen)	Issue #22 offen	NILAS-StarWeb erfordert Session-Cookie, HAR-Capture vom User nötig

4.5 KiB Raw Blame History Unescape Escape