Ik heb voor de testomgeving BAG bevraging een API key aangevraagd en hiermee wil ik het e.e.a. testen, maar het ontbreekt aan enige documentatie hoe een API uberhaupt te gebruiken in bijvoorbeeld QGIS en/of FME. Gewoon basis en niet direct de diepte in. Waar vul ik wat in? Hoe ziet de URL er nu uiteindelijk uit?
Er zijn vast links te vinden (ook op dit forum), maar het lijkt of iedereen met Postman (of een soortgelijk programma) werkt i.p.v. QGIS/FME.
Alvast bedankt voor een reactie.
Heel herkenbaar. Ik gebruik veel FME, en het kost me elke keer weer een heleboel trial-and-error om de gegevens een beetje correct uit welke API of WFS dan ook op PDOK te halen. Documentatie op dat gebied is ontzettend summier. Er word dan wel weer verwezen naar de standaarden, maar dan kom je direct weer uit bij de standaarddefinities, die zo uitgebreid zijn dat je door de bomen het bos niet meer zietā¦
Kost me elke keer weer vreselijk veel tijd.
Elke tool heeft natuurlijk zijn eigen manier om met WFS om te gaan. Die zal dus per tool beschreven moeten worden. Het lijk me praktisch dat de aanbieder van de WMS zich op het bieden van de service en bijbehorende metadata richt en niet op alle mogelijke afnemers en de software die zij gebruiken.
Voor QGIS staat het hier uitgelegd:
En er is natuurlijk de āPDOK Services Pluginā voor QGIS waarmee je de service gewoon kan vinden en met een klik toevoegen aan je project.
Het is niet alleen WFS, het zijn ook de APIās. En wat is er mis met een simpel voorbeeldje bij een WFS, over hoe je bijvoorbeeld filtert op een geometrie of een attribuut?
Ik zie genoeg verschillen, soms minuscuul, tussen verschillende WFSāsen. En voor de APIās geld hetzelfde. Een simpel voorbeeld is al voldoende, maar daar ontbreekt het simpelweg aan.
Natuurlijk heeft elke tool zān eigenaardigheden, eisen enzovoorts. Maar alls ik bijvoorbeeld wil zoeken binnen een vlak, dan is het handig als er een voorbeeldje te vinden is van de json die ik moet posten naar de API, of naar de WFS, en welke waarden daar in moeten, en wat dan vervolgens het antwoord is. De locatieserver doet dat naar mijn mening nog het beste.
Ik weet dat elke tool een eigen manier heeft om met WFS om te gaan. En ik weet ook hoe ik WFS (e.d.) kan gebruiken binnen QGIS/FME/Geoserver enz. Waar het mij om gaat is dat het bij bijvoorbeeld een WFS een kwestie is van de URL kopieren/plakken en ik heb alle services. Bij een API is het niet zo dat ik de URL https://bag.basisregistraties.overheid.nl/api/v1/API-key kan gebruiken en direct de beschikking heb over de data die ik zoek. Daar is meer voor nodig en dƔƔr gaat het me om.
Op internet wordt de indruk gewekt dat het een kwestie van gebruiken van de URL is en je bent āingepriktā op de brondata, maar helaas.
Als ik dus maar weet hoe ik de specifieke API-URL+key moet interpreteren en gebruiken, dan stel ik mijn eigen documentatie op.
De BAG individuele bevragingen API is niet bedoeld voor de verwerking van gegevens in QGIS en/of FME. Hiervoor is de WFS bedoeld.
In de loop van Q1 2021 komt er een nieuwe versie van de WFS beschikbaar die gebaseerd is op BAG 2.0
Ook hiervan ben ik op de hoogte. Mijn vraag is heel simpel:
welke URL moet ik gebruiken om van de API gebruik te kunnen maken, om bevragingen te kunnen doen op, in mijn geval, de BAG? Kan dit uberhaupt in QGIS of FME? De bedoeling is namelijk dat de API ingezet gaat worden voor interne bevragingen bij de organisatie waar ik werk.
In de toekomst wil ik een API gebruiken voor het (laten) bevragen van de BRK en ik wil graag op de hoogte zijn van de werking ervan. Vandaar dat ik een API-key heb aangevraagd van de testomgeving van de BAG Bevraging API.
Er is niet 1 URL zoals met een bijvoorbleed een WMS/WFS, het betreft een OpenAPI Specification 3 (OAS3) RESTful API. Qua documentatie is dat beschreven ā github. Waar ook links naar een āvisueleā representatie van het koppelvlak d.m.v. een swagger sausje ā Panden
Mogelijk dat @RobinTopper (of iemand anders) hier je iets meer over kan uitleggen.
Misschien dat @E.M.Knol een voorbeeld call kan laten zien om een Pand op te halen op basis van een BAGID?
Nope, tenzij iemand een plugin in QGIS wil gaan maken of een adapter voor FME. Deze twee applicaties leunen āsterkā tegen de OGC spec en deze API betreft geen OGC spec. (mogelijk dat iemand wel met HTTP calls het 1 en ander kan scripten binnen FMEā¦ maar 't werkt niet zo 1,2,3, out-of-the-box zoals je nu een WFS/SHAPEFILE/enzā¦ in FME zou inladen)
Een voorbeeld om een Pand op PandID te bevragen:
https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/panden/0200100000085932
Bedankt voor de informatie Wouter. Nu weet ik dat dat niet meer hoef te proberen in ieder geval. Ik heb al wel iets gevonden om het in FME wel te kunnen, maar nog niet zelf geprobeerd.
Soortgelijke URLās ben ik inderdaad vaker tegen gekomen. Als ik hier op klik ontvang ik de melding dat er een API key ontbreekt. Ik heb wel een API key, maar moet ik deze dan ergens plaatsen, zodat de bevraging wel informatie oplevert?
Dit soort dingen staan allemaal gedocumenteerd in de OAS. Als je aan de slag wil met REST APIs is het een goed idee je hier in te verdiepen. Alle overheids APIs zouden tegenwoordig een OASv3 moeten publiceren.
De API-key moet voor deze API in de X-API-KEY header meegegeven worden. Dit kan je browser niet zonder extensies. Dit is Ć©Ć©n van de redenen dat Postman in de forum topics zo vaak gebruikt wordt.
Die swagger paginaās zijn echt fantastisch handig!! Komt ook aardig in de buurt bij wat hier over API-voorbeelden wordt gevraagd denk ik.
En het wordt nog leuker in de toekomst, naar verwachting ook bij PDOK: de OGC definieert nu opvolgers van WFS, WMS, CSW etc gebaseerd op OAS3, de āOGC APIsā. De eerste resultaten zijn er al, bijv met het Open Source project pygeoapi, zie de demo hier. In De Grote Geo Show afl 11 is daar deel van uitzending aan gewijd.
Goed, toekomstmuziek, hebben we nu nog niet veel aan, maar wilde dit gezegd hebben.
Hoi ,
in Pyhton kan je het zo doen (en FME kan overweg met Python lee sik op internet)
import requests
for verblijfs_num_id in lijst_num:
try:
url = f'https://bag.basisregistraties.overheid.nl/api/v1/nummeraanduidingen/{verblijfsadres_num_id}'
payload = {}
headers = {'x-Api-Key': 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'}
response = requests.request("GET", url, headers=headers, data = payload)
data = response.json()
except:
pass
zoals anders al hebben gezegd kan je in Postman dit makelijk testen als je het werkend hebt dan kan je het in verschillende programmeertalen ophalen en gebruiken, Ruby php Curl etc.
succes ermee
Carlo
Bedankt voor je reactie. Ik ga weer eens verder met puzzelen. Fijn om dit even te zien zo
Bedankt voor je reactieā¦ Ik had alleen een kleine hoop dat mensen binnen onze organisatie eenvoudig bevragingen zouden kunnen doen
Is daarvoor de bagviewer niet heel handig?
WMS / WMTS / WFS / WCS / CSW zijn door het OGC internationaal gestandaardiseerde generieke Geo-APIs, die ondersteunt worden door de meeste GIS software systemen. Door middel van queries kun je vragen stellen aan deze APIs.
OAS APIs zijn vaak specifieke business APIs (ook wel convenience APIs genoemd, wat volgende de NL API Strategie betekent: āAPI die Ć©Ć©n specifieke gebruikersvraag beantwoordtā). Deze zijn tot op zekere hoogte ook gestandaardiseerd (OAS) maar laten desondanks nog (te) veel ruimte in de implementatie. In Nederland houdt het Kennisplatform APIs zich bezig met de aanvullende / verdere standaardisatie van APIs (aanvullend aan OAS), zie Kennisplatform API's | Geonovum en meer specifiek de Nederlandse API Strategie Kennisplatform API's | Geonovum. In de NL API Strategie staan concrete implementatie richtlijnen waaraan APIs in Nederland moeten voldoen. Op deze manier zullen APIs in de toekomst (nog) meer gestandaardiseerd worden. Op dit moment moet, door de verschillen in implementatie, vaak nog geprogrammeerd worden om APIs te kunnen aanroepen.
