Ik probeer met WFS de GWSW databron op te halen en daar heb ik wat problemen mee.
In de aanroep geef ik een bounding box mee, bijvoorbeeld: bbox=80034.6,452005.1,81976.8,453965.8
Vervolgens haal ik vanwege de paginering de volgende data op als er een ‘next’ atrtibuut voorkomt. Ik heb gezien dat er ook een attribuut ‘numberMatched’ bestaat met de waarde ‘unknown’, totdat de laatste pagina verschijnt die geen ‘next’ parameter meer heeft. Dan staat er een waarde van bijvoorbeeld ‘3166’.
Met de genoemde bounding box krijg ik 1x een ‘next’ pagina, en als ik die aanroep dan is er geen ‘next’ meer maar ‘numberMatched’ is nog steeds unknown.
Dan mis ik vervolgens aan leidingen een heleboel data, terwijl ik in exact dezelfde bounding box wel alle putten binnen kan halen:
Pas ik de bounding box aan naar bbox=80000,452000,82000,454000 (in het plaatje is dat de buitenste rand, degene die er net binnenvalt is de bounding box zoals hierboven is besproken) dan krijg ik wel alle data binnen en zelfs tot 4 pagina’s aan data. De laatste pagina geeft keurig ‘numberMatched’ terug met ‘3166’ items.
Er zit nauwelijks verschil in de beide bounding boxes. Ook als ik een heel groot gebied neem dan gebeurt hetzelfde.
bbox=79035,451240,82990,455242 geeft geen ‘next’ urls meer:
bbox=79030,451240,82990,455242 gaat moeiteloos verder, ondanks maar 5m verschil in de eerste X.
Door een beetje te spelen:
bbox=79031,451240,82990,455242 geeft alles, maar:
bbox=79032,451240,82990,455242 geeft geen ‘next’ urls meer. Er zit maar 1m verschil in de X.
Ik kan niet anders vermoeden dat dit een bug is, en alleen bij ‘beheer_leiding’ optreedt. Met dezelfde bounding box haal ik wel alle putten op.
Tweede issue:
De next urls worden bij elke aanroep voorzien van een extra ‘SERVICE=WFS’:
Dit levert geen fout op maar is wel lelijk. En misschien gaat het de max lengte van een url een keer bereiken.
