Tredes
De trede is de ontwerpcomponent van de geschiktheid: de volgorde waarin locatietypen aan bod komen, naar analogie met de Ladder voor Duurzame Verstedelijking. Waar de empirische component zegt hoe aantrekkelijk een plek is, zegt de ladder welke soort plek eerst aan de beurt is. Deze pagina beschrijft hoe een ladder is opgebouwd, welke assen er zijn, wat de allocatie ermee doet en waar je op moet letten als je er een aanpast.
De empirische kant staat op Geschiktheid, de allocatie zelf op Allocatie procedure in formules.
Wat een trede doet in de allocatie
De ladder deelt de cellen in genummerde klassen in, van hoge naar lage voorrang. In de allocatie wordt de empirische geschiktheid per subsector eerst omgezet in een rangnummer, en dat rangnummer wordt opgeteld bij een offset die per trede verschilt:
Geschiktheid_totaal = Trede_offset x bereik + rangnummer(Empirische_geschiktheid)
De offset is zo gekozen dat hij het rangnummer altijd overstemt. De ordening is daarmee strikt lexicografisch: een cel in een hogere trede gaat altijd voor op elke cel in een lagere trede, hoe hoog de empirische score daar ook is. Pas binnen een trede geeft de empirie de doorslag, en dan alleen als rangorde en niet als hoogte.
Dat maakt de ladder het zwaarste sturingsmiddel in het model. Bij wonen bezetten de harde plannen de bovenste 36 van de 144 treden, en bij nijverheid en logistiek is de plancapaciteit de enige inhoudelijke as van de acht.
Twee dingen doet de ladder niet. Hij weegt niet: er is geen gewicht waarmee een hoge empirische score een trede kan compenseren. En hij is niet vergelijkbaar tussen subsectoren: het aantal treden verschilt per subsector, dus een tredescore van de ene subsector zegt niets over die van de andere. Waar subsectoren om dezelfde cel strijden wordt daarom op iets anders beslist, bij wonen op de hoogte van het exploitatiesaldo en bij werken sinds augustus 2026 op een uniforme plancapaciteit- en stimuliprioriteit die aan de kans voorafgaat. Zie Geschiktheid.
Hoe een ladder is opgebouwd
Een ladder is een cartesisch product van assen. Elke as is een klassenlijst, en elke klasse draagt een expressie (RefSrc) die per cel zegt of de klasse van toepassing is. De ladders staan per sector en subsector in VariantParameters/Tredes, de assen in VariantParameters/Tredes/impl, en de vlaggen waarnaar de expressies verwijzen in Templates/VariantData_T/Trede.dms onder src.
Per cel wordt op elke as de eerste klasse gekozen waarvan de vlag waar is, en die asindices worden samengevoegd tot een klassenummer. De volgorde van de assen in de combine is de prioriteitsvolgorde: het eerste argument telt het zwaarst.
Voor wonen in de BAU-ladder zijn de assen:
- Plancapaciteit en stimuli (4 klassen): binnen hard plan, binnen zacht plan, binnen stimuli, daarbuiten
- Bestaand bebouwd gebied (2): binnen, buiten
- OV-bereikbaarheid (3): zeer nabij, nabij, rest
- Eigendom (3): maatschappelijke ontwikkelende partij binnen bebouwd gebied, commerciele ontwikkelende partij, rest
- Grondgebruik (2): bouwterrein, rest
Samen 144 klassen. Let op dat de eerste as geen kruisproduct van plan en stimuli is maar een aaneenschakeling van vier klassen op volgorde: een cel valt in de eerste klasse die op haar van toepassing is, dus een cel binnen een hard plan komt in klasse 0 ongeacht de stimuli.
Elke as sluit af met een catch-all, zodat elke cel op elke as in precies een klasse valt. Dat is geen nettigheid maar een eis: valt een cel op een as in geen enkele klasse, dan heeft ze geen trede en kan ze niet worden gealloceerd. Op de tredescore in de allocatie staat een IntegrityCheck die bewaakt dat het klassenummer onder de cardinaliteit van de ladder blijft.
De ladder beslist sinds #759 op cellen van 25 meter, dezelfde cellen waarop de allocatie sinds #508 kiest. Tot dan werd hij op 100 meter bepaald en daarna over de zestien cellen eronder uitgesmeerd. De toeleverende lagen in BaseData staan daarom nu ook op 25 meter.
De assen
| As | Klassen | Wat hij leest |
|---|---|---|
| plancapaciteit, in acht varianten | 1 tot 3 | de harde en zachte plankaarten per sector, voor werken per subsector KanOp-gefilterd |
| stimuli | 2 | de stimulikaart per sector |
| plancapaciteit plus stimuli | 4 | de twee hierboven achter elkaar, als een reeks en niet als kruisproduct |
| bestaand bebouwd gebied | 2 | de begrenzing bebouwd gebied |
| bebouwd gebied plus kansrijke woningbouw | 3 | idem, met de zoekgebieden woningbouw uit het landschapstype rivieren ertussen (#620) |
| OV-bereikbaarheid | 3 | reistijd naar een railhalte, rond een kern van 20.000 inwoners of meer |
| eigendom, in vier varianten | 2 of 3 | de eigendomskaart, gecombineerd met bebouwd gebied |
| grondgebruik | 2 | bouwterrein volgens het grondgebruik van het basisjaar |
| grondgebruik voor energie | 2 | langs rijkswegen of primaire waterkeringen |
| bouwregime | 4 | de overstromingsgevaarzonering, en uitdrukkelijk niet de landschapstypen |
| belevingswaarde landschap | 2 of 4 | de belevingskaart van het Nederlandse landschap |
| slappe bodem | 2 | de bodemkaart |
| hoog of laag Nederland | 2 | de pleistocene tegen de holocene helft |
| woongebied of kom | 2 | bebouwd gebied of de schijf rond bestaand woongebied (#710) |
| bestaand kantoorgebied | 2 | cellen waar kantoor de werkstand domineert (#668) |
| wel of geen wind in het basisjaar | 2 | de turbinestand |
| zonneladder | 5 | de treden van de zonneladder die daadwerkelijk alloceren, plus een restklasse |
| Totaal | 1 | de catch-all die alles vangt |
De bouwregime-as leest bewust alleen de overstromingskant en niet de landschapstypen: de trede zou anders van betekenis veranderen op cellen die de zeef toch al heeft weggehaald. De as komt alleen voor in de ladders Intensiveren en Transformeren; de andere ladders gebruiken hem niet.
De ladders die er zijn
Per sector en subsector staat er een unit per trede-variant. Welke een toepassing kiest bepaalt Trede_Variant in VariantK.dms, per variant. De namen in de tabel hieronder zijn variantnamen uit de toepassingen waarin die ladders zijn gebouwd, dus voorbeelden en geen modeleigenschap: BAU, Intensiveren en Transformeren komen uit de Ruimtelijke Verkenningen 2023, NbSMax en NbSGenuanceerd uit een latere toepassing met natuurlijke maatregelen. Wat wel een modeleigenschap is, is dat de ladders per sector en subsector worden gedefinieerd en dat een sector alleen kan draaien als er voor de gekozen variantnaam een unit bestaat.
| Sector en subsector | Beschikbare trede-varianten | Klassen in de BAU-ladder |
|---|---|---|
| wonen, vier subsectoren | BAU, Intensiveren, Transformeren, NbSMax, NbSGenuanceerd, plus enkele oudere | 144, en 216 in NbSGenuanceerd |
| werken, nijverheid en logistiek | BAU, Intensiveren, Transformeren, NbSMax, NbSGenuanceerd | 8 |
| werken, zakelijke dienstverlening | BAU, NbSMax, NbSGenuanceerd | 288 |
| werken, de drie verzorgende subsectoren | BAU, NbSMax, NbSGenuanceerd | 288, en 432 in NbSGenuanceerd |
| verblijfsrecreatie | BAU, Intensiveren, Transformeren, en twee oudere | 4 |
| zon | BAU en vier oudere namen | 40 |
| wind | BAU en vier oudere namen | 64 |
| waterberging | BAU, NbSMax, NbSGenuanceerd, alle drie leeg | 1 |
| landbouw | alleen de lege ladder | 1 |
Waar een variant hetzelfde wil als BAU staat er een alias, bijvoorbeeld NbSMax := BAU. Waterberging en landbouw hebben geen ladder: daar valt alles in een enkele klasse en beslist de empirische geschiktheid alleen.
Let op de asymmetrie in die tabel. Voor wonen en werken zijn de ladders bij elke nieuwe toepassing meegegroeid; die voor verblijfsrecreatie, zon en wind dragen nog de namen van de toepassingen waarvoor ze gemaakt zijn. Wie zo’n sector aanzet onder een variantnaam waarvoor geen unit bestaat, moet die eerst toevoegen, desnoods als alias van een bestaande.
Welke assen met de tijd meebewegen
De ladder is van oorsprong volledig op het basisjaar geankerd: geen van de assen werd bijgewerkt met wat het model zelf bouwt, zodat een wijk uit een vroeg zichtjaar in een laat zichtjaar nog steeds als uitbreiding telde. Sinds #739 en #749 kunnen er drie van de vijf wonen-assen meebewegen, elk achter een eigen schakelaar in ModelParameters/Advanced. Ze staan standaard aan; een toepassing die de ladder volledig op het basisjaar wil ankeren zet ze uit.
De eerste schakelaar laat de plancapaciteit-as vervallen na PlancapaciteitGeldigTotEnMet, op dezelfde datum als de vrijstelling in de zeef: een cel binnen een plan zakt daarna naar de stimuli-trede of de restcategorie. Dit is een aparte schakelaar en geen bijvangst van de zeef, juist omdat de trede zwaarder weegt dan de zeef.
De tweede laat de eigendom-as vervallen op een eigen jaartal, EigendomGeldigTotEnMet, omdat grondeigendom in het basisjaar weinig zegt over een zichtjaar decennia later. Elke cel valt dan in de restklasse van die as. Dat kan zonder de ladder te verbouwen omdat de as een catch-all heeft.
De derde bouwt de as bestaand bebouwd gebied per zichtjaar opnieuw op, als het bebouwd gebied van het basisjaar verenigd met een schijf van 100 meter rond de cellen die het model in eerdere zichtjaren voor wonen of werken heeft gealloceerd. Die ingreep moest om de omgeving van gebouwde cellen gaan en niet om die cellen zelf: een cel die het model eenmaal alloceert komt de rest van de reeks niet meer in de allocatie, dus haar aan het bebouwd gebied toevoegen verandert niets. De schijf is 100 meter, precies een cel van het oude allocatiegrid; ruimer werkt niet, want een schijf van 500 meter voegt al 862.700 hectare toe, bijna tweemaal het bebouwde gebied zelf.
De OV-bereikbaarheid en het bouwterrein bewegen niet mee. Voor de eerste is er geen bron die zegt hoe die zich ontwikkelt, en dat is een aanname die bij de resultaten hoort te worden benoemd. Voor de tweede hoeft het niet, om dezelfde reden als hierboven.
Los daarvan bepaalt RondBevolkingskernVolgtUrbanContour waarop de buffers rond kernen naar inwonertal staan: op de begrenzing bebouwd gebied met het inwonertal uit de CBS-vierkanten, of op de oudere kaart met bevolkingskernen. Dat verzet meer dan de trede alleen: dezelfde buffers voeden de OV-klassen en de dichtheidsfactoren per kerngrootte.
Om die vervaldatums te kunnen zetten worden de ladders in vier smaken opgebouwd: met beide assen, zonder plancapaciteit, zonder eigendom en zonder allebei. De ladder zelf is in alle vier dezelfde; wat verschilt is de bron, waarin de betreffende vlaggen zijn platgelegd. Per zichtjaar kiest de allocatie welke van de vier ze leest, net zoals de zichtjaarzeef sinds #682 kiest tussen de twee uitkomsten van de basisjaarzeef. Staan beide schakelaars uit, dan komen de andere drie opbouwen niet in de boom en kosten ze niets.
Hoe de ladder wordt gerekend
Tot #775 werd de ladder opgebouwd als een attribuut per klasse: per klasse een kaart met het klassenummer waar alle asvlaggen waar zijn, en daaroverheen een ArgMin die de laagste pakte. Dat is een correcte maar dure vorm. Op 25 meter gaat het om 144 tot 432 kaarten van 145,6 miljoen cellen per ladder, per zichtjaar opnieuw, en dat verklaarde de sprong in geheugengebruik na de overgang naar 25 meter.
Sinds #775 leest het sjabloon de assen uit de combine-unit zelf, bouwt per as een kaart van een byte met de eerste ware klasse, en telt die asindices met een mixed-radix som samen in combine-volgorde. Rekenkundig is dat hetzelfde, want de klassenconjuncties zijn per constructie het cartesisch product van de asvlaggen. Gemeten op vier ladders in een aanroep ging de piekreservering van 166.033 naar 8.439 MB en de rekentijd van 400 naar 43 seconden, bij nul cellen verschil.
Twee details van die constructie zijn het onthouden waard. Een alias als NbSMax := BAU heeft de subitems van de combine niet zelf; het sjabloon volgt de alias tot twee niveaus diep om alsnog bij de assen te komen. En een unit zonder first_rel is geen combine en is dan zelf de enige as, wat de ladders met een enkele as opvangt.
Valkuilen bij het aanpassen
Elke as heeft een catch-all nodig. Zonder sluitstuk valt een cel buiten de ladder en doet ze niet mee.
De volgorde van de assen is de prioriteitsvolgorde. Een as verplaatsen is geen cosmetische ingreep maar een andere ladder.
Een as toevoegen vermenigvuldigt de cardinaliteit. Van 144 naar 216 klassen kost niets bijzonders, maar de ladder is wel de plek waar dat zich opstapelt.
Een nieuwe variantnaam vraagt een unit per sector en subsector die de allocatie draait. Ontbreekt hij, dan faalt de configuratie op een niet bestaand item.
En een as mag geen alias van een classificatie-unit zijn. De verwijzing die het sjabloon volgt loopt dan door tot de classificatie zelf, en daar staat geen RefSrc. Om die reden dragen de assen bestaand bebouwd gebied en bouwregime sinds #775 hun eigen klassenlijst met dezelfde namen als de classificatie.