Skip to content

ADR-0029: Editor Filteransichten (lokal pro Projekt)

  • Status: accepted
  • Datum: 2026-08-27
  • Phase: Editor Kartenansicht
  • Bezug: ADR-0001 (OpenLayers + MVT), ADR-0004 (Editor online), Layer-Context-Prefs im Editor

Kontext

Kartenarbeiter brauchen benannte, wiederanwendbare Filter über Layer-Sichtbarkeit und Feature-Attribute (Ansicht → Filter → Management / Anwenden / Lösen). Die Werte sind Anzeige-Präferenzen, kein Fachdatenbestand.

Entscheidung

  1. Filteransichten sind lokal pro project_id im Tauri Store (settings.json) bzw. Browser-Prefs gespeichert — gleiches Muster wie Layer-Context.
  2. Eine Ansicht enthält layerKeys (MVT-Overlay-Keys) und Attributregeln auf Tile-Properties (kind, stage, label; Ops eq / neq / contains).
  3. Anwenden wählt eine oder mehrere Ansichten (Session-State); Anzeige ist die OR-Vereinigung der Views. Lösen stellt die vorherige Layer-Sichtbarkeit wieder her.
  4. Filterung erfolgt clientseitig im Overlay-Style (wie Hide-by-id) — kein Feature-Dump, keine Server-API.

Begründung

Display prefs gehören nicht in die PostGIS-SSOT. MVT liefert bereits die filterbaren Attribute; Style-Time-Hide skaliert mit dem Viewport. Mehrere angewendete Views OR-kombiniert entsprechen „welche angezeigt werden“.

Verworfene Alternativen

Alternative Warum verworfen
Server-Tabellen pro User/Projekt API-, Auth- und Sync-Aufwand ohne fachliche SSOT-Rolle
Filter auf Schema-CMS-Felder Nicht in MVT; bräuchte Tile-Erweiterung oder ID-Listen-Query
Genau eine aktive Ansicht (Radio) Weniger flexibel als Multi-Select mit OR
Tiefe Menü-Checkboxen unter Filter Menü-Nesting im Editor stoppt bei einer Submenü-Ebene

Folgen

  • Editor: FilterView-Modell, Prefs, Management-/Anwenden-Dialoge, Map-Wiring.
  • Spätere Server-Sync oder erweiterte Tile-Attribute wären ein neues ADR.