Als we de page-size reduceren tot bv 10 dan is het prettig als er meer dan 30 testgevallen op te vragen zijn in de collectie om het pagineren te kunnen testen.

zodat ik beleid kan maken en kan handhaven

zodat iedere gemeente met eigen data acceptatietesten en integratietesten kan doen.

Eigen data betekent: kadastrale onroerende zaken binnen mijn gemeente.

zodat ik kan voorkomen dat aan hen een parkeervergunning kan worden toegewezen.

... zodat ik alle gegevens in de API kan gebruiken en de verwerking daarvan in mijn applicatie kan testen

Zie de tabel in /test/cases.

Velden waar nog geen waarde voor is:

• aanduiding.locatieomschrijving
• adresseerbaarObjectIdentificaties: >1 items
• belanghebbendeEigenaar.geheimhoudingPersoonsgegevens: true
• belanghebbendeEigenaar.kvkNummer
• belanghebbendeEigenaar.vestigingsnummer
• belanghebbendeEigenaar.type: vestiging
• belanghebbendeGebruiker.geheimhoudingPersoonsgegevens: true
• belanghebbendeGebruiker.burgerservicenummer
• belanghebbendeGebruiker.kvkNummer
• belanghebbendeGebruiker.vestigingsnummer
• belanghebbendeGebruiker.type: natuurlijk_persoon en vestiging

zodat ik mijn applicatie kan testen en demonstreren met werkende gerelateerde data.

dus:

• aanduiding.nummeraanduidingIdentificatie is bestaand adres in BAG (identificatie + hele adres)
• adresseerbaarObjectIdentificaties is bestaand adresseerbaar object in BAG
• belanghebbendeEigenaar en belanghebbendeGebruiker is, wanneer dit natuurlijk persoon met burgerservicenummer is, bestaande persoon in GBA-V proefomgeving
• belanghebbendeEigenaar en belanghebbendeGebruiker is, wanneer dit niet-natuurlijk persoon is met rsin, kvknummer of vestigingnummer, bestaande persoon, maatschappelijke activiteit of vestiging in KvK dataservice
• belanghebbendeEigenaar is eigenaar in Haal Centraal BRK API testomgeving

Het zoeken van WOZ-objecten van natuurlijk personen (op burgerservicenummer), gaat via de BRK API. De daarin gevonden onroerende zaken moeten ook een bijbehorend WOZ-object hebben. Dus heb ik WOZ-objecten nodig voor kadastraalOnroerendeZaakidentificaties:

• 76870487970000
• 22310827210003
• 65490485270000
• 17550448670000

zodat ik het vermogen van aanvrager kan bepalen.

GET 'https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten/000500055044?fields=bestaatniet'

geeft in de response:

"invalidParams": {
        "reason": "ongeldige waarde: 'bestaatniet' opgegeven",
        "name": "fields",
        "code": "fields"
    },

invalidParams is volgens schema een array, maar in de response is het object direct opgenomen.

https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten?rsin=020664606 vindt geen WOZ-object

https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten/800000051111 bevat in het antwoord:

    "belanghebbendeEigenaar": {
        "naam": "Boerderij Mutatie BV",
        "rsin": "020664606",
        "type": "niet_natuurlijk_persoon"
    },

Dus had ik verwacht dat met zoeken op rsin=020664606 het WOZ-object 800000051111 zou worden gevonden.

zodat ik de kwaliteit van deze basisregistraties kan verhogen door het uitvoeren van kwaliteitsanalyses terugmeldingen.

Het gaat om de relaties:
BAG-WOZ, BRK-WOZ, BRP-WOZ, HR-WOZ

Het zoekresultaat wordt nu geplaats in "_embedded": { "wozobjecten": [ ... ] }

Volgens het API schema zou dit moeten zitten in "_embedded": { "wozObjecten": [ ... ] }

(dus hoofdletter "O" voor Objecten)

zodat ik kan beoordelen of een pand geschikt is om aan te kopen of te verkopen.

zodat ik in het kader van de participatiewet een afweging kan maken over enerzijds het vestigen van een krediethypotheek of verkoop van het huis.

exclusief WOZ waarden, externe links en fields parameter

zodat ik mijn zoekcriteria kan verfijnen en daarmee de kansen vergroot om te vinden wat ik zoek.

In de Haal Centraal API's hebben we afgesproken properties met leegwaarden (null of lege array of object waarin geen enkele property een waarde heeft)) niet te leveren.

Ook worden indicatoren (booleans) alleen geleverd wanneer de waarde true is. Dit om te voorkomen dat berichten heel veel lege/niet relevante properties bevat.

Bijvoorbeeld in het antwoord hieronder zouden we properties geheimhoudingPersoonsgegevens, kvkNummer, rsin, vestigingsnummer, belanghebbendeGebruiker en kadastraalOnroerendeZaakIdentificaties niet opnemen in het antwoord.

    "belanghebbendeEigenaar": {
        "burgerservicenummer": "48",
        "geheimhoudingPersoonsgegevens": false,
        "kvkNummer": null,
        "naam": "Binnenhuis",
        "rsin": null,
        "type": "INP_BSN",
        "vestigingsnummer": null
    },
    "belanghebbendeGebruiker": null,
    "grondoppervlakte": 106,
    "identificatie": "000500055044",
    "kadastraalOnroerendeZaakIdentificaties": [],

Wat hier dan overblijft is de volgende response:

    "belanghebbendeEigenaar": {
        "burgerservicenummer": "48",
        "naam": "Binnenhuis",
        "type": "INP_BSN"
    },
    "grondoppervlakte": 106,
    "identificatie": "000500055044",

zodat ik:

• de relevante waarden als beschreven in de waarden.feature kan implementeren en dit kan testen
• de features kan valideren
• deze situaties met mijn client applicatie kan testen

In de features zoeken, waarden en belanghebbende naam staan testsituaties beschreven. Deze wil ik graag beschikbaar hebben als testdata in de WOZ-bevragen API.

N.B. wanneer exact dezelfde gegevens niet mogelijk of erg onhandig zijn, kunnen details (zoals identificaties) zo nodig worden aangepast in de features.

GET 'https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten/000500055044?fields=bestaatniet'

levert in het antwoord "instance": "/wozobjecten/000500055044"

Hierin ontbreekt de fields parameter die ook was meegegeven (en die in dit geval zelfs de oorzaak is van de fout)

In de specificaties voor problem+json is instance gedefinieerd met format: uri.

Verschillende tooling, zoals Postman geeft hierop een foutmelding, wanneer een relatieve link wordt geleverd. Formeel is het denk ik niet fout om een relatieve link te leveren, maar wellicht toch beter absolute link te leveren (om een foutmelding in Postman te voorkomen)?

zodat ik een krediethypotheek op het huis kan vestigen, waardoor ik bij verkoop van het huis aanspraak kan maken op een deel van de opbrengst.

zodat ik de hoogte van de erfpachtcanon kan bepalen.

zodat ik kan berekenen of het gaat om een woning met minder dan 185 punten waarvoor bewoners een huisvestigingsvergunning moeten hebben.

Voor woningen die lager zijn dan 185 punten of 950 euro moet je in het bezit zijn van een huisvestingsvergunning. Geldt zowel voor de sociale woningvoorraad, als voor particulieren.

In WozObjectHal is sprake van inconsistentie in naamgeving.
Naast de property 'belanghebbendeEigenaar' komt er in ' _links' de property 'belanghebbendEigenaar' voor en naast de property 'belanghebbendeGebruiker' komt er in ' _links' de property 'belanghebbendGebruiker'.

Maak deze aan elkaar gelijk.

Uit de opmerking van @oversticht, zie #34 (comment), blijkt dat de LV niet in staat is de juiste omschrijving te leveren op basis van de codering.

De soort belanghebbendeEigenaar willen we eigenlijk als omschrijving leveren. Deze zou moeten worden samengesteld uit de codering voor Aard zakelijk recht. Die kan bestaan uit 1, 2 of 3 2-letter codes (dus een code van 2, 4 of 6 letters lang). De omschrijving van het soort zakelijk recht moet worden samengesteld door de omschrijvingen van de codes achter elkaar te plakken.
Bijvoorbeeld code "PEOS" betekent "recht van erfpacht belast met recht van opstal".

Een oplossing kan zijn soort te definiëren als array voor elke deelcode. Bijvoorbeeld "PEOS" wordt dan "soort": ["PE", "OS"].

Liever dan de codes (zoals "EP"), zou ik meer begrijpelijke codering gebruiken, zoals "recht_van_erfpacht". Bijvoorbeeld "PEOS" wordt dan "soort": ["recht_van_erfpacht_belast_met", "recht_van_opstal"].

Wellicht nog beter (wanneer de gebruiker niet de code, maar de tekst wil) is de array items niet als enumeratie, maar als string te definiëren. "PEOS" wordt dan "soort": ["recht van erfpacht belast met", "recht van opstal"].

@oversticht:

• leidt het opsplitsen van de codering en voor elke code de omschrijving gebruiken zoals hierboven staat tot de juiste samengestelde omschrijving van de soort/aard zakelijk recht?
• kan de LV wel de 2, 4 of 6 letter code naar 1, 2 of 3 2-lettercodes en deze vertalen naar enumeratiewaarden (bijvoorbeeld "EP" = "recht_van_erfpacht") of strings (bijvoorbeeld "EP" = "recht van erfpacht")?

zodat ik dit kan verwerken in statistieken waarop beleid kan worden gemaakt, en aangepast.

zodat ik de openbare ruimte kan inrichten, en de doelstellingen gebiedsontwikkeling en vastgoeddoelstellingen van de gemeente kan realiseren

Met elke response moet de API-version worden geleverd. Die ontbreekt nu nog.

wanneer ik zoek maar niks vindt, leveren de andere Haal Centraal API's in het antwoord property _embedded als leeg object:

{
    "_links": {
        "self": {
            "href": "http://api.acceptatie.kadaster.nl/haalcentraal-api/wozobjecten?rsin=123456789"
        }
    },
    "_embedded": {}
}

Op dit moment wordt alleen _links geleverd, niet _embedded. Voor consistente werking van de verschillende Haal Centraal API's zou graag dat hier ook zo terugleveren.

zodat ik bij outsourcing van deze taak aan een samenwerkingsverband te aller tijde over de gegevens kan beschikken waarvoor ik eindverantwoordelijk ben.

...zodat zodat ik sneller/gemakkelijker een WVg- of onteigeningsbesluit kan voorbereiden of een koopovereenkomst kan opstellen.

De Wvg is een bestuursrechtelijk instrument met privaatrechtelijke inslag en kan gezien worden als een vorm van publiekrechtelijk optierecht.

De property 'kadastraalOnroerendeZaken' in 'WozObjectHal' volgt DD1.8 niet. Deze zegt:

Wanneer een relatie-property (niet link of embedded) alleen de identificatie van een gerelateerde resource bevat en geen andere properties, wordt als naam van de property de naam van de resource plus het woord 'Identificatie' gebruikt.

Het schemafragment ziet er als volgt uit:

        kadastraalOnroerendeZaken:
          type: array
          description: De kadastraal onroerende zaken die geheel of gedeeltelijk deel uitmaken van het WOZ-object
          items:
            $ref: '#/components/schemas/KadastraalOnroerendeZaak'

Terwijl je volgens mij

        kadastraalOnroerendeZakenIdentificaties:
          type: array
          description: De kadastraal onroerende zaken die geheel of gedeeltelijk deel uitmaken van het WOZ-object
          items:
            type: string

zou verwachten.

zodat ik zodat ik kan beoordelen of een pand geschikt is om aan te kopen of te verkopen

https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten?rsin=020664606

bevat:
"_links": {
"self": {
"href": "http://api.acceptatie.kadaster.nl/haalcentraal-api/wozobjecten?rsin=020664606"
}
}

De base url is niet correct:

• http i.p.v. https
• "haalcentraal-api" i.p.v. "lvwoz/api/v1"

Idem in de self link van gevonden wozobjecten:

                "_links": {
                    "self": {
                        "href": "http://api.acceptatie.kadaster.nl/haalcentraal-api/wozobjecten/800000051111"
                    }

En in de self link bij het raadplegen van een WOZ-object. Bijvoorbeeld https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten/000500055044 geeft:

    "_links": {
        "self": {
            "href": "http://api.acceptatie.kadaster.nl/haalcentraal-api/wozobjecten/000500055044"
        },

zodat ik kan beoordelen of een pand geschikt is om aan te kopen of te verkopen

zodat ik (massaal) terugmeldingen kan doen bij het Kadaster op de perceel-object koppeling.

zodat ik een garagelijst kan opstellen
en inzicht krijg in de problematiek en feitelijke situatie in kader van de plannen voor de projecten Autoluw en kades & bruggen, ook op de kaart

GET 'https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten/000500055044?fields=adresseerbaarObjectIdentificaties,grondoppervlakte'

dit levert in het antwoord:
"_links": {
"self": {
"href": "http://api.acceptatie.kadaster.nl/wozobjecten/000500055044?fields=adresseerbaarObjectIdentificaties&fields=grondoppervlakte"
}
}

De verschillende waarden in fields zijn opgesplitst in verschillende voorkomens van de fields parameter. De waarde in _links.self.href moet identiek zijn aan het request

Hoe gaan we om met de situatie dat een vorige bewoner bezwaar indient op een beschikking, en er voor de nieuwe bewoner er een beschikking is met meer recente ingangsdatum (op zelfde peiljaar)?

1. Wordt indicatieBezwaarBeroep=true (want er loopt een bezwaar tegen een beschikking op dit peiljaar)
2. Of indicatieBezwaarBeroep=false (want het bezwaar betreft een andere beschikking dan die die getoond wordt)?

/wozobjecten/000000061120 levert belanghebbendeEigenaar met "type": "INP_BSN"

Volgens de specificaties is dit een enumeratie:

        type:
          $ref: '#/components/schemas/PersoonTypeEnum'

    PersoonTypeEnum:
      type: string
      enum:
      - natuurlijk_persoon
      - niet_natuurlijk_persoon
      - vestiging

get /wozobjecten/bestaatniet levert nu een 400 foutmelding:
{
"type": "https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1",
"title": "Een of meerdere parameters zijn niet correct.",
"detail": "Parameter 'identificatie' is geen valide wozobject identificatie",
"instance": "/wozobjecten/bestaatniet",
"status": 400,
"code": "paramsValidation"
}

Dit is denk ik niet terecht, want in de specificaties is niet opgegeven waar de identificatie aan moet voldoen, anders dan dat het een string is (en dat is het).

      parameters:
        - name: identificatie
          in: path
          description: Unieke identificatie van een WOZ-object
          required: true
          explode: true
          schema:
            type: string

Ik had daarom een 404 not found verwacht i.p.v. de 400 fout.

Mogelijk is het wel wenselijk de mogelijke waarden voor identificatie te beperken, bijv. met een pattern. Dat moet dan in de specificaties worden toegevoegd (en dan is de 400 fout wel terecht). Aan de gebruiker moet dan ook in de foutmelding gemeld krijgen waar de identificatie aan moet voldoen om wel een geldige identificatie te kunnen zijn.

Wat zijn de eisen aan de invoer (reguliere expressie, minimale en/of maximale lengte)?

Daarnaast had ik in dit geval (als dat ook in de specificaties is opgenomen) ook invalidParams verwacht, bijvoorbeeld:
"invalidParams": [
{
"name": "nummeraanduidingidentificatie",
"code": "pattern",
"reason": "Waarde voldoet niet aan patroon ^[0-9]{12}$."
}
]

zodat ik heffingen kan bepalen

de WOZ api vereist nu een API-key header "apikey". In de andere Haal Centraal API's (BAG en BRK gebruiken we "x-api-key". Ik denk dat het uiteindelijk handig is om in alle API's dezelfde api-key headernaam te gebruiken.

Kan de API-key headernaam worden gewijzigd in "x-api-key"?

GET 'https://api.acceptatie.kadaster.nl/lvwoz/api/v1/wozobjecten/000500055044?fields=_links' geeft een foutmelding:

{
    "type": "https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1",
    "title": "Een of meerdere parameters zijn niet correct.",
    "detail": "Parameter 'fields' bevat een (deels) ongeldige waarde",
    "instance": "/wozobjecten/000500055044",
    "status": 400,
    "invalidParams": {
        "reason": "ongeldige waarde: '_links' opgegeven",
        "name": "fields",
        "code": "fields"
    },
    "code": "paramsValidation"
}

_links is een property in de response, dus zou geen foutmelding moeten geven (ook al wordt die altijd geleverd)

Plus invalidParams is volgens schema een array, maar in de response is het object direct opgenomen: #69

zodat ik daar ons beleid op kan baseren

bij een request zonder gebruik van de fields parameter, bevat de self link {?fields} en templated: true

get http://api.acceptatie.kadaster.nl/wozobjecten/000500055044

bevat in de response:

    "_links": {
        "self": {
            "href": "http://api.acceptatie.kadaster.nl/wozobjecten/000500055044{?fields}",
            "templated": true
        }
    },

Ik had hier verwacht:

    "_links": {
        "self": {
            "href": "http://api.acceptatie.kadaster.nl/wozobjecten/000500055044"
        }
    },