Tijdsdynamiek

Het RuimteScanner 2.0 model werkt niet met een enkele tijdstap, maar simuleert ruimtelijke ontwikkelingen over een reeks zichtjaren. Deze pagina beschrijft hoe de temporele structuur is opgebouwd, welke keuzen daarin zijn gemaakt en welke afhankelijkheden tussen parameters bestaan.

Basisjaar en eindjaar

Het model kent twee ankerjaaren:

• Model_StartYear (standaard: 2023): het basisjaar van waaruit de simulatie start. De stand in dit jaar — woningen, banen, pandfootprints, landgebruik — vormt de uitgangssituatie.
• Model_FirstZichtjaar (nu 2040): het eerste zichtjaar, en daarmee het tweede modeljaar na het basisjaar.
• Model_FinalYear (nu 2120): het laatste jaar waarvoor de allocatie wordt doorgerekend.

Het basisjaar heeft een dubbele functie. Het is zowel het startpunt van de allocatie als het ijkjaar voor dichtheden: de verhouding woningen per hectare en banen per m² pandfootprint in dit jaar vormt de referentie voor alle dichtheidsberekeningen in latere zichtjaren.

Relatie met inputdata

Het basisjaar moet overeenkomen met het peiljaar van de belangrijkste inputregistraties. De meest kritische koppeling is die met LISA (Landelijk Informatiesysteem Arbeidsplaatsen), vanwege de centrale rol van banendata in de dichtheidsberekening voor werken. Wanneer werken wordt meegealloceerd geldt daarom de eis dat Model_StartYear gelijk is aan LISA_StartYear. Deze eis wordt afgedwongen via een IntegrityCheck.

De achtergrond is dat de werkdichtheid (m² pandfootprint per hectare) wordt berekend als een breuk waarvan de teller (pandfootprint per subsector) uit het LISA-jaar wordt opgehaald en de noemer (hectare per landgebruiksklasse) uit het Model_StartYear. Bij ongelijke jaren is deze ratio inconsistent. Daarnaast worden banen uit LISA gekoppeld aan panden uit de BAG van het overeenkomstige jaar; bij een mismatch bevatten panden die na het LISA-peiljaar zijn gebouwd geen banen, wat de dichtheidsratio lokaal verstoort.

Andere inputregistraties (BAG, BBG, BGT, NVM) hebben hun eigen peiljaren die via parameters in ModelParameters.dms worden ingesteld. De BAG wordt ook gebruikt voor een recenter peiljaar dan het basisjaar (via BAG_RecentYear), om recente bouwontwikkelingen mee te nemen. Zie BAG nieuwbouw in details voor deze procedure.

Zichtjaren

Tussen het basisjaar en het eindjaar liggen de zichtjaren: de tijdstippen waarvoor het model een allocatie doorrekent. Het zijn hele decennia, en de set wordt dynamisch opgebouwd in Classifications/Time.dms uit drie parameters:

1. Het basisjaar zelf (Model_StartYear, nu Y2023). Dit is geen zichtjaar in de allocatie maar het startpunt.
2. Het eerste zichtjaar (Model_FirstZichtjaar, nu Y2040).
3. Tussenliggende decennia, dynamisch gegenereerd tot aan het eindjaar.
4. Het eindjaar (Model_FinalYear, nu Y2120).

In de huidige instelling zijn dat negen zichtjaren, Y2040 tot en met Y2120. Elk zichtjaar kent een voorganger (PrevYear); voor het eerste is dat het basisjaar. De allocatie voor een zichtjaar bouwt voort op de resultaten van zijn voorganger.

Dat het eerste zichtjaar instelbaar is en nu op 2040 staat, komt uit issue #658. De TIGRIS-claim voor 2030 ligt in veel regio’s onder de stand van het basisjaar, bij de banen zelfs in vrijwel alle regio’s. Het model kan geen woningen of banen slopen om een claim te halen, dus daar kon alleen overrealisatie uitkomen; zie Claimrealisatie. Met 2040 als eerste zichtjaar vervalt die klem voor het merendeel van de regio’s. De eerste allocatiestap beslaat dan zeventien jaar in plaats van zeven. De groeifactoren rekenen met de werkelijke periodelengte uit Zichtjaar/PrevYearRange_rel, dus dat gaat vanzelf goed, maar het tussenstation 2030 ontbreekt wel in de padafhankelijkheid.

De claims lopen niet zo ver door als de zichtjaren. TIGRIS levert tot en met 2060, en ModelParameters/Advanced/FromWhichDoWeKeepTIGRISconstant (2060) zorgt ervoor dat elk zichtjaar daarna de claimmap van 2060 leest. Vanaf 2070 groeit de opgave voor wonen en werken dus niet meer, en verschillen tussen varianten in die jaren komen uit de ruimtelijke sturing en niet uit extra vraag.

AlleenEindjaar

De parameter AlleenEindjaar (standaard: FALSE) bepaalt of alle zichtjaren worden doorlopen of alleen het eindjaar.

Bij TRUE springt het model direct van het basisjaar naar het eindjaar. De tussenliggende zichtjaren worden niet berekend en verschijnen niet in de GeoDMS-boom. Dit bespaart rekentijd, maar de padafhankelijkheid vervalt: verdichtings- en verdringingsmechanismen die normaal doorheen decennia doorwerken worden overgeslagen.

Bij FALSE worden alle zichtjaren sequentieel doorlopen. De resultaten van elk zichtjaar (de stand na allocatie) vormen de input voor het volgende. Dit is de volledig padafhankelijke modus.

De keuze heeft effect op de modelresultaten. Bij AlleenEindjaar=TRUE worden alle claims voor de gehele periode in een keer gealloceerd, waardoor het model meer ruimte in een keer opvult zonder tussentijdse terugkoppeling. In batchmodus wordt deze parameter aangestuurd via de omgevingsvariabele AlleenEindjaar; RunAll.cmd zet hem standaard op FALSE en vraagt of je toch alleen het eindjaar wilt.

Sequentieel doorrekenen is sinds issue #637 niet meer alleen een kwestie van nauwkeurigheid. De geschiktheid voor wonen weegt de natuur en het water mee die aan het begin van een zichtjaar liggen, en dat mechanisme doet niets wanneer er maar een zichtjaar is. Zie Geschiktheid.

Sequences en iteraties

Binnen elk zichtjaar doorloopt het model twee geneste lussen: sequences (buitenste lus) en iteraties (binnenste lus).

Iteraties

Iteraties zijn nodig om concurrentie tussen subsectoren te simuleren. In elke iteratie wordt een deel van de regionale claim voor elke subsector toegewezen aan de meest geschikte beschikbare locaties. Na elke iteratie blijven er restlocaties (waar nog niet is gealloceerd) en restclaims (regionale vraag die nog niet is vervuld) over. In de volgende iteratie worden de restclaims toegewezen aan de restlocaties.

Het aantal iteraties wordt ingesteld via Default_NrOfIters in ModelParameters.dms, en dat staat op 15. Een hoger aantal iteraties leidt tot een fijnmaziger verdeling maar een langere rekentijd. De allocatietabel kan er per regel van afwijken: wonen en werken op NVM-niveau draaien in latere sequences op 5 iteraties in plaats van op de default.

Sequences

Sequences zijn nodig om verdringing tussen sectoren op te vangen. Wanneer een sector locaties claimt waar al actoren of objecten uit een eerdere sector aanwezig waren, worden die bestaande actoren/objecten verdrongen. De verdrongen eenheden genereren restclaims die in een volgende sequence opnieuw worden gealloceerd.

Het minimale aantal sequences is 2 (Default_NrOfSequences, afgedwongen via IntegrityCheck). In de eerste sequence worden alle sectoren in volgorde gealloceerd. In de tweede sequence worden alleen de sectoren opnieuw doorlopen die in de eerste sequence verdringing hebben ondervonden (aangestuurd via UseInLaterSequences per sector-allocatieregio-combinatie).

Sectorvolgorde

De volgorde waarin sectoren worden gealloceerd is vastgelegd in de tabel SectorAllocRegio in ModelParameters.dms, niet bij de variantparameters. Elke regel noemt een sector, het regionale schaalniveau, of de sector in latere sequences opnieuw wordt doorlopen, en het aantal iteraties in de eerste en in de latere sequences. Sectoren die niet meedraaien staan als uitgecommentarieerde regel in dezelfde tabel, zodat aanzetten een kwestie is van de regel terugzetten en het rijtotaal ophogen. In de toepassing NL2120 zijn zeven regels actief:

1. Wonen op NVM-niveau, daarna COROP, daarna Provincie
2. Werken op NVM-niveau, daarna COROP, daarna Provincie
3. Waterberging op het niveau van de waterbergingsregio

Verblijfsrecreatie, zon, wind en landbouw staan daar uitgecommentarieerd. Dat is een keuze van die toepassing en geen eigenschap van het model.

Per sector wordt de allocatie op meerdere regionale schaalniveaus uitgevoerd, van fijn naar grof. Zo worden restclaims die op NVM-niveau niet konden worden vervuld, overgeheveld naar het provinciale niveau. De parameter UseInLaterSequences bepaalt per sector-regiocombinatie of de sector in latere sequences opnieuw wordt doorlopen bij verdringing.

Ontkoppeling

Het model kan in stappen worden uitgevoerd door tussenresultaten op te slaan (“ontkoppelen”) en bij vervolgberekeningen te hergebruiken. Dit is essentieel voor de rekentijd tijdens ontwikkeling en debugging.

Er zijn zes ontkoppelingsparameters:

Parameter	Stap	Wat wordt ontkoppeld
BaseDataOntkoppeld	1	Generieke, scenario/variant-onafhankelijke data
VariantDataOntkoppeld	2	Variant-specifieke pre-allocatie data
StandAllocatieOntkoppeld	3	De allocatieresultaten per zichtjaar
BAG_WP5_rel_Ontkoppeld	—	Debug: pandtype-afleidingen
OntkoppelStedelijkeKlasses	—	Debug: stedelijke functies exogeen maken
LandUseMapOntkoppeld	4	Landgebruikskaarten in indicatoren

Een parameter op TRUE zetten betekent: lees dit onderdeel van schijf in plaats van het opnieuw te berekenen. Voorwaarde is dat de ontkoppelde bestanden actueel zijn voor de huidige configuratie. Bij een volledige productierun staan alle parameters op TRUE (alle stappen eerder berekend); bij een volledige herberekening op FALSE.

Niet alle combinaties zijn geldig. In het bijzonder is het niet zinvol om VariantDataOntkoppeld=FALSE te combineren met BaseDataOntkoppeld=FALSE, tenzij ook de BaseData daadwerkelijk opnieuw moet worden gegenereerd. De geldige combinaties zijn nog niet formeel vastgelegd; het verdient aanbeveling deze in een toekomstige versie via IntegrityChecks af te dwingen.