“the plot thickens”
Voor deze use-case is dus precies de BRK download api in “het leven geroepen”. Waarbij de afnemer 1x een FULL download (van alle miljoen percelen, de ‘actuele stand’) waarna je daarna dagelijks (dezelfde update frequentie als de WFS, technisch gezien zelfs “iets” eerder up-to-date) de gemuteerde percelen naar binnen kan trekken en je database te updaten. M.a.w. je hoeft niet continue alle “miljoenen” percelen naar binnen te trekken. En als jullie ‘werken’ met bekende gebieden (de oranje polygonen) zou je op dat niveau ook de specifieke percelen (en indien aanwezig de mutaties) naar binnen kunnen halen.
Kijk voor jullie styling-probleem/issue is het idee om vanuit PDOK(/Kadaster) dit te gaan faciliteren d.m.v. Vector Tiles. Maar tot die tijd hebben we ‘helaas’ alleen de bestaande smaakjes (WMS/WFS/Download API).
Feit blijft dat wat jullie met de WFS proberen te doen “suboptimaal” gebruik daarvan is. Een WFS is geen bulkdownload interface, hoewel andere daar misschien anders overdenken is dit wel ons (PDOK) standpunt. En ik neem aan dat jullie dit enigszins kunnen beamen gezien er bewust’ om limieten heen wordt gewerkt.
Ik weet verder niet wat jullie capabilities/resources/ander functional requirements/enz… zijn, maar met deze ‘nieuwe’ informatie zou ik toch adviseren (zolang we nog geen VT van percelen hebben) dit met een DB + download API server-side op te lossen, al is het alleen maar om grip te krijgen op dit issue (c.q. het binnen jullie eigen invloedssfeer te trekken).