Bij het opvragen van teksten willen we de volledige plantekst van meerdere plannen ophalen om te doorzoeken op zoekwoorden en een tekst-analyse te kunnen toepassen.
Op het moment is er alleen de mogelijkheid om te expanden op de children of children.children om de losse tekst objecten op te halen. Dit is logisch in een omgevingsloket-context waar de niveau’s één voor één worden opengeklapt, maar als je meerdere teksten wilt doorzoeken op bijv. zoekwoorden of iets anders wilt doen waar de gehele tekst voor nodig is moet de API dus ook een honderdtal keer recursief aangeroepen worden per plan, iets wat veel tijd kost (en me ook niet echt een server-vriendelijke oplossing lijkt 
).
Zou het voor deze use-case mogelijk zijn om een expand optie beschikbaar te krijgen (of een nieuwe query parameter) om alle teksten onder een plan op te kunnen halen met één API call? Dit zou dit proces een stuk efficienter en sneller maken, en minder server load veroorzaken.
1 like
Als je niet te kieskeurig bent over het formaat van de teksten is er ook een snellere weg om alle teksten op te halen:
- Zoek het plan op via één van de
/plannen endpoints
- Kijk in de respons onder
heeftOnderdelen
- Volg de link naar de brondocumenten onder
externeReferenties
Heel groot deel van de plannen heeft helaas HTML als bron formaat. En, nog een helaas, een deel van de HTML brondocumenten is in stukken opgeknipt, dus je zal soms de linkjes in de HTML moet volgen.
Als een plan objectgerichte teksten heeft die je kan opvragen in het /teksten endpoint, kan je zonder query params alle teksten binnen halen. Het zullen voor de meeste plannen een paar pagina’s zijn, maar dan heb je wel alle teksten.
Let wel op dat het /teksten endpoint alleen teksten bevat die geautomatiseerd uit de bronbestanden geëxtraheerd konden worden. Waar dat niet is gelukt, zal je voor de teksten sowieso terug naar de bronbestanden moeten.
1 like
En in aanvulling op de reactie van Robin zijn er nog enkele zaken om rekening mee te houden;
Planteksten kunnen ook als PDF gepubliceerd zijn en die zijn vaak niet (eenvoudig) doorzoekbaar
Daarnaast moet je er ook rekening mee houden dat plannen, en daarmee bijbehorende plnteksten, gedeeltelijk in werking kunnen zijn, bijvoorbeeld door gerechtelijke uitspraken, aanvullende plannen zoals parapluplannen of andere redenen. Ook de omgevingsplannen zijn nog van invloed, deze kunnen de bestemmingsplannen geheel of gedeeltelijk buiten werking stellen.
1 like
Hoi Robin,
Bedankt voor je vlugge reactie! Ik ben bekend met de externeReferenties aanpak, helaas moet ik wel kieskeurig zijn in dit geval. Ik haal de objectgerichte teksten op om deze gestructureerd te kunnen doorzoeken en te weergeven, waarvoor ik de tekst objecten gebruik. Alle plannen waar geen objectgerichte teksten bij zitten (verwijzingen naar HTML index pagina’s, PDF bestanden etc.) zet ik indien relevant zelf semi-automatisch om naar deze objectgerichte structuur.
Dus, het gaat voor mij echt om het inladen van alle objectgerichte teksten onder een plan. De tip die je geeft over het binnenhalen zonder query params is wel een goede optie die functioneel aan mijn vraag voldoet, wel dan met het nadeel natuurlijk dat er waarschijnlijk erg veel pages zijn die niet concurrent binnen zijn te halen en de structuur daarna handmatig weer in elkaar gezet moeten worden. Een total_pages property in de response zou kunnen helpen met concurrency (zit er op het moment niet in volgensmij) maar of deze aanpak uiteindelijk echt sneller zou zijn zou ik moeten uittesten.
Desalniettemin is het hierbij ook zonde dat de structuur die al bestaat dan wel verloren gaat in de overdracht. Als expand=children.children mogelijk is, dan lijkt me dat expand=children.children.children... ook mogelijk zou moeten zijn. Ik kan me voorstellen dat de responses niet te groot moeten worden, maar het lijkt me alsnog efficienter om alle data in één keer op te halen in plaats van in meerdere losse stapjes en concurrent requests.
Ik ben een groot fan de objectgerichte aanpak, en maak hier ook graag gebruik van. Het binnenhalen van alle objectgerichte teksten die bij een plan horen in plaats van een subset hiervan terwijl de structuur behouden blijft zou in mijn ogen een logische feature zijn van de /teksten endpoint.
Hoi Merijn, jij ook bedankt voor je reactie!
Zie in mijn reactie aan Robin hoe ik om ga met PDF plannen.
Zelf ben ik geen planoloog of jurist, dus hoe de plannen overlappen (gedeeltelijke plannen, parapluplannen etc.) en hoe hier mee omgegaan wordt laat ik aan de eindgebruiker. Ik wil vooral zorgen dat alle informatie een beetje vlot in de database landt en op een goede manier weergeven en verwerkt kan worden 
Maar als je zonder query params dat endpoint bevraagt, heb je alle teksten van het plan én gaat er geen structuur verloren (want die zit er niet in als je de expand niet gebruikt 
).
De vragen mbt de total_pages en het ophalen van alle teksten in een geneste structuur zet ik door naar de product owner.
Kan je wel al vertellen dat het heel onwaarschijnlijk is dat we op het bestaande endpoint de expand opties gaan uitbreiden. Als je die optie gebruikt zonder verdere filters explodeert de respons grootte.
2 likes
Ter aanvulling maar wellicht overbodig voor deze usecase: sinds de inwerkingtreding van de Omgevingswet per 01-01-2024 geven de Wro ruimtelijke plannen en de “ruimtelijke plannen API” géén compleet overzicht | inzicht in de juridische regelgeving in de fysieke leefomgeving.
Maar als je zonder query params dat endpoint bevraagt, heb je alle teksten van het plan én gaat er geen structuur verloren (want die zit er niet in als je de expand niet gebruikt ).
Klopt, hier bedoelde ik uiteraard het “behouden” van de expand structuur, deze structuur is een zeer nuttige feature van het endpoint
De vragen mbt de total_pages en het ophalen van alle teksten in een geneste structuur zet ik door naar de product owner.
Bedankt, dat waardeer ik! Zeker een total_pages (ook op bijv. het /plannen endpoint) zou concurrency weer een stukje simpeler maken.
Kan je wel al vertellen dat het heel onwaarschijnlijk is dat we op het bestaande endpoint de expand opties gaan uitbreiden. Als je die optie gebruikt zonder verdere filters explodeert de respons grootte.
Snap ik helemaal, vanaf een plan niveau zal het inderdaad wel een grote response worden.
Zou een mogelijk werkbaar alternatief kunnen zijn dat het inladen van alle children in één request pas vanaf een bepaald niveau mogelijk is? Het zou bijvoorbeeld al enorm behulpzaam zijn als voor een enkel artikel tekstobject alle onderliggende teksten opgehaald zouden kunnen worden. children.children is hier niet altijd toereikend (ivm subsubleden), maar het verschil tussen children.children en “alles” ophalen zal dan niet zo groot zijn, en dit zou wel alle extra subsubleden meepakken waar anders een losse API call gemaakt voor zou moeten worden.
Bedankt voor je reacties tot nu toe in ieder geval, dit is al een zeer leerzame discussie 