[OpenLayers-Dev] layer order in findLayers() of WMSGetFeatureInfo and WMTSGetFeatureInfo controls

[Marc Jansen]

Hi Bart,

I am currently looking at application code that registers an 
eventlistener to getfetureinfo on the WMSGetFeatureInfoControl.

In that handler all results except for the first a thrown away. UMN 
Mapserver in that particular case returns the results for the particular 
location in the order they were requested.

The current logic in WMSGetFeatureInfo orders the layers for GetMap in a 
different Way than for GetFeatureInfo. For UMN this results in a setup 
where one only sees a feature from layer B (it is drawn atop a feature 
at the same location from layer A) and the first result of the GFI is 
the feature from layer A.

I am totally unsure what (if any) sorting is being applied to results of 
getFeatureInfo-results by the various WMS-implementations or what the 
standard says.

At least for UMN the order seems to be relevant.

I know that the application code could be refactored to examine the 
results and find the correct one, but I also see UMN mapserver behaving 
as one might (!) expect it to do:

Draw layer B atop of A => REQUEST=GetMap&LAYERS=A,B
Query Layer for Feature Info => REQUEST=GetFeatureInfo&QUERY_LAYERS=B,A

I am just unsure what the correct behaviour is, and if we should ignore 
the fact that UMN does respect the order of QUERY_LAYERS.

I hope my point is somehow clear and not to insignificant (Maybe I 
should not be working on this after a week of conference-stress ;-)).

Regards,
Marc



On 08.04.2011 10:30, Bart van den Eijnden wrote:
> Hi Marc,
>
> I did not see how the confusing behaviour could be reached, since FEATURE_COUNT is on a *per layer* basis AFAIK.
>
> So if there are features in both layers on the clicked point and FEATURE_COUNT is 1, you will always get back 2 features.
>
> Or am I missing something here?
>
> Best regards,
> Bart
>