[WMS] FEATURE_COUNT paremeter is not respected

[assefa]

reprorted in the user list by Nick Floersch <Nick@STONE-ENV.COM>

>...Interestingly, the number given to FEATURE_COUNT seems
> to have nothing to do with how many features are returned once the query
> becomes an NQUERY... I set it to '2' for my example, and '7' unique and
> correct and appropriate records were returned.

[zoontf@…]

I would suggest that not only should the parameter be respected, but a * or
wildcard option be given (maybe 0 or -1) so that an unknown amount of features
can be returned by the GetFeatureInfo query.

[zoontf@…]

Also, Assefa entered this bug for me, which was great. I should note that my
platform is different than the on entered originallly.

I am using MapServer 4.8.1 on Debian Linux SID. I have tested the bug by
manually entering the GetFeatureInfo URL into Firefox and viewing the output
(GML) there, as well as using my WMS client application built with the Community
MapBuilder library. The results were the same.

[dmorissette]

Nick, Assefa,

Can you please more details about the exact problem or even better, a testcase to reproduce?

GetFeatureInfo with info_format GML and text/plain do honour the feature count properly

However I noticed in the source code that when using info_format text/html (i.e. using MapServer query templates) then the feature_count is ignored. Is this the problem you ran into and were reporting here?

[dmorissette]

No replies, so I'll assume that the problem is *NOT* with info_format GML or text/plain, but that it happens only with info_format text/html i.e. when using metadata ows_feature_info_mime_type to enable use of MapServer query templates with GetFeatureInfo.

Steve, to fix this I would like to add a max_features arg to the msReturnTemplateQuery() and msReturnQuery() functions. Any objection?

[dmorissette]

Checking the code again, it seems that GML output does not respect feature_count either.

Instead of modifying all functions that return query results to take a max_results arg, I think it would be more efficient to pass a max_results arg to msQueryByPoint().

Once again, seeking feedback on this option.

[assefa]

Sorry fot the delay. I have not looked into this bug for sometime so I do not have the exact test case that was used originally. Looking into your comments and the code, I think It covers both text/html and GML that would be format that was used in this bug. I also agree that using max_results at the query level is more efficient. Looking back I think we could have done the same with WFS (and querybyrect) instead of passing it to msGMLWriteWFSQuery.

Do you intend to expose this at mapscript level? Not sure if it is that useful but could be nice. (in fact I think we should not expose it until we have all the query functions using the max_features argument :less confusing for users I think)

[sdlime]

One problem with doing this at the query function level is that folks could mis-interpret the meaning. For example, by setting max results you'd be grabbing the 'first n' features, not the 'closest n' features. Unless of course we figure out a way to do just that, which would require changes to the query code.

Also the the query functions can handle 1 or many layers so I think this should be a LAYER-level paremeter rather than a function parameter. It needs to be useful beyond WMS and extended to all query types. (the point query is actually the most confusing)

I do think it belongs in the query functions rather than on the presentation side for performance reasons.

Steve

[dmorissette]

I needed a fix for this WMS issue quickly and had already committed r7147 before reading your suggestion to make this a layer-level parameter. :( See #2420 for the details of what has been committed so far.

How'bout we keep r7147 as an interim fix for the WMS issues and we take time to produce a RFC to extend the maxresults concept to all layers and to MapScript for 5.2?

[dmorissette]

Correction: in last comment I meant #2423 (and not 2420)

[sdlime]

Ok by me... Will you lead that effort?

Steve

[dmorissette]

Closing this ticket.

New ticket #2424 has been created about extending the maxresults concept to all layers and to MapScript in 5.2... and i'll take the lead on this.