fix(plateau): 編集の確定で判定を作り直し、1 つ受理しても残りを候補に残す

[nyampire]

直したこと

2 つの不具合を直しました。

1. 編集を確定しても重なりの判定が古いまま残る

すでに OSM にある建物を動かしても、重なっている Plateau の候補が消えたり現れたりしませんでした。
報告者はモードを往復させて、候補を作り直させていました。

重なりの判定の結果は PlateauService._plateauConflationCache に記憶されます。
この記憶を消していたのは merge の合図だけで、編集システムが新しい OSM のデータを取り込んだときにしか出ません。
編集が確定したときに出る stablechange を購読していませんでした。

stablechange を購読し、差分に建物が含まれるときだけ記憶を消すようにしました。

建物が含まれるかどうかは _differenceTouchesBuilding() で見ます。
difference.changes の変更前と変更後の地物を先に見ます。
建物の way を編集した場合、建物を作った場合、建物を消した場合、building タグを外した場合は、ここで片付きます。
残る「建物の node だけを動かした場合」のために、そのあと difference.complete() を見ます。親の way と relation を含むためです。

描画はこちらから要求していません。
MapSystem が stagingchange を受けて次の描画を予約し、その予約は stablechange の後で実行されるためです。
取り消しとやり直しも同じ経路を通ります。

2. 1 つ受理すると同じ relation の残りが消える

1 を入れた結果、type=building の relation のメンバーを「この地物だけを追加」で受理すると、その直後に残りが候補から消えるようになりました。

受理した地物は、Plateau 側と同じ id のまま OSM のグラフに入ります。
evalRelationOverlap は relation の判定を外形の重なりだけで決めるため、受理した建物と重なって relation ごと外れていました。

画面の文言は「外形とほかの部分は提案のまま残ります」と約束しています。
この規則自体は以前からありましたが、これまでは次にデータを取り込むまで残りが見えたままでした。

重なりの判定の材料に sourceID を持たせました。
relation を判定するときは、その relation 自身とメンバーの way から来た面を材料から外します。
外形の役割を持つメンバーが無い relation では、メンバーが 1 本ずつ判定されるため、その経路にも同じ集合を渡します。

relation に属さない候補の判定は変えていません。
別の建物として受理したものは、これまでどおり重複の判定に使われます。

守るべきもの

この食い違いは、約束が画面の文言にしか書かれていなかったために起きました。

重なりの判定と候補の表示について、守るべきものを 8 項目に並べました。
出どころと、それを固定する試験の名前を対で書いています。
出どころには画面の文言も含めました。

8 項目すべてに対応する試験がある状態にしました。
表に挙げた 14 件の名前が試験ファイルに 1 件ずつ存在することを、実装のあとに確かめています。

一覧は設計文書の「守るべきもの」の節にあります。

変えていないもの

merge の購読はそのまま残しています。
高さの転記の経路（skipConflation）と isAddBlocked の動きは変えていません。
Plateau 以外のデータセット（mapwithai、esri、overture）には触れていません。
上流のファイルには手を入れていません。

試験

npm run build && npm run dist && npm run test:browser で 805 件成功、5 件スキップ、失敗 0 件です。
起点の 28996a427 では 791 件成功、5 件スキップ、失敗 0 件でした。

足した 14 件の内訳です。

• 編集の確定で記憶を作り直す経路が 7 件
• 1 つ受理しても残りが残ることが 3 件（外形を受理した場合、parts を受理した場合、外形の無い relation の場合）
• 判定の下位の関数で、外す集合に入る面を飛ばすことが 1 件
• これまでの動きが変わっていないことの確認が 3 件（別の建物との重なり、relation に属さない候補、重なりの除去を止めている場合）

各段の 1 件目は、実装の前に失敗することを確認しています。
最後の 3 件は、いまの動きを固定するための試験で、実装は変えていません。

npm run lint は誤り 0 件、警告 42 件で、起点と同じ内容です。

未検証の事項

自動の試験はグラフを組み立てて呼ぶ形で、実際の操作は通っていません。
公開中のサイトへ反映する前に、parts のある建物で外形を受理し、残りが候補として残ることを画面で確かめます。

分かっている弱点

負の id の空間は、利用者が新しく引いた地物や、id を持たない他のデータセットの地物と共有されています。
負の連番が Plateau の id の範囲まで進み、かつ同じ表示範囲に建物として存在した場合に限り、無関係な面が材料から外れます。
そのときの結果は「すでに OSM にある建物の候補が 1 件余分に出る」で、被害は小さいものです。

relation の可否は毎回計算し直す一方、メンバーの way は記憶から返ります。
編集を挟まずに地図を動かして材料が変わると、両者が食い違いえます。
これは変更前からある性質で、今回の修正は記憶を消す機会を増やす方向なので、食い違いが起きる範囲はむしろ狭くなっています。

設計と計画

• docs/superpowers/specs/2026-09-10-plateau-conflation-cache-invalidation-design.ja.md
• docs/superpowers/plans/2026-09-10-plateau-conflation-cache-invalidation.md
• docs/superpowers/specs/2026-09-11-plateau-keep-relation-members-after-accept-design.ja.md
• docs/superpowers/plans/2026-09-11-plateau-keep-relation-members-after-accept.md

🤖 Generated with Claude Code