Het Kadaster heeft een nieuwe PDOK Location API ontwikkeld, die klaar is voor gebruik in websites, apps en geo-informatiesystemen. De PDOK Location API is een open, gratis en toekomstbestendige geocodeerapi waarmee je op een moderne, snelle en intelligente manier locatiegegevens kunt vinden uit verschillende overheidsregistraties. Via één uniform zoekmechanisme worden OGC API Features-collecties van meerdere officiële datasets doorzocht. Door het ingeven van (een gedeelte van) een zoekopdracht kun je razendsnel de juiste locatie vinden (‘geocoderen’). Of je nu zoekt op een adres, gebouw, perceel, wegdeel, of andere locatie-informatie (Bekijk alle collecties), binnen enkele milliseconden krijg je een compact antwoord als zoekresultaat. In die zin lijkt de Location API sterk op de Locatieserver.
Maar de techniek is anders
Daar waar de Locatieserver soms wat diffuus tot resultaten komt is het bij de Location API erg transparant. De collecties (uit de open geodata van PDOK in OGC API Features) die gebruikt worden om op te kunnen zoeken, zijn samen met data-aanbieders vastgesteld. Ook de criteria waarop is geselecteerd zijn getoond. En krijg je een resultaat dan is direct zichtbaar uit welke bron dit komt. Wil je vervolgens meer informatie dan ga je direct naar de bron. Door het zoeken dus te combineren met de nieuwste bevragingsservice is informatie zo up-to-date mogelijk.
Wat kun je ermee?
Wie al bekend is met de Locatieserver zal veel herkennen. Net zoals bij de Locatieserver kunnen gebruikers eenvoudig zoeken op tekst en krijgen direct relevante resultaten terug. Door slimme technieken als auto-aanvullen en ondersteuning van alternatieve schrijfwijzen en synoniemen vind je snel wat je zoekt. Met slimme ranking, selectie van bron, highlight-functionaliteit en ondersteuning binnen een geografische gebied (bounding box) vindt de PDOK Location API altijd de meest relevante locaties voor jouw zoekopdracht.
Het grootste voordeel is dat je als afnemer geen geo-expert hoeft te zijn en dat je zelf, vanuit jouw applicatie of website, invloed uit kunt oefenen op de data waarop je wilt zoeken.
Slim zoeken naar adressen, postcodes, functionele gebieden, tunnels, bruggen, percelen en meer
Nog actuelere data en direct bij de bron
Resultaten in verschillende kaartprojecties opvragen
Gemakkelijk zelf je eigen zoekcomponent maken voor websites en applicaties
Aan de slag?
De nieuwe Location API biedt al voldoende basisfunctionaliteit voor gebruik in de PDOK viewer, de activiteiten om over te stappen staan gepland. Maar het is nog geen volwaardige vervanger, zo ontbreken er nog databronnen, is er nog geen invulling gegeven aan reverse geocoderen (zoeken door te klikken op de kaart) en verandert er mogelijk nog iets in de standaarden. Je ziet in één oogopslag (via collecties) welke databronnen er al beschikbaar zijn. Er vindt nog doorontwikkeling plaats, zo zijn er vergaande gesprekken om collecties uit het Nationaal wegenbestand, Wijken en buurten (CBS) en Kadastraal objectlocaties (appartement-informatie) op te gaan nemen in de Location API.
De Basisregistratie Adressen en Gebouwen (adressen en woonplaatsen)
De Bestuurlijke gebieden (provincie- en gemeentegebieden)
De Kadastrale Kaart (Percelen)
De Basisregistratie Topografie via de TOP10NL (functionele gebieden en diverse andere collecties).
Meer informatie
De PDOK Location API is primair een geocodeerapi die aangeeft waar de detailinformatie per item kan worden bevraagd. Voor het downloaden van bulk data biedt PDOK andere mogelijkheden via webservices en/of downloads.
Bekijk voor gebruik de PDOK Location API Leermodule
en volg discussies en geef feedback op het Geoforum
. Tot slot is er een PDOK Location API handout
beschikbaar waarin meer ingegaan wordt op de vergelijking met de locatieserver.
Uitleg of meer lezen?
Voor uitleg van afkortingen en begrippen die gaan over webservices en OGC API’s, klik hier
Eens een kijkje genomen, ook in de leermodule. Een aantal dingen die mij zo opvallen:
Wat voegt dat [version]=1 toe? ALs je 0 of 2 probeert, komt er niks meer terug uit die collectie. Dus m.i. voegt dat niks toe, behalve een langere, slechter leesbare url. Het lijkt mij makkelijker en duidelijker om een komma-gescheiden lijst van collections door te geven (dus iets als &collections=adres,woonplaats ipv &adres[version]=1&woonplaats[version]=1).
De voorbeeld-urls in de Leermodule landen op een webpagina per default als je die in je browser plakt (ik mag geen curl gebruiken op mijn werklaptop - dus het makkelijkst is om een dergelijke url in de browser te plakken) - en dan zie je dus niet dat het antwoord bijvoorbeeld 502 - bad request is. Je moet dan zelf f=json toevoegen (format=json werkt niet, heb ik gemerkt). De HTML-pagina verbergt dat antwoord, en dan krijg je bij zoeken op “Dam” in adressen geen features (terwijl ik er daar toch wel een flink aantal zou verwachten)
Het feit dat je van tevoren al een idee moet hebben van wat je zoekt, vind ik een nadeel ten opzichte van de huidige locatieserver. Je moet nu aangeven in welke collecties je wil zoeken, dus dat impliceert dat je al weet dat het gaat om een adres, woonplaats of gebied of zo. Het suggest-endpoint van de huidige locatieserver is daar veel soepeler in, en persoonlijk vind ik dat een groot voordeel - je zoek-code word een stuk generieker.
Linken naar de bron voor het opvragen van de details vind ik een uitstekend idee, met 1 uitzondering: wegen en straten. Openbare Ruimtes hebben geen geometrie, dus kun je niet op de kaart tonen - maar de NWB heeft dat wel (niet altijd correct, maar dat is wat anders). Als je in de huidige locatieserver een openbare ruimte opvraagt, krijg je een (vereenvoudigde) lijn-geometrie terug - dat is ideaal voor een web-applicatie om als highlight op de kaart te tonen. Hopelijk word dat, als de NWB aan de collecties word toegevoegd, nog wel geimplementeerd, want een zoekresultaat op de kaart highlighten werkt m.i. het best als de geometrie daarvan overeenkomt met wat je zoekt (dus een punt voor een adres, lijn voor een weg/straat, vlak voor een gebied).
parameters zijn een beetje inconsistent. De een is een heel woord, de ander is een enkele letter, daar struikelde ik even over
Het default CRS zou m.i. niet CRS84 moeten zijn, maar EPSG:28992. Nu moet ik expliciet aangeven dat ik de resultaten in RD wil terugkrijgen. Mij lijkt dat de omgekeerde wereld in NL, maar dat is mijn mening.
Dat zijn zo de eerste paar dingen die ik tegenkom. Ik zie wel voordelen, maar op dit moment dekt de bestaande locatieserver mijn behoeften beter. Hopelijk blijft die nog even bestaan (en bijgewerkt, qua gegevens ).
Word vast nog wel vervolgd, als ik wat meer tijd heb
Toevallig een voorbeeldje: Ik had reden om de Venneweg in Hippolytushoef op te zoeken, dus heb dat eens via beide locatie services geprobeerd.
De Venneweg is een Openbare Ruimte zonder adressen:
Dus afgezien van het verschil in lengte van de url, vind ik dat nog wel een dingetje, zeker als de Veiligheidsregio’s hier ook gebruik van (moeten?) gaan maken. Maar mijn collega’s gaan hier ook last van krijgen, omdat vrijwel alles in het buitengebied ligt, aan wegen die veelal geen adressen hebben (het is al lastig genoeg om dan uit te moeten leggen dat zo’n weg dan geen postcode heeft, laat staan dat ie dan helemaal niet gevonden word zonder aanliggende adressen). Omdat Openbare Ruimtes geen eigen geometrie kennen (het waarom daarvan is mij nog steeds een raadsel: in het begin van de BAG moest er bij het vastleggen van de Openbare Ruimtes een kaart in de brondocumentatie aanwezig zijn - waarom dan geen geometrie opnemen in de registratie?), is het hier dus wel van belang dat de NWB hier op de een of andere manier aan geknoopt word. Want op dit punt mist er dus duidelijk functionaliteit, omdat niet ieder wegdeel van de BRT een straatnaam heeft (of in ieder geval niet zoekbaar - A7 bijvoorbeeld word wel gevonden in Wegdeel, maar gewone wegen of straten niet, zoals blijkt uit dit voorbeeld).
Ontzettend bedankt voor je uitgebreide review, daar kunnen we wat mee!
Even beantwoorden is een ding, maar hierbij alvast enkele opmerkingen over de Location API zelf, je opmerkingen over de leermodule pakken we ook op. Weet even dat we alle feedback meenemen in ons doorontwikkeltraject, maar mogelijk niet alles al op korte termijn kunnen realiseren.
1. Allereerst is het maar goed dat je deze Location API nog niet als vervanger ziet van de locatieserver. Je zou dan inderdaad data en functionaliteit missen. Zoals aangegeven hebben wij er alle vertrouwen in en gaan deze wel gebruiken in onze eigen PDOK Viewer. Voorlopig blijven beiden nog naast elkaar voortbestaan en hebben we geen datum voor uitfaseren vastgesteld, geen zorgen.
2. Dan over NWB en linken naar de bron. Fijn dat je die oplossing een uitstekend idee vindt ;). De data van NWB is nog niet opgenomen. As we speak is NWB bezig met het maken van een leverbestand waarmee wij vernieuwde en verbeterede services en API’s gaan maken. Inderdaad hebben we samen slim nagedacht over een oplossing. Onze gezamenlijke verwachting is dat afnemers van o.a. de Location API daarmee gebaat zullen zijn. Zodra we iets aanpassen/wijzigen maken we een bericht in dit kanaal en dan wil ik je vragen om hier nog eens extra naar te kijken.
3. Inderdaad moet je zelf van te voren een idee hebben van wat je zoekt en dat hebben we nu juist zo ingesteld om meer bewust zoekgedrag te stimuleren. In het genoemde overzicht van collecties is het voorlopig de intentie om identiek met de Locatieserver aan te bieden. Daarnaast hebben we uitgebreid met collecties uit de TOP10NL. Dus als je die uitzet zou je identieke informatie terug moeten ontvangen (maar zoals gezegd ontbreekt er nog data).
4. Over default CRS dat klopt, dit is de standaard voor de OGC API’s en die volgen wij. We snappen dat de verwachting default RD is, maar helaas moeten we ons confirmeren aan de internationale standaard. Dat is de reden dat wij meerdere CRS uitserveren en je in feite (gelukkig maar) kan kiezen.
5/6. Ten aanzien van je opmerkingen over inconsistente parameters en [version]=1 ga ik even met de achterban in overleg zodat ik je ook kan vertellen waarom dit zo werkt.
Met betrekking tot 4 wil ik nog wel het volgende inbrengen:
WGS84 hoef je alleen terug te sturen als er helemaal GEEN crs beschikbaar is in de request. Als je zelf bij voorbaat wel een crs opgeeft, zoals in het api-overzicht, dan mag deze best “by default” op RD staan.
Sommige van mijn opmerkingen zijn misschien een beetje nitpicken, maar ik heb wat lopen spelen en alles wat ik tegenkwam maar even opgeschreven. Dus hoe serieus je dingen moet nemen is aan jullie
Dat gezegd hebbende:
Hier ben ik het niet helemaal mee eens. In Nederland is de standaard om met RD (EPSG:28992) te werken. Dus dat zou m.i. hier ook het geval moeten zijn, en past zeker binnen het pas-toe-of-leg-uit principe.
Maar goed, dat is wederom mijn mening, en het voegt voor mij in ieder geval weer een extra parameter toe die ik dus vrijwel altijd moet toevoegen - en da’s ietwat onhandig (en geheid iets wat ik een keer ga vergeten…)
Ik ben de nieuwe API nu aan het testen om de PDOKgeocoder te vernieuwen die ik voor FME heb uitgewerkt als custom transformer (zie PDOK Locatieserver als geocoder voor FME). Ik loop daarbij tegen dezelfde dingen aan als @sbjager al aangeeft.
Ik zou het in ieder geval erg handig vinden dat standaard alle collecties/bronnen worden gebruikt als je niets specificeert. Nu moet je verplicht één of meer collecties meegeven.
Ik ga ondertussen nog verder puzzelen met de API, dus wanneer ik nog meer dingen tegen kom dan zal ik het hier melden!
).