Table of Contents

multi-map 使用ガイドとベストプラクティス

Mega アプリケーション開発では、1 つの localization library に複数の map（Block）を追加すべきかどうかがよく問題になります。multi-map を誤って使用してもアプリケーション能力は向上せず、むしろパフォーマンス低下や positioning jump を引き起こす可能性があります。

本ガイドでは、multi-map 機能を正しく理解して使用し、よくある誤解を避けられるようにします。

なぜ複数の map 追加を避ける必要があるのか？

核心原則: 「カバレッジ拡大」のために複数の map を追加しないでください。

ほとんどの場合、1 つの localization library には、1 つの地点の Mega Block map を 1 つだけ追加するべきです。以下はよくある誤った使い方であり、必ず避けてください。

  • 誤ったシナリオ A: multi-region

    • 考え方: 観光地内で互いにつながっている「A エリア」「B エリア」「C エリア」それぞれに map を作成し、アプリケーションでこの 3 つの map を一度に library に追加して、ユーザーが観光地内を移動するときにシームレスに切り替えられることを期待する。
    • 問題: このように作成された 3 つの map は、空間座標上の数学的関連を持たず、互いに独立しています。それぞれの coordinate system が一致しないため、移動中の seamless switching は実現できず、エリア境界で positioning jump が発生します。
    • 解決: このようなシナリオでは、超大規模空間データ収集方法 に従って「A エリア」「B エリア」「C エリア」を収集し、互いに十分な overlap があることを保証するのが最適です。超大範囲 fusion task に従って map construction を行います。このとき、上記すべてのエリアを含む統一 coordinate system の single Block map が生成され、この map を localization library に追加できます。

  • 誤ったシナリオ B: multi-location

    • 考え方: ある地点のショッピングモールに map を作成し、別地点の同名ショッピングモールにも map を作成して、1 つのアプリケーションで同時に使用したい。
    • 問題: これは positioning 速度を大幅に低下させます。positioning 時、デバイスは library 内のすべての map データを同時に照合する必要があり、計算量が急増して initialization 時間が長くなります。ユーザーは同時に 1 つのショッピングモールにしか存在できないため、別のショッピングモールの map をロードするのは resource の無駄です。あるショッピングモールの request 量が多い場合、別のショッピングモールの request 応答時間も遅くなります。
    • 解決: 異なる地点のショッピングモールには異なる localization library を作成し、各 library には 1 つの map だけを追加します。アプリケーション内では、ユーザーの現在位置に基づいて対応する localization library に 動的にアクセス します。

  • 誤ったシナリオ C: cross-time

    • 考え方: 同じ地点で昼に収集して map construction を行い、夜にも収集して map construction を行い、昼と夜の map を library に追加して、同じ地点の異なる時刻で一貫した体験を得たい。
    • 問題: このシナリオは誤ったシナリオ A と似ており、別々の map construction 結果間で空間位置関係を保証できません。
    • 解決: 超大範囲 fusion task に従って、昼と夜の収集を合わせて fusion map construction を行います。最終的に生成された single Block map を localization library に追加します。

  • 誤ったシナリオ D: cross-version

    • 考え方: 同じ地点で既にバージョン A の map を作成して使用中で、後続の運用中により新しいバージョン B の map を作成して元の localization library に追加し、アプリケーションを再リリースせずに新しい map を使いたい。
    • 問題: 同じ地点の異なるバージョンの map であるため、positioning 時に結果が 2 つの異なるバージョンデータ間で jump する可能性があります。
    • 解決: lossless full update に従って旧バージョンの map construction を upgrade し、map データバージョンを更新しながら coordinate system を維持します。更新後の map を追加した後は、必ず localization library から旧バージョンの map を削除してください。

  • 誤ったシナリオ E: supplementary update

    • 考え方: 同じ地点で既にバージョン A の map を作成して使用中で、後続の運用中に局所エリアが変化したり、小範囲エリアの追加収集が必要になったため、新しい map B を作成して元の localization library に追加し、アプリケーションを再リリースせずに新しい map を使いたい。
    • 問題: 新しく収集した小区域 map B は元の map A と空間座標の関連がなく、新旧データの間に位置する体験では positioning jump が発生します。
    • 解決: supplementary update に従って旧バージョンの map construction に追加更新を行い、新しく収集した小区域が旧 map と同じ coordinate system を維持できるようにします。更新後の map を追加した後は、必ず localization library から旧バージョンの map を削除してください。

まとめ: 複数の小さな map をつなぎ合わせて大きな世界を作ろうとする方法は、Mega の高精度 map には適していません。Mega の設計思想は、空間的に連続し、座標が統一され、時空的に一貫した高精度 3D 表現です。

本当に multi-map が必要なシナリオ

では、どのような場合に 1 つの library に複数の map（Block）を追加する必要があるのでしょうか。主なシナリオは 「parallel tasks」 または 「multi-space selection」 であり、「spatial stitching」 ではありません。

  • シナリオ 1: multi-space selection

    • 説明: アプリケーションが同じ地点の複数の完全に異なるエリアを対象にしています。ただし建物構造や収集実務上の問題により、これらのエリアをデータ上で完全につなげられず、ユーザーが最初に自分のいるエリアを選択する必要がある場合があります。例えば、大規模病院の異なる階などです。
    • 実装: ユーザーがエリアを選択した後、この prior information を使って、その地点に対応する single map を 動的に有効化 します。同時点では、localization library 内で計算に参加する map は依然として 1 つだけです。ユーザーが新しいエリアへ移動したときは、エリア選択を再確認する必要があります。

  • シナリオ 2: parallel tasks

    • 説明: アプリケーションが、同じ地点に存在するが互いに関連せず、feature の差が非常に大きい 2 つ以上の独立した既知の object tracking タスクを同時に処理する必要がある場合です。例えば、博物館内の複数の展示品です。
    • 実装: このような高度なシナリオでは、各オブジェクトに独立した map を作成し、それらの「object map」を 1 つの localization library に追加できます。ただし、この場合の positioning performance は localization library に追加されたオブジェクト数に依存します。オブジェクト数が非常に多い場合、positioning performance と localization library 数の間でバランスを取る必要があり、オブジェクトを分類して複数の localization library を個別に作成できます。

multi-map 使用時の rendering 側の挙動

multi-map positioning を使用する場合、プラットフォームやバージョンによって 3D rendering の挙動が異なる点に注意してください。

ベストプラクティスの推奨事項

実際に 本当に multi-map が必要なシナリオ に該当する場合、または multi-map を使わざるを得ない場合は、以下の原則に従ってください。

  1. 必要に応じて有効化: ユーザーが選択したとき、または特定エリアに入ったとき、positioning request 送信時に対応する prior information を提供し、対応する 3D コンテンツのみをロードします。
  2. 動的切り替え: ユーザーが scene を選択できる明確な UI を提供します。新しい map に対応する 3D コンテンツをロードする前に、古い map に対応する 3D コンテンツを先にアンロードし、memory を解放します。
  3. State management: コード内で現在 active な map を明確に管理し、positioning 結果内の Block ID を監視して、異なる map の positioning feedback を区別します。
  4. Performance monitoring: multi-map 使用時は、デバイスの memory usage、positioning latency、消費電力に注意し、target device 上でアプリケーションがスムーズに動作することを確認します。

要するに、ほとんどのアプリケーションでは、「1 つの scene、1 つの map」の原則を守ることが、Mega positioning performance と安定性を保証する最良の選択です。