Zoals eerder gemeld bepaalde mijn BAG tooltje het woningtype, zoveel mogelijk het algoritme volgend zoals beschreven in bijlage 1 van de productbeschrijving Woningtypering van het Kadaster.
Daarmee kwam ik op de volgende aantallen en percentages:
┌────────────┬─────────┬────────┐
│ woningtype │ # │ % │
├────────────┼─────────┼────────┤
│ A │ 3308082 │ 33.5 │
│ T │ 2427660 │ 24.6 │
│ N │ 1291550 │ 13.1 │
│ V │ 1078285 │ 10.9 │
│ H │ 1049383 │ 10.6 │
│ K │ 725058 │ 7.3 │
│ NULL │ 6762 │ 0.1 │
└────────────┴─────────┴────────┘
Zonder vergelijkingsmateriaal heb ik eigenlijk geen idee of dat goed overeenkomt met de woningtypering van het kadaster zelf, maar het aantal NULL (geen typering) waarden wilde ik toch verder in duiken.
Een voorbeeld van zo’n NULL geval is deze:
Deze is NULL omdat het verblijfsobject naar twee panden verwijst, waarbij het pandtype voor de een ‘H’ is en voor de andere ‘T’. In de bepaling van het woningtype valt dit verblijfsobject er dus uit volgens het algoritme (verblijfsobjecten met meerdere panden nemen het pandtype over als alle pandtypes gelijk zijn, zo niet dan valt het verlijfsobject er uit → NULL dus).
Een ander voorbeeld met dezelfde reden:
Op het oog zou bij het eerste voorbeeld een Hoekwoning passend zijn, het tweede voorbeeld een 2onder1kap (waarbij de buurwoning in dit geval ook een 2onder1kap zou moeten zijn en geen hoekwoning).
Ik ben aan het spelen gegaan met het algoritme en heb het uiteindelijk aangepast naar het volgende, waarbij ik wederom uitga van actuele panden die gekoppeld zijn aan actuele verblijfsobjecten en nummeraanduiding:
- Verblijfsobjecten zonder woonfunctie worden op ‘N’ gezet.
- Panden met meer dan 1 verblijfsobject zijn Appartementen, zet woningtype voor die verblijfsobjecten op ‘A’ als ze (ook) een woonfunctie hebben.
- Voor alle Verblijfsobjecten met (ook) woonfunctie - niet zijnde (A)ppartementen - die bestaan uit meerdere panden: voeg de panden samen (onthoud referenties naar oorspronkelijke pandnummers). Dit gaat om zo’n 22 duizend verblijfsobjecten.
- Vul die collectie van samengevoegde panden aan met alle andere actuele panden.
Bereken vervolgens alle buurpanden:
CREATE OR REPLACE TABLE tmp._08_neighbours AS
SELECT p1.id, p1.l_pnd_id, p2.id as neighbour
FROM tmp._07_tmp_pnd p1, tmp._07_tmp_pnd p2
WHERE st_dwithin(p1.geom, p2.geom, {dist});
Waarbij {dist} 10 cm is.
Een berekening die DuckDB overigens minder dan 10 seconden kost 
Daarna kunnen pandtypes worden bepaald:
Panden zonder buren → Vrijstaand (V)
Panden met 1 buur (die elkaars buur zijn) → 2onder1kap (K)
Andere Panden met 1 buur → Hoekwoning (H)
Panden met meerdere buren die nog niet als (A)ppartement zijn aangemerkt → Tussenwoning (T)
Vervolgens kan weer woningtype worden bepaald door het over te nemen van het pandtype (of van pandtypes bij meerdere panden, mits de types gelijk zijn).
Vergeleken met de oorspronkelijk methode zijn dit de verschuivingen, waarbij de rijen het oorspronkelijke woningtype zijn en de kolommen het woningtype met aangepast algoritme:
┌────────────┬─────────┬─────────┬─────────┬─────────┬────────┬─────────┬────────┐
│ woningtype │ aantal │ A │ T │ H │ K │ V │ NULL │
├────────────┼─────────┼─────────┼─────────┼─────────┼────────┼─────────┼────────┤
│ A │ 3308082 │ 3308082 │ 0 │ 0 │ 0 │ 0 │ 0 │
│ T │ 2427660 │ 0 │ 2425584 │ 1041 │ 1015 │ 20 │ 0 │
│ N │ 1354425 │ 0 │ 0 │ 0 │ 0 │ 0 │ 0 │
│ V │ 1078285 │ 0 │ 0 │ 0 │ 0 │ 1078285 │ 0 │
│ H │ 1049383 │ 0 │ 1 │ 1047841 │ 1541 │ 0 │ 0 │
│ K │ 725058 │ 0 │ 1 │ 5 │ 720892 │ 4160 │ 0 │
│ NULL │ 6762 │ 1488 │ 1058 │ 2230 │ 1842 │ 141 │ 3 │
└────────────┴─────────┴─────────┴─────────┴─────────┴────────┴─────────┴────────┘
Aantal niet bepaalde woningtypes is dus gedaald naar 3, en dat blijken dan ook verblijfsobjecten die verwijzen naar niet actuele panden (2x gesloopt, 1x ten onrechte opgevoerd).
De eerste twee voorbeelden zien er dan zo uit en hebben nu een op het oog passend type:
Hoekwoning i.p.v. NULL:
2onder1kap i.p.v. NULL en ook het buurpand is nu een 2onder1kap:
Een aantal verschuivingen zijn ook mooi verklaarbaar, zoals van Tussenwoning naar 2onder1kap hieronder: Met het oorspronkelijk algoritme heeft ieder (afzonderlijk) pand immers twee buren en is het geen appartement, zodat het wordt geclassificeerd als Tussenwoning. het aangepaste algoritme voegt de panden eerst samen, zodat ze maar 1 buur hebben (wederzijds, dus 2onder1kappers).
Twee voorbeelden waarbij deze aanpassing toch niet helemaal goed werkt of gek lijken:
De (enkele) verschuiving van K naar T ziet er zo uit op de kaart:
Strikt genomen moet dit wellicht toch een 2onder1kap zijn? Of toch niet? Het is zeker een gek geval
Een ander (en ook enkel) geval is deze van H → T:
Dit zou denk ik toch echt wel een hoekwoning moeten zijn, maar doordat de twee panden voor de bepaling worden samengevoegd heeft het ineens extra buren gekregen en is het daarmee een tussenwoning in plaats van een hoekwoning. Dit is nog oplosbaar door alleen panden samen te voegen als ze ook echt aan elkaar vast zitten (gelukkig gaat het maar om 1 geval).
Bovenstaande cijfers zijn van de bag extract van januari. De extract van februari is vanmiddag uitgekomen en heeft nog maar 1 onbepaalde woningtype in plaats van 3.
De parquet en geopackage bestanden van de nieuwste extract zijn zoals altijd hier te vinden en worden nachtelijks automatisch bijgewerkt.
Groetjes,
Remco
. Idee om ‘overig’ niet mee te nemen in berekening vind ik ook wel een goede; hun voorbeeld van woning naast garagebox wordt door mij inderdaad als tussenwoning getypeerd 
