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:
adres - > coordinaten
perceel opvragen van deze coordinaten: service.pdok.nl/kadaster/kadastralekaart/wfs/v5_0
Bestemmingplannen zoeken die binnen de gegeven geometrie vallen.
Bestemmingsvlakken binnen elk gevonden plan zoeken die binnen de gegeven geometrie vallen.
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:
vertellen of dit de juiste manier is om dit te bereiken, het lijken nogal veel requests voor dit doel
en
of de 500 error aan mijn request ligt of de server?
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.
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âŠ
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
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 ).
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.
Voor een uitbereiding van IFC Site maker
wil ik eigenlijk hetzelfde doen als Tim1 hierboven. Maar dan vanaf stap 3.
Ik heb dus een gegeven geometrie/coordinaten (bbx).
Graag zou ik opvragen welke bestemmingsplannen hierop geldend zijn. In andere plannen ben ik vooralsnog niet geĂŻnteresseerd.
Met de namen/codes van die plannen zal ik dan vervolgens nieuwe aanvragen doen om de bestemmingsvlakken/bouwvlakke etc. boven tafel te krijgen.
Is er iemand die mij een voorbeeldje kan geven van een request die daar toe zou leiden?
dank voor je snelle antwoord allereerst. Ik heb daar inderdaad vooraf naar gekeken. Wel moet ik bekennen dat ik de âexpandâ parameter helemaal over het hoofd heb gezien. Dank dus wederom.
Wel heb ik nog steeds vraagtekens over hoe ik dan een bbox of andere vorm als input meegeef. Bij de verklaring staat namelijk:
Array of strings Items Enum: âgeometrieâ âbboxâ
Ik geloof dus dat ik daar als input maar keuze heb uit twee specifieke woorden, terwijl ik eerder de input van getallen (x en y van ruimtelijke punten) zou verwachten.
Specifieker dus: hoe voer ik mijn bbox in, en doe ik dat inderdaad bij âexpandâ?
Je moet een POST doen, met de volgende payload:
(Overigens houd hier mijn technische kennis wel zoân beetje op, maar er zijn hier genoeg anderen die je verder kunnen helpenâŠ)
Volgensmij kun je gewoon mijn voorbeeld overnemen en in plaats van Polygon, Point gebruiken. En natuurlijk de endpoint voor bestemmingsplannen gebruiken ipv bestemmingsvlakken.
Wederom dank hiervoor. Ik ben bij de GET opdrachten gaan kijken, omdat ik iets wil opvragen, niet wil achter laten. Echter, je methode werkte. Ik krijg nu allerlei plannen terug voor ergens in Enschede uit mijn hoofd.
Toch: als ik vervolgens -van welk plan ik dan ook vind met deze methode- met de methoden daaronder bestemmingsvlakken of bouwvlakken probeer op te vragen, krijg ik steeds geldige (200) maar lege resultaten. Ik had natuurlijk op meer gehoopt.
Omdat daar in de voorbeelden wordt gewerkt met {planId} , in plaats van een daadwerkelijk planID, kan ik ook deze niet nabootsen als test: GET /plannen/{planId}/bestemmingsvlakken en POST /plannen/{planId}/bestemmingsvlakken en POST /plannen/{planId}/bestemmingsvlakken/_zoek
Is er iemand die mij verder kan helpen? Kort gezegd wil ik graag bestemmingsvlakken en bouwvlakken opvragen die voor bepaalde coordinaten / bbox geldig zijn.
Dank voor je aanhoudende hulp. Inmiddels heb ik -inclusief de âexpandâ: âgeometrieâ parameter- de boel aan de praat gekregen. Het was me even zoeken, maar ik krijg nu resultaten waar ik iets mee kan. Mijn dank is groot.
dat is precies wat ik bedoelde met âGoed lezend sluit 422 ook niet helemaal aanâ.
).