Skip to content

ADR-0027: Management tabs Datenbank | Layer | Feature

  • Status: superseded by ADR-0037
  • Datum: 2026-08-27
  • Phase: Editor Management / Schema-CMS
  • Bezug: ADR-0025 (Schema-CMS Hybrid)

Kontext

Unter Management lagen Layer-Gruppen und Feature-Typen im selben Reiter Layer. In QGIS fasst ein Layer Features zusammen; die IA soll das trennen. Der Seed-Kind admin_group („Administrative Gruppe“) war Fachjargon und deckte sich nicht mit dem Reiter-Namen.

Entscheidung

  1. Drei Reiter: management_tab ∈ database | layer | feature.
  2. Seed: feature_type → Tab feature; ehemaliges admin_group → Code/Label layer / Layer im Tab layer.
  3. API-Filter ?management_tab= bleibt die einzige Partitionierung der Kind-Liste (kein Client-Full-Dump).

Begründung

QGIS-Analogie (Layer bündelt Features) und klares Wording ohne „Admin-Gruppe“. Kind-Code-Rename, weil Codes in Dialog und API sichtbar sind.

Verworfene Alternativen

Alternative Warum verworfen
Nur Label „Layer“, Code admin_group belassen Code bleibt in Dialog/API sichtbar
Feature-Tab = geo_objects-Instanzen Andere SSOT (Karte); Management bleibt Kind/Schema-CMS
Zwei Reiter belassen, nur Label ändern Keine Trennung Layer vs Feature-Typ

Folgen

  • Alembic 0009_management_feature_layer.
  • Editor-Nav und ManagementTab in Editor-Client um feature erweitert.