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 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.