Opened 16 years ago

Closed 16 years ago

#2423 closed defect (fixed)

GetFeatureInfo FEATURE_COUNT should be per layer and not global

Reported by: dmorissette Owned by: dmorissette
Priority: normal Milestone: 5.2 release
Component: MapServer C Library Version: unspecified
Severity: normal Keywords:
Cc: sdlime, assefa

Description (last modified by dmorissette)

In WMS 1.1.1 and older, there were two ways that WMS GetFeatureInfo FEATURE_COUNT could be interpreted and the WMS 1.1.1 and older spec was not clear on which way it was:

1- FEATURE_COUNT could limit the number of results per layer.

2- FEATURE_COUNT could limit the overall number of results

MapServer 5.0 and older implemented the second option (i.e. FEATURE_COUNT limits the overall number of results). However, the WMS 1.3.0 spec finally clarified this behavior and clearly states that FEATURE_COUNT is the maximum number of features *per layer*.

We need to change MapServer's behavior to handle FEATURE_COUNT per layer. This change will apply to all supported WMS versions since it was not clearly defined in older WMS releases.

While we're at it we will also fix ticket #1686 which was about the fact that feature_count was ignored for GML info_format

Change History (7)

comment:1 by dmorissette, 16 years ago

Description: modified (diff)

comment:2 by dmorissette, 16 years ago

Description: modified (diff)

comment:3 by dmorissette, 16 years ago

Status: newassigned

This will be done by modifying msQueryByPoint() to take a new maxresults argument and passing the feature_count value to it for GetFeatureInfo. This will also fix #1686 without requiring any additional change:

  • Pass maxresults = 0 to have unlimited number of results.
  • Pass maxresults > 0 to limit the number of results per layer.

I do not plan to add maxresults support to other query functions nor to expose the maxresults argument in MapScript functions. However this could be done at some point in the future if one sees a need for this in MapScript.

comment:4 by sdlime, 16 years ago

I think this needs an RFC... Steve

comment:5 by dmorissette, 16 years ago

My changes were already done in r7147 (5.1-dev) before I read your comment about a RFC. Please read on and let me know if you still see a need for a RFC.

The maxresults arg has been added to msQueryByPoint() and is used to handle WMS GetFeatureInfo FEATURE_COUNT.

The new maxresults arg to msQueryByPoint() operates as follows. Basically, passing maxresults=0 maintains the traditional behavior in all cases:

  • With mode=MS_SINGLE:
  • Pass maxresults = 0 to have a single result across all layers (the closest
  • shape from the first layer that finds a match).
  • Pass maxresults = 1 to have up to one result per layer (the closest shape
  • from each layer). *
  • With mode=MS_MULTIPLE:
  • Pass maxresults = 0 to have an unlimited number of results.
  • Pass maxresults > 0 to limit the number of results per layer (the shapes
  • returned are the first ones found in each layer and are not necessarily
  • the closest ones).

As I wrote above, I have not exposed the new option to MapScript. We should do that only if/when we implement maxresults in all the query functions.

comment:6 by dmorissette, 16 years ago

Repeating comment from #1686:

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 (as you usggested in #1686) and to MapScript for 5.2?

comment:7 by dmorissette, 16 years ago

Resolution: fixed
Status: assignedclosed

Closing this ticket.

New ticket #2424 has been created about extending the maxresults concept to all layers and to MapScript in 5.2

Note: See TracTickets for help on using tickets.