1GBの点群OBJアップロード時間はどれくらいか
1GBの点群OBJをアップロードする時間は、契約回線の最大速度ではなく、送信中に実際に維持できる上り速度で決まります。1GBを10進表記の1,000,000,000バイトとして計算すると、上り10Mbpsでの理論最短時間は約13分20秒です。実際には通信経路、無線品質、混雑、送信先の受付速度、通信制御などの影響があるため、15分から25分程度を初期の計画目安とする考え方があります。ただし、この幅は保証値ではなく、実測結果によって調整する必要があります。
上り速度が50Mbpsなら理論上は約2分40秒、100Mbpsなら約1分20秒です。実務では、50Mbpsで3分から6分程度、100Mbpsで2分から4分程度を見込むと計画を立てやすい場合があります。一方、上り速度が5Mbpsなら理論上でも約26分40秒かかるため、速度変動を含めると30分以上になる可能性があります。
ここでいう時間は、原則としてファイル本体の転送時間です。アップロード先でOBJの構文確認、頂点数の集計、面参照の検証、表示用データへの変換などが行われる場合、進捗表示が100％になってから閲覧できるまでに追加時間が発生します。転送が5分、変換が10分なら、利用開始までの総時間は約15分です。
正確な見積もりには、アップロードする場所で上り速度を複数回測り、短時間の最高値ではなく、低い側の値や長時間の平均値を使います。さらに、同じ端末、同じ通信経路、同じ送信先で過去に送った記録があれば、その実績が一般的な速度表よりも有効です。
なお、OBJは点群専用形式ではありません。頂点だけを並べたOBJを点群として扱えるか、点の大きさや頂点カラーを表示できるかは、アップロード先の実装によって異なります。容量と速度だけでなく、受け入れ仕様も事前に確認する必要があります。
アップロード時間を求める基本計算
アップロード時間の理論値は、ファイル容量をビットへ換算し、上り速度で割って求めます。通信速度のMbpsは1秒あたりのメガビットを表し、ファイル容量のGBやMBはバイト単位です。1バイトは8ビットなので、10進表記の1GBは8,000メガビットです。
計算式は「理論時間の秒数＝ファイル容量のメガビット÷上り速度Mbps」です。1GBを10Mbpsで送る場合は8,000÷10で800秒、つまり13分20秒です。20Mbpsなら400秒で約6分40秒、50Mbpsなら160秒で約2分40秒、100Mbpsなら80秒で約1分20秒となります。
GBとGiBは区別が必要です。1GBは10億バイト、1GiBは1,073,741,824バイトです。一部のOSやアプリでは、2進換算した容量を慣習的にGBと表示することがありますが、厳密には1GiBと表すのが適切です。1GiBを送る場合のデータ量は約8,590メガビットとなり、1GBとして計算した場合より約7.4％長くなります。NIST
実際の所要時間に一律の倍率を掛ければ必ず当たるわけではありません。通信方式、遅延、パケット損失、無線の再送、サーバー側の制限、ブラウザやアプリの実装によって差が大きいためです。運用開始時は理論値を下限として余裕を持たせ、実績が集まった後は「実時間÷理論時間」で自社環境の係数を求める方法が安全です。
たとえば、上り10Mbpsで1GBを3回送り、実時間が18分、20分、22分だった場合、次回は最短値だけでなく20分前後を中心に、通信変動を含む余裕を加えて計画できます。回線や送信先が変われば同じ係数を流用せず、条件ごとに記録を分けます。
OBJ本体が1GBでも、MTL、テクスチャ画像、補助ファイルを同時に送るなら合計容量で計算します。OBJが1GB、画像が300MB、その他が50MBなら、送信対象は合計1.35GBです。転送量が1.35倍になれば、同じ実効速度では転送時間もおおむね1.35倍になります。
上り速度別に見る1GBの転送時間
上り速度が1Mbpsの場合、1GBの理論時間は約2時間13分20秒です。実際の回線が不安定で平均速度が1Mbpsを下回れば、3時間以上かかることもあります。この速度帯では、途中切断や端末の電源管理による失敗の影響が大きいため、安定した場所へ移動するか、容量を減らしてから送る判断が必要です。
3Mbpsでは理論上約44分27秒です。安定して3Mbpsを維持できれば1時間以内で終わる可能性がありますが、移動通信で速度が大きく上下する環境では、1時間を超える場合があります。開始前の一度だけの速度測定ではなく、数分間の変動を確認します。
5Mbpsでは理論上約26分40秒です。安定した条件なら30分台で完了する可能性がありますが、再送や速度低下が多い場合はさらに長くなります。作業終了直前に開始すると、完了確認や失敗時の再送ができないため、十分な残り時間を確保します。
10Mbpsでは理論上約13分20秒です。初期の計画目安として15分から25分程度を置くことはできますが、送信先が速度を制限している場合や回線変動が大きい場合は、この範囲を超える可能性があります。
20Mbpsでは理論上約6分40秒です。実務では8分から12分程度を見込むと計画しやすい場合があります。同じ回線で動画会議、写真同期、バックアップなどの上り通信が始まると、OBJに利用できる帯域が減ります。
30Mbpsでは理論上約4分27秒です。安定した事務所回線なら5分から8分程度で終わる可能性があります。ただし、この範囲も回線以外のボトルネックがないことを前提にした目安です。
50Mbpsでは理論上約2分40秒です。実際には3分から6分程度になる場合があります。速度測定で50Mbps前後が継続しているのに10分以上かかる場合は、送信先の制限、端末負荷、ファイルの事前処理、ブラウザの実装などを切り分けます。
100Mbpsでは理論上約1分20秒です。実務では2分から4分程度となる場合がありますが、ネットワーク経路や送信先によってはさらに長くなります。高速回線ほど、ファイル読み出し、分割、暗号化、サーバー受付など、回線以外の時間が目立ちます。
200Mbpsでは理論上約40秒です。ただし、これはファイル本体8,000メガビットを200Mbpsで連続送信できた場合の下限です。端末の記憶装置、CPU負荷、通信遅延、アップロード方式、送信先の処理能力により、数分かかっても直ちに異常とは限りません。
理論値よりアップロードが遅くなる理由
表示される通信速度は、長時間にわたって維持される保証値とは限りません。速度測定時に50Mbpsでも、1GBの送信中に20Mbpsや5Mbpsへ低下すれば、全体の平均速度は下がります。大容量ファイルでは、瞬間的な最大値より継続して維持できる速度が重要です。
速度測定の接続先と実際の保存先が異なることも影響します。近い測定サーバーへの通信は速くても、実際のアップロード先までの距離、経路、混雑状況、接続方式が異なれば、同じ速度にはなりません。
通信ではOBJ本体以外にも、パケットのヘッダー、暗号化に関係する情報、受信確認などが扱われます。さらに、損失やタイムアウトが発生すると再送が行われ、混雑制御によって送信量が調整されます。TCPには再送タイムアウトや混雑制御の仕組みがあるため、回線の公称速度を常にファイル本体へ使い切れるわけではありません。IETF Datatracker
無線通信では、電波強度だけでなく干渉や接続品質も重要です。進捗が増えていても、一部のデータが再送されていれば実効速度は低下します。移動中や遮蔽物の多い場所では接続先の切り替えや一時切断も起こりやすくなります。
同じ回線を複数の端末や処理で共有すると、上り帯域が分けられます。写真や動画の自動同期、遠隔会議、クラウドバックアップ、別ファイルのアップロードなどが重なると、点群OBJに割り当てられる速度は大きく低下する可能性があります。
端末側の処理能力も関係します。ブラウザやアプリは、ファイルの読み出し、分割、ハッシュ計算、暗号化、再送管理などを行う場合があります。メモリ不足や高いCPU負荷があると、回線に余裕があっても送信処理が追いつかないことがあります。
高温時の性能制御や省電力動作は、機種やOSによって挙動が異なります。直射日光下や高温の車内では端末が処理性能を下げる場合があるため、温度上昇を避け、電源を確保し、送信中の動作を確認します。
送信先が一接続あたりの速度、同時接続数、ファイル容量、処理待ち数などを制限している場合、利用者側の回線を高速化しても時間は短縮しません。特定の時間帯だけ遅い場合は、利用集中による待ち時間も疑います。
点群OBJならではの時間増加要因
OBJは、頂点座標、テクスチャ座標、法線、面、グループ、材質参照などをテキストで記述できる三次元形状形式です。点群専用形式ではありませんが、頂点行だけを多数並べたデータを点群として扱う実装があります。受け入れ側が頂点のみのOBJに対応していない場合、アップロードできても表示されないことがあります。
同じ1GBでも、頂点だけのOBJと、面、法線、テクスチャ座標、グループ、材質参照を大量に含むOBJでは、解析負荷が異なります。面を含む場合は、各面が参照する頂点番号やテクスチャ座標、法線の整合性を確認する必要があり、変換処理が長くなる場合があります。
参照先の頂点が存在しない、数値として読めない文字がある、行が途中で欠けている、受け入れ側が対応していない記述があると、転送後の解析で失敗する可能性があります。アップロード完了後に再出力と再送が必要になれば、通信時間以上の手戻りが発生します。
座標値の桁数は容量に影響します。小数点以下の桁が必要以上に長いと、各頂点行の文字数が増え、数百万点以上では全体容量に大きな差が出ます。ただし、桁数を減らすと座標の量子化誤差が増えるため、座標単位、要求精度、後工程を確認せずに変更してはいけません。
対象外の点、重複点、外れ点、不要な孤立点も容量を増やします。共有対象が現場の一部だけなら、必要な周辺範囲を残して切り出すことで容量を減らせます。外れ点の除去は表示範囲の適正化にも役立ちますが、細い部材や離れた基準点を誤って削除しないよう確認が必要です。
頂点カラーは特に注意が必要です。一般的なOBJ仕様では、頂点行にRGB値を追加する表現は広く使われる慣例ですが、すべてのソフトウェアで同じように解釈される保証はありません。米国議会図書館も、MTLを使わず頂点ごとに色を持たせる慣例が複数のアプリケーションで利用されていると説明しています。色付き点群を送る場合は、アップロード先がその拡張表現に対応するか、小容量データで確認します。The Library of Congress
MTLやテクスチャ画像を使用する場合は、OBJ単体ではなく関連ファイルの合計容量を見ます。高解像度画像が複数あると、画像容量がOBJ本体を上回る場合があります。関連ファイル数が多いと、個別の開始処理や整合性確認も増えます。
改善策1 上り回線を安定させる
一つ目の改善策は、最高速度だけを追うのではなく、送信中の実効速度を安定させることです。短時間だけ100Mbpsになる回線より、30Mbps前後を継続できる回線のほうが、再送や停止を減らし、総時間を短くできる場合があります。
可能であれば端末と通信機器の間を有線接続します。有線化できない場合は、無線アクセスポイントとの距離を短くし、壁、金属設備、車両などの遮蔽物を避けます。通信機器を床面や収納内から見通しのよい位置へ移すだけで改善することもあります。
同じ回線で行われている上り通信を確認します。写真や動画の同期、バックアップ、遠隔会議、別の点群送信などを許可された範囲で一時停止すると、OBJへ利用できる帯域を確保しやすくなります。
速度は一度だけでなく複数回測ります。45Mbps、42Mbps、38Mbpsのように近い値なら比較的安定しています。50Mbps、8Mbps、3Mbpsのように大きく変動する場合は、最高値ではなく低い値を基準に見積もります。
時間帯を変える方法もあります。共有回線では、始業前後、終業前、会議が集中する時間などに上り通信が混雑する場合があります。時間帯別の実績を記録し、大容量ファイルを送る時間を決めると再現性が高まります。
送信中に端末が休止状態へ移行しないことを確認します。画面消灯だけなら継続する場合もありますが、ブラウザのバックグラウンド制限やOSの省電力制御によって停止することもあります。電源へ接続し、組織の運用ルールに従って必要な設定を確認します。
移動しながらのアップロードは避けます。移動通信では基地局やアクセスポイントの切り替え、電波の弱い区間、トンネルや建物による遮蔽が発生します。安全で通信の安定した場所に端末を置き、完了まで接続条件を変えない運用が有効です。
改善策2 点群OBJの容量を適切に減らす
二つ目の改善策は、利用目的に必要な情報を維持しながら容量を減らすことです。送信速度が同じなら、1GBを800MBに減らすと理論上の転送時間は約2割短くなり、500MBなら約半分になります。
最初に、対象外の範囲が含まれていないか確認します。施工箇所の一部だけを共有するのに現場全体が含まれている場合は、必要区域を切り出せます。ただし、周辺構造物、基準点、接続部など、判断に必要な範囲まで削らないようにします。
外れ点、孤立点、明らかな計測ノイズ、重複点も確認します。対象から大きく離れた外れ点は、容量だけでなく表示範囲にも影響し、本体を小さく見せる原因になります。ただし、自動除去では細い配管、電線、縁石、標識などがノイズと誤判定される場合があるため、処理前後を目視で比較します。
点密度の調整も有効です。概況確認や進捗共有では、全域に最大密度を残す必要がない場合があります。一方、出来形確認、微細な変状、狭い隙間、端部形状を確認する用途では、間引きによって必要な情報が失われます。用途ごとに許容する点間隔を決めます。
座標値の桁数を見直す場合は、座標の単位と要求精度を先に確認します。メートル単位の小数第3位と、ミリメートル単位の小数第3位では意味が異なります。単純に文字数を減らすのではなく、必要な分解能を維持できるか検証します。
面、法線、テクスチャ座標、グループ、材質参照が不要なら、確認用データから省ける可能性があります。ただし、頂点のみOBJを表示できること、後工程が面情報を必要としないことを確認します。アップロード先がメッシュを前提としている場合は削除できません。
頂点カラーが不要な確認用途では、色なしの軽量版を作る方法があります。ただし、OBJの頂点カラーは実装依存であり、削除前に元データを保存します。変色、材質、対象物の識別に色を使う作業では、軽量化を優先して削除すべきではありません。
テクスチャ画像が大きい場合は、閲覧目的に必要な解像度を確認します。縮小表示だけに使う画像を適切な解像度へ調整できる場合がありますが、文字、ひび割れ、境界などを確認する用途では解像度低下が判断へ影響します。
アップロード先が対応している場合に限り、OBJ、MTL、画像を圧縮ファイルへまとめる方法もあります。テキスト主体のOBJは圧縮効果が得られることがありますが、JPEGなど既に圧縮された画像は大きく減らない場合があります。圧縮形式、展開方法、ファイル上限を事前に確認します。
軽量化後は、点数、座標範囲、形状、色、面、方向、標高、必要な細部を元データと比較します。容量が減っても、内容不良によって再出力と再アップロードが必要になれば、総時間は増えます。
改善策3 失敗と再送を防ぐ運用に変える
三つ目の改善策は、送信速度の数％改善よりも、失敗による全量再送を防ぐことです。1GBの送信に20分かかる環境で、完了直前に切断されて最初からやり直せば、転送だけで40分以上を費やします。
利用するアップロード機能が、分割送信や途中再開に対応しているか確認します。途中再開に対応していれば、一時的な通信断が起きても送信済み部分を保持できる場合があります。対応の有無はサービスごとに異なるため、推測せず仕様や小容量テストで確認します。
ファイル分割が許容される場合は、工区、範囲、階層、取得日などの単位で分けます。1GBを4個の250MBに分ければ、一つが失敗したときの再送量を抑えられます。必要な範囲から先に送れば、全体完了前に確認を開始できます。
OBJをテキストの途中で単純に切ってはいけません。面情報は頂点番号などを参照しているため、途中切断すると参照関係が壊れます。三次元データを扱えるソフトウェアで空間的または論理的に分割し、各ファイルが単独で開けることを確認します。
分割後も座標系、単位、原点、軸方向を一致させます。各ファイルで原点を変更すると、アップロード後に位置が合わないことがあります。分割条件、元ファイル、処理日時を記録し、後から追跡できるようにします。
本番前に小容量のテストOBJを送る方法も有効です。本番と同じ出力条件で一部を作り、頂点、面、色、材質、座標、標高、方向が正しく読めるか確認します。特に頂点のみOBJや頂点カラーは対応差があるため、事前検証の効果が大きい項目です。
ファイル名と関連参照も確認します。OBJ内のMTL名と実ファイル名、大文字と小文字、拡張子、画像の相対参照が一致しているかを確認します。送信先のOSや実装によっては、大文字と小文字を区別する場合があります。
ブラウザを利用する場合は、送信中にページを再読み込みしたりタブを閉じたりしません。別画面へ移動しても続く仕組みと、中断する仕組みがあります。回線の切り替えも送信前に行い、開始後は接続条件を変えないようにします。
完了後は進捗100％だけで終了せず、受け入れ完了、変換完了、表示、点数、座標範囲、色、面、権限を確認します。アップロード成功とデータ利用可能は同じ状態ではありません。
アップロード前に確認したい項目
最初にOBJ本体と関連ファイルの総容量を確認します。OBJが1GBでも、MTLや画像を加えると1.5GB以上になることがあります。送信先の単一ファイル上限、合計容量上限、ファイル数上限、対応拡張子を確認します。
次に、実際の上り速度を複数回測ります。一回だけ高い値が出ても安定性は分かりません。低い側の値で理論時間を計算し、過去実績があれば現実の係数を加えます。失敗時の再送時間まで確保できない状況では開始を見直します。
端末の電源、発熱、スリープ設定、空き容量も確認します。アップロード方式によっては、送信準備や一時ファイルのために追加領域が必要になる場合があります。空き容量が極端に少ないと、ブラウザやアプリの処理が不安定になる可能性があります。
ファイルが最後まで正常に開けることも確認します。OBJ末尾の欠落、途中行の破損、数値形式の異常、存在しない頂点参照などがあると、転送後の解析に失敗します。別の対応環境で開き、点数や形状に大きな異常がないか確認します。
座標系、単位、軸方向、原点、標高の扱いも整理します。これらは転送速度には直接影響しませんが、設定ミスがあれば再出力と再送が必要です。メートルとミリメートル、平面座標とローカル座標などを混同しないようにします。
面を含むOBJでは、頂点、テクスチャ座標、法線の参照整合性を確認します。極端に長い面定義や受け入れ側が対応しない記法がある場合は、小容量の同形式データでテストします。
点群の全体範囲も確認します。遠方の外れ点があると、本体が極端に小さく表示され、通信失敗やデータ欠落と誤認されることがあります。全体表示と対象部の拡大表示を行います。
保存先、案件、共有権限、閲覧者も事前に確認します。1GBを送った後に保存先の誤りが判明すると、再アップロードや移動作業が必要になります。閲覧担当者がアクセスできるところまでを完了条件にします。
転送後の変換・解析時間にも注意する
アップロード先では、ファイル構造の確認、頂点数の集計、面参照の検証、座標範囲の算出、表示用形式への変換、階層化、縮小表示用データの生成などが行われる場合があります。処理内容はサービスごとに異なります。
1GBを2分で転送できても、変換に15分かかれば閲覧開始まで17分です。この場合、回線を高速化して転送を1分短縮するより、点数、面数、付随情報、座標範囲を見直すほうが総時間を短縮できる可能性があります。
進捗段階が表示される場合は、「アップロード中」「処理待ち」「変換中」「閲覧準備中」を分けて記録します。アップロード中が長ければ回線や端末、変換中が長ければデータ構造や点数、処理待ちが長ければ利用時間帯や送信先の混雑を疑います。
解析失敗を容量だけの問題と決めつけてはいけません。頂点番号の不整合、改行や文字コードの扱い、数値として解釈できない文字、非対応記述、関連ファイル欠落、極端な座標値などでも失敗します。容量を小さくしても構文上の問題が残れば解決しません。
変換後は、表示できたことだけでなく、点数、範囲、形状、色、方向、標高を確認します。一部欠落は全体表示だけでは気づきにくいため、送信前の点数や境界値を記録し、変換後と比較します。
初回閲覧では、表示用データを閲覧端末へ受信する時間もかかります。アップロードと変換が完了していても、閲覧側の下り回線や端末性能によって表示が遅い場合があります。転送時間、サーバー処理時間、閲覧読み込み時間を分けて扱います。
現場から送る場合と事務所から送る場合の違い
現場から直接アップロードする利点は、取得後すぐに遠隔担当者と共有できることです。取得漏れや異常が見つかれば、現場を離れる前に再取得できる可能性があります。
一方、現場の通信環境は、建物、地形、資材、車両、利用者の集中などによって変動しやすく、安定した電源や端末の設置場所も確保しにくい場合があります。天候そのものが必ず速度を下げるとは限りませんが、機器の設置条件や電波経路が変化する要因にはなり得ます。
現場では小容量の確認用データを先に送り、位置、範囲、色、方向などを確認する二段階運用が有効です。正式な高密度データは、安定した通信環境へ移動してから送ります。早期確認と大容量転送の確実性を分けて考えられます。
事務所では、有線接続、安定電源、十分な端末性能を確保しやすく、複数データを順番に送る運用を組みやすくなります。ただし、取得内容の確認が遅れるため、現場では最低限の範囲確認と品質確認を済ませます。
役割を分ける場合は、送信担当、変換完了確認担当、内容検査担当を明確にします。「アップロード開始」を完了とせず、点群を開き、必要な範囲が表示され、関係者が閲覧できる状態を完了条件とします。
複数の点群OBJを効率よく送る方法
1GBのOBJが複数ある場合、すべてを同時に送ると上り帯域を分け合い、各ファイルの進捗が遅くなることがあります。送信先の同時接続仕様や回線品質が不明なら、一件ずつ順番に送るほうが安定する場合があります。
緊急性の高い工区、後工程で先に使う範囲、品質確認が必要なデータから送ります。全件完了を待たずに作業を開始できるよう、送信順を業務の優先順位と合わせます。
ファイル名には、現場、工区、取得日、範囲、処理段階などを識別できる情報を含めます。同名ファイルによる取り違えや上書きを避ける一方、極端に長い名前、制御文字、送信先が扱えない記号は避けます。
送信記録には、ファイル名、容量の表記方法、上り速度、開始時刻、転送完了時刻、変換完了時刻、失敗の有無を残します。容量がGBかGiBかも記録すると、見積もり誤差を減らせます。
同じ条件での記録が蓄積されれば、一般的な目安より正確に予測できます。1GBあたりの転送実績が平均12分であれば、同条件の5GBは転送だけで約1時間が基準になります。変換と確認の時間を加えて開始時刻を逆算します。
共有用、確認用、保存用でデータを分ける方法もあります。確認用には必要範囲と必要密度に絞った軽量版、正式保存には高密度版を使います。軽量版を正式成果と誤認しないよう、ファイル名と保存場所を明確に分けます。
1GBの点群OBJアップロードでよくある疑問
1GBなら必ず同じ時間で送れるわけではありません。同じ容量でも、実効上り速度、通信の安定性、端末性能、送信先の受付速度、時間帯によって変わります。利用場所で複数回測定し、低い側の値と過去実績を基準にします。
下り速度が速くても、アップロード時間が短くなるとは限りません。送信に直接関係するのは上り速度です。下りが数百Mbpsでも、上りが10Mbpsなら1GBの理論時間は約13分20秒です。
1GBと1GiBは同じではありません。1GBは10億バイト、1GiBは1,073,741,824バイトです。画面表示がどちらの換算を使っているか分からない場合は、バイト数を確認すると正確に計算できます。
圧縮すれば必ず短時間になるわけでもありません。OBJはテキスト主体なので圧縮効果を得られることがありますが、送信先が圧縮形式を受け付けなければ使えません。既に圧縮された画像が多い場合は、全体容量が大きく減らないこともあります。
分割しても総容量が同じなら、理論上の総転送量は変わりません。ファイルごとの開始処理が増えて少し長くなる場合もあります。分割の利点は、失敗時の再送量を減らし、必要な範囲から先に利用できることです。
進捗が止まったように見えても、すぐにページを閉じたり再読み込みしたりしません。表示更新が遅い場合、確認処理に移った場合、通信が低速で継続している場合があります。明確なエラー表示、通信状態、サービスの仕様を確認します。
100％の後に時間がかかる場合は、解析や変換の可能性があります。上り速度を上げても短縮できない工程です。軽量な確認用データと比較すると、転送と変換のどちらがボトルネックか切り分けやすくなります。
容量を減らしても品質が必ず低下するわけではありません。対象外範囲、重複点、明らかな外れ点、不要な付随情報の整理なら、必要部分を維持できる場合があります。一方、点密度や座標桁数の変更は精度や再現性へ影響するため、用途に応じた検証が必要です。
頂点カラー付きOBJは、すべてのアップロード先で同じように表示されるとは限りません。色が重要な場合は、小容量テストで対応を確認し、元データを保持します。
まとめ
1GBの点群OBJを送る理論時間は、10Mbpsで約13分20秒、20Mbpsで約6分40秒、50Mbpsで約2分40秒、100Mbpsで約1分20秒です。実際には回線変動、通信制御、端末処理、送信先の制限があるため、理論値より長くなります。10Mbpsなら15分から25分程度、20Mbpsなら8分から12分程度、50Mbpsなら3分から6分程度、100Mbpsなら2分から4分程度を初期の計画目安にできますが、保証値ではなく実測で調整します。
容量計算では、1GBと1GiBを混同しないことが重要です。1GiBは1GBより約7.4％大きいため、同じ上り速度でもその分だけ理論時間が長くなります。OBJ本体だけでなく、MTLやテクスチャ画像を含む合計容量で計算します。
改善策は三つです。一つ目は、有線接続、遮蔽物の回避、上り通信の整理、時間帯の選択によって回線を安定させることです。二つ目は、対象外範囲、外れ点、重複点、過剰な点密度、不要な付随情報を整理し、用途に必要な品質を保ちながら容量を減らすことです。三つ目は、途中再開の確認、適切な分割、小容量テスト、完了後の検査によって失敗と全量再送を防ぐことです。
OBJは点群専用形式ではなく、頂点のみの表示や頂点カラーの解釈には実装差があります。転送速度だけでなく、アップロード先が使用するOBJ記述に対応しているかを事前に確認します。
また、転送完了後に解析、変換、閲覧用データ生成が行われる場合があります。アップロード中、処理待ち、変換中、閲覧読み込みを分けて記録すると、改善すべき工程を判断しやすくなります。
最も確実なのは、自社環境で実績を蓄積することです。ファイルのバイト数、上り速度、転送時間、変換時間、失敗回数を条件別に記録すれば、次回の所要時間をより正確に予測できます。
点群の取得から整理、確認、アップロードまでを一連の業務として効率化したい場合は、LRTK Phoneを利用する運用についても、対応形式、容量上限、通信条件を確認したうえで検討してください。