Twee grootheden heten waterberging: de gealloceerde bergingsgebieden en de piekbui-dekkingsgraad

[jipclaassens]

Twee verschillende grootheden heten in dit model allebei waterberging, en ze worden in de rapportage door elkaar gehaald. Ze meten ander water, op een andere plek, op een andere tijdschaal.

De twee grootheden

De sector Waterberging alloceert bergingsgebieden. De claim komt per waterbergingsregio uit ModelParameters/Waterberging/Claims, aangeleverd door Deltares bij #575, in kubieke meter per maand voor de maand juli. De deelgebieden zijn de veengebieden plus een restregio, en de geschiktheid stuurt met VeenNabijPotentiaal op 5.000 meter naar de omgeving van het veen. Een cel telt pas mee bij een waterschijf van minstens een meter. Dit gaat over seizoensberging in het landelijk gebied. Voor BAU 2050 telt die claim landelijk op tot 137,0 miljoen kubieke meter.

De indicator in Templates/Indicatoren/Waterberging meet iets anders. De vraag daar is de waterschijf bij een hevige bui maal het celoppervlak, gemaskeerd op bestaand bebouwd gebied, landelijk 497,0 miljoen kubieke meter. Het aanbod komt uit groene en blauwe daken, wadi's en halfverharding. Dit gaat over een piekbui in de stad.

Een hectare seizoensberging in het veen doet niets voor een piekbui in een stad vijftig kilometer verderop. Dat de indicator de gealloceerde berging niet meetelt is dus verdedigbaar en waarschijnlijk juist. Wat niet klopt is dat beide grootheden dezelfde naam dragen en in dezelfde tabellen naast elkaar staan zonder dat het verschil ergens is vastgelegd.

Concreet gemeten in zichtjaar 2040: de bijdrage van de aan de sector toegewezen cellen aan het aanbod van de indicator is exact nul, bij 2.685 hectare toegewezen areaal in BAU en 2.187 hectare in NbSGenuanceerd. Dat is geen gemis in de telling maar een gevolg van het feit dat het over twee systemen gaat.

Wat de dekkingsgraad wel is, en wat hem bepaalt

Zichtjaar 2040, heel Nederland, in miljoen kubieke meter.

maat	BAU	NbSGenuanceerd
vraag, piekbui in bebouwd gebied	497,0	497,0
aanbod totaal	38,2	297,5
aanbod dat vraag dekt	25,1	180,1
aanbod dat vervalt door de blokklemming	13,0	117,4
dekkingsgraad	5,1 procent	36,2 procent

Vraag en aanbod worden allebei opgeteld naar blokken van 500 meter en daar tegen elkaar weggestreept, met RestvraagPositief := max_elem(Restvraag, 0). Aanbod in een blok waar meer aanbod dan vraag ligt vervalt en kan niet naar een naburig blok. In NbSGenuanceerd is dat 117,4 miljoen kubieke meter, oftewel 39 procent van het totale aanbod. Dat is de grootste enkele post in de indicator en hij staat nergens gerapporteerd.

De blokgrootte staat als parameter met twee standen, Grid_ref := '500m'; // 100m, 500m, zonder onderbouwing waarom 500 meter de juiste maat is voor de afstand waarover berging een piekbui kan bedienen. Bij 100 meter zou het verlies groter zijn en de dekkingsgraad lager.

Verder is de vraag gemaskeerd op bestaand bebouwd gebied en het aanbod niet. Door de aggregatie naar 500 meter telt aanbod net buiten bebouwd gebied nog wel mee zolang het in hetzelfde blok ligt.

Openstaande vragen Deltares

• klopt het dat de gealloceerde bergingsgebieden en de piekbui-indicator twee losse systemen zijn die niet bij elkaar opgeteld horen te worden? Zo ja, dan horen ze in de rapportage uit elkaar gehouden te worden met namen die dat duidelijk maken.
• is 500 meter de bedoelde afstand waarover berging en piekbuivraag aan elkaar gekoppeld mogen worden?
• hoort het aanbodoverschot binnen een blok werkelijk te vervallen, of hoort het binnen een groter gebied verrekend te worden?

[jipclaassens]

Gemeten op zichtjaar 2120, en de klemming groeit mee

De cijfers hierboven staan op zichtjaar 2040. Hier dezelfde uitsplitsing op 2120, het zichtjaar van de oplevering.

maat, miljoen kubieke meter	BAU	NbSGenuanceerd
piekbuiopgave, bebouwd gebied	497,0	497,0
stedelijk aanbod	40,5	365,5
daarvan gedekt	26,0	186,7
vervallen door de blokklemming	14,5	178,8
dekkingsgraad	5,2 procent	37,6 procent

Het aandeel van het aanbod dat vervalt loopt op met de tijd: in NbSGenuanceerd van 39 procent op 2040 naar 48,9 procent op 2120, in BAU van 34 naar 35,8 procent. Dat is verklaarbaar, want hoe meer aanbod er in het bebouwde gebied bij komt, hoe vaker een blok van 500 meter meer aanbod dan vraag draagt en het overschot dus vervalt.

Het gevolg is wel dat deze indicator de latere zichtjaren stelselmatig strenger beoordeelt dan de vroege. Op 2120 komt in NbSGenuanceerd bijna de helft van de daken, wadi's en halfverharding niet in de dekkingsgraad terecht. Dat is geen eigenschap die je van een dekkingsgraad verwacht, en het verklaart waarom de dekking afvlakt terwijl het aanbod doorgroeit.

Het areaal dat aan de sector Waterberging is toegewezen staat op 2120 op 4.952 hectare in BAU en 4.060 in NbSGenuanceerd, en levert nul aan deze indicator. Dat blijft correct: het is seizoensberging in het landelijk gebied en geen piekbuiberging in de stad.

De keuze van 500 meter is daarmee het scherpst geformuleerde openstaande punt van dit issue. Hij bepaalt op 2120 bijna de helft van de uitkomst in de NbS-variant, en hij staat als parameter met twee standen zonder onderbouwing.

[jipclaassens]

Opgelost, en hoe

De indicator heet nu piekbuiberging en de sector blijft waterberging, in de boom, in de kolomnamen van RegionaleIndicatoren, in de kaartnamen, in de diagnose-uitdraai en op de wiki. Daarmee kunnen de twee grootheden niet meer naast elkaar in dezelfde tabel staan onder bijna dezelfde naam. Commit db0de58.

De namen binnen de indicator zijn meegegaan, want twee ervan zeiden iets anders dan ze deden. Afname was het gedekte deel van de opgave en niet een afname, en Vraag botst met de ruimtevraag elders in het model. Voor wie een oudere uitdraai naast een nieuwe legt:

tot #720	nu
Waterberging_Vraag	Piekbuiberging_Opgave_m3
Waterberging_Afname	Piekbuiberging_Gedekt_m3
Waterberging_RestvraagPositief	Piekbuiberging_Ongedekt_m3
kaart Waterberging_RestvraagPositief	kaart Piekbuiberging_Ongedekt_m3_per500m
bestond niet	Piekbuiberging_Aanbod_m3
bestond niet	Piekbuiberging_AanbodBinnenBBG_m3
bestond niet	Piekbuiberging_AanbodZonderOpgave_m3
bestond niet	Piekbuiberging_Dekkingsgraad
bestond niet	Piekbuiberging_Dekkingsgraad_Ongeklemd
bestond niet	kaart Piekbuiberging_Gedekt_m3_per500m

De dekkingsgraad zelf werd tot nu toe niet geleverd, terwijl dat het getal is dat in een beleidstekst wordt overgenomen. Iedere lezer deelde zelf, en niemand zag daarbij dat de deling een aanname over afstand bevat. Hij staat er nu, met de ongeklemde variant ernaast als bovengrens.

De blokmaat staat als parameter met twee standen en heeft nu een Descr met de gemeten gevoeligheid. De kaart met het gedekte deel bestond alleen op papier: het item droeg een StorageName maar stond in geen enkele ExplicitSuppliers, dus het bestand is nooit geschreven. Nu is het een gewone rasterexport, en beide piekbuikaarten dragen de blokmaat in de naam, want ze liggen als enige export niet op 25 meter maar op 500.

De gemeten cijfers, nu op één codestand

De tabel in de opening stond op een mengeling van codestanden. Hieronder alles op de standen van oplevering_NL2120_20260901, commit 401f7b5, met StandAllocatieOntkoppeld op TRUE. In miljoen kubieke meter.

Zichtjaar 2040:

maat	BAU	NbSGenuanceerd
opgave, piekbui in bebouwd gebied	497,0	497,0
aanbod	38,2	293,5
gedekt	25,1	178,7
aanbod zonder opgave in zijn blok	13,1	114,8
dekkingsgraad	5,1 procent	36,0 procent
dekkingsgraad zonder blokklemming	7,7 procent	59,1 procent

Zichtjaar 2120:

maat	BAU	NbSGenuanceerd
opgave, piekbui in bebouwd gebied	497,0	497,0
aanbod	40,5	361,3
gedekt	26,0	185,3
aanbod zonder opgave in zijn blok	14,5	176,0
dekkingsgraad	5,2 procent	37,3 procent
dekkingsgraad zonder blokklemming	8,1 procent	72,7 procent

Het aandeel van het aanbod dat door de blokklemming vervalt loopt op van 34 procent in BAU 2040 naar 48,7 procent in NbSGenuanceerd 2120. Dat is de bevestiging van wat hierboven al stond: de indicator beoordeelt latere zichtjaren strenger naarmate er meer aanbod is, en dat is geen eigenschap die je van een dekkingsgraad verwacht.

Wat de blokmaat waard is

Dit was de tweede openstaande vraag, en die is nu gemeten in plaats van gesteld. Zelfde stand, NbSGenuanceerd 2120, alleen Grid_ref verzet:

blokmaat	gedekt	aanbod zonder opgave	dekkingsgraad
100 meter	148,3	213,0	29,8 procent
500 meter	185,3	176,0	37,3 procent
geen klemming, heel Nederland	361,3	0,0	72,7 procent

De opgave en het aanbod zijn in alle drie de regels dezelfde getallen. De uitkomst verschilt met meer dan een factor twee, puur door de afstand waarover opgave en aanbod elkaar mogen vinden. Daarom staan de twee dekkingsgraden nu als paar in de tabel: de geklemde is de ondergrens, de ongeklemde de bovengrens, en de blokmaat bepaalt waar je daartussen uitkomt. Wat die maat hydrologisch zou moeten zijn is een vraag die openblijft, en die staat nu in #741.

Wat er is doorgerekend en wat niet

De hele keten per blok is doorgerekend en geeft tot op de laatste decimaal dezelfde getallen als voor de hernoeming: aanbod 361,32785757974483 miljoen kubieke meter en restopgave 311,6931779638481 in NbSGenuanceerd 2120, gelijk aan de uitdraai van de productierun zelf. De twee kaarten zijn geschreven en dragen de goede naam. De regio- en NL-aggregaties zijn niet doorgerekend: de BAG-keten op deze branch valt vanavond om op WP5_rel, ook zonder mijn wijziging, en daar hangt de regiokaart aan. Die items zijn dezelfde optelling als de bestaande regels ernaast, maar gemeten zijn ze nog niet.

Antwoord op de eerste vraag uit de opening

De vraag of de gealloceerde bergingsgebieden en de piekbui-indicator twee losse systemen zijn hoeft niet meer aan Deltares gesteld te worden. Het antwoord staat in de configuratie zelf: een cel die aan de sector waterberging is toegewezen valt in geen van beide takken van het aanbod, dus levert per constructie nul, en dat wordt in ToetsOplevering.ps1 als harde toets bewaakt. Wat overbleef was dat ze dezelfde naam droegen, en dat is nu opgelost. De twee andere vragen uit de opening gaan niet over de naam maar over de rekenwijze, en die verhuizen samen met wat de doorlichting verder vond naar #741.

Daarmee kan dit issue dicht.

Openstaande punten Object Vision

• de kolom WaterbergingVeen in RegionaleIndicatoren is niet op veen gemaskeerd maar telt alle gealloceerde waterberging, en heeft in Landgebruik_Areaal.csv dezelfde waarde onder de naam Waterberging_Totaal; dat bijt nu niet, want de opgave bestaat alleen in het veen, maar de naam belooft een begrenzing die de formule niet legt. Eigen issue waard?
• de indicatorregio staat in de oplevering op NL, dus de piekbuiberging komt als één landelijk getal plus één blokkenkaart. Moet die tabel op provincie of landschap geleverd worden?

[jipclaassens]

Correctie op de vorige comment

Hierboven schreef ik dat de BAG-keten vanavond omvalt op WP5_rel. Die toeschrijving klopt niet, en het verschil is groter dan een datum.

Nagerekend na het sluiten: de betrokken bestanden zijn identiek tussen 401f7b5, de commit waarop de oplevering van 1 september is gedraaid, en de huidige stand. Het defect zit dus ook in de codestand van die oplevering en niet in iemands werkkopie van vanavond. De vindplaats is cfg/main/SourceData/Vastgoed/BAG/AfleidingPandtype.dms rond regel 115: point_xy(float32(min_x), float32(max_y), rdc_meter), terwijl rdc_meter in Geography.dms een unit<DPoint> is en dus float64. Voor die combinatie bestaat geen operator, en de keten die de WP5-mmd's aanmaakt loopt daarop vast.

Wat ik zag was daarmee niet het ontstaan van het defect maar het effect ervan. De mmd-bestanden op de bronschijf staan er sinds augustus en worden gewoon gelezen; zodra het domein waarin ze worden ingelezen niet meer exact past, 11157667 bytes tegen 11157666 gevraagd, valt de leeskant om. Opnieuw aanmaken uit de configuratie kan niet, want dat is precies de keten die op het type-conflict vastloopt.

Voor dit issue betekent dat twee dingen. De regio- en NL-aggregaties van de piekbuiberging blijven voorlopig ongemeten, want die hangen aan de regiokaart. En ToetsOplevering.ps1 meldt voor de piekbuitoets GEEN DATA tot er een verse /Diagnose/GenerateAll is gedraaid, en dat is op dit moment door hetzelfde probleem geblokkeerd. De naamsverandering van dat diagnosebestand komt daar bovenop, maar is niet de oorzaak.

Het defect zelf hoort niet bij dit issue en wordt apart opgepakt.