(NIEUW) Reverse Geocoder API beschikbaar om te testen (PDOK locatieserver)

Toepassingen LocatieServer
#1

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.

4 likes
Geolocatie naar postcode
#2

Even wat getest, eerste indruk is dat dit goed bruikbaar is.

Wel zit er iets verkeerd bij het reverse geocoden op gemeente (ontbrekende index?).

Een request als de volgende duurt ruim een minuut:
http://test.geodata.nationaalgeoregister.nl/locatieserver/revgeo?X=86427&Y=446166&type=gemeente&rows=1&fl=*

#3

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.

#4

@jeroenk

Dit was inderdaad een bug in de reverse geocoder, dit is nu gefixt.

#5

@rboeters

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.

#6

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.

#7

@rboeters

De performance problemen zijn nu opgelost op de test versie
Het heeft wat lang geduurd vanwege prioriteiten en vakanties

1 like
#8

Beste PDOC,

Er zItten afstanden in de resultaatset van de reverse service maar waarom geen coördinaten?

Verder is het opgeven van ?type=x&type=y lastig als je leaflet gebruikt. Wellicht is het handiger om iets te doen als &types=x,y,z.

Verder is het een interessante aanvulling.

Groet, Rob

#9

@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.

#10

@robbedoes je kunt ook met filters werken en dan krijg je ook de geometrie terug:

http://geodata.nationaalgeoregister.nl/locatieserver/revgeo?X=86427&Y=446166&type=gemeente&rows=1&fl=*

#11

Goed dat er nu een reverse geocoder is. En ziet er goed uit.

Is er ook al ergens een JS response parser beschikbaar?

#12

Dag @Jeroen,

Dank je, ik zal die filters eens bestuderen.

Groet, Rob

#13

Erg gaaf deze revgeo. Toepasbaarheid is giga. Dank!
Marcel van Mackelenbergh

1 like