Allow deck.gl z-index/container pane to be configurable with Google Maps

[SterlingMcCall]

Target Use case

Because the deck.gl heatmap layer only supports WebGL2 enabled browsers, I wanted to use a Google Maps native heatmapLayer as a fallback. However, the fact that deck.gl creates itself on the overlayLayer MapPane (which is the proper pane) results in the native Google Maps heatmapLayer appearing overtop the deck.gl layer. The use-case is for those wanting a native Google Map heatmapLayer to appear below deck.gl.

Proposed feature

I propose that the MapPane onto which deck.gl attaches itself be configurable.
The 5 MapPanes available are the mapPane, overlayLayer, makerLayer, overlayMouseTarget, and the floatPane.

Attaching the deck.gl instance to the markerLayer results in the native heatmap appearing below the deck.gl layer, and if native google maps markers are desired to be used, they can be placed above the deck.gl layer by increasing their z-index in the marker's constructor opts. Placing deck.gl on the overlayLayer works, but it does break mouse interactions with deck.gl. I don't know of any other side effects of using the different panes.

This would be a relatively simple code change. The createDeckCanvas method in /modules/google-maps/src/utils.js currently selects the overlayLayer pane via const container = overlay.getPanes().overlayLayer; but if changed to const container = overlay.getPanes().markerLayer;, the native Google Maps heatmap can appear underneath deck.gl. Obviously, this change should be opt-in.

I understand this is a relatively rare use-case, but until deck.gl heatmaps support WebGL1 browsers I need to be able to reorder the maps layers.

To Do List

• Add label and assign to milestone
• Coding
• Doc update
• What’s new update
• Test

[benderlidze]

any updates on this?

[Pessimistress]

This sounds reasonable. You're welcome to open a PR.