Ophalen van perceel bestemming volgens bestemmingsplan

Datasets Ruimtelijke Plannen
#38

Heb een gecombineerde search op BRK v1, BAG v1 en Ruimtelijke Plannen v3 gedraaid over alle BRK Percelen met {“kadastraleGemeentecode”:"BMN01}.

Als eerste conclusie lijkt de performance nu heel werkbaar.

Via query Q10 (bestemmingsplannen volgens _geo match) ga ik naar Q11 (bij bestemmingsplan horende bestemmingsvlakken) om vervolgens in Q12 de bestemmingsfuncties op te halen. OP Q12 krijg ik onverwachte 404 not founds wat resulteert in een .63 positive ratio. Dat betekent dat ik in 37% van de gevallen onderstaande API call voor een eerder opgehaald planId (Q10) en vlakId (Q11) niet slaagt. Zie hier onder twee willekeurig gekozen gevallen …

Dit is de Q12 API call …
https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/%{planId}/bestemmingsvlakken/%{vlakId}

HTTP 400 ERROR STATUS 404: %{
“error” => “Not Found”,
“message” => “[OpenApi] An Exception occurred [Did not find data for your response.] resulting in [404] reason [No results found.]”,
“path” => “/plannen/NL.IMRO.0213.BPBRHARH110000-va01/bestemmingsvlakken/NL.IMRO.146”,
“requestId” => “27f7941b-3828”,
“status” => 404,
“timestamp” => 1597249415978
}

en als ander voorbeeld …

HTTP 400 ERROR STATUS 404: %{
“error” => “Not Found”,
“message” => “[OpenApi] An Exception occurred [Did not find data for your response.] resulting in [404] reason [No results found.]”,
“path” => “/plannen/NL.IMRO.0213.BPBRKOM100000-va01/bestemmingsvlakken/NL.IMRO.620”,
“requestId” => “3714ca9a-3776”,
“status” => 404,
“timestamp” => 1597249385890
}

Weet iemand wat er speelt? Doe ik iets verkeerd?

#39

NL.IMRO.146 is het ID van een functieaanduiding van plan NL.IMRO.0213.BPBRHARH110000-va01.
NL.IMRO.620 is het ID van een functieaanduiding van plan NL.IMRO.0213.BPBRKOM100000-va01.

Ik vermoed dat Q11 niet is wat je beschrijft. Kan je van Q11 het request inclusief queryparameters en requestbody delen?

Als onderstaande is wat je Q11 noemt, is het planobjectType filter het probleem. Daarmee vraag je zowel enkelbestemmingen als functieaanduidingen op. Functieaanduidingen kan je niet op /plannen/<planId>/bestemmingsvlakken/<id> opvragen, maar op /plannen/<planId>/functieaanduidingen/<id>.

#40

Robin, dat klopt. Is inderdaad Q11. Met in abstractie API Param {"_geo": “%{_geo}”, “planobjectType”: “enkelbestemming,functieaanduiding”}. Dacht destijds dat de functieaanduiding toevoeging een soort expand was zoals je dat op andere plekken tegen komt. Het is sinds kort dat ik de wereld van bestemmingsplannen in duik :slight_smile: Is nog even een zoekplaatje. Zal functieaanduiding weghalen.

De queries zijn genummerd omdat ze bij mij in een flowgraph staan met input/output signatures. Met hashtags kan je dan individuele datapaden per item symbolisch en gevisualiseerd tracen over meerdere queries, filters en collects die gezamenlijk de search samenstellen.

#41

De gecombineerde search met BRK v1 Percelen, BAG v1 Panden/Verblijfsobjecten en Ruimtelijke Plannen v3 begint goed te werken.

In één van mijn testgevallen voor perceel ASD16-T3536 kan ik echter alleen bestemmingsplan NL.IMRO.0363.E1601PBPSTD-VG01 vinden met een lege lijst [] bestemmingsvlakken.

Volgens ruimtelijkeplannen.nl is er een bestemmingsplan NL.IMRO.0363.E1503PBPSTD-VG01 met een bestemmingsvlak met enkelbestemming wonen. De API geeft dit echter niet terug!

Heef iemand een idee wat er fout gaat?

#42

Dit is de API call die ook NL.IMRO.0363.E1503PBPSTD-VG01 zou moeten teruggeven:

STREAM QUERY FETCH PAGE …: {{1, 1},
“https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/_zoek”,
%{
“_geo” => %{
“intersects” => %{
“coordinates” => [
[
[4.858617351, 52.361584775],
[4.858752256, 52.361376304],
[4.858767787, 52.361380049],
[4.858768607, 52.361380251],
[4.858834042, 52.361396028],
[4.858701137, 52.361604284],
[4.858617351, 52.361584775]
]
],
“type” => “Polygon”
}
}
},
[
{“Accept”, “application/hal+json”},
{“Accept-Crs”, “epsg:28992”},
{“X-API-Key”, “440a7fce-89ae-4490-bbac-b45df4ded58d”}
],
[
{:page, 1},
{“regelStatus”, “geldend”},
{“regelBinding”, “burgerbindend”},
{“planType”, “bestemmingsplan”}
]}

#43

Wat is het ID van het bestemmingsvlak dat je verwacht?

Zoeken in de viewer van RP gaat met een zekere tolerantie rond het punt dat je prikt. Dus je zal daar met een punt vlak bij een scheiding tussen meerdere vlakken, meer vinden dan de API.

#44

Het bestemmingsplan is

Oud West 2018
gemeente Amsterdam
bestemmingsplan
geheel in werking (vastgesteld 2019-11-07)

Het bestemmingsvlak is Amsterdam Oud West daar ligt het perceel midden in dat zou toch moeten matchen met een intersect.

Kan in de RP viewer geen vlakId vinden!

#45

NL.IMRO.0363.E1503PBPSTD-VG01 bestaat niet als planId.

NL.IMRO.0363.E1503BPSTD-VG01 wel … Het is lastig helpen als je informatie met typfouten verstrekt :roll_eyes:

#46

De uiteindelijke enkelbestemming wonen die ik verwacht is een bouwblok van plus minus zes percelen waarvan het gezochte perceel aan het uiteinde ligt. Als het eindperceel hier net buiten ligt op de erfgrens dan zou ik get geografisch centrum van perceel of een op perceel gelegen pand kunnen gebruiken.

Maar daar kom ik helemaal niet aan toe. Ik krijg het bestemmingsplan met bestemmingsvlak Oud-West al niet terug laat staan kleinere enkelbestemmingen daar binnen in.

#47

Je krijgt NL.IMRO.0363.E1503BPSTD-VG01 niet terug op /plannen/_zoek omdat de regelStatus van het plan nog op in ontwikkeling staat. Daarmee voldoet het niet aan je regelStatus=geldend filter.

#48

Sorry!

#49

Status is geheel in werking (vastgesteld 2019-11-07)

Uitgebreide status is vastgesteld (plan); geheel in werking (dossier)

Dat is dus nog niet definitief.

Maar het perceel kan toch niet zonder een geldend bestemmingsplan met (in dit geval) een bestemmingsvlak met enkelbestemming wonen zijn?

#50

Het ruimtelijke plannen domein is geen eenvoudige materie. Toevallig heeft Merijn hier deze week nog een stuk over geschreven in een ander topic:

#51

Dit is het voorgaande bestemmingsplan BP_Oud West met id NL.IMRO.03630000B010BPSTD-. Maar die heeft geen PLEKINFO zoals de RP viewer dat noemt.

#52

Ik zou de regelStatus kunnen verruimen al dan niet met een gebruikersoptie. Die status wordt zo wie zo geaggregeerd en teruggemeld aan de eindgebruiker. Aangezien deze info informatief is en niet selectief vanwege de noodzakelijke uiteindelijk juridische interpretatie.

Ik ga wat experimenteren. Kijken hoe het zich gedraagt.

#53

Heb Ruimtelijke Plannen API v3 nu in de search engine geïntegreerd. Werkt goed. Je kan bestemmingsplannen selecteren met “regelStatus” op [“geldend”], [“geldend”, “in ontwikkeling”] of alleen [“in ontwikkeling”]. Dat is handig voor individuele percelen die met een hoge rating uit de search komen.

Wat mij wel opvalt met een paar testgevallen in Amsterdam dat er geen “geldend” maar alleen een “in ontwikkeling” bestemmingsplan is voor ASD16-T-3536 maar. Voor ASD14-R-5050 is de status volgens RP Viewer “onherroepelijk” en daarmee ongetwijfeld “geldend”. Voor ASD16-T-3536 is de status volgens RP Viewer “vastgesteld (plan); geheel in werking (dossier)” en daarmee ongetwijfeld “in ontwikkeling” aangezien het nog niet “onherroepelijk” is.

Toch gebruikt RP Viewer bestemmingsplan NL.IMRO.0363.E1503BPSTD-VG01 met API status “in ontwikkeling” en leidt daar enkelbestemming “wonen” van af. Volgens de API is bestemmingshoofdgroep":[“gemengd”,“tuin”,“verkeer”,“wonen”].

Je zou verwachten dat de RP Viewer zou terugvallen op een eerder versie van het bestemmingsplan.

Voorlopig zet ik in mijn search “regelStatus” op [“geldend”, “in ontwikkeling”].

#54

Hallo John,
Gemeente Amsterdam heeft nagelaten om van meerdere plannen de dossierstatus aan te passen naar ‘geheel onherroepelijk in werking’, dat geldt ook voor NL.IMRO.0363.E1503BPSTD-VG01. Onherroepelijk wordt pas toegevoegd aan het eind van de beroepstermijn en uiteraard ook indien er geen beroep/bezwaar is ingediend welke tot wijzigingen heeft geleid of nog moet gaan leiden.
Wij constateren dat meerdere bronhouders slecht omgaan met de dossierstatussen. Hierover zijn zij ook meerdere malen geïnformeerd, zo ook Gemeente Amsterdam. Wanneer zij dit niet aanpassen dan resulteert dit in een verkeerde regelstatus in het DSO.
Overigens ook in de keuzehulp van Ruimtelijkeplannen.nl kun je dit terug zien. Bij dit plan staat namelijk vermeld dat er nog een gerechtelijke procedure loopt. Die uitspraak is gebaseerd op het feit dat de vaststellingsdatum en bijbehorende dossierstatus al geruime tijd geleden zijn, langer dan de normale termijn voor beroep/bezwaar.

#55

Bedankt Merijn voor het uitzoeken. Geen sinecure om dit soort data met bezwaarmogelijkheden up to date te houden. In het bijzonder met zo veel aanleverende partijen.

Bevraag nu “geldend” en “in ontwikkeling” en gebruik dat informatief en niet selectief. Dat laatste wordt aan de eindgebruiker overgelaten ter eigen interpretatie. Dat is voor ons type gebruik prima.

#56

Een bericht is gesplitst naar een nieuw topic: Plancontouren pdf-plannen

#57

Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.