ADR-0066: PDF/UA-Parzellengeometrie als Figure (Slice H)

• Status: Accepted; Vertrag vor Implementierung festgelegt, 4. September 2026
• Issue: #550, Parent #333 bleibt offen

Eingabe und Autorisierung

Ein optionaler typisierter Geometrieeingang wird serverseitig aus dem bestehenden pdf_parcel_outline-Export aufgelöst. Der Adapter verwendet resolveBevExportReportContext, Consumerbindung und getReleasedParcelGeoJSON. Damit bleiben Rechte, Freshness, Coverage, Quarantäne, aktiver Public-/Export- Release und wertschöpfender Report Voraussetzung. Der reine Renderer liest weder Datenbank noch Provider. Eine Geometrie ist an den SHA-256 des übergebenen Reportstands sowie Public-/Export-Release gebunden; Änderungen am Report machen sie unbrauchbar. BEV-Tokens sind höchstens 60 Sekunden gültig und werden unmittelbar für einen Renderlauf aufgelöst. Der Vertrag ist intern und kein neuer Request-Body der Route.

Geometrie und Ausgabe

EPSG:4326 Polygon und MultiPolygon werden lokal metrisch angenähert (Längengrade mit Kosinus der mittleren Breite, Norden oben), proportional und zentriert mit Rand in den vorhandenen Kartenrahmen projiziert. Kein Clipping und keine Ersatzform. Höchstens 48 Features, 64 Polygone und insgesamt 2048 Koordinaten; alle Koordinaten liegen vollständig innerhalb der bestehenden Pilot-Coverage. Ringe müssen geschlossen, endlich, nicht degeneriert und ohne Selbstüberschneidung sein. Innenringe werden in Slice H ausdrücklich als nicht unterstützt abgelehnt; die Ausgabe nennt diesen Grund sichtbar. Der Reportpunkt muss eindeutig innerhalb der Treffergeometrie liegen; vorhandene Grundstückskennung und kanonische Parzellen-ID müssen zum Treffer passen. Widersprüchliche Lookup-Status, Fehlermeldungen oder Quellen-Releases sperren die Abbildung.

Nur eine akzeptierte Geometrie erzeugt eine Figure. Ihr Alternativtext nennt Treffer-/Nachbaranzahl, Teilflächen, Eckpunkte, metrische Ausdehnung und die synthetische Herkunft beziehungsweise den Datenstand. Herkunft, Attribution, Lizenz, Änderungshinweis, Non-Endorsement und Vermessungsgrenze bleiben sichtbar. Fehlende, gesperrte, veraltete, leere, widersprüchliche oder ungültige Eingaben liefern einen Absatz mit Abwesenheitsgrund statt einer erfundenen Karte.

Prüffälle vor Implementierung

Rot, anschließend Grün: veränderte Koordinaten verändern Vektorpfad und Alt-Text; Polygon, MultiPolygon und Nachbar; Innenring; Selbstüberschneidung; offener/degenerierter Ring; NaN/Infinity; falscher Typ; leere und zu große Eingabe; mehrere Treffer; Report-/Release-Mismatch; gesperrter Consumer; alle negativen Exportzustände und Fehler. PDF-Prüfung bestätigt zwei Figures bei Abwesenheit, drei bei gültiger Geometrie, passende Alt-Texte und Lesereihenfolge.

Herkunft und Grenzen

Die Preview bleibt ausschließlich ein fest definierter synthetischer Prüfstand. Die neue unregelmäßige Referenz ist repository-eigene synthetische Testgeometrie, kein BEV-Ausschnitt und keine Rechtefreigabe. Ihr Dateihash wird im Slice-H- Nachweis dokumentiert. Der vorhandene reale Rechtebeleg ist FND-03, der Exportstand ist im Produktionsnachweis dokumentiert. Ein echter autorisierter positiver Geometrieausschnitt mit Hash fehlt für Slice H bisher; dies bleibt als eigener Nachweis offen.

Keine Änderung am öffentlichen React-PDF-Pfad, keine echten Nutzerreports, keine neuen Provider oder Importe. Chrome-Tag-Semantik bleibt offen; ein experimentelles PdfTags-Flag ist kein Abnahmekriterium. Risikokarten, Rollout und echter PDF/UA-Produktionsreport gehören nicht zu diesem Slice.

Der feste Chrome-Prüfer gilt für den positiven synthetischen Slice-H-Shadow: 20 Überschriften, sieben Tabellen, sechs Listen, drei Figures und zwei Links. Die Herkunftsüberschrift auf Seite 6 erhöht den früheren Slice-G-Sollwert von 19 auf 20. Abwesenheits- oder BEV-PDFs sind kein Teil dieses festen Vier-Tier-Chrome-Profils; dafür wären getrennte Manifestprofile erforderlich.