Repository navigation
Conversation
Google compares one zIndex across polylines, polygons, circles, ground overlays and tile layers. Each overlay passed its own zIndex through (all 0 by default; ground overlays and the marker tile layer never set one), so equal values fell back to add order: a re-sent ground image covered the polygons, a circle covered the polyline. The zIndex is now OverlayStacking.globalZIndex (ios-sdk-core): each band gets its own range, raster layers < ground images < polygons < circles < polylines < markers, the overlay's zIndex orders within the band. The marker tile layer is in the marker band. Markers are still drawn above every non-marker overlay by the SDK itself. Basemap labels stay above the overlays: Google draws its labels over polygons and the rest regardless (unchanged). Requires ios-sdk-core fix/overlay-stacking-order (OverlayStacking).
This was referenced Nov 8, 2026
Open
Open
Open
Open
Open
Open
Open
This was referenced Nov 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
なぜ
利用者の決定で、すべてのプロバイダ・3 プラットフォームで、オーバーレイを下から次の順に重ねます。
追加した順・送り直した順(clearOverlays の後など)・デザイン変更の後に左右されません。帯の中は zIndex、同じ zIndex なら渡された順です。
プロバイダごとに重なり順がばらばらでした(TomTom のラスターがポリゴンを覆う、送り直した GroundImage がポリゴンより上に来る、GL 系でサークルがポリゴンの下になる、など)。
何を変えたか
Google はポリライン・ポリゴン・サークル・GroundOverlay・タイルレイヤーを 1 つの zIndex で比べます。前は各オーバーレイの zIndex をそのまま渡していて(既定はすべて 0。GroundOverlay とマーカータイルは未設定)、同じ値は追加の順になり、送り直した GroundImage がポリゴンを覆い、サークルがポリラインを覆っていました。zIndex を
OverlayStacking.globalZIndexにしました。マーカータイルはマーカーの帯です。地図のラベルとの関係(今のまま)
今のままにしています。GL 系(MapLibre・Mapbox・Mappls・MapTiler)はラスターをベースマップの最初のラベルの下、他のオーバーレイはラベルの上です(MapTiler のラスターは、前はすべての上でしたが、他の GL 系に合わせてラベルの下に移りました)。Google はラベルを常にオーバーレイの上に描きます(変更なし)。MapKit だけは変わります: 帯の順を守るために全部を同じレベルに置く必要があり、ラスターと GroundImage が .aboveLabels から .aboveRoads(ラベルの下)へ移りました。ポリゴン・サークル・ポリラインは前からラベルの下です。逆に全部を .aboveLabels にすると、ポリゴン類がラベルの上へ移ります。今回は前者で、利用者の判断で承認済みです。
検証
2026-11-08 に develop(fix/mapview-teardown、fix/geodesic-polygon-fill、fix/clear-followups、refactor/polygon-controller などのマージ後)の上に載せ直してから確かめています。
OverlayStackingTestsは 720 通りの追加順。前の MapLibre の差し込み方に戻すと 4 件落ちます)。api-surface は変化なし(@_spi)。fix/clear-strategy+ この PR 一式を合わせたアプリが実機向けにビルドでき、iPad 実機で MapLibre / MapKit を撮り直しました。普通に追加・逆の順・clearOverlays → 送り直し・デザイン変更 のどれでも、下から ラスター < GroundImage < ポリゴン < サークル < ポリライン < マーカー でした。確認できていないもの
rasterKey(stateId:)でポリゴンの帯に入る用意だけしてあり、実物では確かめていません。関連 PR(
fix/overlay-stacking-orderの一式)マージの順番:
fix/clear-strategyの一式(先に入れる想定。衝突はしないことをgit merge-treeで確認済み)fix/maptiler-overlay-restoreの上に載せています(同じ削除処理を両方が書き換えたため)。先に restore の PR(Remove style layers and sources by object so they can come back android-for-maptiler#17)を入れてください。