WFS Feature paging … yes please

Sean posted his thoughts in response to Chris’ and all i can say is, yes please!

My random thoughts,

  • Why this functionality was never embedded into WFS i will never know. After playing with CSW for the last 6 months where similar “pagination” is available … it just makes sense. How the average Jo Blogs will ever understand what maxFeatures should be set to is irrelevant if the user cannot even determine how many *total* features are available given his query. OGC CS-W handles this quite nicely, almost identical to how Chris H. described it. If i search for “hydro”, it will give me a numberOfRecordsMatched=”340″ but then also tell me that i’m just viewing the first 10 records.
  • Paging has been linked to server performance, particularly caching a set number of features. This imo, would only hold true if the given features are retrieved in the same manner. How this would handle filters i’m a little unsure of (beyond the simple bbox). Just because search engines index http://sigma.openplans.org/geoserver/water_shorelines/100 doesn’t mean that the same features will appear in the same page 10 days later, for example. Checksum? HTTP Last-modified? *shrug*

Looks like i need to pay more attention to the OGC boards :)

3 thoughts on “WFS Feature paging … yes please”

  1. In WFS 1.1 you can get the total number of features to be returned by a given query by doing resultType=’hits’.

    As for CSW paging, yes, that’s definitely my inspiration. I need to get around to submitting a change request to WFS to adopt the same CSW semantics. I asked the editor of the spec and he wasn’t against it. Just need to write up the document. I also want to get CQL in to WFS – we’re already using it, and we have it for WMS as well. I need to write up some examples of how it’s useful.

  2. While the resultType=hits may solve the issue of the total number, i still prefer CSW in that it is only a single request/response.

    With WFS1.1 afaik (correct me if im wrong Chris) … you need to submit 2 requests, the first to retrieve the number based on your filter, and then submit the actual, “real” request.

    Conversely, with CSW … all the useful info is contained in the header. This IMO, is the way it should be done if you are considering revisions …

    SearchResults elementSet="summary" recordSchema="csw:Record" numberOfRecordsMatched="43" numberOfRecordsReturned="10" nextRecord="11"

Comments are closed.