BEV-Parzellengeometrie- und Exportvertrag v1

Stand: 7. Oktober 2026

Zweck und tatsächlicher Geltungsbereich

Dieser Vertrag beschreibt ausschließlich eine qualifizierte BEV-Parzellen- geometrie als begrenzten Bestandteil eines wertschöpfenden LandNutzen- Standortprodukts. Er ist weder ein Grundbuchauszug noch ein Eigentümerdienst, kein selbstständiges BEV-Datenprodukt und keine nationale Katasterlieferung.

Der qualifizierte BEV-Export-Pointer ist seit dem Produktionslauf vom 25. August 2026 aktiv (am 29. September 2026 neu qualifiziert, siehe „Unveränderter Public-Snapshot und strenge Export-Teilmenge“). Seine Aktivierung ist von den Consumer-Deployments getrennt: GeoJSON, PDF und DXF sind release-gebunden. Der DXF-Consumer wurde am 26. August 2026 auf Merge-SHA 8b276764f8d5803e8dc6ecdbe54323d8b38445c1 mit Dark Deploy, kontrolliertem Flagwechsel, positivem und negativem Readback, GDAL-Parserprüfung sowie bewiesenem Rollback aktiviert. Der finale Produktionszustand ist DXF_EXPORT_ENABLED=true; false bleibt der jederzeitige fail-closed Rollbackzustand. Eine Umgebung darf Geometrie nur nach eigenem Consumer-Deployment und mit ihrem qualifizierten Export-Pointer ausgeben.

Exakte Quellen- und Release-Identität

Eigenschaft	Verbindlicher Wert
Source-Slug	bev-parzellen
Distribution	bev-dkm-gpkg-pilot-snapshot
Nutzungszweck	export
Active-Pointer-Kanal	export
Pilot-Coverage	bev-gaenserndorf-pilot-v1
BBox [W,S,E,N]	[16.64,48.28,16.8,48.4]
Lizenz	CC-BY-4.0
Source-Review-Status	conditional
Export-Capabilities	parcel_geojson, pdf_parcel_outline, parcel_dxf

Der getrennte öffentliche Punkt-Lookup verwendet weiterhin ausschließlich bev-parzellen/public, den Zweck public_display und die Capability point_lookup. Sein Active Pointer ist kein Export-Pointer. Umgekehrt erweitert der Exportkanal weder die Punkt-Coverage noch den öffentlichen Standort-Check.

Unveränderter Public-Snapshot und strenge Export-Teilmenge

Der bestehende öffentliche Pilot umfasst 29.746 veröffentlichte Originalgeometrien und 15 quarantänisierte Quellzeilen, insgesamt 29.761 Quellzeilen. Sein historischer Import mit ogr2ogr -spat hat auch Pilotgrenzen schneidende Parzellen als vollständige, unveränderte Originalpolygone übernommen. Für den an seinen Abfragepunkt gebundenen point_lookup ist das kein Geometrieexport.

Der getrennte Export darf ausschließlich unveränderte Originalpolygone übernehmen, die vollständig innerhalb der genehmigten Pilotgrenze liegen:

ST_CoveredBy(geom, ST_MakeEnvelope(16.64, 48.28, 16.8, 48.4, 4326))

ST_Intersects, ein Polygonmittelpunkt, eine Adresse innerhalb der BBox oder eine beschnittene beziehungsweise mit ST_Intersection veränderte Geometrie sind kein zulässiger Ersatz. Die 29.746 öffentlichen Geometrien bleiben unverändert; outsideCoverageRowCount zählt alle daraus ausgeschlossenen, nicht vollständig umschlossenen Originalpolygone, unabhängig davon, ob sie die Grenze schneiden oder vollständig außerhalb liegen.

Die überprüfte Zählwertbindung lautet:

publicRowCount = publishedRowCount + outsideCoverageRowCount = 29.746
publicSourceRowCount = publicRowCount + quarantinedRowCount = 29.761
sourceRowCount = publishedRowCount + quarantinedRowCount
publicSourceRowCount = publishedRowCount + outsideCoverageRowCount + quarantinedRowCount
quarantinedRowCount = 15

Der Produktions-Readback vom 25. August 2026 bestätigte publishedRowCount=28535, outsideCoverageRowCount=1211, sourceRowCount=28550 und quarantinedRowCount=15. Damit gilt 28.535 + 1.211 = 29.746 und 28.535 + 15 + 1.211 = 29.761. Damals war der Export-Release 7ae1d4da-e5d5-5c09-ae1f-15997506d4f7 mit Pointer-Version 1 aktiv, der öffentliche Release 655a7dc3-1f7a-5bdc-a329-d73f1c458320 mit Pointer-Version 2.

Stand nach der Neuqualifizierung vom 29. September 2026: Weil die Frischegrenze von 190 auf 306 Tage an den Veröffentlichungsrhythmus des BEV gebunden wurde (#618), wurde derselbe Quellenstand 2026-04-01 neu qualifiziert (Nachweis). Aktiv sind seitdem der öffentliche Release 5e5329cf-630f-5df1-a8b7-47bafa401856 (Pointer-Version 3) und der Export-Release 74be37a0-6aaf-5888-bb03-7a6a2ab4f30d (Pointer-Version 2), beide frisch bis 2027-02-01. Manifeste und Zeilenzahlen (28.535, 1.211, 29.746, 15 Quarantänefälle) sind unverändert. Weil Exporte an den öffentlichen Release des gespeicherten Reports gebunden sind, verlieren Reports, die auf dem früheren Release gebaut wurden, den Export.

publicManifestSha256 und publicSourceManifestSha256 gehören zum vollständigen öffentlichen Snapshot. Der Export-Release erhält dagegen sein eigenes manifest_sha256 und sourceManifestSha256 für die zulässige Teilmenge; quarantineManifestSha256 bindet die übernommenen 15 Quarantänefälle. Migration 0048_bev_parcel_export_release.sql schafft den separaten Kanal, Migration 0049_bev_parcel_export_bounded_subset.sql bindet die strenge Teilmenge. Öffentliches Manifest ad8d194236e319a55a784d6ad6a37b0c6e4cb25f0d1925bd16ce4dd19f3f99c7 und Export-Manifest d6c29076b1c50551cf5ca8c12f8e9948cb8081b75f9108eb5120a734f4898397 sind getrennt nachgewiesen. Der Infrastruktur-Readback allein belegt noch keinen produktiven GeoJSON-/PDF-Consumer.

Verbindliche Bedingungen

Die export-Regel des geprüften BEV-Rechtevertrags enthält genau diese Bedingungen:

1. attribution;
2. sourceLink;
3. licenseLink;
4. changeNotice;
5. nonEndorsement;
6. valueAddedReport;
7. notStandaloneBevProduct;
8. pilotCoverageOnly;
9. noOwnerData.

Die geprüfte Rechte-Datei muss mit rightsReviewSha256 und rightsReviewStateSha256 im usage_context des tatsächlich aktiven öffentlichen BEV-Release übereinstimmen. Der Export-Release übernimmt genau diese beiden Nachweise; source_release_registry_allows prüft zusätzlich den zulässigen Registry-/Zweckvertrag. Die gleichnamigen Digest-Spalten von source_registry dürfen für diese Quelle NULL sein und sind kein alternativer BEV-Rechtenachweis.

Die vorgeschriebene sichtbare Quellenangabe lautet:

Datenquelle: BEV – Bundesamt für Eich- und Vermessungswesen (data.bev.gv.at), CC BY 4.0

• Amtlicher BEV-Quelldatensatz
• CC BY 4.0

Technische Ableitungen werden als Bearbeitung gekennzeichnet. Das BEV unterstützt oder bestätigt die LandNutzen-Auswertung nicht. Die dargestellte DKM-Geometrie ist kein rechtsverbindlicher Vermessungsplan. Namen, Eigentümerdaten, Grundbuchinhalte, Anschriften, Eigentumsanteile oder andere personenbezogene Inhalte werden weder übernommen noch ausgegeben.

Atomare Export-Sicht und Statusmodell

parcel_versions_export_current ist eine eigenständige, zweckgebundene Sicht; parcel_versions_current bleibt für den öffentlichen Punkt-Lookup erhalten. Ein einzelner atomarer SQL-Read verbindet den export-Active-Pointer, den gebundenen qualifizierten Pilot-Release, den erfolgreichen Importlauf, Distribution, angeforderte Capability, Rechte, Freshness, Quality, Pilotgrenze und unveränderte parcel_versions. Der öffentliche Release des vorhandenen Reports, der derzeit aktive öffentliche Pointer und die im Export-Release fixierte öffentliche Pointer-Version müssen übereinstimmen; ein bloß gleicher Source-Slug reicht nicht.

getReleasedParcelGeoJSON(lat, lon, capability, expectedPublicReleaseId);

Der vierte Pflichtparameter bindet den Report-Stand an den tatsächlichen öffentlichen Active Release. Zusätzlich verlangt der atomare Read Parität zwischen sourceSelection.publicPointerVersion und der aktiven öffentlichen Pointer-Version. Eine Rotation oder ein fremder Report-Release verhindert gemischte Report-/Public-/Exportstände fail-closed.

Zulässige technische Ergebnisse:

hit
no_hit
outside_coverage
ambiguous_boundary
quality_rejected
source_not_released
failed

Der GeoJSON-/PDF-Pfad kennt zusätzlich freshness_rejected: eine reine Diagnose derselben Datenbankabfrage, kein zusätzliches Gate. Sie wird nur gemeldet, wenn kein ausgabefähiger Release gefunden wurde und der aktive Export-Release zwar Registry- und Rechteprüfung besteht, aber ausschließlich wegen überschrittenem fresh_until gesperrt ist. Rechte- oder Registry-Sperren haben Vorrang und bleiben source_not_released.

Nur hit enthält eine freigegebene Geometrie. Ein Randpunkt mit mehreren möglichen Parzellen wird nicht willkürlich aufgelöst. Quarantänefälle, fehlende Rechte, fehlende oder veraltete Releases, falsche Capabilities, fehlende Qualität, Außen-Coverage und technische Fehler öffnen weder einen Legacy-Read noch einen WMS-Geometrie-Fallback.

Quarantäne: Sperre nur, wenn die Parzelle am Punkt betroffen sein könnte

Quarantänisierte Quellparzellen (ungültige BEV-Geometrie) werden nie ausgegeben. Von ihnen ist nur die Hülle bekannt, also die Bounding Box der ungültigen Geometrie. Eine einzelne langgestreckte Parzelle kann damit mehrere Quadratkilometer überdecken. Karte, PDF-Outline und DXF entscheiden deshalb gleich (seit 5. Oktober 2026, ADR-0055-Nachtrag):

• Genau eine gültige Parzelle enthält den Adresspunkt: hit. Die quarantänisierte Parzelle bleibt weggelassen, auch wenn ihre Hülle Punkt und Ausschnitt überdeckt.
• Der Punkt liegt in keiner gültigen Parzelle oder auf einer Grenze, und eine Quarantäne-Hülle überdeckt ihn: quality_rejected. Die Adresse könnte auf der fehlerhaften Parzelle liegen.
• Schneidet eine Hülle nur den Ausschnitt, nicht den Punkt, sperrt sie nicht.

metadata.quarantinedInWindow nennt die Zahl der Quarantäne-Hüllen, die den Ausschnitt schneiden (0, wenn keine); der Kartenpfad liefert sie mit jedem hit. Das ist eine Obergrenze der nicht dargestellten Parzellen: Die Parzelle selbst kann außerhalb des Ausschnitts liegen. Karte, PDF und DXF (Planer-Umfang) nennen sie mit demselben Satz, etwa: „In diesem Ausschnitt fehlt möglicherweise eine Parzelle, deren Amtsgeometrie (BEV) fehlerhaft ist und die deshalb nicht dargestellt wird.“

Vorhandener GeoJSON-Kartenpfad

GET /api/parcel-geojson?lat=<lat>&lon=<lon>&reportId=<report-id>
Cache-Control: private, no-store

Der bestehende, rate-limitierte Kartenpfad verwendet ausschließlich die Capability parcel_geojson für ein internes Kartenoverlay eines bereits gespeicherten wertschöpfenden Standortreports. Die verpflichtende reportId muss einen tatsächlich vorhandenen Report mit exakt derselben Koordinate, bestätigtem BEV-Pilot-Treffer und mindestens einer zusätzlichen Nicht-BEV-Datenquelle bezeichnen. Der Report-Release, der aktive öffentliche Pointer und der Export-Release müssen exakt zusammenpassen. Der Pfad ist weder ein eigenständiges BEV-Datenprodukt noch ein allgemeiner Kataster-Download.

• Fehlende oder formal ungültige reportId: 404 report_context_required, bevor Rate-Limit oder Datenbankzugriff ausgelöst werden.
• Nicht vorhandener oder abgelaufener Report: 404 report_not_found.
• Abweichende Koordinate, fehlender BEV-Pilot-Treffer oder fehlendes wertschöpfendes Nicht-BEV-Quellensignal: 403 report_context_mismatch.
• Ungültige Koordinaten: 400; überschrittenes Kartenlimit: 429.

Nur ein hit liefert die bestehende GeoJSON-FeatureCollection mit zusätzlicher BEV-Herkunft, Quellen-/Lizenzhinweis, Quellenstand, Bearbeitung und Vermessungsgrenze. Vorhandene Reports werden nur gelesen; der Endpunkt legt weder einen neuen Report an noch schreibt er zusätzliche personenbezogene Produktionsdaten.

Außen-Coverage, no_hit, Boundary-Mehrdeutigkeit, Quarantäne, abgelaufene Rechte, Stale-Zustände, fehlender Export-Pointer, ein abweichender öffentlicher Release und technische Fehler führen zu 503 Service Unavailable. Auch Fehlerantworten bleiben private, no-store. Ein fachlich unsicherer Fall wird nie als leere, scheinbar bestätigte FeatureCollection verkauft.

Der Fehlercode unterscheidet, was die Karte dazu sagen darf:

• 503 source_stale — freshness_rejected: Datenstand veraltet; erst ein erneuerter Release hilft, Neuladen nicht.
• 503 source_unavailable — failed oder unerwarteter Adapterfehler: vorübergehend gestört; später erneut versuchen.
• 503 source_quality_rejected — quality_rejected: Der Adresspunkt liegt in keiner gültigen Parzelle (oder auf einer Grenze), aber in der Hülle einer Parzelle mit fehlerhafter Amtsgeometrie. Deterministisch; Neuladen hilft nicht.
• 503 source_not_released — alle übrigen Zustände: für diesen Ausschnitt nicht freigegeben.

PDF-Outline innerhalb eines bestehenden Reports

Die bereits vorhandene Report-PDF verwendet ausschließlich pdf_parcel_outline und denselben zwingenden öffentlichen Release aus dem gespeicherten Report. Nur ein qualifizierter hit mit Report-/Public-/Export- Parität darf die Parzellenoutline zeichnen. Bei jedem anderen Zustand bleibt die Outline null; der übrige Report und die PDF werden dadurch nicht zu einem ungebundenen Geometry-Export. Das Deckblatt nennt den Grund: bei freshness_rejected (oder einem schon beim Report-Aufbau veralteten Parzellen-Release) „Datenstand veraltet — Parzellenbezug derzeit nicht ausgewertet“, bei quality_rejected „Parzellen-Umriss nicht eingezeichnet — der Adresspunkt könnte auf einer Parzelle mit fehlerhafter Amtsgeometrie (BEV) liegen“, bei jedem anderen erwarteten, aber nicht gelieferten Umriss „Parzellen-Umriss derzeit nicht verfügbar“. Beim gezeichneten Umriss nennt es wie die Karte metadata.quarantinedInWindow.

Die bestehende Reportpersistenz, Zugriffskontrolle, Rate-Limits und Attributionspflichten bleiben unverändert. Der eigenständige Standort-Check erzeugt weiterhin weder Report noch PDF oder Geometrieexport.

DXF ist release-gebunden und kontrolliert live

parcel_dxf ist rechtlich überprüfte Capability und im Consumer-Inventar release_bound. #412 ist mit einem vollständigen Produktions- und Rollback-Readback abgeschlossen. Im finalen Produktionszustand ist DXF_EXPORT_ENABLED=true; der initial bewiesene und jederzeitige Rollbackzustand false liefert 404 und entfernt den Pfad aus dem öffentlichen OpenAPI-Schema. Nur die Kombination aus release-gebundenem Consumer und exakt DXF_EXPORT_ENABLED=true dokumentiert den Pfad; das Flag umgeht weder Export-Release noch Report-, Rechte-, Coverage-, Freshness-, Quality-, Quarantäne- oder Boundary-Gates.

Der DXF-Aufruf ist an einen bereits gespeicherten wertschöpfenden Report, seine exakte Standortkoordinate, denselben öffentlichen Release und mindestens eine Nicht-BEV-Datenquelle gebunden. Ausgegeben werden ausschließlich die vollständigen, unveränderten Originalpolygone des qualifizierten ST_CoveredBy-Exports in voller Stützpunktdichte; weder Clipping noch Vereinfachung, Mittelpunktfreigabe oder ein Legacy-/WMS-Fallback sind zulässig. Die Ausgabe bewahrt sichtbare BEV-Attribution, Quelle, Lizenz, Bearbeitung, Nicht-Unterstützungshinweis und Vermessungsgrenze. Sie enthält keine Eigentümerdaten, ist kein eigenständiges BEV-Produkt, kein allgemeiner Katasterdownload und kein rechtsverbindlicher Vermessungsplan. Ein fehlender Report bleibt 404, ein gespeicherter Report ohne passenden Mehrwert-/Public- Release-Kontext 403 report_context_mismatch, ein unpassender Export-Release oder Nutzungszweck 503 und ein Rendererfehler 500 dxf_failed.

NÖGIS-Widmung und sonstige NÖGIS-Distributionen erhalten keine BEV-Rechte. Ihre Speicherung, Anzeige und Exportfähigkeit bleiben je Bezugskanal an #413 gebunden. Es entstehen keine Eigentümerabfrage, keine bundesweite Parzellenabdeckung und keine neue indexierbare öffentliche Werkzeugroute.

Aktivierung und Rollback

node scripts/publish-bev-parcel-export-release.mjs \
  --expected-public-release-id=<uuid>

Die Aktivierung bindet den Export-Kandidaten an genau den erwarteten bereits qualifizierten öffentlichen Pilot-Snapshot. Candidate, Qualitätsprüfung und Expected-Current-CAS betreffen ausschließlich bev-parzellen/export.

Der manuell gestartete Betreiber-Workflow unterstützt einen schreibfreien dry-run. Eine tatsächliche Veröffentlichung verlangt die exakte Bestätigung PUBLISH bev-parzellen export, die erwartete öffentliche Release-ID und einen versionierten Prüfnachweis (Eingabe evidence_ref; bei einer Neuqualifizierung des öffentlichen Kanals den Nachweis dieser Erneuerung angeben). Seit #627 (30. September 2026) akzeptiert die Vorprüfung einen noch am vorherigen öffentlichen Release hängenden Export. Es wird keine automatische Veröffentlichung ausgelöst.

Für den DXF-Consumer wird zuerst mit DXF_EXPORT_ENABLED=false deployt und gegen 404, einen ebenfalls geschlossenen OPTIONS-Preflight sowie ein fehlendes OpenAPI-Path-Item rückgelesen. Erst nach qualifiziertem Export-Pointer und erfolgreichem Dunkel-Readback darf die Umgebung exakt auf true wechseln. Weil Vercel-Umgebungsänderungen erst in einem neuen Deployment wirksam werden, gehört dazu jeweils ein Redeploy desselben geprüften Commits, das Warten auf Ready und der anschließende HTTP-/OpenAPI-Readback. Das deploymentabhängige OpenAPI-Dokument trägt Cache-Control: no-store. Der Consumer-Rollback ist entsprechend: Flag auf false, denselben geprüften Commit erneut deployen, Ready abwarten und 404 plus fehlendes OpenAPI-Path-Item bestätigen. Daten und Pointer werden dabei nicht geändert.

Dieser Ablauf wurde am 26. August 2026 vollständig auf Merge-SHA 8b276764f8d5803e8dc6ecdbe54323d8b38445c1 ausgeführt. Das finale Produktionsdeployment dpl_CaUMXVpyerL5iV6BzraupmboMgtr liefert DXF mit 200, private, no-store, sichtbarer Attribution und unveränderter Originalgeometrie. GDAL 3.13.3 öffnete die Datei erfolgreich. Ungültige, unbekannte und quarantänisierte Fälle blieben im Live-Readback fail-closed und redigiert. Die blockierte Consumer-Bindung sowie Außen-Coverage, Boundary- und Reportkontextfälle sind zusätzlich durch Route-, Contract- und echte PostGIS- Tests belegt, nicht als eigene produktive Requests. Der Flag-Rollback auf false bestätigte 404 für GET und OPTIONS sowie das fehlende OpenAPI-Path-Item; nach dem erneuten Aktivieren blieb der Datei-Hash deterministisch gleich. Öffentlicher Release 655a7dc3-1f7a-5bdc-a329-d73f1c458320 und Export-Release 7ae1d4da-e5d5-5c09-ae1f-15997506d4f7 blieben währenddessen unverändert.

Ein Datenrollback setzt nur den Export-Pointer auf einen zuvor qualifizierten Export-Release zurück beziehungsweise hält ihn geschlossen, wenn kein geeigneter Stand vorliegt. Der öffentliche public-Punkt-Lookup und andere Datenquellen bleiben unberührt. Der erfolgreiche Infrastruktur-Publish war die Voraussetzung, aber nicht der DXF-Consumer-Nachweis. Der DXF-Produktionsnachweis enthält die ausgeführten Negativ-, Positiv-, Parser- und Rollback-Readbacks.

Weitere Informationen: BEV-Pilot und Datenexport, Quellen und Lizenzen, Standort-Check-Datenpass und aktueller Produktstatus.