点群OBJアップロードで413・504エラーが出る仕組み
点群から作成したOBJファイルをクラウドや社内システムへアップロードするとき、413または504というHTTPステータスコードが表示され、処理が完了しないことがあります。どちらも大容量データを扱う場面で目にすることがありますが、HTTP上の意味は異なります。
413は、サーバーが受信したリクエストの内容を、処理可能または許容可能な大きさを超えているとして拒否したことを示します。現在のHTTP仕様では「Content Too Large」と呼ばれ、過去の仕様や製品画面では「Payload Too Large」や「Request Entity Too Large」と表示されることもあります。点群OBJのアップロードでは、OBJ本体だけでなく、同時送信するMTLファイル、テクスチャ画像、圧縮ファイル、フォーム情報などを含むリクエスト全体が判定対象になる場合があります。
一方の504は「Gateway Timeout」であり、ゲートウェイまたはプロキシとして動作するサーバーが、処理完了に必要な上流サーバーから時間内に応答を得られなかったことを示します。点群OBJでは、受信後の解析、展開、変換、保存などを担当する上流処理の応答が遅れた場合に、途中のゲートウェイが504を返す構成が考えられます。
したがって、413は主にリクエスト容量の制限、504は主にゲートウェイと上流サーバー間の応答待ちに関係します。ただし、画面に表示された番号だけで、設定箇所や根本原因まで断定することはできません。アップロード経路には、ブラウザ、通信回線、負荷分散装置、中継サーバー、アプリケーション、変換処理、保存先などがあり、どの機器がエラーを返したかによって対策が変わります。
点群OBJのアップロードでは、OBJ本体だけが送信されるとは限りません。材質情報を記録したMTLファイルや、表面色を表現するテクスチャ画像を同時に送ることがあります。複数ファイルを圧縮して登録する運用もあるため、利用者が見ているOBJ本体の容量と、実際に送信または展開されるデータ量が一致しない場合があります。
エラーを解消するには、同じファイルを連続して再送するのではなく、どの段階で処理が止まったかを整理することが重要です。送信開始直後に拒否されたのか、送信が進んだ後に失敗したのか、受信後の変換中に止まったのかを確認すると、調査範囲を絞りやすくなります。ただし、進捗表示はシステムごとに実装が異なるため、表示上のタイミングだけで413と504を決めつけず、処理履歴や管理側のログと照合する必要があります。
点群OBJのアップロード負荷が大きくなる理由
OBJは、三次元形状を頂点座標、面、法線、テクスチャ座標などで表現できる形式です。点群からOBJを作成する場合は、点の集合から三角形などの面を生成し、対象物の表面形状をメッシュとして記録します。対象範囲が広く、点群密度が高く、細かな凹凸を残すほど、生成される頂点数や面数は増えやすくなります。
現場全体を高密度で計測し、不要部分を除かずに面を生成すると、OBJには大量の座標と面定義が記録されます。精細な形状を残すことには意味がありますが、共有や閲覧が目的であれば、取得時の情報量をそのまま一つのOBJへ反映する必要があるとは限りません。用途に対して過剰な面数は、ファイル容量だけでなく、読み込み、解析、変換、表示準備に必要な計算量も増やします。
OBJ本体が比較的小さくても、テクスチャ画像が高解像度であれば、アップロード一式の総容量は大きくなります。複数の画像が細かく分割されている場合や、未使用の画像が同じフォルダに残っている場合は、テクスチャ群がOBJ本体より大きくなることもあります。
点群からOBJへ変換した直後のデータには、業務上不要な部分が含まれている場合があります。計測対象から離れた孤立形状、地面や構造物の裏側に生成された面、通行人や車両などの移動物、反射ノイズから生じた小さな形状などです。これらを残したままにすると、見た目への寄与が小さい一方で、容量や処理対象は増えます。
複数回の編集や結合を行ったOBJでは、同じ位置に重複した頂点が残ったり、近い位置に類似面が重なったりすることもあります。すべての重複が不要とは限りませんが、意図しない重複が大量に存在すると、ファイルサイズや解析負荷を増やす原因になります。
アップロード後に表示用データへ変換するシステムでは、ファイルを受信するだけで処理が終わりません。ファイル構造の確認、頂点と面の解析、材質の読み込み、画像のデコード、表示範囲の計算、別形式への変換、保存先への書き込みなどが続くことがあります。そのため、OBJの容量だけでなく、頂点数、面数、材質数、画像枚数、画像解像度、圧縮ファイルの展開量なども処理時間に影響します。
同じ容量のOBJでも、比較的単純な形状と、非常に細かい面や多数の材質を含む形状では、処理時間が異なる場合があります。413への対策では送信リクエストの大きさを確認し、504への対策ではゲートウェイの待機時間だけでなく、上流側の解析や保存処理が遅くなっていないかを確認することが重要です。
413エラーが発生する主な原因
413エラーで最初に確認するのは、アップロード要求の内容が、経路上のどこかに設定された上限を超えていないかという点です。ここでいう大きさは、OBJ本体だけではなく、同時に送るMTLファイル、テクスチャ画像、圧縮ファイル、付随するフォームデータなどを含む場合があります。
たとえば、OBJ本体が画面に記載された上限より小さくても、複数の高解像度画像を追加することで、リクエスト全体が上限を超えることがあります。圧縮ファイルを使用する場合も、入口では圧縮後の容量を判定し、後段では展開後の容量やファイル数を別に制限する設計があります。圧縮によって入口の制限を通過しても、展開処理で別のエラーになる可能性があるため、圧縮だけを万能な解決策と考えるのは安全ではありません。
アップロード経路に複数の容量制限があることも、413が解消しにくい理由です。利用者から送信されたデータは、負荷分散装置、リバースプロキシ、ウェブサーバー、アプリケーションなどを通過する場合があります。それぞれに上限が設定されていれば、経路上で最も小さい上限が実質的な制限になります。
アプリケーション側の設定で大容量ファイルを許可していても、前段の中継サーバーの上限が小さければ、リクエストはアプリケーションへ届く前に拒否されます。管理担当者が一つの設定値を変更しても413が続く場合は、経路全体の設定と、実際にどの機器が応答を返したかを確認する必要があります。
アップロード画面に独自の合計容量制限やファイル数制限が設けられている場合もあります。ただし、ファイル形式や権限の不一致は、標準的には413とは別のエラーとして扱われることが多いため、413が表示された場合はまず大きさに関する制限を優先して確認します。画面が独自にエラー番号を割り当てている可能性があるときは、管理側のログや仕様も確認します。
不要なファイルの混入も実務で起こりやすい原因です。作業フォルダには、旧版のOBJ、過去のテクスチャ、確認用画像、書き出し前のデータ、圧縮前のファイルなどが残りがちです。フォルダをそのまま圧縮すると、必要なデータだけを選んだつもりでも、送信内容が想定以上に大きくなることがあります。
413が発生した場合は、アップロード専用の新しいフォルダを作り、必要なOBJ、MTL、テクスチャだけを格納して総容量を確認します。さらに、同じ構成を保ったまま範囲や画像枚数を減らした検証用データを作り、制限との関係を確認します。小さなデータでは成功し、元データでは413になる場合、リクエストの大きさに関する制限が影響している可能性が高まります。
504エラーが発生する主な原因
504エラーは、ゲートウェイまたはプロキシが、処理に必要な上流サーバーから時間内に応答を得られなかったときに返されます。点群OBJの場合、ファイル受信後の解析、展開、変換、保存などを同一の要求内で実行し、その完了を中継サーバーが待つ構成では、処理が長引くと504になる可能性があります。
OBJの面数が多いと、上流側の処理は大量の頂点座標と面情報を読み込む必要があります。材質やテクスチャが含まれる場合は、それらの参照関係や画像も処理します。さらに、表示用の分割、軽量形式への変換、索引作成などが行われるシステムでは、完了までの時間が延びることがあります。
一時保存領域や最終保存先の応答が遅い場合も、上流処理が完了しにくくなります。ファイルの受信が終わっていても、書き込み、展開、変換結果の保存が終わらなければ、アプリケーションからゲートウェイへの応答が遅れます。その結果としてゲートウェイの待機時間を超え、504が返されることがあります。
サーバー側の計算資源や同時処理数も影響します。同じ時間帯に複数の大容量データが処理されると、解析や保存に通常より時間がかかる場合があります。同じファイルが混雑の少ない時間帯では成功するのであれば、一時的な負荷が関係している可能性はありますが、時間帯だけで原因を断定せず、処理記録や資源使用状況を確認します。
利用者側の通信が遅い、または不安定な場合は、送信時間の増加、接続切断、ブラウザ側の失敗などにつながります。ただし、504のHTTP上の意味は、ゲートウェイが上流サーバーから適時の応答を得られなかったことです。利用者側の上り速度が遅いという事実だけで、504の原因と断定することはできません。通信状況は確認項目の一つですが、504が返された機器と上流処理の状況を合わせて調べる必要があります。
ログイン状態やセッションの有効期限が切れた場合も、アップロードが失敗することがあります。ただし、認証切れは401、403、ログイン画面への転送、アプリケーション独自エラーなどで示されることが多く、504そのものの定義ではありません。セッション切れと504が同時に見える実装も考えられますが、一般化せず、システムの仕様とログで確認します。
504が表示されても、上流側の処理が継続している設計はあります。利用者への応答だけが時間切れになり、後から登録が完了する場合です。ただし、常に処理が続くとは限りません。再送する前に、一覧画面、処理履歴、保存先、管理側ログなどを確認し、重複登録や同じ処理の多重実行を避けます。
対策1 アップロード対象の総容量を確認する
最初に行う対策は、送信対象の総容量を把握することです。OBJ本体だけを確認するのではなく、MTLファイル、テクスチャ画像、圧縮ファイル、付属データを含め、実際に選択または格納したファイル一式を確認します。
アップロード画面で複数ファイルを選択する場合は、選択済みファイルの合計容量が表示されていないか確認します。表示されない場合は、必要なファイルだけをコピーしたアップロード専用フォルダを作成し、フォルダ全体の容量を調べます。作業用フォルダと送信用フォルダを分けることで、旧版や確認用データの混入を防ぎやすくなります。
圧縮して送信する場合は、圧縮後の容量と展開後の容量を区別します。テキスト情報が多いOBJは圧縮によって小さくなりやすい一方、すでに圧縮された画像形式は、まとめても容量が大きく減らないことがあります。また、システムによっては圧縮後の入口制限とは別に、展開後の容量、ファイル数、一時保存領域の制限があります。
上限ぎりぎりを狙う運用は避けたほうが安全です。公開されている最大容量を下回っていても、別の中継装置に小さい上限が残っていたり、アップロード後の展開や変換に別制限があったりする場合があります。安定して処理できた過去データと比較し、余裕を持ったデータ構成に整えます。
413が出た場合は、同じ構成のまま対象範囲、画像枚数、画像解像度などを減らした検証用データを作ります。小さいデータで成功すれば、容量制限との関係を確認しやすくなります。小さいデータでも413が続く場合は、リクエストに付加される別データ、アップロード画面の独自制限、経路上の設定、エラー表示の実装を管理側で確認します。
管理担当者へ問い合わせる際は、OBJ本体の容量だけでなく、送信した総容量、ファイル数、圧縮の有無、実行時刻、エラーが出るまでの時間を共有します。どの入口で拒否されたかを判断するには、利用者側の情報とサーバー側の記録を照合することが重要です。
対策2 不要な頂点や面を整理してOBJを軽量化する
第二の対策は、OBJに含まれる不要な形状を整理することです。点群から生成したOBJには、業務上必要な対象だけでなく、周囲の地形、仮設物、移動物、遠方のノイズなどが含まれる場合があります。
まず、アップロード後に何を確認したいのかを明確にします。現場全体の状況共有が目的なのか、特定構造物の形状確認が目的なのかによって、必要な範囲と密度は変わります。目的に関係しない範囲を削除できれば、必要な部分の品質を保ちながら容量を抑えられる可能性があります。
孤立した頂点や小さな面も確認します。対象物から大きく離れた位置に形状が残っていると、モデル全体の境界範囲が広がり、初期表示の縮尺が不自然になる場合があります。表示範囲の計算や空間分割の方法によっては処理対象も増えるため、意図しない孤立形状は削除候補になります。
重複頂点や重複面が存在する場合は、意味を確認したうえで統合や削除を検討します。複数のデータを結合したモデルでは、接合部分に同じ位置の頂点が重なったり、近い面が二重に作成されたりすることがあります。ただし、材質境界や法線、テクスチャ座標の都合で頂点が分かれている場合もあるため、単純な一括統合は避けます。
面数を削減する場合は、全体を一律に粗くするのではなく、形状変化の少ない部分を中心に調整します。広い平面や緩やかな地形は、面数を減らしても見た目への影響を抑えやすい場合があります。一方で、角部、段差、境界、設備周辺などは、削減しすぎると形状や寸法確認に影響するため注意が必要です。
計測成果として保管する原本と、共有や閲覧に使用する軽量版は分けて管理します。原本を直接編集して容量を減らすと、後から詳細確認が必要になった際に元の情報へ戻れない可能性があります。原本を保存したまま、目的別のアップロード用OBJを書き出す運用が安全です。
軽量化後は、ファイル容量だけでなく、形状の欠け、面の反転、境界の変形、テクスチャのずれ、座標の変化がないか確認します。軽量化によってアップロードが成功しても、必要な情報が失われていれば業務データとして適切とはいえません。
対策3 テクスチャ画像とMTLファイルを見直す
第三の対策は、OBJと一緒に使用するテクスチャ画像およびMTLファイルの整理です。OBJ本体を軽量化しても、テクスチャ画像が高解像度のまま多数残っていれば、送信容量や画像処理時間は十分に減らないことがあります。
テクスチャ画像の解像度は、アップロード後の利用目的に合わせます。現場全体を俯瞰する用途で、細部まで大きく拡大しないのであれば、必要以上に高い解像度を維持する意味は小さくなります。表示確認を行いながら適切な範囲まで縮小すれば、見た目への影響を抑えつつ容量を減らせる場合があります。
表面の損傷、細かな文字、設備番号などを画像で確認する用途では、単純な縮小によって必要な情報が読めなくなる可能性があります。その場合は、全体閲覧用の軽量データと、詳細確認が必要な範囲の高精細データを分ける方法が考えられます。
未使用画像が含まれていないかも確認します。作業途中で生成された旧画像、過去の書き出し画像、確認用画像などが同じフォルダに残っていても、現在のOBJ表示には使われていないことがあります。MTLファイル内で参照されている画像と、送信フォルダ内の画像を照合し、不要なものを除外します。
MTLファイルには、OBJで使用する材質名や画像ファイルの参照が記録されます。MTL内のファイル名と実際の画像名が一致していないと、アップロード後に色が表示されないことがあります。大文字と小文字、拡張子、空白、記号、相対的な配置などを含めて確認します。
ファイル名は、利用するシステムの仕様に合わせ、短く識別しやすい文字列へ統一すると管理しやすくなります。長い名前や特殊な記号は413や504の直接的な定義原因ではありませんが、展開、参照解決、文字コード処理などで別の問題を起こすシステムもあります。対応文字や命名規則が定められている場合は、その仕様を優先します。
材質数が非常に多い場合は、解析や変換の処理対象が増えることがあります。業務上区別する必要がない材質は統合候補になりますが、材質名を施工区分や部位区分として利用している場合は、統合によって識別情報が失われます。容量だけでなく、アップロード後の利用方法を踏まえて判断します。
対策4 サーバー側の容量上限と待機時間を確認する
第四の対策は、システム管理側でアップロード経路全体の設定を確認することです。利用者側で十分に整理しても、業務上必要なデータが制限を超える場合は、サーバー側の構成や処理方式を見直す必要があります。
413への対応では、負荷分散装置、リバースプロキシ、ウェブサーバー、アプリケーションなどに設定された受信上限を確認します。設定箇所が複数ある場合は、一つだけ値を変更しても解決しません。実際に413を返した機器をログや応答ヘッダーなどから特定し、経路上の最小値を確認します。
504への対応では、ゲートウェイが上流サーバーを待つ時間と、上流側の処理時間を確認します。待機時間を長くすれば一時的に通る場合はありますが、解析や保存が過度に重い状態を放置すると、同時利用時の遅延や資源不足につながります。待機時間の調整と処理負荷の改善を分けて考えることが重要です。
大容量OBJの受信、変換、保存を一回のHTTP要求の中で完了させる仕組みは、処理が長くなるほどタイムアウトの影響を受けやすくなります。システムを設計または改修できる場合は、受信完了後に変換を別処理として実行し、利用者が処理状況を確認できる方式にすると、長時間の同期応答に依存しにくくなります。
一時保存領域の空き容量も確認します。最終保存先に余裕があっても、アップロード途中のファイル、圧縮データの展開、変換中間ファイルを置く領域が不足すれば処理は失敗します。圧縮ファイルを扱う場合は、圧縮後の容量だけでなく、展開後と処理中に必要な作業領域を見積もります。
サーバーの計算能力、メモリ、保存先の応答、同時実行数も確認します。大容量データを複数人が同時にアップロードすると、解析や書き込みが集中し、通常より上流処理の応答が遅くなる場合があります。大容量処理を別時間帯へ分散する運用は応急策になりますが、継続的に発生する場合は処理構成や資源配分を見直します。
設定値を必要以上に大きくすることには注意が必要です。容量や待機時間を無制限に近づけると、誤って巨大なファイルが送られた場合や処理が停止した場合に、他の利用者へ影響する可能性があります。実際のデータ規模、処理能力、一時領域、同時利用数、セキュリティ方針を踏まえて上限を決めます。
対策5 安定した通信環境とアップロード手順を整える
第五の対策は、アップロードを行う端末と通信環境を整えることです。通信環境だけで413や504の原因を断定することはできませんが、大容量データの送信失敗や再送を減らすうえでは重要です。
アップロード前には、利用している回線の上り通信が安定しているか確認します。通常の閲覧や動画視聴では主に下り通信が使われますが、ファイル送信では上り通信が重要です。閲覧が快適でも、大容量アップロードが安定するとは限りません。
可能であれば、変動の少ない接続方法を利用します。共有回線では、他の利用者による通信量が増えると速度が低下することがあります。混雑が明確な場合は、大容量アップロードの時間帯を調整し、失敗時の条件を記録します。
アップロード中は、端末を休止状態にしたり、ブラウザを閉じたりしないようにします。別ページへの移動、戻る操作、再読み込みなどによって処理が中断されるシステムもあります。バックグラウンド送信に対応しているかどうかは製品ごとに異なるため、操作手順に従います。
端末の電源も確保します。長時間の送信中に省電力機能が働くと、通信やブラウザ処理が制限される場合があります。現場や移動環境で作業する場合は、通信品質と電源残量の両方を確認してから開始します。
ログイン後に長時間放置した画面から大容量アップロードを始めると、処理中に認証期限へ達する可能性があります。これは504の定義とは別の問題ですが、結果としてアップロード失敗につながります。大容量データを送る前に認証状態を確認し、必要に応じて再ログインします。
アップロードが止まったように見えても、すぐに再読み込みや再送を行わないことが重要です。送信後にサーバー側で変換している場合、画面上の進捗が長時間変わらないことがあります。処理履歴や登録一覧を確認し、実際に失敗したかを確かめます。
504が出た後も同様です。上流処理が継続している可能性と、すでに失敗している可能性の両方があります。システムの状態を確認せずに同じファイルを再送すると、重複登録や処理負荷の増加につながるおそれがあります。
対策6 小さな検証データで原因を段階的に切り分ける
第六の対策は、本番データを繰り返し送るのではなく、小規模な検証データを使って原因を段階的に調べることです。大容量OBJには、リクエスト容量、面数、材質数、画像、圧縮、通信、上流処理、保存先など複数の要因が含まれます。本番データだけで試すと、どの要素がエラーに関係したか分かりにくくなります。
まず、本番OBJの一部範囲を抽出し、面数と容量を小さくした検証用OBJを作成します。可能であれば、本番と同じ座標系、材質構成、書き出し方法を保ち、変更する要素を一つに絞ります。この小規模OBJだけをアップロードし、成功するか確認します。
次に、MTLファイルを追加して試します。その後、低解像度のテクスチャ画像を少数追加し、最後に画像枚数や解像度を増やします。この順序で確認すると、どの要素を追加した段階で失敗したかを把握しやすくなります。
OBJ単体では成功し、テクスチャを追加すると413になる場合は、リクエスト全体の容量やファイル数に関する制限を疑います。小規模モデルは成功し、面数を増やすと504になる場合は、上流側の解析、変換、保存処理が長くなっている可能性を確認します。ただし、いずれも検証結果だけで確定せず、管理側の記録と照合します。
ファイル容量だけを変えた検証と、面数だけを変えた検証を分けることも有効です。同じ容量でも、面数が多いOBJは解析に時間がかかる場合があります。反対に、面数が少なくても高解像度画像が多ければ、転送量や画像処理量が増えます。
圧縮の有無を比較する場合は、圧縮後の送信容量だけでなく、展開後の容量と展開時間も記録します。圧縮すると413が出なくなり、その後504になる場合は、入口の容量条件と上流処理の時間条件が別々に影響した可能性があります。ただし、別の設定や一時的な負荷でも同じ結果になり得るため、仮説として扱います。
検証結果は記録として残します。ファイル名、OBJ容量、総容量、頂点数、面数、画像枚数、実行時刻、使用した回線、完了までの時間、表示されたエラー、処理履歴の状態などを記録します。数値を残せば、担当者が変わっても過去の結果と比較できます。
成功した条件を基準として、アップロード用データの作成手順を決めます。共有用OBJは対象範囲を限定する、画像解像度を用途別に決める、送信前に総容量を確認するなど、再現できる工程として標準化します。
413と504を判断する実務的な確認手順
413と504を効率よく切り分けるには、エラー番号、発生時刻、処理段階、データ構成をまとめて確認します。413が表示された場合は、まず送信リクエストの大きさに関する制限を優先して調べます。
最初に、アップロード対象の総容量を確認します。次に、不要ファイルが含まれていないかを確認し、同じ構成の小規模データで試します。小規模データが成功する場合は、容量やファイル数の制限が影響している可能性が高まります。
小規模データでも413になる場合は、画面に表示されている上限だけでなく、前段の中継装置、アプリケーションの受信設定、リクエストに追加されるデータ、独自エラー表示の有無を確認します。ファイル形式や権限が原因であれば別のステータスになることが一般的ですが、実装によって表示が置き換えられている可能性もあるため、ログの確認が必要です。
504が表示された場合は、どのゲートウェイまたはプロキシが応答を返したかを確認し、その機器が待っていた上流処理を調べます。送信後の解析、展開、変換、保存が長引いていないか、上流サーバーや保存先に障害や混雑がないかを確認します。
テクスチャなしでは成功し、テクスチャありでは失敗する場合は、画像容量、画像枚数、画像解像度、MTL内の参照、画像処理時間を確認します。面数を減らすと成功する場合は、形状解析や変換処理の負荷が関係している可能性があります。
同じファイルが時間帯によって成功したり失敗したりする場合は、サーバー負荷、保存先の混雑、回線状況などの変動要因を確認します。毎回ほぼ同じ条件と経過時間で失敗する場合は、設定された容量上限や待機時間など、再現性のある制限が存在する可能性があります。
管理担当者へ問い合わせる際は、エラー番号だけを伝えるのではなく、実行日時、利用者、ファイル名、OBJ容量、総容量、頂点数、面数、画像枚数、圧縮の有無、エラーまでの時間、画面に表示された処理状態を共有します。これらの情報があれば、サーバー側のログから該当処理を見つけやすくなります。
点群OBJアップロードの再発防止策
点群OBJの413・504エラーを防ぐには、エラーが発生したときだけ軽量化するのではなく、データ取得から共有までの運用を整える必要があります。
計測時に高密度な点群を取得することと、共有時に巨大なOBJを使用することは別の判断です。詳細な原データは保管しつつ、確認や共有には目的に合った範囲と密度のデータを使用します。
すべての情報を一つのOBJへまとめると、ファイル容量だけでなく、表示や変換の負荷も高くなります。現場全体を確認するデータ、特定箇所を詳細確認するデータ、記録として保管する原本を分けることで、それぞれに適した品質を設定できます。
対象範囲が非常に広い場合は、工区や場所ごとにデータを分ける方法も検討します。ただし、完成したOBJを単純に分割すると、材質、テクスチャ、座標、境界面の関係が崩れる場合があります。元の編集環境で範囲を分け、それぞれを正しい構成で書き出すことが大切です。
ファイル名やフォルダ構成も統一します。OBJ、MTL、テクスチャ画像の対応が分かる名称にし、旧版と完成版を同じ送信フォルダへ混在させないようにします。アップロード用フォルダを毎回新しく作り、必要ファイルだけを格納する運用が有効です。
容量だけでなく、頂点数、面数、材質数、画像枚数、画像解像度も確認項目にします。過去に安定して処理できたデータの規模を記録し、新しいデータがその範囲を大きく超える場合は、アップロード前に軽量化、分割、処理方式の見直しを行います。
システム管理側では、実際に扱うデータ規模に合わせて、受信上限、ゲートウェイの待機時間、上流処理時間、一時保存領域、同時処理数を定期的に確認します。利用者数やデータ密度が増えると、以前の設定や設備では不足することがあります。
代表的な検証用OBJを用意しておくことも有効です。システム更新、構成変更、保存先変更の後に、検証データをアップロードし、受信、変換、保存、表示まで正常に動くか確認します。実業務の大容量データで初めて問題に気づくリスクを減らせます。
エラー対応の役割分担も明確にします。データ作成担当者は容量と構成を確認し、利用者は実行状況を記録し、管理担当者は中継装置、上流処理、保存先のログと設定を確認します。それぞれの確認範囲を決めておけば、同じ調査を繰り返す時間を減らせます。
まとめ
点群OBJアップロードで発生する413は、サーバーがリクエストの内容を大きすぎるとして拒否したことを示します。OBJ本体が上限以下でも、MTLファイル、テクスチャ画像、圧縮ファイル、付加情報を含むリクエスト全体が大きければ、413になる可能性があります。
504は、ゲートウェイまたはプロキシが、処理に必要な上流サーバーから時間内に応答を得られなかったことを示します。点群OBJでは、受信後の解析、展開、変換、保存などが長引いた場合に発生する構成が考えられますが、利用者側の回線速度やセッション切れだけで504の原因と断定することはできません。
対策の第一歩は、アップロードするファイル一式の総容量を確認することです。そのうえで、不要な頂点や面を整理し、用途に合わせてOBJを軽量化します。テクスチャ画像とMTLファイルも確認し、未使用画像や参照不一致を減らします。
利用者側の対策だけで解決しない場合は、サーバー側の受信上限、ゲートウェイの待機時間、上流処理、一時保存領域、保存先、同時処理数を確認します。待機時間を延ばすだけでなく、重い変換処理を別工程へ分けるなど、処理方式そのものを見直すことも重要です。
原因が分からない場合は、小さな検証用データから段階的に容量、面数、材質、テクスチャを増やします。どの条件で413または504が発生するかを記録し、管理側のログと照合すれば、容量制限と上流処理の遅延を切り分けやすくなります。
点群OBJを安定して活用するには、詳細な原本と共有用の軽量データを分け、目的に合った範囲と品質を選ぶ運用が重要です。現場全体の確認、詳細部分の検証、成果の保管を一つの巨大データで兼ねようとせず、用途別に整理することで、送信容量と処理負荷を抑えやすくなります。
現場で取得した三次元データを早い段階で確認し、不要範囲を整理してから共有用データを作る工程も再発防止に役立ちます。LRTK Phoneを利用する場合も、製品を使うだけで413や504を防げるわけではありません。計測結果を現場で確認する運用と、原本保存、範囲整理、軽量版作成、アップロード前確認を組み合わせることで、必要以上に大きなOBJを作成するリスクを抑えやすくなります。