点群OBJアップロードで見積もりが必要な理由
点群や三次元計測データから作成したOBJをクラウド環境や共有用のサーバーへアップロードするときは、事前に通信量と所要時間を見積もっておく必要があります。数百MB程度のデータであれば短時間で送信できることもありますが、高密度な形状や多数のテクスチャ画像を含むデータは数GBから数十GBになる場合があります。
容量を確認しないままアップロードを始めると、現場から事務所へ戻る時間になっても送信が終わらない、モバイル回線の通信量を想定以上に消費する、通信が途中で切れて最初からやり直すといった問題が起こりやすくなります。アップロード後に変換処理が必要な仕組みでは、送信が完了してもすぐに閲覧できるとは限りません。
OBJは、頂点座標や面の構成などを文字情報として記録する形式です。点群から作成したデータであっても、書き出し時には点だけではなく三角形の面、法線、テクスチャ座標などが含まれることがあります。さらに、材質情報を記録した関連ファイルや、表面の色を表現するテクスチャ画像が別ファイルとして生成される場合があります。
このため、OBJ本体の容量だけを見ても、実際にアップロードする通信量は判断できません。OBJ本体が比較的小さくても、高解像度のテクスチャ画像が数十枚に分割されていれば、付属ファイルのほうが大きくなることがあります。反対に、テクスチャを持たない単色の形状データであれば、OBJ本体が通信量の大部分を占めます。
通信時間を見積もるときには、データ容量と回線速度だけでなく、通信の安定性、送信処理の効率、再送の有無、アップロード先での処理時間を分けて考えることが重要です。理論上の計算時間と、実際の作業完了時間には差が生じます。
実務では、ぴったりの完了時刻を当てることよりも、作業計画に使える安全側の時間を求めることが大切です。予定より少し早く終わる見積もりは問題になりにくい一方、予定時間を大幅に超える見積もりは、次工程や現場の撤収計画に影響します。
ここでは、点群OBJアップロードの通信量と所要時間を見積もるための5つの目安を、具体的な計算方法とともに解説します。
目安1 アップロード対象の総容量を確認する
最初に確認するのは、アップロード対象となるファイル一式の総容量です。通信時間は送信するデータ量にほぼ比例するため、容量の把握が見積もりの出発点になります。
確認対象はOBJ本体だけではありません。同じフォルダに保存されている材質情報のファイル、テクスチャ画像、付属する設定ファイルなども含めて合計します。アップロード時にフォルダを圧縮する場合は、圧縮後のファイル容量を確認します。個別ファイルをそのまま選択して送信する場合は、選択対象全体の容量を確認します。
たとえば、OBJ本体が2GB、テクスチャ画像が3GB、関連ファイルが数MBであれば、通信量の基準は約5GBです。OBJ本体だけを見て2GBとして計算すると、実際の所要時間を半分以下に見積もることになります。
書き出し先のフォルダに、過去の出力データや不要な中間ファイルが混在している場合にも注意が必要です。フォルダごとアップロードすると、閲覧には使わないファイルまで送信対象に含まれる可能性があります。出力後はアップロード専用のフォルダを用意し、必要なファイルだけが入っている状態にすると確認しやすくなります。
通信量を管理する際は、ファイル容量の単位にも注意します。一般的な画面では、MBやGBとして表示されますが、計算方法によっては1GBを1000MBとして扱う場合と、1024MBとして扱う場合があります。現場での概算では1GBを1000MBとして計算すれば十分ですが、表示された容量と計算結果にわずかな差が出ることは理解しておく必要があります。
また、アップロードしたデータを別の端末でダウンロードしたり、複数人に配布したりする場合は、アップロード以外の通信量も発生します。送信だけで完結する運用なのか、送信後に確認用端末へ再度取得するのかによって、業務全体で必要となる通信量は変わります。
通信量の見積もりでは、最低でもアップロード容量と同じだけの送信通信が発生すると考えます。ただし、通信が切断されて一部を再送した場合や、アップロードの再試行を行った場合は、実際の通信量が元データの容量を上回ります。
モバイル回線を利用する場合は、同じ月に送信する案件数も考慮します。1回のアップロードが5GBであっても、月に10回行えば単純計算で50GBになります。さらに、再送や確認用データの取得が加われば、必要な通信量は増えます。
単発の作業だけを見るのではなく、1案件当たりの平均容量と月間の案件数を掛け合わせると、回線運用の計画が立てやすくなります。現場ごとの容量を記録しておけば、似た規模の案件で過去の実績を利用できます。
OBJの容量は、測定した範囲の広さだけでは決まりません。点や面の密度、表面形状の複雑さ、法線の有無、テクスチャ画像の解像度、画像の枚数などによって大きく変わります。同じ建物を対象にしても、出力条件の違いによって数倍の容量差が生じることがあります。
そのため、作業前に面積だけで容量を予測する方法には限界があります。最も確実なのは、実際に出力したファイル一式の容量を確認することです。作業前に概算する必要がある場合は、過去に同じ設定で出力した類似案件の容量を基準にします。
通信時間を正しく計算するためには、まず何を送るのかを確定し、その合計容量を把握することが第一の目安です。
目安2 回線の上り実効速度を測る
データ容量の次に確認するのが、アップロードに使用する回線の上り速度です。ここで重要なのは、契約上の最大速度や端末に表示される通信方式ではなく、実際の場所と時間帯で測定した上り実効速度を使うことです。
インターネット回線の速度には、受信する下り速度と、送信する上り速度があります。ウェブサイトの閲覧や動画視聴では下り速度が重視されますが、OBJのアップロードでは上り速度が所要時間を左右します。
下り速度が十分に速くても、上り速度が同じとは限りません。速度測定を行うときは、必ず上り側の測定結果を確認します。
同じ現場でも、測定する場所や時刻によって速度は変化します。屋外では安定していても、建物内、地下、山間部、構造物の陰などでは電波が弱くなることがあります。利用者が多い時間帯には、電波表示が良好でも速度が低下する場合があります。
一度の測定値だけで判断せず、数回測って低めの値を見積もりに使うと安全です。たとえば、上り速度が18Mbps、12Mbps、8Mbpsと変動した場合、平均値だけでなく8Mbps程度でも完了できる計画を考えます。
速度の単位にも注意が必要です。ファイル容量はMBやGBで表示される一方、通信速度はMbpsで表示されることが一般的です。大文字のBはバイト、小文字のbはビットを表し、1バイトは8ビットです。
この単位差を考慮せず、100MBのファイルを10Mbpsで10秒と計算すると、大きな誤差が生じます。100MBは約800Mbなので、通信効率を無視した理論上の時間でも約80秒が必要です。
実際のアップロード速度は、測定結果として表示された数値を常に維持できるわけではありません。通信の制御情報、暗号化、データの分割、応答待ちなどにより、ファイル容量だけを回線速度で割った理論値より長くなります。
また、速度測定では短時間だけ高い速度が出ても、大容量ファイルを長時間送信すると速度が変化する場合があります。数GBを超えるアップロードでは、瞬間的な最高値よりも、一定時間継続して維持できる速度のほうが重要です。
可能であれば、小さめの実データを試験的にアップロードし、実際の送信速度を確認します。たとえば、500MB程度のデータに何分かかったかを測れば、同じ環境で5GBを送信する時間をある程度推定できます。
500MBの送信に5分かかった場合、単純に考えると1分当たり約100MBです。通信状態が同程度で続けば、5GBでは約50分が基準になります。ただし、長時間の通信では速度低下や瞬断が起こる可能性があるため、さらに余裕を加えます。
事務所の固定回線を使用する場合も、回線の公称値だけで判断しないことが大切です。同じ回線を複数人が利用していると、他の端末によるデータ送受信の影響を受けます。オンライン会議、クラウド同期、大容量ファイルの取得などが同時に行われると、OBJに使える上り速度が低下します。
無線接続では、回線そのものが速くても、端末と通信機器の距離や遮蔽物によって速度が落ちることがあります。大容量データを送るときは、電波状態が安定する位置を選び、可能であれば通信中に端末を移動させないようにします。
回線の上り速度は一定の固定値ではなく、変動する数値です。見積もりでは最高速度を使わず、実測した中で無理なく維持できる速度を採用することが第二の目安になります。
目安3 容量と速度から基準時間を計算する
総容量と上り実効速度が分かれば、アップロードの基準時間を計算できます。概算には次の式を使います。
基準時間の秒数＝総容量のMB数×8÷上り速度のMbps
たとえば、総容量が1000MBで、上り速度が10Mbpsの場合は、1000×8÷10で800秒です。800秒は約13分20秒になります。
ただし、これは通信効率を100％として計算した理論上の時間です。実際には制御情報や速度変動があるため、13分20秒ぴったりで終わるとは限りません。
容量をGBで計算する場合は、1GBを1000MBとして、次のように概算できます。
基準時間の秒数＝総容量のGB数×8000÷上り速度のMbps
総容量が5GBで、上り速度が20Mbpsの場合は、5×8000÷20で2000秒です。2000秒は約33分20秒です。
この結果は、通信が一定速度で続き、再送も発生しない場合の基準です。実務では、通信効率を考慮した補正を行います。
たとえば、実際にファイル送信へ使える速度を、測定した上り速度の70％として見積もる方法があります。この場合、上り速度が20Mbpsであっても、計算上は14Mbps程度として扱います。
5GBを14Mbpsで送る場合は、約2857秒となり、約48分です。さらに、通信の揺らぎや操作時間を考慮して余裕を加えると、作業計画上は1時間程度を確保する判断ができます。
通信効率をどの程度に設定するかは、回線環境やアップロード方法によって異なります。安定した固定回線で過去の実績がある場合は、理論値に近い結果になることがあります。一方、速度が大きく変動するモバイル回線では、理論値との差が広がることがあります。
実務で使いやすい方法は、理論時間を計算した後に、安全率を掛ける方法です。安定した回線では理論時間の1.2倍程度、変動が予想される回線では1.5倍以上を一つの検討材料にします。ただし、これらは一律の保証値ではなく、過去の実績に合わせて調整するための目安です。
たとえば、理論時間が40分で、比較的安定した環境なら48分程度を基準にできます。通信が不安定な現場では60分以上を確保するなど、回線条件に応じて計画します。
所要時間を計算するときは、アップロード時間と、その後の処理時間を分けて記録します。送信画面が100％になった時点でアップロードが完了しても、サーバー側でデータの展開、形状の解析、表示用データへの変換が行われる場合があります。
アップロードに50分、変換に30分かかる場合、データを確認できるまでの合計時間は80分です。アップロードだけを見積もっていると、後工程の開始時刻を誤る可能性があります。
サーバー側の処理時間は、回線速度を上げても短縮できません。データ容量、形状の複雑さ、処理待ちの混雑状況などによって変化します。初めて利用するアップロード先では、小規模データで処理完了までの流れを確認しておくと安全です。
また、表示される進捗率が、純粋なファイル転送だけを表しているとは限りません。ファイルの確認や事前処理を含めて進捗を表示する仕組みもあるため、100％になるまでの時間を通信速度だけで正確に説明できない場合があります。
作業計画では、「送信開始からアップロード完了まで」と「送信開始から閲覧可能になるまで」の二つを区別します。現場を退出できる時刻を知りたいのか、別の担当者がデータを確認できる時刻を知りたいのかによって、必要な見積もりは異なります。
容量と上り速度から理論時間を求め、通信効率と安全率を加え、サーバー処理時間を別枠で考えることが第三の目安です。
目安4 通信の揺らぎと再送分を上乗せする
実際の通信量と所要時間は、ファイル容量を回線速度で割った結果だけでは決まりません。通信状態が不安定な場合は、データの一部が正常に届かず、再送が発生することがあります。
再送されるデータは、元のファイル容量に追加される通信量です。5GBのデータをアップロードしている途中で一部の通信が失敗し、500MBが再送された場合、実際の送信量は約5.5GBになります。
アップロードが途中から再開できる仕組みであれば、失敗した部分だけを送り直せる可能性があります。一方、再開に対応していない場合や、接続状態が保存されない場合は、最初からやり直しになることがあります。
9割まで進んだ5GBのアップロードを最初からやり直すと、最終的な通信量は元データの約2倍近くになることもあります。モバイル回線では通信量への影響が大きいため、長時間の送信を始める前に再開機能の有無を確認しておくことが重要です。
通信の揺らぎは、電波表示だけでは判断できません。電波が十分に見えていても、瞬間的な混雑、端末の切り替え、建物内での反射、通信機器の負荷などによって、速度低下や一時停止が生じる場合があります。
移動中の車内などでアップロードすると、接続先の切り替えによって通信が不安定になりやすくなります。大容量のOBJを送る場合は、できるだけ同じ場所に端末を置き、安定した電源と通信環境を確保します。
端末の省電力設定や画面消灯後の動作にも注意が必要です。画面を消すと送信処理が一時停止する仕組みでは、計算上の時間より大幅に長くなることがあります。アップロード中に別の処理を行ったことで、利用可能なメモリや通信帯域が減少する場合もあります。
長時間アップロードでは、端末の電池残量も所要時間に関係します。送信途中で電源が切れれば、再送や再操作が必要になります。開始前に十分な電池残量を確認し、可能であれば電源へ接続した状態で実行します。
ただし、端末が高温になる環境では、充電と大容量通信を同時に行うことで温度が上昇し、処理速度が低下する可能性があります。直射日光の当たる車内や高温の屋外を避け、端末を安定して動作させられる場所を選びます。
通信量の余裕は、回線の安定性に応じて考えます。安定した環境では元データ容量に対して少し余裕を持つ方法で足りることがありますが、不安定な現場では再送を前提に大きめの余裕を確保します。
月間通信量の上限に近い状態で大容量OBJを送ると、途中で速度が制限される可能性もあります。開始時点では高速でも、送信中に条件が変われば、残り時間が急激に増えることがあります。
通信量に制約がある場合は、元データ容量と残り通信量を比較するだけでなく、再送分まで含めて送信可能かを判断します。たとえば、5GBのデータに対して残り通信量が5GBしかない状態では、少しでも再送が起これば不足する可能性があります。
複数ファイルを個別にアップロードできる場合は、すべてを一度に送る方法と、分割して送る方法のどちらが安全かを検討します。分割送信なら、一つのファイルが失敗しても、そのファイルだけを再送できる場合があります。
一方、ファイル同士の関連性を保つ必要がある場合は、分割方法を誤るとテクスチャが表示されないなどの問題が起こります。通信上の都合だけで分割せず、OBJ本体と関連ファイルの対応関係を維持します。
理論時間に加えて、通信の変動、再送、端末の動作、月間通信量の残量まで考えることが第四の目安です。
目安5 出力条件を調整して待ち時間を減らす
見積もったアップロード時間が長すぎる場合は、回線を変更するだけでなく、OBJの出力条件を見直す方法があります。必要な精度や見た目を維持しながら容量を減らせれば、通信量と所要時間の両方を抑えられます。
容量に大きく影響するのが、形状を構成する頂点数と面数です。点群から非常に細かいメッシュを作成すると、頂点座標だけでなく、面の接続情報や法線なども増えます。
用途に対して過剰に細かい形状を出力している場合は、メッシュを適切に簡略化することで容量を減らせます。ただし、簡略化しすぎると、小さな段差、角部、設備の形状などが失われる可能性があります。
必要な細かさは、利用目的から決めます。概略形状を遠隔で確認する用途と、細部の納まりを確認する用途では、求められる密度が異なります。一つの高密度データをすべての用途に使うのではなく、確認用と保存用で出力条件を分ける方法もあります。
テクスチャ画像も容量を左右します。高解像度の画像を多数使用すると、形状データより画像データのほうが大きくなる場合があります。閲覧画面で必要となる解像度を考え、過剰な解像度になっていないかを確認します。
広い範囲を一つのOBJとして出力すると、容量が大きくなり、アップロード失敗時の影響も大きくなります。工区、階、区画、構造物などの単位で分割できる場合は、必要な範囲だけを送れる構成にすると運用しやすくなります。
ただし、分割することで座標の整合性が失われたり、境界部分に欠けや重複が生じたりしないよう注意が必要です。分割後も同じ座標系と基準位置を維持し、再配置しなくても重ね合わせられる状態が望まれます。
不要な範囲を削除することも効果的です。計測時に対象外の地面、周辺建物、空間中のノイズなどが含まれている場合、それらも頂点や面として容量を増やします。
対象範囲を切り出し、明らかな不要点や孤立した形状を整理してからOBJを書き出せば、必要な情報を保ちながら容量を抑えられることがあります。
圧縮ファイルとして送信できる場合は、OBJのような文字情報を含むデータで容量が減る可能性があります。ただし、すでに圧縮効率の高いテクスチャ画像は、まとめて圧縮しても大きく減らないことがあります。
アップロード先が圧縮ファイルに対応しているか、アップロード後に展開が必要か、関連ファイルの参照関係が維持されるかを事前に確認します。容量だけを小さくできても、展開後にOBJが正しく表示されなければ実務では使えません。
出力条件を変えたときは、容量だけでなく品質も確認します。形状の角が崩れていないか、必要な設備が欠けていないか、テクスチャが正しく対応しているか、座標が変わっていないかを確認します。
特に、外部の担当者へ渡すデータでは、軽量化したデータがどの用途を想定しているかを共有します。確認用に簡略化したOBJを、詳細計測や寸法確認に使われないようにするためです。
現場で取得した元データは高密度のまま保存し、アップロード用に軽量版を作成する運用も有効です。元データを失わず、通信環境に合わせたデータを用意できます。
容量を減らすことは、単なる待ち時間の短縮ではありません。アップロード失敗の可能性を下げ、再送による通信量の増加を抑え、受け取る側の閲覧負荷も軽減できます。
必要な品質を決めたうえで、面数、対象範囲、テクスチャ解像度、分割方法、圧縮方法を調整することが第五の目安です。
現場回線別に見積もりを考える
点群OBJのアップロード時間は、使用する回線の種類と利用環境によって大きく異なります。計算式は同じでも、見積もりに採用する速度と安全率を変える必要があります。
事務所などの固定回線では、長時間にわたって比較的安定した速度を得られることがあります。ただし、同じ回線を利用する人数や時間帯によって速度は変動します。
大容量OBJを定期的に送る場合は、業務時間中と利用者の少ない時間帯で速度を測り、どの時間帯が安定しているかを把握します。通信が集中する時間を避けるだけでも、所要時間を短縮できる場合があります。
現場のモバイル回線では、場所による差が大きくなります。作業場所では上り速度が遅くても、現場事務所や建物の外周部へ移動すると改善することがあります。
アップロードを始める前に、候補となる場所で速度を測定し、最も安定する位置を選びます。瞬間的に速い場所より、数回測って変動の少ない場所のほうが大容量送信に適しています。
複数の通信手段を利用できる場合は、速度だけでなく、通信量の条件と安定性を比較します。短時間で終わる回線でも通信量に余裕がなければ、再送時に不足する可能性があります。
現場での送信が難しい場合は、その場ですべてをアップロードする必要があるかを検討します。緊急確認に必要な軽量データだけを先に送り、詳細なOBJは安定した回線へ移動してから送る方法もあります。
たとえば、現場では対象範囲を絞った軽量版を送信し、事務所へ戻った後に保存用の高密度版をアップロードします。目的別に送信を分けることで、現場での待ち時間を減らせます。
回線を選ぶ際は、送信にかかる時間だけでなく、送信中に端末を占有する時間も考慮します。アップロード中に端末を別の計測や確認へ使えない場合、通信時間がそのまま作業停止時間になります。
アップロード専用の端末や通信環境を用意できれば、送信中も別の作業を続けられます。専用環境を用意できない場合は、昼休みや撤収準備中など、端末を使用しない時間に送信を進める計画が有効です。
回線環境ごとの実測値と過去の完了時間を記録しておくと、次回の見積もり精度が高まります。現場名、場所、時間帯、総容量、平均上り速度、アップロード時間、再送の有無を残しておけば、類似条件で参考にできます。
容量別の所要時間を概算する
ここでは、容量と上り速度によって所要時間がどの程度変わるかを文章で確認します。実際の時間は通信状態によって変動するため、以下の計算は作業計画を立てるための目安です。
総容量が1GBで、上り速度が10Mbpsの場合、理論時間は約13分20秒です。通信効率を70％程度として考えると約19分となり、さらに余裕を加えれば20分から30分程度を確保する判断になります。
同じ1GBでも、上り速度が2Mbpsであれば、理論時間は約1時間6分40秒です。通信効率や速度変動を考えると、1時間30分以上かかる可能性があります。
総容量が5GBで、上り速度が20Mbpsの場合、理論時間は約33分20秒です。通信効率を考慮すると50分前後となり、通信の揺らぎや操作時間を含めて約1時間を確保する方法があります。
同じ5GBを5Mbpsで送る場合、理論時間だけで約2時間13分です。実際には3時間以上かかる可能性があるため、現場で送信を続けるか、別の回線へ移動するかを検討する水準です。
総容量が10GBで、上り速度が50Mbpsの場合、理論時間は約26分40秒です。安定した環境なら1時間以内に終わる可能性がありますが、ファイルの確認処理やサーバー側の変換時間は別に必要です。
10GBを10Mbpsで送る場合は、理論時間が約2時間13分です。通信効率と安全率を考慮すると、3時間から4時間程度を想定することがあります。
総容量が20GBで、上り速度が50Mbpsの場合、理論時間は約53分20秒です。通信効率を70％として安全率を加えると、1時間30分から2時間程度を見込む計画が考えられます。
20GBを5Mbpsで送る場合は、理論時間だけでも約8時間53分です。速度が不安定で再送が発生すれば、営業時間内に終わらない可能性があります。
このように、容量が数倍になると時間もほぼ同じ割合で増えます。上り速度が半分になれば、所要時間はおおむね2倍になります。
計算結果が数時間を超える場合は、そのままアップロードを始める前に、軽量化、分割、回線変更、送信時間帯の変更を検討する価値があります。
特に現場からの送信では、計算上は完了できる場合でも、端末を長時間置いておけるか、電源を確保できるか、現場を施錠する時刻までに終わるかを確認します。
時間の見積もりは、単なる計算問題ではなく、現場運用の判断材料です。数値を出した後に、実際にその時間を確保できるかまで検討する必要があります。
アップロード前の確認手順
点群OBJをアップロードする前には、データ、通信、端末、アップロード先の順に確認すると抜けを防ぎやすくなります。
まず、アップロード対象のフォルダを開き、OBJ本体と関連ファイルがそろっていることを確認します。不要な過去データや中間ファイルが混ざっていないかも確認します。
次に、選択対象全体の容量を確認し、GBまたはMB単位で記録します。この数値が通信量と所要時間を計算する基準です。
続いて、実際にアップロードする場所で上り速度を測定します。複数回測定し、低めの値を見積もりに使います。
総容量と上り速度を計算式へ入れ、理論時間を求めます。その後、通信効率と安全率を考慮して、作業計画上の時間を決めます。
計算結果が許容できない場合は、開始前にデータを軽量化します。送信途中で容量が大きすぎると判断して中止すると、そこまでに使用した通信量と時間が無駄になります。
端末の電池残量、電源接続、空き容量、温度、画面消灯時の動作も確認します。アップロードに使う画面を閉じても処理が継続するか、事前に小さなデータで試しておくと安全です。
アップロード先については、1ファイル当たりの容量上限、ファイル数の上限、対応する関連ファイル、途中再開の可否を確認します。データを送信してから容量上限を超えていることが分かると、出力や分割をやり直す必要があります。
アップロード開始後は、進捗率だけでなく、送信速度と残り時間の変化を確認します。残り時間が増え続けている場合は、回線速度が低下している可能性があります。
通信が完全に停止しているように見えても、すぐに操作を繰り返さないことが大切です。画面上の表示が更新されていないだけの場合もあるため、送信状態を確認してから再試行します。
完了後は、アップロードされた容量やファイル数を元データと照合します。OBJを開いて形状が欠けていないか、テクスチャが正しく表示されるか、座標や向きが変わっていないかを確認します。
送信完了の表示だけで作業を終えず、実際に利用できる状態になったことまで確認することで、後から再アップロードする手戻りを防げます。
失敗しやすい見積もりと対策
点群OBJアップロードの見積もりで多い失敗は、OBJ本体だけを容量として扱うことです。テクスチャ画像を含むデータでは、関連ファイルが総容量の大部分を占める場合があります。
対策は、個別ファイルではなく、アップロード対象全体の容量を確認することです。圧縮して送る場合は、圧縮後の容量を使います。
次に多いのが、下り速度を使って時間を計算することです。閲覧時の通信が速くても、上り速度が遅ければアップロードには時間がかかります。
速度測定結果を見る際は、送信側の数値を確認します。表示項目が分かりにくい場合は、実際のファイルを短時間アップロードし、送信実績から速度を求めます。
最高速度をそのまま見積もりに使うことも失敗の原因です。数秒だけ記録された最高値は、数時間の送信で維持できない可能性があります。
複数回の測定結果から低めの数値を選び、理論時間に余裕を加えることで、現実的な計画になります。
アップロード時間とサーバー処理時間を混同するケースもあります。送信が完了していても、閲覧可能になるまで変換処理が続く場合があります。
送信完了時刻と利用可能時刻を分けて記録し、次工程の開始は利用可能時刻を基準にします。
ファイルを過度に軽量化し、必要な形状まで失うことにも注意が必要です。通信時間を短くすることが目的になり、データの利用目的を満たせなければ意味がありません。
軽量化前後のOBJを比較し、必要な部分の形状、座標、テクスチャが維持されていることを確認します。
反対に、保存用の最高密度データを毎回そのまま共有し、通信時間と閲覧負荷を増やしている場合もあります。保存用と確認用を分けることで、必要な品質を保ちながら運用を効率化できます。
アップロードを始める時刻にも注意します。数時間かかるデータを退勤直前や現場撤収直前に開始すると、途中で端末を移動する必要が生じます。
計算した時間に、準備、確認、再送の可能性を加え、端末を安定して置ける時間帯に開始します。
小容量ファイルを多数送信する場合は、合計容量が同じでも、一つの大きなファイルより時間がかかることがあります。各ファイルの開始処理や確認処理が繰り返されるためです。
ファイル数が非常に多い場合は、アップロード先の仕様を確認したうえで、一つの圧縮ファイルにまとめる方法も検討します。
ただし、圧縮後に関連ファイルの位置関係が変わると、OBJからテクスチャを参照できなくなる場合があります。まとめ方を変えたときは、展開後に正しく表示できることを確認します。
通信量と時間の見積もりは、計算式だけで完結しません。データ構成、回線の変動、端末の動作、アップロード先の処理を一つずつ確認することで、実務で使える見積もりになります。
まとめ
点群OBJアップロードの通信量と所要時間を見積もるには、まずOBJ本体だけでなく、材質情報やテクスチャ画像を含む送信対象全体の容量を確認します。
次に、アップロードを行う場所で上り実効速度を測定します。下り速度や公称上限ではなく、複数回測定した中から継続して利用できる速度を採用することが重要です。
基準時間は、総容量のMB数に8を掛け、上り速度のMbpsで割ることで概算できます。ただし、計算結果は理論値であるため、通信効率や速度変動を考慮した余裕を加えます。
通信が不安定な環境では、再送によって通信量と所要時間が増える可能性があります。途中再開の可否、端末の電源、省電力設定、月間通信量の残りなども事前に確認します。
見積もった時間が長すぎる場合は、形状の密度、対象範囲、テクスチャ解像度、分割方法を見直します。保存用の高密度データと、確認用の軽量データを分ける方法も有効です。
実務では、理論上の最短時間ではなく、作業終了までに確実に完了できる時間を見積もることが大切です。案件ごとの容量、実効速度、完了時間を記録しておけば、次回以降の見積もり精度も高まります。
点群OBJを効率よく共有するには、アップロードの直前だけでなく、計測範囲や出力条件を決める段階からデータ容量を意識する必要があります。現場で取得した三次元データをどのように整理し、必要な範囲をどのような品質で共有するかまで考えることで、通信待ちや再送による手戻りを抑えられます。
現場での計測からデータ確認、点群の活用、共有までを一連の流れとして見直す際は、LRTK Phoneを活用した三次元計測の方法もあわせて確認してみてください。