Repository navigation
Conversation
Composed rasters were appended at the end of the style, above the SDK's polygon/polyline/marker layers, so a RasterLayerState covered polygons, polylines and ground images. App rasters are now inserted before the first label or SDK overlay layer of the composed style, in zIndex order; marker tiles stay on top. TomTom's native Polygon/Polyline have no draw order and stack in add order; ground images, polygons and circle fills are all native Polygons and circle outlines are Polylines. When something is added to a lower band, the bands above it are cleared and added again so the order follows the bands. Stacking order (all providers, all platforms), bottom to top: raster layers < ground images < polygons < circles < polylines < markers. Needs android-sdk-core with OverlayStacking (fix/overlay-stacking-order).
This was referenced Nov 8, 2026
Open
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 系でサークルがポリゴンの下になる、など)。
何を変えたか
合成したラスターがスタイルの末尾、SDK のポリゴン・ポリライン・マーカーのレイヤーより上に足され、RasterLayerState がポリゴン・ポリライン・GroundImage を覆っていました。アプリのラスターは、合成したスタイルの最初のラベルか SDK のオーバーレイのレイヤーの前に、zIndex の順で入れます。マーカータイルは一番上のままです。TomTom のネイティブの Polygon/Polyline には描画順が無く、追加した順に積まれます(GroundImage・ポリゴン・サークルの塗りはすべてネイティブの Polygon、サークルの輪郭は Polyline)。下の帯に何かを足したときは、その上の帯を外して足し直すことで、帯の順に従わせます。
地図のラベルとの関係(今のまま)
今のままにしています。MapLibre・Mapbox・Mappls・Longdo はラスターをベースマップの最初のラベルの下、ほかのオーバーレイはラベルの上です。Mapbox Standard はベースマップが import なので POI などのラベルは図形の上に出ます。Google はラベルを図形の上に描きます。MapTiler はベースマップのレイヤー一覧が取れないので、ラスターもラベルの上です(制約)。
検証
2026-11-08 に develop(fix/mapview-teardown、fix/geodesic-polygon-fill、fix/clear-followups、refactor/polygon-controller などのマージ後)の上に載せ直してから確かめています。
OverlayStackingTestを含む。落ちたのは develop でも落ちる 2 つだけ)。apiCheck: この PR の.apiの差分は追加のみ。*OverlayStackingを通っています。stacking の外でaddLayer*を呼ぶ箇所はありません)。fix/clear-strategy+ この PR 一式 + MapTiler の restore を合わせた APK)で、普通に追加・逆の順・clearOverlays → 送り直し・デザイン変更 を撮り直しました。確認できていないもの
.apiの取り残し)。関連 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)を入れてください。