NbS-OP's: FractieUitgeefbaar gelijk aan GSI maakt Tuinoppervlakte 0 en laat de lnlotsize-term uit de nieuwbouwprijs vallen

[jipclaassens]

Alle 22 NbS-ontwikkelpakketten (MaxLNL*/MaxHNL*) in VariantParameters/Ontwikkelpakketten/NettoBuurt/Default_src.dms hebben FractieUitgeefbaar exact gelijk aan de GroundSpaceIndex. Daardoor is Buitenruimte = Terrein * (FractieUitgeefbaar - GSI) = 0 en dus Tuinoppervlakte = 0 m2/woning. Dit geldt in zowel de NettoBuurt- als de BrutoBuurt-route (gesloten vorm: Tuin = BVO * (FU - GSI) / FSI, dus schaalonafhankelijk).

In Templates/Suitabilities/Woningwaarde.dms kapt max_elem(OP_Buurt/Tuinoppervlakte[OP_id], 1[m2_Woning]) de tuin af op 1 m2, waarna log(1) = 0: de volledige lnlotsize-bijdrage valt uit Prijs_perWoning.

Omvang (coefficienten Estimates_20260711):

• 6 OP's met WP4 vrijstaand (lnlotsize 0.0932): circa +80% prijs gemist t.o.v. een reguliere tuinomvang
• 4 OP's met WP4 rijtjeswoning (lnlotsize 0.0211): circa +10%
• 12 OP's met WP4 appartement: geen lnlotsize-coefficient, geen effect

De doorwerking op het ExploitatieSaldo is groter dan het prijseffect, omdat het saldo een verschil van grote termen is. In NbS-varianten concurreren buiten de plancapaciteit wonen alleen NbS-OP's, dus dit drukt de grondgebonden groene pakketten systematisch t.o.v. de appartement-pakketten. De uitkomst hangt bovendien aan de arbitraire guard-constante van 1 m2.

Kernvraag: is "geen private buitenruimte" een bewuste ontwerpkeuze voor deze OP's?

• Zo ja: dan verdient de prijsformule voor deze pakketten een expliciete lotsize-aanname in plaats van de 1 m2-guard (bijv. het WP4-gemiddelde perceel, analoog aan Prijs_perWoning_zWeging).
• Zo nee: dan moet FractieUitgeefbaar voor deze rijen boven de GSI, zodat er weer een tuin bestaat.

Raakt alleen de NbS-varianten; BAU/BAU2 gebruiken deze OP's niet.

[jipclaassens]

Correctie op de cijfers hierboven

De genoemde coefficienten kwamen uit de verkeerde kopie van de estimates. De actieve SourceDataDir is E:\SourceData, en daar staat wel degelijk de rs_groen-set (17-07, inclusief fr_natuur_tot2500m/fr_water_500m). De juiste lnlotsize-waarden zijn iets lager:

WP4	lnlotsize (gebruikt)	lnlotsize (actief)
vrijstaand	0.0932	0.0905
rijtjeswoning	0.0211	0.0205
twee_onder_1_kap	0.0290	0.0270
appartement	—	—

Effect daarmee: vrijstaand circa +76% i.p.v. +80%, rijtjeswoning +10.2% i.p.v. +10.6%. De diagnose zelf verandert niet.

Aanvullende bevindingen

1. Het is een invulfout, geen ontwerpkeuze. De uitkomst hangt volledig aan de guard-constante: max_elem(..., 1[m2_Woning]) is precies de waarde waarbij de term verdwijnt. Bij een cap van 10 m2 was de vrijstaand-prijs x1.24 geweest, bij 25 m2 x1.35. Een modeluitkomst die zo scharniert op een arbitraire ondergrens is geen gemodelleerde keuze.

2. De Checks vangen dit niet af. GSIIsNietGroterDanFractieUitgeefbaar toetst op > en laat gelijkheid dus door. Bovendien is het een los Bool-attribuut zonder IntegrityCheck, dus het faalt nergens op.

3. Tweede, losstaande bug in dezelfde template. Woningwaarde.dms regel 75 (Prijs_perWoning_zWeging0) heeft géén max_elem. Voor deze pakketten geeft dat log(0) = -inf, dus prijs 0 bij vrijstaand/rijtjeswoning en 0f * -inf = NaN bij de 12 appartement-pakketten. Dat voedt P_nieuwbouw in Indicatoren.dms:522, die indicator is dus voor alle 22 NbS-pakketten onbruikbaar.

4. De nul was consequent ingevuld, niet vergeten. Bij alle 22 NbS-rijen staan ook de drie InUitgeefbaarExPandFootprint-fracties (verhard/groen/water) op 0.00, terwijl ze bij de BAU-rijen tot 1.00 sommeren. Dat is relevant voor de fix: wie alleen FractieUitgeefbaar verhoogt, krijgt via NettoBuurt.dms:38-46 een buitenruimte die 100% Bruin wordt (Verhard = 0 -> GroenEnWaterEnBruin = 1 -> Groen/Water vallen via de 0/0-MakeDefined op 0 -> Bruin = 1). Dat zou stilzwijgend groen uit de buurt slopen en NDVI, carbon, waterberging en BereikbaarheidGroenBGT raken.

Doorgevoerde fix

a. Tien eengezinspakketten krijgen een private buitenruimte. FractieUitgeefbaar omhoog volgens FU = GSI + FSI * doeltuin / BVO, met doeltuin 250 m2 voor vrijstaand en 60 m2 voor rijtjeswoning. Tegelijk zijn de InUitgeefbaar-fracties gelijkgezet aan de InOpenbaar-fracties van hetzelfde pakket, zodat de ingreep fysiek neutraal is: de vierkante meters verhuizen van openbaar naar uitgeefbaar, maar de buurttotalen groen/water/verhard blijven exact gelijk. Alleen het eigendomslabel verschuift — en dat is precies wat de hedonische formule meet.

pakket	WP4	FU oud	FU nieuw	tuin	prijs
MaxLNLLaagGroenVS, MaxLNLLaagBlauwVS, MaxHNLLaagGroenVS	vrijstaand	0.08	0.29	255.6 m2	x1.651
MaxLNLLaagGroenSH, MaxLNLLaagBlauwSH, MaxHNLLaagGroenSH	vrijstaand	0.08	0.33	246.7 m2	x1.646
MaxLNLMiddenGroenVS, MaxHNLMiddenGroenVS	rijtjeswoning	0.18	0.35	61.0 m2	x1.088
MaxLNLMiddenGroenSH, MaxHNLMiddenGroenSH	rijtjeswoning	0.18	0.40	59.2 m2	x1.087

Ook na de ingreep houden deze pakketten 60-71% openbare ruimte, tegen 50% bij alle BAU-pakketten. Het NbS-karakter blijft dus overeind.

De 12 appartement-pakketten zijn bewust ongemoeid gelaten: de NVM-schatting kent voor appartementen geen lnlotsize, dus daar is FU == GSI prijsneutraal en fysiek verdedigbaar.

b. Check die dit voortaan afvangt. Nieuw Checks/EengezinsHeeftPriveBuitenruimte, plus een harde IntegrityCheck op FractieUitgeefbaar:

all(!(GroundSpaceIndex > this)) && all(WP2_rel != Vastgoed/WP2/V/eengezins || this > GroundSpaceIndex)

Die dekt zowel het oude GSI > FU als het nieuwe FU == GSI bij eengezins. Appartementen mogen FU == GSI houden.

c. De ontbrekende guard op regel 75 is toegevoegd, zodat Prijs_perWoning_zWeging niet langer 0 of NaN oplevert.

Verificatie

Gedraaid met GeoDmsRun 20.8.0.m tegen cfg/main.dms:

• Default/FractieUitgeefbaar rekent door, IntegrityCheck slaagt en levert geen circulaire afhankelijkheid op (vandaar de formulering met this in plaats van een verwijzing naar Checks/...).
• Negatieve test: een van de tien rijen tijdelijk teruggezet op FU = 0.08 laat de run falen met IntegrityCheck ... is not true. De check vuurt dus echt.
• NettoBuurt/PerVariant/NbSMax/InDezeBuurt/Tuinoppervlakte, dezelfde via BrutoBuurt, .../Terreinoppervlakte/Totaal/Groen en Checks/EengezinsHeeftPriveBuitenruimte rekenen alle vier foutloos door.
• Neutraliteitstoets over alle 49 pakketten: grootste afwijking in de terreinfracties verhard/groen/water/bruin is 1.1e-16 (0.0000 m2 per ha), dus exact neutraal op float-precisie na.
• Na de fix hebben nog 12 pakketten FU == GSI; alle 12 zijn appartement en geen daarvan heeft een lnlotsize-coefficient.

Nog open

• Doeltuinen 250 m2 / 60 m2 zijn mijn aanname, afgeleid van de BAU-tegenhangers (DorpsLandLaagEGVS heeft 553 m2, LagerStedelijkEGVS 118 m2) en bewust een stuk krapper gehouden om het NbS-karakter te bewaren. Graag bevestiging van Bart/Deltares; het zijn twee getallen per rij, dus makkelijk te draaien.
• Waterberging is niet volledig neutraal. FractieWadiNieuwbouwUitgeefbaarGras (0.30) en FractieHalfverhardingNieuwbouwUitgeefbaar (0.30) liggen in de NbS-varianten lager dan hun openbare tegenhangers (beide 0.50). Bij MaxLNLLaagGroenVS verhuist circa 825 m2/ha gras naar prive, waarvan het wadi-aandeel van 50% naar 30% zakt: circa 165 m2/ha minder wadi, die terugvalt op doorlatend groen. Inhoudelijk verdedigbaar (een prive tuin heeft minder wadi's dan een park), maar het is een reeel effect op het bergingsaanbod.
• Voor de Blauw-pakketten erft de prive buitenruimte een hoog waterandeel (MaxLNLLaagBlauw*: 60% water). Dat volgt uit de neutrale keuze om de openbare samenstelling over te nemen. Een realistischer tuinsamenstelling (meer groen, minder water) kan niet neutraal: deze pakketten hebben zo weinig verharding (4% van openbaar) dat een tuin met terras alleen kan door het totale verharde oppervlak te verhogen. Dat is een ontwerpwijziging, geen bugfix — vandaar bewust niet gedaan.