CConstaterende datAmsterdam
Koppel je AI →
Document · PDF

Bijlage 3 - Notitie Grondwaardebepaling 2024 - SEO.pdf

Raadscommissie Ruimtelijke ordening 7 februari 2024, gemeente AmsterdamBij agendapunt: Kennisnemen van het beleid Grondwaardebepaling voor bestaande erfpachtrechten 2024 en kennisnemen van de daaruit voortvloeiende lijst met buurtstraatquotes 2024. (VN2023-023089)7.364 woorden

Open het PDF bij de gemeente ↗Naar de vergadering →

Tekst van het document

Uit het bestand gehaald, zonder opmaak, tabellen en afbeeldingen

GRONDWAARDEBEPALING AMSTERDAM 2024 NOTITIE

AUTEURS CHRISTIAAN BEHRENS, STEF KONIJN, & ANTONIA PETRAT IN OPDRACHT VAN GEMEENTE AMSTERDAM AMSTERDAM, 12 DECEMBER 2023

SEO-notitie nr. 2023-130 Informatie & Disclaimer SEO Economisch Onderzoek heeft op de verkregen informatie en data geen onderzoek uitgevoerd dat het karakter draagt van een accountantscontrole of due diligence. SEO is niet verantwoordelijk voor fouten of omissies in de verkregen informatie en data. Copyright © 2023 SEO Amsterdam. Alle rechten voorbehouden. Het is geoorloofd gegevens uit deze notitie te gebruiken in artikelen, onderzoeken en collegesyllabi, mits daarbij de bron duidelijk en nauwkeurig wordt vermeld. Gegevens uit deze notitie mogen niet voor commerciële doeleinden gebruikt worden zonder voorafgaande toestemming van de auteur(s). Toestemming kan worden verkregen via secretariaat@seo.nl.

Roetersstraat 29

+31 20 399 1255

1018 WB, Amsterdam

secretariaat@seo.nl www.seo.nl

GRONDWAARDEBEPALING AMSTERDAM 2024

1

Inleiding Het college van burgemeester en wethouders van de gemeente Amsterdam (hierna: “de gemeente”) heeft in 2017 besloten tot een nieuw beleid ten aanzien van grondwaardebepaling voor bestaande erfpachtrechten. De gemeenteraad heeft ingestemd met dit collegebesluit. Onderdeel van het collegebesluit vormt een jaarlijkse toetsing op de bepaling van de grondwaarde uit te voeren door een externe commissie van deskundigen. De toetsing heeft tot doel om na te gaan of de in het beleid opgenomen methodiek voor grondwaardebepaling correct is toegepast. De gemeente heeft SEO Economisch Onderzoek (hierna: “SEO”) opdracht gegeven om deze toetsing in 2023 uit te voeren. Deze toetsing betreft de grondwaardebepaling voor bestaande erfpachten voor 2024. In voorgaande jaren heeft SEO deze toetsing ook uitgevoerd. Het onderzoeks- en beoordelingsteam van SEO bestaat uit: ● A. Petrat M.Sc., onderzoeker bij SEO; ● S. Konijn M.Sc., onderzoeker bij SEO; ● Dr. C. Behrens, senior projectleider bij SEO; ● Prof. dr. Erik Brouwer, clusterhoofd bij SEO en hoogleraar duurzame innovatie en mededinging aan Nyenrode Business Universiteit. Prof. dr. H.L.F. de Groot, hoogleraar regionaal economische dynamiek aan de Vrije Universiteit Amsterdam, onderwerpt in opdracht van de gemeente Amsterdam de werkwijze, de bevindingen en de aanbevelingen zoals beschreven in deze notitie aan een second opinion.

In deze notitie beschrijven we achtereenvolgens: ● de opdracht en reikwijdte; ● de gehanteerde werkwijze bij de toetsing/beoordeling; ● de bevindingen, conclusies en aanbevelingen.

Opdracht en reikwijdte De opdracht aan SEO is middels deze toetsing antwoord te geven op de volgende onderzoeksvraag: Wordt de toepassing van het beleid van de gemeente Amsterdam voor grondwaardebepaling voor bestaande erfpachtrechten op een correcte wijze uitgevoerd? Net als in de voorgaande jaren zal SEO bij de beantwoording van deze onderzoeksvraag toetsen of: 1. de gekozen uitgangspunten en parameters in het beleid, en de beschikbaar gestelde data, op juiste wijze tot uitdrukking komen in de gehanteerde rekenmethoden waarmee de grondwaarde wordt bepaald; 2. de gehanteerde rekenmethoden technisch correct worden toegepast en uitgevoerd. De eerste toetsing geeft antwoord op de vraag of de methode aansluit op het beleid. De tweede toetsing geeft antwoord op de vraag of de technische uitvoering — het toepassen van de methode — correct plaatsvindt. De totale beoordeling heeft betrekking op de wijze van uitvoering van het beleid ten aanzien van grondwaardebepaling en niet op het beleid zelf. Additioneel in de beoordeling van dit jaar is een controle op de informatie die de gemeente via de website verstrekt over de grondwaardebepaling bestaande erfpachten en de berekening van de

GRONDWAARDEBEPALING AMSTERDAM 2024

2

buurtstraatquote.1 We controleren in hoeverre deze informatie in lijn is met het huidig beleid en de op dit moment gehanteerde rekenmethoden. De beoordeling is beperkt tot de grondwaardebepaling voor bestaande erfpachtrechten voor woningen, zoals omschreven in het document ‘De grondwaardebepaling voor bestaande erfpachtrechten 2024’ (hierna "Beleid Grondwaardebepaling").2 In dit document is het beleid van de gemeente ten aanzien van grondwaardebepaling bij erfpachtrechten beschreven. Naast deze documenten heeft SEO ook drie interne documenten ontvangen met daarin technische toelichtingen op de gekozen uitgangspunten, databewerkingen en werkinstructies met de gehanteerde rekenmethoden.3 Ook staan hierin de voorgenomen aanpassingen voor 2024. Tot slot kijken we ook naar de online beschikbare notitie 'Onbezwaarde waarde, maatwerk BSQ en procedure van bedenkingen' uit 2019, maar deze is sindsdien niet vernieuwd. Om de onderzoeksvraag te beantwoorden heeft SEO de bestanden ontvangen waarmee de technische berekeningen door de gemeente zijn uitgevoerd.4 Deze bestanden bevatten de regels en stappen waarmee de berekeningen door de gemeente zijn uitgevoerd en deze resulteren in de buurtstraatquotes (BSQ) voor 2024. De gemeente heeft dit jaar de stap vooruit gemaakt om de berekeningen uit te voeren (te programmeren) in R.

Dit is een open source omgeving voor (statistische) berekeningen en data-analyse. Verder is een workflow met berekeningen ontvangen voor het programma KNIME. KNIME is de omgeving waarin de gemeente vorig jaar de berekeningen heeft uitgevoerd. Box 1 in de volgende sectie geeft een verdere uitleg van de programma’s R en KNIME.5 Daarnaast heeft SEO de data ontvangen die de input vormen van de berekeningen.6 In het vervolg van deze notitie noemen we dit de inputbestanden. Ten slotte heeft SEO een R- en KNIME-outputbestand ontvangen met daarin een de resulterende lijst met buurtstraatquotes bepaald aan de hand van het beleid, de workflows en inputbestanden.7 Deze documenten en bestanden — het beleidsdocument, de R-scripts, KNIME-workflow, in- en outputbestanden — vormen het basismateriaal waarmee de beoordeling is uitgevoerd. Tot de opdracht behoort het controleren van de bestanden waarmee de technische berekeningen door de gemeente zijn uitgevoerd. Niet tot de opdracht behoort het controleren van de data in de door de gemeente 1

2

3

4 5 6

7

Zie https://www.amsterdam.nl/wonen-leefomgeving/erfpacht/nieuw-beleid/grondwaardebepaling/ en https://www.amsterdam.nl/wonen-leefomgeving/erfpacht/buurtstraatquote-(bsq)/. Vastgesteld in het college van burgemeester en wethouders van 9 mei 2017, behandeld in de gemeenteraad op 28 juni 2017, en gewijzigd naar aanleiding van de collegebesluiten van 31 oktober 2017, 6 februari 2018, 11 december 2018, 19 november 2019, 8 december 2020 (verlengd n.a.v. collegebesluit 1 maart 2022), 10 januari 2023, en gewijzigd ten behoeve van de BSQ 2024. De meest recente openbare versie van dit beleidsdocument is te vinden via https://www.amsterdam.nl/wonen-leefomgeving/erfpacht/nieuw-beleid/grondwaardebepaling/. Deze bestanden genaamd ‘20221013 documentatie BSQ 2024 v1.0’ (hierna: “Procesbeschrijving”); ‘20231013 concept Nota Grondwaardebepaling bestaande erfpachtrechten 2024’; en ‘20231013 Memo Voorgenomen aanpassingen BSQ 2024’ zijn ontvangen op 18 oktober 2023. Deze bestanden genaamd ‘BSQ_v0.R’; ‘BSQ_test_v0.R’; en ‘path-define_toetsing_v0.R’ zijn ontvangen op 18 oktober 2023. Dit bestand genaamd ‘BSQ-2024.knwf’ is ook ontvangen op 18 oktober 2023.

Deze bestanden zijn ‘230907_WOZ.xlsx‘; ‘20220920 Gebiedstyperingen buurtcode nieuw.csv‘; ‘20230927_Hermes.csv‘; ‘20230927_HermesKadaster.csv‘; ‘20231002_WOZ deelcodes Tools.csv‘; ‘20231002_WOZkadaster.csv‘; ‘20231005_WOZ_informatie.csv‘; ‘20231011_WOZ_Tools.csv‘; ‘A1 20231018 HBK M3E A1.csv‘; ‘A2 20231018 HBK M3E A2.csv‘; ‘A3 20220728 HBK M3E A3.csv‘; ‘A4 20231017 HBK M3E A4.csv‘; ‘A5.1 20220728 HBK M3E A5.1.csv‘; ‘Adressen.csv‘; ‘gebieden-stadsdelen.csv‘; en ‘index_herbouwkosten.xlsx‘ en zijn ontvangen op 23 oktober 2023. Na een tussentijdse bijeenkomst volgde ook de vernieuwde ‘A1 20231114 HBK M3E A1.csv’ op 14 november. De gemeente en SEO hebben een overeenkomst getekend die toeziet op de vertrouwelijkheid van deze bestanden. Na een tussentijdse bijeenkomst is het bestand ‘Knime_BSQ.csv’ op 14 november ontvangen door SEO en de outputbestanden ‘R_BSQ_per_buurtstraat.csv’, ‘R_BSQ_per_wozobject.csv’ en ‘Knime_BSQ_per_buurtstraat.csv’ op 23 november.

GRONDWAARDEBEPALING AMSTERDAM 2024

3

geleverde bronbestanden die niet afhankelijk zijn van het beleid. De data die voor deze beoordeling zijn gebruikt, zijn verkregen van de gemeente. Aangezien SEO op deze data zelf geen controle heeft uitgevoerd, geeft het derhalve geen oordeel over de juistheid van deze data.

Werkwijze De beoordeling is in een aantal opeenvolgende stappen uitgevoerd. De beoordeling is uitgevoerd tussen 6 oktober (startoverleg) en 12 november 2023. De eerste stap betrof een startoverleg met de gemeente op 6 oktober 2023 om het plan van aanpak en werkafspraken te maken. De gemeente heeft op 18 oktober het noodzakelijke materiaal (het beleidsdocument, de procesbeschrijving, R-script en de KNIME-workflow) aan SEO opgeleverd, op 23 oktober de inputbestanden, op 14 november het KNIME-outputbestand en een vernieuwde versie van een inputbestand, en op 23 november het R-outputbestand per buurtstraat en per WOZ-object. De tweede stap betrof het bestuderen en analyseren van dit materiaal. Er zijn verschillende toetsen uitgevoerd op de gehanteerde methoden en de toegepaste stappen en achterliggende rekenregels. In deze stap is gecontroleerd of: ● het R-script zoals opgesteld door de gemeente leidt tot de resultaten zoals gebruikt door de gemeente; ● de koppeling van de bronbestanden door de gemeente correct is uitgevoerd; ● de stappen en regels in het R-script technisch correct zijn uitgevoerd; ● de stappen en regels in het R-script aansluiten op het voorgestelde beleid; ● het voorgestelde beleid tot uitdrukking komt in het R-script; ● de documentatie en het versiebeheer voldoen. De R-scripts zijn volledig gecontroleerd; er is dus geen steekproef gebruikt.

Dit wil zeggen dat alle regels in de betreffende R-scripts zijn gecontroleerd. Deze controles zijn uitgevoerd in oktober en november 2023. Naast deze controle in R zijn de belangrijkste en meest foutgevoelige stappen van de berekening in een alternatief softwarepakket nagebouwd. Hiervoor is Stata gebruikt. Het gaat hierbij dan om het inlezen van de data, het toepassen van bepaalde selecties, het wijzigen van de dimensies (meeteenheden) van de data – bijvoorbeeld van objectniveau naar kadastraal nummer – en het combineren van datasets. De consistentie is gevalideerd via beschrijvende statistiek tussen twee stappen, zoals het aantal waarnemingen en het minimum, maximum en het gemiddelde van de belangrijkste variabelen. Box 1 geeft een verdere technische toelichting op onze aanpak en gebruik van de verschillende softwarepakketten in de beoordeling. De controles zijn door drie onderzoekers van SEO onafhankelijk van elkaar gecontroleerd waarna de bevindingen onderling vergeleken en gevalideerd zijn. De vierde onderzoeker heeft de bevindingen kritisch tegen gelezen. Vervolgens zijn de bevindingen in de vorm van een conceptnotitie op 24 november 2023 gedeeld met prof. dr. H.L.F. de Groot en de gemeente. Box 1

Stata is gebruikt om foutgevoelige stappen uit R en KNIME integraal na te bouwen

KNIME KNIME heeft een grafische gebruikersomgeving en kent geen integrale syntax die stap voor stap door de gehele berekening gaat. De werkwijze in KNIME bestaat uit losse blokken met uit te voeren opdrachten, zogeheten 'nodes'. Deze nodes selecteren, filteren, wijzigen of combineren bijvoorbeeld bepaalde gegevens en dienen handmatig te worden bewerkt. De nodes bevatten mogelijk regels code (in JavaScript) die bijvoorbeeld

GRONDWAARDEBEPALING AMSTERDAM 2024

4

specificeren welke aanpassingen voor welke objecten gelden. De mogelijke regels code zijn niet integraal — dus over de hele berekening — uit te lezen. De gemeente heeft de KNIME-workflow van vorig jaar aangepast door de beleidswijzigingen door te voeren. Dit betekent dat de output van de KNIME-workflow vergeleken kon worden met de uiteindelijke BSQ 2024 op basis van een ander programma.

R R heeft een command-line-interface met een integraal overzicht van de syntax met alle regels code. In R kan gebruik worden gemaakt van verschillende packages met daarin (zelfgecreëerde) functies. Daarnaast is het mogelijk om formules, lijsten en (numerieke) aannames op te slaan in de environment en deze later in de code toe te passen. SEO heeft de R-scripts volledig gecontroleerd. De tussentijdse stappen, zoals de datakoppeling, zijn onderzocht door de beschrijvende statistieken (aantal observaties, gemiddelde en extremen per variabele) te controleren en de toegepaste stappen met het Beleid Grondwaardebepaling en de Procesbeschrijving te vergelijken.

Stata R is zeer gebruiksvriendelijk en flexibel in het programmeren, maar kent relatief weinig ingebouwde foutmeldingen en waarschuwingen rondom databewerkingen zoals het koppelen van databestanden. Als additionele check heeft SEO daarom ook met een derde programma, Stata, verschillende stappen van de R-code nagebouwd. R en Stata zijn substituten, net als R kent Stata een command-line-interface en biedt het de mogelijkheid voor het programmeren en runnen van de integrale code. Specifiek hebben we de zogenoemde “Stap 1” integraal nagebouwd, deze stap behelst al het inlezen van de data, het koppelen van de databestanden en het selecteren van de relevante observaties. De uitkomst van “Stap 1” is het databestand waarmee vervolgens in “Stap 2” de daadwerkelijke berekeningen plaatsvinden. Voor “Stap 2” zijn enkele cruciale onderdelen nagebouwd in Stata, met daarbij de focus op het koppelen van bestanden en het aggregeren van de uitkomsten op het juiste ruimtelijke niveau (buurtstraat, wijk, object etc.).

De derde stap betrof het bespreken van de bevindingen. SEO presenteerde de voorlopige algemene bevindingen en een lijst met vragen tijdens een tussenbijeenkomst met de gemeente op 8 november. Op 14 november heeft de gemeente schriftelijk commentaar geleverd op de tussentijdse bevindingen. Vervolgens is op 24 november een conceptnotitie gedeeld met de gemeente waar de gemeente op 1 december reactie op heeft gegeven. Op nog enkele openstaande gedetailleerde vragen van SEO is door de gemeente gereageerd op 11 en 12 december. Op dat moment is ook de laatste en aangepaste versie van de R-code door de gemeente gedeeld. De inzichten hieruit zijn door SEO verwerkt in de definitieve notitie.

Bevindingen Gebruik R SEO heeft in de evaluatie van vorig jaar de aanbeveling gedaan om de berekeningen in R te programmeren, een open-source-programma met een command-line-interface (regels code in plaats van enkel een grafische weergave). SEO beoordeelt de overstap van KNIME naar R als een substantiële verbetering. Het is verstandig dat de gemeente de KNIME-workflow voor dit jaar heeft geüpdatet met de beleidsmatige wijzigingen om op deze manier de consistentie tussen de twee programmeertalen te kunnen toetsen en borgen. Door het programmeren in R zijn de berekeningen overzichtelijker en beter controleerbaar. Verder is het script is eenvoudiger uit te voeren, waardoor het ook gemakkelijker overdraagbaar is naar nieuwe medewerkers. In vergelijking met KNIME is de doorrekentijd aanzienlijk verbeterd; het uitvoeren van het script duurt nu slechts enkele minuten. Daarnaast is het gemakkelijker

GRONDWAARDEBEPALING AMSTERDAM 2024

5

om wijzigingen door te voeren en nieuwe bestanden in te lezen. Dankzij de snellere rekentijd kunnen berekeningen direct na het doorvoeren van wijzigingen of bij het gebruik van nieuwe bestanden worden uitgevoerd. Bij de positieve beoordeling van de overgang naar R benoemen we tegelijkertijd nog wel enkele belangrijke verbeterpunten voor de komende jaren. Hoewel de R-code een significante verbetering qua transparantie, duidelijkheid en toepasbaarheid heeft opgeleverd lijkt de huidige versie van de code nog niet gemakkelijk overdraagbaar. De R-code is door één werknemer ontwikkeld. In de bijeenkomsten met de gemeente heeft de gemeente aangegeven dat meerdere medewerkers het kunnen runnen en eventueel kleine aanpassingen kunnen doorvoeren. Aan de hand van onze controle en beoordeling van de R-code is het onze inschatting dat de huidige code geen waarborg geeft dat zonder vergaande kennis van de materie in combinatie met gemiddelde kennis van R andere dan oppervlakkige veranderingen op een juiste manier kunnen worden doorgevoerd. We bevelen daarom ook aan om te blijven investeren in de overdraagbaarheid binnen de gemeente, bijvoorbeeld met betrekking tot het aantal personen dat de R-code en -structuur volledig doorgrondt. Eén van de manieren om de overdraagbaarheid en transparantie te borgen is het structureren van de code zelf.

Het valt op dat de flow van de code nog erg op de structuur van de KNIME-workflow lijkt, bijvoorbeeld door het opslaan van elke bewerking als nieuw dataframe en de ‘opdeling’ van het script in “Syntax 1” en “Syntax 2”. Ook de volgorde is één-op-één van de KNIME-workflow overgenomen. Hierdoor wordt deels data op een in R niet logische plek ingeladen.8 Vanuit de overgangssituatie van KNIME naar R is het te begrijpen dat de R-code zo gelijkend mogelijk aan de KNIME-workflow is opgezet. SEO raadt echter sterk aan om het R-script aan te passen zodat het een meer logische en efficiënte structuur heeft en overbodige stappen die van de KNIME-workflow zijn overgenomen eruit gehaald kunnen worden. Het is onze inschatting dat dit een cruciale stap is om de berekening voor een breder publiek transparant te maken. Veel van de specifieke punten (zie Tabel 1) bevatten suggesties om het script nog eenvoudiger en robuuster te maken, bijvoorbeeld door eenvoudigere variabelnamen of duidelijker beschrijven van de genomen stappen. 9 Bovendien kunnen objectnamen in de R-environment gelabeld worden met bijvoorbeeld ‘.df’ voor dataframe, ‘.tb’ voor tibble en ‘.ls’ voor een lijst.

Algemeen beeld Uit de controles van de verdere berekeningswijze tekenen wij het volgende algemene beeld op. Zoals in de voorgaande jaren resulteren de berekeningen, dit jaar in R geprogrammeerd, in de door de gemeente gebruikte uitkomsten. De op 23 november door de gemeente gedeelde R-outputbestanden per buurtstraat en per WOZobject komen volledig overeen met de outputbestanden die SEO zelf heeft uitgedraaid op basis van het R-script van de gemeente.10 SEO stelt wel vast dat de gemeente het opslaan van het finale outputbestand met de BSQ’s niet

8

9

10

Ter illustratie, de adressen worden in Syntax 1, regel 174, tussen het inlezen van meerdere herbouwkostendatabestanden ingelezen en pas in regel 317 gebruikt door het aan een andere dataset te koppelen. Een ander voorbeeld betreft het gebruik van loops in het programmeren. Het valt op dat er geen loops worden gebruikt voor repeterende bewerkingen. Het gebruik van loops zou het script efficiënter maken en voor de geoefende lezer transparanter. Hierbij is wel een afruil tussen snelheid/efficiëntie en het eenvoudig/begrijpelijk houden van het script voor een breder publiek. In eerste instantie leken er in het outputbestand ‘R_BSQ_per_wozobject.csv’ van de gemeente voor de variabele ‘WijkcodeNieuw’ 3.984 observaties te ontbreken, maar dit blijkt te liggen aan de wijkcode “NA” (“Oostzanerwerf”). Het gebruik van “NA” om een daadwerkelijke categorie te markeren is potentieel foutgevoelig aangezien veel programma’s, waaronder R, “NA” als lege cel/missende waarde beschouwen.

GRONDWAARDEBEPALING AMSTERDAM 2024

6

heeft opgenomen in het R-script. SEO raadt aan om het finale outputbestand op te slaan en dit te automatiseren in het R-script om zo mogelijke verwarring over versies en runs te voorkomen. SEO heeft de KNIME-workflow uitgevoerd en geconstateerd dat de output hetzelfde is als de KNIME-output die gedeeld is door de gemeente en de R-output zoals gegenereerd door SEO. Met andere woorden, uit de door de gemeente aangeleverde KNIME-workflow en R-code volgt dezelfde output. De output die voortkomt uit de KNIMEworkflow kwam in eerste instantie niet overeen met de R-output vanwege een verouderd inputbestand. De R-output bevatte een rij minder dan de KNIME-output. Daarna is een nieuw inputbestand gedeeld en kwam de output volledig overeen. Op 14 november is een nieuwe KNIME-outputbestand van de gemeente Amsterdam met SEO gedeeld. Aan de hand van deze outputbestand heeft SEO gecontroleerd of de uitkomsten van het R-script overeenkomen met de uitkomsten van de KNIME workflow. SEO concludeert dat de uitkomsten overeenkomen. Er zijn alleen afrondingsverschillen aanwezig. De gemeente heeft al aangegeven hiervan op de hoogte te zijn. Pogingen van de gemeente om de afrondingsmethode aan te passen zijn niet gelukt.11 Het databestand waarop de berekeningen worden uitgevoerd is opgebouwd (gekoppeld) uit verschillende bronbestanden.

Deze bronbestanden zijn met behulp van koppelfuncties, left_join() en inner_join() , aan elkaar gekoppeld. SEO heeft cruciale stappen zoals het inlezen en koppelen van databestanden in Stata nagebouwd. Daarin zijn geen onvolkomenheden gevonden. Het is alleen in sommige gevallen niet duidelijk waarom bepaalde observaties niet worden gekoppeld (zie Tabel 1 voor specifieke punten). Ook kan in de code (vaker) genoteerd worden met welk doel bepaalde bronbestanden (en variabelen) worden ingelezen en gekoppeld. Daarnaast wordt iedere koppeling als los dataframe opgeslagen terwijl er (meer) voor gekozen kan worden om een bestaand bestand te overschrijven. Deze werkwijze in het huidige R-script lijkt met name terug te grijpen op (het reproduceren van) de KNIME-workflow. Het R-script en daarmee de toegepaste methode komen grotendeels overeen met de Procesbeschrijving van de berekening van de buurtstraatquote 2024. SEO vond nog enkele incidentele onjuistheden, met potentieel een materiële impact, die eenvoudig te corrigeren zijn in zowel de Procesbeschrijving als in de berekeningen (het Rscript). Deze onjuistheden zijn aan de gemeente gemeld. De gemeente heeft per mail op 11 en 12 december een nadere schriftelijke reactie gegeven en de meest recente versie, inclusief aanpassingen, van het R-script gedeeld.

De gemeente Amsterdam heeft dit jaar enkele aanpassingen gemaakt in de BSQ-berekeningen.12 Ten eerste zijn de herbouwkosten ten behoeve van prijspeilcorrectie van 2021 naar 2022 geïndexeerd. 13 SEO heeft deze aanpassing gecontroleerd en de correcte uitvoering binnen het R-script kunnen constateren. Ten tweede is de selectie van deelcodes gewijzigd die wordt gebruikt voor de bepaling van de woningoppervlakte voor de herbouwkostenberekeningen. 14 SEO heeft gecontroleerd of deze aanpassing van de deelcodes correct is toegepast en oordeelt dat dat het geval is. Echter is het origineel gedeelde R-script niet volledig consistent met betrekking tot de verwerking van deelcodes die worden toegevoegd aan deelcode 1100. Deelcode 1320 wordt als onderdeel van deelcode 1100 beschouwd en aan de lijst met ‘non-exotische’ deelcodes toegevoegd. Daarentegen worden de codes 1200 en 1230, die ook als onderdeel van deelcode 1100 worden beschouwd, niet aan de lijst

11 12 13

14

Zie ‘20231013 Memo Voorgenomen aanpassingen BSQ 2024’ Zie ‘20231013 Memo Voorgenomen aanpassingen BSQ 2024’ De herbouwkostenramingen zijn geïndexeerd met 5,10 procent voor eengezinswoningen en 4,15 procent voor stapelwoningen. Naast de deelcode 1100 ‘Woning’ worden al sinds de BSQ 2021 deelcodes 1101 ‘Woningdeel overig’ en 1320 ‘Dakopbouw’ meegenomen voor de bepaling van de totale oppervlakte woningoppervlakte in m². Tevens worden daar nu deelcodes 1200 ‘Aanbouw woonruimte’ en 1230 ‘Serre’ aan toegevoegd.

GRONDWAARDEBEPALING AMSTERDAM 2024

7

toegevoegd. In een reactie van 14 november 2023 geeft de gemeente aan dat dit is gecorrigeerd in het R-script en in de documentatie. Naast de keuze voor een ander programma en enkele beleidsmatige wijzigingen is ook de Procesbeschrijving verbeterd vergeleken met voorgaand jaar. Zo deed SEO vorig jaar de aanbeveling om vast te leggen hoe jaar-opjaar geïndexeerd wordt en hoe de lijst exotische deelcodes is vastgesteld. De indexatie is nu vastgelegd in het nieuwe Beleid Grondwaardebepaling (bijlage 2, paragraaf 8 ‘Indexatie herbouwkosten’) en geschiedt op basis van indexcijfers van het Bureau Documentatie Bouwwezen. In de Procesbeschrijving is nu opgenomen wat de definitie van exotische deelcodes is (paragraaf 5.1, stap 3) en hoe de deelcodes gecategoriseerd zijn (bijlage 6). In het kader van de informatievoorziening heeft de gemeente op haar website voorbeeldberekeningen staan voor het berekenen van de herbouwkosten en de BSQ.15 Deze voorbeelden blijken echter niet aangepast aan de nieuwe methodiek die sinds de BSQ 2023 van toepassing is. In plaats daarvan hanteren de voorbeelden nog de berekeningsmethode die tot 2021 (en na verlenging ook tot 2022) van toepassing was. Zo worden de herbouwkosten voor een hoekwoning in ‘WOZ voorbeeldberekening 1: reguliere BSQ’ nog berekend aan de hand van de formule: (EXP([Opp] ∗ −0.02359 + 8.36)) + 1375 .

Dergelijke formules waren destijds per woningtype gebaseerd op een non-lineaire ‘best fit’-regressie op een aantal referentiepunten met de taxatiewaarde per oppervlaktegrootte. Het huidig beleid gaat uit van een lineaire interpolatie tussen de referentiepunten. Ook staat online een verouderde versie van het Beleid Grondwaardebepaling (het laatste gewijzigd in december 2020 in plaats van januari 2023). SEO beveelt aan om de informatie op de website zo spoedig mogelijk in lijn te brengen met de huidige methode en aanpak om zo eventuele verwarring te voorkomen. 16

Specifieke punten Tijdens de controle constateerden wij dat er op een aantal punten in het R-script en in de openbare en/of interne documentatie aanpassingen nodig zijn om consistentie te waarborgen. Deze punten zijn weergegeven in de onderstaande tabel. De eerste kolom geeft aan op welk onderdeel of aspect van het beleid en/of de berekening het betreffende punt betrekking heeft. De tweede kolom geeft een beknopte beschrijving. In de derde kolom geven we weer of de gemeente het betreffende punt heeft geadresseerd, eventueel met aanpassingen in het R-script en/of in de openbare en interne documentatie. Voor elk van de specifieke punten is toegelicht in welk van de volgende categorieën het valt: ● Beschrijvend: de opmerking is enkel van belang voor de beschrijving van de toegepaste rekenmethode; ● Robuustheid: het beleidsonderdeel kan mogelijk minder foutgevoelig toegepast worden, maar de toepassing is op dit moment wel correct; of ● Materieel: het punt leidt mogelijk tot materiële afwijkingen in de berekeningen en leidt daarmee mogelijk tot afwijkende uitkomsten. Veel van de specifieke punten —met name onder 'robuustheid'— betreffen verbetervoorstellen voor nog meer overzicht en duidelijkheid van het R-script.

In de tabel wordt ‘BSQ_v0.R’ beschreven als Syntax 1 (tot en met regel 495, “Genereren werkbestand waarop BSQ-berekening kan worden uitgevoerd’) en Syntax 2 (vanaf regel 496, “Berekening BSQ”).

15

https://www.amsterdam.nl/wonen-leefomgeving/erfpacht/buurtstraatquote-(bsq)/voorbeeldberekeningen-herbouwkostenbsq/#h2712e407-81e2-4426-8be2-dcc5b0cdce49 16 https://www.amsterdam.nl/wonen-leefomgeving/erfpacht/nieuw-beleid/grondwaardebepaling/

GRONDWAARDEBEPALING AMSTERDAM 2024 Tabel 1

8

Bevindingen specifieke punten

Beleidsonderdeel

Beschrijving

Samenvattende (re)actie gemeente

Instellen working directories

Robuustheid: Ondanks dat de syntax ‘path-define_toesting_v0.R’ een overzichtelijke toevoeging is, kan de local ‘pathToInput’ (mogelijk) nog robuuster worden geprogrammeerd door de working directory in te stellen naar de huidige map waarin het R-script zich bevindt, bijvoorbeeld: setwd(dirname(rstudioapi: : getActiveDocumentContext()$path))

Aanbeveling wordt in de BSQberekening voor het volgende jaar onderzocht.

Bronbestand Index Herbouwkosten

Robuustheid: Syntax 1, regel 166: De indexering van de herbouwkosten in 2022 wordt als extern bronbestand ingelezen. Het omvat enkel het jaar en het indexeringspercentage voor eengezinswoningen en stapelwoningen. ● Aanbeveling om de percentages voor de indexering als numerieke aanname in het script op een duidelijke afgebakende plek te definiëren in plaats van het inlezen van een dataframe.

Aanbeveling wordt overgenomen en is reeds doorgevoerd.

Bronbestanden Herbouwkosten

Robuustheid: Er worden nu veel losse en zeer uitgebreide bronbestanden ingelezen voor de herbouwkosten. ● Voor bronbestanden A3 20220728 HBK M3E A3.csv‘ en ‘A5.1 20220728 HBK M3E A5.1.csv‘ wordt een bestand van vorig jaar (2022) ingelezen. Onduidelijk waarom deze niet geüpdatet zijn, maar bronbestand ‘A4 20231017 HBK M3E A4.csv‘ (dat enkel vaste percentages bevat) wel. ● Aanbeveling om, waar mogelijk, generieke formules of numerieke aannames toe te passen op in te lezen bestanden en daarmee het laden van externe (additioneel op te stellen) bestanden te beperken. ● Voor de bronbestanden A1, A2, A3 en A5.1 geldt dat enkel de schattingen per specifiek taxatiepunt (bijv. 25 m2, 57 m2, etc.), zoals weergegeven in de factsheets per woningtype in Bijlage 1 van het Beleid Grondwaardebepaling, hoeven te worden ingelezen. Vervolgens kan de formule ter interpolatie, zoals weergegeven in paragraaf 5 van Bijlage 2 van het Beleid Grondwaardebepaling, worden toegepast om de tussenliggende punten te berekenen. x(m ) − x1 y(m ) = y1 + × (y2 − y1) x2 − x1 ● Voor bronbestand A4 geldt dat deze drie/vier numerieke aannames kunnen worden vastgesteld en opslagen in R zonder daarvoor een extern bronbestand in te lezen. Dit is daarmee vergelijkbaar met de opslag herbouwkosten voor A5.2 à €572,8181.

Aanbeveling wordt niet overgenomen gelet op de status van de bronbestanden en het gemak waarmee een eventuele erfpachter de herbouwkosten kan opzoeken in zo’n bronbestand.

GRONDWAARDEBEPALING AMSTERDAM 2024

9

Inlezen bronbestanden

Robuustheid: Syntax 1, regels 52-227: Voor enkele in te lezen bronbestanden wordt gespecifieerd dat een waarde van "99999999" een lege cel moet zijn, i.e., na = "99999999". Voor een aantal bronbestanden komen er ook cellen met deze waarde voor, maar wordt de waarde niet op NA (oftewel een lege cel) ingesteld. Dit geldt bijvoorbeeld voor ‘KadastraalGewijzigd’ in WOZKadaster_01. ● Aanbeveling om consistent observaties met ‘99999999’ op NA te zetten bij het inlezen van alle bronbestanden.

Aanbeveling wordt overgenomen en is reeds doorgevoerd.

Inlezen bronbestanden

Robuustheid/Beschrijvend: Syntax 1, regels 52-227: Voor enkele in te lezen bronbestanden wordt gespecifieerd welke variabelen (kolommen) moeten worden ingelezen omdat de rest overbodig is. Dit gebeurt op dit moment niet volledig of consistent voor alle bronbestanden. Bij het gekoppelde WOZData_01 is er bijvoorbeeld zowel een kolom ‘HOOFDCODE’ als ‘Hoofdcode’ terwijl deze een-op-een overeenkomen. ● Aanbeveling om dit voor alle bronbestanden volledig te doen zodat direct duidelijk is welke variabelen van toegevoegde waarde zijn en behouden moeten worden.

Aanbeveling wordt overgenomen en doorgevoerd in de BSQ-berekening voor het volgende jaar.

Bronbestanden en outputbestand

Materieel: De door SEO gegenereerde output van de KNIME-workflow ‘BSQ – 2024.knwf’ bleek niet overeen te komen met de output van het R-script op basis van de verschillende inputbestanden. De R-output bevatte een rij minder dan de KNIME-output.

Opgelost met sturen update inputbestanden.

Selectie erfpachtregime

Robuustheid/Beschrijvend: Syntax 1, regel 80: Weesp wordt uit WOZ_01 gefilterd omdat het niet onder het erfpachtregime valt. Dit staat echter niet in de documentatie. Tevens wordt er bij het inlezen van het bestand WOZ_objecten_01, dat later aan WOZ_01 wordt gekoppeld, niet gefilterd op woonplaats. ● Aanbeveling om te onderzoeken of een veralgemenisering door filtering op (een gebrek aan) een bepaald erfpachtregime robuuster (meer toekomstbestendig) en efficiënter is. Er wordt later in het script bijvoorbeeld ook gefilterd op erfpachtregime (“AB Code”).

Aanbeveling wordt in de BSQberekening voor het volgende jaar onderzocht.

WOZ-waarde boten en parken

Robuustheid: Syntax 1, regel 293: in WOZTypes_01 zijn er 2.711 objecten met een WOZ-waarde van 0 in 2022 (n=2.710 BOOT en n=1 PARK). Hoe wordt hier verder mee omgegaan in de databewerkingen? Na koppeling loopt het aantal in WOZData_02 en vervolgens WOZKadaster_Koppeling_01 ook op omdat het om meerdere ObjectId’s gaat. In BsqInput_01 zitten deze objecten nog altijd.

Deze objecten zijn niet van invloed op de BSQ-bepaling omdat het geen EGWO of STWO betreffen. Het in de data behouden van deze objecten (zonder herbouwkosten) helpt bij controleren herleidbaarheid en objecten zonder herbouwkosten te verklaren.

GRONDWAARDEBEPALING AMSTERDAM 2024

10

Selectie deelcodes

Robuustheid: Syntax 1, regel 293-301: De WOZ-waarde en WOZ-type worden uit de WOZ-deelcodes gehaald. In de documentatie is niet omschreven waarom observaties met deelcode 9998 (‘erfpacht correctiedeel‘, ‘regulier‘) eruit worden gefilterd. Daarnaast worden observaties met deelcode 9999 niet gefilterd en staat deze ook niet in de documentatie (maar komt wel eenmaal voor). Aanbeveling om alle in de data voorkomende deelcodes in de documentatie op te nemen en te omschrijven

Aanbeveling wordt overgenomen en is reeds doorgevoerd.

Definiëren en selecteren van corporatiewoningen

Materieel/Robuustheid/Beschrijvend: Syntax 1, regels 239-275 en 424-433: Er wordt gedefinieerd welke objecten onder corporatiewoningen vallen. ● Het is niet altijd duidelijk waarom bepaalde organisaties zijn opgenomen in de lijst met corporaties, ondanks het definiëren van kenmerken in paragraaf 5.1 van de Procesbeschrijving. Zo is “Stichting Pensioenfonds Rail & Openbaar Vervoer” (tweemaal in de lijst) geen woningcorporatie. Anderzijds zijn er erfpachters die ogenschijnlijk corporatie zijn, maar niet als dusdanig gemarkeerd worden, zie bijvoorbeeld: `Erfpachter(s)` n De Alliantie Ontwikkeling BV 67 ( onduidelijk) De Alliantie Woonfonds B.V. 3 ( in lijst corporaties) Stichting de Alliantie 15965 ( in lijst corporaties) Stichting de Alliantie, […] 1 ( bevat particuliere naam?) Stichting de Alliantie, […] 1 ( bevat particuliere naam?) Stichting de Alliantie, […] 1 ( bevat particuliere naam?) Aanbeveling om in de documentatie nader te expliciteren hoe de lijst met woningcorporaties (en andere organisaties) wordt opgesteld en deze lijst eventueel van een update te voorzien.

● Omdat later al hoofdletters worden verwijderd met tolower() kan de lijst met corporaties bondiger, zie bijvoorbeeld de huidige opsomming: "WoonStichting Lieven De Key", "WoonStichting Lieven de Key", "Woonstichting Lieven de Key", … "Woonstichting Lieven de Key") ● Aanbeveling om de code te generaliseren en alleen naar de aangemaakte corporatielijst te verwijzen in plaats van verwijzingen naar specifieke woningstichting (in dit geval “Woningstichting Eigen Haard”), i.e. `Erfpachter(s)` %in% tolower(corporaties) ● Aanbeveling om niet alleen hoofdletters in tekststrings weg te halen, maar ook spaties en punten te verwijderen (relevant voor bijvoorbeeld “N.V.” of “NV”)

De gemeente licht toe dat het gaat om uitsluiten sociale huurwoningen en dat hiervoor naast het selecteren op AB codes ook een additionele lijst van (voormalig) eigenaren van sociale huurwoningen is samengesteld. Aanbeveling voor expliciteren in documentatie en updaten van deze additionele lijst wordt overgenomen en doorgevoerd in de BSQberekening voor het volgende jaar. Aanbeveling hoofdletters wordt overgenomen en is reeds doorgevoerd. Aanbeveling verwijzing aangemaakte lijst wordt overgenomen en is reeds doorgevoerd. Aanbeveling rondom opschonen namen (punten en komma’s) wordt overgenomen en doorgevoerd in de BSQ-berekening voor het volgende jaar.

GRONDWAARDEBEPALING AMSTERDAM 2024

11

Koppelen van WOZTypes aan WOZData

Robuustheid: Syntax 1, regel 307: WOZData wordt aan WOZTypes gekoppeld met de functie left_join(). Hierbij worden 6.218 observaties niet gekoppeld; voor 4.319 observaties is er geen WOZ-waarde, maar wel het ObjectId en andere kenmerken; en voor 1.899 observaties is er wel een WOZ-waarde maar geen ObjectId en andere kenmerken. ● Aanbeveling om te onderzoeken wat hier gebeurt en waarom bepaalde observaties niet gekoppeld kunnen worden.

Voor 4.319 objecten zijn er geen WOZ-waarden 2022 toegekend. De 1.899 objecten betreffen objecten in Weesp.

Koppelen van Hermeskadasterdata aan Hermesdata

Robuustheid: Syntax 1, regel 314: Hermeskadaster-data wordt aan Hermes-data gekoppeld met de functie inner_join(). De variabele ’Edossier’ is niet uniek: na de koppeling heeft een Kadastraal-nummer in sommige gevallen meerdere Edossier-nummers. Hierdoor wordt het dataset vergroot. ● Aanbeveling om te onderzoeken of het de bedoeling is om van Kadastraalniveau naar Edossier-niveau te gaan. Gaat het hier bijvoorbeeld om een flatgebouw dat over meerdere kadastrale gebieden strekt?

Aanbeveling om dit te checken is overgenomen en uitgevoerd, conclusie is dat de koppeling is uitgevoerd zoals bedoeld, waarbij het genoemde voorbeeld een juist voorbeeld is.

Selectie exotische deelcodes

Robuustheid: Syntax 1, regel 347: Het vaststellen van de deelcodes die worden aangemerkt als 'exotisch' gebeurt volledig handmatig door het invullen van deelcodes die niet onder deze lijst vallen. ● Aanbeveling om de terminologie constant te houden in het R-script en in de documentatie (regulier vs. non-exotisch). ● Aanbeveling om alle in de documentatie als “regulier” gedefinieerde deelcodes consistent in het script op te nemen. ● Sommige deelcodes worden toegevoegd aan deelcode 1100 (bijvoorbeeld deelcode 1320). Aanbeveling om dit ook in de code op te nemen voor alle deelcodes waarvoor dit het geval is. ● Aanbeveling om de documentatie ‘Onbezwaarde waarde, maatwerk BSQ en procedure van bedenkingen’ (versie 1.0, 27 juni 2019) te updaten omdat deze nog uitgaat van de vorige herbouwkostenmethodiek die tot de BSQ 2021 (en na verlenging ook tot de BSQ 2022) van toepassing was.

Aanbeveling wordt overgenomen en is reeds doorgevoerd (zowel in script als documentatie).

Toepassen exotische deelcodes

Robuustheid: Syntax 1, regel 354: Het dataframe ExotischeDeelcodes_01 wordt aangemaakt en opgeslagen, maar dit lijkt overbodig. De lijst met exotische deelcodes, non_exotische_deelcode, kan ook direct worden toegepast op WOZDeelcodes_02 (waar ExotischeDeelcodes_01 aan wordt gekoppeld). De beschrijvende statistieken uit ExotischeDeelcodes_01 kunnen wel geprint worden, maar opslaan en later koppelen voegt niets toe. Daarnaast belangrijk om rekening te houden met het verschil tussen mean(WOZpermeter) * mean(GO) en mean(WOZpermeter*GO), welk van de twee is bedoeld om uit te rekenen?

Aanbeveling wordt overgenomen en is reeds doorgevoerd, het betrof een oude analyse uit de KNIME-workflow zonder verdere impact op de BSQberekening.

GRONDWAARDEBEPALING AMSTERDAM 2024

12

Koppelen van WOZdata aan WOZkadaster

Robuustheid: Syntax 1, regel 381: WOZ-data worden aan WOZ-kadaster gekoppeld met de functie left_join(). De variabele ‘ObjectID’ is niet uniek: na de koppeling heeft een ObjectID in sommige gevallen meerdere Kadastraalnummers. Hierdoor wordt het data set vergroot. ● Aanbeveling om te onderzoeken of het de bedoeling is om van ObjectIDniveau naar kadasterniveau te gaan.

Aanbeveling om dit te checken is overgenomen en uitgevoerd, conclusie is dat de koppeling is uitgevoerd zoals bedoeld.

Selectie objecten tuin

Robuustheid: Syntax 1, regel 443: ‘Tuin Flag’ wordt aangemaakt. Deelcode 2011 (‘tuin overig’) wordt niet geselecteerd maar komt ook niet voor in de data. Dit is foutgevoelig indien deze deelcode wel voorkomt. Er is geen verdere toelichting in BSQ-documentatie 2024 over waarom deze deelcode ontbreekt in het script en in de data.

Opmerking wordt overgenomen en verbetering – alle deelcodes in het Script meenemen – is reeds doorgevoerd.

Selectie objecten herbouwkosten berekening

Beschrijvend: Syntax 2, regel 514: Er is een typo in de toelichting van de selectie van de objecten voor de herbouwkosten berekening. Er moet ‘geen’ staan in plaats van ‘een’ in de zin “Het WOZ-object een exotische deelcode heeft”.

Selectie objecten herbouwkosten berekening

Beschrijvend: Syntax 2, regels 526-551: Of een woning wordt meegenomen voor de BSQ-berekening is in de code gelimiteerd door een onder- en bovengrens van de gebruiksoppervlakte per hoofdcode. Ondanks dat wordt gesproken over ‘interpolatie’ tussen punten is deze keuze niet expliciet vermeld in het Beleid Grondwaardebepaling.

Toelichting gemeente: de onder- en bovengrens is gelijk aan de min- en max-oppervlakte van de herbouwraming per woningtype.

Definiëren opslag herbouwkosten

Robuustheid: Syntax 2, regel 734: de opslag herbouwkosten wordt aangemaakt. Er wordt een andere afronding gehanteerd dan in de formules voor de herbouwkosten berekening in regels 743-749 (drie versus vier digits achter de komma). ● Aanbeveling om dezelfde afronding te hanteren.

Aanbeveling wordt overgenomen en doorgevoerd in de BSQ-berekening voor het volgende jaar.

Selectie oppervlaktes

Robuustheid: Syntax 2, regel 701: Aanmaken van categorieën op basis gebruiksoppervlaktes.  Aanbeveling om categorielabels aan te passen naar wat er feitelijk geselecteerd wordt en niet hetzelfde getal in twee categorieën voor te laten komen, bijvoorbeeld “2. 40-59” en “3. 60-79” in plaats van “2. 40-60” en “3. 60-80” en ook “6. >=200” in plaats van “6. >200”.  Aanbeveling om voor de duidelijkheid de selectie van oppervlaktes aan beide kanten van het bereik te definiëren, bijvoorbeeld Gebruiksoppervlakte < 40 ~ “1. < 40”, between(Gebruiksoppervlakte, 40,59) ~ “2. 40 − 59”

Aanbeveling wordt overgenomen en doorgevoerd in de BSQ-berekening voor het volgende jaar.

GRONDWAARDEBEPALING AMSTERDAM 2024

13

Selectie erfpachtregime

Materieel/robuustheid: Syntax 2, regel 1230: Er is een mismatch tussen het Rscript en de documentatie bij het filteren op ‘AB Codes’. In het R-script ontbreekt de AB code ‘AB1934‘ en in het R-script staat ‘AB2013H’ maar deze staat niet in de documentatie.

Wordt overgenomen en aanpassing – meenemen AB1934 en verwijderen AB2013H – is reeds doorgevoerd.

Variabelnamen

Robuustheid: Variabelnamen zijn deels vrij lang. Daarnaast bevatten veel variabelnamen hoofdletters en/of spaties. ● Aanbeveling om lange variabelnamen te verkorten voor verbeterde leesbaarheid. ● Aanbeveling om hoofdletters zo veel als mogelijk te vermijden en daarmee de foutgevoeligheid te verlagen. Aanbeveling om spaties te vermijden en indien nodig te vervangen door een underscore, ‘_’. Op deze manier kunnen variabelen gemakkelijker opgeroepen worden zonder aanhalingstekens. Dit is mogelijk met clean_names(). Bijvoorbeeld go_categorie in plaats van `GO categorie`.

Aanbeveling wordt overgenomen en doorgevoerd in de BSQ-berekening voor het volgende jaar.

Organisatie van numerieke aannames

Robuustheid: Numerieke aannames worden tussendoor in het script gemaakt. ● Aanbeveling om een aparte sectie in het script aan te maken met numerieke aannames en eventueel ook voor het aanmaken van lijsten met strings (zoals corporaties).

Aanbeveling wordt overgenomen en is reeds doorgevoerd.

Versiebeheer van dataframes

Robuustheid: Er worden vele versies van dataframes opgeslagen in de Renvironment. ● Aanbeveling om minder versies van dataframes op te slaan voor meer overzicht of tussendoor versies van dataframes te verwijderen die niet meer worden gebruikt, bijvoorbeeld direct na laatste koppeling of bewerking van een bepaald dataframe.

Aanbeveling wordt overgenomen en doorgevoerd in de BSQ-berekening voor het volgende jaar.

Refereren aan toegepaste documentatie

Robuustheid (potentieel materieel): Duidelijke opmerkingen over de berekeningen in het script en verwijzingen naar specifieke regels uit de documentatie ontbreken nu in het script. Bijvoorbeeld, de koppeling van A5.2 aan BsqInput in Syntax 2, regel 736-741, wordt vaag omschreven. Het is moeilijk om als buitenstaander te begrijpen wat hier precies gedaan wordt. Ook is onduidelijk waar de correctie `Gemiddelde WOZ per meter wijk woningtype per GO cohort` * 1.1 vandaan komt. ● Aanbeveling om duidelijke opmerkingen toe te voegen die de berekeningen toelichten en verwijzen naar bepaalde regels uit het Beleid Grondwaardebepaling en/of de Procesbeschrijving (eventueel inclusief het versienummer).

Aanbeveling voor extra toelichting wordt overgenomen en is deels al doorgevoerd en wordt deels doorgevoerd in de BSQ-berekening voor het volgende jaar. De berekening rondom A5.2 komt nog uit KNIME-workflow en is niet nodig en daarom verwijderd.

GRONDWAARDEBEPALING AMSTERDAM 2024

14

Controle van koppeling

Robuustheid: Controle van beschrijvende statistieken na datakoppelingen ontbreekt in het script. ● Aanbeveling om na elke koppeling bijvoorbeeld het aantal waarnemingen en het gemiddelde van enkele variabelen te vergelijken met de waarden voor de koppeling en dit integraal in de code mee te kopiëren.

Aanbeveling wordt overgenomen en doorgevoerd in de BSQ-berekening voor het volgende jaar.

Overzichtelijkheid van het script

Robuustheid/Beschrijvend: Het script loopt in de breedte ver door. Het is daarmee niet op alle beeldschermgroottes in één keer leesbaar en daarmee niet goed overzichtelijk. Daarnaast is het mogelijk om in R nog beter te structureren waardoor het gemakkelijker door de code te navigeren is. ● Aanbeveling om over meerdere regels te breken voor verbeterde overzicht. ● Aanbeveling om de verschillende stappen te structureren aan de hand van ‘code sections’, ofwel een hoofdstukstructuur. Bijvoorbeeld: # Inlezen bestanden ---## Inlezen WOZ_informatie ---## Inlezen WOZ_objecten ----

Aanbeveling wordt overgenomen en doorgevoerd in de BSQ-berekening voor het volgende jaar.

Outputbestand

Robuustheid: De uitkomsten van de berekeningen worden niet automatisch buiten R opgeslagen. Daarnaast is het door de gemeente gegenereerde outputbestand volgend uit de R-code en de KNIME-workflow in eerste instantie niet met SEO gedeeld. ● Aanbeveling om de uitkomsten aan het eind van het script (naar Excel) te exporteren en dit outputbestand eventueel te voorzien van de datum van uitdraaien.

Aanbeveling wordt overgenomen en is reeds doorgevoerd.

Bron:

SEO Economisch Onderzoek (2023)

GRONDWAARDEBEPALING AMSTERDAM 2024

15

Conclusies en aanbevelingen De voorgenomen wijzigingen in het beleid van de gemeente Amsterdam voor de bepaling van de erfpachtgrondwaarden zijn op een adequate wijze vertaald in de toegepaste rekenmethode (R-script). SEO vond wel incidentele onjuistheden die de gemeente naar aanleiding van deze toetsing heeft aangepast. Van gemaakte keuzes in de toegepaste methode die niet zijn geëxpliciteerd in het beleid en die niet als fout zijn bestempeld, is niet gebleken dat deze inconsistent zijn met het beleid. Ten opzichte van voorgaande jaren heeft de gemeente opnieuw duidelijk geïnvesteerd in de berekening en bijbehorende documentatie en daarmee de transparantie over en overdraagbaarheid van de uitvoering van de berekening van de buurtstraatquotes vergroot. Positief is dat de berekeningen nu in R worden gedaan zoals ook vorig jaar aanbevolen door SEO. Het gebruik van R vereenvoudigt en verbetert de controle van berekeningen, minimaliseert foutgevoeligheden, maakt het script gemakkelijk uitvoerbaar en overdraagbaar tussen medewerkers. De doorrekentijd is aanzienlijk verbeterd ten opzichte van KNIME, met snelle uitvoering en eenvoudige wijzigings- en invoermogelijkheden voor nieuwe bestanden. Echter valt op dat de flow van de R-code nog erg op de structuur en volgorde van de KNIME-workflow lijkt, waardoor de code nog niet logisch gestructureerd is.

De documentatie en Procesbeschrijving is zeer uitgebreid en naar aanleiding van de aanbevelingen van vorig jaar verder verbeterd. Het zou daarom juist verhelderend zijn als er in het R-script vaker wordt verwezen naar specifieke beleidsregels of processtappen zodat het, ook voor nieuwe medewerkers, eenvoudiger te begrijpen is en beleidsmatige wijzigingen gemakkelijk doorgevoerd kunnen worden. We hebben geconstateerd dat de informatie op de website van de gemeente rondom de erfpachtberekening en de buurstraatquote op enkele punten niet meer overeenkomt met het huidige beleid en de wijze van berekenen. Net als in voorgaande jaren is er nog sprake van het op meerdere plekken in de berekening (R-script) ‘hard’ coderen van dezelfde informatie, zoals correctietarieven en -percentages. Dit is foutgevoelig; we adviseren daarom bij de volgende BSQ-berekening numerieke waarden op één (centrale) plek in de code(s) op te nemen. Naar aanleiding van de beoordeling doen wij de volgende aanbevelingen aan de gemeente: ● Werk bij het programmeren zo robuust ('fout vermijdend') mogelijk om consistentie en overzicht te waarborgen.

Dit kan bijvoorbeeld door het gebruik van kortere variabelnamen, het verwijderen van punten en spaties in strings, het overal toepassen van dezelfde soort filters voor bepaalde variabelen, en het eenmalig (op een centrale plek) programmeren van andere bedragen; ● Verbeter de Procesbeschrijving verder door eerder niet expliciet omschreven stappen alsnog toe te lichten en zorg ervoor dat de documentatie en het R-script volledig op elkaar aansluiten; ● Zorg voor een constante update van de (online) communicatie van de gemeente over de erfpachtberekeningen en de buurtstraatquotes.

De tekst is automatisch uit het bestand gehaald en kan afwijken van het origineel (kolommen, tabellen en koppen lopen door elkaar). Het officiële stuk bij de gemeente is leidend. Bron: https://api.notubiz.nl/document/13730112/1