点群OBJをクラウドや社内システムへアップロードした際に、画面上へ「413」「Request Entity Too Large」「Content Too Large」などのエラーが表示されることがあります。小さなOBJファイルは送信できるのに、現場全体を収録した大容量データだけが失敗する場合は、アップロードするデータ量が通信経路やサーバーに設定された上限を超えている可能性があります。
413エラーは、ファイルが壊れている場合に必ず発生するエラーではありません。OBJの記述内容や拡張子が正しくても、アップロードの入口となるサーバー、中継装置、アプリケーションなどが受信できる容量を超えれば、保存処理へ進む前に拒否されます。そのため、OBJを作り直すだけでは解決せず、どこに容量上限があるのかを順番に切り分ける必要があります。
点群OBJは、頂点数、面数、座標値の桁数、色情報、UV座標、法線、テクスチャ画像などによって容量が大きく変化します。点群として取得した範囲が広いほど、また細部まで残すために点密度を高くするほど、OBJ本体は大きくなります。さらに、マテリアルファイルや画像を一緒に送信すると、画面で確認したOBJ単体の容量よりも実際の送信量が増える点にも注意が必要です。
この記事では、点群OBJアップロードで413エラーが出る代表的な原因を5つに整理し、利用者側で行える軽量化と、システム管理者が確認すべき容量設定を解説します。点群データを削減しすぎて必要な精度を失わないための考え方や、エラー発生時の切り分け手順も紹介します。
413エラーの意味と点群OBJで発生しやすい理由
413エラーは、サーバーが受け取ろうとしたリクエストの本文を大きすぎると判断し、処理を拒否したときに返されるHTTPステータスです。画面に表示される文言はシステムによって異なりますが、アップロード対象の容量が許容値を超えている状況を示す場合が多くあります。
ここでいう容量は、必ずしも保存先の空き容量ではありません。保存領域に十分な余裕があっても、通信の入口で一回に受信できる容量が制限されていれば、ファイルは保存先まで到達しません。アップロード処理には、利用者の端末、社内ネットワーク、通信中継層、Webサーバー、アプリケーション、保存先などが関係します。このうち一つでも小さな上限を持っていれば、その値が実質的な最大アップロード容量になります。
点群OBJで413エラーが起こりやすい理由は、データの構造と点数にあります。OBJは頂点座標や面の構成を文字列として記録する形式です。各頂点にはX、Y、Zなどの座標値が書かれ、必要に応じて色情報やUV座標、法線なども追加されます。数百万点を含むデータでは、一つ一つの行が短くても、全体では大きな容量になります。
点群から三角形メッシュを作成している場合は、頂点だけでなく面の索引情報も増えます。高密度な点群から細かな面を生成すると、頂点数と面数の両方が増えるため、OBJの容量が急激に大きくなることがあります。色付き表示のためにテクスチャ画像を付けると、関連ファイルの合計容量も増加します。
また、利用者が確認しているファイル容量と、実際に送信されるリクエスト容量が完全に同じとは限りません。ファイルをアップロードする際には、ファイル名、入力項目、データの区切り情報などが付加されます。上限にほぼ等しい容量のOBJでは、この付加分によって設定値を超える可能性があります。
たとえば、アップロード上限が一定の値に設定されている場合、その値と同じ容量のファイルが必ず送れるとは限りません。OBJ本体だけで上限付近まで達していると、マテリアルファイルや送信時の付加情報を含めた段階で超過することがあります。そのため、上限ぎりぎりではなく、一定の余裕を持ったファイル容量に整えることが大切です。
原因1 Webサーバーの受信容量を超えている
413エラーの代表的な原因は、外部からの通信を受け付けるWebサーバーに設定された受信容量の上限です。アップロード画面から送信された点群OBJは、アプリケーションへ直接渡されるとは限りません。多くのシステムでは、最初にWebサーバーが通信を受け取り、問題がなければ内部の処理へ転送します。
このWebサーバーに小さな上限が設定されている場合、アプリケーションが大容量OBJに対応していても、ファイルは入口で拒否されます。利用者から見るとアップロードボタンを押した直後に413エラーが表示され、進捗がほとんど進まないこともあります。
Webサーバーの上限を疑いやすいのは、一定の容量までは安定して成功し、その値を少し超えたファイルが毎回失敗する場合です。たとえば、同じ形式、同じ操作、同じ回線で小さなOBJは成功するものの、容量が大きくなると必ず失敗する場合は、固定された容量制限が関係している可能性があります。
ただし、Webサーバーの受信上限だけを引き上げれば解決するとは限りません。大容量ファイルを受け取る際には、一時的にメモリーやディスクへデータを保持することがあります。受信上限を大きくしても、一時保存領域が不足していれば、別のエラーや処理停止につながる可能性があります。
設定変更では、無制限に近い値を指定するのではなく、業務で必要となる最大容量を確認したうえで適切な値を決めます。点群OBJの標準容量、同時にアップロードする利用者数、保存先の余裕、通信時間などを考慮し、安全に処理できる範囲を設定することが重要です。
また、設定変更後に反映作業が必要な環境もあります。設定を書き換えただけでは反映されず、サービスの再読み込みや再起動が必要になることがあります。複数台のサーバーで処理を分散している場合は、すべての処理先へ同じ設定を適用しなければなりません。
一部のサーバーだけ上限が低い状態になると、同じOBJが成功する場合と失敗する場合に分かれます。利用者からは不規則な障害に見えるため、設定値だけでなく、各サーバーに正しく反映されたかまで確認する必要があります。
原因2 リバースプロキシや通信中継層に上限がある
Webサーバーやアプリケーションの設定に問題がなくても、その手前にある通信中継層で413エラーが発生することがあります。外部からの通信を内部へ振り分ける仕組み、アクセスを制御する装置、セキュリティ検査を行う機能、社内ネットワークのプロキシなどが、独自の容量上限を持っている場合です。
通信経路に複数の中継層がある場合、最も小さい上限が実際のアップロード上限になります。たとえば、Webサーバー側では大容量を許可していても、その前段にある中継層が小さな値で制限していれば、点群OBJはWebサーバーへ到達する前に拒否されます。
この原因は、サーバー側の設定を変更したのに413エラーが解消しないときに見落とされやすいポイントです。アプリケーション担当者が自分の管理範囲を確認して問題がなくても、ネットワーク担当者が管理する中継層に別の制限が残っていることがあります。
利用する回線によって結果が変わる場合も、中継層の影響が考えられます。社内ネットワークからは失敗するのに、承認された別の回線からは成功する場合、社内プロキシなどが大容量送信を制限している可能性があります。反対に、社内では成功して現場回線では失敗する場合は、外部公開側だけが通過する中継層を確認します。
ただし、回線を変えて試験する際は、情報管理ルールに従う必要があります。機密性のある点群データを、検証目的で未承認の回線や保存先へ送信してはいけません。切り分けには、公開しても問題のないテスト用OBJや、同じ構造を持つダミーデータを使用すると安全です。
エラーが返るまでの時間も判断材料になります。送信開始直後に413エラーが返る場合は、通信の入口が申告された容量を確認し、データを受信する前に拒否している可能性があります。ある程度送信が進んでから失敗する場合は、受信中の容量監視、一時保存領域、通信時間の上限なども確認が必要です。
システム構成を変更した直後に413エラーが始まった場合は、新しく追加された通信中継層の設定を確認します。以前は問題なく送れていた容量でも、中継構成の変更によって新しい上限が加わることがあります。変更前後の経路を比較し、どの層が増えたかを整理すると原因を特定しやすくなります。
原因3 アプリケーション側のアップロード制限に達している
通信の入口を通過した後も、アップロード処理を担当するアプリケーション側で容量を制限していることがあります。アプリケーションは、受信したOBJを案件情報や利用者情報と関連付け、保存先へ転送したり、解析処理を開始したりします。この処理を安定させるために、一つのファイルまたは一回の送信に上限を設けることがあります。
アプリケーション側の制限には、単一ファイルの最大容量と、送信全体の最大容量があります。OBJ本体が上限以内でも、MTLファイルや複数のテクスチャ画像を同時に送ると、リクエスト全体の上限を超える可能性があります。
一つずつ送れば成功するのに、複数ファイルをまとめて選択すると失敗する場合は、送信全体の容量制限を疑います。画面上で複数ファイルを選択できることと、その合計容量を受信できることは別の問題です。
また、画面上の事前チェックと、サーバー側の実際の上限が一致していない場合もあります。画面では大容量ファイルを選択できても、送信後にアプリケーションが拒否すれば、利用者はアップロードを完了できません。反対に、サーバー側では受信できるのに、画面側だけが小さな上限で選択を止めていることもあります。
管理者は、画面表示、利用者端末での入力チェック、Webサーバー、アプリケーション、保存先の各上限を一致させる必要があります。画面に表示する最大容量だけを変更し、内部設定を変更し忘れると、表示と実際の動作に食い違いが生じます。
大容量OBJをアプリケーションが一度にメモリーへ読み込む構成にも注意が必要です。ファイル全体を保持してから保存する処理では、複数の利用者が同時にアップロードした際にメモリー使用量が増加します。そのため、システムを保護する目的で上限が低く設定されていることがあります。
この場合、上限だけを引き上げると、413エラーは減っても、サーバー全体が不安定になる可能性があります。大容量ファイルを少しずつ読み取りながら保存する方式や、アップロード専用の保存領域へ直接送信する方式など、処理構成自体の見直しが必要になることもあります。
利用者向けのエラー表示も重要です。「アップロードに失敗しました」だけでは、容量超過なのか、通信障害なのか、ファイル形式の問題なのか判断できません。容量上限を超えた場合は、対象となった合計容量と上限を確認できる案内を表示すると、不要な再試行や問い合わせを減らせます。
原因4 OBJと関連ファイルの合計容量が大きい
点群OBJのアップロードでは、OBJ本体だけで容量を判断すると実際の送信量を見誤ることがあります。OBJと一緒に、マテリアル情報を記録したファイル、テクスチャ画像、補助情報などを送信する場合、それらを含めた合計容量が判定対象になるためです。
たとえば、OBJ本体が上限以内に収まっていても、複数の高解像度テクスチャを追加すると合計容量が大きくなります。特に色付き点群や写実的なメッシュでは、OBJ本体よりもテクスチャ画像の合計容量が大きくなる場合があります。
ZIP形式へ圧縮して送信する場合も、必ず容量を確認します。OBJは文字情報が多いため圧縮によって小さくなりやすい一方、すでに圧縮された画像は、ZIPへまとめても容量が大幅に減らないことがあります。画像が多い構成では、圧縮前と圧縮後の差が想定より小さい可能性があります。
フォルダー全体をそのまま圧縮すると、不要なファイルまで含まれることがあります。作業途中の出力、古いテクスチャ、確認用画像、別の測定範囲、複製されたOBJなどが混在していると、本来必要のないデータがアップロード容量を消費します。
容量を減らす際は、OBJから実際に参照されている関連ファイルだけを残します。ただし、不要だと判断してファイルを削除すると、アップロード後に色や質感が表示されなくなることがあります。OBJ、マテリアル情報、テクスチャ画像の参照関係を確認し、削除後に別の環境で表示できるかを確かめることが大切です。
ZIPの中に不要な階層が含まれている場合も整理します。複数の親フォルダーや一時フォルダーが重なっていると、展開後の参照関係が崩れる可能性があります。OBJと関連ファイルの位置関係を保ちながら、必要最小限の構成に整えます。
なお、アップロード上限の判定は圧縮後の容量で通過しても、保存先でZIPを展開した後の容量が別の上限を超えることがあります。圧縮前の総容量、圧縮後の容量、展開後のファイル数を把握し、送信と保存の両方に余裕があるかを確認します。
原因5 大容量ファイルを一括送信している
点群OBJを一回の通信でまとめて送信する方式では、ファイル全体が一つのリクエストとして扱われます。サーバーが一回に受信できる容量をOBJが超えていれば、通信速度が速くても413エラーを回避できません。
大容量ファイルに適した方法として、ファイルを小さなデータ片に分けて送信する方式があります。一定の容量ごとに分割して個別に送信し、すべての受信が完了した後に保存先で元のファイルへ結合します。一回の送信量を小さくできるため、単一リクエストの上限に達しにくくなります。
ただし、利用者がOBJを複数ファイルに分けるだけでは、必ずしも解決しません。複数ファイルを選択した後、システムが一つのリクエストへまとめて送信している場合は、合計容量が上限を超える可能性があります。複数選択できる機能と、通信単位を分ける機能は同じではありません。
システムが分割送信に対応している場合は、送信済みの範囲を記録し、一部が失敗したときにその部分だけを再送できると効率的です。現場回線では、移動や電波状況によって通信が一時的に切れることがあります。最初からすべてを送り直す方式では、大容量になるほど完了しにくくなります。
再開送信へ対応していれば、通信が切れた位置から残りを送ることができます。これにより、容量上限だけでなく、通信時間や回線の不安定さによる失敗も減らせます。
システムが分割送信に対応していない場合は、点群OBJ自体を測定範囲ごとに分割し、それぞれを別のデータとして送信する方法が現実的です。その際は、各ファイルの座標基準、原点、縮尺、向きを統一し、後から重ね合わせられる状態を維持します。
また、分割送信で413エラーを回避できても、結合後のファイルを解析する処理や表示機能が大容量に対応していなければ、アップロード後に別の問題が生じます。送信だけでなく、保存、変換、表示、共有まで含めて処理可能な容量を確認することが重要です。
点群OBJの容量を増やす主な要素
点群OBJの容量を適切に減らすには、何がファイルサイズを増やしているのかを理解する必要があります。単純に圧縮率だけを見るのではなく、頂点数、面数、記録項目、関連ファイルを分けて確認します。
最も大きな影響を与えやすいのは頂点数です。OBJでは、各頂点の座標が一行ずつ記録されます。点密度が2倍になれば、測定範囲や記録内容によっては頂点情報も大きく増加します。広い現場全体を高密度で出力すると、数百万点以上になることもあります。
座標値の桁数も容量へ影響します。各頂点に長い小数が記録されている場合、頂点数が多いほど文字数の差が全体へ積み重なります。ただし、小数桁を減らすと位置や形状が丸められるため、必要精度を確認せずに変更してはいけません。
色情報を頂点ごとに持たせる構成では、座標値に加えて色の値が記録されます。色付き点群は視認性が高い一方、位置情報だけの点群より容量が増える可能性があります。業務上、色が必要かどうかを判断することが大切です。
点群からメッシュを生成している場合は、面数が容量を増やします。頂点数が同じでも、細かな三角形を大量に持つOBJは、面を持たない点群OBJより大きくなります。法線やUV座標を含める場合は、その情報と索引も追加されます。
テクスチャ画像は、解像度、枚数、圧縮方法によって容量が変わります。現場全体を高解像度の画像で表現すると、画像だけで大容量になることがあります。拡大表示をほとんど行わない共有用データに、最高品質の画像を付ける必要があるかを検討します。
不要な範囲やノイズも容量を増やします。測定対象の周囲にある地面、空、車両、作業員、仮設物などが大量に含まれていると、業務に使わない点がファイル容量を消費します。取得後の編集で削除できるものは、アップロード前に整理します。
容量対策1 不要な点と範囲を削除する
点群OBJを軽量化する際は、最初から全体の点密度を下げるのではなく、業務に不要な範囲を削除する方法から検討します。不要部分の削除は、必要な対象物の精度を維持しながら容量を減らしやすい対策です。
現場で点群を取得すると、対象物だけでなく、その周囲の地面、壁、空、資材、車両、作業員などが含まれることがあります。施工対象や確認範囲が明確であれば、対象外の部分を切り取ることで大きく容量を減らせる場合があります。
遠く離れた場所に少数だけ残った孤立点も確認します。反射や移動物などの影響で、測定対象から離れた位置に点が発生することがあります。これらの点があると、表示時に全体範囲が不自然に広がり、閲覧しにくくなるだけでなく、不要な容量も増えます。
近い位置に重複している点も整理対象です。複数回の測定を統合した際に、同じ面へ大量の点が重なる場合があります。必要以上に密集した点を整理すれば、形状を大きく変えずに容量を減らせる可能性があります。
ただし、自動処理で孤立点や重複点を削除すると、細い部材、鋭い角、小さな突起など、必要な形状まで除去されることがあります。削除条件を強くしすぎず、処理後に対象物の輪郭や寸法を確認します。
不要範囲を削除する前には、元データを別に保存します。軽量化したOBJだけを残すと、後から別の範囲が必要になった場合に再取得しなければなりません。元データは保管用、切り出したデータは共有用として区別すると安全です。
切り出す単位は、現場の管理方法に合わせます。工区、階、部屋、構造物、施工区分などで分けると、関係者が必要なデータを選びやすくなります。単に容量だけを基準に切ると、対象物が途中で分断され、確認しにくいデータになる可能性があります。
容量対策2 頂点数と面数を適切に削減する
不要範囲を削除しても容量が大きい場合は、頂点数や面数を減らします。点群の軽量化では、近接する点を一定の間隔で整理し、代表となる点を残す方法が一般的です。
点数を減らす際に重要なのは、利用目的に必要な精度を先に決めることです。現場全体の形状や大まかな進捗を確認する用途と、小さな段差や部材位置を確認する用途では、必要な点密度が異なります。
全体表示用のデータであれば、多少点密度を下げても視認性を保てることがあります。一方、出来形確認や細部の寸法確認に使用するデータでは、点を減らしすぎると角部や段差の形状が変わる可能性があります。
一律に同じ割合で削減するのではなく、平坦な面は強めに削減し、形状変化の大きい部分は点を多く残す方法も有効です。平面上では多くの点を必要としない場合がありますが、曲面や角部では点が少ないと形状を表現しにくくなります。
メッシュを含むOBJでは、面数の削減も検討します。細かな三角形を統合すると、面の索引情報を減らせます。ただし、面を減らしすぎると、曲面が粗く見えたり、小さな凹凸が失われたりします。
点数や面数を削減した後は、元データとの比較を行います。全体の位置、外形、主要寸法、基準点、段差、開口部、角部などを確認し、業務上必要な特徴が維持されているかを判断します。
ファイル容量だけを見て軽量化の成否を決めてはいけません。容量が大幅に減っても、必要な精度を満たせなければ実務には使用できません。削減後のデータを実際の閲覧環境へ読み込み、表示速度と品質の両方を確認することが重要です。
また、座標値の小数桁を減らす方法もありますが、慎重な判断が必要です。必要以上に長い小数が記録されている場合は容量を抑えられる可能性がありますが、桁数を減らすと座標が丸められます。用途に必要な位置精度を確認し、影響を評価したうえで設定します。
容量対策3 テクスチャと関連ファイルを整理する
OBJ本体の軽量化だけで十分な効果が得られない場合は、テクスチャ画像と関連ファイルを見直します。色や質感を再現するための画像は、点群やメッシュの視認性を高めますが、解像度や枚数によっては全体容量の大部分を占めます。
最初に、アップロード後の用途を確認します。形状、距離、面積、体積、断面などの確認が中心であれば、最高解像度のテクスチャが必要とは限りません。関係者が全体を把握するための共有データであれば、画像解像度を下げても実用上問題がない場合があります。
一方、ひび割れ、表面状態、材料の違いなどを画像で確認する用途では、解像度を下げすぎると必要な情報が失われます。容量削減の前に、どの程度の拡大表示を行うかを決めます。
テクスチャを軽量化するときは、元画像を上書きせず、共有用の複製を作成すると安全です。高品質な元データを保管し、アップロード用だけを軽量化すれば、詳細確認が必要になったときにも対応できます。
画像の枚数も確認します。複数の作業段階で生成されたテクスチャが同じフォルダーへ残っていると、使用されていない画像までアップロード対象になることがあります。マテリアル情報から参照されている画像だけを残します。
ファイルを削除または移動した後は、OBJを別の環境で開いて表示を確認します。作業した端末では一時情報によって画像が表示されていても、アップロード先では参照先が見つからず、色が反映されない場合があります。
ファイル名を変更する際も、参照関係の更新が必要です。OBJが参照するマテリアルファイル名や、マテリアル情報が参照する画像名が一致していなければなりません。容量整理と同時に名前を変更するときは、参照先の記述も含めて確認します。
色が必要ない業務では、テクスチャを含まない軽量版を用意する方法があります。形状確認用と写実表示用を分けることで、日常的な共有では小さなデータを使い、必要な場合だけ高品質版を利用できます。
容量対策4 OBJを範囲別や用途別に分割する
一つのOBJへ現場全体をまとめると、アップロード容量だけでなく、閲覧時の読み込み時間や端末負荷も大きくなります。上限を繰り返し超える場合は、データを範囲別または用途別に分割する方法が有効です。
範囲別に分割するときは、工区、階、区画、部屋、構造物、測定日など、実際の業務で使用する単位に合わせます。関係者が必要な範囲だけを開けるため、ダウンロード時間や表示負荷も抑えられます。
単純に同じ点数になるよう分割すると、一つの構造物が複数ファイルへまたがる可能性があります。形状や進捗を確認しやすい境界を選び、現場図面や施工区分と対応させることが大切です。
分割後のOBJを重ね合わせる可能性がある場合は、すべてのファイルで座標基準を統一します。ファイルごとに異なる原点へ移動すると、単体では正しく見えても、複数データを読み込んだ際に位置が合わなくなることがあります。
大きな座標値を避ける目的でローカル原点を使用する場合は、原点の位置、変換方法、基準点などを記録します。担当者ごとに異なる原点を使用すると、後から統合する際に位置調整が必要になります。
境界部分に少し重なりを持たせる方法もあります。隣接区画を完全に分断すると、接続部の形状を確認しにくくなることがあります。適度な共通範囲を残せば、隣接するOBJの位置関係を確認しやすくなります。
ただし、重複範囲を広くしすぎると、分割後の合計容量が増えます。接続確認に必要な範囲だけを重ねることが重要です。
用途別の分割も効果的です。全体確認用の低密度版、詳細確認用の高密度版、色付き表示用、形状だけの軽量版などを作成します。利用者は目的に合ったデータだけを扱えるため、常に最大容量のOBJを送信する必要がなくなります。
ファイル名には、案件、範囲、取得日、用途、版などを含めます。どのデータが最新か、どの範囲を示すかを開かずに判断できれば、分割によってファイル数が増えても管理しやすくなります。
容量対策5 サーバー側の上限を整合させる
利用者側で不要範囲や点数を整理しても、業務上必要なOBJが上限を超える場合は、システム側の設定を見直します。重要なのは、一つの設定だけを変更するのではなく、アップロード経路に存在するすべての上限を確認することです。
確認対象には、通信の入口、リバースプロキシ、セキュリティ機能、Webサーバー、アプリケーション、一時保存領域、最終的な保存先などがあります。各層の上限を一覧化し、最も小さい値を特定します。
画面に表示する最大容量も、実際の上限と一致させます。画面では大容量に対応しているように見えるのに、内部では小さな上限のままになっていると、利用者は送信後に初めて失敗を知ることになります。
設定値には一定の余裕を持たせます。OBJ本体だけでなく、関連ファイル、フォーム情報、送信時の付加情報が含まれるため、想定する最大ファイルと同じ値では境界付近で失敗する可能性があります。
一方、上限を必要以上に大きくするのは適切ではありません。大容量リクエストを無制限に近い状態で受け付けると、サーバー資源が消費され、ほかの利用者の処理へ影響する可能性があります。業務上必要な最大容量と同時利用数を基に、安全な範囲を設定します。
容量上限を引き上げる際は、一時保存領域も確認します。アップロード中のデータを一時的にディスクへ置く構成では、同時送信が増えると必要容量も増加します。保存領域に余裕がなければ、容量上限以内でも失敗することがあります。
処理時間の上限も合わせて見直します。大容量OBJは送信に時間がかかるため、容量制限を通過しても、完了前に接続が終了する可能性があります。通信時間、受信後の変換時間、解析時間を含めて検証します。
設定変更後は、複数の容量で試験します。小容量、標準容量、上限付近、上限超過のOBJを用意し、想定どおりに成功または拒否されるかを確認します。上限を超えた場合に、利用者へ分かりやすい案内が表示されることも大切です。
複数台のサーバーを使用している場合は、すべての処理先で同じ試験を行います。一部だけ古い設定が残ると、同じファイルでも結果が不安定になります。設定値の確認だけでなく、実際の通信を通した試験が必要です。
413エラーが出たときの切り分け手順
413エラーが発生したら、最初に失敗した条件を記録します。ファイル名、OBJ本体の容量、関連ファイルを含む合計容量、圧縮後の容量、利用した回線、操作日時、表示されたエラー文を残します。
次に、同じ環境で小さなOBJを送信します。小容量ファイルが成功する場合は、認証や基本的な通信経路は動作しており、容量に関する制限が原因である可能性が高まります。小容量でも失敗する場合は、権限、形式、通信障害なども確認します。
容量の異なる複数ファイルを使い、成功と失敗の境界を調べます。ある容量までは成功し、それを超えると毎回失敗する場合は、固定された上限が存在する可能性があります。比較には、できるだけ同じ形式と構成のOBJを使用します。
OBJ単体と、関連ファイルを含む状態も比較します。OBJだけなら成功し、テクスチャを追加すると失敗する場合は、合計容量の上限や複数ファイル送信の制限が考えられます。
ZIPで送る場合は、圧縮後の容量を確認します。圧縮前のフォルダー容量だけを見て判断すると、実際の送信量を把握できません。また、ZIP内に不要なファイルが含まれていないかも確認します。
承認された範囲で異なる通信経路を使い、同じテストデータを送信します。特定の回線だけで失敗する場合は、その経路にある中継層やプロキシの設定を確認します。どの回線でも同じ容量を境に失敗する場合は、共通するサーバー側の上限を疑います。
管理者は、Webサーバーとアプリケーションの記録を同じ時刻で確認します。Webサーバーに413の記録があり、アプリケーションには受信記録がない場合は、アプリケーションより前で拒否されています。アプリケーションまで到達している場合は、内部の受信制限や保存処理を調査します。
設定変更後は、同じファイルを再度送信します。ファイルも同時に変更すると、設定変更と軽量化のどちらが効果を持ったのか判断できません。原因を特定するためには、一度に変更する条件を減らすことが重要です。
容量対策で避けたい失敗
413エラーを急いで解消しようとして、点群OBJを必要以上に軽量化すると、業務に必要な情報が失われる可能性があります。ファイルが送信できることだけを目標にせず、アップロード後に目的を達成できるかを確認します。
特に注意したいのが、点数を大幅に削減して細部が消えるケースです。平坦な面では変化が少なく見えても、角部、段差、開口、細い部材などは点密度の影響を受けやすくなります。
座標値の小数桁を減らしすぎることにも注意が必要です。見た目では違いが分かりにくくても、寸法確認や重ね合わせでずれが生じる可能性があります。必要精度を決めずに桁数を変更してはいけません。
テクスチャ画像を削除した結果、現場状況を識別できなくなることもあります。色が必要ない用途では問題ありませんが、材料、施工状態、対象物の区別に色を使う場合は、画像品質を保つ必要があります。
ファイルを分割した後に座標基準が変わる失敗もあります。各OBJを個別に見やすくするため原点を変更すると、後から重ね合わせられなくなる可能性があります。分割前に座標管理方法を決めます。
サーバー側の上限を大幅に引き上げるだけの対応も避けます。受信できる容量が増えても、一時保存領域やメモリー、解析処理が対応できなければ、別の障害へ変わるだけです。アップロード後の処理まで含めて確認します。
また、元データを残さず軽量版へ上書きすることも避けるべきです。軽量化後に不足が見つかっても、元の点や画像を復元できない場合があります。元データ、編集用、共有用を分けて保管します。
点群OBJアップロードを安定させる運用方法
413エラーを再発させないためには、アップロード直前だけでなく、点群の取得から出力、保存までの流れを整える必要があります。
まず、用途ごとに標準的な出力条件を決めます。全体確認用、詳細確認用、共有用、長期保管用などで、必要な点密度、面数、テクスチャ品質、分割単位を定めます。担当者ごとに異なる設定で出力すると、同じ規模の現場でも容量に大きな差が生じます。
案件開始時には、測定範囲と想定容量を確認します。広い範囲を高密度で取得する場合は、最初から工区ごとに分けることを検討します。取得後に大きなOBJを無理に分割するより、管理単位を意識して計測した方が整理しやすくなります。
アップロード前の確認工程も標準化します。OBJ本体の容量、関連ファイルの合計、ZIPの容量、不要ファイルの有無、座標基準、表示確認などを一定の手順で確認します。
過去のアップロード結果を記録することも有効です。ファイル容量、送信時間、利用した回線、成功または失敗の結果を蓄積すると、現場で安定して送れるデータ量の目安が分かります。
容量上限以内でも送信に長時間かかる場合は、実務上の適正容量を見直します。技術的に送信できる最大値と、現場で安定して運用できる値は同じとは限りません。回線が不安定な現場では、小さく分割した方が再送の負担を減らせます。
システム側では、413エラーの発生回数や失敗容量を確認します。大容量エラーが増えている場合は、利用者の操作だけでなく、点群利用の拡大に対してシステム設計が合わなくなっている可能性があります。
ネットワークやサーバー構成を変更した際には、テスト用OBJでアップロード試験を行います。実際の案件で初めて問題が分かる状態を避けるため、標準容量と上限付近のファイルを用意しておくとよいでしょう。
LRTK Phoneで点群取得から共有までを整える
点群OBJの容量対策は、ファイルをアップロードする直前だけの作業ではありません。取得する範囲、点群の密度、成果物の用途を計測前に整理すると、不要に大きなOBJの生成を抑えやすくなります。
LRTK Phoneで点群を取得する場合も、最終的に誰がどの範囲を確認するのかを考えながら計測単位を決めることが重要です。現場全体を一つのデータとしてまとめる必要がない場合は、工区、構造物、施工段階などで取得や出力を分けます。
対象範囲を明確にすれば、不要な周辺物や遠方の点が含まれにくくなり、後工程での切り出し作業を減らせます。共有先が必要とする範囲だけをOBJとして出力すれば、アップロード容量と閲覧負荷の両方を抑えられます。
取得日、対象、座標基準、出力条件などを統一して記録することも大切です。容量対策として複数のOBJへ分割しても、条件が記録されていれば位置関係や版を管理しやすくなります。
全体確認には軽量版を使用し、細部の確認が必要な範囲だけ高密度版を用意する運用も有効です。すべての関係者が常に最大容量のデータを扱う必要がなくなり、点群OBJアップロードの失敗を減らせます。
計測、編集、出力、アップロードを別々の作業として考えるのではなく、一連のデータ管理として整えることが重要です。LRTK Phoneを用いた点群取得から共有までの手順に、容量確認や分割ルールを組み込むことで、413エラーが起きにくい運用につながります。
まとめ
点群OBJアップロードで表示される413エラーは、送信するリクエストの容量が、通信経路やサーバーに設定された上限を超えた場合に発生する代表的なエラーです。OBJが壊れていなくても、Webサーバー、リバースプロキシ、通信中継層、アプリケーションなどのいずれかが受信を拒否すれば、アップロードは完了しません。
原因を調べる際は、OBJ本体だけでなく、MTLファイル、テクスチャ画像、ZIPなどを含めた送信全体の容量を確認します。小さなOBJとの比較、成功と失敗の容量境界、異なる回線での結果、サーバー記録を順番に確認すると、どの層で拒否されているかを絞り込みやすくなります。
利用者側で行える容量対策には、不要範囲や孤立点の削除、頂点数と面数の削減、テクスチャの軽量化、関連ファイルの整理、範囲別または用途別の分割があります。ただし、必要な精度や色を失わないよう、軽量化後の形状、寸法、座標、表示状態を確認することが欠かせません。
システム側では、アップロード経路に存在するすべての上限を洗い出し、画面表示と実際の設定を一致させます。上限を引き上げる場合は、一時保存領域、メモリー、通信時間、同時利用数、解析処理なども含めて検証する必要があります。
413エラーを防ぐには、アップロード時だけでなく、点群を取得する段階から対象範囲、点密度、出力単位、関連ファイルの構成を管理することが重要です。現場での計測から点群OBJの共有までを効率化する方法として、LRTK Phoneを活用した運用も検討してみてください。