BEV-Parzellengeometrie- und Exportvertrag v1

Stand: 26. August 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. 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 tatsächliche Produktions-Readback bestätigt 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. Der aktive Export-Release lautet 7ae1d4da-e5d5-5c09-ae1f-15997506d4f7 mit Pointer-Version 1; der öffentliche Release 655a7dc3-1f7a-5bdc-a329-d73f1c458320 mit Pointer-Version 2 bleibt unverändert.

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:

attribution;
sourceLink;
licenseLink;
changeNotice;
nonEndorsement;
valueAddedReport;
notStandaloneBevProduct;
pilotCoverageOnly;
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

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

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.

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.

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.

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. 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.