点群OBJを更新しても古いデータが表示されるのはなぜか
点群から作成したOBJファイルをアップロードし直したにもかかわらず、閲覧画面には更新前の形状や色が表示されることがあります。修正したはずの箇所が変わっていない、削除した点や面が残っている、テクスチャだけが古いといった現象が起きると、アップロードそのものに失敗したように見えます。
しかし、実際には新しいOBJファイルの保存が完了しており、閲覧画面やデータ配信経路に残ったキャッシュが古い内容を返している場合があります。キャッシュとは、一度取得したデータを端末やサーバーなどへ一時的に保存し、次回以降の表示を高速化する仕組みです。容量が大きくなりやすい点群や3Dモデルでは、毎回すべてのデータを取得し直すと表示開始までに時間がかかるため、キャッシュは重要な役割を持っています。
一方で、更新前と更新後のファイルが同じ名前、同じURL、同じ管理番号で扱われると、閲覧側が変更を正しく認識できないことがあります。保存済みのデータをまだ利用できると判断されれば、サーバー上に新しいファイルが存在していても、旧データが画面へ表示されます。
点群OBJアップロード後に関係するキャッシュは、ブラウザ内の一時保存だけではありません。閲覧中の画面が保持しているメモリ、3D表示機能が独自に保存するローカルデータ、公開サーバーの一時保存、中継サーバーのキャッシュ、表示用データの変換結果、サムネイルなど、複数の場所に古い情報が残る可能性があります。
そのため、画面を再読み込みしても直らないからといって、必ずしもアップロードが失敗しているとは限りません。通常の再読み込みでは、保存済みデータが有効かどうかを確認したうえで再利用することがあります。更新の判定情報が適切に変わっていなければ、再読み込み後も旧版が表示され続けます。
また、OBJ形式では形状情報を記録するOBJファイルのほかに、材質設定を記録するMTLファイルや、色や模様を表現するテクスチャ画像を組み合わせることがあります。OBJファイルだけを新しくしても、MTLファイルやテクスチャ画像が旧版のままであれば、形状は更新されたのに見た目だけが古い状態になります。
アップロード後に軽量化、分割、座標変換、索引作成などを行う仕組みでは、元のOBJファイルと閲覧用データが別々に管理されます。この構成では、OBJの保存が完了しても、閲覧用データが再生成されていなければ古い表示が続きます。利用者からはキャッシュのように見えますが、原因は変換済みデータの更新漏れです。
古いデータが表示される問題を解決するには、ブラウザの保存データを削除するだけでなく、ファイルの識別方法、通信時のキャッシュ設定、配信経路、変換処理、関連ファイル、閲覧端末という複数の観点から確認する必要があります。
キャッシュ問題を調べる前に確認したい基本事項
キャッシュ対策を始める前に、まずアップロードしたファイルが本当に最新版であることを確認します。キャッシュ問題と、古いファイルを誤って再アップロードした問題は、画面上ではほぼ同じ症状になります。何度キャッシュを削除しても表示が変わらない場合、元のアップロード対象が更新前のファイルだった可能性があります。
ファイル名だけで新旧を判断するのは危険です。同じ作業フォルダー内に似た名前のOBJが複数ある場合や、書き出し先が別のフォルダーになっている場合、修正前のデータを選択してしまうことがあります。アップロード前には、更新日時、ファイル容量、頂点数、面数、対象範囲などを確認します。
修正箇所が小さい場合は、見た目だけで新版かどうかを判断しにくくなります。確認用として、一時的に分かりやすい変更を加えたテストデータを使う方法もあります。明確な形状差や識別用の変更が画面に反映されれば、配信経路全体が新版へ切り替わったことを確認しやすくなります。
アップロードされたファイルを再取得できる仕組みがある場合は、サーバー上のファイルと手元の最新版を比較します。ファイル容量が一致するか、内容から算出した識別値が一致するかを確認すれば、アップロード段階の問題か、表示段階の問題かを切り分けられます。
次に、古いデータがどの範囲で表示されているかを確認します。特定の端末だけで旧版が表示されるのか、複数の端末で同じ旧版が表示されるのかによって、原因の可能性が変わります。ある端末だけで発生する場合は、端末側の保存データや画面内のメモリが疑われます。すべての端末で発生する場合は、公開サーバー、変換済みデータ、配信経路などを優先して確認します。
どの部分が古いかも重要です。形状全体が旧版なのか、色だけが古いのか、一覧画面のサムネイルだけが古いのか、計測結果だけが古いのかを分けて考えます。形状が古ければOBJ本体や閲覧用変換データ、色だけが古ければMTLやテクスチャ画像、サムネイルだけが古ければ画像生成処理が原因である可能性があります。
さらに、アップロード完了と公開完了が同じ意味で使われていないか確認します。サーバーへ元ファイルが保存された時点でアップロード完了と表示されても、閲覧用データの生成がまだ終わっていないことがあります。処理中に閲覧画面を開くと、公開中の旧データが一時的に表示される場合があります。
このような基本事項を先に確認しておけば、不要なキャッシュ削除や再アップロードを繰り返さずに済みます。原因を特定しないまま同じファイルを何度も上書きすると、処理ジョブや保存データの世代が増え、かえって状況を把握しにくくなるため注意が必要です。
キャッシュ対策1 ファイル名とURLに更新識別子を付ける
点群OBJアップロード後に旧データを表示させないための基本的な対策は、更新版を以前のファイルとは異なるデータとして認識させることです。同じファイル名へ上書きするのではなく、更新日時、版番号、処理番号、内容から算出した識別値などをファイル名やURLへ含めます。
閲覧側では、一般にURLを基準としてキャッシュが管理されます。ファイルの中身が変わっていてもURLが同じであれば、保存済みデータを再利用できると判断される可能性があります。反対に、URLが変われば、まだ取得していない新しいデータとして扱われやすくなります。
たとえば、第1版と第2版を同じ名称へ上書きするのではなく、データの世代を識別できる名称に変更します。ただし、「最新」「修正版」「最終版」といった曖昧な名称だけでは、時間が経過したときにどれが新しいのか判断できません。「最終版の修正版」や「最新2」のような名称が増えると、誤ったファイルを選ぶ原因になります。
実務では、対象現場、取得日、処理段階、版番号などを一定の順序で組み合わせる命名規則が有効です。ファイル名を見ただけで、どの案件の何番目の版なのかを判断できれば、アップロード時の選択ミスも減らせます。
更新識別子はOBJファイルだけでなく、MTLファイルやテクスチャ画像にも付けます。OBJが第3版、MTLが第2版、テクスチャが第1版という状態になると、関連ファイルの世代が一致しません。ファイル群全体を一つの公開単位として扱い、同じ版番号を共有させることが重要です。
ファイル名を変更した場合は、内部の参照記述も更新しなければなりません。OBJファイルからMTLファイルを参照している場合、OBJ内の記述が旧名称のままだと、古いMTLを読み込む可能性があります。同様に、MTLファイル内のテクスチャ画像名も、新しいファイル名と一致させます。
サーバー上の実体ファイル名を変更できない場合は、URLへ更新識別子を加える方法があります。URLの末尾に版番号や更新値を付けることで、閲覧側へ異なるアクセス先として認識させます。ただし、配信設定によっては末尾の追加情報を無視し、同じキャッシュとして扱うことがあります。導入前に、実際の配信環境で別データとして認識されるか確認が必要です。
ファイル内容から識別値を生成する方式では、中身が変わった場合にだけURLが変わります。変更がなければ保存済みデータを再利用し、変更があれば新しいデータを取得できます。容量が大きい点群OBJでは、不要な再取得を抑えながら更新を確実に反映させやすい方法です。
更新版を別URLで公開する方式には、旧版へ戻しやすいという利点もあります。新版に問題が見つかった場合、旧版のURLを残したまま参照先だけを戻せます。同じURLへ上書きする運用では、旧版を復元するために再アップロードが必要になることがあります。
点群OBJを複数の担当者や取引先が閲覧する場合、利用者一人ひとりへキャッシュ削除を依頼する方法は安定しません。更新のたびにURLが変わる仕組みにしておけば、利用者の端末操作に依存せず、新版へ切り替えやすくなります。
キャッシュ対策2 キャッシュ制御と再検証の設定を見直す
同じURLを維持する必要がある場合は、データ配信時のキャッシュ制御を見直します。キャッシュ制御では、保存を許可する期間、利用前に更新確認が必要か、端末だけで保存するか、中継経路でも保存するかなどを指定できます。
点群OBJは容量が大きいため、アクセスのたびに全ファイルを取得し直す設定では、表示時間や通信量が増えます。そのため、キャッシュを全面的に禁止するよりも、保存済みデータを使う前にサーバーへ更新の有無を確認する再検証を利用する方法が現実的です。
再検証では、サーバーがファイルの状態を示す情報を返します。閲覧側は、以前取得したデータの識別情報や更新日時をサーバーへ送り、ファイルが変わっているかを確認します。変更がなければ保存済みデータを利用し、変更があれば新しいファイルを取得します。
この方式であれば、更新されていない大容量ファイルを何度も転送せずに済みます。一方、同じURLへ新版を上書きした場合は、新しい内容へ切り替えられます。ただし、更新判定に使う情報が正しく変化していることが前提です。
アップロード後も同じ識別情報が返され続ける設定や、ファイルを差し替えても更新日時が変わらない処理では、再検証が正しく働きません。サーバー上の内容が新しくなっていても、閲覧側は変更なしと判断します。ファイル更新時に識別情報も更新されているかを確認する必要があります。
保存期間の設定も重要です。作業中で頻繁に更新される点群OBJに長い保存期間を設定すると、修正が反映されにくくなります。一方、公開後に変更しない確定データであれば、長期間保存して表示性能を優先できます。
作業中データと確定データを同じ方針で扱わないことが大切です。確認用の画面では毎回更新確認を行い、確定後の共有画面では版番号付きURLを使用して長く保存するなど、用途に応じて設定を分けます。
OBJ、MTL、テクスチャ画像のキャッシュ設定をそろえることも必要です。OBJだけが短期間で更新確認され、テクスチャ画像だけが長期間保存されると、形状は新版なのに色だけが旧版という状態になります。関連ファイルが同じ世代で表示されるように、保存期間と再検証の条件を設計します。
サムネイルや表示用変換データにも別の設定が適用されていることがあります。3D表示は更新されたのに一覧画面だけ古い場合は、サムネイルの保存期間が長すぎる可能性があります。画面を構成する各データのキャッシュ設定を個別に確認します。
設定変更後の試験では、初回表示だけを確認しても十分ではありません。キャッシュが存在しない初回表示では、必ずサーバーから新しいデータが取得されるためです。まず旧版を表示して保存させ、その後同じURLへ新版をアップロードし、意図したタイミングで表示が切り替わるかを試します。
点群OBJアップロードの運用では、表示速度と更新の確実性を両立する必要があります。すべてを保存禁止にすれば更新問題は減らせますが、閲覧のたびに大量の通信が発生します。版番号付きURLと再検証を適切に組み合わせることで、必要な性能を維持しながら旧データの表示を防ぎやすくなります。
キャッシュ対策3 配信経路に残る古いデータを無効化する
アップロードされた点群OBJが利用者の端末へ届くまでには、複数の配信設備を通過することがあります。元ファイルを保管する領域、公開用サーバー、通信を中継する設備、負荷を分散する仕組みなどです。それぞれにキャッシュが存在すると、元ファイルだけを更新しても途中に残った旧コピーが返されることがあります。
この場合、閲覧端末の保存データを削除しても改善しません。端末は新たな取得要求を送っていますが、配信経路上の設備が古いファイルを返しているためです。複数の端末や利用者で同じ旧版が表示される場合は、端末側よりも配信側を優先して確認します。
配信キャッシュを利用している環境では、ファイル更新後に対象キャッシュを無効化する処理が必要です。OBJファイルだけでなく、関連するMTL、テクスチャ画像、変換済みデータ、サムネイルなども対象に含めます。画面が取得するデータのうち一つでも旧版が残れば、部分的に古い表示になる可能性があります。
削除対象をファイル名だけで判断すると、別のURL表現で保存されたキャッシュを見落とすことがあります。同じデータでも、URL末尾の記号、更新識別子の有無、大文字と小文字、圧縮状態などによって、別々のキャッシュとして管理される場合があります。
実際に閲覧画面が要求しているURLを確認し、そのURLに対応するキャッシュを無効化することが重要です。管理画面上の保存先と、利用者がアクセスしている公開URLが異なる構成では、元ファイルの場所だけを確認しても原因を特定できません。
配信拠点が複数ある場合、無効化の反映に時間差が出ることがあります。ある利用者には新版が表示され、別の利用者には旧版が表示されるときは、接続先となる配信拠点の違いが考えられます。同じ端末でも、時間帯や通信経路によって結果が変わる可能性があります。
無効化処理を実行した後は、処理完了の表示だけで判断しないようにします。実際に取得されたファイルの容量、更新日時、版番号などを確認し、新版へ切り替わったことを検証します。見た目の差が小さい場合は、確認用の識別情報を画面上へ表示する方法が有効です。
アップロードのたびに担当者が手動でキャッシュを削除する運用では、実施忘れが起こりやすくなります。可能であれば、アップロード完了、変換完了、公開切り替えなどの処理とキャッシュ無効化を連動させます。作業者が誰であっても同じ順序で実行される仕組みにすれば、更新漏れを減らせます。
ただし、広い範囲のキャッシュを毎回すべて削除すると、変更していない点群データまで再取得が必要になります。通信負荷や表示性能へ影響するため、案件、現場、データ版ごとにURLや保存場所を分け、更新対象だけを限定して無効化できる設計が望ましいです。
公開中のURLを直接上書きするのではなく、新しい保存先へ新版を登録し、検証後に参照先を切り替える方法も有効です。新旧データが別々のURLで存在するため、途中のキャッシュに影響されにくく、問題があれば旧版へ戻しやすくなります。
キャッシュ対策4 変換済みデータと処理ジョブを世代管理する
点群OBJアップロード後に古いデータが表示される原因は、通信キャッシュだけとは限りません。アップロードされたOBJをそのまま表示せず、閲覧用に軽量化、分割、圧縮、座標変換、索引作成などを行う仕組みでは、元ファイルと画面表示用データが別々に存在します。
元のOBJファイルを上書きしても、変換処理が再実行されなければ、閲覧画面では以前の変換結果が使用されます。利用者から見るとキャッシュが残っているように見えますが、実際にはサーバー側に保存された旧変換データが公開されています。
また、過去の処理結果を再利用する仕組みがある場合、更新されたファイルを旧版と同じデータだと誤判定することがあります。ファイル名や容量だけで同一性を判断していると、内容が変わっていても以前の変換結果が使われる可能性があります。
対策として、元データと変換処理に共通の世代番号を付けます。OBJ、MTL、テクスチャ、変換結果、サムネイル、公開状態を同じ世代へひも付け、画面には同一世代のデータだけを表示させます。
元OBJが第5版で、表示用データが第4版の状態であれば、旧版をそのまま表示するのではなく、変換中または更新待ちとして扱うほうが安全です。利用者が旧データを最新版と誤認することを防げます。
アップロード完了と変換完了を区別することも重要です。元ファイルの保存が終わった時点では、閲覧用データの準備ができていない場合があります。画面上で単に「完了」と表示すると、利用者はすぐに新版を確認できると考えます。
処理状態は、元ファイル受け付け、関連ファイル確認、変換中、検証中、公開完了など、実際の段階に応じて示す必要があります。少なくとも、アップロード完了と閲覧可能状態を明確に分けます。
安全な公開手順では、まず新版の元ファイルを保存し、関連ファイルの不足や参照エラーを検査します。その後、表示用データを生成し、形状、色、座標、対象範囲などを確認してから、公開先を新版へ切り替えます。公開中の旧版は、新版の準備が整うまで維持します。
処理ジョブが失敗したときの扱いも決めておく必要があります。通信切断、容量不足、処理時間超過、参照ファイル不足などにより、変換が完了しない場合があります。元ファイルだけが新版で、表示用データが旧版という状態を防ぐため、失敗時は公開を切り替えない制御が必要です。
同じファイル名で再アップロードを繰り返すと、複数の変換ジョブが同時に動くことがあります。処理時間の長い旧ジョブが、新しいジョブより後に完了し、公開先を旧結果で上書きする可能性もあります。
各ジョブに世代番号を付け、最新世代以外の結果を公開先へ反映しないようにします。旧ジョブが後から完了しても、その結果を保存するだけにとどめ、最新版として公開しない制御が必要です。
サムネイル生成も同じ世代管理へ含めます。3D画面は新版なのに一覧画面だけ旧版という状態は、サムネイルが再生成されていないときに起こります。サムネイルの生成時刻や元データの版番号を記録し、3D表示用データと一致させます。
座標変換や単位変換の設定も世代管理の対象です。形状データは更新されていても、変換条件が旧版であれば、位置や大きさが以前と同じに見えることがあります。元ファイルだけでなく、読み込み条件や変換設定も公開版の一部として扱います。
キャッシュ対策5 閲覧端末側の保存データを更新する
配信側と変換処理が正常でも、閲覧端末に古いデータが残っていることがあります。一般的なブラウザキャッシュに加えて、3D表示機能が保持するメモリ、ローカル保存領域、オフライン閲覧用データなどが原因になる場合があります。
最初に確認したいのは、対象画面を長時間開いたままにしていないかです。サーバー上では新版へ切り替わっていても、すでに開いている画面内には旧データが保持されています。自動更新の仕組みがなければ、画面を開き直すまで内容は変わりません。
同じ画面内で別データへ切り替えただけでは、3D表示機能が以前のデータをメモリへ残していることがあります。対象ページや閲覧画面を完全に閉じ、再度アクセスして確認します。
通常の再読み込みで改善しない場合は、保存済みファイルを利用せずに取得し直す更新操作を試します。通常の再読み込みでは、キャッシュがまだ有効かを確認し、問題がないと判断すれば保存済みデータを再利用することがあります。
対象サイトの保存データを削除する方法もあります。ただし、すべての閲覧履歴や保存情報を削除すると、ほかの業務画面からログアウトしたり、入力設定が失われたりする可能性があります。可能な限り、問題が起きている対象サイトのデータだけを削除します。
オフライン閲覧に対応した仕組みでは、通常のブラウザキャッシュとは別に点群データが保存されることがあります。通信状態が不安定な現場でも閲覧できる反面、更新確認が適切に行われなければ、古いデータを長期間表示し続けます。
オフライン保存されたデータには版番号や取得日時を持たせ、サーバー上の最新版と比較できるようにします。新版が存在する場合は、利用者へ更新を促し、更新前の状態であることを画面上に表示することが望ましいです。
端末側の問題か配信側の問題かを切り分けるには、別の端末や保存データのない閲覧環境で同じ公開先を開きます。別環境では新版が表示される場合、特定端末の保存データが原因である可能性が高くなります。別環境でも旧版が表示される場合は、配信側や変換処理を確認します。
同じ端末でも、別の通信経路を利用すると結果が変わる場合があります。その場合、端末内のキャッシュではなく、接続先となる中継設備に古いデータが残っている可能性があります。端末、通信環境、確認時刻、表示された版番号を記録すると、原因を追いやすくなります。
利用者が現在どの版を見ているか判断できるように、画面へ版番号、公開時刻、更新日時などを表示する方法も有効です。形状の見た目だけで新旧を判断する必要がなくなり、問い合わせを受けた際にも状況を正確に把握できます。
複数の現場端末で点群OBJを確認する場合は、更新時の操作手順を統一します。更新通知を受けたら画面を閉じる、対象データを開き直す、表示中の版番号を確認するという流れを決めておけば、端末ごとに異なる版が表示される混乱を抑えられます。
OBJとMTLとテクスチャの世代ずれにも注意する
点群OBJの表示が古いと感じたときは、OBJファイルだけでなく関連ファイルも確認する必要があります。OBJ形式では、形状情報と材質情報や画像情報が別々のファイルに保存される場合があります。
OBJファイル内には、使用するMTLファイルを指定する記述が含まれることがあります。OBJを新版へ更新しても、この参照先が旧MTLのままであれば、材質設定は以前の状態になります。
MTLファイルには、テクスチャ画像の参照先が記録されることがあります。MTLを更新しても、画像ファイル名が以前と同じでキャッシュが残っていれば、色や模様だけが古い状態になります。
形状は修正されているのに外観だけが変わらない場合は、OBJではなくMTLやテクスチャ画像のキャッシュを疑います。画像ファイルはOBJとは異なる保存期間が設定されていることがあり、同じ名前への上書きでは旧画像が残りやすくなります。
関連ファイルには同じ版番号を付け、一つのデータセットとして管理することが重要です。OBJ第4版、MTL第3版、画像第2版のような組み合わせを作らないようにします。
ファイル名を変更したときは、参照記述と実際のファイル名を完全に一致させます。大文字と小文字を区別する環境では、表記の違いだけで別ファイルとして扱われる場合があります。作業端末では問題なく表示できても、アップロード先では参照に失敗する可能性があります。
同じ保存場所へ旧版と新版を混在させる運用も避けたほうが安全です。参照に失敗した際、同名の旧ファイルが選択される可能性があります。公開用の保存先を世代ごとに分け、新版の関連ファイルだけが存在する状態で検証します。
圧縮ファイルへまとめてアップロードする場合は、展開後のフォルダー構造も確認します。OBJから見たMTLやテクスチャの相対位置が変わると、参照できません。参照エラー時に既存の旧ファイルが再利用される構成では、キャッシュ問題のような表示になります。
点群の色を頂点情報として持たせる場合も、表示側の対応状況を確認します。OBJの頂点色は利用する読み込み処理によって解釈が異なることがあり、変換設定が旧版のままだと、色の変更が反映されていないように見える可能性があります。
OBJ、MTL、テクスチャ、変換条件、サムネイルを一つの公開単位として管理すれば、部分的に古いデータが混ざる問題を減らせます。
表示される症状からキャッシュの場所を切り分ける
古いデータが表示されたときは、まず症状を具体的に分類します。何が古く、どこまで影響しているかを整理すれば、確認対象を絞り込めます。
形状全体が旧版の場合は、OBJ本体、表示用変換データ、配信キャッシュ、閲覧画面内のメモリを確認します。新版では頂点数や面数が大きく変わっている場合、実際に取得されたファイルの容量を比較すると判断しやすくなります。
形状は新版なのに色だけが古い場合は、MTLやテクスチャ画像を確認します。特にテクスチャ画像を同じ名称へ上書きした場合、画像だけが旧キャッシュから読み出される可能性があります。
一覧画面の画像だけが古い場合は、サムネイル生成処理や画像配信のキャッシュが疑われます。サムネイルがOBJアップロードとは別の処理で作成される構成では、元データの更新が自動的に反映されない場合があります。
計測値や属性情報だけが古い場合は、3D形状とは別に保存された解析結果や索引データを確認します。形状の変換は完了していても、計測用データの再生成が行われていない可能性があります。
特定の利用者だけが旧版を見る場合は、その端末のキャッシュ、ローカル保存、開いたままの画面を確認します。複数人が同じ旧版を見る場合は、公開サーバーや配信経路を優先して調べます。
利用者ごとに新旧が分かれる場合は、接続先となる配信拠点の違いや、更新反映の時間差も考えられます。確認した時刻と通信環境を記録し、一定時間後に再度比較します。
アップロード直後だけ旧版が表示され、しばらくすると新版になる場合は、変換処理やキャッシュ無効化に必要な時間が関係している可能性があります。この場合は、処理完了前に旧版が表示されているのか、複数拠点への反映が進行中なのかを確認します。
一部の修正箇所だけが変わらない場合は、キャッシュではなく元データの書き出し条件も確認します。修正したレイヤーや対象範囲が書き出し対象から外れていると、アップロードしたファイル自体に変更内容が含まれていません。
位置や縮尺だけが以前と同じ場合は、座標変換、単位、原点設定などが旧設定のまま残っている可能性があります。キャッシュ削除に進む前に、表示条件や変換条件も照合します。
原因の切り分けでは、元ファイル、アップロード済みファイル、変換済みデータ、配信データ、端末表示という順番で確認すると整理しやすくなります。どの段階から旧版になっているかを見つければ、必要な対策を限定できます。
点群OBJアップロード後の確認手順
点群OBJをアップロードする前には、対象ファイルが最新版であることを確認します。ファイル名だけではなく、更新日時、容量、頂点数、面数、対象範囲、座標、テクスチャの内容を照合します。
OBJがMTLやテクスチャ画像を参照している場合は、必要なファイルがすべてそろっていることを確認します。参照先の名称、文字の大文字と小文字、フォルダー構造も確認します。
アップロード用ファイルには、版番号や更新識別子を付けます。関連ファイルにも同じ識別子を使い、異なる世代のデータが混ざらないようにします。
アップロード開始後は、元ファイルの保存完了だけで作業を終えません。サーバー側で変換や軽量化が行われる場合は、処理状態が完了になるまで確認します。
処理が失敗した場合は、同じファイルをすぐに繰り返しアップロードするのではなく、失敗理由を確認します。参照ファイル不足、容量不足、形式不整合などが残ったままでは、再実行しても同じ結果になります。
変換完了後は、元ファイルと表示用データの版番号が一致していることを確認します。サムネイルや計測用データが別に生成される場合は、それらも同じ世代になっているか確認します。
公開前の確認画面がある場合は、形状、色、座標、向き、縮尺、表示範囲を確認します。修正箇所だけでなく、更新によって別の部分へ影響が出ていないかも確認します。
新版の検証が終わったら、公開先を切り替えます。必要に応じて、OBJ、MTL、テクスチャ、サムネイル、変換済みデータの配信キャッシュを無効化します。
公開後は、以前に旧版を表示したことがある端末で新版を開きます。保存データのない端末だけで確認すると、キャッシュがある状態で正しく更新されるかを検証できません。
通常の画面更新で新版へ切り替わるかを確認し、必要に応じて保存済みデータを利用しない再取得も試します。別の端末や別の通信環境でも表示結果を比較します。
画面に版番号や公開時刻が表示される場合は、見た目だけでなく識別情報を確認します。複数の確認者がいる場合は、全員が同じ版を表示しているかを共有します。
公開完了後は、作業者、アップロード時刻、元ファイル名、版番号、変換完了時刻、公開時刻、確認結果を履歴へ残します。問題が起きたときに、どの段階で旧版が混ざったかを追跡しやすくなります。
キャッシュ問題を再発させない運用設計
キャッシュ問題を根本的に減らすには、不具合が起きるたびに担当者が手動で削除するのではなく、アップロードから公開までの流れを標準化する必要があります。
まず、作業中データと公開データを分けます。作業中は上書きが便利な場合もありますが、複数人が閲覧する公開データでは、世代ごとに別の保存先を使うほうが安全です。
公開版は新しい場所へ登録し、検証が完了してから参照先を切り替えます。この方法であれば、利用者が変換途中のデータを見る可能性を抑えられます。新版に問題があった場合も、旧版へ参照先を戻せます。
OBJ、MTL、テクスチャ、座標設定、変換結果、サムネイルなどは、一つの公開単位として管理します。担当者がOBJだけを更新し、関連ファイルを更新し忘れる状態を防ぐ必要があります。
アップロード時に、必要ファイルの有無、内部参照、ファイル名、文字種、容量などを自動確認できると、人的ミスを減らせます。変換処理を開始する前に不整合を検出すれば、旧データとの混在も防ぎやすくなります。
版番号は画面上にも表示します。利用者が見ているデータの版を判断できれば、「更新されていない」という問い合わせに対して、実際に旧版なのか、見た目の差が小さいだけなのかを確認できます。
更新履歴には、アップロードした担当者、日時、元ファイル、変換条件、公開した版、主な変更内容を記録します。「最新版」という名称だけに頼らず、番号や日時で追跡できるようにします。
キャッシュ無効化は公開処理へ組み込みます。担当者が別画面で手作業を行う方式では、実施忘れが起こります。新版の公開切り替えと同時に、対象となるキャッシュだけを無効化する仕組みが望ましいです。
利用者への更新通知には、対象データ、版番号、公開時刻、主な変更点、確認先を含めます。単に「更新しました」と伝えるだけでは、利用者が開いている画面が新版かどうか判断できません。
旧版を一定期間保管する場合は、新版と明確に区別します。同じURLや同じ保存場所に混在させると、参照ミスの原因になります。保管用と公開用の領域を分けます。
問題発生時の対応手順も決めておきます。最初に元ファイルを確認し、次に変換済みデータ、配信キャッシュ、端末側の順に調べるなど、確認順序を統一します。
点群OBJアップロードを行う担当者だけでなく、閲覧する担当者にも版確認の方法を共有します。公開側だけが正しく管理されていても、利用者が長時間開いた旧画面を見続ければ、現場では情報の食い違いが起こります。
取得から公開までを一つのデータ管理工程として考えることも重要です。現場で取得した時点から案件名、取得日、座標系、処理段階、版番号を整理しておけば、アップロード時のファイル選択ミスを減らせます。
まとめ
点群OBJアップロード後に古いデータが表示される原因は、ブラウザのキャッシュだけではありません。同じURLへの上書き、配信経路に残った旧コピー、更新されていない変換済みデータ、OBJとMTLやテクスチャの世代ずれ、閲覧画面内のメモリ、オフライン保存など、複数の要因が考えられます。
対策の第一は、ファイル名やURLへ更新識別子を付け、新版を以前のデータとは別のものとして認識させることです。OBJだけでなく、MTLやテクスチャにも同じ版番号を付け、内部の参照記述も更新します。
固定URLを使う場合は、キャッシュ制御と再検証の設定を見直します。ファイルが更新されたときに、更新判定用の情報も正しく変化していることが重要です。作業中データと確定データでは、適切な保存期間が異なります。
配信経路にキャッシュがある場合は、新版の公開と同時に対象データを無効化します。OBJだけでなく、関連ファイル、サムネイル、変換済みデータも確認します。
アップロード後に表示用データを生成する構成では、元ファイルと変換結果を同じ世代として管理します。新版の変換と検証が完了する前に公開先を切り替えないことが大切です。複数の処理ジョブが動く場合は、旧ジョブの結果が最新版を上書きしないように制御します。
閲覧端末側では、画面の開き直し、保存済みデータを使わない再取得、対象サイトの保存データ更新などを行います。ただし、複数端末で同じ旧版が表示される場合は、端末側だけでなく配信側や変換処理を確認する必要があります。
安定した運用には、アップロード、変換、検証、公開、キャッシュ無効化、利用者への通知までを一連の工程として管理することが欠かせません。版番号と履歴を残し、利用者が現在表示しているデータを確認できるようにすれば、更新漏れや認識違いを減らせます。
現場で取得したデータを点群OBJとして整理し、アップロードから確認、共有までを円滑に進めるには、取得段階からの世代管理も重要です。現場計測と点群データの管理方法を見直す際は、LRTK Phoneを活用した取得から共有までの流れもあわせて確認してみてください。