Skip to content

Put app rasters under the SDK overlays; restack native shapes by band - #16

Open
wf9a5m75 wants to merge 1 commit into
developfrom
fix/overlay-stacking-order
Open

wf9a5m75 wants to merge 1 commit into
developfrom
fix/overlay-stacking-order

Conversation

@wf9a5m75

@wf9a5m75 wf9a5m75 commented Nov 8, 2026 •

Copy link
Copy Markdown
Contributor

なぜ

利用者の決定で、すべてのプロバイダ・3 プラットフォームで、オーバーレイを下から次の順に重ねます。

  1. ラスターレイヤー(RasterLayerState)
  2. GroundImage
  3. ポリゴン(ネイティブのポリゴンと、ポリゴンのタイルレイヤーが同じ帯)
  4. サークル
  5. ポリライン
  6. マーカー(ネイティブのマーカーと、マーカーのタイルレイヤーが同じ帯)

追加した順・送り直した順(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 などのマージ後)の上に載せ直してから確かめています。

  • 親ビルドと各 submodule の単体ビルドで、コンパイルと単体テストが通りました(OverlayStackingTest を含む。落ちたのは develop でも落ちる 2 つだけ)。apiCheck: この PR の .api の差分は追加のみ。
  • maplibre / mappls / mapbox は develop の refactor/polygon-controller を受けたので、載せ直す前の commit との range-diff を確かめました(差は名前の付け替えだけで、ポリゴンの z レイヤーの追加・削除は *OverlayStacking を通っています。stacking の外で addLayer* を呼ぶ箇所はありません)。
  • タブレット実機(develop + fix/clear-strategy + この PR 一式 + MapTiler の restore を合わせた APK)で、普通に追加・逆の順・clearOverlays → 送り直し・デザイン変更 を撮り直しました。
    • MapLibre・Mapbox・Mappls・MapTiler・Google・TomTom・Longdo: 下から ラスター < GroundImage < ポリゴン(z0 < z1)< サークル < ポリライン < マーカー。
    • HERE: ポリラインがポリゴン・サークルの下(制約)。ほかは帯の順。
    • OMM: 帯の中の zIndex が効かない(制約)。ほかは帯の順。
    • ArcGIS 2D: 順は正しい(GroundImage が出ない別件あり。別の担当が調査中)。

確認できていないもの

  • ArcGIS 3D: 実機で逆の順に足している途中にアプリが前面から消え、その後タブレットが adb から外れたため、原因を取れていません(載せ直す前は最後まで動いていました)。ArcGIS の 2 つの PR は、これを確かめるまで draft にしています。
  • Mappls・Longdo はデザイン変更の後に図形が消えます。develop でも直す前でも同じで、この PR とは無関係の既存の問題です。
  • apiCheck は arcgis / mapbox / maplibre / mappls / omm で、develop でも同じ内容で落ちます(develop の .api の取り残し)。
  • CI: プロバイダの CI は core の同名ブランチを clone して組むので、core 未マージでも通っています(初回の gradle ダウンロードのタイムアウトは再実行で解消)。

関連 PR(fix/overlay-stacking-order の一式)

マージの順番:

  1. fix/clear-strategy の一式(先に入れる想定。衝突はしないことを git merge-tree で確認済み)
  2. 各プラットフォームの core(android-sdk-core / ios-sdk-core / js-sdk-core)
  3. そのプラットフォームのプロバイダ(core の新しいヘルパーを使うので、core より先に入れるとビルドが通りません)
  • Android MapTiler は fix/maptiler-overlay-restore の上に載せています(同じ削除処理を両方が書き換えたため)。先に restore の PR(Remove style layers and sources by object so they can come back android-for-maptiler#17)を入れてください。
  • web はさらに js-sdk-core の npm 公開と、各 react-for-* の依存の引き上げが前提です(npm 公開はまだしない、という決定なので、web のプロバイダ PR はそれまで保留です)。

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant