Repository navigation
Hold ground image removals until the style can be edited; drop the clear() overrides - #16
Merged
Merged
Conversation
They redrew after super.clear() because js-sdk-core's clear() called onPostProcess before emptying the manager (polyline) or not at all (circle), so this provider's redraw-from-manager renderer kept drawing what clear() removed. js-sdk-core now runs onRemove, manager.clear(), onPostProcess, which redraws an empty layer. clear() is still there, inherited from the core controller with the same signature; the API snapshot only stops listing the override. Requires the js-sdk-core release with that change (MapConductor/js-sdk-core fix/overlay-clear-order). Against an older core, clearOverlays() leaves polylines and circles drawn until something else redraws them.
removeGroundImage returned early while canEditStyle() was false, and the controller had already forgotten the state, so the image stayed on the map for good. canEditStyle follows isStyleLoaded(), which turns false right after other overlays rewrite their sources; clearOverlays() clears those first, so the ground image survived every clearOverlays(). The renderer now keeps such removals and applies them from the controller's resync(), which runs when the style becomes editable again. Adding the same id again before then cancels the held removal. GroundImageRemoval.test.mjs covers both.
This was referenced Nov 8, 2026
Clear overlays in the order remove, empty the manager, then post-process
MapConductor/js-sdk-core#26
Merged
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.
なぜ
clearOverlays()の後も、この地図では GroundImage が残っていました。またポリライン・サークルは、js-sdk-core のclear()の呼び順の問題を、このプロバイダ側のclear()の上書きで回避していました。GroundImage が残る（2 つ目のコミット）
GroundImage のコントローラは core を継承しない独自のもので、
renderer.removeGroundImageはcanEditStyle()が false のとき何もせずに戻っていました。一方でコントローラは削除を頼んだ時点で state を忘れるので、その画像は二度と消されません。canEditStyle()はstyledataでisStyleLoaded()を見て切り替わります。他のオーバーレイがソースを書き換えた直後はisStyleLoaded()が一瞬 false になるので、ポリライン・サークル等を先に消すclearOverlays()では毎回これに当たっていました。調べる途中で分かったこと（この PR では直していません）: 検証用のページでは、
styleReadyが約 0.3 秒ごとに true / false を往復し続けていました。styledata（loaded=false）→idle→resyncAll()→ 各コントローラの再同期がまたstyledataを起こす、の繰り返しで、描画中のどの時点でもcanEditStyle()が false の可能性があります。6 種類の再同期を 1 つずつ止めても往復は続き、全部止めると止まりました（複数の再同期がそれぞれstyledataを起こしています）。別の問題として扱うべきだと思います。clear() の上書きを消す（1 つ目のコミット）
js-sdk-core の
clear()が「onRemove → manager.clear() → onPostProcess」の順になった（js-sdk-core の同じ PR）ので、ポリライン・サークルのclear()の上書き（super.clear()の後に描き直す）を消しました。clear()は core から同じシグネチャで継承されるので、公開 API の実体は変わりません（API スナップショットから上書き分の行が消えるだけです）。このコミットは js-sdk-core の新しい版の公開と、依存（今は
^0.3.1）の引き上げが前提です。 依存を上げるコミットはこの PR に入れていません。js-sdk-core を公開した後で、その版に上げてからマージしてください。古い core のままこのコミットを入れた場合: 前の担当の確認（古い core で上書きだけを消したビルド）では、ラスターレイヤーが無い画面だと、
clearOverlays()の後もポリライン・サークルが残るはずです（ラスターがあると、その再描画のついでに消えるので見た目では分かりにくい）。何を変えたか
LongdoGroundImageOverlayRenderer: スタイルを編集できない間に来た削除をpendingRemovalsに残し、flushPendingRemovals()（@internal）で反映します。同じ id がその前に追加し直されたら、残していた削除は取り消します。LongdoGroundImageController.resync(): 最初にflushPendingRemovals()を呼びます。resync()はスタイルが編集できるようになった（styleReady が false → true になった）ときに呼ばれます。test/GroundImageRemoval.test.mjsを足しました（修正前は 1 本目が失敗）。clear()の上書きを消しました（上記）。clear()の 2 行が消えただけです。関連 PR（同じ修正の一式）
fix/overlay-clear-orderは次の 21 リポジトリにまたがります。1. core（3 本は互いに独立。先にマージ・公開してください）
2. Android プロバイダ（core が無くても単独で効く修正。ただしポリライン・ポリゴン・GroundImage・ラスターの消え残りは core 側で直るので、core と合わせて初めて clearOverlays() が全部消えます）
3. iOS プロバイダ（ios-sdk-core のマージ・公開の後。
clearOverlays()からコントローラのclear()を呼ぶ変更は、core の呼び順の修正が無いと GL 系で描き直しが起きて消えません）4. web プロバイダ（js-sdk-core の新しい版を npm に公開し、依存（今は
^0.3.1）を引き上げてから。理由は各 PR の本文に）マージの順番: core 3 本 → core の公開 → Android / iOS プロバイダ → js-sdk-core の npm 公開と依存の引き上げ → web プロバイダ。
検証
npm test（新しいテストを含めてすべて通過）、tsc --noEmit、npm run build。node scripts/api-surface.mjs check（react-sdk）: 上記以外の差分なし。getLayer('mc-gimg-lyr-GI')が無い）を確かめました。refactor/polygon-controllerの OPEN な PR とはgit merge-treeで衝突しないことを確かめました。実機・ブラウザでの確認（共通の手順）
同じ手順で、ポリゴン・ポリライン・サークル・GroundImage・ラスター・マーカーを出し、追加 → 更新（色・半径・不透明度）→ 一部削除（ポリゴン・サークル・ラスター）→ 戻す →
clearOverlays()→ clear 後に同じ state を in-place で書き換え → 同じ id・同じ内容の state を作り直して送り直す、の 7 段階をスクリーンショットで比べました。検証用のページはコミットしていません。追加・更新・削除・戻すの 4 段階の見た目は修正前と同じでした。clear 後の振る舞い（in-place の更新では戻らず、顔ぶれが変わるか作り直された state が来たら全部描き直す）は、3 プラットフォームの core の collector と同じです。
確認できていないもの
setStyleの最中）は、単体テストの「スタイルを編集できない間の削除」で代わりに確かめただけで、ブラウザでは試していません。