Pagination: Previous/next response parameters alleen bij gebruik van startIndex

Datasets
#1

Het was even zoeken in de documentatie, maar de WFS service geeft geen previous/next URI’s mee, zoals in de WFS standaard is opgenomen:

Hier is een voorbeeld.

De response heeft deze URI’s niet en dus kan de volgende in de set niet worden opgehaald. De server adverteerd echter wel paging support:

<ows:Constraint name="ImplementsResultPaging">
    <ows:NoValues/>
    <ows:DefaultValue>TRUE</ows:DefaultValue>
</ows:Constraint>

(Bron)

Daarnaast is de resultsetgrootte gelimiteerd tot 1000 (dus niet alleen een default count, maar ook de max):

% curl --silent 'https://geodata.nationaalgeoregister.nl/bag/wfs?version=2.0.0&request=GetFeature&service=WFS&typeNames=bag:woonplaats&sortBy=bag:identificatie+A&count=2501'| \
    egrep -o 'numberReturned="[^"]+"'
numberReturned="1000"

% xmllint --xpath 'count(//*[local-name()="member"])' woonplaatsen.gml
1000

Volgens de standaard:

In order for paging to be triggered, either the count (see 7.6.3.5) parameter shall be set on the request or the server shall implement a default value for this parameter that shall be advertised in the server’s capabilities document (see Table 14).

Maar hij triggered dus alleen wanneer startIndex aanwezig is (0-based).

De documentatie hierover is daarom ook niet volledig genoeg en hopelijk bespaart deze post anderen mijn zoekwerk.

#2

Gist om ze allemaal binnen te halen (python).

#3

Zonder de WFS2.0 standaard hierop te raadplegen werkt eea in mijn beleving als volgt:
-als je niet specifiek een maximum aantal features opvraagt krijg je alle features of het maximum dat in is gesteld op de server. Je krijgt dan GEEN pagination links in de response.

  • als je zelf wel specifiek een maximum aantal features opvraagt dan krijg je dit aantal of minder als er minder features zijn of de server een lager maximum heeft ingesteld. Je krijgt WEL pagination links in de response.

Als je het volgende request met POST verstuurd naar: https://geodata.nationaalgeoregister.nl/bag/wfs
krijg je wel pagination links in de response (let op het count attribuut in het GetFeature element):

<?xml version="1.0" encoding="UTF-8"?> 
<GetFeature count=100 xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/2.0/wfs.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns="http://www.opengis.net/wfs/2.0" service="WFS" version="2.0.0"> 
   <Query xmlns:app="http://www.deegree.org/app" typeNames="bag:pand"> 
     <fes:Filter xmlns:fes="http://www.opengis.net/fes/2.0"> 
      <fes:And> 
       <fes:Within> 
        <fes:ValueReference>bag:geometrie</fes:ValueReference> 
         <gml:Envelope srsName="urn:ogc:def:crs:EPSG::28992"> 
          <gml:lowerCorner>138000 452000</gml:lowerCorner> 
          <gml:upperCorner>139000 453000</gml:upperCorner> 
        </gml:Envelope> 
      </fes:Within> 
       <fes:PropertyIsEqualTo> 
        <fes:ValueReference>bag:bouwjaar</fes:ValueReference> 
        <fes:Literal>1982</fes:Literal> 
       </fes:PropertyIsEqualTo> 
     </fes:And> 
    </fes:Filter> 
  </Query> 
</GetFeature>

Eventueel kun je ook nog een startIndex attribuut toevoegen aan het GetFeature element.

#4

Nope, count attribuut zit in m’n voorbeeld link (alleen via GET parameter). startIndex is het enige wat de paginatie activeert. Misschien dat een POST request het anders doet - niet getest.

Gelukkig is hij stateless, dus kan je gewoon de startindex met de count ophogen voor de volgende pagina, maar zou PDOK besluiten om transactie support te activeren, dan heb je toch echt die links nodig voor je transactie ID.

#5

In jouw voorbeeld staat count groter dan het max aantal features dat de server teruggeeft. Dan krijg je geen pagination links.

Probeer het eens met count=100

Melvyn Sopacua noreply@pdokforum.geonovum.nl schreef op 26 september 2017 18:37:50 CEST:

#6

Hmm, inderdaad, ook bij count=10 komen er geen pagination links. Bij het gebruik van startIndex wel.

Overigens is het zou dat deze pagination links exact gelijk zijn aan die je zelf zou berekenen op basis van startIndex en count.

deze begrijp ik niet “maar zou PDOK besluiten om transactie support te activeren, dan heb je toch echt die links nodig voor je transactie ID.”

#7

Uit “OpenGIS Web Feature Service 2.0 Interface Standard”

7.7.4.4.2.2
Response paging with transactional consistency
Servers that declare transactional consistency shall maintain transactional consistency between paging
iterations. Thus, the view of the data that a client sees while paging through the response set shall be
consistent with respect to the time that the originating request was executed.

Om dat te kunnen implementeren, heb je een transactie ID nodig (of cache ID of hoe je het ook maar noemt) om de dataset van dat specifieke moment te kunnen garanderen.

#8

Responsepaging bij PDOK werkt altijd middels een opgegeven limiet (bij PDOK of meegegeven in een WFS request als ‘count’ request parameter) in combinatie met een ‘startIndex’ request parameter in het WFS request waarbij de laagste waarde van de limiet bepaalt hoeveel features maximaal geretourneerd worden. Het toevoegen van de ‘startIndex’ request parameter is dus cruciaal voor het verkrijgen van een next en/of previous header met een link naar respectievelijk de volgende of vorige features.

Daarnaast ondersteund PDOK geen transaction safe response paging zoals ook in de WFS Getcapabilities wordt geadverteerd. Indien er een update op de data komt tijdens het itereren door de paging resultaten kan het dus voorkomen dat features ontbreken of dubbel voorkomen.

#9

Dit stond ook in de documentatie. Alleen waren er in dezelfde documentatie ook voorbeelden met count en zonder startIndex. Dat is nu allemaal gecorrigeerd, zodat je niet op het verkeerde been wordt gezet.

Voor de duidelijkheid: count zonder startIndex limiteert wel het aantal resultaten, maar geeft dus geen paginatie links.