Zum Inhalt

Districts and buildings data model

The district is the demand side of your study. It is the geographic zone you are designing for, the buildings inside it, and the climate that drives their loads. Almost everything you do in TESSA — sizing a network, dispatching heat sources, calculating CO₂ — starts from the district and the buildings it contains.

This page describes what a district is made of, what TESSA stores for each building, and how the GIS overlays you draw or import fit alongside. For the project/scenario container above, see Projects, scenarios, and the data model. For the network you build on top, see Networks and heat sources data model.

A district at a glance

A scenario typically contains one district — the area you are studying — but you can have several inside the same scenario if you want to model disconnected zones together (for example, two neighbourhoods that might or might not be linked by a future trunk pipe).

flowchart TD SC["📄 Scenario"] --> D["🗺️ District"] D --> B["🏠 Buildings"] D --> CL["🌤️ Climate"] D --> N["🔥 Thermal network"] D -.has.-> BD["Boundary polygon"] D -.has.-> LC["Aggregate hourly<br/>load curve"] D -.has.-> CY["Calculation year"] classDef scenario fill:#c5cae9,stroke:#000072,stroke-width:2px,color:#000072 classDef district fill:#a5d6a7,stroke:#1b5e20,stroke-width:2px,color:#1b5e20 classDef demand fill:#e8f5e9,stroke:#2e7d32,stroke-width:1.5px,color:#1b5e20 classDef thermal fill:#fff3e0,stroke:#ED6000,stroke-width:1.5px,color:#bf360c classDef attr fill:#ffffff,stroke:#2e7d32,stroke-width:1px,color:#1b5e20,stroke-dasharray:3 3 class SC scenario class D district class B,CL demand class N thermal class BD,LC,CY attr

Things to know when you set up a district:

  • The boundary is the geographic extent of the study area. By default it is the convex hull of the buildings you load in, but you can replace it with a manually-drawn polygon if you want to constrain the area more tightly (for example, to follow a municipal boundary).
  • The calculation year is the reference year for the demand and climate calculations. It also anchors degradation, indexation, and depreciation in the financial model.
  • The aggregate load curve is the hourly demand the district imposes on the network. It is the sum of every connected building's load curve and is what the simulator dispatches sources against.
  • The CRS and local UTM zone are computed automatically from the boundary so distances and areas come out right. You don't usually need to think about them, but they do affect things like pipe length once you start designing.

What TESSA stores for each building

The building is the smallest unit that carries demand, equipment, and emissions in TESSA. Most of what you see in reports and dashboards is rolled up from these per-building values.

flowchart LR B["🏠 Building"] ID["Identity<br/>━━━━━━━━<br/>National ID<br/>Address<br/>Geometry"] PH["Physical<br/>━━━━━━━━<br/>ERA (m²)<br/>Number of floors<br/>Construction period<br/>Construction class<br/>Altitude"] DH["Heating &amp; DHW<br/>━━━━━━━━<br/>Annual demand (kWh)<br/>Intensity (kWh/m²)<br/>Peak power (kW)<br/>Supply temperatures"] DC["Cooling<br/>━━━━━━━━<br/>Annual demand<br/>Peak power<br/>Supply temperature<br/>is_cooled flag"] EQ["Existing equipment<br/>━━━━━━━━<br/>Heat generator type<br/>Fuel<br/>Cooling generator<br/>Cooling fuel"] EM["Emissions<br/>━━━━━━━━<br/>CO₂eq<br/>NOx, CO, SOx<br/>PM10, PM2.5"] B --- ID B --- PH B --- DH B --- DC B --- EQ B --- EM classDef building fill:#a5d6a7,stroke:#1b5e20,stroke-width:2px,color:#1b5e20 classDef field fill:#e8f5e9,stroke:#2e7d32,stroke-width:1.5px,color:#1b5e20 class B building class ID,PH,DH,DC,EQ,EM field

A few practical notes:

  • National identifier. In Switzerland this is the EGID. It is what TESSA uses to join your buildings to authoritative datasets — energy reference area from the cantonal register, addresses, alti­tude — and what you should preserve when you bring data in from your own sources.
  • Heating and hot water are separate. The model carries them as q_h (space heating) and q_ww (domestic hot water), and a combined q_hww for convenience. Each has both an annual figure (kWh) and an intensity (kWh/m²), and each has an associated peak hourly power used for sizing. Cooling (q_c) is a third channel.
  • Existing equipment is what's installed today. It is what the baseline emissions calculation uses, and it is what the comparison view contrasts against the district-heating alternatives in your scenarios. If you connect the building to a network in a scenario, the existing-equipment figures still describe the counterfactual.
  • Each building has its own supply temperatures. They drive how the building is connected (direct, via heat exchanger, or via a booster heat pump on a low-temperature network) — see Network generations.

For where each value comes from in practice — measured, modelled, defaulted — see Building data origins.

Climate

Climate is attached to the district one-to-one. It is a time series, not a single number, and it underpins both the demand calculation (heating and cooling degree days) and the simulation of any heat pumps that depend on ambient temperature.

flowchart LR D["🗺️ District"] -->|1:1| CL["🌤️ Climate"] CL --> TS["Hourly time series<br/>━━━━━━━━<br/>Ambient temperature<br/>Smoothed daily / 3-day means"] CL --> DG["Aggregates<br/>━━━━━━━━<br/>Heating degree days<br/>Cooling degree days<br/>Temperature bins"] classDef district fill:#a5d6a7,stroke:#1b5e20,stroke-width:2px,color:#1b5e20 classDef climate fill:#bbdefb,stroke:#0d47a1,stroke-width:2px,color:#0d47a1 classDef field fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#0d47a1 class D district class CL climate class TS,DG field

In present-day mode, the climate series is loaded from a meteorological reference station near the district. To run a future-climate study, you swap in a transformed series for a target year — see Future climate. The buildings and their demand intensities stay the same; what changes is the temperature time series, which the model then propagates through degree days to annual demand and through the hourly perturbation method to the load curve.

GIS overlays

Alongside the buildings, a scenario carries a set of map overlays that you draw, import, or compute. They are not strictly part of the demand model but they are how you tell TESSA where to look, what to include, and what to leave out.

flowchart TD SC["📄 Scenario"] SC --> RZ["✏️ Region<br/>(study area polygon)"] SC --> EZ["🚫 Exclusion zones<br/>(no-build areas)"] SC --> BSEL["🏠 Building selections<br/>(filter / cluster results)"] SC --> IMP["📥 Imported layers<br/>(GeoJSON, your data)"] SC --> RW["🛣️ Streets<br/>(used for pipe routing)"] classDef scenario fill:#c5cae9,stroke:#000072,stroke-width:2px,color:#000072 classDef gis fill:#f3e5f5,stroke:#6a1b9a,stroke-width:1.5px,color:#4a148c class SC scenario class RZ,EZ,BSEL,IMP,RW gis

What each is for:

  • Region. The polygon you draw to delimit the study area. The "create district from region" tool uses it to pull in the buildings inside.
  • Exclusion zones. Polygons where pipes are not allowed to run — protected areas, planned construction sites, river crossings without a feasible solution. The auto-layout tool routes around them.
  • Building selections. Whenever you filter or cluster buildings in the UI, the result is a saved selection you can reuse — for example, "all multi-family buildings built before 1980, ERA above 1000 m²" — when you point a tool at a subset of the district. See Filter and cluster buildings.
  • Imported layers. Anything you bring in from outside — heat plans, planning constraints, ownership polygons — kept on the map so you can use it as context or as input to TESSA's spatial tools.
  • Streets. A road network overlay. The auto-layout and routing tools constrain pipe paths along streets when this is loaded. Without it, layout tools can produce direct point-to-point connections that don't respect road geometry.

How a district gets populated

A district is built up in stages. The flow below shows the order; the create-district workflow walks each step in detail.

flowchart TD A["✏️ Define area<br/>region polygon"] --> B["🏠 Load building base data<br/>national register / GeoJSON / table"] B --> C["🌤️ Load climate"] C --> D["🔥 Apply heat demand model<br/>annual energy, intensities,<br/>peak power"] D --> E["❄️ Apply cooling model<br/>(if any cooling)"] E --> F["📈 Generate hourly<br/>load curves"] F --> G["✅ District ready<br/>for network design"] classDef step fill:#e8f5e9,stroke:#2e7d32,stroke-width:1.5px,color:#1b5e20 classDef done fill:#a5d6a7,stroke:#1b5e20,stroke-width:2px,color:#1b5e20 class A,B,C,D,E,F step class G done

By the time the district is "ready":

  • Every building has its annual heating, hot-water, and cooling demands populated, plus the corresponding peak powers used for sizing.
  • Every building has an emissions figure for its current equipment, against which network alternatives can be compared.
  • The district has its hourly aggregate load curve — the curve the network simulator works against.

At this point you can start designing a network on top of it. See Networks and heat sources data model for what comes next.

Where to go next