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_FinalYear (standaard: 2050): 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. De standaard zichtjaren zijn decennia: 2030, 2040, 2050. De set wordt dynamisch opgebouwd in Classifications/Time.dms op basis van Model_StartYear en Model_FinalYear.

De reeks van zichtjaren is als volgt opgebouwd:

1. Het basisjaar zelf (Y2023) — dit is géén zichtjaar in de allocatie, maar dient als startpunt.
2. Het eerste vast anker (Y2030).
3. Tussenliggende decennia (Y2040, etc.), dynamisch gegenereerd.
4. Het eindjaar (Y2050).

Elk zichtjaar kent een voorganger (PrevYear). Voor het eerste zichtjaar (Y2030) is dat het basisjaar; voor Y2040 is dat Y2030, enzovoort. De allocatie voor een zichtjaar bouwt voort op de resultaten van zijn voorganger.

AlleenEindjaar

De parameter AlleenEindjaar (standaard: TRUE) 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 2023–2050 in één keer gealloceerd, waardoor het model meer ruimte in één keer "opvult" zonder tussentijdse terugkoppeling. In batchmodus wordt deze parameter aangestuurd via de omgevingsvariabele AlleenEindjaar.

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 (standaard: 10). Een hoger aantal iteraties leidt tot fijnmaziger verdeling maar langere rekentijd. Voor de meeste toepassingen zijn 10 iteraties voldoende om claims nagenoeg volledig te realiseren.

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 VariantParameters/SectorAllocRegio. De standaard volgorde is:

1. Wonen (op NVM-niveau, daarna Provincie)
2. Werken (op NVM-niveau, daarna Provincie)
3. Verblijfsrecreatie (op Provincie-niveau)
4. Zon (op Provincie-niveau)
5. Wind (op Provincie-niveau)

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.