Regiokarakteristieken

Regiokarakteristieken

Afstandsgewogen gemiddelde woningkenmerken per woningtype, als 25m-rasters over heel Nederland. Container RegionalAverages in main/SourceData/NVM.dms.

Waarom

De hedonische coëfficiënten uit de R-pipeline geven de prijs van een woning met bekende kenmerken. Voor een locatie waar nog geen woning staat — de RuimteScanner-vraag — moet je die kenmerken invullen. De regiokarakteristieken zijn dat antwoord: "een rijtjeswoning die hier gebouwd wordt, lijkt qua oppervlak, perceel en kamers op de rijtjeswoningen die hier verhandeld worden."

Voor elke cel × woningtype × kenmerk één waarde, gladgestreken over de omgeving zodat ook cellen zonder transacties een zinnige waarde krijgen.

Waar de RuimteScanner deze rasters precies invult (verwervingskosten van de bestaande voorraad, waar de BAG het kenmerk niet levert) staat op Hedonisch woningprijsmodel; zie ook Koppeling met RuimteScanner.

Wat er berekend wordt

Vijf kenmerken (Classifications/HouseCharacteristics) × vier woningtypen (Classifications/WP4) = 20 rasters:

kenmerk	betekenis
size	woonoppervlak (m²)
lotsize	perceeloppervlak (m²)
nrooms	aantal kamers
d_maintgood	aandeel met onderhoudsstaat 'goed'
d_highrise	aandeel hoogbouw (pand ≥ 15 m)

Woningtypen: vrijstaand, twee_onder_1_kap, rijtjeswoning, appartement.

De combinaties komen uit WP4xHouseChar (combine(WP4, HouseCharacteristics)), wat ook de itemnamen levert: vrijstaand_size, rijtjeswoning_nrooms, enz.

Hoe

Stap 1 — subsets per woningtype

Types_WP4 maakt met TypeSubset_T per WP4-type een subset van Result:

select_with_org_rel_with_attr_by_cond(Result, Result/d_<type> == 1)

Elke subset krijgt zijn eigen rdc_25m_rel.

De selectie gaat alleen over het woningtype. Er stond hier ook een lotsize < 99999-conditie, maar die is per 2026-08-17 verwijderd: lotsize is in Result al null gemaakt bij waarden ≥ 99999, dus het enige wat de conditie nog deed was records zónder perceelmaat helemaal uit de subset gooien — inclusief hun size, nrooms en d_maintgood. Bij appartementen, waar perceel vaak ontbreekt, dunde dat de subset onnodig uit. Ontbrekende waarden horen per kenmerk te worden overgeslagen, niet per record; dat gebeurt in stap 2.

Stap 2 — gemiddelde met afstandsverval

Per combinatie (CalcRegionalAvgCharacteristics_T), alles op rdc_25m:

Sum_attribute_ha   = som van het kenmerk per cel
Count_attribute_ha = aantal transacties per cel
Potential_sum      = potential(Sum_attribute_ha,   pot5000m/rev_dist_scaled)
Potential_count    = potential(Count_attribute_ha, pot5000m/rev_dist_scaled)
Potential          = Potential_sum / Potential_count

Dus: een afstandsgewogen gemiddelde over een straal van 5 km, met rev_dist_scaled als verval — dichtbijgelegen transacties wegen zwaarder. De deling door de gewogen tellingen maakt het een gemiddelde in plaats van een dichtheid, en zorgt tegelijk voor de randcorrectie (cellen met weinig buren in de straal krijgen geen te lage waarde).

Teller én noemer worden per kenmerk berekend: Count_attribute_ha telt het kenmerk zelf, niet het aantal records. Een transactie zonder perceelmaat valt daardoor uit de lotsize-noemer maar telt gewoon mee voor size en nrooms. Zo hoort het ook — daarom kon de recordselectie in stap 1 versimpelen.

Wil je dat hardmaken na een run: vergelijk Potential_count van appartement_lotsize met dat van appartement_size. Zijn ze identiek, dan telt count tóch alle records en is de lotsize-noemer te groot (te lage gemiddelden). Verschillen ze, dan klopt het.

Stap 3 — wegschrijven

MakeRegionalAvgCharacteristics schrijft met for_each_nedvnat per combinatie een GeoTIFF:

%PrivDataDir%/NVM_Regiokarakteristieken_<nvm_filedate>/WP4/<type>_<kenmerk>.tif

Daarnaast schrijft MakeNationalAvgCharacteristics de landelijke gemiddelden per type als .fss:

%PrivDataDir%/NVM_Nationalekarakteristieken_<nvm_filedate>/WP4.fss

Die nationale set is de terugvaloptie voor gebieden waar de regionale waarde onbruikbaar is.

Draaien:

GeoDmsRun.exe main.dms /SourceData/NVM/RegionalAverages/per_WP_type/WP4/MakeRegionalAvgCharacteristics

Interpretatie van d_highrise

d_highrise wordt in Result afgeleid als bag_pand_hoogte >= 15 m en blijft null als de pandhoogte onbekend is. Die nulls vallen uit teller én noemer, dus het raster is het aandeel hoogbouw onder de transacties met bekende pandhoogte — niet het aandeel over alle transacties. Dat is de bruikbare lezing: een onbekende hoogte is geen laagbouw, en meetellen als 0 zou het aandeel structureel naar beneden trekken in gebieden met slechte BAG-dekking.

Let op dat de R-pipeline dezelfde variabele anders definieert: daar is onbekende hoogte expliciet 0, met een aparte d_hoogte_onbekend-dummy die de onbekend-categorie in de regressie opvangt (zie R-pipeline). Dat verschil is bewust — in een regressie moet elke observatie een waarde hebben, in een gebiedsgemiddelde niet — maar het betekent wel dat het rastergemiddelde en de dummy in de schattingsset niet exact dezelfde grootheid zijn. De hoogbouwgrens is aan beide kanten 15 m (ModelParameters/Hoogbouwgrens resp. cfg$hoogbouwgrens_cm).

Valkuil: valuetype

De ValueType-kolom in Classifications/HouseCharacteristics staat voor alle vijf kenmerken op float32_t, en dat is geen detail. Het zijn gemiddelden: met een integer-valuetype werden d_maintgood en d_highrise teruggerond naar 0/1 en nrooms naar hele kamers — de hele fractie verdween. Dit is in juli 2026 gefixt en de tifs zijn toen opnieuw gegenereerd (commit f8c005d). Voeg je een kenmerk toe, zet het valuetype dan ook op float32_t.

WP2/WP4

WP_typen bevat nu alleen WP4. De structuur (per_WP_type_T als template) is er op gebouwd om ook een WP2-variant (eengezins/meergezins) te kunnen draaien — de regel voor WP2 staat uitgecommentarieerd. De classificatie-units WP2/WP3/WP5 en hun onderlinge relaties staan klaar in main/Classifications.dms.