点群OBJアップロード後に旧データが表示される問題とは
点群や三次元モデルをOBJ形式でアップロードしたにもかかわらず、画面には更新前の形状や色、位置が表示されることがあります。アップロード画面では完了と表示されているため、ファイルの差し替えが成功したように見えますが、実際の閲覧画面では古いデータが残り続けるという状態です。
この問題は、アップロード自体の失敗だけで起きるわけではありません。ブラウザ、配信経路、保存領域、表示用データの生成処理など、複数の場所に古い情報が残ることで発生します。特に、同じファイル名を使ってOBJを上書きしている運用では、新旧データの判別が難しくなり、キャッシュの影響を受けやすくなります。
点群OBJは、一般的な画像や文書よりもファイルサイズが大きくなる傾向があります。そのため、表示速度を上げる目的で、閲覧端末や配信側にデータを一時保存する仕組みが利用されることがあります。毎回すべてのOBJを読み直すと通信量と待ち時間が増えるため、過去に取得したファイルを再利用する設計自体は合理的です。
一方で、更新後も古いファイルが再利用されると、現場の最新状況と画面表示が一致しません。測量成果、施工進捗、出来形確認、土量計算、設備位置の検討などに点群を利用している場合、旧データの表示は単なる見た目の問題ではなく、判断の誤りにつながる可能性があります。
たとえば、前回計測時には存在していなかった構造物が、更新後も表示されないことがあります。反対に、撤去済みの資材や仮設物が画面に残り続ける場合もあります。座標補正後のOBJをアップロードしたのに、補正前の位置で表示されるケースもあります。
このような症状が起きたときは、何度も同じファイルをアップロードするだけでは解決しないことがあります。アップロードされた元ファイルが新しいのか、閲覧端末が新しいファイルを取得しているのか、関連ファイルが正しく更新されているのか、表示用データの生成が終わっているのかを順番に確認する必要があります。
重要なのは、キャッシュを一括して疑うのではなく、どの段階に古いデータが残っているかを切り分けることです。原因を特定せずに削除や再アップロードを繰り返すと、作業履歴が複雑になり、どのOBJが最新なのか分からなくなるおそれがあります。
点群OBJアップロード後の旧データ表示は、主に四つの原因に整理できます。ブラウザ側のキャッシュ、配信側のキャッシュ、関連ファイルの更新漏れ、変換処理や同期処理の未完了です。それぞれの特徴と対処方法を理解しておくことで、復旧までの時間を短縮できます。
原因1 ブラウザキャッシュに古いOBJが残っている
最初に確認したいのが、閲覧に使用しているブラウザのキャッシュです。ブラウザには、一度読み込んだファイルを端末内へ一時保存し、次回の表示を速くする仕組みがあります。OBJの取得先が前回と同じ場合、ブラウザが保存済みのファイルを再利用し、更新前の形状を表示することがあります。
この症状は、同じ端末では旧データが表示される一方、別の端末では新しいデータが表示される場合に疑われます。また、通常の閲覧画面では古い状態が表示されるものの、キャッシュを利用しにくい一時的な閲覧環境では新しい状態が表示される場合も、ブラウザ側に原因がある可能性が高いと考えられます。
ブラウザが保持する対象は、OBJ本体だけとは限りません。形状を表すOBJ、材質情報を持つMTL、色や模様に使われる画像、表示設定、変換済みの軽量データなどが個別に保存されることがあります。そのため、OBJだけを更新できていても、関連ファイルの一部が端末内に残り、表示が完全には切り替わらない場合があります。
対処の第一段階は、対象画面を通常の再読み込みではなく、保存済みデータを使わずに読み直す方法で更新することです。一般的な再読み込みでは、キャッシュされたファイルが再利用されることがあります。通信元へ再取得を要求する更新方法を使い、OBJや関連ファイルが再び取得されるか確認します。
それでも変わらない場合は、対象サイトに関する一時保存データを削除します。すべての閲覧履歴を削除する必要はなく、対象となるサービスのキャッシュや保存データに限定して消去できる場合があります。業務で複数のシステムを利用している端末では、必要なログイン情報まで消さないように注意が必要です。
開発者向けの確認機能を利用できる環境では、OBJの取得要求が実際に発生しているかを見る方法もあります。画面を開いた際に通信が発生せず、端末内の保存済みデータから読み込まれている場合は、ブラウザキャッシュの影響が考えられます。取得日時、応答状態、転送量などを確認すると、再取得されているか判断しやすくなります。
ただし、ブラウザキャッシュを削除しても旧データが表示される場合は、配信元から返されているファイル自体が古い可能性があります。端末側のキャッシュ削除だけを何度も繰り返しても解決しないため、別端末や別の通信環境でも同じ症状が出るかを確認し、次の原因へ切り分けることが重要です。
ブラウザ側の問題を減らすには、更新するOBJに対して毎回異なる識別情報を持たせる方法が有効です。ファイル名や取得先が更新ごとに変われば、ブラウザは別のデータとして扱いやすくなります。同じ名前への単純な上書きを避けることが、旧データ表示の防止につながります。
原因2 同じURLへの上書きで配信キャッシュが更新されない
ブラウザのキャッシュを削除しても旧データが表示される場合は、サーバーから閲覧端末までの配信経路に古いファイルが残っている可能性があります。大容量のOBJを効率よく配信する仕組みでは、利用者に近い中間地点へファイルを一時保存し、同じ要求に対して保存済みデータを返すことがあります。
この仕組みによって表示速度や通信負荷は改善しますが、同じURLへ新しいOBJを上書きした場合、中間地点に残っている旧ファイルが返されることがあります。保存領域では更新済みでも、閲覧画面には更新前のOBJが届くため、アップロード結果と表示内容が一致しません。
配信側キャッシュの特徴は、複数の端末で同じ旧データが表示されることです。ブラウザを変えても、端末を変えても、一定時間は古い形状が出る場合があります。また、利用する地域や通信経路によって新旧の表示が分かれることもあります。ある担当者には新しいOBJが見えているのに、別の担当者には古いOBJが表示されるケースです。
同じファイル名を上書きする運用では、取得先が変化しません。配信側から見ると、以前と同じ場所にある同じデータへの要求に見えるため、保存済みファイルを返してよいと判断されることがあります。内容だけが変更されても、URLが同一であれば更新を即座に認識できない設計もあります。
対策として分かりやすいのは、更新ごとにファイル名や格納先を変更することです。たとえば、計測日、更新時刻、版番号、処理番号などをOBJ名へ含めます。取得先が新しくなるため、旧ファイルのキャッシュと衝突しにくくなります。
閲覧画面からファイルを呼び出す際に、更新番号を付加する方法もあります。OBJ本体の保存名を変えにくい場合でも、取得先を更新ごとに異なるものとして扱わせることで、古いキャッシュの利用を避けられることがあります。ただし、画面上だけで番号を変更しても、内部で同じ変換済みデータを参照している場合は解決しません。OBJから表示用データまでの参照関係を確認する必要があります。
配信設定を管理できる場合は、キャッシュの有効期間も確認します。OBJの更新頻度が高いのに長期間保存する設定になっていると、更新反映まで時間がかかります。反対に、毎回キャッシュを無効にすると、大容量データを繰り返し取得することになり、表示速度や通信量へ影響します。
そのため、更新頻度と利用目的に合わせた設定が必要です。更新作業中のデータは短い期間で切り替え、確定後の成果データは長く保存するなど、運用段階によって扱いを分ける方法があります。ファイル名を版ごとに変更できれば、確定済みデータを長くキャッシュしながら、新版を確実に取得させることが可能です。
配信側の古いデータを削除する操作が用意されている場合は、対象を正確に指定します。OBJだけではなく、MTL、テクスチャ、変換済みデータ、一覧画面の情報などが別々に保存されていることがあります。一部だけを削除すると、新旧データが混在した表示になる可能性があります。
旧データを確実に切り替えるには、上書き完了後に閲覧画面で確認するだけでなく、配信されているファイルのサイズや更新識別情報を確認することが有効です。元のOBJと取得されたOBJの容量が大きく異なる場合、想定していない版が配信されている可能性があります。
原因3 OBJとMTL・テクスチャの更新がそろっていない
OBJは、形状情報だけで完結するとは限りません。材質や色を含むモデルでは、MTLや画像ファイルなどを参照して表示することがあります。点群をOBJとして出力した場合も、頂点情報、面情報、頂点色、材質、テクスチャなどの構成は、作成方法によって異なります。
OBJ本体だけを更新し、MTLやテクスチャを更新していないと、形状は新しいのに色が古い、削除した部分の模様が残る、別の計測データの画像が貼られるといった問題が起きます。利用者から見ると旧データが表示されているように見えますが、実際には一部の関連ファイルだけが古い状態です。
反対に、MTLやテクスチャだけを差し替え、OBJが古いままになっている場合もあります。この状態では色や見た目は更新されても、点群の位置、形状、欠損部分、構造物の有無などは変わりません。見た目の一部が新しくなるため、アップロードが成功したと誤認しやすい点に注意が必要です。
関連ファイルの参照先も確認しなければなりません。OBJ内には、使用する材質ファイル名が記載されていることがあります。新しいMTLをアップロードしていても、OBJが旧ファイル名を参照していれば、新しい材質は読み込まれません。
MTL側でも、画像ファイルの名称や相対的な位置関係が指定されることがあります。アップロード時にフォルダ構成を変更した場合、参照先が見つからず、既定の色で表示されたり、過去に保存された画像が使われたりする可能性があります。大文字と小文字、空白、記号、拡張子の違いも確認が必要です。
同じテクスチャ名を繰り返し利用していると、画像キャッシュの影響も受けやすくなります。OBJとMTLには更新ごとの名前を付けていても、参照する画像が常に同じ名称であれば、画像だけが古いまま残る場合があります。OBJ、MTL、画像を一つの更新単位として扱い、すべての識別情報をそろえることが重要です。
アップロード前には、対象OBJがどの関連ファイルを参照しているか確認します。書き出し元のフォルダに複数世代のMTLや画像が混在していると、意図しない旧ファイルをまとめてアップロードすることがあります。書き出し専用の新しいフォルダを作成し、今回必要なファイルだけを配置してからアップロードすると、混在を防ぎやすくなります。
圧縮ファイルとして一括アップロードする場合も、内部構成を確認します。圧縮ファイル名が新しくても、中に古いOBJが残っていることがあります。前回使用した圧縮ファイルへ新しいデータを追加する運用では、同名ファイルの置換に失敗したり、別階層へ保存されたりすることがあります。
更新確認では、色や質感だけで判断しないことが大切です。形状が変化した場所、点数、面数、座標範囲、ファイル容量など、OBJ本体の更新を判断できる情報を合わせて確認します。目印となる箇所を事前に決めておけば、新旧どちらのデータが表示されているかを短時間で判別できます。
原因4 変換処理や表示用データの生成が完了していない
点群OBJをアップロードした直後に閲覧画面を開くと、旧データが表示されることがあります。この場合、ファイルの転送は完了していても、その後に行われる変換処理、最適化、分割、索引生成、同期などが終わっていない可能性があります。
大容量のOBJをそのまま表示すると、読み込みに時間がかかり、端末への負荷も高くなります。そのため、アップロードされたOBJを表示しやすい形式へ変換したり、範囲ごとに分割したり、詳細度の異なる複数のデータを生成したりする仕組みがあります。
アップロード画面の完了表示が、必ずしも閲覧準備の完了を意味するとは限りません。ファイル転送の終了だけを示しており、その後の処理は別に進行している場合があります。処理中に閲覧画面を開くと、更新前の表示用データが残されているため、旧OBJが表示されます。
この仕組みは、変換処理に失敗した場合にも注意が必要です。新しいOBJの受信には成功していても、形式の不整合、参照ファイル不足、容量超過、文字コード、座標値、面構成などの影響で変換が完了しないことがあります。旧データが削除されずに残る設計では、利用者には前回の点群が表示され続けます。
処理状態を確認できる画面がある場合は、アップロード済み、処理中、完了、失敗といった状態を区別します。進行表示が止まっている場合や、完了時刻が更新されていない場合は、表示画面を再読み込みする前に処理結果を確認します。
一覧画面の更新日時だけで判断するのも危険です。ファイルを受信した日時は新しくても、表示用データの生成日時が古い場合があります。元OBJ、関連ファイル、変換結果、公開状態のそれぞれについて、どの段階まで更新されたかを確認する必要があります。
処理が完了する前に同じデータを繰り返しアップロードすると、複数の変換処理が重なり、完了順が前後する可能性があります。後から開始した新版の処理より、先に開始した旧版の処理が遅れて完了し、最終的に旧版が公開対象として設定される設計も考えられます。
アップロードのやり直しは、現在動いている処理を確認してから行うことが大切です。処理中のデータを削除すると、関連情報だけが残り、再アップロード後の判別が難しくなる場合があります。処理番号や更新時刻を記録し、どの処理が最新なのかを明確にします。
また、複数の保存領域へ同期している場合は、同期完了まで時間差が生じることがあります。管理画面では新しいOBJが確認できても、閲覧専用の保存領域には旧ファイルが残っている状態です。この場合、端末側のキャッシュを削除しても、同期先から旧データが返されます。
変換処理がある運用では、アップロード完了と公開完了を別の工程として管理する必要があります。担当者は転送終了だけで作業完了とせず、処理状態、公開版、閲覧画面の三つを確認します。確認工程を分けることで、処理待ちをキャッシュ障害と誤認することを防げます。
旧データが表示されたときの切り分け手順
旧データが表示された場合は、最初からすべてを削除するのではなく、影響範囲を順番に確認します。切り分けの目的は、端末固有の問題なのか、すべての利用者に共通する問題なのかを判断することです。
最初に、表示されているものが本当に旧データかを確認します。更新前後で変化した場所を一つ決め、形状、色、構造物の有無、点群の欠損状態などを比較します。画面の視点や表示範囲が違うだけで、更新されていないように見える場合もあります。
次に、アップロードした元ファイルを確認します。ファイル名だけで判断せず、更新日時、容量、頂点数、面数、座標範囲などを確認します。書き出し先を間違え、古いOBJを再びアップロードしていることも珍しくありません。
元ファイルが正しい場合は、別の閲覧環境で表示します。別端末で新版が表示されるなら、最初の端末に保存されたキャッシュやローカルデータが原因と考えられます。どの環境でも旧版が表示される場合は、配信側、保存領域、変換処理へ範囲を広げます。
続いて、通常の再読み込みではなく、保存済みデータを使わずに再取得する方法を試します。それでも変わらない場合は、対象サービスに関するキャッシュを削除します。ログイン情報や他の業務データへ影響しない範囲で実施します。
別端末でも旧版が表示される場合は、アップロード後の処理状態を確認します。新しいOBJが処理待ちになっていないか、変換に失敗していないか、公開対象が新版へ切り替わっているかを見ます。アップロード日時と公開日時が異なる場合は、公開完了を待つ必要があります。
関連ファイルを利用している場合は、OBJ、MTL、画像が同じ版でそろっているかを確認します。参照名と実際のファイル名が一致しているか、旧ファイルが同じフォルダに残っていないかも確認します。
さらに、同じURLへ上書きしている場合は、版ごとに異なる名前でアップロードして比較します。新しい名前では新版が表示されるのに、以前と同じ名前では旧版が表示される場合、配信経路またはブラウザのキャッシュが強く疑われます。
原因を調べる際には、同時に複数の変更を行わないことが重要です。ブラウザキャッシュの削除、ファイル名の変更、再アップロード、関連ファイルの差し替えを一度に行うと、どの対処が有効だったのか分からなくなります。
一つの確認を行ったら、結果を記録して次へ進みます。確認日時、使用端末、OBJの版、ファイル容量、処理状態、表示結果を残しておくと、同じ問題が再発した際の対応時間を短縮できます。
点群OBJのキャッシュを確実に更新する方法
キャッシュ対策の基本は、新しいデータを新しい取得先として扱えるようにすることです。同じURLに同じ名前のOBJを上書きする方式では、閲覧端末や配信側が内容変更を認識できない場合があります。
最も管理しやすい方法は、更新ごとにファイル名へ版情報を付けることです。計測日だけでは同日に複数回更新した場合に区別できないため、時刻、連番、処理番号などを組み合わせます。担当者が見ても新旧を判断できる名称にすることが重要です。
ファイル名には、対象現場、計測範囲、計測日、版番号などを含めると整理しやすくなります。ただし、名称が長くなりすぎると入力ミスが増えます。社内で規則を決め、同じ順序で記録します。
OBJと関連ファイルには、同じ版を識別できる名称を使います。OBJだけが新版で、MTLや画像は旧版という状態を防ぐためです。複数の画像を参照する場合は、版ごとのフォルダへまとめる方法も有効です。
保存先を更新版ごとに分ける場合、旧版をすぐに削除する必要はありません。新版の表示確認が終わるまで旧版を保持しておけば、不具合時に比較できます。公開対象だけを新版へ切り替え、確認後に不要な世代を整理します。
取得先に更新識別情報を付ける方法を使う場合は、OBJだけでなく関連するすべての取得先へ反映します。表示設定や変換済みデータが同じ取得先のままでは、一部が旧状態になることがあります。
キャッシュの有効期間を短くする設定も考えられますが、点群OBJは容量が大きいため、毎回再取得すると待ち時間が増えます。頻繁に更新される作業中データと、更新がほとんどない確定データを分けて管理すると、更新性と表示速度を両立しやすくなります。
作業中のOBJには短い更新間隔を設定し、確定版は変更しない前提で長く保存する方法があります。確定版を修正する必要が生じた場合は、同じファイルを上書きせず、新しい版として登録します。
配信側のキャッシュを削除できる場合でも、通常運用として毎回削除に依存するのは避けた方が安全です。削除操作の対象指定を誤ると、別の点群や他の利用者の表示へ影響する可能性があります。版管理によって自然に新しい取得先へ切り替える仕組みの方が、再現性を確保しやすくなります。
ブラウザ側でも、新版が公開されたことを判断できる情報が必要です。画面上に更新日時や版番号を表示すると、担当者は自分が見ているデータが最新か確認できます。形状だけで新旧を判別する運用は、変更範囲が小さい場合に見落としが生じます。
キャッシュ対策は、単に古いデータを削除する作業ではありません。どのファイルを、どの版として、どの取得先から配信するかを明確にすることが本質です。
再発を防ぐアップロード運用の設計
旧データ表示を根本的に減らすには、担当者の判断だけに依存せず、アップロード手順を標準化することが重要です。毎回異なる方法で書き出しや上書きを行うと、問題発生時に原因を追跡できません。
まず、OBJを書き出す前に作業用フォルダを新しく作成します。前回のOBJ、MTL、画像が残っている場所へ上書きすると、新旧ファイルが混在する可能性があります。今回アップロードするデータだけが入った状態を作ります。
次に、OBJの版を決定します。再出力した場合は、内容の変更が小さくても版番号を更新します。座標補正、不要点の削除、色補正、穴埋め、面生成の変更など、画面に影響する処理を行った場合は別版として扱います。
アップロード前には、書き出したOBJをローカル環境で開き、内容を確認します。対象範囲、座標、方向、縮尺、形状、色、欠損部分などを見ます。アップロード後に問題が見つかったとき、元ファイルが正しかったと確認できれば、調査範囲を配信側へ絞れます。
ファイル容量も記録します。前回とほぼ同じ範囲の点群なのに、容量が大幅に小さい場合は、書き出し範囲や点数が不足している可能性があります。反対に、想定以上に大きい場合は、不要な範囲や重複データが含まれていることがあります。
アップロード後は、転送完了と処理完了を分けて確認します。処理状態を確認せずに閲覧画面だけを見ると、旧版が表示された際にキャッシュ問題と処理待ちを区別できません。
公開切り替え後は、更新作業を行った端末だけでなく、確認用の別環境でも表示します。作業端末には過去のキャッシュが残っている可能性があり、反対に管理操作によって一時的に新版が見えている可能性もあります。
確認担当者には、最新版の版番号と更新箇所を共有します。「新しくなったはずです」という伝え方ではなく、「対象範囲の北側にある仮設物が削除され、版番号が更新されていることを確認する」といった判定条件を示します。
旧版を削除する時期も決めておきます。新版の確認前に旧版を消すと、比較や復旧が難しくなります。一方で、旧版を無期限に残すと、誤って公開するリスクが高まります。保持する世代数や期間を決め、公開版と保管版を区別します。
担当者が複数いる場合は、同時更新を避ける仕組みが必要です。別々の担当者が同じ名前でOBJをアップロードすると、どちらが最新か分からなくなります。更新中であることを共有し、公開担当を明確にします。
作業記録には、元データの名称、OBJの版、アップロード日時、処理完了日時、公開日時、確認者、確認結果を残します。問題が起きたときに、この記録からどの段階で旧版が残ったかを判断できます。
点群OBJ更新時に確認したい関連ファイル
点群OBJの更新では、OBJ本体だけに注目しがちですが、表示に関係するデータ全体を確認する必要があります。どの関連ファイルが必要かは、OBJの作成方法や閲覧環境によって異なります。
材質を使用している場合はMTLを確認します。OBJ内で指定されている名称と、アップロードしたMTLの名称が一致している必要があります。ファイル名を変更した場合は、参照内容も更新します。
画像を使用する場合は、MTLが参照する画像名を確認します。画像を別の場所へ移動したり、フォルダ名を変更したりすると、参照できない場合があります。画像名に空白や特殊な記号が含まれていると、処理環境によって解釈が異なる可能性もあります。
頂点色をOBJ内へ記録する方式では、閲覧側がその記述方法に対応しているか確認します。書き出し元では色が表示されても、アップロード後の閲覧環境では色として認識されない場合があります。この状態を旧データと誤認することがあります。
点群の位置合わせに外部の座標情報や変換情報を使う場合は、それらの更新も確認します。OBJが新しくても、表示位置を決める設定が古いままだと、更新前の位置へ配置される可能性があります。
表示範囲や初期視点の設定も確認対象です。新版の点群が以前と異なる場所へ移動した場合、画面を開いた直後には何も表示されず、旧版が残っているように見えることがあります。実際には新版が別の位置に存在している場合があります。
一覧画面で使用される縮小表示や概要情報が別に生成される場合もあります。三次元画面は新版なのに、一覧の画像だけが旧版というケースです。利用者が一覧だけを見て更新失敗と判断しないよう、各表示の更新タイミングを把握します。
圧縮ファイルでアップロードする場合は、展開後の階層を確認します。OBJが一段深いフォルダへ入ると、関連ファイルを見つけられないことがあります。圧縮前の構成と展開後の参照関係が一致していることが必要です。
ファイル名の大文字と小文字も統一します。作業端末では同じ名称として扱われても、アップロード先では異なるファイルと判断される場合があります。OBJ内の参照名と実ファイル名を一文字ずつ合わせることが安全です。
不要な旧ファイルを同じ更新単位に含めないことも大切です。複数のMTLや同名画像が存在すると、処理時にどれが選ばれたか分からなくなります。今回の版で使用するものだけをまとめます。
キャッシュ以外に考えられる表示不具合
旧データのように見えても、原因がキャッシュではない場合があります。キャッシュ削除やファイル名変更で解決しないときは、元OBJの内容や表示条件も確認します。
一つ目は、アップロードするファイルの取り違えです。更新版を別フォルダへ書き出したにもかかわらず、前回のフォルダから旧OBJを選択しているケースです。名称が同じ場合、更新日時や容量を確認しなければ判別できません。
二つ目は、書き出し処理の未反映です。点群編集画面では変更されていても、その後にOBJを書き出していなければ、アップロード対象は古いままです。編集データの保存とOBJ出力を別工程として確認します。
三つ目は、表示範囲の違いです。新版で座標系や原点が変わると、カメラの初期位置から点群が見えないことがあります。旧データが表示されているのではなく、別の位置に新版が配置されている可能性があります。
四つ目は、複数モデルの重複表示です。新版を追加アップロードしただけで旧版を非表示にしていない場合、二つのモデルが同時に表示されます。位置が近いと、旧版だけが残っているように見えることがあります。
五つ目は、表示の詳細度です。遠距離表示では簡略化された古い概要データが使われ、近づくと新版へ切り替わる場合があります。距離によって形状が変わる場合は、詳細度別データの更新状態を確認します。
六つ目は、座標値や縮尺の問題です。単位の解釈が異なると、新版が極端に小さくなったり、遠くへ移動したりします。画面内には旧版だけが見えているように感じますが、実際には新版も読み込まれている場合があります。
七つ目は、公開対象の選択ミスです。管理画面には新版が存在していても、閲覧画面が参照する対象として旧版が指定されていることがあります。アップロード済みであることと、公開中であることを区別します。
八つ目は、権限や共有範囲の違いです。管理者には新版が見えていても、一般の閲覧者には承認済みの旧版だけが表示される場合があります。確認するアカウントによって結果が違うときは、公開状態と権限を確認します。
キャッシュを疑う前に、元ファイル、公開版、表示位置、関連ファイルを確認すると、不要な削除作業を減らせます。キャッシュ削除は有効な対処ですが、原因が別にある場合は一時的にも改善しません。
点群OBJアップロードの作業時間を短縮するポイント
点群OBJのアップロード作業を効率化するには、転送速度だけでなく、書き出し、確認、変換、公開までの全工程を見る必要があります。ファイルの転送時間が短くても、旧データ表示の調査に時間がかかれば、業務全体としては効率化できません。
まず、必要な範囲だけを書き出します。現場全体の点群が必要でない場合は、確認対象となる区域に限定します。不要な点や離れた場所のデータを含めると、OBJの容量が増え、転送と変換に時間がかかります。
重複点や明らかな外れ値を整理することも有効です。ただし、点を減らしすぎると形状確認に必要な情報まで失われます。利用目的に応じて、必要な密度を決めます。
OBJを書き出す前に座標や範囲を確認しておくと、アップロード後のやり直しを減らせます。特に、広域座標をそのまま使用する場合や、複数時期の点群を重ねる場合は、原点と座標系の扱いを統一します。
アップロードするデータを版ごとに整理すれば、キャッシュ対策と作業効率化を同時に進められます。毎回同名ファイルを上書きすると、更新確認に時間がかかり、問題発生時の復旧も難しくなります。新版を別データとして登録し、確認後に公開を切り替える方が安全です。
関連ファイルは一つのフォルダへまとめます。必要なOBJ、MTL、画像が分散していると、アップロード漏れや参照切れが発生します。今回使用するファイルだけをまとめた状態で転送します。
確認項目を固定することも重要です。アップロード後に毎回異なる場所を見るのではなく、更新版で必ず変化する地点を確認します。構造物の追加、不要点の削除、座標補正、色の変更など、判別しやすい箇所を基準にします。
処理完了の通知や状態表示がある場合は、画面を何度も開き直すのではなく、完了を確認してから閲覧します。処理中に再アップロードを重ねると、かえって時間がかかることがあります。
モバイル端末で現場確認を行う場合は、通信環境も考慮します。大容量OBJをそのまま取得すると、読み込みに時間がかかります。事前に必要なデータを準備したり、表示範囲を分割したりすることで、現場での待ち時間を抑えられます。
点群の取得から共有までを短縮するには、現場で計測したデータを分かりやすく管理し、最新の版を関係者が確認できる流れを整えることが重要です。LRTK Phoneのように、現場での計測や位置情報の取得を一連の運用へ組み込める環境を活用すると、データの出所や計測時期を整理しやすくなります。
まとめ
点群OBJをアップロードした後も旧データが表示される主な原因は、ブラウザキャッシュ、同じURLに残る配信キャッシュ、OBJと関連ファイルの更新不一致、変換処理や同期処理の未完了という四つです。
同じ端末だけで旧データが表示される場合は、ブラウザ側の一時保存を確認します。複数端末で同じ症状が出る場合は、配信側のキャッシュ、公開対象、変換処理まで範囲を広げます。
形状は新しいのに色が古い場合や、色だけが変わって形状が変わらない場合は、OBJ、MTL、テクスチャの版がそろっているか確認します。アップロード完了直後だけ旧版が表示される場合は、表示用データの生成や同期が終わっていない可能性があります。
再発防止には、同じファイル名への単純な上書きを避け、版番号、計測日時、処理番号などを用いて新旧を識別する運用が有効です。OBJだけではなく、MTL、画像、表示設定、変換済みデータを同じ更新単位として管理します。
旧データが表示されたときは、複数の対策を一度に試すのではなく、元OBJ、別端末、キャッシュ、処理状態、関連ファイル、公開版の順に確認します。確認結果を記録すれば、同じ問題が起きたときの対応時間を短縮できます。
点群OBJの更新作業では、アップロードできたことだけでなく、正しい版が閲覧者へ配信されていることまで確認する必要があります。現場で取得する点群や位置情報の管理を効率化し、アップロード前後のデータを整理したい場合は、LRTK Phoneを活用した計測・共有の流れも確認してみてください。