EN Scenarios and policy variants
This is an English translation of the Dutch page Scenario’s en beleidsvarianten, which is leading. Translated on 8 November 2026 from wiki commit 428045e.
Back to Home
RSopen never computes a single future, but a combination of a scenario and a variant. This page describes that structure. Which scenarios and variants exist belongs to the application and not to the model; see Part III for the applications and their names.
Scenario, variant and case
A scenario describes the environment in which the model computes: how many dwellings, jobs and other functions are added, and where that demand ends up regionally. The claims come from outside, usually from TIGRIS XL, and differ per scenario.
A variant describes policy and design: where building is and is not allowed, which locations get priority, how densely is built, which measures apply and what is imposed exogenously. A variant therefore does not change how much has to happen, but where and how it happens.
The combination of the two is called a case, with a name of the form <scenario>_<variant>, for example WLO_hoog_BAU. All results and indicators are stored per case.
Variants are project-specific. The Ruimtelijke Verkenningen 2023 worked with four environmental scenarios and with variants called Intensiveren and Transformeren; the pilot application Friesland used a variant Water en Bodem Sturend; NL2120 computes with BAU, BAU2, NbSGenuanceerder and NbSGenuanceerd. Where a variant name is mentioned in this wiki, it is therefore an example from an application.
Where the variant settings are
| Part | Where | What you set with it |
|---|---|---|
| Variant parameters | VariantParameters/VariantK.dms | A table with a column per variant: restrictions, building regimes per flood hazard zone, density factors, water management, claim sources and the settings of the indicators |
| Rungs | VariantParameters/Tredes/ | Which location types get priority, per sector and subsector. A variant chooses a rung set with Trede_Variant; the name of that set does not have to be equal to the name of the variant |
| Development packages | VariantParameters/Ontwikkelpakketten/ | What a residential neighbourhood looks like: density, construction method, sealed surface, greenery and water |
| Exogenous imposition | Templates/VariantData_T.dms and SourceData/Grondgebruik/Natuur.dms | Which nature and water map a variant imposes, and which areas are locked |
| Claims | SourceData/RSopen/Claims through ModelParameters/TIGRIS_filedate | Which claim set, and which scenario variant within it, is read |
Part of the settings is deliberately not set per variant but in ModelParameters: the reference years of the source data, the study area, the base year and the final year, and the choice of which sectors are allocated at which level. These apply to all variants of an application.
What a variant can change
The four places where a variant intervenes, in the order in which the model meets them:
- Availability. The sieve determines where a sector can go. Restrictions, building regimes and the selection of evidently in use are variant settings. See Availability.
- Suitability. The rungs determine the coarse order of preference, the empirical component the fine order. Only the rungs depend on the variant. See Suitability.
- Density and layout. The development packages and the density factors determine how many dwellings come per hectare and how the neighbourhood is laid out. See Density.
- Exogenous imposition. What a variant puts down itself, nature and water, precedes the allocation and is kept free afterwards.
The claims themselves belong to the scenario. When a variant cannot build somewhere, that claim does not disappear: it comes back as a residual claim and is realised elsewhere. See Overflow (in Dutch).