Standortvergleich (Professional-Beta)

Status: Beta, nur für eingeladene Organisationen · Roadmap-Paket PRO-01 / T06, Issue #570.

Datenmodell, API und Oberfläche sind implementiert und getestet. Sichtbar wird die Funktion nur, wenn der Betriebsschalter gesetzt ist und die Organisation in der Beta-Allowlist steht. Für alle anderen antworten Seite und API mit 404.

Mitglieder einer freigeschalteten Organisation speichern unter /workspace/vergleich mehrere österreichische Standorte und vergleichen sie anhand derselben Datenkarten wie im öffentlichen Standort-Check. Der Vergleich zeigt, welche qualifizierten Daten an welchem Standort tatsächlich verfügbar sind. Er bewertet nicht, welcher Standort besser ist.

Datenquellen

Dieselben dreizehn Karten wie beim Standort-Check (Klima, Hitzetage, Brachflächen, BEV-Parzelle, Hochwasser, Widmung, Erdbeben, Local Climate Zones, Radonpotenzial, Öffi-Anbindung, Denkmalschutz, Breitband, Wildbach und Lawine) mit ihren acht Zuständen: Treffer, kein Treffer, außerhalb der Abdeckung, Grenzfall, Datenstand veraltet, derzeit nicht verfügbar, nicht freigegeben, noch nicht angebunden. Es kommen keine eigenen Quellen, Rechte oder Regeln hinzu: Jede Zeile übernimmt den Zustand der jeweiligen Standort-Check-Karte zum Prüfzeitpunkt. Seit dem 27. September 2026 sind dort auch Widmung (Niederösterreich), Radonpotenzial, Öffi-Anbindung und Hochwasser außerhalb des Gänserndorf/Marchegg-Piloten freigegeben, seit dem 30. September 2026 zusätzlich Widmung für Wien, Denkmalschutz, Breitband und Wildbach und Lawine, seit dem 4. Oktober 2026 Widmung für Vorarlberg und seit dem 8. Oktober 2026 Widmung für Oberösterreich; ältere Snapshots zeigen den damaligen Zustand, bis der Standort neu geprüft wird. Snapshots, die vor der Hitze-, Radon-, Öffi-, Denkmalschutz-, Breitband- oder Wildbach-und-Lawinen-Karte gespeichert wurden, zeigen in diesen Zeilen „Keine Karte“, bis der Standort neu geprüft wird.

So funktioniert es

1. Standort anlegen: Adresse aus den Photon-Vorschlägen wählen (nur signierte österreichische Treffer), optional ein Label vergeben. Der Datenpass wird serverseitig geprüft und als Snapshot gespeichert.
2. Liste: alle Standorte der Organisation, neueste zuerst, mit Prüfzeitpunkt. Standorte, deren Snapshot älter als 30 Tage ist, sind als „veraltet“ markiert.
3. Matrix: Datenkarten in Zeilen, Standorte in Spalten. Zeilen, deren Standorte auf unterschiedlichen Quellenständen beruhen, sind als „unterschiedliche Quellenstände“ gekennzeichnet.
4. Neu prüfen: schreibberechtigte Mitglieder erneuern den Snapshot eines Standorts mit dem aktuellen Quellenstand; Adresse und Koordinate bleiben unverändert.
5. Löschen: schreibberechtigte Mitglieder löschen Standorte einzeln nach Inline-Bestätigung.

Wiederholen nach Timeout

Beta-Funktion: Der folgende Ablauf (Issue #596) gilt wie der gesamte Standortvergleich nur für freigeschaltete Organisationen. Er setzt voraus, dass die zugehörige Datenbankerweiterung in der jeweiligen Umgebung vollständig eingerichtet ist; andernfalls legt die Anlage keinen Standort an und antwortet mit 503 workspace_idempotency_unavailable.

Jeder bewusste Anlageversuch erhält einen eigenen Schlüssel. Dauert die Antwort zu lange oder geht sie verloren, bleibt der Versuch offen. „Denselben Versuch wiederholen“ sendet denselben Schlüssel und dieselben Eingaben erneut. Auch wenn der erste Request nach dem Timeout noch erfolgreich abschließt, entsteht für diesen Versuch höchstens ein Standort. Ein Neuladen der Seite erhält den offenen Versuch.

Der Browser hält dafür je Organisation und Tab den Schlüssel und die Anfrage mit Adresse, Koordinaten, Bundesland, optionalem Label und den Signaturen der Adressauswahl im Sitzungsspeicher (sessionStorage). Dieser Eintrag endet nach bestätigtem Erfolg, mit „Bewusst neue Anlage starten“ oder mit der Tab-Sitzung; Timeout und Seiten-Reload beenden ihn nicht. Ist der Sitzungsspeicher gesperrt, wird keine Anlage gesendet.

„Bewusst neue Anlage starten“ verwirft nur den lokalen offenen Versuch. Eine anschließende Anlage erhält einen neuen Schlüssel und kann deshalb einen weiteren Standort derselben Adresse erzeugen – auch wenn der vorherige Versuch noch erfolgreich abgeschlossen wird. Bereits gespeicherte Standorte werden durch diesen Schritt nicht gelöscht.

Rollen und Grenzen

• Alle Mitglieder der Organisation lesen; owner, admin und member legen an und löschen; viewer und external_consultant lesen nur.
• Höchstens 25 Standorte je Organisation; höchstens 75 Snapshot-Erneuerungen je Organisation und Tag.
• Kein Scoring, keine Rangfolge, keine Eignungsaussage. Fehlende Evidenz ist kein negativer Fachbefund.
• Snapshots altern; die Erneuerung erfolgt manuell je Standort, nicht automatisch.
• Standorte gehören der Organisation, nicht dem Konto. Wird das anlegende Konto gelöscht, bleibt der Standort ohne Kontobezug erhalten.

Datenschutz

Gespeichert werden Adresse, Koordinaten, Bundesland, Label, Datenpass-Snapshot, Organisation und anlegendes Konto, bis ein schreibberechtigtes Mitglied den Standort löscht oder die Organisation entfernt wird. Details unter /datenschutz#standortvergleich.

Für die Wiederholung nach Timeout (#596) kommt eine org-gebundene Kopie der ursprünglichen erfolgreichen Antwort hinzu. Sie enthält die Standortdaten einschließlich Datenpass und Zeitstempeln und bleibt bis zur Standortlöschung unverändert. Bei Standortlöschung wird diese Antwortkopie ebenfalls entfernt. Nur Organisation, Versuchsschlüssel (UUID), Hash der Eingaben sowie Anlage- und Löschzeitstempel bleiben bis zur Organisationslöschung erhalten. Dieser Sperrvermerk verhindert, dass eine alte Wiederholung einen gelöschten Standort wieder anlegt. Er enthält keine rohe Adresse und keinen Datenpass. Die oben beschriebene Kopie im Browser folgt der Lebensdauer der Tab-Sitzung beziehungsweise endet früher bei Erfolg oder bewusstem Neustart. Die Datenschutzerklärung beschreibt auch diese Verarbeitung, einschließlich der Aufbewahrungsliste (siehe Link oben).

Headless

• GET /api/v1/org/{slug}/workspace/sites, POST …/sites
• GET/DELETE …/sites/{id}, POST …/sites/{id}/refresh
• GET …/workspace/compare

Session-gebunden, nicht API-Key-fähig; Vertrag in /docs/api, sichtbar nur bei gesetztem Betriebsschalter. Entscheidung: ADR-0068.

POST-Vertrag mit Idempotency-Key (#596)

Jeder POST benötigt zusätzlich den Header Idempotency-Key mit einer UUID v4. Der Schlüssel gilt innerhalb der aktuellen Organisation. Bei Timeout oder verlorener Antwort müssen API-Clients denselben Schlüssel und dieselben fachlichen Eingaben verwenden; ein neuer bewusster Versuch erhält einen neuen Schlüssel. Der Server liefert für einen erfolgreichen Retry die ursprünglich gespeicherte Antwort, auch wenn der Standort später neu geprüft wurde.

• Gleicher Schlüssel mit geändertem Label, Adresse, Koordinaten oder Bundesland: 409 idempotency_payload_conflict.
• Mit diesem Versuch angelegter Standort inzwischen gelöscht: 410 idempotency_site_deleted; keine Wiederanlage.
• Fehlender oder ungültiger Schlüssel: 400 idempotency_key_invalid. Nach dem Vertragswechsel eine bereits offene Browserseite neu laden. Eigene API-Clients müssen den Header ergänzen und den Schlüssel für Retries aufbewahren; ein Browser-Reload passt solche Clients nicht automatisch an.
• Speicherung der Anlagebelege in der Umgebung nicht vollständig eingerichtet: 503 workspace_idempotency_unavailable; der POST legt dann keinen Standort an. Lesen und Löschen bleiben davon unberührt.

Der Vertrag ist nicht mit alten POST-Clients ohne Schlüssel kompatibel. Schlüssel laufen serverseitig nicht automatisch ab; mit der Organisation werden auch ihre Belege und Sperrvermerke gelöscht. Der Vertrag gilt nur für freigeschaltete Organisationen (Beta); die Funktion ist nicht für alle Organisationen aktiv.