Zoeken op coordinaten url

Datasets Ruimtelijke Plannen
#5

Bedankt Robin! De POST Request via Excel is gelukt.

Ik heb gebruik gemaakt van de Point coƶrdinaten + intersects. Ook is het gelukt om het onherroepelijk bestemmingsplan te vinden van het specifieke object, inclusief het ID. Op basis van dit ID wil ik graag de fungerende Enkelbestemming zoeken via:

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

Dit levert mij echter alle bestemmingsvlakken binnen het bestemmingsplan op, ondanks dat in de request dezelfde coƶrdinaten weer worden gebruikt via een POST. Hoe kom ik er nu achter welke Enkelbestemming voor de coƶrdinaten van toepassing is?

Als voorbeeld gebruik ik
Locatie: Paul Krugerlaan 2, 2571HK 's-Gravenhage ā†’ enkelbestemming Gemengd-2 volgens ruimtelijke plannen viewer.
Coordinaten: 4.28537, 52.07069

Tnx!

#6

Het POST endpoint /plannen/{id}/bestemmingsvlakken ondersteunt het zoeken op geometrie niet.

Voor het zoeken naar planobjecten mbv een geometrie is momenteel alleen het /_zoek endpoint beschikbaar (let op: niet /plannen/_zoek !). Daar kan je een request doen met een planId parameter. Voor jouw specifieke geval zou het dit zijn:

https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/_zoek?planId=NL.IMRO.0518.BP0156ETransvaal-50VA

Waar je de volgende respons krijgt met de gezochte enkelbestemming:

{
  "_embedded": {
    "resultaten": [
      {
        "_links": {
          "self": {
            "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/NL.IMRO.0518.BP0156ETransvaal-50VA/bouwvlakken/NL.IMRO.0518.BP121950608-00"
          }
        },
        "planId": "NL.IMRO.0518.BP0156ETransvaal-50VA",
        "id": "NL.IMRO.0518.BP121950608-00",
        "type": "bouwvlak"
      },
      {
        "_links": {
          "self": {
            "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/NL.IMRO.0518.BP0156ETransvaal-50VA/maatvoeringen/NL.IMRO.0518.MP121974883-00"
          }
        },
        "planId": "NL.IMRO.0518.BP0156ETransvaal-50VA",
        "id": "NL.IMRO.0518.MP121974883-00",
        "type": "maatvoering"
      },
      {
        "_links": {
          "self": {
            "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/plannen/NL.IMRO.0518.BP0156ETransvaal-50VA/bestemmingsvlakken/NL.IMRO.0518.EP121876942-00"
          }
        },
        "planId": "NL.IMRO.0518.BP0156ETransvaal-50VA",
        "id": "NL.IMRO.0518.EP121876942-00",
        "type": "enkelbestemming"
      }
    ]
  },
  "_links": {
    "next": {
      "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/_zoek?planId=NL.IMRO.0518.BP0156ETransvaal-50VA&page=2"
    },
    "prev": {
      "href": null
    },
    "self": {
      "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/_zoek?planId=NL.IMRO.0518.BP0156ETransvaal-50VA"
    }
  }
}

Zou misschien handig zijn om filteren op type te ondersteunen op dit endpoint. Zal de wijziging daarvoor op ons backlog zetten.

#7

Heb dit vandaag even tussen het andere werk door opgepakt. Er is nu een planobjectType parameter beschikbaar op het /_zoek endpoint waarmee je de resultaten kan filteren op een specifiek planobject type.

Voor je enkelbestemming doe je dan het volgende request:
https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v3/_zoek?planId=NL.IMRO.0518.BP0156ETransvaal-50VA&planobjectType=enkelbestemming

Opvragen Enkelbestemming bestemmingsplan coordinaatklikker
#8

Geweldig! Het is gelukt.

Bedankt voor je hulp :slight_smile:

1 like
#9

Hallo Robin,

Heb sinds november 2020 niet meer de Ruimtelijke Plannen geraadpleegd. Maar ik zie nu dat mijn searches bij planobjectType parameter op enkelbestemming, dubbelbestemming of beiden een leeg resultaat [ ] terug krijgen. Dat was voorheen niet zo. Search software is ongewijzigd.

Kan jij hier even naar kijken? Alvast bedankt.

#10

Een probleem met het type veld in de respons heb ik wel vrij snel kunnen vinden. Aangezien het planobjectType filter op dezelfde data probeert te filteren, zal er inderdaad een bugje in zitten.

We gaan er naar kijken.

#11

Hallo Robin,

Is het lastiger dan gedacht? Zie het fenomeen nog steeds optreden.

John

#12

Ja, het was lastiger dan gedacht. Het hele endpoint bleek niet naar behoren te functioneren na de wisseling van het backend van begin dit jaar (waar niemand iets van had horen te merken ā€¦ :sweat:). En er kwamen andere bugs tussendoor die hogere prioriteit hadden.

De oplossing van het probleem is zojuist uitgerold. planId en planobjectType filters en paginering werken weer.

De lege waarden voor type die je nog tegen zou kunnen komen, zijn een bekend probleem waar we nog mee bezig zijn.

Mocht je nog merken dat er iets anders niet naar verwachting werkt, horen we dat graag.

#13

Ja, samengestelde systemen met mogelijk meerdere produktie teams kunnen altijd voor verrassingen zorgen.

Is het een idee om samengestelde queries uit BRK, BAG en Ruimtelijke Plannen in een soort QA/QC acceptatie mee te nemen?

#14

Dat heeft niet heel veel zin. In principe hebben die APIs niks met elkaar te maken behalve dat ze gebruik maken van dezelfde database en backends. Testen voor de IHR API zijn nu uitgebreid om dit probleem een volgende keer eerder op te merken.

#15

Het probleem met de lege type waarden is ook opgelost, dus het hele endpoint zou weer naar behoren moeten werken.

#16

Hi Robin,

Even een vraag mbt een reactie welke hierboven hebt gegeven.

Ik maak gebruik van https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen/_zoek?regelBinding=burgerbindend&regelStatus=geldend om de bestemmingsplannen voor een point op te vragen. Nu komt het voor dat niet bij elke locatie (point) een bestemmingsplan wordt teruggegeven, terwijl deze er wel moet zijn. Op een andere locatie binnen hetzelfde bestemmingsplan komt deze namelijk wel naarvoren.

Voorbeeld:
plandId: NL.IMRO.0361.BP00100-0305

point 4.771854579475986, 52.63078115837533 = geen bestemmingsplan
point 4.777509570667463, 52.63738433343166 = wel bestemmingsplan

Terwijl beide locaties binnen hetzelfde bestemmingsplan vallen.

Is dit een bug of doe ik iets verkeerd?

Dank!

#17

Ik kan dit reproduceren en we gaan kijken wat de oorzaak is. Wordt vervolgd!

#18

https://xkcd.com/2170/

8 likes
#19

Los van de vraag of de nauwkeurigheid wel realistisch is, feitelijk waar Jochem op doelt, hebben we de oorzaak achterhaald. Deze zit in het platform waarvan wij gebruik maken. Op dit moment zitten we echter middenin een migratie naar een nieuw platform. Daarmee zal dit automatisch verholpen moeten zijn. Deze migratie zal begin januari afgerond zijn.

1 like
#20

Ja hoor, daar is de coƶrdinatenpolitie weer! :wink:

Leuke strip, en helemaal waar natuurlijk. Maar we werken hier met digitale systemen, die gewoon veel decimalen opslaan en weergeven. En als je die copy-paste komen ze in je bericht te staan. Deze handmatig gaan verwijderen (en uitzoeken hoeveel je er wel mag laten staan) is extra werk en zonde van de tijd. En er is niemand die denkt dat je buiten met een microscoop hebt staan landmeten en echt super precies wil weten waar een bestemmingsplan ligt. Dus, ā€œplease stopā€!

1 like
#21

Haha :slight_smile: je hebt ongetwijfeld gelijk maar ik ben zelf toch wel van mening dat het niet vaak genoeg herhaald kan worden wat decimalen voor werkelijke waarde hebben. Zie het bij een aantal van onze klanten ook terug dat ze lat en lon beschouwen als een soort x,y en niet weten of 4 decimalen wel/niet genoeg is, 6 lijkt al teveel te zijn in hun ogen. Dit in tegenstelling tot RD, waar ze in AutoCAD het aantal units op minimaal 4 zetten en zonder blikken of blozen maten ophangen aan een kadastrale grens of leiding uit de Klic.

Al meerdere keren gehad dat landmeetkundige bureaus grenzen rechtstreeks uit de DKK uitzetten bij grensgeschillen want je kunt coƶrdinaten toch tot op de mm uit die kaart halen.

Dus wat mij betreft, kom maar op met die plaatjes :stuck_out_tongue:

4 likes
#22

Zelf noem ik mijn werk bijdragen aan de geodetische infrastructuur, maar coƶrdinatenpolitie vind ik een mooie geuzennaam. :nerd_face:

Bij onderlinge communicatie tussen digitale systemen hoeft het inderdaad niet slecht te zijn om gewoon alle 15 decimalen door te geven. Tussentijds afronden kan namelijk ongewenste effecten hebben (zoals we pas nog gezien hebben in een ander draadje hier). Als het maar een bewuste keuze is. Ik draag graag bij aan bewustwording door hier onvermoeibaar bepaalde dingen te herhalen, maar als ik de irritatiegrens bereik dan hoor ik dat graag.

3 likes
#23

Geen irritatiegrens bij mij bereikt hoor! Maar vond het tijd om ook de andere kant een keer te benoemen. Ter voorkoming dat mensen die een paar decimalen teveel plakken zich heel dom gaan voelen.

#24

Ik heb het meegemaakt (al lang geleden overigens) dat een architekt heel boos bij ons kwam omdat op de bouwplaats bleek dat zijn bouwwerk niet paste tussen de bestaande bouwwerken. Bleek dat hij was uitgegaan van de terug gezette dakranden van de toenmalige GBKN, zonder rekening te houden met de nauwkeurigheid van die gegevens ā€œwant het staat toch op de millimeter in jullie bestand!ā€. helaas voor hem wezen wij vervolgens op de disclaimer rechts onderaan ā€œmaten in het werk te controlerenā€, dus dat was einde verhaal wat ons betrof - maar dat bouwwerk heeft wel wat vertraging opgelopenā€¦

En een tweede voorbeeld: ā€œals ik jullie bestand in Google Earth zet, klopt er niks van de wegen! Die liggen er overaal naast!ā€ā€¦ tsja. wat vertrouw je meer: een door landmeters tachymetrisch ingemeten bestand, of een applicatie van een bedrijf dat wereldwijd werkt en dus compromissen moet sluitenā€¦

Dus ik meld me aan als vrijwilliger bij de coƶrdinatenpolitieā€¦ :wink::laughing:

5 likes