Ik heb hier naar gekeken. De fout die je krijgt is wat je zelf ook al in je vraag aangeeft: Onze backend kan niet met een dergelijke complexe query omgaan, de iets minder complexe query wel. De foutmelding is mogelijk wat cryptisch. Mag ik je vragen waarvoor je een dergelijke query nodig hebt?
We willen na een zoekopdracht van een gebruiker naar personen (die meerdere personen kan opleveren) de bijbehorende verblijfsobjecten in de kaart bepalen.
Technisch kan dat natuurlijk maar eigenlijk wil je niet je je eigen code complexer maken dan nodig is. Is extra werk. Zo complex is de query ook weer niet, gaat maar om 30 adressen. Geeft te denken als de WFS server dat niet aankan.
Gebruik je een GET of een POST? het zou kunnen (heb het niet geverifieerd) dat met een dergelijke lange lijst de url te lang word als je een GET doet, en dat daardoor een deel van het filter afgekapt word (en dat daardoor de server een foutmelding geeft). @RoelvandenBerg kun je dat zien in de logs van de server?
Met een POST zou je een groter filter mee moeten kunnen sturen. Als dat ook niet werkt (cq niet de oorzaak is), dan is het beter om een dergelijk verzoek te splitsen in max 5 adressen, en die dan separaat af te vuren. Heeft meteen ook het voordeel dat dat performance gaat schelen aan de gebruikerskant, omdat je alle 6 requests tegelijk kunt afvuren.
Een laatste optie zou nog kunnen zijn de BAG API te gebruiken, maar die ken ik niet, dus ik weet niet of dit daarmee zou lukken.
En het probleem is niet zozeer het aantal adressen dat je terugkrijgt / opvraagt. Het probleem is de complexiteit query die uit “veel” losse deelqueries bestaat als:
Ons doel voor het beschikbaar stellen van de WFS is niet een service net die je als SQL alle mogelijke vragen kan stellen. Als je complexere queries op data wilt kunnen uitvoeren bieden wij de bag aan in geopackage formaat; zie: BAG
Ik zou zeggen dat 1 van de 2 afdoende zou moeten zijn, of reageert de WFS hier niet eenduidig op?
Dit zou i.i.g. de complexiteit van de query verminderen.
Als ik zo ff snel test lijkt de PropertyIsNull degene te zijn waarop de WFS reageert.
Daarmee lijkt 't request nog wel te groot te zijn, maar wat @sbjager zegt, ik zou deze ook opsplitsten in meerdere requesten.
Ons doel voor het beschikbaar stellen van de WFS is niet een service net die je als SQL alle mogelijke vragen kan stellen. Als je complexere queries op data wilt kunnen uitvoeren bieden wij de bag aan in geopackage formaat; zie: BAG
hmm, ik vind dit moeilijk. Volgens de WFS standaard is een WFS niet bedoeld als download service, maar als query service. Daar verwijst PDOK/ Kadaster ook veelvuldig naar om het beperken van het aantal features dat uit zo’n service wordt teruggeven te motiveren.
Nu is het volgens dit antwoord ook niet de bedoeling om de service scherp te bevragen en daarmee de resultatenset te beperken. Ik begin me dan toch serieus af te vragen waarvoor de WFS service dan wel bedoeld is.
Ik zou het persoonlijk een enorm verlies vinden als we weer jaren terug in de tijd worden gegooid en steeds maar weer complete datasets moeten downloaden en daarmee dus de lokale kopie actueel houden om relatief eenvoudige vragen over zo’n dataset te beantwoorden.
Dit soort bevragingen is m.i. precies waar de WFS standaard voor is bedoeld! Laten we ons inspannen om dit ook waar te maken. En dus niet al te snel doorpakken naar het downloaden van de gehele dataset.
Hoewel we een beetje off-topic gaan
Is het denk ik wel goed om een aantal punten uit te beantwoorden/verduidelijken.
Mee eens, hier hebben we (zeker in het verleden) genoeg vervelende ervaringen mee
Dit is in zekere zin waar. Hoewel ik de beschrijven uit de spec (2.0) “WFS offers direct fine-grained access to geographic information” nu niet direct als ‘alleen’ een query service zou defineren. Maar meer als een service “waarmee je ook kunt queryen”.
I.i.g. om zo te gebruiken zoals hij/deze nu door de meeste gebruikt wordt. Ik denk dat deze situatie een uitzonderlijke is die we (in bijna 10 jaar) niet eerder zijn tegengekomen. Of niet eerder onze oren heeft bereikt.
En dat het in dit geval een ‘verzameling’ van verschillende losse queries betreft gezien de opbouw, de ‘verbindende’ factor “een persoon/gebruiker” ligt namelijk buiten deze dataset.
Mee eens.
Het is altijd goed om op verschillende manier te kijken naar hoe WFS als koppelvlak te gebruiken is, zonder direct naar een ‘full download’ achtige alternatief te gaan.
Wat welk goed is om in het achterhoofd te houden is dat WFS ondertussen 12-20 jaar oud is (versie 1.0.0 mei 2002, versie 2.0 nov 2010) en de wereld er nu anders uitziet. Zie ook de ontwikkelingen m.b.t. de OGC API’s.
Voor de WFS ‘vervanger’, de OGC API Features, is het filter/query gedeelte een aparte ‘conformance’/onderdeel. M.a.w. het is dus niet een gegeven dat een dergelijk request op deze nieuwe koppelvlakken in 1 call/request is te beantwoorden en gezien het op RESTful services is gebaseerd dit inherent met meerdere losse requests gedaan moet worden. (Wat mogelijk ook sneller kan zijn, gezien requesten dan in parallel uitgevoerd kunnen worden)
Bij onderliggende databases van de WFS is een NULL waarde niet gelijk aan een lege waarde, zoals bij Oracle. Het ligt er maar net aan hoe het is opgeslagen. Wij genereren generieke queries zodat het ons niet uitmaakt hoe het is opgeslagen (NULL of lege waarde) in de onderliggende database van de WFS.
Het is ook al door iemand anders gezegd, ik vind dit inderdaad ook terug in de tijd.
Het ligt niet aan de complexiteit van de query want voor 20 adressen gaat de complexe query prima maar bij 30 adressen gaat het fout.
Is dit probleem al bij het Mapserver forum aangemeld? Zo niet, zou dat dan niet eerst beter afgewacht kunnen worden in plaats van voorbarig met deze reactie te komen?
Nog een verduidelijking op mijn bovenstaande antwoord, dat ik naar de download service verwees was inderdaad niet behulpzaam voor jouw usecase aangezien je overduidelijk op zoek bent naar een feature service.
Wat ik bedoelde met:
Ons doel voor het beschikbaar stellen van de WFS is niet een service net die je als SQL alle mogelijke vragen kan stellen.
Is dat een WFS meer constraints nodig heeft dan een database (in eigen beheer). Een database (in eigen beheer) biedt bijvoorbeeld de mogelijkheid om indices te bouwen voor eigen gebruik, een web feature service heeft dat voor een gebruiker niet. Voor een beheerder is het ook niet per se mogelijk om alle mogelijk vragen af te dekken. Daarbij geldt dat hoe complexer de filter die wordt toegestaan, hoe groter de kans dat de filter niet meer performt en een negatieve impact heeft op de service. Daarom is het vanuit het oogpunt van de service niet gek om de complexiteit / diepte van een filter ergens te beperken. De vraag blijft dan hoe diep?
Ik ben het er overigens met je eens dat de vraag die je aan de wfs stelt op het eerste oog niet supercomplex is. Omdat je effectief dezelfde vraag herhaalt en die bundelt. Je bevraagd dezelfde velden. Waar we hier volgens mij ook tegen aan lopen is een beperking van de wfs filters. Wat fijn zou zijn is als we zouden kunnen filteren op arrays van waarden. Dat zou de filter ook een stuk simpeler maken. Op dit moment biedt WFS voor zover ik weet alleen filteren op basis van ranges toe. Wat dus helaas niet aansluit op jouw usecase.
Je hebt dus te maken met een limitatie op de filtercomplexiteit die dus voor andere mogelijke queries bestaat. Wat ingesteld is om de service performant te houden.
@rli ik krijg een parser stack overflow, maar na nog iets dieper kijken lijkt die uit de database te komen, niet uit mapserver zelf. We gaan dit verder onderzoeken.
@rli ik heb het nu verder uitgezocht. Mapserver zet de filter correct door. De wfs query levert echter wel een zeer sterk genestte database query op. Daarmee wordt zoals ik hierboven aangaf een database limiet overschreven. Uiteindelijk ligt de genestte vorm van de query en daarmee het overschrijden van die limiet aan de aan de wfs filter die je aanbiedt. Het zou fijn zijn als je die filter zou kunnen herschrijven zodat die nestting niet optreedt, maar daar loop je aan tegen de beperkingen van wfs, zoals ik hierboven heb uitgelegd. Daarmee blijven de mogelijkheden beperkt tot wat we hierboven aangeven: de query op te knippen en dus een beperkt aantal resultaten tegelijkertijd op te vragen. Je zou de filter dus nog kunnen tweaken zoals @wouter.visscher hierboven aangeeft om meer resultaten tegelijk op te vragen. Het aanpassen van de databaselimieten doen we niet in verband met de mogelijke performance problemen die dit oplevert. Daarnaast zal ook dat je probleem niet oplossen, je zal altijd dan uiteindelijk later tegen een dergelijke limiet aanlopen.
Dit is niet anders te herschrijven qua nesting. De nesting is ook niet erg diep. Alleen het aantal voorkomens in de OR is korter te maken. Het geeft voor mij de tekortkomingen aan van Mapserver als product voor WFS. Daar is Geoserver beter in.
Bedankt voor het uitzoekwerk in ieder geval!
