@bartjkdp de CORS preflight request gaat nu goed. Dit werkt alleen wanneer de request volgens de http specificaties gedaan wordt, dus met een Origin en Access-Control-Allow-Methods header. Zie voorbeeld:
curl -X OPTIONS -H "Origin: http://example.com" -H "Access-Control-Request-Method: GET" -v https://api.pdok.nl/bzk/locatieserver/search/v3_1/suggest
Onlangs heeft PDOK gecommuniceerd dat de Locatieserver naar het nieuwe platform is gemigreerd (met nieuwe URL’s). Daarbij is gemeld dat XML als output niet meer ondersteund wordt.
Op basis van feedback van gebruikers is echter besloten om dit ook in de nieuwe variant van de Locatieserver weer mogelijk te maken. Naar verwachting zal de XML output volgende week weer beschikbaar zijn. Zodra gereed zal PDOK dit communiceren in deze post op het Geoforum.
Top Yvette_PDOK !
Wat fijn PDOK! hier zijn wij heel blij mee.
De XML output functionaliteit voor de nieuwe locatieserver is weer beschikbaar. XML output kan worden opgevraagd met de wt=xml parameter, gelijk aan hoe dat voor de huidige locatieserver is ingericht.
Toch verbaast het me enigszins hoe zo’n besluit (eerst geen XML en dan weer wel) tot stand komt.
Misschien is dit topic niet de meest logische plek en hoeft zo’n discussie ook niet publiek. Toch zou het fijn zijn als zo’n grote wijziging vooraf wat ruimer onderzocht werd, bijvoorbeeld door een poll of via het panel van het PDOK Ontwikkelteam. Of alvast eerder melden, zodat ontwikkelaars zich erop voor kunnen bereiden.
Heb na de eerste melding een dag uitgetrokken om mijn code om te bouwen, was achteraf dus niet nodig geweest. Heb weer wat geleerd van JSON, zullen we maar zeggen. Deze ervaring zal nu wel meespelen waarom ik toch even wilde reageren op dit besluit 
De verplichte ‘q’ parameter was niet helemaal duidelijk, dank voor de melding.
Wij hebben in onze applicatie een formulier die op dit moment géén gebruik maakt van de q parameter in de /free service. In dit geval is het use-case: formulier met verschillende velden (bv postcode, huisnummer, huisletter etc), waarbij elk veld expliciet in de query wordt toegevoegd met een filter.
Uiteindelijk resulteert dat in het formaat: /free?fq=type:adres&fq=postcode:1122AA&fq=huisnummer:66.
Dit levert goede betrouwbare resultaten op, echter werkt dat niet meer in 3.1.
Is er een mogelijkheid voor deze functionaliteit zonder ‘vrije’ query?
We hebben dit eerlijkheidshalve onderschat. We zagen laag gebruik (o.a. t.o.v. JSON) en omdat er sprake was van nieuwe URL’s (en een half jaar overgangstermijn) leek het een geschikt moment. Excuses en gelukkig dat de investering in JSON niet helemaal voor niks is geweest.
We hebben dit intern nog even besproken en voor de /free API is het inderdaad wellicht handig om zonder q parameter te kunnen zoeken. Voor de /suggest laten we hem wel verplicht omdat deze API specifiek voor autocomplete doeleinden bedoeld is. Als de wijziging is doorgevoerd laat ik het weten.
De q parameter is niet langer verplicht op het /free endpoint.
Zojuist even een test gedaan met de oude en nieuwe versie van de free variant.
Oud:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?q=2991HC+and+6&wt=xml&rows=999&plaats=&straatNaam=&huisnummer=6&postcode=2991HC&huisletter=&huisnummertoevoeging=
Nieuw:
https://api.pdok.nl/bzk/locatieserver/search/v3_1/free?q=2991HC+and+6&wt=xml&rows=50
Als ik bij de nieuwe API de velden opneem achter &rows krijg ik een foutmelding. Is dat niet meer toegestaan of niet meer nodig? Overigens geeft de oude versie een hogere score dan de nieuwe.
Het is bij de nieuwe locatieserver inderdaad niet toegestaan om query parameters op te geven die niet in de OpenAPI specificatie staan. Dat kon bij de oude locatieserver wel, maar deze waren niet nodig.
De scoreberekening tussen de oude en de nieuwe locatieserver is inderdaad anders doordat de onderliggende componenten zijn geüpgraded. Dit zou voor de volgorde van de resultaten in de meeste gevallen niet uit moeten maken. Het kan wel zijn dat voor hele specifieke gevallen dit invloed heeft.
Bedankt voor je antwoord. Maakt het weer een stukje eenvoudiger 
De velden in de responses zijn hetzelfde zag ik. Zijn daar nog aanpassingen gedaan voor het type xml ?
In principe zijn alle velden hetzelfde. Met de parameter fl=* krijg je alle velden terug. Dan zie je dat naast het veld shard het veld shards is toegevoegd. Dit heeft met backwards compatibility te maken.
Goed dat de XML output weer terug is. Hierop heb ik ook de PDOK geocodeer spreadsheet gebaseerd. Na een omhangen van de url’s blijkt Excel de output niet als XML te kunnen openen. De output lijkt hetzelfde, maar Excel geeft voor mij onduidelijke reden een foutmelding (#waarde / #value).
Welke Excel of PDOK held kan hier de gouden tip geven, zodat de spreadsheet weer tot leven kan komen.
Voor wie dit wil reproduceren in Excel (desktop):
Deze functies doet het wel:
=WEBSERVICE(HYPERLINK(“https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?wt=xml&rows=1”))
Deze functie doet het niet meer:
=WEBSERVICE(HYPERLINK(“https://api.pdok.nl/bzk/locatieserver/search/v3_1/free?wt=xml&rows=1”))
Both service gives the same XML response.
Who can help me to solve this problem?
<?xml version="1.0" encoding="UTF-8"?>
<response>
<result name="response" numFound="10412976" start="0" maxScore="7.629905" numFoundExact="true">
<doc>
<str name="bron">Bestuurlijke Grenzen</str>
<str name="identificatie">0518</str>
<str name="provinciecode">PV28</str>
<str name="type">gemeente</str>
<str name="provincienaam">Zuid-Holland</str>
<str name="centroide_ll">POINT(4.29300241 52.07207297)</str>
<str name="gemeentecode">0518</str>
<str name="weergavenaam">Gemeente 's-Gravenhage</str>
<str name="provincieafkorting">ZH</str>
<str name="centroide_rd">POINT(79981.846 454319.602)</str>
<str name="id">gem-339aeade1bbb0005ba845b14d29d2c15</str>
<str name="gemeentenaam">'s-Gravenhage</str>
<float name="score">7.629905</float></doc>
</result>
</response>
Als je de knop ‘Vooraf opgemaakte tekst’ gebruikt, dan word je xml ook leesbaar op het forum. Nu word een deel van de xml-tags als html geinterpreteerd, en dan blijft er niet veel over…
Verder ben ik enigszins verbaasd dat 1 van beide urls het wel zou doen. Beide hebben namelijk een extra dubbele punt na de dubbele forward slash, en beide geven bij mij een foutmelding als ik ze rechtstreeks kopieer. Maar misschien ligt dat ook aan het ‘vooraf opgemaakte tekst’ dingetje.
Overigens zie ik wel een verschil tussen beide xmls: de nieuwe heeft een extra attribuut in de result-tag (numFoundExact), misschien dat Excel daar over struikelt?
<result name="response" numFound="10413185" start="0" maxScore="7.6299176" numFoundExact="true">
Dank voor je antwoord. Er zat een typefoute in de url.
Er zitten inderdaad kleine verschillen in de XML output, maar die zouden dit probleem niet kunnen veroorzaken denk ik.
De verschillen die ik constateer zijn:
oud: <result name="response" numFound="1" start="0" maxScore="17.284231">
Nieuw: <result name="response" numFound="1" start="0" maxScore="7.8937407" numFoundExact="true">
oud: <str name="centroide_ll">POINT(5.37203312 52.15247416)</str>
nieuw: <str name="centroide_ll">POINT(5.37203305 52.15247416)</str>
oud: <float name="score">17.284231</float></doc>
nieuw: <float name="score">7.8937407</float></doc>
Het enige waar Exel over zou kunnen struikelen gaf ik al aan, dat is het extra attribuut. Waardes zou ie niet over mogen struikelen. Dus dan word de volgende vraag:
Wat bedoel je hier precies mee? Geeft ie een foutmelding, of wat? “Doet het niet meer” is een beetje vaag… (en ik heb geen Excel, dus kan dit ook niet naspelen…).
De foutmeling staat in eerste berichtje.
In de cel waarin de genoemde formule staat komt de foutmelding #waarde of #value te staan ipv van de gevraagde XML.
Bedankt, het werkt nu goed!