ResultPaging bij WFS datasets

[wouter.visscher]

Hoi @SebastiaanR

@SebastiaanR

Niet alle WFS diensten op PDOK geven een “next” URL als ik een count variabele opgeef. Als work-around werkt het om ook “startindex=0” mee te geven.

We zitten in een “migratie traject”, dit zal over tijd gelijk getrokken worden tussen de verschillende datasets.

@SebastiaanR

De “next” URL wordt bij een aantal datasets (oa BAG v1_1 en kadastralekaart v4) steeds langer, omdat de server er iedere keer een extra “SERVICE=WFS&” aantoe voegt. Is niet echt een probleem, maar is wel wat rommelig

We zien het, dit kunnen (mogelijk) ‘eenvoudig’ oplossen.

@SebastiaanR

De BAG service geeft bij het in pagina’s inlezen van de resultaten dubbele objecten (en mist er daardoor ook een aantal)

Dat dit gebeurd met de URL’s die jij gebruikt heeft een technische ‘achtergrond’… als eerste dit is te ‘fixen’ door een SORTBY=bag:identificatie in je QUERY request mee te geven.

Dan krijg je dezelfde output als met een ‘compleet’ request, dus:

http://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?REQUEST=GetFeature&SERVICE=WFS&VERSION=2.0.0&OUTPUTFORMAT=application%2Fgml%2Bxml%3B%20version%3D3.2&BBOX=192652.920425,470719.209986,193252.920425,471319.209986&srsName=EPSG:28992&TYPENAMES=bag:pand

heeft dan hetzelfde resultaat als

http://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?REQUEST=GetFeature&SERVICE=WFS&VERSION=2.0.0&OUTPUTFORMAT=application%2Fgml%2Bxml%3B%20version%3D3.2&BBOX=192652.920425,470719.209986,193252.920425,471319.209986&srsName=EPSG:28992&TYPENAMES=bag:pand&count=100&startindex=0&SORTBY=bag:identificatie
http://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?REQUEST=GetFeature&SERVICE=WFS&VERSION=2.0.0&OUTPUTFORMAT=application%2Fgml%2Bxml%3B%20version%3D3.2&BBOX=192652.920425,470719.209986,193252.920425,471319.209986&srsName=EPSG:28992&TYPENAMES=bag:pand&count=100&startindex=100&SORTBY=bag:identificatie
http://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?REQUEST=GetFeature&SERVICE=WFS&VERSION=2.0.0&OUTPUTFORMAT=application%2Fgml%2Bxml%3B%20version%3D3.2&BBOX=192652.920425,470719.209986,193252.920425,471319.209986&srsName=EPSG:28992&TYPENAMES=bag:pand&count=100&startindex=200&SORTBY=bag:identificatie
http://geodata.nationaalgeoregister.nl/bag/wfs/v1_1?REQUEST=GetFeature&SERVICE=WFS&VERSION=2.0.0&OUTPUTFORMAT=application%2Fgml%2Bxml%3B%20version%3D3.2&BBOX=192652.920425,470719.209986,193252.920425,471319.209986&srsName=EPSG:28992&TYPENAMES=bag:pand&count=100&startindex=300&SORTBY=bag:identificatie

347 objecten, allemaal uniek

Waarom een SORTBY in de query, dit heeft te maken (zoals je mogelijk wel kan voorstellen) dat je niet met 1 server aan het communiceren bent maar met meerdere. Je requesten landen dus op verschillende backends, waardoor de resultset door verschillende cursurs (ongesorteerd) terugkomen. Door dit te ‘escapen’ kan je een SORTBY ‘gebruiken’ wat ervoor zorgt dat ongeacht de backend het resultaat ‘altijd’ in dezelfde volgorde terugkomt en dat iedere backend op de juiste plek ‘inprikt’ om de vraag “count=100&startindex=200” hetzelfde te beantwoorden.