[mapserver-dev] WFS maxFeatures Support (sucks)...

Steve Lime sdlime at gmail.com
Mon Sep 5 08:56:55 EDT 2011

Hi all: I've been working on a ticket related to WFS filters and the
maxFeatures parameter. Basically it just doesn't work, in fact it
can't work as designed. The layer maxfeatures parameter is what's used
and its purpose long ago was to limit the number of features drawn
from a sorted (by size) data source. So, for instance, you'd see the
50 largest lakes in any map view.

Not all drivers support it (SDE does not, OGR might not, SQL server
does not, nor do tiled shapefiles) and all that do, apply that limit
before checking filters (there's a comment to that effect in

Now its use needs to be much more precise. The best way to do that
IMHO would be to handle the feature counting outside the drivers, in
the msQueryBy...() functions and in msDrawLayer(). In the query
functions the result cache already maintains a counter so we just need
to examine it after each feature is added and when we hit the limit we
simply stop reading from the data source. The result cache drives and
subsequent presentation so that code wouldn't be touched. Check is
something like:

      /* check shape count */
      if(lp->maxfeatures > 0 && lp->maxfeatures ==
lp->resultcache->numresults) {
	status = MS_DONE;
    } /* next shape */

So my proposal would be to:

  1) pull maxfeatures use out of the driver code, usually just a few lines
  2) install the code to check the shape count in the query functions
for consistent behavior
  3) update msDrawLayer() similarly (code might already be doing this)
  4) pull maxfeatures checks out of mapgml.c, they're redundant

I consider this a bug, not a new feature so I'd propose this for
6.0.2. I can prepare a patch against branch-6-0 if that would help
folks with the scope of the change. Note the OGC code that *sets*
maxfeatures either based on a user set parameter or metadata would
continue on "as is".


More information about the mapserver-dev mailing list