Ophalen van perceel bestemming volgens bestemmingsplan

Datasets Ruimtelijke Plannen
#21

Denk dat ik de bestemmingsfuncties van de bestemmingsvlakken alleen informatief gebruik en naast de gebruiksdoelen van de verblijfsobjecten in de BAG zet. BAG geeft als gebruiksfunctie industriefunctie waar ook agrarisch onder valt.

Als ik bestemming en gebruik informatief naast elkaar zet dan moet de eindgebruiker dat zelf interpreteren. Gezien de stapeling en het feit dat alleen onderliggende documenten rechtsgeldigheid geven lijkt mij eindgebruiker interpretatie de beste weg. En dus niet automatische selectie door een search algoritme.

#22

Enkelbestemming Wonen hoort bij een ander perceel BMN01-K-85.

#23

Ook dat klopt John. Dat is het gevolg van mijn eerdere opmerking

#24

Wat is het ID van dit bestemmingsvlak? Ik kan dit niet vinden met de eerder genoemde zoekgeometrie.

Lijkt er wel op dat de RP Viewer meer bestemmingsvlakken toont bij het klikken op een punt dan dat er werkelijk op dat punt liggen.

#25

https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/NL.IMRO.02130000BPBG700000VA01-/bestemmingsvlakken/EP411424

#26

Sorry, dat was de waterhuishouding.

Nu de agrarische bestemming 

https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/NL.IMRO.02130000BPBG700000VA01-/bestemmingsvlakken/EP459364

#27

Robin en Merijn,

Volgens mij zijn jullie thuis in de ruimtelijke plannen API. Heb een functioneel en een performance probleem met betrekking tot onderstaande query 


https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen//%{planId}/bestemmingsvlakken/%{vlakId}

en de resultaten van die query twee maal identiek uitgevoerd en over alle bestemmingsplannen en enkelbestemmingenen geaggregeerd 


{“bestemmingsfuncties”:[{“bestemmingsfunctie”:“waterhuishouding”,“functieniveau”:“hoofdfunctie”},{“bestemmingsfunctie”:“werken; niet zijnde dienstverlening; agrarische bedrijvigheid; grondgebonden”,“functieniveau”:“hoofdfunctie”}],“planId”:[“NL.IMRO.0213.BPBG700010-va01”,“NL.IMRO.0213.BPBREEPPARK10000-VA01”,“NL.IMRO.02130000BPBG700000VA01-”],“vlakId”:[“EP411424”,“EP459364”]}

en

{“bestemmingsfuncties”:[{“bestemmingsfunctie”:“Bestemmingsfunctie”,“functieniveau”:“hoofdfunctie”},{“bestemmingsfunctie”:“werken; niet zijnde dienstverlening; agrarische bedrijvigheid; grondgebonden”,“functieniveau”:“hoofdfunctie”}],“planId”:[“NL.IMRO.0213.BPBG700010-va01”,“NL.IMRO.0213.BPBREEPPARK10000-VA01”,“NL.IMRO.02130000BPBG700000VA01-”],“vlakId”:[“EP411424”,“EP459364”]}

In het tweede resultaat wordt de “Bestemmingsfunctie” van EP411424 ten onjuiste niet geĂ«xpandeerd tot “waterhuishouding”. Eerder heb ik deze expansie soortgelijk ook niet zien plaats vinden voor EP459364.

Daarnaast duren de queries ontzettend lang. Het lijkt of alle bestemmingsvlakken van het bestemmingsplan worden opgehaald en daarna pas gefilterd worden op vlakId. Staan er datbase indexen op zowel “planId” als “vlakId”? Waarom moet dit zo lang duren?

#28

Over jouw 2 varianten en jouw bevinding geeft Robin zo meteen nog een reactie.

Wat betreft de aangetroffen plannen op de gebruikte locatie;
NL.IMRO.02130000BPBG700000VA01- (IMRO2006)
NL.IMRO.0213.BPBG700010-va01 (parapluplan, ook ontwerp aanwezig)
NL.IMRO.0213.BPBREEPPARK10000-VA01 (parapluplan, ook ontwerp aanwezig)
NL.IMRO.0213.BPBREEPARCH20000-on01 (parapluplan, alleen ontwerp aanwezig, plan in procedure)
Voor geldende regelgeving zijn er dus 3 plannen welke in aanmerking komen;
NL.IMRO.02130000BPBG700000VA01-
NL.IMRO.0213.BPBG700010-va01
NL.IMRO.0213.BPBREEPPARK10000-VA01
Verder hanteert de viewer van Ruimtelijkeplannen.nl een kleine tolerantie bij de bevraging op coördinaat. Deze is noodzakelijk om punten en lijnen te kunnen selecteren in de viewer.

Jouw opmerking over de performance kan ik (helaas) bevestigen. Deze is niet altijd wat gebruikers zouden mogen verwachten. Dit heeft onze aandacht en we zijn bezig om verbeteringen in te plannen.

#29

Hierdoor krijg je dus meer bestemmingsvlakken in de RP viewer dan in de RP REST API als je zoekt op een punt.

Het probleem met de inconsistente bestemmingsfunctie in de respons heb ik zojuist verholpen. Bestemmingsfunctie had nooit in het antwoord mogen zitten.

#30

Bedankt voor jullie reactie!

De bestemmingsplannen heb ik dus correct te pakken. Maar, als ik op enkelbestemmingen selecteer kan ik dan beter het geografisch centrum kiezen dan een willekeurig perceel polygoon punt? Zou ik bij toeval een polygoon punt kunnen selecteren wat samenvalt met een belendend perceel zodat ik de enkelbestemming van dat belendend perceel per ongeluk ook mee krijg?

Gebruik nu ook het geografisch centrum (zwaartepunt) ook om panden binnen een perceel te selecteren. Dat werkt in mijn geval goed. Voor extreme pand polygonen met geen omliggende perceelruimte daar omheen zou het theoretisch slecht uit kunnen pakken. In de praktijk voor onze applicatie geen probleem. Levert een false negative wat niet erg is. False positives zijn in ons geval vervelender.

Ben ik wat betreft enkelbestemmingen beter uit met het geografisch centrum van het perceel?

#31

Ik neem aan dat je zoekt met een intersects operator in de requestbody.

Zoeken met een intersects met een punt op de grens van een bestemmingsvlak zal als resultaat ook een aangrenzend bestemmingsvlak geven dat de grens deelt (als zo’n vlak bestaat). Als dat niet wenselijk is, zou je inderdaad beter met een punt midden in het vlak kunnen zoeken.

Zoeken met een contains operator is voor punten op de grens geen optie, want een punt op de grens van een polygon wordt met contains niet gezien als een punt binnen de polygon.

#32

OK. Ga er mee experimenteren.

Waterhuishouding komt nu goed door. Dat is wel prettig met deze warmte :wink:

1 like
#33

Kan je nog iets melden over het zoekproces? Staat er een gecombineerde index op bestemmingsplan ID en bestemmingsvlak ID? Of, is dit iets wat devops regelt en hebben jullie daar geen zicht op? Of misschien, is die gecombineerde index ruimte gewoonweg te groot?

Het lijkt dat alle bestemmingsplan en bestemmingsvlak objecten worden opgehaald die samenvallen met de opgeven _geo parameter. Klopt dat?

#34

De data achter de IHR API zit niet in een reguliere relationele database. Het zetten van extra indices is hierdoor niet mogelijk.

Zoals Merijn al aan heeft gegeven, zijn we ons bewust van de huidige tegenvallende performance. Maar het zetten van extra indices is in dit geval niet de oplossing.

Ja, met de _geo in de requestbody filter je op plannen/planobjecten met een geometrie met de gekozen relatie (intersects, contains, within) tov de zoekgeometrie

#35

Bedankt voor de uitleg.

Het is met name de call met _geo en planId die lang duurt 


STREAM QUERY FETCH PAGE 
: {{1, 1},
“https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/_zoek”,
%{
“_geo” => %{
“intersects” => %{
“coordinates” => [6.1221575086543565, 52.147980018133396],
“type” => “Point”
}
}
},
[ headers ],
[
{:page, 1},
{“planobjectType”, “enkelbestemming,functieaanduiding”},
{“planId”, “NL.IMRO.02130000BPBG700000VA01-”}
]}

Mijn vermoeden is dat hier eerst het _geo criterium toegepast wordt en dat dat resultaat op planId gefilterd wordt. Dat zou mogelijk de wachttijd verklaren.

De gecombineerde calls zonder _geo maar met planId en vlakId gaat wel snel 


“https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/NL.IMRO.02130000BPBG700000VA01-/bestemmingsvlakken/EP459364”

#36

Er is zojuist een nieuwe versie van de API in productie gezet met een kleine configuratie wijziging. Deze wijziging zou er voor moeten zorgen dat het /_zoek endpoint, vooral bij gebruik van een planId parameter, vele malen sneller is.

#37

Query van BRK v1 Perceel BMN01-K-89 met gerelateerde bestemmingsplannen en enkelbestemming bestemmingsvlakken gaat dramatisch terug van 1 min 37 sec (vannacht) naar 12 sec (nu)!

Geweldig! Bedankt!!!

1 like
#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.