Ability to render GroundOverlays on top of map content such as buildings
Is your feature request related to a problem? Please describe.
GroundOverlays always render below map content (specifically buildings that are enabled via isBuildingEnabled = true in MapProperties for instance) and there isn't any way to make GroundOverlays be rendered on top (i.e. their z index is always below everything else on the map).
Describe the solution you'd like Add an API that offers the ability to for GroundOverlays to be rendered above other map content, and especially for buildings as that is needed for my team's use case where we want buildings to be drawn below our GroundOverlay image.
Describe alternatives you've considered We tried working with the various shape APIs (Circle, Polygon, and Polyline) to see if any of those rendered above map content and found that none of those do either, though those also don't offer the same functionality we need which only GroundOverlay offers anyways.
Additional context Below you can see examples of how buildings are always rendered on top of GroundOverlay, Circle, and Polygon:
| GroundOverlay | Circle | Polygon |
|---|---|---|
If you would like to upvote the priority of this issue, please comment below or react on the original post above with :+1: so we can see what is popular when we triage.
@zalexbag Thank you for opening this issue. 🙏 Please check out these other resources that might help you get to a resolution in the meantime:
- Check the issue tracker - bugs and feature requests for Google Maps Platform APIs and SDKs
- Open a support case - Get 1:1 support in Cloud Console.
- Discord - chat with other developers
- StackOverflow - use the
google-mapstag
This is an automated message, feel free to ignore.
Have you tried specifying the zIndex in the GroundOverlay function to be higher than 0f(the default)?
@lucanicoletti yes I did test changing the zIndex to a few different non-zero values including Float.MAX_VALUE and buildings still render on top of the GroundOverlay.
Oh and one other point of context to add to that, in the Maps Android SDK documentation for Shapes in the Z-index section they state the following:
The z-index specifies the stack order of this shape, relative to other overlays (other shapes, ground overlays and tile overlays) on the map. An overlay with a high z-index is drawn above overlays with lower z-indexes. Two overlays with the same z-index are drawn in an arbitrary order.
Note that markers are always drawn above other overlays, regardless of the z-index of the other overlays.
This is referring to shapes, but I would infer the behavior is the same for other overlay types and in this case for GroundOverlay. So the way I see it, the zIndex is meant to layer with regards to other overlays but has no effect when non-overlay elements are displayed like buildings or (as they mentioned) map markers.
@zalexbag did you find some solution?
@Hugo-Persson no, I did not find a solution yet 🫤 .
Reporting back here just to mention one other important point that I forgot to mention originally, this behavior does not align with Google Maps behavior on iOS and Web. Both of those platforms show the overlay on top of 3D buildings. So to make sure there is feature parity across all platforms, this issue should be prioritized for Android.
@zalexbag I'm having the same issue on Android. Did you manage to find a workaround for it?
Update-1: I wasn't expecting this but it worked by setting zIndex to a huge value of 100000.
Update-2: It had worked but not working now when I ran the app again. And, can not make it work again. Wow :).
Update-3: After many tests, unbelievably, circles (possible other shapes too) are sometimes behind the buildings layer and sometimes on top of them. How can this be? Not sure.. Maybe there is a discrepancy with the responses of Google Maps servers and the result differs according to which maps server is responding.
Hey @umutm , no I haven't found a workaround. This issue has been put on the back burner for my team until Google is able to release a fix. That's very interesting that you managed to get it to work temporarily. There must be some kind of discrepancy as you suggest. I'll be interested to hear if you manage to find a workaround!