[OpenLayers-Dev] layer order in findLayers() of WMSGetFeatureInfo
and WMTSGetFeatureInfo controls
jansen at terrestris.de
Fri Apr 8 06:46:32 EDT 2011
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
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 ;-)).
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,
More information about the Dev