woningwaardering 0.5.0a1

Berekent de punten van een woning op basis van het woningwaarderingsstelsel.

Woningwaardering

📊 Status

Het Microservices team van Woonstad Rotterdam is in Q1 2024 begonnen met het ontwikkelen met een open-source Python-package waarmee het mogelijk zal zijn om het puntensysteem van het woningwaarderingsstelsel toe te passen. We gaan hierbij uit van de VERA-standaard van de corporatiesector. Het doel is om tot een completere woningwaarderingsstelsel-berekening te komen dan die nu beschikbaar zijn via tools zoals bijvoorbeeld die van de huurcommissie.

Momenteel wordt er gewerkt aan de implementatie van de woningwaardering van zelfstandige woonruimten volgens het gepubliceerde beleidsboek van de huurcommissie in juli 2024. Het beleidsboek van januari 2024 voor zelfstandige woonruimten is afgerond voor zover deze geïmplementeerd kon worden en zal vanaf nu niet meer worden uitgebreid. Voor meer details over wat er precies is geïmplementeerd van het beleidsboek van januari 2024 verwijzen wij naar de documentatie over de implementatie van dit beleidsboek. Voor meer informatie over hoe documentatie van het beleidsboek is gemaakt, verwijzen wij naar het hoofdstuk Implementatie beleidsboek huurcommissie in deze README.

Voor vragen kunt u contact opnemen met Product Owner en mede-developer van Team Microservices Tomer Gabay of één van de andere maintainers van deze repo.

Inhoudsopgave

• Woningwaardering
  • Inhoudsopgave
  • 1. Opzet woningwaardering-package
    • Implementatie beleidsboek huurcommissie
    • Repository-structuur
    • Design
    • Lookup tabellen
  • 2. Contributing
    • Setup
    • Naamgeving van classes
      • Stelsels
      • Stelselgroepen
      • Stelselgroepversies
    • Testing
      • Conventies voor tests
      • Test modellen
    • Datamodellen
      • Datamodellen uitbreiden
    • Referentiedata
  • 3. Datamodel uitbreidingen
    • Ruimtedetailsoort kast
    • Verbonden ruimten
    • Gedeeld met aantal eenheden
    • Bouwkundige elementen

1. Opzet woningwaardering-package

Implementatie beleidsboek huurcommissie

Voor het berekenen van een woningwaardering worden de beleidsboeken van de Nederlandse Huurcommissie voor de waarderingstelsels voor zelfstandige en onzelfstandige woningen gevolgd. De beleidsboeken van de Huurcommissie Nederland volgen Nederlandse wet- en regelgeving zoals beschreven in Artikel 14 van het "Besluit huurprijzen woonruimte".

Om berekeningen te maken met betrekking tot een woningwaardering wordt het gepubliceerde beleid vertaald naar Python-code. Een woningwaardering wordt gemaakt op basis van woningelementen. De stelselgroepen waarop gescoord wordt, zijn vastgelegd in het woningwaarderingstelselgroep op www.coraveraonline.nl. Deze worden aangehouden in de opzet van de woningwaardering-package. Voor elke stelselgroep wordt een apart Python-object gemaakt met een naam die overeenkomt met woningwaarderingstelselgroep. Een stelselgroep-object zal een nieuwe versie krijgen wanneer nieuw gepubliceerde wet- en regelgeving, die is opgenomen in de beleidsboeken van de Nederlandse Huurcommissie, verschilt van de huidige berekening voor dat stelselgroep.

De woningwaardering package volgt de beleidsboeken van de Nederlandse Huurcommissie en daarmee de Nederlandse wet en regelgeving m.b.t. het waarderen van woningen. Tijdens de ontwikkeling van deze package komt het voor dat we inconsistenties in de beleidsboeken vinden of dat er ruimte is voor interpretatie. Daarnaast kan het voorkomen dat dat de VERA modellen, met eventuele uitbreidingen, niet toereikend zijn om de stelselgroep voglens het beleidsboek tot op de letter nauwkeurig te implementeren. In implementatietoelichting-beleidsboeken onderbouwen wij hoe elke stelselgroep is geïmplementeerd en welke keuzes daarin zijn gemaakt per jaar. In deze documenten wordt bijgehouden welke onderdelen van het beleidsboek wel en niet zijn geïmplementeerd per stelselgroep. De gepubliceerde tekst uit het beleidsboek wordt gekopieerd en wanneer een onderdeel niet in de code van de package is geïmplementeerd zal dit worden aangegeven met doorgestreepte tekst.
De reden van het niet implementeren van een regelonderdeel is vrijwel altijd dat het technisch niet mogelijk is op basis het inputmodel van de VERA-standaard. Een voorbeeld hiervan is dat voor oppervlakte van vertrekken in 2024 de minimale breedte van een vertrek over de volle lengte 1.5m moet zijn. Omdat wij alleen de totale oppervlakte binnenkrijgen via het inputmodel kunnen wij dit onderdeel van de regel niet implementeren. Dit betekent dat het aan de gebruiker is om met deze regel-onderdelen rekening te houden bij het eenheid-inputmodel. Een deel van de deze regelonderdelen wordt al afgevangen indien het eenheid-inputmodel voldoet aan de NEN-norm. Regels die wel zijn geimplementeerd zijn niet doorgestreept. Keuzes die zijn gemaakt en of interpretaties die zijn gedaan, worden in een gemarkeerd blok weergegeven zoals hieronder is gedaan.

Dit is een tekstblok waarmee commentaar van een developer wordt aangegeven in het beleidsboek.

Repository-structuur

De repository-structuur is ingedeeld volgens de referentiedata van stelselgroepen van de VERA-standaard; eerst de stelsels (bijvoorbeeld zelfstandig, onzelfstandig) en vervolgens de stelselgroepen (bijvoorbeeld Energieprestatie, Wasgelegenheid). In de folders van de stelselgroepen bevindt zich de code voor het berekenen van de punten per stelselgroep.

Design

Het design van de woningwaardering-package is zo gekozen dat stelselgroep-objecten en bijbehorende regels modulair zijn. Dit houdt in dat regels in een stelselgroep-object vervangbaar en inwisselbaar zijn, met als resultaat dat op basis van de gegeven input de woningwaardering berekend wordt met de juiste set aan stelselgroep-objecten en bijbehorende regels. Ook wanneer een wet verandert met ingang van een bepaalde datum zorgt de modulariteit ervoor dat de juiste regels worden gebruikt voor de stelselgroep. De woningwaardering-package selecteert op basis van een peildatum de juiste set aan regels die volgens de Nederlandse wet gelden voor de desbetreffende peildatum. Hieronder is het modulaire principe op basis van een peildatum schematisch weergegeven voor het stelselgroep-object OppervlakteVanVertrekken. Voor de duidelijkheid: Onderstaand voorbeeld is niet gebaseerd op een echte verandering in het beleidshandboek. Het voorbeeld laat zien hoe de berekening van de OppervlakteVanVertrekken afhangt van de peildatum. Op basis van de peildatum wordt voor de bovenste beleidsregel gekozen omdat die berekening geldig is voor de opgegeven peildatum.

Lookup tabellen

In lookup tabellen worden constanten en variabelen opgeslagen die nodig zijn bij het berekenen van de punten voor een stelselgroep. In de woningwaardering package wordt CSV gebruikt als bestandstype voor het opslaan van een lookup tabel. De keuze is op CSV gevallen omdat lookup data soms bestaat uit meerdere datarijen waardoor dit vaak minder leesbaar wordt wanneer dit bijvoorbeeld in json of yaml wordt opgeslagen. Voor VSCode-gebruikers is de extensie Excel Viewer van GrapeCity aan te raden. Met behulp van deze extensie kunnen CSV-bestanden als tabel weergegeven worden in VSCode. Hieronder is een voorbeeldtabel te zien zoals deze met Excel Viewer in VSCode wordt weergegeven.

Door gebruik van CSV-bestanden, wordt het selecteren van de juiste rij of waarde door middel van een peildatum vergemakkelijkt. In de woningwaardering-package wordt een peildatum gebruikt om de juiste waarde van bijvoorbeeld een variabele uit een tabel te selecteren. Dit kan worden gedaan op basis van de Begindatum en de Einddatum kolommen in een CSV-bestand. Wanneer er geen Begindatum of Einddatum is gespecificeerd, dan is deze niet bekend. Dit betekent niet dat er geen werkbare en geldige rij geselecteerd kan worden. Wel zou het kunnen dat er door het ontbreken van een Begindatum of Einddatum meerdere rijen geldig zijn voor een peildatum. In dit geval zal de woningwaardering-package een error geven die duidelijk maakt dat er geen geldige rij gekozen kan worden op basis van de peildatum voor het desbetreffende CSV-bestand.

Warnings

In de woningwaardering package worden UserWarnings gegenereerd wanneer de inputdata niet volledig of correct wordt aangeleverd. Deze waarschuwingen worden gegeven met een warning bericht en een type warning, bijvoorbeeld:

warnings.warn("Dit is een warning", UserWarning)

Standaard genereert de woningwaardering package een error wanneer een UserWarning wordt gegeven. Hoewel de package kan werken met incomplete data, is ervoor gekozen om standaard te falen bij incomplete inputdata, zodat de gebruiker hiervan op de hoogte wordt gebracht. Het is echter ook mogelijk om het warning filter terug te zetten naar de standaardinstellingen, waardoor een warning m.b.t. incomplete data niet leidt tot een error, maar slechts een warning:

warnings.simplefilter("default", UserWarning)

Alle waarschuwingen die worden gegenereerd met warnings.warn(), worden standaard gelogd met logger.warning() en weergegeven in het standaardfout bestand. Mocht door de gebruiker logging worden uitgezet, dan zullen de UserWarnings altijd te zien zijn voor de gebruiker in de output van de stderr.

Warning vs Exception

Er wordt doorgaans in de stelgroepversies gebruik gemaakt van warnings.warn() in plaats van het raisen van een exception. Hierdoor bestaat de mogelijkheid om stelselgroepen te berekenen voor stelselgroepen waarvoor de data wel compleet genoeg is, mits de warnings.simplefilter naar default is gezet.

2. Contributing

Setup

Om de woningwaardering-package en de daarbij behorende developer dependencies te installeren, run onderstaand command:

git clone https://github.com/woonstadrotterdam/woningwaardering.git
cd woningwaardering
pip install -e ".[dev]"

Naamgeving van classes

Voor de naamgeving van de classes in de woningwaardering module volgen we de VERA referentiedata. Deze referentiedata is gedefinieerd in de referentiedata enums, te vinden onder woningwaardering/vera/referentiedata.

Genereren opzet woningwaarderingstelsels en -groepen

Om alle onderstaande naamgevingen correct en consequent door te voeren, is er een task beschikbaar die de opzet van een woningwaarderingstelsel en -groep volgens deze regels voor je kan aanmaken.

Zorg er voor dat Task en de dev dependencies zijn geïnstalleerd:

pip install -e ".[dev]"

Vervolgens voer je onderstaand command uit:

task genereer-opzet-woningwaarderinggroep

Dit script stelt je een aantal vragen, waarna de code en configuratie voor het stelsel en de stelselgroep aangemaakt worden.

Stelsels

De namen voor de stelsels zijn te vinden in de Woningwaarderingstelsel Enum. Bijvoorbeeld: het stelsel voor zelfstandige woonruimten wordt aangeduid als Woningwaarderingstelsel.zelfstandige_woonruimten. De implementatie van dit Stelsel bevindt zich in woningwaardering/stelsels/zelfstandige_woonruimten/zelfstandige_woonruimten.py. De begin- en einddatum van de geldigheid van een stelsel wordt vastgelegd in de configuratie .yml van het betreffende stelsel. Bijvoorbeeld: voor zelfstandige woonruimten is dit woningwaardering/stelsels/config/zelfstandige_woonruimten.yml

Stelselgroepen

De namen voor de stelselgroepen zijn te vinden in de Woningwaarderingstelselgroep Enum. Bijvoorbeeld: de stelselgroep voor oppervlakte van vertrekken wordt aangeduid als Woningwaarderingstelselgroep.oppervlakte_van_vertrekken. De implementatie van deze Stelselgroep bevindt zich in woningwaardering/stelsels/zelfstandige_woonruimten/oppervlakte_van_vertrekken/oppervlakte_van_vertrekken.py. De begin- en einddatum van de geldigheid van een stelselgroep en de volgorde waarin de stelselgroepen moeten worden uitgevoerd wordt vastgelegd in de configuratie .yml van het betreffende stelsel.

Stelselgroepversies

De daadwerkelijke implementatie van een stelselgroep is een Stelselgroepversie. Voor stelselgroepversies wordt de naam van de stelselgroep gevolgd door het jaar waarin de versie van de stelselgroep in gebruik gaat. Bijvoorbeeld: de implementatie van de Stelselgroepversie voor oppervlakte van vertrekken die in gaat in het jaar 2024 bevindt zich in woningwaardering/stelsels/zelfstandige_woonruimten/oppervlakte_van_vertrekken/oppervlakte_van_vertrekken_jan_2024.py. Omdat het lastig is met terugwerkende kracht te achterhalen in welk jaar een versie van een stelselgroep ingegaan is, gebruiken we voor de eerste versie van een stelselgroep het jaar van de implementatie van de stelselgroep in deze module. Wanneer de berekening van een stelselgroep in een bepaald jaar niet wijzigt, wordt er geen nieuwe stelselgroepversie aangemaakt. De begin- en einddatum van de geldigheid van een stelselgroepversie wordt vastgelegd in de configuratie .yml van het betreffende stelsel.

Releasemanagement

Versienummering

Voor versienummering maken we gebruik van SemVer:

Bij SemVer wordt een versienummer in de vorm MAJOR.MINOR.PATCH gebruikt, waarbij elk element als volgt wordt verhoogd:

• MAJOR wordt verhoogd bij incompatibele API-wijzigingen,
• MINOR wordt verhoogd bij het toevoegen van functionaliteit die compatibel is met de vorige versie, en
• PATCH wordt verhoogd bij compatibele bugfixes.

Er zijn aanvullende labels beschikbaar voor pre-release en build-metadata om toe te voegen aan het MAJOR.MINOR.PATCH-formaat.

Bijvoorbeeld: stel dat de huidige versie 0.1.3-alpha is.

• De suffix -alpha wordt gebruikt zolang de software nog niet volledig is, bijvoorbeeld zolang nog niet alle beoogde stelselgroepen geïmplementeerd zijn
• Wanneer een nieuwe release alleen compatibele bugfixes of updates van dependencies bevat, wordt de nieuwe versie 0.1.4-alpha
• Wanneer een nieuwe release ook compatibele nieuwe functionaliteit toevoegt, bijvoorbeeld de implementatie van een nieuwe stelselgroep, dan wordt de nieuwe versie 0.2.0-alpha.
• Wanneer alle beoogde stelselgroepen geïmplementeerd zijn, wordt de nieuwe versie 1.0.0-beta. De publieke api mag vanaf dan enkel nog backwards-compatible wijzigen.
• Wanneer de software volledig is en in productie genomen wordt, wordt de nieuwe versie 1.0.0
• Wanneer er een incompatible wijziging is in de VERA modellen, wordt de nieuwe versie 2.0.0, eventueel met het -alpha of -beta label, afhankelijk van de implementatiestatus.

Releaseproces

Om een nieuwe release te starten, moet er een Git tag aangemaak worden volgens het format v<versienummer>. De prefix v geeft aan dat de tag een versiepunt markeert.

Bijvoorbeeld:

$ git tag v0.2.3-alpha
$ git push --tags

Hiermee start het releaseproces, gedefinieerd in een GitHub workflow: .github/workflows/publish-to-pypi.ymls

In dit proces wordt een package aangemaakt met een Python versienummer, afgeleid van het SemVer nummer in de tag. Bijvoorbeeld: 0.2.3-alpha wordt 0.2.3a0

De package wordt eerst gepubliceerd op TestPyPi. Na goedkeuring wordt de package naar PyPi gepubliceerd. Daarna wordt er een release aangemaakt in GitHub, met een changelog met de titel en link naar alle pull requests die deel uitmaken van deze release.

Testing

Voor het testen van code wordt het pytest framework gebruikt. Meer informatie is te vinden over het framework. Passende tests worden altijd met de nieuw geschreven code opgeleverd. Er zijn verschillende "test-scopes" te bedenken, zoals het testen van details en specifieke functies. Daarnaast is het testen van een hele keten of stelselgroep-object ook vereist. Bij het opleveren van nieuwe code moet aan beide test-scopes gedacht worden.

Test coverage rapport

Na het uitvoeren van pytest wordt er een code coverage report getoond. Hierin is per file te zien welk percentage van de code in de files getest is. Daarnaast wordt de code coverage ook naar een file lcov.info geschreven. Die kan gebruikt worden in VSCode om de coverage weer te geven met een plugin zoals "Coverage Gutters".

Conventies voor tests

Tests worden toegevoegd aan de tests-folder in de root van de repository. Voor de structuur in de tests-folder wordt dezelfde structuur aangehouden als die in de woningwaardering-folder. De naam van het bestand waarin de tests staan geschreven is test_<file_name>.py. Elke testfunctie begint met test_, gevolgd door de naam van de functie of class die getest wordt, bijvoorbeeld def test_<functie_naam>() of def test_<ClassNaam>(). Hierin wordt de naam de van de functie of class exact gevolgd. Voor pytest is test_ een indicator om de functie te herkennen als een testfunctie.

Stel dat de functionaliteiten van woningwaardering/stelsels/zelfstandige_woonruimten/oppervlakte_van_vertrekken/oppervlakte_van_vertrekken.py getest moeten worden, dan is het pad naar het bijbehorende testbestand tests/stelsels/zelfstandige_woonruimten/oppervlakte_van_vertrekken/test_oppervlakte_van_vertrekken.py. In test_oppervlakte_van_vertrekken.py worden testfuncties geschreven met bijbehorende naamconventies. Hieronder is de functienaamconventie en python code weergegeven voor het testen van een losse functie (def losse_functie):

def test_losse_functie() -> None:
    assert losse_functie() == True

Als er een class getest wordt, bijvoorbeeld OppervlakteVanVertrekken, dan is de testfunctie opzet als volgt:

def test_OppervlakteVanVertrekken():
    opp_v_v = OppervlakteVanVertrekken()
    assert self.opp_v_v.functie_een() == 1
    assert self.opp_v_v.functie_twee() == 2

Test modellen

Om de woningwaardering-package zo nauwkeurig mogelijk te testen, zijn er eenheidmodellen (in .json format) toegevoegd in tests/data/.... De modellen volgen de VERA standaard en dienen als een testinput voor de geschreven tests. Omdat er gewerkt wordt met peildata en de berekening van een stelselgroep per jaar kan veranderen worden de outputmodellen per jaar opgeslagen. Zie bijvoorbeeld de folder tests/data/zelfstandige_woonruimten/output/peildatum/2024-01-01. Deze bevat de output voor de inputmodellen met als peildatum 2024-01-01 of later. Op deze manier kunnen dezelfde inputmodellen in tests met verschillende peildata getest worden. De resulterende outputs zijn met de hand nagerekend om de kwaliteit van de tests te garanderen.

Om heel specifieke regelgeving uit het beleidsboek te testen, kunnen er handmatig test modellen gemaakt worden. Deze test modellen worden opgeslagen in de test folder van een stelselgroep waarvoor de specifieke regelgeving die getest wordt. Zie bijvoorbeeld tests/data/zelfstandige_woonruimten/stelselgroepen/oppervlakte_van_vertrekken/input/gedeelde_berging.json: hier is een gedeelde berging gedefinieerd om een specifieke set van regels in oppervlakte_van_vertrekken te testen.

Logger Guidelines

In de woningwaardering package wordt de logger van loguru gebruikt voor logging. Voor het developen in de woningwaardering package worden de logging levels DEBUG, INFO, WARNING en ERROR gebruikt. De verschillende levels worden gebruikt voor de verschillende types van logging, zoals beschreven in de python 3.11 documentatie. Hieronder is de tabel van de python documentatie gekopieerd waarin de verschillende logging levels staan beschreven. De tabel is aangevuld met de kolom "Gebruik Woningwaardering Package", waarin wordt aangegeven met voorbeelden welke soort logging gedaan wordt op de verschillende logging levels.

Level	Numerieke waarde	Wat het betekent / Wanneer te gebruiken	Gebruik Woningwaardering Package
NOTSET	0	Wanneer ingesteld op een logger, geeft dit aan dat bovenliggende loggers geraadpleegd moeten worden om het effectieve niveau te bepalen. Als dit nog steeds NOTSET oplevert, worden alle gebeurtenissen gelogd. Wanneer ingesteld op een handler, worden alle gebeurtenissen afgehandeld.	Wordt niet gebruikt in de woningwaardering package.
DEBUG	10	Gedetailleerde informatie, meestal alleen van belang voor een ontwikkelaar die een probleem probeert te diagnosticeren.	Wordt alleen gebruikt om details weer the geven aan een developer. bijvoorbeeld: wat een functie terug geeft of welke type een variabele heeft.
INFO	20	Bevestiging dat alles werkt zoals verwacht.	Bevat beschrijvingen van de werking van de code. Bijvoorbeeld: Het berekende resultaat voor een stelselgroep of welke code op basis van de input data wordt gerund.
WARNING	30	Een indicatie dat er iets onverwachts is gebeurd, of dat er in de nabije toekomst een probleem kan optreden (bijv. 'schijfruimte bijna vol'). De software werkt nog steeds zoals verwacht.	Een warning wordt gelogd wanneer er bijvoorbeeld iets mist in de input data of een functie deprecated is. Dit kan er toe leiden dat bepaalde code niet uitgevoerd kan worden. Voor warnings aan de package gebruiker, wordt altijd warnings.warn() gebruikt. Zie het kopje warnings voor meer informatie over het geven van warnings voor gebruikers en hoe hier mee omgegaan wordt.
ERROR	40	Vanwege een ernstiger probleem heeft de software een bepaalde functie niet kunnen uitvoeren.	Een error wordt in de woningwaardering package gelogd wanneer het gedrag verwacht is en de error een extra toelichting nodig heeft. Wanneer een error kritiek is voor het functioneren van de package wordt deze error geraisd. Ook kan het voorkomen dat de verwachte error toegestaan is. Dit kan bijvoorbeeld in een try/except patroon. Er kan dan gekozen worden om de error te loggen maar niet te raisen. Hierdoor kan het programma wel doorgaan en is het wel duidelijk dat er een exception heeft plaatsgevonden. Zoals een error geraisd kan worden en het programma kan laten stoppen, zo kunnen warnings ook geraisd worden om het progromma te stoppen.
CRITICAL	50	Een ernstige fout, die aangeeft dat het programma zelf mogelijk niet meer kan blijven draaien.	Wordt niet gebruikt in de woningwaardering package.

Datamodellen

De datamodellen in de woningwaardering package zijn gebaseerd op de OpenAPI-specificatie van het VERA BVG domein.

Wanneer je deze modellen wilt bijwerken, zorg er dan voor dat Task en de dev dependencies zijn geïnstalleerd:

pip install -e ".[dev]"

Vervolgens kan je met dit commando de modellen in deze repository bijwerken:

task genereer-vera-bvg-modellen

De classes voor deze modellen worden gegeneerd in woningwaardering/vera/bvg/generated.py

Datamodellen uitbreiden

Wanneer de VERA modellen niet toereikend zijn om de woningwaardering te berekenen, kan het VERA model uitgebreid worden.

Maak hiervoor altijd eerst een issue aan in de VERA OpenApi repository.

Maak vervolgens in de map woningwaardering/vera/bvg/model_uitbreidingen een class aan met de missende attributen. De naamgeving voor deze classes is: _{classNaam}.

Zet in de class bij het toegevoegde attribuut een comment met een link naar het issue in de VERA OpenApi repository zodat duidelijk is waar de toevoeging voor dient, en we kunnen volgen of de aanpassing is doorgevoerd in de VERA modellen.

Daarnaast neem je in de class een docstring op met uitleg over het gebruik en doel van de uitbreiding.

Bijvoorbeeld: voor het uitbreiden van de class EenhedenRuimte maak je een class _EenhedenRuimte aan:

from typing import Optional

from pydantic import BaseModel, Field


class _EenhedenRuimte(BaseModel):
    # https://github.com/Aedes-datastandaarden/vera-openapi/issues/44
    gedeeld_met_aantal_eenheden: Optional[int] = Field(
        default=None, alias="gedeeldMetAantalEenheden"
    )
    """
    Het aantal eenheden waarmee deze ruimte wordt gedeeld. Deze waarde wordt gebruikt bij het berekenen van de waardering van een gedeelde ruimte met ruimtedetailsoort berging.
    """

De task genereer-vera-bvg-modellen zal de body van deze classes samenvoegen met de gelijknamige VERA class en zo de toegevoegde attributen beschikbaar maken.

Referentiedata

We maken gebruik van de VERA Referentiedata.

Wanneer je de referentiedata wilt bijwerken, zorg er dan voor dat Task is geïnstalleerd

Vervolgens kan je met dit commando de referentiedata in deze repository bijwerken:

task genereer-vera-referentiedata

De referentiedata wordt gegenereerd in woningwaardering/vera/referentiedata

3. Datamodel uitbreidingen

Tijdens de ontwikkeling van de woningwaardering-package komt het voor dat de VERA modellen niet toereikend zijn om de punten voor een stelselgroep te berekenen. Daarom kunnen er indien nodig uitbreidingen gemaakt worden op de VERA modellen. In deze sectie onderbouwen en documenteren wij deze uitbreidingen. In de sectie Referentiedata wordt uitgelegd hoe uitbreidingen toe te voegen als contributor van dit project.

Ruimtedetailsoort kast

Binnen het woningwaarderingsstelsel mag onder bepaalde voorwaarden de oppervlakte van vaste kasten worden opgeteld bij de ruimte waar de deur van de kast zich bevindt. Als hier bij het inmeten geen rekening mee gehouden is, kan het attribuut verbonden_ruimten gebruikt worden om de met een ruimte verbonden vaste kasten mee te laten nemen in de waardering. Hiervoor is de VERA referentiedata binnen deze repository uitgebreid met ruimtedetailsoort Kast, code KAS.

Verbonden ruimten

Het attribuut verbonden_ruimten bevat de ruimten die in verbinding staan met de ruimte die het attribuut bezit. verbonden_ruimten wordt gebruikt bij het berekenen van de waardering van kasten en verwarming van ruimten. verbonden_ruimten heeft type Optional[list[EenhedenRuimte]] en is een uitbreiding op EenhedenRuimte. Voor deze uitbreiding staat een github issue open ter aanvulling op het VERA model.

Gedeeld met aantal eenheden

Het attribuut gedeeld_met_aantal_eenheden geeft het aantal eenheden weer waarmee een bepaalde ruimte wordt gedeeld. Dit attribuut wordt gebruikt bij het berekenen van de waardering van een gedeelde ruimte met ruimtedetailsoort berging. gedeeld_met_aantal_eenheden heeft als type Optional[int]. Er staat een github issue open voor deze aanvulling op het VERA model: https://github.com/Aedes-datastandaarden/vera-openapi/issues/44

Bouwkundige elementen

In de beleidsboeken wordt soms op basis van een bouwkundig element dat aanwezig is in een ruimte, een uitzondering of nuance op een regel besproken. Dit kan bijvoorbeeld tot gevolg hebben dat er punten in mindering worden gebracht, of punten extra gegeven worden. Bijvoorbeeld bij de berekening van de oppervlakte van een zolder als vertrek of als overige ruimte is er informatie nodig over de trap waarmee de zolder te bereiken is. Daartoe is het VERA model EenhedenRuimte uitgebreid met het attribuut bouwkundige_elementen met als type Optional[list[BouwkundigElementenBouwkundigElement]]. Er staat een github issue open om bouwkundige_elementen standaard in het VERA model toe te voegen: https://github.com/Aedes-datastandaarden/vera-openapi/issues/46

Verwarmd

In de VERA standaard is nog geen mogelijkheid om aan te geven of een ruimte verwarmd is. Het attribuut verwarmde_vertrekken_aantal bestaat wel, maar dit bestaat op niveau van de eenheid en daarin bestaat geen onderscheid tussen vertrekken en overige ruimten. Dit is aangekaart in deze twee issues:

• https://github.com/Aedes-datastandaarden/vera-openapi/issues/41
• https://github.com/Aedes-datastandaarden/vera-referentiedata/issues/100