Hoe de woningscan werkt
Je vult een postcode en huisnummer in en ziet binnen twee seconden hoe groot het pand is, wanneer het gebouwd is, waar het voor gebruikt wordt en hoe het eruitziet van boven. Hieronder staat precies hoe dat werkt, inclusief de twee dingen die we onderweg fout deden.
Waar de gegevens vandaan komen
Drie aanroepen bij PDOK, allemaal openbaar en zonder sleutel. De Locatieserver zoekt het adres op en geeft een object-id en de coördinaten terug. Het BAG-verblijfsobject levert de oppervlakte en het gebruiksdoel. Het BAG-pand levert het bouwjaar en de omtrek van het gebouw. Dat bouwjaar zit dus niet in het verblijfsobject maar in het pand eromheen, en dat is het soort ding dat je pas weet als je het gebouwd hebt.
Valkuil één: het verkeerde pand
De voor de hand liggende manier om een adres op te zoeken is een vrije zoekopdracht met postcode en huisnummer, en dan het eerste resultaat pakken. Dat levert het verkeerde pand op. Bij "1012AB 1" krijg je een heel ander huisnummer aan hetzelfde plein, bij "1012AB 14" krijg je 14B, en bij een postcode in Nijkerkerveen krijg je een adres in een andere straat. Telkens één treffer uit honderdduizenden, en telkens niet degene die je bedoelde. Met exacte filters op postcode en huisnummer blijft er precies één over. We hebben dat gemeten en niet aangenomen.
Valkuil twee: de kaart een halve provincie verderop
Nederlandse kaartgegevens staan in Rijksdriehoek, een eigen coördinatenstelsel. De gebruikelijke reflex is om dat om te rekenen naar de lengte- en breedtegraden die de rest van de wereld gebruikt. Dat hoeft hier niet: de luchtfotodienst accepteert Rijksdriehoek gewoon, en de BAG levert de omtrek van het pand in datzelfde stelsel. Uitsnede en omtrek vallen daardoor samen zonder ook maar één omrekening. Dat scheelt niet alleen werk: elke conversie is een kans om er een akker in Duitsland van te maken.
Waarom we niets bewaren
Er heeft een cache in gezeten, met het adres als sleutel. Die is eruit gehaald, en niet omdat hij traag was. Een cache met het adres als sleutel is precies wél het adres opslaan, en dan klopt de regel onder het formulier niet meer. Het adres gaat daarom in de body van een POST en nooit in een webadres, want daar belandt het in serverlogs, in analytics en in je browsergeschiedenis. Op het antwoord staat no-store. Misbruik remmen we af met een limiet per bezoeker in plaats van met een cache. De winst zou trouwens klein zijn: die drie aanroepen samen duren ongeveer een halve seconde.
Wat er gebeurt als een bron wegvalt
Elk veld kan los ontbreken zonder dat de rest stukgaat. Geeft de BAG niets terug, dan blijven oppervlakte en gebruiksdoel leeg en zie je de rest gewoon. Alleen een adres dat niet gevonden wordt is blokkerend, want dan valt er niets te tonen. Op elke aanroep staat een timeout van acht seconden: een demo die twintig seconden hangt is erger dan een demo met een ontbrekend veld.
We bewaren je adres niet
Niet in een database, niet in een logregel, niet in een cache. Wat je invult gaat naar de openbare bronnen en het antwoord komt terug naar je scherm. Daarna is het weg. Dat is geen instelling die we aan hebben staan maar een gevolg van hoe het gebouwd is, en het is de reden dat er hierboven geen cache zit.
De scan zoekt op in het Nederlandse adressenregister, dus hij werkt met Nederlandse postcodes.