melsk-r / HC-BAG-bevragen-issues

0 stars 0 forks source link

geconstateerd, oppervlakte, gebruiksdoel en type ook toestaan op andere parametercombinaties #280

Open melsk-r opened 4 months ago

melsk-r commented 4 months ago

Originally created by fsamwel (https://github.com/VNG-Realisatie/BAG-Gemeentelijke-wensen-tav-BAG-Bevragingen/issues/474):

Bijvoorbeeld combinatie met pandIdentificatie:

{
    "type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
    "title": "De combinatie van opgegeven parameters is niet toegestaan.",
    "status": 400,
    "detail": "Bad request.",
    "instance": "https://api.bag.acceptatie.kadaster.nl/esd/huidigebevragingen/v1/adresseerbareobjecten?gebruiksdoelen=woonfunctie&geconstateerd=true&type=verblijfsobject&pandIdentificatie=0599100000103376",
    "code": "unsupportedCombi"
}

Besproken met @CathyDingemanse en zij ziet geen reden dit niet toe te staan. Bijvoorbeeld de combinatie pandIdentificatie met gebruiksdoelen is ook logisch gebruik, om alle woningen in een flat te krijgen (en dus de serviceruimtes eruit te filteren).

Ook denk ik dat we zoveel mogelijk ingewikkelde eisen voor de gebruiker, die alleen uit het lezen van de description te halen zijn, moeten voorkomen. Voor minimaal op te geven parameters is dat wellicht onvermijdelijk, maar het verbieden van deze combinatie zou m.i. toch mogelijk moeten zijn.

melsk-r commented 4 months ago

This comment originally might have been created by someone else.

@CathyDingemanse @fsamwel Zouden jullie user stories willen maken voor de mogelijke zoek functionaliteiten, zodat we precies weten welke combinaties we moeten ondersteunen? Deze vraag stond ook in #470.

melsk-r commented 4 months ago

This comment originally might have been created by someone else.

Voor #470 geldt dit iig niet. Wij willen voorlopig geen andere parameters toestaan in combinatie met de vrije contour.

melsk-r commented 4 months ago

This comment originally might have been created by someone else.

Zouden jullie user stories willen maken voor de mogelijke zoek functionaliteiten, zodat we precies weten welke combinaties we moeten ondersteunen?

Ik zie het eigenlijk andersom. Standaard REST API functionaliteit is filteren met parameters, dus dat elke parameter samen met elke andere gebruikt kan worden. Ik snap de eis dat er minimaal een relevante parameter wordt gegeven, anders kan de API gebruikt worden om de hele BAG te downloaden, en dat is nadrukkelijk niet de bedoeling van de API. Dus moet je minimaal een van de parameters nummeraanduidingIdentificatie, pandIdentificatie, pandidentificaties of bbox. Maar dat wil niet zeggen dat het combineren van parameters daarmee ook uitgesloten moet worden. En dus ook niet waarom het aanvullend gebruiken van extra parameters als type en gebruiksdoelen verboden zou moeten zijn.

Ik had het verbieden van combinaties uit de specificaties ook niet geconcludeerd (en had er dus ook nog geen testgevallen voor om dit te testen). Vraag me af of dit voor andere gebruikers wel duidelijk is.

Een voorbeeld van een user Storie is de combinatie pandIdentificatie(s) met gebruiksdoelen. Bijvoorbeeld om alle bewoners van een (of meerdere) pand(en) aan te schrijven (en de serviceruimten en winkels en kantoren in hetzelfde pand niet).

melsk-r commented 4 months ago

This comment originally might have been created by someone else.

In overleg besproken. eerst uitzoeken wat functioneel de wens is en hoe dit opgelost moet worden (in een volgende release).

issue is gevolg van: