LandNutzen.Anmelden

Produktionsnachweis Lärminfo-WMS 2026-08-26

  • Source: laerm
  • Release-Typ: live_check
  • Zweck/Kanal: public_display / public
  • Distribution: laerminfo-wms-000804
  • Capabilities: report_lookup, map_tile, legend
  • Source-Vintage: 2022-12-31 (Kartierungsrunde 2022)
  • Coverage: country:AT innerhalb der amtlich publizierten Layer-BBox
  • Release-Persistenz: keine WMS-Rohantworten, Kartenbilder oder Live-Check-Koordinaten; eine bewusst gespeicherte Reportkoordinate folgt dem bestehenden Report-Lifecycle
  • Status: Initial-Release und Consumer produktiv aktiviert; erster planmäßiger Cron-Renewal noch nicht beobachtet

Produktions-Cutover

Die Infrastruktur aus PR #519 und der atomare Consumer-Cutover aus PR #520 sind am 26. August 2026 produktiv ausgerollt worden. Vor der Aktivierung blieb der neue Pfad nachweislich geschlossen:

  • Die öffentliche Provenienz lieferte HTTP 200 mit activeRelease=null.
  • Der exakte Vier-Quellen-GetMap für Lden endete mit HTTP 503, Cache-Control: no-store und source_not_released.
  • Ein transienter öffentlicher Report enthielt keinen Lärmblock und wies degraded.laerm=source_not_released aus.

Damit ist belegt, dass das Consumer-Deployment allein weder einen ungeprüften Providerzugriff noch einen stillen Legacy-Fallback öffnete.

Initiale Aktivierung

Der manuell bestätigte GitHub-Actions-Lauf 32916857279 war erfolgreich. Er verwendete die exakte Bestätigung ACTIVATE laerm public, wandte den distributionsgenauen Rechte-Review per CAS an und qualifizierte alle sechs Pflichtchecks. Die unveränderlichen Belege lauten:

  • Review-SHA-256 6452d389024700cf32b53581189591a02ec9e79c665ea2ce4df5892f73aaeba9
  • Rights-State-SHA-256 a6d214de335703fa65782681c4e3caefb6a38338eeb287d45d6de1511402b074
  • Manifest-SHA-256 5429352fc10d437e6cfac31ce3610fc308f36d99585f9fd89197f18aa32979c5
  • Release-Key 8173f289-1e3a-58e3-a215-2d4444e43111
  • Release-ID 63575c23-0121-506d-8baa-210a82dd957f
  • Qualifikations-Event 460, Aktivierungs-Event 461, Pointer-Version 1
  • Providerprüfung 2026-08-26T00:54:09.908Z, Aktivierung 2026-08-26T00:54:17.219Z, frisch bis 2026-08-27T00:54:09.908Z

Die öffentliche Provenienz weist die Quelle seitdem als registered, die Rechte als conditional, sechs von sechs bestandene Pflichtchecks und den genannten Active Release aus. Ein konditionaler Abruf mit ETag endete mit HTTP 304.

Provider-, Karten- und Legenden-Readback

Nach der Aktivierung lieferten die produktiven Proxy-Pfade:

  • den kombinierten Lden- und Lnight-GetMap über jeweils alle vier Quelltypen mit HTTP 200, image/png, no-store, 256 × 256 Pixeln und sichtbarem, vollständig dekodierbarem Inhalt;
  • die Lden-Legende mit HTTP 200, image/png, no-store, 234 × 152 Pixeln und die Lnight-Legende mit 252 × 172 Pixeln;
  • eine absichtlich manipulierte Ein-Layer-Kombination weiterhin mit HTTP 400, no-store und bad_request.

Die positive Probe und die Gegenprobe belegen gemeinsam, dass nur der kanonische Release-Vertrag geöffnet wurde.

Report-, Web- und PDF-Readback

Drei nicht personenbezogene öffentliche Adressen belegten die fachlichen Pfade:

  • Rathausplatz 1, 2230 Gänserndorf: gültiger No-Hit, alle acht Pegelfelder null, Ampel grün und kein degradierter Layer;
  • Flughafen Wien, 1300 Schwechat: Flug Lden 60 / Lden6064, Lnight 50 / Lnight5054, Ampel gelb und kein degradierter Layer;
  • voestalpine-Straße 3, 4020 Linz: Industrie/IPPC Lden 55 / Lden5559, Lnight 50 / Lnight5054, Ampel gelb und kein degradierter Layer.

Der bewusst gespeicherte, nicht personenbezogene Rathaus-Report vsBDmoEYS71Q1ERO5hfIn7 ist unter /r/vsBDmoEYS71Q1ERO5hfIn7 abrufbar. Permalink, beide Kartenebenen und Legenden verwenden denselben Vier-Quellen-Vertrag. Das reale PDF antwortete mit HTTP 200, application/pdf und private, no-store; sein Text enthält die vier Hauptquellen, Kartierungsrunde 2022, den kanonischen R-03-Satz und die verpflichtende Attribution.

Weder beim Publisher noch bei den Live-Checks wurden WMS-Rohantworten, Kartenbilder oder Koordinaten persistiert. Der einzige gespeicherte Produktionsreport verwendet eine öffentliche Gemeindeadresse; es wurden keine personenbezogenen Produktionsdaten und keine künstlichen Nutzerkonten geschrieben.

Noch getrennter Betriebsnachweis

Die vorstehende Aktivierung war ein einmaliger, manuell bestätigter GitHub-Actions-Lauf und kein ausgeführter Vercel-Cron. Der öffentliche Cron-Endpunkt verweigert anonyme Aufrufe korrekt mit HTTP 401. Der erste planmäßige, mit CRON_SECRET autorisierte Acht-Stunden-Renewal ist zum Zeitpunkt dieses Nachweises noch nicht beobachtet; deshalb wird weder eine erfolgreiche Cron-Erneuerung noch ein zweiter Pointer behauptet. PR #521 härtete getrennt sämtliche Cron-Antwortpfade mit Cache-Control: no-store. Die vollständige CI 32917107226 war grün; Merge-Commit 4edc262f568f2143f4392cff6103901fc148f6ef wurde als Vercel-Deployment dpl_BpJjyoGJ4HG2ZfS6B2vHNCsdYt6g produktiv bereitgestellt. Der anschließende anonyme Readback vom 26. August 2026 um 01:10:05 UTC bestätigte HTTP 401, Cache-Control: no-store, X-Vercel-Cache: MISS und den stabilen Fehlercode unauthorized. Damit sind Auth-Grenze und Nicht-Cachebarkeit produktiv belegt; der authentifizierte planmäßige Renewal bleibt weiterhin der oben getrennt ausgewiesene, noch nicht beobachtete Betriebsnachweis.

Betriebsvertrag

Der Release ist höchstens 24 Stunden gültig. Ein CRON_SECRET-geschützter Job erneuert ihn alle acht Stunden mit einem deterministischen UTC-Schlüssel. Das Live-Gate besitzt ab Eintritt in die 120-Sekunden-Route eine absolute 45-Sekunden-Deadline. Erst ein vollständig gültiger Live-Vertrag darf einen Candidate erzeugen. Der getrennte read-only Neon-Transport des Preflights endet ebenfalls nach 45 Sekunden, der Publish-Transport spätestens nach 105 Sekunden. Die letzten 15 Sekunden bilden Headroom für die fail-soft Cron-Telemetrie; deren harte Obergrenze bleibt das Plattformlimit. Ein bereits während der vorbereitenden Lesezugriffe abgelaufenes Live-Fenster bleibt schreibfrei. Ein abgelaufener oder unvollständiger Release öffnet keinen Legacy-Fallback.

Rights Attribution

Der separate Quellenrechte-Review bindet alle drei Fähigkeiten an die exakte sichtbare Attribution „Datenquelle: www.laerminfo.at“, Quellen- und Lizenzlink, Änderungsabgrenzung, Non-Endorsement und Screening-Hinweis.

Capabilities Contract

Unmittelbar vor jedem Publish muss der amtliche WMS die exakte Version 1.1.1 und alle acht vertraglich gebundenen 2022-Layer als queryable=1 führen. Der Publisher akzeptiert keine unbekannten Layer oder abweichende Distribution.

Coverage Contract

Die Union der amtlich publizierten Layer-BBoxen ist [9.529195722817407, 46.092518623724054, 17.608034986628898, 49.215923751587525]. Sie enthält Österreich und wird als country:AT gespeichert. Bekannte fachliche Lücken bleiben als strukturierte Gaps am Release: nur strategische Hauptquellen, IPPC nur in ausgewiesenen Ballungsräumen, berechnete Pegel in vier Metern Höhe.

Report Lookup Canaries

Vier feste, nicht personenbezogene Referenzpunkte prüfen Straße, Schiene, Flug und Industrie/IPPC jeweils für Lden und Lnight. Erwartet werden exakt:

  • Straße Wien: Lden6064 / Lnight5559
  • Schiene Wien: LdenGreaterThan75 / Lnight6569
  • Flug Wien: LdenGreaterThan75 / LnightGreaterThan70
  • IPPC Linz: Lden6064 / Lnight5559

Map Tile Canaries

Die Canaries verwenden exakt die ausgelieferte Request-Familie mit SRS=EPSG:3857, leerem STYLES=, transparenter PNG-Ausgabe und einer realen z15-Web-Mercator-BBox: Web-Lden und Web-Lnight jeweils mit 256 × 256 Pixeln sowie die statische PDF-Lden-Karte mit 512 × 512 Pixeln. Jeder kombinierte GetMap über die vier Quelltypen muss HTTP 2xx, image/png, begrenzte Größe und ein vollständig dekodierbares PNG liefern. Geprüft werden exakte Rastermaße, IHDR/IDAT/IEND-Struktur, Chunkgrenzen, CRCs, zlib-Raster und sichtbarer Inhalt; Signaturhüllen, abgeschnittene oder blanke Bilder qualifizieren keinen Release.

Legend Canaries

Je eine Lden- und Lnight-Legende für den tatsächlich von der Web-UI angezeigten ersten Schienenlayer muss HTTP 2xx, image/png, begrenzte Größe und dieselbe vollständige PNG-/Sichtbarkeitsprüfung bestehen.

Idempotenz und Aktivierung

Release-, Qualifikations- und Aktivierungs-UUID entstehen deterministisch aus dem achtstündigen UTC-Fenster. Coverage und alle sechs Pflichtchecks werden idempotent gespeichert, bevor der Kandidat qualifiziert wird. Der Active-Pointer wechselt mit Expected-Current-CAS; verlorene Acknowledgements werden aus dem Event-Ledger rückgelesen. Es entstehen keine ingest_runs. Ein Dry-Run auf einer frischen Installation ohne Registry-Zeile bleibt schreibfrei, ruft den Provider nicht auf und meldet rightsAllowed=false; eine Aktivierung bleibt in diesem Zustand fail-closed. Der Usage-Context bindet zusätzlich eine atomare Contract-Identity aus WMS-Endpunkt, Version, Source-Vintage und der kanonischen Acht-Layer-Liste. Ein alter oder driftender Release kann dadurch auch beim JSONB-Containment nicht versehentlich einen geänderten Consumer öffnen.