Foutmelding 'The provided geobody is invalid' bij gebruik van Ruimtelijke Plannen API

Datasets
, ,
#1

Beste API-beheerder,

Ik ben momenteel bezig met het ontwikkelen van een applicatie (voor eigen gebruik) die gebruikmaakt van de Ruimtelijke Plannen API. Tijdens het implementeren loop ik tegen een aantal problemen aan waar ik na uitgebreide pogingen niet uit kom. Ik hoop dat u mij kunt helpen bij het oplossen van deze issues.

Probleembeschrijving:

  • Doel: Het opvragen van bestemmingsplannen en bestemmingsvlakken op basis van een ingevoerd adres.
  • Aanpak:
    1. Het ingevoerde adres wordt gegeocodeerd naar WGS84-coördinaten met behulp van de Nominatim API van OpenStreetMap.
    2. De verkregen WGS84-coördinaten worden geconverteerd naar RD-coördinaten (EPSG:28992) met de proj4 bibliotheek.
    3. Met de RD-coördinaten probeer ik via de Ruimtelijke Plannen API relevante plannen en bestemmingsvlakken op te halen.

Stappen die ik heb ondernomen:

  1. Gebruik van Point geometrie:

    • Ik heb een Point geometrie verstuurd naar het endpoint /plannen/_zoek, met de RD-coördinaten in de volgorde [x, y] en [y, x].
    • Foutmelding ontvangen:
      {
  "status": 400,
  "message": "The provided geobody is invalid"
}

  2. Aanpassen van de coördinatenvolgorde:

    • Ik heb de volgorde van de coördinaten aangepast en beide varianten ([x, y] en [y, x]) geprobeerd.
    • De foutmelding bleef hetzelfde.

  3. Gebruik van Polygon geometrie:

    • Op basis van de documentatie heb ik de geometrie aangepast naar een Polygon, waarbij ik een vierkant rondom het punt heb gemaakt met een offset van 50 meter.
    • Ik heb de coördinatenvolgorde wederom in beide varianten geprobeerd.
    • Foutmelding bleef:
      {
  "status": 400,
  "message": "The provided geobody is invalid"
}

  4. Testen met voorbeeld uit de documentatie:

    • Ik heb een request-body gebruikt die exact overeenkomt met een voorbeeld uit de API-documentatie, inclusief de coördinaten.
    • Zelfs met deze voorbeelddata ontving ik dezelfde foutmelding.

  5. Controle van de API-sleutel:

    • Ik heb mijn API-sleutel gecontroleerd op correctheid en volledigheid, en ervoor gezorgd dat er geen onzichtbare tekens of spaties aanwezig zijn.
    • De API-sleutel lijkt correct te zijn; bij ongeldige sleutels krijg ik een andere foutmelding.

  6. Testen via PowerShell:

    • Ik heb de API-aanroepen ook getest via PowerShell met Invoke-RestMethod om mijn applicatiecode uit te sluiten als oorzaak.
    • Dezelfde foutmeldingen verschenen bij het gebruik van PowerShell.

  7. Aanroepen van het endpoint /plannen/{planId}/bestemmingsvlakken/_zoek:

    • Na het succesvol verkrijgen van een planId heb ik geprobeerd om bestemmingsvlakken op te halen met een Polygon geometrie.
    • Ook hier ontving ik de foutmelding: {"status": 400, "message": "The provided geobody is invalid"}.

Specifieke details:

  • Request-headers die ik gebruik:

    • Content-Type: application/json
    • Accept: application/hal+json
    • X-Api-Key: [mijn geldige API-sleutel]

  • Voorbeeld van een request-body die ik verstuur:

    {
  "crs": {
    "type": "name",
    "properties": {
      "name": "EPSG:28992"
    }
  },
  "geometrie": {
    "type": "Polygon",
    "coordinates": [
      [
        [105368.1394, 431553.1332],
        [105468.1394, 431553.1332],
        [105468.1394, 431653.1332],
        [105368.1394, 431653.1332],
        [105368.1394, 431553.1332]
      ]
    ]
  }
}

  • Coördinaten:

    • De RD-coördinaten liggen binnen het geldige bereik van het Rijksdriehoekstelsel.
    • Ik heb de volgorde van de coördinaten zowel als [x, y] als [y, x] geprobeerd.

  • Headers en request-body komen overeen met de voorbeelden uit de documentatie.

Vragen:

  1. Is er een specifieke vereiste voor de volgorde van coördinaten (bijv. [x, y] vs [y, x]) die ik mogelijk over het hoofd zie?

  2. Zijn er aanvullende parameters of instellingen die nodig zijn om een geldige geometrie te versturen naar de API?

  3. Is het mogelijk dat de API momenteel technische problemen ondervindt, of dat er onderhoud plaatsvindt waardoor deze foutmeldingen optreden?

  4. Kunt u aangeven wat de correcte manier is om een geometrie (zowel Point als Polygon) aan te leveren bij de Ruimtelijke Plannen API?

Ik zou uw hulp enorm waarderen bij het identificeren van de oorzaak van deze foutmeldingen en het vinden van een oplossing. Als er aanvullende informatie nodig is, hoor ik dat graag.

Alvast hartelijk dank voor uw tijd en moeite.

Met vriendelijke groet,

#2

Heb je een linkje naar de documentatie die je hebt gebruikt? Die zou dan verkeerde voorbeelden bevatten.

Als je de OpenAPI specification pakt van de base URL van de API en deze invoert in editor.swagger.io krijg je het volgende als voorbeeld voor een request met geoquery:

{
  "_geo": {
    "contains": {
      "type": "Point",
      "coordinates": [
        5.960233,
        52.179515
      ]
    }
  }
}

Zoals je ziet is de opbouw van de requestbody anders dan wat je tot nu toe hebt geprobeerd. Logischerwijs worden je requests dan ook afgekeurd omdat ze niet aan het schema voldoen.

Om ook nog even op je vragen in te gaan:
1: RD is altijd x, y
2. Requestbody volgens het gevraagde schema en een Content-Crs header
3. Nee
4. Zie uitleg hierboven

Hoop dat je hiermee wel een werkend request voor elkaar krijgt.

#3

Tot voor kort heb ik me nog niet heel veel bezig gehouden met die DSO API’s, maar op aanvraag van mijn organisatie is dat veranderd en ben ik er sinds kort mee aan de slag gegaan.
En ik moet zeggen, wat ik daar tegenkom word ik niet echt vrolijk van. Er word gezegd dat in de POST-zoekrequests GeoJson word verwacht, maar dat is het dus niet. En verschillende endpoints verwachten telkens net iets andere json - dus je moet goed opletten wat je naar welk endpoint POST. Sommige API’s hebben zelf een redelijke swagger-documentatie met samples, bij andere krijg je alleen een json - wat nogal lastig uitvogelen is. En de functionele documentatie is nogal summier, en helpt niet echt bij het uitvogelen hoe je op basis van een locatie of kadastraal perceel het een en ander ophaalt. Het kost me tot dusver enorm veel tijd, en ik ben nog niet echt verder gekomen dan alleen de oude bestemmingsplannen op te halen, als die er zijn op een locatie. Iets anders lukt me nog steeds niet, en moet noodgedwongen op basis van trial-and-error…
Het zou erg fijn zijn als er wat aandacht besteed word aan documentatie en consistentie tussen de verschillende API’s…

#4

Beste,

Hartelijk dank voor de terugkoppeling.

Het is inmiddels gelukt om een werkend request te versturen, wat al een positieve stap is. Echter, ik heb nog steeds moeite met het begrijpen hoe je, conform de opbouw van de API, tot een specifiek hoofdstuk komt en de bijbehorende artikelen uit de regels van het bestemmingsplan kunt ophalen. Is dit überhaupt mogelijk binnen de API? Zo ja, welke GET- of POST-verzoeken moet ik volgen om dit te realiseren?

Ik kan me voorstellen dat ik, nadat ik het juiste ID van het specifieke plan heb achterhaald, vervolgens zou moeten kunnen filteren op bepaalde termen die overeenkomen met de inhoud van de (bouw)regels waarnaar ik op zoek ben.

Een voorbeeld:

Teksten

Zelfstandig leesbare stukken tekst met een titel, die beginnen met een hoofdletter en eindigen met een punt. De tekst is samengesteld uit één of meerdere TekstObjecten, zoals objectgerichte planteksten, regels, toelichtingen, beleids-/besluitdocumenten of bijlagen.

GET

/plannen/{planId}/teksten
Opvragen van teksten die horen bij een specifiek plan.

GET

/plannen/{planId}/teksten/{id}
Opvragen van een specifieke tekst.

POST

/plannen/{planId}/artikelen/_zoek
Zoeken naar artikelen die behoren bij een specifiek plan en van toepassing zijn binnen de meegegeven geometrie.

Wat betreft het laatste request (/plannen/{planId}/artikelen/_zoek), begrijp ik dat de volgende filters beschikbaar zijn voor zoekopdrachten: children, children.children, bestemmingsvlakken, bouwaanduidingen, figuren, functieaanduidingen, gebiedsaanduidingen, lettertekenaanduidingen, maatvoeringen, besluitvlakken.

Klopt dit? Zo ja, dan lijkt het erop dat geen van deze termen direct betrekking heeft op de artikelen binnen de regels van het bestemmingsplan die ik wil opzoeken. Dit maakt het behoorlijk lastig om met deze beperkingen te werken.

Ik hoor graag van u wat de mogelijkheden zijn.

Met vriendelijke groet,

#5

Het kost wat moeite, maar het is zeker mogelijk om de hoofdstukken en artikelen van een bestemmingsplan op te halen via de API.

Bestemmingsplannen zou je kunnen ophalen door op het /plannen of /plannen/_zoek endpoint het planType filter te gebruiken. Bijvoorbeeld: https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen?planType=bestemmingsplan

In de respons vind je bij ieder plan een heeftOnderdelen. Bijvoorbeeld voor het eerste plan uit bovenstaand request:


            {

                "_links": {

                    ... knip ...

                },

                ... knip ...

                "heeftOnderdelen": [

                    {

                        "type": "toelichting",

                        "heeftObjectgerichteTeksten": [

                            {

                                "titel": "Toelichting",

                                "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen/NL.IMRO.1586.BPBUI2041-VG01/teksten/NL.IMRO.PT.toelichting.s232",

                                "type": "toelichting"

                            }

                        ],

                        "externeReferenties": [

                            "https://www.ruimtelijkeplannen.nl/documents/NL.IMRO.1586.BPBUI2041-VG01/t_NL.IMRO.1586.BPBUI2041-VG01.html"

                        ]

                    },

                    {

                        "type": "bijlage bij toelichting",

                        "heeftObjectgerichteTeksten": [

                            {

                                "titel": "Bijlagen bij toelichting",

                                "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen/NL.IMRO.1586.BPBUI2041-VG01/teksten/NL.IMRO.PT.bijlagenBijToelichting.s293",

                                "type": "bijlagen bij toelichting"

                            }

                        ],

                        "externeReferenties": [

                            "https://www.ruimtelijkeplannen.nl/documents/NL.IMRO.1586.BPBUI2041-VG01/b_NL.IMRO.1586.BPBUI2041-VG01_tb.html"

                        ]

                    },

                    {

                        "type": "regels",

                        "heeftObjectgerichteTeksten": [

                            {

                                "titel": "Regels",

                                "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen/NL.IMRO.1586.BPBUI2041-VG01/teksten/NL.IMRO.PT.regels.s1251",

                                "type": "regels"

                            }

                        ],

                        "externeReferenties": [

                            "https://www.ruimtelijkeplannen.nl/documents/NL.IMRO.1586.BPBUI2041-VG01/r_NL.IMRO.1586.BPBUI2041-VG01.html"

                        ]

                    },

                    {

                        "type": "bijlage bij regels",

                        "heeftObjectgerichteTeksten": [

                            {

                                "titel": "Bijlagen bij regels",

                                "href": "https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen/NL.IMRO.1586.BPBUI2041-VG01/teksten/NL.IMRO.PT.bijlagenBijRegels.s1394",

                                "type": "bijlagen bij regels"

                            }

                        ],

                        "externeReferenties": [

                            "https://www.ruimtelijkeplannen.nl/documents/NL.IMRO.1586.BPBUI2041-VG01/b_NL.IMRO.1586.BPBUI2041-VG01_rb.html"

                        ]

                    }

                ],

                "type": "bestemmingsplan",

                ... knip ...

                "id": "NL.IMRO.1586.BPBUI2041-VG01",

                ... knip ...

                "naam": "Buitengebied herziening Gasteveldsdijk 6 Lievelde",

                ... knip ...

            }

Als de teksten objectgericht beschikbaar zijn (aangeleverd door BG als niet-PDF, en automatisch verwerkbaar door Informatiehuis Ruimte), zit hier een object van type: regels in met een heeftObjectgerichteTeksten array. Met de href daarin kom je uit op het eerste Tekst object van de regels van het plan. Je kan je de regels in een plan voorstellen als een boomstructuur: de regels bevatten hoofdstukken, ieder hoofdstuk bevat artikelen, een artikel bevat leden, leden bevatten subleden, etc.

Op het /teksten endpoint kan je met het planId, het id van het eerste regel object, en een filter op niveau 2 alle hoofdstukken van de regels ophalen:


https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen/NL.IMRO.1586.BPBUI2041-VG01/teksten?niveau=2&ouderId=NL.IMRO.PT.regels.s1251

Je krijgt hierin standaard alleen een linkje naar de kinderen (de artikelen in de hoofdstukken). Als je die direct op wil halen, kan je de expand optie gebruiken. Met


https://ruimte.omgevingswet.overheid.nl/ruimtelijke-plannen/api/opvragen/v4/plannen/NL.IMRO.1586.BPBUI2041-VG01/teksten?niveau=2&ouderId=NL.IMRO.PT.regels.s1251&expand=children

krijg je bij ieder hoofdstuk direct de artikelen in de _embedded property. Mocht je daar ook nog de leden van willen hebben, kan je de expand op children.children zetten.

Meer dan twee niveaus dieper opvragen dan het niveau waar je je request mee start is momenteel niet mogelijk. Als je alle teksten van een plan op wilt halen, zal je met meerdere requests zelf de boom door moeten lopen.

Filteren op de inhoud van de tekstobjecten is niet mogelijk.

Volgens mij heb ik zo de meeste vragen enigszins geraakt. Laat het vooral weten als er iets niet duidelijk is, of er nog meer vragen zijn.

@sbjager, vraag het vooral hier op het forum als je een concrete vraag over een DSO API hebt. Ik probeer te beantwoorden wat ik kan (en waar ik kennis van heb). Dat niet alle DSO APIs even goed de DSO API strategie volgen (of anders interpreteren), kan ik helaas niet ontkennen.

#6

Doe ik zeker. Tot dusver heeft het nog geen urgentie, dus het blijft een beetje een tussendoor-klus. De bestemmingen kan ik allemaal wel ophalen op een locatie, het zijn de overige zaken die niks opleveren - maar dat kan ook aan de locatie(s) liggen die ik gebruik als test/ontwikkel-input. Dat zijn over het algemeen percelen in het buitengebied, dus misschien krijg ik telkens 404 op bijvoorbeeld de regelingen en toepasbare omgevingsdocumenten omdat er op die locaties niks is.
Is het altijd zo dat als de een er niet is, de andere er wel moet zijn? dus als ik geen ruimtelijk plan vind,dan moet er een omgevingsdocument zijn, en vice versa?

#7

Onderwerp: Problemen met het Opvragen van Specifieke Omgevingsplannen via de API

Beste Robin,

Allereerst wil ik u bedanken voor de verstrekte informatie tot nu toe. Deze heeft me enorm geholpen in mijn werkzaamheden.

Ik ondervind echter een probleem bij het opvragen van de juiste omgevingsplannen via de API. Mijn doel is om plannen op te halen waarvan de identificatiecode (ID) de volgende structuur heeft:

/akn/nl/act/gm0482/2020/omgevingsplan

Helaas lijkt deze ID-structuur niet ondersteund te worden door de huidige API, waardoor ik deze specifieke plannen niet kan verkrijgen. Ik heb diverse methoden geprobeerd, waaronder het gebruik van coördinaten, en heb tot nu toe 75 pagina’s met elk 10 plannen opgehaald. Helaas bevatten geen van deze plannen de gewenste ID-structuur. De meeste plannen die ik binnenkrijg zijn oud of specifiek gericht op een bepaald adres en hebben een andere ID-structuur, zoals bijvoorbeeld:

NL.IMRO.1652.BPKomwegHaageijk-VG01

Dit betekent dat de API momenteel niet de mogelijkheid biedt om omgevingsplannen op te halen met de ID-structuur zoals deze op de kaart wordt weergegeven. Hierdoor is de API in mijn specifieke geval niet bruikbaar, tenzij ik iets over het hoofd zie.

Mijn vragen zijn dan ook:

  1. Is er een alternatieve methode of endpoint binnen de API waarmee ik de gewenste omgevingsplannen kan opvragen?
  2. Zijn er aanvullende parameters of filters die ik kan gebruiken om deze specifieke plannen te vinden?
  3. Bestaat er een mapping tussen de externe ID-structuur (/akn/nl/act/…) en het NEN3610ID-formaat dat door de API wordt gebruikt?

Ik zou het zeer op prijs stellen als u mij kunt helpen bij het oplossen van dit probleem of als u verdere richtlijnen kunt geven over hoe ik deze plannen kan verkrijgen.

Bij voorbaat dank voor uw tijd en moeite.

Met vriendelijke groet,

#8

Iedere gemeente heeft met ingang van de Omgevingswet een “bruidsschat” gekregen, een soort van placeholder omgevingsdocument met (meestal) alleen een regelingsgebied. Dat zou je overal in Nederland moeten kunnen vinden.

Ruimtelijke plannen zijn ook nog overal te vinden waar het bevoegde gezag nog niet alle regels heeft overgezet naar een omgevingsdocument. Als een bevoegd gezag wel alle regels heeft over gezet naar het omgevingsdocument wordt een pons object aangemaakt in het omgevingsdocument om aan te geven dat binnen de geometrie van de pons geen ruimtelijke plannen meer geldig zijn. Het enige voorbeeld hiervan is een minuscuul gebiedje in Groningen.

Hiervoor moeten we toch even terug naar af. De API die je tot nu toe hebt gebruikt, levert alleen informatie uit over de ruimtelijke plannen (de oude standaard die met ingang van de Omgevingswet langzaam uit gefaseerd wordt). Als je op zoek bent naar de omgevingsdocumenten van de Omgevingswet heb je een hele andere API, of APIs, nodig.

Het beste startpunt voor informatie uit de omgevingsdocumenten van de Omgevingswet is de Presenteren API.

Teruglezend naar het eerste bericht in dit topic, is het doel (Het opvragen van bestemmingsplannen en bestemmingsvlakken op basis van een ingevoerd adres) niet haalbaar als het gaat over omgevingsdocumenten. Omgevingsdocumenten kennen geen bestemmingsplannen en -vlakken.

Als je aan de slag wil met omgevingsdocumenten is het verstandig om je eerst enigszins te verdiepen in het informatiemodel. Met die informatie zullen de DSO APIs ook iets eenvoudiger te begrijpen zijn.

#9

Zoals @RobinTopper hierboven beschrijft: op elke plek in Nederland is vanaf 01-01-2024 een Omgevingsdocument beschikbaar. Voor gemeenten is dat het Omgevingsplan met daarin (minimaal) de bruidsschatregels. Daarnaast zijn er provinciale Omgevingverordeningen, Waterschapsverordeningen en Rijksregelgeving (o.a. 4 AMvB’s). En daarnaast zijn er dus (bijna) overal ook Wro Bestemmingsplannen.
Er bestaat niet zoiets als “toepasbare Omgevingsdocumenten”. Wellicht gebruik je de ‘toepasbaar opvragen API’, maar die is (waarschijnlijk) niet geschikt voor jouw usecase.
Om te achterhalen waarom je een 404 krijgt, is het handig als je wat meer info geeft: welke API gebruik je, op welke manier, met welk doel?

#10

Beste Robin,

Ik ben momenteel bezig met het gebruiken van de Presenteren API om omgevingsdocumenten op te vragen op basis van coördinaten van een locatie. Het uiteindelijke doel is om de documenten verder te filteren op specifieke onderdelen, zoals hoofdstukken, afdelingen, artikelen en paragrafen. Ik ben echter tegen enkele problemen aangelopen met betrekking tot de authenticatie en het correct opvragen van de documenten.

Huidige aanpak

  1. Stap 1: Coördinaten ophalen via PDOK Ik gebruik de PDOK Locatieserver om de coördinaten van een adres om te zetten naar RD-coördinaten. Bijvoorbeeld, voor het adres “Stationsweg 1, Amersfoort” haal ik de volgende coördinaten op:
  • RD X = 155000.0
  • RD Y = 463000.0
  1. Stap 2: Documenten opvragen via de Presenteren API Met deze coördinaten probeer ik vervolgens de omgevingsdocumenten op te vragen via de Presenteren API. Hiervoor gebruik ik het endpoint:
POST https://service.pre.omgevingswet.overheid.nl/publiek/omgevingsdocumenten/api/presenteren/v7/locatieidentificaties/_zoek

Dit is de body die ik meestuur:

{
  "geo": {
    "geometrie": {
      "type": "Point",
      "coordinates": [155000.0, 463000.0]
    },
    "spatialOperator": "intersects"
  }
}

Dit proces levert een 401-foutmelding (“Authenticatie is mislukt”), ondanks dat ik zeker weet dat de API-key correct is ingevoerd. Ik vermoed dat het probleem kan liggen aan de toegang tot de pre-productieomgeving, of dat er mogelijk iets anders in het authenticatieproces niet correct gaat.
3. Stap 3: Filtering van de ontvangen documenten Het doel is om, zodra de documenten succesvol worden opgehaald, deze verder te filteren op specifieke onderdelen zoals hoofdstukken, afdelingen, artikelen en paragrafen. Hiervoor wil ik gebruik maken van het /teksten-endpoint, met als voorbeeld het volgende verzoek:

GET https://service.pre.omgevingswet.overheid.nl/publiek/omgevingsdocumenten/api/presenteren/v7/regelteksten?niveau=2&ouderId=<document_id>&expand=children

Dit zou mij in staat moeten stellen om de hoofdstukken van de regels op te halen en verder in te zoomen op artikelen, afhankelijk van de structuur van het document. Als ik direct ook de artikelen wil ophalen, gebruik ik de parameter expand=children.

Voorbeeld van de volledige code die ik gebruik:

Hier is de volledige code die ik gebruik om het proces te automatiseren:

import requests

# Stap 1: Adres omzetten naar coördinaten via PDOK Locatieserver
def geocode_address(address):
    pdok_url = f"https://api.pdok.nl/bzk/locatieserver/search/v3_1/free?fq=type:adres&q={address}"
    response = requests.get(pdok_url)
    
    if response.status_code == 200:
        results = response.json()['response']['docs']
        if results:
            # Haal de RD-coördinaten op
            rd_x = results[0].get('centroide_rd', '').split('(')[1].split(' ')[0]
            rd_y = results[0].get('centroide_rd', '').split('(')[1].split(' ')[1].strip(')')
            return float(rd_x), float(rd_y)
        else:
            print("Geen coördinaten gevonden voor het opgegeven adres.")
            return None
    else:
        print("Geocodering mislukt.")
        print(response.text)
        return None

# Stap 2: Opvragen van omgevingsdocumenten op basis van coördinaten
def find_omgevingsdocument(api_key, rd_x, rd_y):
    presenteren_api_url = "https://service.pre.omgevingswet.overheid.nl/publiek/omgevingsdocumenten/api/presenteren/v7/locatieidentificaties/_zoek"
    
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Content-Type": "application/json"
    }

    data = {
        "geo": {
            "geometrie": {
                "type": "Point",
                "coordinates": [rd_x, rd_y]
            },
            "spatialOperator": "intersects"
        }
    }

    response = requests.post(presenteren_api_url, json=data, headers=headers)
    
    if response.status_code == 200:
        return response.json()  # Ontvang de documenten
    else:
        print(f"Error: {response.status_code}, {response.text}")
        return None

# Stap 3: Filteren van documenten op basis van hoofdstukken, afdelingen, etc.
def filter_regelteksten(api_key, document_id):
    teksten_api_url = f"https://service.pre.omgevingswet.overheid.nl/publiek/omgevingsdocumenten/api/presenteren/v7/regelteksten?niveau=2&ouderId={document_id}&expand=children"
    
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Content-Type": "application/json"
    }

    response = requests.get(teksten_api_url, headers=headers)
    
    if response.status_code == 200:
        return response.json()  # Ontvang de hoofdstukken en artikelen
    else:
        print(f"Error: {response.status_code}, {response.text}")
        return None

# API-key en adres invoeren
address = "Stationsweg 1, Amersfoort"
api_key = "<JOUW API-KEY>"

# Stap 1: Coördinaten ophalen
coordinates = geocode_address(address)

if coordinates:
    rd_x, rd_y = coordinates
    print(f"Coördinaten voor {address}: RD X={rd_x}, RD Y={rd_y}")
    
    # Stap 2: Omgevingsdocument opvragen
    document = find_omgevingsdocument(api_key, rd_x, rd_y)
    if document:
        print("Omgevingsdocument:", document)
        # Stap 3: Document filteren op hoofdstukken, artikelen, etc.
        filtered = filter_regelteksten(api_key, "<document_id>")
        if filtered:
            print("Gefilterde inhoud:", filtered)
else:
    print("Geen omgevingsdocumenten beschikbaar zonder coördinaten.")

Mijn vraag:

  • Ligt het probleem aan de API-key?: Krijg ik een 401-fout omdat mijn API-key mogelijk geen toegang biedt tot de pre-productieomgeving, of is er een andere reden dat de authenticatie mislukt?
  • Optimalisatie van het filteren: Zodra de authenticatie werkt, wil ik de opgevraagde documenten filteren op verschillende niveau’s zoals hoofdstukken, afdelingen, en artikelen. Heb je aanbevelingen over hoe ik dit proces efficiënter kan aanpakken?

Ik zou het erg waarderen als je me kunt helpen met deze problemen en suggesties kunt geven voor verdere stappen.

Alvast hartelijk dank voor je tijd en hulp!

Met vriendelijke groet,

#11 
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Content-Type": "application/json"
    }

vervangen door

    headers = {
        "x-api-key": "{api_key}",
        "Content-Type": "application/json"
    }

zou je authenticatie probleem moeten verhelpen.

De query parameters die je denkt te gaan gebruiken op het /regelteksten endpoint bestaan daar niet, dus dat gaat niet werken.

Waarschijnlijk is het regelingen/{identificatie}/tekststructuur endpoint een betere ingang in de teksten. Daar krijg je de complete tekst van de regeling mee terug in een boomstructuur. Op basis van het type veld kan je daar de verschillende “niveaus” in vinden. Filteren met query parameters wordt niet ondersteund op dat endpoint, dus dat zal je zelf na bevraging moeten doen.