Repository navigation
Conversation
Overlays removed from a MapTiler map - a polygon, circle, raster layer, ground image or polyline taken out of the composition, or everything after clearOverlays() - did not come back when added again with the same id. MTStyle remembers every source and layer it added, by id, and refuses to add the same id again (SourceAlreadyExists / LayerAlreadyExists, which the renderers caught and logged). removeSourceById / removeLayerById only remove them from the page and leave that record behind; removeSource / removeLayer clear it too. Remove by object everywhere the renderers take a source or layer out, falling back to the id when MTStyle has no record of it (its add records asynchronously). The same applies to the background layer the vector-style mutation target adds and removes. A raster layer whose source changes is removed and re-added under the same ids, so that path was broken too. MapTilerStyleRemovalTest drives a real MTStyle through a recording command executor: removing by id leaves the id recorded; removing by object lets the same id be added again.
MTStyle.addLayer has no beforeId and always appends, so overlays were stacked in add order, and after a style reload in the reapply order (raster, polyline, polygon, circle, ground image). MapTilerOverlayStacking keeps the SDK layers' order per style and moves each new layer below the lowest SDK layer with a higher key. Reapply now runs in band order after resetting the record. The SDK cannot list the basemap's layers, so rasters sit above the basemap including its labels. MTStyle.addLayer does not reach the page right away: for anything but an image source it first waits for an isSourceLoaded round trip, and if the source is not loaded yet it holds the layer until the next idle. A moveLayer sent right after addLayer then arrives before the layer and does nothing (adding in reverse order left the raster on top, and a zIndex 0 polygon above a zIndex 1 one). So after an add, the recorded order is sent again on the next two idle events (onIdle, from onEventTriggered; launched once on the main dispatcher so it lands after the SDK flushes its queue). 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
Add OverlayStacking: one bottom-to-top order for every overlay kind
MapConductor/android-sdk-core#31
Open
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 系でサークルがポリゴンの下になる、など）。
何を変えたか
MTStyle.addLayerには beforeId が無く常に末尾に足すので、追加した順に積まれ、スタイルの読み直し後は reapply の順（ラスター・ポリライン・ポリゴン・サークル・GroundImage）でした。MapTilerOverlayStackingがスタイルごとに SDK のレイヤーの順を持ち、新しいレイヤーを鍵がより大きい SDK のレイヤーのうち一番下のものの下へmoveLayerします。reapply は記録を消してから帯の順に流します。SDK からベースマップのレイヤー一覧が取れないので、ラスターはベースマップ（ラベルを含む）の上になります。この PR は
fix/maptiler-overlay-restore（MTStyle の id の記録を消して外す）の上に載せています。 両方が 5 つのレンダラの削除処理を書き換えたためで、restore 側のremoveLayerAndForget/removeSourceAndForgetを残し、その前にMapTilerOverlayStacking.remove(...)を呼ぶ形にまとめました。restore の PR を先にマージしてください（この PR の差分には restore の commit も含まれて見えます）。載せ直しで直したもの: 実機で、逆の順に足すとラスターが一番上に残り、zIndex 0 のポリゴンが zIndex 1 の上に来ていました（載せ直す前の撮影は WebView の描き直しが止まった古い画面で、確かめられていませんでした）。
MTStyle.addLayerはすぐにはページへ届かず（画像ソース以外はisSourceLoadedの往復を待ち、ソースが読み込み前なら次の idle まで SDK の中で待つ）、直後のmoveLayerが層より先に届いて何もしていなかったためです。足したあとの idle 2 回分、記録した並びをmoveLayerで送り直すMapTilerOverlayStacking.onIdle()を足し、MapTilerMapViewの ON_IDLE から（1 度メインへ戻してから）呼びます。直した後は実機で 4 場面とも帯の順でした。地図のラベルとの関係（今のまま）
今のままにしています。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 #17）を入れてください。