De trede-voorrang van plancapaciteit vervalt nooit, en de rest van de ladder staat op het basisjaar stil

[jipclaassens]

De vervaldatum PlancapaciteitGeldigTotEnMet werkt sinds #682 op de hele zeef. De trede valt daarbuiten, en daar weegt plancapaciteit zwaarder dan in de zeef.

Waar het zit

De trede-assen worden in cfg/main/Templates/VariantData_T/Trede.dms:63-113 opgebouwd, in VariantData en dus zichtjaaronafhankelijk. De ladders staan in cfg/main/VariantParameters/Tredes/Wonen.dms:27 en :94 en in cfg/main/VariantParameters/Tredes/Werken.dms:31, :89 en :124. Ze worden verzilverd in cfg/main/Templates/Allocatie/IterSubsector_T.dms:80-83 en cfg/main/Templates/Allocatie/IterSubsector_T_Wonen.dms:86. Daarnaast staat er een tweede, losse plancapaciteitsvoorrang in IterSubsector_T.dms:68-73, in de keuze tussen werksubsectoren die dezelfde cel boven hun zaaglijn hebben.

Hoe zwaar de as weegt

Drie dingen bepalen dat samen, en ik heb ze alle drie nagelopen.

Ten eerste de volgorde binnen de ladder. Trede_T.dms:82 kiest met ArgMin de laagst genummerde klasse die waar is, dus de rijvolgorde van de combine-unit is de voorrangsvolgorde.

Ten tweede welke as het zwaarst weegt. In combine(A, B) varieert het eerste argument het langzaamst. Gemeten met een losse dms op GeoDms20.17.0.m, drie bij twee:

rij 0: a0_b0   rij 2: a1_b0   rij 4: a2_b0
rij 1: a0_b1   rij 3: a1_b1   rij 5: a2_b1

Het eerste argument is dus het zwaarste cijfer. PlancapaciteitPlusStimuli staat bij wonen vooraan, en bij nijverheid en logistiek ook.

Ten derde hoe hard de trede de geschiktheid overstemt. IterSubsector_T.dms:83 maakt er een strikt lexicografische ordening van, met TredeScore * Geschiktheid_Ordered_range + Geschiktheid_Ordered en Geschiktheid_Ordered_range = max(Geschiktheid_Ordered) + 100. Een cel in een hogere trede gaat dus altijd voor op elke cel in een lagere trede, ongeacht de geschiktheid.

Per subsector:

subsector	ladder	positie plancapaciteit
wonen, alle vier de varianten	Tredes/Wonen.dms:27 en :94	eerste as
nijverheid en logistiek	Tredes/Werken.dms:124	eerste as, en de ladder heeft er maar twee
de drie verzorgende subsectoren	Tredes/Werken.dms:31	tweede as, onder WoongebiedK
zakelijke dienstverlening	Tredes/Werken.dms:89	tweede as, onder BestaandKantoorK

De as zelf is een union_unit van vier klassen op volgorde: binnen hard plan, binnen zacht plan, binnen stimuli, daarbuiten (Tredes.dms:100). Voor wonen telt de ladder 144 treden, en 216 in NbSGenuanceerd omdat BBGK daar vervangen is door BBGPlusKansrijkWoningbouw. Harde plannen bezetten daarmee de bovenste 36 respectievelijk 54 treden.

Waarom dit niet klopt

Een hard plan is een onherroepelijk bestemmingsplan of een verleende vergunning. Dat is een uitspraak met een looptijd van jaren, niet van een eeuw. Het model kiest in 2120 nog steeds bij voorrang een locatie omdat een gemeente daar in 2023 een plan had liggen, en dat is een patroon dat geen enkele provincie of gemeente terugkent. Sinds #682 vervalt de restrictievrijstelling wel vanaf Y2060, dus de twee mechanismen die op dezelfde plankaart leunen spreken elkaar nu tegen.

De bovenste trede eet zichzelf ook niet leeg. Afgelezen op de bestaande BAU-uitdraai van Y2050 uit de productiereeks, niet vanavond opnieuw gedraaid: van de 24.369 ha harde wonen-plancapaciteit was aan het eind van Y2050 ongeveer 9.658 ha gealloceerd en ruim 14.700 ha nog niet. Een vervaljaar zet de rangorde daar dus echt om.

Het grotere punt eronder

De hele ladder staat op het basisjaar stil, niet alleen de plancapaciteit-as. Trede.dms:141 leest BBG uit BaseData, :158-173 de OV-bereikbaarheid, :133-139 het eigendom en :180 het bouwterrein. Geen van die assen wordt bijgewerkt met wat het model zelf bouwt. Een wijk die het model in 2040 neerzet is in 2050 nog steeds geen bestaand bebouwd gebied en telt daar dus nog steeds als uitbreiding.

Alleen de plancapaciteit-as laten vervallen repareert een van de vijf assen. Dat is wel de as met de grootste sprong, want hij staat vooraan, maar het betekent dat de ladder vanaf 2060 volledig op de wereld van 2023 blijft rusten.

Wat ik ga doen

De basisjaarzeef kreeg bij #682 een tweede uitkomst naast de eerste, en de zichtjaarzeef kiest er per zichtjaar een van. Voor de trede kan hetzelfde: een tweede trede-container waarin de plancapaciteitsvlaggen in Trede/src op FALSE staan, en IterSubsector_T die er per zichtjaar een van kiest via het meta-item TredeK op :37. Ik heb het idioom container src_zonder := src { <overschrijvende items> } los getoetst en dat werkt: het overschreven item volgt de nieuwe definitie, de rest wordt geerfd.

De cellen zakken dan binnen dezelfde BBG-, OV-, eigendoms- en grondgebruikcombinatie naar de stimuli-trede of de restcategorie. Bij wonen is dat een sprong van trede 0 tot 35 naar 72 tot 143. Bij nijverheid en logistiek blijft er van de ladder vrijwel niets over, want daar is plancapaciteit de enige inhoudelijke as; de plek van nieuwe bedrijventerreinen wordt dan volledig door de empirische geschiktheid bepaald. Dat laatste is een grotere ingreep dan bij wonen en zet ik daarom achter dezelfde vervaldatum maar met een aparte schakelaar.

Openstaande punten

• moet de trede-voorrang met dezelfde vervaldatum uitfaseren als de restrictievrijstelling, of met een eigen jaartal?
• geldt dat ook voor nijverheid en logistiek, waar de ladder daarmee tot twee treden terugvalt?
• moet de tweede voorrang in IterSubsector_T.dms:68-73, de keuze tussen werksubsectoren, dezelfde vervaldatum krijgen?
• moeten de vier andere trede-assen dynamisch worden gemaakt, te beginnen bij BBG? Dat is een eigen verbouwing en niet in dit issue meegenomen.

[jipclaassens]

Gebouwd in a6dca33, achter de schakelaar TredeVolgtPlancapaciteitVervaldatum in ModelParameters/Advanced. Die staat op FALSE, dus de uitkomst verandert vandaag niet.

Hoe het werkt

Dezelfde vorm als de reparatie van #682. De tredes worden in VariantData gebouwd en kennen het zichtjaar niet, dus staan er nu twee opbouwen klaar en valt de keuze bij de afnemer:

• Templates/VariantData_T/Trede.dms heeft naast src een src_ZonderPlancapaciteit, waarin elke Binnen-vlag op FALSE staat en elke Buiten-vlag op TRUE, en naast SectorxSubsectoren een SectorxSubsectoren_ZonderPlancapaciteit die daarop is opgebouwd.
• Templates/Allocatie/IterSubsector_T.dms en IterSubsector_T_Wonen.dms kiezen per zichtjaar met TredeContainer, op dezelfde vervaldatum PlancapaciteitGeldigTotEnMet.
• De tweede plancapaciteitsvoorrang, SubsectorKeuzePrioriteit in IterSubsector_T, volgt via TredeSrc dezelfde keuze. Dat was een openstaand punt hierboven en zit er dus in.

Met de schakelaar uit wijst alles naar de bestaande containers en komt de tweede opbouw niet in de boom, dus hij kost dan ook niets.

Een bevinding die de bouwvorm bepaalde

Alle 57 plancapaciteitsvlaggen staan expliciet in src_ZonderPlancapaciteit, niet alleen de zeven die rechtstreeks uit SourceData lezen. Dat is nodig omdat overerving in GeoDMS early binding is. Gemeten in een losse dms op GeoDms20.17.0.m:

container src          { Blad := TRUE;  Afgeleid := !Blad; }
container src_zonder := src { Blad := FALSE; }

src_zonder/Afgeleid blijft dan FALSE en niet TRUE: het geerfde afgeleide item leest het blad van de oorspronkelijke container en niet de override. Alleen de bladeren overschrijven zou dus stilletjes niets doen aan BuitenPlancapaciteitWonen en de andere dertig afgeleide vlaggen. Dat is het soort fout dat geen foutmelding geeft, dus die hoort in de valkuilenskill.

Gemeten

Met de schakelaar aan, wonen eengezins vrije sector in BAU, op AllocDomain:

maat	met plancapaciteit	zonder
aantal treden	144	144
cellen in het harde-planblok, trede 0 tot 35	22.565	0
cellen in het planblok, trede 0 tot 71	40.804	0
cellen die van trede veranderen	40.804

De ladder houdt dus zijn cardinaliteit en alleen de bovenste twee klassen van de plancapaciteit-as lopen leeg. 40.804 hectare zakt vanaf Y2060 naar de stimuli-trede of de restcategorie.

Ter controle: het aantal cellen in het harde-planblok, 22.565, is precies gelijk aan het areaal van de harde wonen-plancapaciteit op AllocDomain in diezelfde configuratie. Dat is wat het hoort te zijn en het bevestigt dat de as leest wat hij moet lezen.

Wat ik niet heb gedaan

De vier andere trede-assen zijn niet aangeraakt. BBG, de OV-bereikbaarheid, het eigendom en het bouwterrein staan nog steeds op het basisjaar stil en worden niet bijgewerkt met wat het model zelf bouwt. Deze schakelaar repareert dus een van de vijf assen, en dat is bewust: een dynamische BBG-as is een eigen verbouwing met eigen gevolgen voor de binnenstedelijkheidsmaat.

Ik heb ook geen allocatie gedraaid. Wat 40.804 hectare aan verplaatste voorrang met het ruimtelijk patroon doet is daarmee niet gemeten; daarvoor zijn twee reeksen nodig, met en zonder, vanaf Y2060.

Tot slot heb ik voor nijverheid en logistiek geen aparte schakelaar gemaakt, zoals ik hierboven aankondigde. Het mechanisme is identiek en een tweede schakelaar zou alleen een dekkingslijst zijn; wie die twee subsectoren wil uitzonderen kan dat met een sectornaamtoets in TredeContainer doen. Wel blijft staan dat de ingreep daar het zwaarst is, want daar is plancapaciteit de enige inhoudelijke as van de acht treden.

Openstaande punten

• mag TredeVolgtPlancapaciteitVervaldatum aan in de productiereeks, of eerst een tegenfeitelijke run vanaf Y2060?
• moeten nijverheid en logistiek erbuiten blijven, gezien de ladder daar tot twee treden terugvalt?
• moeten de vier andere trede-assen dynamisch worden, te beginnen bij BBG? Dat vraagt een eigen issue.

[jipclaassens]

Besloten en aangezet in d47f9a7. TredeVolgtPlancapaciteitVervaldatum staat op TRUE.

Harde en zachte plannen vervallen allebei, en op dezelfde datum. Het onderscheid in looptijd tussen een onherroepelijk bestemmingsplan en een voornemen doet er op deze afstand niet meer toe: de vervaldatum werkt vanaf Y2060 en het eindjaar is 2120.

Nijverheid en logistiek gaan mee, ook al valt hun ladder daarmee terug van acht treden naar twee en wordt de plek van nieuwe bedrijventerreinen vanaf Y2060 volledig door de empirische geschiktheid bepaald. Dat is expliciet akkoord bevonden.

De drie andere trede-assen

Drie van de vier openstaande assen zijn hiermee ook beslecht, en geen van drieen wordt gewijzigd.

De OV-bereikbaarheid en het eigendom zijn niet bij te werken. Er is geen bron die zegt hoe de OV-bereikbaarheid of het grondeigendom zich in 2060 of 2120 ontwikkelt, dus die assen blijven noodgedwongen op het basisjaar staan. Dat is een aanname die in de resultaten hoort te worden benoemd en niet iets dat het model kan oplossen.

Het bouwterrein hoeft niet te worden bijgewerkt, om een reden die de moeite van het vastleggen waard is: een cel die het model eenmaal heeft bebouwd komt de rest van de reeks niet meer in de allocatie. Beschikbaar_Init in Templates/Allocatie/IterSubsector_T.dms sluit elke cel met een gedefinieerde StateVoorAllocatie/SubSector_rel uit, dat veld is eerste-wint, het is een veld voor alle sectoren samen, en het wordt over de zichtjaren heen nooit gewist. Een bouwterrein dat volloopt kan dus niet nog eens vollopen.

Wel een correctie op de aanname dat de as er daarom uit kan. De as heet GrondGebruikK en staat als laatste argument in alle vier de draaiende ladders, dus hij werkt wel degelijk: in het basisjaar geeft hij voorrang aan cellen die toen al bouwterrein waren. Weghalen zou de uitkomst veranderen. Wat niet nodig is, is hem bijwerken.

BBG gaat naar een eigen issue

De vierde as, BBG, is de enige die inhoudelijk wel bijgewerkt zou moeten worden, en daar zit een addertje onder het gras dat een eigen issue verdient. Zie de doorverwijzing hieronder.

Daarmee is dit issue af.

[jipclaassens]

De BBG-as is doorgezet naar #749. De letterlijke uitbreiding met nieuw bebouwde cellen blijkt een no-op, omdat zo'n cel de rest van de reeks niet meer in de allocatie komt en BBG strikt per cel wordt gelezen. Daar staat wat er dan wel moet gebeuren, plus de constatering dat de kaart zelf de bevolkingskernindeling van 2011 is.