点群から生成したOBJファイルをクラウドへアップロードすると、処理が長時間続いたあとに504エラーが表示されることがあります。現場で即土量を確認したい実務担当者にとって、アップロードの時間切れは単なる操作上の不便ではありません。計測結果の確認、施工前後の比較、掘削量や盛土量の算出、現場事務所への共有、日報作成まで止まる可能性があるため、原因を正しく切り分ける必要があります。 504エラーは、利用者が操作している画面と実際に処理を行うサーバーとの間で、決められた時間内に応答が返らなかったときに表示されるのが一般的です。ただし、画面に504と表示されたからといって、OBJファイルがまったく送信されていないとは限りません。ファイルの転送は完了しているものの、その後の展開、解析、変換、保存などに時間がかかり、完了結果だけが画面へ返らなかった可能性もあります。 特に点群から作成したOBJは、一般的な文書や写真とは異なり、頂点、面、法線、テクスチャ座標などの大量の情報を含みます。ファイルサイズが大きいだけでなく、ポリゴン数、関連画像の枚数、メッシュの状態、座標値の持ち方によっても処理負荷が変わります。そのため、通信速度だけを確認しても解決しないことがあります。 この記事では、点群OBJのアップロード時に504エラーが出る代表的な6原因と、それぞれの時間切れ対策を詳しく解説します。現場側で実施できる確認方法、システム管理者へ伝えるべき情報、現場で即土量を止めないためのデータ運用まで整理します。
点群OBJのアップロードで504エラーが起きる仕組み
OBJは、三次元形状を頂点と面の組み合わせで表現するデータ形式です。点群そのものを別形式から変換してOBJとして扱う場合もありますが、実務では点群から三角形のメッシュを生成し、その形状をOBJへ出力する使い方が多く見られます。色付きで表示する場合は、OBJ本体に加えて、材質情報を記録したファイルやテクスチャ画像が必要になることもあります。 利用者がアップロードボタンを押すと、OBJがそのまま保存されるだけとは限りません。まず、ブラウザやアプリからデータが送信され、受信側でファイル容量や拡張子が確認されます。圧縮されている場合は展開され、OBJの記述内容、頂点数、面数、関連ファイル、画像参照などが解析されます。その後、表示しやすい内部形式への変換、サムネイルの生成、点群やメッシュの登録、体積計算用データの準備などが行われる場合があります。 504エラーは、この一連の処理のどこかで時間がかかり、利用者側へ応答を返す中継機能が待ちきれなくなったときに発生します。たとえば、ファイルの送信自体は短時間で終わっていても、メッシュ解析に時間がかかれば504になることがあります。反対に、現場の上り通信が遅く、ファイル送信だけで制限時間を超える場合もあります。 ここで注意したいのは、504が表示された時点で処理が完全に中止されたとは限らないことです。裏側では処理が続いており、少し時間を置くとデータ一覧に表示されることがあります。受付と保存は完了しているものの、完了画面だけを返せなかった可能性もあります。 その状態で同じファイルを何度も送信すると、重複したデータが登録されたり、処理待ちが増えたりするおそれがあります。エラー表示後は、すぐに再送信するのではなく、データ一覧、処理状況、更新時刻などを確認することが重要です。 また、504という数字だけで原因を断定することはできません。システムによっては、転送時間、解析時間、認証時間、保存処理など異なる問題が同じ表示になることがあります。発生時刻、ファイル容量、テクスチャの有無、エラーまでの時間、使用した通信環境を記録し、条件を一つずつ変えて確認する必要があります。
原因1｜OBJファイルの容量が大きすぎる
最初に確認したい原因は、OBJ本体や関連画像を含めた総容量が大きすぎることです。大容量のOBJは、アップロードに時間がかかるだけでなく、受信後の検査、展開、解析、変換、保存にも長い時間を要します。画面上では送信率が100パーセントになっていても、サーバー側の処理が終わらなければ504エラーが表示される可能性があります。 OBJは、頂点や面の情報を文字列として記録する形式です。点群から高密度のメッシュを生成すると、平らに見える地面にも細かな三角形が大量に作られます。さらに、法線、テクスチャ座標、材質の割り当てなどを含めると、ファイル容量が増加します。 確認するときは、OBJ単体の容量だけを見てはいけません。材質情報のファイル、テクスチャ画像、圧縮ファイル内の不要データなども含めた総容量を確認します。OBJが比較的小さくても、高解像度の画像が多数含まれていれば、アップロードと展開に時間がかかります。 現場で即土量を算出する目的であれば、すべての色や質感が必要とは限りません。土量計算で重要なのは、地表面の高さ、対象範囲の境界、法肩、法尻、掘削底、段差などの形状です。色付き表示を使わない場合は、テクスチャを除いた形状データだけで処理できるか確認します。 また、計測した全範囲を一つのOBJとして出力するのではなく、土量計算に必要な区域だけを切り出す方法も有効です。現場周辺の建物、道路、重機、資材置き場、遠景などが含まれていても、対象土量の算出に使わないのであれば処理負荷を増やすだけです。 ただし、単純に範囲を狭くすればよいわけではありません。施工前後を比較する場合は、両方のデータで同じ境界を使えるようにする必要があります。片方だけ切り出し範囲が異なると、体積差に境界条件の違いが混ざります。軽量化前に、工区境界、比較範囲、基準面との交線などを決めておくことが大切です。 圧縮によってファイル容量を小さく見せても、サーバー側では展開後のデータを解析します。そのため、圧縮後の容量だけで安全と判断することはできません。圧縮ファイルが小さくても、展開後のOBJや画像が非常に大きければ、解析処理で時間切れになる可能性があります。 大容量データを扱う場合は、現場確認用の軽量版と、保存用の高密度版を分ける運用が効果的です。まず軽量版をアップロードして土量や範囲を確認し、必要に応じて詳細版を安定した環境から送信します。これにより、現場判断を高密度データの処理完了まで待つ必要がなくなります。
原因2｜頂点数やポリゴン数が多すぎる
二つ目の原因は、OBJに含まれる頂点数やポリゴン数が多すぎることです。ファイル容量とポリゴン数は関係しますが、必ずしも同じではありません。同程度の容量でも、面の構成、数値の桁数、法線情報、テクスチャ座標の有無などによって、解析に必要な処理量は変わります。 点群からメッシュを生成するとき、元の点密度に近い細かさで三角形を作ると、平坦な地面にも大量のポリゴンが配置されます。見た目の変化がほとんどない場所で面を細かくしても、土量計算の結果が大きく改善するとは限りません。一方、サーバーはすべての頂点と面を読み込み、接続関係や座標範囲を確認するため、処理時間は増えます。 ポリゴン数が多いデータでは、アップロード後の表示用変換にも時間がかかります。画面上で三次元モデルを滑らかに動かすために、内部で複数段階のデータを生成する場合があるためです。OBJの読み込みだけでなく、サムネイル、簡易表示データ、断面計算用データの作成まで連続して行われると、制限時間を超える可能性があります。 対策としては、形状変化の少ない平坦部の面を減らし、重要な地形変化がある部分を残します。法肩、法尻、掘削底の端部、盛土の裾、段差、構造物との取り合いなどは、土量や断面へ影響するため、過度に簡略化してはいけません。 メッシュの品質も処理時間に関係します。重複した頂点、同じ位置に重なる面、面積がほぼゼロの三角形、極端に細長い面、裏返った面、孤立した小片などが多いと、解析や修復に時間がかかることがあります。点群から自動生成したメッシュでは、草、機械、反射物、動いた対象などが細かな突起や浮遊面として残ることがあります。 特に注意したいのは、対象地形から大きく離れた外れ値です。遠くに一つだけ頂点が残っていると、モデル全体の座標範囲が広がります。見た目では小さな異常でも、表示範囲や空間分割の計算へ影響し、処理負荷が増える場合があります。 軽量化の前後では、必ず体積と断面を比較します。元データと簡略化データに同じ基準面と境界を設定し、体積差を確認します。また、代表的な断面を複数箇所で見比べ、法面の折れや掘削底の凹凸が必要以上に丸められていないかを確認します。 単純に面数を一定割合まで減らす社内ルールを作ると、現場条件によっては精度を損ないます。広く平坦な造成地と、凹凸の多い法面では必要な面密度が異なります。対象面積、地形の複雑さ、要求する土量精度を踏まえ、用途ごとの目安を決めることが重要です。
原因3｜テクスチャや関連ファイルに問題がある
三つ目の原因は、OBJ本体とテクスチャ画像、材質情報の関係に問題があることです。色付きの三次元モデルは、一つのOBJだけで構成されているとは限りません。OBJが材質情報ファイルを参照し、その材質情報が複数の画像を参照する構造になることがあります。 ファイル名が一致していない、画像が欠けている、保存場所の記述が異なる、フォルダー階層が深すぎるなどの問題があると、受信側が関連データを正常に読み込めない場合があります。ローカル環境では表示できても、クラウド側では画像が見つからず、処理が長引いたり失敗したりすることがあります。 書き出し後に画像や材質情報のファイル名だけを変更すると、参照関係が切れることがあります。また、同じ名前の画像が複数のフォルダーに存在すると、書き出し元の環境では表示できても、アップロード先では正しい画像を特定できない場合があります。 ファイル名には、機種や環境によって扱いが異なりやすい文字を避けることが安全です。長すぎる名前、全角と半角が混在した名前、特殊な記号を含む名前は、処理環境の違いによって問題になる可能性があります。アップロード用データでは、短い半角英数字を中心とした分かりやすい名称に統一します。 ただし、ファイル名を変更する場合は、OBJや材質情報の中に記録されている参照名も合わせる必要があります。手作業で変更すると不整合が生じやすいため、可能であれば書き出し前に名称を整えておきます。 テクスチャ画像の解像度と枚数も重要です。点群計測時に取得した画像を高い解像度のまま多数添付すると、総容量が大きくなります。土量確認で地形の色が重要でなければ、テクスチャなしのOBJを先にアップロードする方法があります。 色付き表示が必要な場合でも、現場全体を確認できる程度の解像度へ調整できることがあります。細かな表面模様まで保存した詳細版と、土量や形状確認に使う軽量版を分けることで、時間切れを防ぎやすくなります。 原因を切り分けるときは、同じ形状をテクスチャなしで出力してアップロードします。テクスチャなしでは成功し、画像付きでは504になる場合は、画像容量、材質情報、ファイル名、階層構成のいずれかを優先して確認します。形状だけでも失敗する場合は、ポリゴン数、OBJの記述、座標範囲、サーバー負荷などを疑います。 圧縮ファイルを使う場合は、アップロード対象だけを新しいフォルダーへまとめてから圧縮します。作業フォルダーをそのまま圧縮すると、元画像、一時ファイル、過去のOBJ、別条件のデータなどが混在し、知らないうちに容量が増えることがあります。
原因4｜現場の通信回線が遅いか不安定になっている
四つ目の原因は、現場で利用している通信回線の上り速度が遅い、または通信が不安定になっていることです。日常的なウェブ閲覧や地図確認では問題がなくても、大容量OBJのアップロードでは時間切れになることがあります。 一般的な情報閲覧では、端末がデータを受け取る下り通信が中心です。一方、OBJのアップロードでは、端末からデータを送り出す上り通信が重要になります。下り速度が速くても上り速度が遅ければ、数百メガバイト以上のデータを送るのに長い時間がかかります。 現場の無線通信は、電波表示だけでは安定性を判断できません。周囲の利用状況、遮蔽物、車両内、建物の壁、地形、時間帯などによって通信品質が変化します。アップロード中に移動すると、通信先が切り替わり、一時的な切断や再送が発生することもあります。 通信が途中でわずかに途切れても、自動的な再送によって画面上では処理が続く場合があります。しかし、再送が繰り返されると合計時間が長くなり、最終的に制限時間を超えることがあります。 対策として、アップロードを行う場所を固定します。現場事務所、休憩所、車両の外など、過去に安定して送信できた場所を決めておくと、条件をそろえやすくなります。計測しながら移動中に送信するのではなく、安全で通信の安定した場所に止まってからアップロードします。 同じ回線で写真の自動同期、映像通信、大容量データの取得などが動いている場合は、帯域を奪い合います。重要なOBJを送るときは、不要な同期や大容量通信を一時的に止めると安定しやすくなります。 端末の省電力機能にも注意が必要です。画面が消えたときにブラウザやアプリの動作が制限されると、バックグラウンドでの送信が停止する可能性があります。大容量データを送る際は、処理完了まで端末の状態を確認し、ほかの重い操作を同時に行わないようにします。 通信原因を判断するには、同じOBJを別の安定回線から送信して比較します。安定した回線では成功し、現場回線では失敗する場合は、上り速度や接続維持が主な原因と考えられます。小さいOBJは成功するものの大きいOBJだけ失敗する場合も、通信時間または処理時間の上限が関係している可能性があります。 現場で即土量を確認する場合は、現場確認用の軽量データを先に送り、高密度の詳細データは安定した回線へ移動してから送る方法が有効です。すべてを一度に送る運用から、用途別に段階送信する運用へ変えることで、回線状態に左右されにくくなります。
原因5｜アップロードと解析の制限時間が合っていない
五つ目の原因は、システム内に設定されている複数の制限時間が、OBJの処理時間に合っていないことです。利用者が操作する画面の奥には、通信を受け付ける中継機能、認証機能、ファイル受信機能、保存機能、OBJ解析機能、表示データ変換機能などがあります。 それぞれに待ち時間や処理時間の上限が設定されている場合、どこか一つでも先に時間切れになると504が表示されます。たとえば、OBJの解析には数分かかるのに、中継側がそれより短い時間で接続を終了する設定なら、解析が正常に進んでいても利用者側にはエラーが返されます。 反対に、中継側の時間だけを長くしても、解析処理側の上限、認証の有効時間、保存先への接続時間などが短ければ解決しません。システム管理者は、利用者から処理サーバーまでの経路全体を確認する必要があります。 現場担当者が時間設定を直接変更できない場合でも、調査に役立つ情報を残すことはできます。重要なのは、アップロード開始から504表示までのおおよその時間です。毎回ほぼ同じ時間でエラーになる場合は、何らかの固定された制限時間に達している可能性があります。 管理者へ伝える際は、ファイル名だけでなく、OBJ本体の容量、関連画像を含む総容量、圧縮の有無、頂点数や面数が分かればその情報、エラーまでの時間、テクスチャなし版の結果、軽量版の結果も共有します。 「大きいファイルだけ失敗する」「一定時間で必ず504になる」「送信率は完了したあとにエラーになる」といった情報があれば、通信中の時間切れなのか、解析中の時間切れなのかを判断しやすくなります。 システム側の有効な対策として、ファイルの受信と重い解析処理を分ける方法があります。アップロード受付が完了した段階で利用者へ受付結果を返し、OBJ解析は別の処理として進めます。利用者は処理中、完了、失敗などの状態を画面で確認します。 この方式であれば、解析が長時間かかっても画面との接続を維持し続ける必要がありません。ただし、処理の重複防止、失敗理由の表示、再実行方法、古い処理の整理なども必要です。 大容量ファイルを複数の部分に分けて送信できる仕組みも、通信切断への対策になります。途中で失敗しても完了した部分から再開できれば、最初から送り直す必要がありません。ただし、利用できるかどうかはアップロード先の仕様によります。 単純に制限時間を長くするだけでは、長い処理が多数残り、ほかの利用者の操作へ影響することがあります。転送、展開、解析、変換、保存の各工程に何秒かかっているかを確認し、時間のかかっている処理そのものを改善することが根本対策です。
原因6｜サーバーの混雑やメモリー不足が発生している
六つ目の原因は、サーバー側の処理待ち、混雑、メモリー不足、保存先の遅延などです。OBJはファイル容量が大きいだけでなく、解析時に多くのメモリーを使うことがあります。文字列として保存されている頂点や面を内部データへ変換し、それぞれの関係を整理するため、一時的な使用量が元のファイル容量より大きくなる場合があります。 複数の利用者が同時に高密度OBJをアップロードすると、処理待ちが増えます。一件だけなら時間内に完了するデータでも、同時処理が重なると応答が遅れ、504になる可能性があります。 サーバー混雑が原因の場合、同じOBJでも時間帯によって成功したり失敗したりすることがあります。また、OBJのアップロード以外にも、データ一覧の表示、サムネイルの読み込み、体積計算などが全体的に遅くなる場合があります。 一方、特定のOBJだけが毎回失敗する場合は、サーバー全体の混雑ではなく、そのファイル固有の問題を疑います。極端に長い記述、不正な頂点参照、重複面、数値として読み取れない項目、異常に離れた座標などがあると、解析処理が長時間化したり停止したりすることがあります。 原因を分ける方法として、OBJの対象範囲を二つに分割してアップロードします。分割した両方が成功し、結合した元データだけ失敗する場合は、総容量や総ポリゴン数が上限に近いと考えられます。片方だけが失敗する場合は、その範囲に異常形状や不正なデータが含まれている可能性があります。 管理者側では、処理待ち件数、処理時間、メモリー使用量、保存容量、保存先の応答時間、失敗時の記録などを確認します。大容量処理を同時に実行する件数を制限し、一件ごとに必要な資源を確保する方法もあります。 現場数や利用者数が増えれば、過去には問題のなかった処理能力でも不足することがあります。OBJの平均容量、ピーク時間帯、同時処理数などを記録し、利用状況に合わせて見直す必要があります。 現場側でも、日報提出前など同じ時間帯に高密度データを集中して送らない運用が有効です。計測後に軽量版を早めに送り、詳細版は作業の区切りごとに順番に送ることで、処理集中を避けやすくなります。
504エラーが出た直後に確認する手順
504エラーが表示された直後は、同じファイルをすぐに再送信しないことが重要です。まずデータ一覧や処理履歴を開き、対象ファイルが受付済み、処理中、変換中などの状態になっていないか確認します。 処理中のデータが存在する場合は、画面への完了応答だけが時間切れになった可能性があります。その状態で再度送信すると、同じデータが重複登録され、さらにサーバー負荷を高めることがあります。 対象データが一覧にない場合は、発生条件を記録します。アップロードを開始した時刻、504が出た時刻、ファイル名、OBJ本体の容量、関連ファイルの数と総容量、テクスチャの有無、圧縮の有無、利用した回線、利用端末を残します。 画面上の進捗がどこまで進んでいたかも重要です。送信途中で止まったのか、送信完了後に長時間待ってからエラーになったのかで、疑う原因が変わります。送信途中なら通信や容量、送信後なら解析やサーバー処理を優先して確認します。 次に、小容量の確認用OBJをアップロードします。確認用データが成功すれば、認証や基本的なアップロード機能は動いている可能性が高くなります。確認用データまで失敗する場合は、サービス全体の障害、権限、保存先、通信経路などを疑います。 その後、元データから条件を一つだけ変えたファイルを作ります。まず対象範囲を狭くした版、次にテクスチャなし版、さらに面数を減らした版などを試します。一度に複数の条件を変えると、どの変更が有効だったのか分からなくなります。 テクスチャなし版だけが成功すれば、関連画像や材質情報の問題が考えられます。面数を減らした版だけが成功すれば、ポリゴン数や解析負荷が主な原因です。別の安定した回線で成功すれば、現場回線の上り速度や接続維持を確認します。 再送信用のファイルは、元データと区別できる名称にします。ただし、長い説明をすべてファイル名へ入れるのではなく、計測日、工区、軽量版、テクスチャなしなど最低限の違いが分かる名称にします。 現場で即土量を確認する必要がある場合は、504の原因調査と並行して、軽量版で暫定計算を進めます。暫定値には、使用したデータ、対象範囲、基準面、軽量化の有無を記録し、高密度データから算出した正式な結果と混同しないようにします。
OBJを軽量化するときに残すべき形状
OBJを軽量化すると、アップロード時間と解析時間を短縮できます。しかし、必要な地形まで削ると土量計算の精度に影響します。軽量化では、容量を小さくすることより、計算に必要な形状を選んで残すことが重要です。 掘削土量を求める場合は、掘削底、法面、法肩、法尻、段差、掘削範囲の端部を残します。盛土量を求める場合は、盛土上面、法面、裾、既設地盤との取り合いが重要です。これらの位置が変わると、基準面との間に作られる体積が変化します。 平坦部では、細かな三角形を減らしても体積への影響が小さい場合があります。一方、急な高低差や複雑な凹凸がある場所では、同じ削減条件を使うと形状が丸められます。そのため、現場全体へ一律の簡略化を行うより、形状変化に応じて調整するほうが安全です。 重機、作業員、車両、仮置き資材などが地表面に含まれている場合は、土量計算の対象外として除去します。ただし、除去後にできた空白を自動で広く埋めると、実際には計測していない地表面が作られることがあります。 補間する場合は、周辺の地形が連続していると判断できる範囲に限定します。重機の下や資材山の下など、実際の地面が見えていない区域を推定だけで埋めると、土量結果の根拠が弱くなります。再計測できる場合は、対象物が移動したあとに不足範囲を取得するほうが確実です。 草や小さな突起も注意が必要です。地表面として扱う高さに草の先端が含まれると、盛土側の体積が増える可能性があります。地盤面を求める処理を行い、孤立した突起や浮遊点を確認します。 簡略化後は、上から見ただけでなく、横方向と斜め方向から形状を確認します。地表面から下へ伸びる面、針のような突起、裏返った面、遠くへ飛んだ要素などは、平面表示では見落としやすいためです。 元データと軽量版には同じ境界と基準面を設定し、体積を比較します。代表断面も確認し、重要な折れ点が移動していないかを見ます。体積差が小さくても、特定の法面や掘削底だけが変形している場合があるため、数値と形状を両方確認します。 軽量化条件は、現場名、対象範囲、元の面数、処理後の面数、体積差などと一緒に記録します。同じ条件を別の現場へ適用する場合も、地形と要求精度が異なれば再確認が必要です。
アップロード前に行うファイル構成の確認
504エラーを未然に防ぐには、OBJを書き出した直後にアップロードせず、ファイル構成を一度確認します。まず、アップロード専用のフォルダーを作成し、OBJ本体、材質情報、必要なテクスチャ画像だけを入れます。 作業中のフォルダーには、元点群、複数の書き出し結果、一時データ、過去の画像などが残っていることがあります。フォルダー全体をそのまま圧縮すると、不要なファイルまで送信することになります。 専用フォルダーへコピーしたあと、そのフォルダーだけを使ってOBJを開けるか確認します。元の作業場所にある画像を参照している場合、専用フォルダーへ移すと色が表示されなくなります。この確認により、アップロード前に参照切れを発見できます。 OBJを一度閉じ、別の場所から再度開くことも重要です。書き出し直後の画面では、作業中の一時情報によって正常に見えている場合があります。再度読み込むことで、保存されたファイルだけで形状と色が再現されるかを確認できます。 ファイル名の大文字と小文字も統一します。処理環境によっては、大文字と小文字を別の名前として扱うことがあります。OBJ内の参照名と実際の画像名が完全に一致しているかを見ます。 圧縮する場合は、圧縮ファイルの中を開いて階層を確認します。不要な親フォルダーが何重にも入り、OBJが深い位置に保存されていないかを確認します。また、同じ名前のOBJが複数含まれていないかも見ます。 容量、ファイル数、画像枚数を記録しておくと、エラー発生時の比較に役立ちます。正常に処理できた過去データと比べて、容量や画像数が急増していれば、時間切れの原因を推測しやすくなります。 座標値の確認も必要です。点群が使用している座標系によっては、原点から非常に離れた大きな数値を持つことがあります。処理環境によっては、大きな座標値で表示や変換が不安定になる場合があります。 座標を一時的に原点付近へ移動する場合は、移動量と元の座標を必ず記録します。正式な位置情報を持つデータと、表示や処理のために移動したデータを混在させると、施工前後比較やほかの測量結果との重ね合わせができなくなります。 アップロード前の確認を定型化すると、現場ごとのばらつきを減らせます。対象範囲、不要物の除去、外れ値、面数、テクスチャ、ファイル名、総容量、再読み込み、座標、基準面を順番に確認し、問題がない状態で送信します。
現場で即土量を止めないデータ運用
現場で即土量を確認する業務では、最高密度のデータが完成するまで、すべての判断を止める必要はありません。現場判断用、詳細確認用、保存用のデータを分けることで、504エラーが発生しても作業全体への影響を抑えられます。 現場判断用には、対象範囲を絞り、重要な地形を残した軽量OBJを使います。短時間でアップロードでき、掘削量、盛土量、残土量などを概算できることを優先します。 詳細確認用には、法面、段差、構造物との取り合いなど、判断に影響する部分を高い密度で残します。軽量版で想定外の数値が出た場合や、発注者や施工担当者へ断面を説明する場合に使います。 保存用には、元点群、高密度メッシュ、基準情報などを保持します。後日、対象範囲や基準面を変更して再計算できる状態にしておくことが重要です。アップロード用に軽量化したOBJだけを保存すると、あとから詳細を確認できない場合があります。 ファイル名には、現場名、工区、計測日、施工前後、データの用途が分かる情報を含めます。軽量版と詳細版を明確に区別し、どちらを正式な計算に使ったかを記録します。 体積結果を共有するときは、数値だけを伝えないようにします。対象範囲、基準面、計測日時、除外した対象、軽量化の有無などを合わせて共有します。同じOBJでも、境界や基準面が違えば土量は変わるためです。 アップロード担当者と確認担当者を決めることも有効です。504が発生した際、複数の担当者が同じデータを再送信すると重複が起きます。処理状況を確認したうえで、一人が再送信する流れを決めます。 確認用の小容量OBJを一つ用意しておくと、障害の切り分けが容易になります。大容量データが失敗した際に確認用OBJを送信し、それも失敗するかを確認します。過去の正常な処理時間を記録しておけば、サービス全体の速度低下にも気づけます。 現場回線が不安定な場合は、計測場所で無理に高密度データを送らず、必要なデータを端末内へ確実に保存します。現場では軽量版や計算結果を優先し、高密度版は安定した通信環境から送ります。 現場で即土量を求める流れでは、計測、データ整理、軽量化、アップロード、体積計算、共有を分け、それぞれの完了を確認できるようにします。一つの長い処理として扱うと、504が出たときにどこまで完了したか分からなくなります。 LRTK Phoneで現場の三次元データを取得する場合も、計測対象を明確にし、不要な範囲を減らしておくことが重要です。取得段階から土量計算に必要な地形を意識すれば、後工程の切り出しや軽量化を行いやすくなります。
まとめ｜504エラーは原因を分けて対策する
点群OBJのアップロードで発生する504エラーは、単なる通信障害とは限りません。OBJや関連画像の総容量が大きい、頂点数やポリゴン数が多い、テクスチャの参照に問題がある、現場の上り通信が不安定、システム内の制限時間が合っていない、サーバーが混雑または資源不足になっているという六つの原因を分けて確認する必要があります。 エラーが表示された直後は、同じファイルを繰り返し送信せず、データ一覧と処理履歴を確認します。ファイルの受付や解析が裏側で続いている可能性があるためです。その後、小容量データ、テクスチャなしデータ、面数を減らしたデータ、別回線という順に条件を一つずつ変えます。 大容量OBJを軽量化するときは、容量だけに注目してはいけません。土量へ影響する法肩、法尻、掘削底、盛土の裾、段差、境界を残し、平坦部や対象外範囲を中心に軽くします。軽量化前後では、同じ境界と基準面を使って体積と断面を比較します。 アップロード前には、OBJ、材質情報、テクスチャ画像の構成を確認し、専用フォルダーだけで再度開けるかを試します。不要ファイルを除き、ファイル名、画像参照、総容量、座標値を確認すれば、関連ファイルによる処理失敗を減らせます。 現場で即土量を止めないためには、軽量な現場判断用データと、高密度な詳細確認用データを分ける方法が有効です。まず軽量版で土量と対象範囲を確認し、高密度版は安定した通信環境から送信します。元点群や基準情報は保存し、必要に応じて再計算できる状態を保ちます。 504エラーへの対策は、単に待ち時間を長くすることではありません。ファイル容量、メッシュ構造、関連画像、通信、制限時間、サーバー負荷を分けて調査し、計測から共有までの流れを整理することが重要です。現場で取得した三次元データから効率よく土量を確認する運用を整える際は、LRTK Phoneを活用した計測とデータ管理も検討するとよいでしょう。