SWMMVis  6.0.0-alpha.4
Qt6/C++ GIS-based graphical user interface for the SWMMVis engine (6.0.0-alpha.4)
Loading...
Searching...
No Matches
auxiliarystoragespec.h File Reference

Typed config for the Layer Properties → Auxiliary Storage tab (Slice Z.15). More...

#include <QJsonObject>
#include <QString>
Include dependency graph for auxiliarystoragespec.h:
This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Classes

struct  OpenSWMM::Render::AuxiliaryStorageSpec
 Per-layer auxiliary-storage configuration. More...
 

Namespaces

namespace  OpenSWMM
 
namespace  OpenSWMM::Render
 

Detailed Description

Typed config for the Layer Properties → Auxiliary Storage tab (Slice Z.15).

Author
Caleb Buahin caleb.nosp@m..bua.nosp@m.hin@g.nosp@m.mail.nosp@m..com
Date
2026
License\n GPL-3.0-or-later

RENDERING_RULE_MODEL_PLAN.md §11.4 — per-feature manual style overrides persisted to a sidecar SQLite DB. Use cases:

  • "This one junction is highlighted red because I'm investigating it"
  • "These three conduits are dashed because they're proposed not built"

Overrides survive Rule edits — they're a layer above the Rule List. The DB stores (feature_id, property_path, value_or_expression) tuples; render path consults it after Data-defined overrides.

The spec itself is small: a toggle plus the sidecar DB path. The override rows themselves don't live in this spec — they're managed at runtime by the auxiliary-storage tab UI and persisted through SQLite. The spec just tells the layer "here's where to find the DB" and "is it active right now."

Slice Z.15-data ships the value type + JSON round-trip. The SQLite schema + tab UI + runtime override application are separate slices (Z.15-db, Z.15-ui, Z.15-paint).