fix: getfeatureinfo on grouplayers

[jokd]

Fixes #1618
Also somewhat rewrites code added in #1652 since it didn't fully handle maps where grouplayers were both visible and hidden.

[Grammostola]

This change appears to fix the related issue, as well as what was missing from 1652. I like the revised logic, it now looks for queryable layers in groups whereas it didn't before. (I don't see anything changed about visible layers or not). Nicely done, have tested a few different combos of imageFeatureInfoMode on a layer-in-group level and featureinfoOptions level and queryable now appears respected. Lgtm

[jokd]

In (the probably rare) case of a layer without imageFeatureInfoMode setting is in a grouplayer that is not visible, the always setting on map level will not have any effect for this particular layer. Think I'll fix that so we are consistent.

[Grammostola]

Right, then your first comment makes sens re: visibility. Looks better now, bit it looked pretty good before too so shan't say "good" again without one hefty testing matrix of scenarios and it's probably better if I go write the documentation : ) (but realistically I think it looks good and not visible group and always appears ok)

[jokd]

Thought of another thing. We just handle group layers that are set to queryable: true but this property is not documented and doesn't make much sense since we anyway look for the queryable property for each individual layer. So we maybe should skip that test and include all group layers in the loop, but this can potentially break someones config where they have set queryable: false on a group layer and expect no layers in than layer to be queried.
This is also a problem for the changePointerOnHover-function so we need to be consistent.

[Grammostola]

I don't know about grouplayers, whether their default queryable true passes the initiative to each included layer and queryable:false does not, or what should be rather. We (municipality) use very few grouplayers. I'm happy we don't employ recursion and fathomless depths.

As for changePointerOnHover..should it react under precisely the same circumstances as featureinfo?

When set to true, the mouse pointer changes when hovering over a clickable object.

It seems that way reading the docs. If so then they ought to meld somehow, configwise and codewise(the same hoops would be needed)

[jokd]

Change a bit so now setting queryable for group layers will have no effect, it just checks whether the individual layers are queryable or not, just like in the documentation.

As for the changePointerOnHover-feature it isn't possible (without rewrite of code) to behave 100% the same way since it is done client side and making getFeatureInfo requests for every pixel you move your pointer will most likely have negative consequences. So not visible layers won't trigger pointer change. Neither will transparent pixels.

[Grammostola]

Looks good. In regards to changePointerOnHover yes, I see your point, when image type layers are employed with a hatch pattern alternating colored lines and full transparency setting the featureInfoOption changePointerOnHover: true rhymes with imageFeatureInfoMode: pixel ie default and actually helps a little in showing when a click is going to produce an infowindow.

It doesn't completely rhyme with imageFeatureInfoMode: visible and as you say that can't really be helped as the response from layer.getdata() looks the same whether background map or transparent image layer feature.