[fschmenger]

Handle hover tooltips with respect to layer z-order.

[chrismayer]

Thanks for your PR @fschmenger. See my comment regarding a possible bug.

[chrismayer]

Some more questions:

1.) The tooltip does not appear until all requests are complete. Previously, displayTooltip was called immediately for each incoming response. Now, allSettled waits for the slowest WMS request. Is that intentional?

2.) Only the top layer with matches is now displayed. Previously, the features of all hoverable layers were collected in featureInfos now, only those of the first layer with matches are included. This aligns with the "prioritize" label, but it is a breaking change for apps that use overlapping layers with multiple tooltip entries.

[fschmenger]

Hi @chrismayer, thanks for the tests and the review. Regarding your questions:

1. Yes, this is the consequence of prioritizing tooltips. You cannot evaluate priority unless you know which of the set of currently visible, hoverable layers has a feature at the current mouse cursor point. For WMS layers this is only known after the feature info request has completed. So there is no easy way around waiting for all pending requests. There is however an optimization: You could stop once a layer L has reported an existant feature while all layers with a higher priority than the layer L have reported not to. This makes the implementation a bit more complicated. In my applications there are barely more than a couple of visibile, hoverable WMS layers so the benefit of this optimization might be doubtful. Should I go for it?

2. There is no real breaking change. The code collects all features associated with a layer in a featureInfos object which has the structure Array<{layer: ol.Layer, feature: ol.feature}>. If the layer has multiple features at the target then displayTooltip picks the first out of the array and emits an update-overlay event. This will display a single feature for a single layer at a time. The only difference is, that in the old code the layer to be picked is not well defined (it is just a race condition), while the new code chooses the topmost layer by z-index.

So IMO the nature of this PR is just a bugfix - it's confusing to see feature tooltips for layers hidden underneath another one.
Good catch with invalid WMS requests, I will look into this now and provide a fix.