BAG WFS met limiet van 10000

De BAG WFS geeft nu melding (in QGIS)

Layer pand: Download of features for layer bag:pand failed or partially failed: WFS exception report (code=InvalidParameterValue text= It’s not possible to use a ‘startindex’ higher then 10.000. Scraping the WFS has a negative impact on the performance of the service. ).

Gevolg is dat de download van de data stopt en de dataset dus niet compleet is.
voor mij is niet compleet = onbruikbaar.

Ik begrijp dat er performance problemen zijn als je heel Nederland gaat ophalen via WFS.
Maar met deze oplossing is de WFS in feite onbruikbaar geworden!
Zijn er echt geen andere (=gebruikers vriendelijke) oplossingen te bedenken?

En, aub, als er weer zo’n aanpassing komt, is het mogelijk dat dit aangekondigd wordt?

@mdijkman

We hebben de startindex begrenst op 10.000 omdat we tegen flinke performance problemen op onze database aanlopen.
Deze performance problemen werden veroorzaakt door het scrapen van de WFS door verschillende clients.
We zien in Qgis dat op hoge zoomniveaus nu inderdaad niet alles op te halen is, we zijn bezig om een goede balans te vinden tussen de performance en de hoeveelheid data die we aan de clients kunnen serveren.

De use-case van de WFS is in ons inzien om alle panden van een gemiddelde woonkern te kunnen opvragen, daarom gaan we zsm de begrenzing op de startindex verhogen naar 50.000.

Hardop meedenkend: ik snap de noodzaak voor enige begrenzing.
Maar loop je nu niet het risico dat er door clients allerlei query parameters op niet-geindexeerde attributen aan de WFS request worden meegegeven?
Of zijn in de achterliggende database álle kolommen geïndexeerd?

@mdijkman we hebben de limiet opgehoogd naar 50.000 objecten. Ik heb even de proef op de som genomen voor een aantal verschillende steden (Utrecht, Amsterdam, Den Haag, Arnhem) in QGIS en het is nu mogelijk om alle objecten in te laden bij een schaal van 1:10.000. In minder dichtbebouwde gebieden gaat een kleinere schaal (cartografisch gezien; 1:20.000 is kleiner dan 1:10.000) ook goed om dat daar minder gebouwen staan.

@gisnederland bedoel je dat we hiermee stimuleren de WFS slimmer bevraagd wordt? Want dat is precies de bedoeling. Aangezien de WFS (in onze optiek) bedoeld is voor het gericht bevragen en niet voor bulk download. De meest bevraagde attributen in de BAG WFS zijn geïndexeerd. Mocht de performance van specifieke queries te wensen over laten dan kan die wens kenbaar gemaakt worden via het Geoforum.

1 like

@antonbakker Dank! ben nu even aan het testen, de eerste resultaten zijn positief!
Nog een kleinigheidje: Ik denk dat het “use a ‘startindex’ higher than 10.000” moet zijn ipv “then”

Helder en herkenbaar punt van WFS als query endpoint ipv bulk download.
Ik puzzel (met andere veiligheidsregio;s) nog wel op hoe je duidelijk kunt maken welke attributen geschikt zijn om op te query-en (en dus geïndexeeerd), en welke (niet geïndexeerde) attributen je eigenlijk alleen als resultaat van de query terugkrijgt.
Heb daar in de WFS standaard én in ISO-19139/19110-metadata nog niets handig voor gevonden. Eigenlijk zou ik in de GetCapabilities (of eigenlijk: de DescribeFeatureType) willen kunnen laten zien welke attributen geïndexeerd zijn, en dus geschikt om op te query-en.

Waarom maakt dat een verschil, welke attributen geindexeerd zijn en welke niet? Dat mag niks uitmaken voor de informatie vraag, en de informatievraag is dat we willen kunnen zoeken op attributen. En dan is het aan de technische kant om er voor te zorgen dat die zoekopdrachten acceptabel performen. Da’s zeker in dit geval netjes uitgesplitst, en dat zou ik zeker zo houden.

Overigens moet je oppassen met overal een index op te (laten) zetten. Een index kan een query in een database juist langzamer maken.

Na wat testen ben ik toch iets minder positief over de gekozen oplossing.
Ik kan nu niet de eindgebruikers garanderen dat het met schaal 1:20.000 of 1:10.000 altijd goed gaat.
Er zijn misschien bepaalde locaties waar teveel objecten bij elkaar staan.
Maar goed, 50.000 objecten werkt wel een stuk beter dan 10.000.