Wat voor request doe je precies? Een request waarbij je zowel filtert op pandidentificatie als op geometrie lijkt mij engiszins overbodig, dus dat zou voor vertraging kunnen zorgen. En ik heb zelf gemerkt dat het er ook nogal vanaf hangt welke ruimtelijke query je gebruikt, dus ook daar zou je misschien wat kunnen aanpassen.
Hoi @rli, wat @sbjager zegt, heb je een voorbeeld request.
Als ik zo ff snel test met wat je beschrijft, BBOX + Filter op pandidentificatie.
Dan lijkt service.pdok.nl de snelste van de 3 te zijn +/-20ms vs +/-40ms
Mijn POST GetFeature request staat in het erin toch? Althans ik zie hem staan.
Deze request is wel snel bij de vorige BAG WFS versies dus waarom niet meer in 2.0?
We hebben onze redenen om deze query ook ruimtelijk af te bakenen. Het zijn namelijk generiek gegenereerde queries die bv ook op gebruiksdoel kunnen selecteren binnen een bepaald gebied.
Daarmee loop je wel het risico dat je tegen dit soort problemen aan loopt. De pandidentificatie is uniek, dus dat levert 1 resultaat op, maar vervolgens moet de server ook nog eens een ruimtelijke index gaan controleren. Of mogelijkerwijs doet de server het net andersom, haalt eerst het ruimtelijke antwoord op en gaat daarbinnen filteren op identificatie. Je loopt dan zelfs het risico dat je geen antwoord terug krijgt, terwijl dat er wel is. Maar in ieder geval kost het minstens twee stappen, dus dat het trager word verbaast mij niks. Ik zou daarom het generiek opbouwen van mijn queries nog eens goed onder de loep nemen. Het is makkelijk genoeg te identificeren of het om een selectie op basis van een unieke waarde gaat of niet. En ik ga er van uit dat je ook controleert dat het ruimtelijke gebied niet al te groot is (je wil niet dat iemand alle panden met woonfunctie over heel NL ophaalt, lijkt mij…) , dus dat soort checks zou ik toch wel inbouwen.
Oh, en je hebt inderdaad alleen de response gepost, geen request (featurecollection met 1 verblijfsobject als member).