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


_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev

Reply via email to