Reverse Geocoder API
Vanaf nu is het mogelijk om de nieuwe Reverse Geocoder API (PDOK locatieserver) te testen. Met de Reverse Geocoder API is het mogelijk om door middel van van coördinaten verschillende objecten in een range op te halen. Bijvoorbeeld het ophalen van de adressen of wegen in de buurt (op basis van je locatie). In deze Reverse Geocoder API zijn meerdere databronnen toegevoegd (BAG, NWB Wegen, CBS wijken en Buurten, Kadastrale Kaart en Waterschappen).
We hebben bewust gekozen om deze versie eerst als testversie beschikbaar te stellen om te kunnen anticiperen op feedback. Mogelijk dat er dus nog wijzigingen worden toegepast op de API.
In verband met de zomerperiode willen wij halverwege september eventuele feedback evalueren om daarna de API productierijp te maken en live te zetten.
Interesse en/of vragen?
Documentatie is als bijlage toevoegd: revgeodocumentatie.pdf (84,5 KB) (De definitieve documentatie zal t.z.t. op GitHub wordt gezet).
Vragen of feedback graag als reactie op dit topic. In verband met vakanties kan het zijn dat niet iedereen van PDOK beschikbaar is maar er voor een reactie dus graag geen reacties naar personen maar algemeen richten aan PDOK.
Allereerst wil ik even vermelden dat ik blij ben met de komst van reverse geocoding. Een mooie toevoeging aan het aanbod van de PDOK diensten
Wat mij wel opvalt is dat het erop lijkt dat de keywords lat en lon verwisseld zijn. Als ik de coördinaten van een adres ophaal via een site als https://www.latlong.net/, dan moet ik de verkregen latitude in de query parameter lon zetten, en longitude in de query parameter lat.
Er zit inderdaad momenteel geen index op gemeentes
Hier was voor gekozen, omdat een query met een groot aantal rows anders heel langzaam worden.
Wij gaan kijken of de performance voor een laag aantal rows kunnen verbeteren zonder de performance voor een groot aantal rows te verslechteren.
Het is onwaarschijnlijk dat het aanmaken van een index negatieve impact heeft in bepaalde scenario’s.
Met een groot aantal rows bedoel je denk ik dat bijna alle features van een bepaald type terug worden gegeven. In dat geval zal de query optimizer van de database ervoor kiezen om de index niet te gebruiken maar een full table scan uit te voeren.
@robbedoes je kunt met de ID’s in de response/resultaten vervolgens de lookup service bevragen (met eventueel nog meer informatie over een object). Ik zal het direct teruggeven van geometrie en zoeken op &types=x,y,z. opnemen als wens om te onderzoeken bij een volgende iteratie.