BAG nieuwbouw in details

Het startjaar van de simulatie (Model_StartYear) valt zelden samen met de meest actuele BAG-gegevens die beschikbaar zijn. De BAG wordt dagelijks bijgewerkt, waardoor er op het moment van modelleren doorgaans een recentere jaargang beschikbaar is dan het modeljaar. Bovendien bevat de BAG statusinformatie over objecten die nog in aanbouw zijn of waarvoor een sloop- of bouwvergunning is verleend. Het BAG-nieuwbouwmechanisme benut beide informatiebronnen om de startsituatie bij te werken vóórdat de allocatieprocedure begint. Het resultaat wordt toegepast op het eerste zichtjaar: deze ontwikkelingen hoeven niet meer door het model te worden gealloceerd.

Twee BAG-jaargangen

Het mechanisme werkt met twee BAG-snapshots:

Jaargang	In code	Beschrijving
Modeljaar	BAG_ModelJaar = BAG/Y{Model_StartYear}	De voorraad op 1 januari van het startjaar. Dit is de stand waarop de startstaat (StateBasisjaar) is gebouwd.
Recentste jaar	BAG_RecentsteJaar = BAG/Y{BAG_RecentYear}	De meest recente BAG-jaargang die in het model is geladen. Hieruit worden zowel de huidige voorraad als de toekomst-set (objecten met een bouw- of sloopvergunning) ingelezen.

Uit de recentste jaargang worden drie sets samengesteld, zowel voor verblijfsobjecten (VBO's) als voor panden:

• Voorraad: objecten met een actieve status op de peildatum.
• Alle statussen: de volledige set inclusief objecten in aanbouw en gevormd.
• Toekomst: objecten die een vergunningsstatus of ingetrokken status hebben, maar waarvan de geldigheidsdatum na de recentste jaardatum ligt en dus een toekomstige mutatie vertegenwoordigen.

Vijf mutatiecategorieën

Door de twee jaargangen met elkaar te vergelijken identificeert het model vijf categorieën mutaties. Elke categorie levert een aparte set VBO's (en bijbehorende panden) op.

Toevoegingen

#	Naam in code	Selectiecriterium	Toelichting
1	NieuwVBO_TussenModelenRecentJaar	VBO zit in voorraad van het recentste jaar maar niet in de voorraad van het modeljaar	Gerealiseerde nieuwbouw en toevoegingen die al hebben plaatsgevonden.
2	NieuwVBO_NaRecentJaarWelActief	VBO heeft in het recentste jaar de status Verblijfsobject gevormd	Objecten waarvan de bouw zo ver gevorderd is dat ze al een VBO-registratie hebben, maar die nog niet als voorraad tellen.
3	NieuwVBO_NaRecentJaar	VBO zit in de toekomst-set van het recentste jaar maar niet in de voorraad-set	Objecten waarvoor een bouwvergunning is verleend of de bouw is gestart, maar die nog niet geldig zijn, en dus geen actieve VBO-status hebben.

Onttrekkingen

#	Naam in code	Selectiecriterium	Toelichting
4	WegVBO_TussenModelenRecentJaar	VBO zat in voorraad van het modeljaar maar niet meer in het recentste jaar	Gerealiseerde sloop of onttrekking die al heeft plaatsgevonden.
5	WegVBO_NaRecentJaar	VBO zit in de toekomst-set van het recentste jaar, was voorraad, en heeft nu een ingetrokken status	Objecten waarvoor een sloopvergunning is verleend of die al gesloopt zijn volgens de toekomst-set.

Analoog worden voor panden drie vergelijkbare categorieën gedefinieerd (NieuwPand_NaRecentJaarWelActief, NieuwPand_NaRecentJaar, WegPand_NaRecentJaar), die als panddomein dienen bij het uitsmeren van de VBO-mutaties.

Per gebruiksdoel: CalcNieuwbouw_perDoel_T

Elke mutatiecategorie wordt vervolgens opgesplitst per BAG-gebruiksdoel (wonen, kantoor, logies, industrie, etc.) via het template CalcNieuwbouw_perDoel_T. Dit template:

1. Selecteert de VBO's uit een mutatiecategorie die het betreffende gebruiksdoel hebben (op basis van de CBS-gebruiksdoelclassificatie van het gerelateerde pand).
2. Koppelt elk VBO aan zijn gerelateerde pand via de gerelateerdPand-tabel, zodat pandkenmerken (woningtype, footprint, eigendomsvorm) beschikbaar zijn.
3. Berekent per VBO het aandeel in de pandfootprint: de totale footprint van het pand voor dat gebruiksdoel, gedeeld door het aantal VBO's van dat gebruiksdoel in het pand (Footprint / Vbos_InPand_perGebruiksdoel).
4. Smeert uit de resultaten naar het 25m-grid (CompactedAdminDomain) via de uitsmeertemplate.

Uitsmeren naar gridcellen: Uitsmeren_T

Objecten uit de BAG zijn puntlocaties of polygonen; het model werkt op een 25m-raster. Het template Uitsmeren_T vertaalt individuele panden naar gridcellen. Dit is nodig omdat een pand vaak meerdere gridcellen overlapt. Als een pand zonder uitsmering aan slechts één cel zou worden toegekend, zou de naastgelegen cel als leeg worden beschouwd en mogelijk onterecht worden volgebouwd.

De uitsmering werkt als volgt:

1. Vergridding naar 5m: de pandgeometrie wordt vergrid naar een 5m-raster (poly2allgrids). Panden die geen 5m-cel raken (te klein of ongelukkig gepositioneerd) worden handmatig toegevoegd op hun centroïde.
2. Toedelingsmatrix: per combinatie van pand × AdminDomain-cel wordt een toedelingsgewicht berekend. Dit gewicht is het aandeel van de 5m-cellen van dat pand dat in de betreffende 25m-cel valt.
3. Uitsmering: het aantal woningen (of footprint, of VBO's) van een pand wordt vermenigvuldigd met het toedelingsgewicht en gesommeerd per 25m-cel.

Het gevolg is dat een gridcel een fractie van een woning kan bevatten. Dit is een bewuste ontwerpkeuze: het voorkomt overschatting van beschikbare ruimte in aangrenzende cellen.

De uitsmering vindt afzonderlijk plaats voor elke combinatie van mutatiecategorie en woningtype (WP2: eengezins/meergezins, of WP4: rijtjes/twee-onder-een-kap/vrijstaand/appartement). Bij sloop (WegVBO_*) wordt bovendien onderscheid gemaakt naar eigendomsvorm (vrije sector / sociale huur, WP2×VSSH), zodat de onttrekking correct kan worden verrekend met de startstaat.

Aggregatie naar sectoren

Na het uitsmeren worden de vijf mutatiecategorieën samengevoegd tot nettomutaties per sector.

Wonen

De netto woningmutatie per WP2×VSSH-categorie per gridcel is:

Netto = NieuwVBO_TussenModelenRecentJaar (WP2→WP2×VSSH)
      + NieuwVBO_NaRecentJaarWelActief   (WP2→WP2×VSSH)
      + NieuwVBO_NaRecentJaar            (WP2→WP2×VSSH)
      − WegVBO_TussenModelenRecentJaar   (per WP2×VSSH)
      − WegVBO_NaRecentJaar              (per WP2×VSSH)

De uitsplitsing naar WP2×VSSH (woningtype × eigendomsvorm) bij toevoegingen gaat via de eigendomsstatus van het gerelateerde pand. Bij sloop is de eigendomsvorm direct bekend uit de oorspronkelijke voorraad.

De pandfootprint voor wonen wordt op dezelfde manier berekend (som van footprints van de vijf categorieën).

Werken

Voor werksectoren (Jobs6: kantoor, industrie, logistiek, etc.) wordt de netto pandfootprint per gebruiksdoel per gridcel berekend. Vervolgens wordt deze footprint gedeeld door de sectorspecifieke dichtheidsparameter (m² pandfootprint per baan) om tot een netto aantal banen te komen:

Netto banen per cel = Netto pandfootprint per cel / pandfootprint_per_baan

Wanneer de nettomutatie negatief is (meer sloop dan nieuwbouw) wordt het resultaat begrensd op minus de celoppervlakte; wanneer het positief is op plus de celoppervlakte. Dit voorkomt onrealistische uitschieters door overlappende pandgeometrieën.

Verblijfsrecreatie

Voor logiesverblijven wordt het netto aantal VBO's per cel geteld, analoog aan de woonsector maar zonder verdere typedifferentiatie.

Wind en zon

In de huidige implementatie levert de BAG-nieuwbouw geen mutaties op voor wind- en zonneparken: deze worden op nul gezet. Dit is logisch omdat windturbines en zonnepanelen geen BAG-panden of -VBO's zijn.

Toepassing op de startstaat: StartState_metBAGnieuwbouw

De nettomutaties worden opgeteld bij de oorspronkelijke startstaat per subsector per gridcel:

StartState_metBAGnieuwbouw = max_elem(StartState + BAG_nieuwbouw, 0)

De max_elem(..., 0) zorgt ervoor dat de stand niet negatief kan worden. Dit kan voorkomen wanneer meer sloop dan nieuwbouw is geregistreerd in een cel.

Correctie bij overschrijding celoppervlakte

Voor pandfootprint (zowel wonen als werken) geldt een aanvullende correctie: als de som van startstaat en BAG-nieuwbouw de celgrootte (NrMeter2PerCell) overschrijdt, wordt de bestaande stand naar beneden bijgesteld zodat het totaal op de celgrootte uitkomt. De BAG-nieuwbouw "corrigeert" in dat geval dus de oorspronkelijke startstaat. Dit kan optreden door overlappende pandgeometrieën, fouten in de BAG, of afrondingseffecten.

Subsectorbepaling

In cellen waar BAG-nieuwbouw een mutatie heeft opgeleverd, wordt via ArgMax de dominante subsector bepaald. Dit is relevant voor de initiële subsectortoewijzing van de cel in het allocatieproces.

Samenvatting van het dataproces

BAG (volledige registratie)
  │
  ├── Snapshot modeljaar (voorraad per 1 jan Model_StartYear)
  │     └── StateBasisjaar (= startstaat)
  │
  └── Snapshot recentste jaar (BAG_RecentYear)
        ├── Voorraad     ─┐
        ├── Alle statussen │──→ Vergelijking → 5 mutatiecategorieën
        └── Toekomst     ─┘         │
                                    ├── Per gebruiksdoel (CalcNieuwbouw_perDoel_T)
                                    ├── Uitsmeren naar 25m grid (Uitsmeren_T)
                                    ├── Aggregatie naar Wonen / Werken / Recreatie
                                    │
                                    └──→ StartState_metBAGnieuwbouw
                                           = StartState + nettomutaties
                                           → input voor eerste zichtjaar

Relevante bronbestanden

Bestand	Rol
BAG_Nieuwbouw.dms	Hoofdcontainer: vergelijkt jaargangen, definieert de vijf mutatiecategorieën, aggregeert naar wonen/werken/recreatie
CalcNieuwbouw_perDoel_T.dms	Template: splits mutatiecategorieën per gebruiksdoel, initieert uitsmering
Uitsmeren_T.dms	Template: vertaalt pandniveau-tellingen naar gridcellen via toedelingsmatrix
Uitsmeer_key.dms	Genereert de toedelingsmatrix (pand → 5m → 25m grid)
StartState_metBAGnieuwbouw.dms	Voegt nettomutaties toe aan de startstaat, inclusief correcties voor celgrootte
BAG.dms	BAG-inlezing en snapshotgeneratie per jaar (inclusief PerJaar_T template)