Bestemmingsvlakken met link naar text opvragen voor adres met geofilter

Datasets Ruimtelijke Plannen
#1

Ik probeer gericht bestemmingsplannen voor een adres op te vragen. En dan alleen het bestemmingsvlak van dit plan wat op deze locatie van toepassing is. Het doel is uiteindelijk om de text uit het bestemmingsplan voor een gegeven locatie in python in te kunnen laden, en dan dus alleen voor de bestemmingsvlakken die van toepassing zijn.

Wat ik nu probeer te doen:

  1. adres - > coordinaten
  2. perceel opvragen van deze coordinaten: service.pdok.nl/kadaster/kadastralekaart/wfs/v5_0
  3. Bestemmingplannen zoeken die binnen de gegeven geometrie vallen.
  4. Bestemmingsvlakken binnen elk gevonden plan zoeken die binnen de gegeven geometrie vallen.
  5. Uit de response de urls naar de tekst halen.

Het probleem is dat filteren met het type ‘Point’ werkt, maar type ‘Polygon’ niet. Bij de laatste krijg ik een 500 error terug.

Voorbeeld van zo’n request:
response = requests.post(
url=“https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/”
f"api/opvragen/v4/plannen/{plan_id}/bestemmingsvlakken/_zoek",
headers={
‘content-crs’: RDS,
‘accept-crs’: RDS,
‘x-api-key’: R_PLANNEN_API_KEY,
},
json={
“_geo”: {
“intersects”: {
“type”: “Polygon”,
“coordinates”: [c for c in polygon.exterior.coords]
}
},
}
)
content = response.json()
print(json.dumps(content, indent=2))

Dit geeft:

{
“title”: “Internal Server Error”,
“status”: 500,
“detail”: “An internal server error has occurred!”
}

Kan iemand mij:

  1. vertellen of dit de juiste manier is om dit te bereiken, het lijken nogal veel requests voor dit doel
    en
  2. of de 500 error aan mijn request ligt of de server?
#2

Het antwoord op je tweede vraag is dat dit een fout aan de server zijde is. De kans is vrij groot dat de server niet om kan gaan met het request dat je stuurt.

Om deze fout te kunnen reproduceren, zou het handig zijn als je aan kan geven wat de waarden van de requests headers (API key natuurlijk niet hier delen, die hebben we niet nodig) en de inhoud van de requestbody zijn. Dat is niet af te leiden uit je code snippet.

#3

url=‘https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen/NL.IMRO.0363.K1005BPSTD-VG01/bestemmingsvlakken/_zoek’

headers={‘content-crs’: ‘epsg:28992’, ‘accept-crs’: ‘epsg:28992’, ‘x-api-key’: ‘’}

json={’_geo’: {‘intersects’: {‘type’: ‘Polygon’, ‘coordinates’: [[120242.987, 485386.345], [120234.078, 485382.542], [120239.908, 485368.91], [120248.84, 485372.718], [120242.987, 485386.345]]}}}

#4

Een collega heeft het uitgezocht. Er zijn twee problemen:

  1. Er ontbreekt een set blokhaken in de coordinates van de geojson.
  2. De geojson is dus invalide, en had een 400 respons moeten opleveren ipv de 500 die je nu krijgt. Hiervoor is een ticket aangemaakt.
1 like
#5

Aha de blokhaken lossen het inderdaad op. Bedankt voor de snelle reactie!

1 like
#6

Zou een 422 - Unprocessable Content in dit geval niet beter zijn dan een 400 - Bad Request?
Tenslotte is het request goed, alleen de payload is niet correct
 Goed lezend sluit 422 ook niet helemaal aan, maar de korte beschrijving sluit (voor mij althans) beter aan bij het probleem in dit voorbeeld


#7

Dat ligt er aan hoe je de uitleg van de 422 interpreteert:

The HyperText Transfer Protocol (HTTP) 422 Unprocessable Content response status code indicates that the server understands the content type of the request entity, and the syntax of the request entity is correct, but it was unable to process the contained instructions.

the syntax of the request entity is correct 
 en wat valt er dan onder “syntax”?

DSO API strategie zegt er het volgende over:

422: Gebruikt voor een verzoek (body) dat correct is maar dat de server niet kan verwerken.

Is het dan de opbouw van de requestbody (wel correct, want alle keys zitten er in), of ook de waarden (niet correct, want invalide geoJSON) waar je de respons code op baseert?

Zoals je leest, kan ik beide respons codes beargumenteren. Als iemand hier met goede onderbouwing een keuze in kan maken, kunnen we die volgen. Anders wordt het voor dit geval toch een 400

1 like
#8

:grin: dat is precies wat ik bedoelde met “Goed lezend sluit 422 ook niet helemaal aan”.

Als je alleen naar de korte omschrijving kijkt (“Unprocessable Content”), vind ik dat beter passen bij dit specifieke voorbeeld. Als je naar de uitgebreidere omschrijving kijkt, dan klopt het weer niet, want persoonlijk vind ik ook dat die twee (dus de korte beschrijving en de lange uiitleg) niet bij elkaar passen voor 422, semantisch gezien.

Dus laat het maar bij 400 ( hoewel 418 ook nog wel toepasselijk zou kunnen zijn, en in ieder geval meer humor heeft :wink: ).
Dat debat hoeven we hier niet echt te herhalen denk ik, het viel me alleen op dat er voor een geval als dit ( waarbij het request op zich correct is, en dus een 200 zou moeten geven, maar de payload niet correct is, en dus een 500 veroorzaakt tenzij die afgevangen word - je ziet in dergelijke gevallen ook nog wel eens dat je wel een 200 terug krijgt, maar met een error message als payload - zou ook nog een optie kunnen zijn
 ) eigenlijk geen goede http-code is.

#9

Het gebruik van 418 (“teapot”) kan in de context van de Omgevingswet | het DSO ook wel tot verwarring leiden