HeatWaves Fire Statistics Data Taxonomy

This document is the single source of truth for how fire statistics data is structured in the HeatWaves application. The app consolidates data from multiple Norwegian databases that each use different terminology, filters, and granularity. This taxonomy captures those differences so every part of the system — from data ingestion to UI — stays consistent.

Why this exists

Norwegian fire statistics are spread across several independent databases (SSB, BRASK, BRIS) that were never designed to work together. Each uses its own terminology for similar concepts, and even the same database (BRIS) splits its data across multiple internal datasets with different filter capabilities. The category values within a given dimension also differ in granularity and naming between sources — what one calls a single broad category, another splits into several specific ones.

The HeatWaves application bridges this gap by mapping everything into a unified structure aligned with the EU Firestat project's harmonization framework. Readers should treat this file as the canonical narrative taxonomy; value-level tables live in category-values-by-source.md, and adapter keys live under ingestion/adapter-mappings/.

Source databases: Public data is pulled from brannstatistikk.no (BRIS) and brask.finansnorge.no (BRASK), with SSB providing aggregate totals.

How to use this document

1. Always consult this taxonomy before making assumptions about what data is available, what filters apply, or what a category is called in a given source.
2. When building UI or features, check which sources support the relevant filters — not all sources have daily data, not all can separate fire types, etc.
3. When working with categories, read category-values-by-source.md for the full list of values per source and the cross-source mappings. This is critical for building consolidation logic.
4. This taxonomy is extensible. New sources, dimensions, or characteristics may be added. Follow the existing patterns when expanding (see Expansion Guidelines at the bottom).

---

Characteristics: EU Firestat–Aligned Definitions

The four analytical dimensions used in HeatWaves are based on the EU Firestat project's recommended variables. The Firestat numbering (#) follows the final Tier 1 + Tier 2 sequence (#1–#14) in eu-firestat-final-report.md. Quick tier/variable lookup: eu-firestat-variable-cheatsheet.md. Full EU framework: same final report.

Firestat numbering (HeatWaves uses Scheme A): Variables #1–#14 are one combined sequence (Tier 1 items 1–8, then Tier 2 items 9–14). The final report lists them twice with different orderings — Executive Summary / §3.3 (Scheme A: PCF #4, IFI #12) vs §11.2 / §12 conclusions (Scheme B: PCF #7, IFI #13). Definitions in chapter 4 are the same; only position numbers differ. HeatWaves cites Scheme A everywhere. Details: eu-firestat-variable-cheatsheet.md.

On terminology: EU Firestat explicitly prefers "Primary Causal Factor" over "Fire Cause" because the direct cause of every fire is already understood — an item first ignited was exposed to a heat source long enough for combustion to occur. The interesting question is why, which is what Primary Causal Factor captures. HeatWaves uses "Primary Causal Factor" as the canonical name; underlying datasets still use "Årsak" / "Fire Cause" / "Brannårsak" / "Vurdering av hvordan brannen kan ha startet" depending on the source.

Conceptual boundary warning: The line between Heat Source and Primary Causal Factor is genuinely muddled in the source data. Several values (åpen ild, selvantennelse, naturlige fenomener) appear as Heat Source values in some sources and as Primary Causal Factor values in others. See category-values-by-source.md for the full overlap analysis — this is essential context when building consolidation logic.

---

Global Dimensions (Standard Filters)

Universal filtering dimensions that apply across the application. Not every data source supports every dimension — see the capability matrix below.

Read path: get_fire_data grain routing

Materialized charts call fire_data.get_fire_data with p_granularity. The RPC uses one fact table per request (no UNION of daily + yearly in a single aggregation):

• year → fact_yearly only. Rows must already exist from ingest; the RPC does not roll fact_daily up to years in SQL.
• day · week · month · quarter → fact_daily only, intersected with sources.supports_subyear so taxonomy yearly-only sources (e.g. SSB, BRIGADE/DSB yearly catalogs) are excluded from sub-year reads.

Schema narrative and RPC summary: conceptual-tables-and-grain.md, postgres-contract-rls-and-keys.md.

---

Fire Type Encoding Per Source

The Fire Type filter standardizes to two values across HeatWaves: CONFINED (Begrenset) and DEVELOPED (Utviklet), based on the SFPE definition — a confined fire is contained to the object or item first ignited; an DEVELOPED fire has spread beyond it.

Both BRASK and BRIS expose fire type as a native API filter parameter — you pass it when fetching data. The values differ between sources, and within BRIS they differ by dataset family.

BRASK — Type parameter (2 values)

BRIS — Oppdragstype parameter (3 or 4 values)

BRIS uses Oppdragstype as its native fire type filter — the structural equivalent of BRASK's Type parameter. The available values depend on the BRIS dataset family:

"Alle branner og ulykker" datasets (Politi Arnested, Politi Objekt) — 4 values:

"Hvordan bygningsbranner starter" datasets (DSB Arnested/Objekt/Tennkilde, Politi Årsak, Brannvesen Årsak) — 3 values:

Brann i skorstein is unique to "Alle branner og ulykker" and does not exist in any other BRIS dataset or in BRASK. It is a CONFINED-class fire type specifically for chimney fires.

Ingestion behaviour

Adapters iterate the native filter values, fetch each slice, and tag every resulting row with the standardized fire type:

• BRASK: 2 fetches per (characteristic × building type) combination, one per Type value.
• BRIS "Alle branner...": 4 fetches per characteristic, one per Oppdragstype value.
• BRIS "Hvordan...": 3 fetches per characteristic, one per Oppdragstype value.

Cross-source comparability

Standardizing to CONFINED / DEVELOPED is what makes BRASK and BRIS comparable on the fire type axis at all — without the mapping, "Kald" and "Brann i bygning" are just two unrelated strings. The standard codes are the join key.

Native values should be preserved alongside the standard mapping during ingest, so source-fidelity is retained for native drill-down (e.g. distinguishing Brann i skorstein from other CONFINED fires inside Politi Sub-A) while cross-source queries use the standardized codes.

SSB has no fire type information at all — it cannot participate in fire-type-filtered comparisons.

---

Data Sources & Capabilities

1. SSB (Statistics Norway)

• Datasource ID: ssb
• Coverage: Total building fires, total dwelling fires (aggregate counts only)
• Original dataset titles: Bygningsbranner · Boligbranner
• Characteristics: None — SSB provides aggregate totals without breakdowns by cause, origin, etc.

Dataset count: N/A (aggregate data)

---

2. BRASK (Finance Norway / Insurance)

• Datasource ID: brask
• Origin: brask.finansnorge.no — insurance industry reporting
• Coverage: Insurance-reported fires with detailed characteristics
• Characteristics provided: Heat Source, Primary Causal Factor

Dataset count: 8 for Kilde and Årsak (2 characteristics × 2 fire types × 2 building types). Bygningsalder is additional — see below.

BRASK: Bygningsalder (Building Age)

BRASK provides a building-age breakdown as a separate dimension. This is BRASK-only — no other source carries building age.

The public Utforsk UI measures age since construction (discrete year bands: Ny, 1-5, 6-10, …), not construction-era calendar buckets (e.g. “before 1900”). Option ids and labels are mirrored in BRASK_EXPLORER_DIMENSIONS_JSON.dimensionValues.bygningsalder.

HeatWaves status: Bygningsalder is implemented as the building_age filter axis (building_age_code on fire_data facts). The BRASK adapter sets lbAldersgruppe from registry filter ids when fetching. Category identity (cat_code, standard_code, collapse rules such as Ny and 1-5 → 0-5) and the native → bucket table live in category-native-to-cat-code.md §7 and filter-axes-native-to-filter-id.md §3. Analytical dim_code = 6 denotes Bygningsalder in fire_data.categories. BRASK_AXIS.bygningsalder (12) in _braskWebForms.constants.ts is the BRASK Utforsk explorer axis index / ddlRad id for that dropdown — not the same integer as categories.dim_code for this characteristic.

Cross-tabulation note: BRASK’s API can cross-tabulate Bygningsalder with Kilde or Årsak. HeatWaves ingests breakdowns per configured slice rather than materializing every cross-tab in the fact table; see adapter docs if extending that behaviour.

Filter compatibility: Bygningsalder can be combined with the same Fire Type (Kald/Varm) and Building Type filters as Kilde and Årsak.

---

3. BRIS (DSB — National Fire Incident Reporting System)

BRIS is the national fire incident reporting system operated by DSB (Direktoratet for samfunnssikkerhet og beredskap / Directorate for Civil Protection). Public access is via brannstatistikk.no.

BRIS Internal Structure

BRIS is not a single dataset — it exposes data through two distinct underlying datasets, each with different filter capabilities and content. This is the reason Police data appears split into two sub-groups in HeatWaves:

This means a single conceptual "BRIS source" actually spans three data-providing entities (Police, Fire Brigade, DSB) reporting through two different datasets. HeatWaves models them separately to preserve transparency.

---

3.1 Datasource: Police

Police-reported data appears across both BRIS underlying datasets, which is why filter capabilities differ between Sub-Groups A and B.

Sub-Group A: Location & Item (from "Alle branner og ulykker")

Dataset count: 8 (2 characteristics × 2 standardized fire types × 2 building types). Native fetches are 16 per characteristic combination (4 Oppdragstype × 2 building) — these get standardized to two fire type codes at ingest.

Sub-Group B: Causality (from "Hvordan bygningsbranner starter")

Dataset count: 2 (1 characteristic × 2 standardized fire types). Native fetches are 3 per characteristic.

---

3.2 Datasource: Fire Brigade (from "Hvordan bygningsbranner starter" only)

Fire Brigade has exactly one dataset, providing fire-officer-assessed causality.

• Datasource ID: fire_brigade (within BRIS)
• Original dataset title: Brann og redningsvesenets vurdering av hvordan brannen kan ha startet
• Characteristic provided: Primary Causal Factor

Dataset count: 2 (1 characteristic × 2 standardized fire types). Native fetches are 3.

Important: Fire Brigade does NOT appear in "Alle branner og ulykker". There is no Brigade-attributed Oppdragstype, Arnested, or Objekt dataset. Police is the only data-providing entity in "Alle branner og ulykker".

---

3.3 Datasource: DSB (from "Hvordan bygningsbranner starter")

• Datasource ID: dsb (within BRIS)
• Characteristics provided: Area of Origin, Item First Ignited, Heat Source

Dataset count: 6 (3 characteristics × 2 standardized fire types). Native fetches are 9 per characteristic.

---

Characteristic Coverage Matrix

Quick reference for which sources provide which characteristic. Read this together with the filter capabilities tables above.

Oppdragstype is intentionally not listed as a characteristic. It is BRIS's native fire type filter parameter (the structural equivalent of BRASK's Type), not a fire-incident characteristic like Arnested or Objekt. See §Fire Type Encoding for its values and standard mapping.

---

Dataset Count Summary

Counts use standardized fire types (CONFINED + DEVELOPED = 2). Native BRIS fetches are larger because Oppdragstype has 3 or 4 values per dataset family — those are aggregated to 2 standardized fire types at ingest.

---

Expansion Guidelines

When adding a new data source, dimension, or characteristic:

1. Add the source to the capability matrix above, documenting all filter support and original dataset titles.
2. Add its characteristics to the Characteristic Coverage Matrix.
3. Add the full category values to category-values-by-source.md, including cross-source mappings where overlaps exist. Use the existing ✓ exact / ≈ partial / ✗ source only mapping convention.
4. Update the Dataset Count Summary.
5. If the new source introduces a new global dimension (beyond Time / Fire Type / Building Type), add it to the Global Dimensions table and document which existing sources support it.
6. If a new characteristic is added, align its name and definition with the EU Firestat framework where possible. Note its Firestat number if one exists.