点群データから作成したOBJファイルをクラウドや外部の共有環境へアップロードしようとしても、社内ネットワークでは送信できないことがあります。ファイルを選択した直後にエラーが出る、送信途中で進捗が止まる、長時間待った後に通信エラーになるなど、症状はさまざまです。
このような状況では、OBJファイルが壊れているとは限りません。社内ネットワークでは、端末とアップロード先の間にプロキシ、通信監視、認証、暗号化通信の検査、外部送信制御などが設けられている場合があります。一般的なウェブページは閲覧できても、大容量の点群OBJを送る通信だけが制限されることもあります。
一方で、プロキシが原因だと思っていたものの、実際にはアップロード先の容量制限、OBJの記述不整合、関連ファイルの不足、端末側の処理停止などが原因だったというケースもあります。問題を効率よく解決するには、OBJ側と通信側を同時に変更するのではなく、失敗している段階を確認しながら一つずつ切り分けることが重要です。
この記事では、「点群 OBJ アップロード」で情報を探している実務担当者に向けて、点群OBJを社内プロキシ経由で送れないときに確認したい六つの項目を解説します。情報システム担当者へ相談する前に整理しておきたい内容や、安全に再送するための注意点も紹介します。
点群OBJのアップロードが止まる段階を整理する
最初に確認したいのは、アップロード処理のどの段階で問題が起きているかです。同じ「送れない」という症状でも、ファイル選択時に拒否される場合と、送信途中で切断される場合と、送信後の変換処理で失敗する場合では、調べるべき場所が異なります。
ファイルを選択した直後にエラーが表示される場合は、まだOBJ本体の送信が始まっていない可能性があります。この段階では、ファイルの拡張子、ファイル名、容量、選択したファイル数、圧縮形式、アップロード先の受付条件などを確認します。OBJと一緒にMTLファイルや画像ファイルを選択している場合は、関連ファイルのうち一つが条件に合っていないこともあります。
送信ボタンを押した後、進捗が途中まで進んで停止する場合は、通信経路、容量制限、通信時間、認証の有効時間、セキュリティ検査などが関係している可能性があります。毎回ほぼ同じ経過時間で停止するのか、ほぼ同じ進捗率で停止するのかも確認すると、原因を絞り込みやすくなります。
ただし、アップロード画面に表示される進捗率は、必ずしも実際に送信されたデータ量と一致するわけではありません。ファイルの読み込み、圧縮、分割、暗号化、外部への送信など、複数の処理をまとめて進捗として表示している場合があるためです。進捗率だけで容量制限だと断定せず、開始時刻、停止時刻、表示されたメッセージを記録します。
送信が完了したように見えた後で解析エラーや変換エラーが出る場合は、プロキシよりもOBJの内容を優先して確認します。OBJ内の頂点番号と面の参照番号が合っていない、材質ファイルへの参照先が見つからない、数値の書式を読み取れない、極端に長い行が含まれているなどの問題が考えられます。
社内ネットワークでは失敗するものの、会社が正式に許可した別の通信環境では同じファイルを送れる場合、社内プロキシや外部送信制御が関係している可能性が高まります。ただし、切り分けを目的として、業務データを許可されていない回線や私的な環境へ送ることは避けなければなりません。点群には現場形状、設備配置、構造物、地形、位置情報などが含まれるため、送信方法は社内規程に従う必要があります。
どの環境でも特定のOBJだけが失敗する場合は、ファイル側の問題を疑います。反対に、複数のOBJが社内環境だけで失敗する場合は、ネットワーク側の確認を優先します。このように、失敗する段階と再現条件を整理してから六つの確認へ進むことが、遠回りを防ぐ基本です。
確認1 社内プロキシを通る通信経路を確認する
一つ目の確認は、点群OBJのアップロード通信がどの経路を通っているかです。社内端末から外部サービスへ接続する場合、端末から直接送信先へ通信するのではなく、社内プロキシや通信検査装置を経由する構成がよく採用されます。
一般的なウェブページを閲覧できるからといって、OBJのアップロードに必要な通信もすべて許可されているとは限りません。ページの表示とファイルの送信では、通信量、接続時間、接続先、通信方法が異なることがあります。アップロード画面を表示する接続先は許可されていても、実際にファイルを受け取る別の接続先が許可されていない可能性があります。
ブラウザからアップロードしている場合は、端末やブラウザに設定されたプロキシを経由することがあります。一方、専用の業務アプリケーションやバックグラウンド処理では、端末のプロキシ設定を正しく参照できない場合があります。ブラウザでは送れるが専用アプリケーションでは送れないときは、OBJの内容ではなく、アプリケーションの通信方式と社内プロキシとの適合を確認します。
プロキシの設定が自動的に配布されている環境では、接続先に応じて直接通信とプロキシ経由の通信が切り替わることがあります。事務所内の有線接続、社内無線、遠隔接続、別拠点のネットワークで結果が異なる場合は、それぞれ異なる経路や外部接続口を通っている可能性があります。
特に遠隔接続中は、端末から社内ネットワークへ入る通信と、社内ネットワークから外部へ出る通信が組み合わさります。通信経路が長くなり、遅延が大きくなることで、大容量OBJの送信だけが不安定になることもあります。遠隔接続では小容量OBJが送れても、大容量OBJでは接続時間の上限に達する可能性があります。
社内プロキシ以外にも、外部送信を監視する装置やファイル内容を検査する仕組みが存在する場合があります。利用者から見ると一つの通信に見えても、実際には複数の中継処理を通過しています。そのどこかで通信が拒否されれば、アップロードは完了しません。
情報システム担当者へ確認を依頼するときは、「インターネットには接続できるがOBJを送れない」と伝えるだけでは情報が不足します。送信した日時、端末、接続していたネットワーク、利用したブラウザまたはアプリケーション、送信先、停止した段階を伝えると、通信記録を照合しやすくなります。
原因を調べる目的でも、利用者が無断でプロキシを解除したり、通信設定を変更したりすることは避けます。プロキシは情報漏えい防止や不正通信対策のために設置されているため、設定変更は必ず管理者の判断で行う必要があります。
確認2 プロキシ認証と利用権限を確認する
二つ目の確認は、社内プロキシの認証がアップロード処理でも正常に成立しているかです。社内プロキシでは、利用者や端末を識別し、許可された通信だけを通すために認証が行われることがあります。
通常のページ閲覧では問題がなくても、大容量OBJの送信中に認証状態が失効すると、通信が途中で切断される場合があります。小容量ファイルは短時間で送信できるため成功するものの、大容量ファイルは認証の有効時間を超えるため失敗するという違いが出ることもあります。
典型的な症状として、アップロードを開始した直後に認証画面が出る、一定時間後にログイン画面へ戻る、最初の一回だけ進むが再試行すると止まる、利用者によって結果が異なるといった状況があります。表示上は一般的な通信エラーでも、プロキシ側の記録には認証失敗として残っている可能性があります。
ブラウザが保持している認証情報を、ファイル送信を担当する別の処理が利用できない場合もあります。利用者から見ると同じ画面の中で行われる操作でも、ページ表示とファイル送信が別の通信として扱われることがあるためです。
専用アプリケーションを利用している場合は、社内プロキシが要求する認証方式に対応しているかを確認します。端末の設定を自動的に利用できるアプリケーションもあれば、別途プロキシ情報の設定が必要なものもあります。ただし、管理者から指定されていない接続情報を利用者が推測して入力することは避けます。
利用権限も重要です。社内ネットワークでは、一般的なウェブ閲覧は許可されていても、外部へのファイルアップロードが利用者や部門ごとに制限されていることがあります。この場合、接続先の画面までは開けても、送信操作だけが拒否されます。
新しい端末へ移行した直後や、利用者情報が変更された直後に発生した場合は、端末登録や認証情報の配布が完了しているかも確認します。利用者単位ではなく端末単位で許可される環境では、同じ利用者が操作していても、新旧端末で結果が異なる可能性があります。
また、送信中に端末が省電力状態へ移行すると、通信や認証状態が維持されない場合があります。大容量OBJを送信するときは、社内管理方針の範囲で、端末がアップロードを継続できる状態にします。画面を閉じる、端末を休止させる、接続を切り替えるといった操作は、送信完了を確認してから行います。
認証エラーが疑われる場合でも、何度も認証情報を入力し直せば解決するとは限りません。認証方式への非対応や利用権限の不足が原因であれば、利用者側の再入力では改善しません。停止までの時間や認証画面の有無を記録し、管理者に確認してもらうことが重要です。
確認3 HTTPS通信と証明書の状態を確認する
三つ目の確認は、暗号化通信と証明書の状態です。点群OBJを外部環境へアップロードする通信では、送信内容を保護するために暗号化された通信が利用されることが一般的です。
社内ネットワークでは、暗号化通信の安全性を確認するため、プロキシや検査装置が通信を中継する場合があります。このとき、端末、ブラウザ、専用アプリケーション、社内プロキシ、アップロード先の間で証明書が正しく信頼されている必要があります。
証明書に問題がある場合、アップロード画面そのものを開けないこともあれば、画面は開けても送信開始時にエラーになることもあります。ページ表示用の通信とファイル送信用の通信で接続先が異なる場合、画面表示では問題がなくても、アップロード時だけ証明書エラーが起こる可能性があります。
ブラウザでは送信できるのに専用アプリケーションでは失敗する場合は、証明書の信頼方法が異なっている可能性があります。ブラウザは社内で配布された証明書を信頼していても、専用アプリケーションが独自の証明書管理を行っていると、その証明書を認識できない場合があります。
証明書の有効期限だけでなく、端末の日時も確認します。端末の日付や時刻が大きくずれていると、有効な証明書であっても、まだ有効ではない、または期限が切れていると判断される可能性があります。長期間ネットワークへ接続していなかった端末や、初期化後の端末では特に注意します。
暗号化通信の検査では、アップロードするファイルの内容を一時的に確認する処理が行われる場合があります。小容量ファイルでは短時間で終わっても、点群OBJのような大容量ファイルでは検査時間が長くなり、通信の上限時間に達することがあります。
OBJ本体だけでなく、MTLや複数の画像を同時に送る場合は、検査対象全体の容量が増えます。ファイルごとに検査される構成では、一つひとつの処理時間が積み重なり、途中で接続が終了する可能性もあります。
証明書に関する警告が表示されたときは、警告を無視して処理を続けないことが重要です。正しい送信先に接続していることを確認できない状態で、現場の点群データを送信するのは適切ではありません。警告画面、表示された内容、発生時刻を記録し、情報システム担当者へ確認します。
送信先の通信要件によっては、社内の暗号化通信検査と相性が合わない場合があります。その場合、検査対象から外す必要があるか、別の承認済み経路を利用するかは、管理者が安全性を確認したうえで判断します。利用者が独自に警告を回避したり、接続方法を変更したりしないことが基本です。
確認4 ファイル容量と通信時間の上限を確認する
四つ目の確認は、ファイル容量と通信時間の上限です。点群から作成するOBJは、頂点数や面数が増えるほど容量が大きくなります。高密度な点群から広い範囲をメッシュ化した場合、OBJ本体だけでも大容量になることがあります。
さらに、材質情報を記録するMTLファイルや、色や外観を表現する画像ファイルを含めると、送信対象全体の容量は増加します。アップロード先が大容量ファイルを受け付けていても、社内プロキシや通信検査装置が同じ容量まで許可しているとは限りません。
容量上限が原因の場合、小容量のOBJは送れるが、大容量のOBJだけが失敗するという差が現れます。ただし、上限を超えた時点で明確な容量エラーが表示されるとは限りません。途中で通信が停止し、しばらく待った後に一般的なネットワークエラーとして表示される場合もあります。
確認するときは、OBJ本体だけでなく、同時に送信するファイルの合計容量を把握します。OBJ、MTL、画像、説明用ファイルなどを一つのアップロード操作で送る場合、合計容量が制限対象になる可能性があります。
圧縮ファイルにまとめる場合も注意が必要です。圧縮後の容量が小さくても、通信検査装置が展開して内容を確認する環境では、展開後の容量が上限に影響することがあります。圧縮すれば必ず送れるとは限りません。
通信時間の上限も見落としやすい原因です。社内回線が混雑している時間帯、遠隔接続中、無線状態が不安定な場所などでは、同じOBJでも送信完了までの時間が長くなります。途中のプロキシや通信装置に接続維持時間の上限が設定されていると、容量上限以下のファイルでも送信が切断されます。
毎回ほぼ同じ時間で停止する場合は、通信時間や認証時間の上限が疑われます。毎回ほぼ同じデータ量で停止しているように見える場合は、容量や検査処理の上限が関係している可能性があります。ただし、画面上の進捗だけでは正確に判断できないため、送信開始時刻と停止時刻を記録します。
OBJの容量を減らすことも対策の一つですが、業務に必要な精度を失わないよう注意が必要です。不要範囲を切り出す、重複頂点や不要な面を整理する、用途に応じて点密度やメッシュ密度を調整する、必要以上に大きな画像を見直すといった方法があります。
容量削減用のデータを作る場合は、必ず元データを保持します。共有用の軽量データと計測成果として保存する元データを分けて管理すれば、後から詳細確認が必要になった場合にも対応できます。
OBJを複数に分割する場合は、座標や原点が変わらないように注意します。単純に分割した結果、ファイルごとの位置関係が分からなくなると、アップロード後に正しく再配置できません。区画名、基準位置、座標の扱い、分割範囲を記録しておく必要があります。
拡張子を別のものに変更したり、内容を偽装したりして容量制限やセキュリティ検査を回避する方法は適切ではありません。正規の申請や承認済みの共有方法を利用することが、安全な運用につながります。
確認5 OBJや関連ファイルの検査条件を確認する
五つ目の確認は、OBJ、MTL、画像などが社内のセキュリティ検査でどのように扱われているかです。社内ネットワークでは、外部へ送信されるファイルについて、拡張子、内容、容量、圧縮状態、機密情報の可能性などを検査している場合があります。
OBJは一般的な文書とは異なる三次元データ用の形式です。内容はテキストとして記述されることが多いものの、大量の座標値や面の参照番号が並びます。そのため、検査装置が未知のファイル、解析に時間がかかるファイル、制限対象の設計データとして扱う可能性があります。
OBJ本体は許可されていても、関連するMTLや画像が制限されることがあります。複数のファイルを同時にアップロードしたとき、そのうち一つでも遮断されると、利用者にはアップロード全体が失敗したように見える場合があります。
原因を切り分けるには、業務上許可された試験データを使い、OBJ単体での結果と、関連ファイルを含めた結果を比較します。OBJ単体では成功し、MTLや画像を追加すると失敗する場合は、追加したファイルの形式、容量、ファイル数、参照関係を確認します。
ただし、OBJ単体を送れたからといって、目的を達成できたとは限りません。外観や色の確認が必要な業務では、MTLや画像も正しく送信できなければ、必要な成果を共有できません。切り分け試験と最終的な業務要件は分けて考えます。
ファイル名も確認します。長すぎる名前、特殊な記号を含む名前、文字の種類が混在する名前、同じ名前の重複などは、アップロード先や中継処理で問題になることがあります。切り分け用の複製では、短い英数字を中心とした名前へ変更して結果を比較します。
ファイル名を変更するときは、元データとの対応が分からなくならないようにします。変更前後の名称を記録し、どの現場、どの範囲、どの時点のデータかを追跡できる状態を保ちます。
圧縮ファイルも検査条件に影響します。複数の関連ファイルを一つにまとめると管理しやすくなりますが、社内環境によっては圧縮ファイルの外部送信が制限されています。暗号化された圧縮ファイルは内容検査ができないため、さらに厳しく遮断されることもあります。
現場情報を保護するために暗号化が必要な場合は、組織が承認した方法を利用します。利用者が独自の暗号化方法や個人的な共有手段を使うと、受信者が開けないだけでなく、社内規程に反するおそれがあります。
セキュリティ検査による遮断では、利用者の画面に具体的な理由が表示されない場合があります。単に「送信できませんでした」と表示されても、管理側の通信記録には、ファイル形式、内容検査、情報持ち出し制御などの理由が残っていることがあります。
このため、拡張子や圧縮方法を何度も推測で変更するより、発生時刻、送信元端末、対象ファイル、接続先を管理者へ伝え、記録を確認してもらう方が効率的です。
また、送信しようとしている点群OBJが外部共有可能なデータかも確認します。点群には、施設内部、設備配置、施工中の構造、周辺地形、座標などが含まれる場合があります。個人情報が含まれていなくても、業務上の機密情報として管理する必要があるため、送信可否と送信方法を事前に確認します。
確認6 接続先の許可設定と名前解決を確認する
六つ目の確認は、アップロード処理に必要な接続先が社内ネットワークで許可されているかです。アップロード画面を表示している接続先と、OBJ本体を受け取る接続先が同じとは限りません。
画面は正常に開くのにファイル送信だけが失敗する場合、ページ表示用の接続先は許可されていても、ファイル受信用の接続先が許可されていない可能性があります。アップロード開始後に別の通信先へ切り替わり、そこで接続が拒否されると、利用者には一般的なアップロードエラーとして表示されます。
ファイル送信以外にも、利用者認証、送信進捗の確認、アップロード完了通知、変換処理の開始、変換結果の取得などで複数の接続先が使われる場合があります。そのうち一部だけが遮断されると、送信途中で止まったように見えたり、送信完了後に処理が進まなくなったりします。
接続先の許可設定は、接続先名だけでなく、通信方法や接続条件を含めて管理されることがあります。また、アップロード先の構成変更によって通信先が変わると、端末側の設定を変更していなくても、以前は送れたOBJが突然送れなくなる場合があります。
昨日まで利用できていたのに急に失敗し始めた場合は、社内プロキシだけでなく、アップロード先の接続構成や認証方法が変更されていないか確認します。障害発生日時が明確であれば、その前後に行われた設定変更と照合しやすくなります。
名前解決の問題にも注意が必要です。端末やプロキシが接続先の名前を正しい通信先へ変換できない場合、画面の一部だけが動作しないことがあります。事務所内、遠隔接続中、別拠点で結果が異なる場合は、利用している名前解決の経路が異なっている可能性があります。
接続先を数値の通信先へ直接置き換えて試す方法は避けます。暗号化通信では接続先名と証明書の整合性が必要であり、数値へ直接接続すると正しく認証されない可能性があります。また、通信負荷に応じて複数の接続先を切り替える構成では、一つの数値へ固定しても適切な検証になりません。
接続先の許可を情報システム担当者へ依頼するときは、広い範囲をまとめて許可するのではなく、業務に必要な接続先と通信に限定します。許可範囲を過度に広げると、不必要な外部通信まで通過させることになり、セキュリティ上のリスクが高まります。
社内側で許可されていても、アップロード先が通信元を制限している場合があります。事務所からは送れるが遠隔接続では送れない、特定拠点だけ失敗するといった状況では、外部へ出るときの通信元が異なる可能性があります。社内ネットワークの出口と、アップロード先の許可条件を照合する必要があります。
通信記録に拒否された接続先が残っている場合は、それがアップロード処理に必要な正規の接続先かを確認します。想定と違う名前が記録されていても、すぐに不正通信と判断せず、管理者がアップロード先の仕様と照合して判断します。
OBJ側とネットワーク側を安全に切り分ける
点群OBJを送れないときは、OBJ側の問題とネットワーク側の問題を分けて調べることが重要です。両方の設定を同時に変更すると、送信できるようになっても、どの変更が有効だったのか分からなくなります。
まず、同じ社内ネットワークで、容量の小さい確認用OBJを送信します。確認用データは、社内で試験利用が認められたものを使います。小容量OBJが成功する場合は、接続先への基本的な通信、認証、証明書の確認が成立している可能性があります。
次に、問題のOBJと同程度の構成を持ち、容量だけが小さいデータで確認します。単純なOBJが送れたとしても、MTLや画像を含むOBJでは別の制限を受ける可能性があるためです。比較条件を近づけることで、容量と形式のどちらが影響しているかを確認しやすくなります。
OBJ単体と、OBJに関連ファイルを加えた状態を比較する方法もあります。OBJ単体では成功し、画像を加えると失敗する場合は、画像形式、画像容量、ファイル数、セキュリティ検査などを優先して確認します。
反対に、小容量OBJでも社内ネットワークから一切送れない場合は、容量以外の原因が疑われます。接続先の許可、プロキシ認証、証明書、アプリケーションのプロキシ対応などを確認します。
送信完了後に解析エラーが出る場合は、OBJの記述を確認します。頂点行、面行、法線、テクスチャ座標、材質参照などが、アップロード先の対応条件に合っているかを調べます。面から参照される頂点番号が実際の頂点数を超えていないか、参照先のMTLが存在するか、数値の区切りが適切かといった点も確認対象です。
OBJが極端に大きい場合、ネットワーク送信前の端末処理で停止することがあります。ブラウザやアプリケーションがファイル全体をメモリへ読み込む方式では、端末の空きメモリが不足し、通信を開始する前に動作が止まる可能性があります。
端末の空き保存容量も確認します。アップロード前に一時ファイルを作成する処理では、元のOBJとは別に作業領域が必要になります。保存容量が不足すると、プロキシへ到達する前にエラーになることがあります。
情報システム担当者が確認した通信記録に、送信開始の形跡がまったくない場合は、端末やアプリケーション側で止まっている可能性が高まります。反対に、送信開始後にプロキシで遮断された記録があれば、ネットワーク側の原因を優先できます。
切り分けでは、一回の試験で変更する条件を一つにします。ファイル名、容量、関連ファイル、端末、接続方法をすべて同時に変更すると、成功しても原因を特定できません。条件と結果を記録しながら進めることで、再発時にも同じ手順で確認できます。
情報システム担当者へ伝える情報を整理する
社内プロキシや通信制御が関係している可能性がある場合は、情報システム担当者へ確認を依頼します。その際、「点群OBJを送れない」という説明だけでは、膨大な通信記録の中から該当処理を特定することが難しくなります。
まず必要なのは、アップロードを開始した日時です。可能であれば、開始時刻と停止時刻の両方を記録します。通信記録は時刻を基準に検索することが多いため、時刻が明確であるほど確認しやすくなります。
次に、送信元となった端末と利用者を整理します。同じ利用者でも複数の端末を使っている場合があり、端末ごとに認証状態や証明書の配布状態が異なることがあります。
接続していたネットワークも重要です。社内有線、社内無線、遠隔接続、別拠点など、どの経路を利用していたかを伝えます。「社内から送信した」だけでは、実際の通信出口を判断できない場合があります。
利用した環境については、ブラウザから送ったのか、専用アプリケーションから送ったのかを区別します。ブラウザとアプリケーションではプロキシ設定や証明書の扱いが異なることがあるためです。
対象ファイルについては、ファイル名、OBJ本体の容量、関連するMTLや画像の有無、全体の容量、圧縮の有無を整理します。機密性の高いデータの場合は、問い合わせにファイル本体を添付せず、社内で定められた安全な方法で共有します。
表示されたエラーメッセージは、記憶だけに頼らず正確に記録します。画面保存が認められている場合は保存し、難しい場合は表示された文章をそのまま控えます。一般的な通信エラーに見えても、短い番号や状態表示が原因特定に役立つことがあります。
比較結果も有効です。小容量OBJは成功したが大容量OBJは失敗した、OBJ単体は成功したが画像を含めると失敗した、ブラウザは成功したが専用アプリケーションは失敗した、といった差を伝えます。
また、業務上なぜアップロードが必要なのかを説明します。どの程度の容量を、どの頻度で、どの接続先へ送る必要があるかが分かれば、管理者は一時的な例外ではなく、継続運用を考慮した安全な対応を検討できます。
単に制限を解除してほしいと依頼するのではなく、必要な通信条件を確認してほしいと伝えることが大切です。社内プロキシは安全性を確保するための仕組みであり、業務要件とセキュリティの両方を満たす方法を選ぶ必要があります。
点群OBJを再送するときの注意点
アップロードが失敗すると、同じOBJをすぐに再送したくなります。しかし、画面では失敗と表示されていても、送信先ではファイルの一部または全部を受信している可能性があります。
再送する前に、アップロード先に未完了データや同名ファイルが残っていないか確認します。重複したデータが作成されると、どれが最新か分からなくなり、後工程で誤ったOBJを参照する原因になります。
再送時にファイル名を変更する場合は、命名規則を決めます。無秩序に末尾へ文字を追加すると、版や更新順を判断しにくくなります。現場名、対象範囲、取得日、版などを必要な範囲で表現し、長すぎない名称にします。
大容量OBJを短時間に何度も再送すると、社内回線や通信検査へ負荷をかける可能性があります。原因が解消していない状態で試行回数だけを増やしても、同じ場所で停止する可能性が高いため、試験ごとに条件と結果を記録します。
送信中は、接続方法を切り替えたり、ブラウザを閉じたり、端末を休止させたりしないようにします。無線接続を利用している場合は、通信状態が安定した場所で作業します。
容量を減らした共有用OBJを作成する場合は、元データを上書きしないことが重要です。元の点群や高密度OBJは別に保存し、軽量化したファイルであることが分かる名称や管理情報を付けます。
不要範囲を削除する場合も、業務上必要な部分まで消していないか確認します。点群やメッシュは、見た目だけでは欠落を判断しにくいことがあります。既知の寸法、基準点、対象範囲、断面などを確認し、共有目的を満たしているかを判断します。
送信先でOBJを変換する場合は、アップロード完了だけでなく、変換処理の完了まで確認します。送信済みでも、解析や表示用データへの変換が失敗していれば、共有作業は完了していません。
変換後には、形状の欠落、座標のずれ、単位の違い、面の反転、材質や画像の不足がないか確認します。プロキシの問題を解決した後でも、OBJ自体の互換性に問題が残っている可能性があります。
継続的に点群OBJを扱う場合は、担当者ごとに異なる方法でアップロードするのではなく、社内標準を整備することが有効です。対象ファイルの作り方、容量の目安、関連ファイルのまとめ方、命名、送信先、承認、エラー時の連絡方法を決めておけば、同じ問題が起きたときに対応しやすくなります。
まとめ 点群OBJの送信経路を順番に確認する
点群OBJを社内プロキシ経由で送れないときは、OBJの容量だけを原因と考えず、アップロード処理が止まる段階から確認することが大切です。
最初に、ファイル選択時、送信開始時、送信途中、送信完了後のどこで失敗しているかを整理します。送信途中で止まる場合は、社内プロキシを通る通信経路、プロキシ認証、暗号化通信と証明書、容量と通信時間、セキュリティ検査、接続先の許可設定を順番に確認します。
小容量OBJとの比較や、OBJ単体と関連ファイルを含めた状態の比較を行えば、容量、形式、通信経路のどこに原因があるかを切り分けやすくなります。ただし、業務データを無断で社外回線へ送ったり、セキュリティ検査を回避したりしてはいけません。
情報システム担当者へ相談するときは、発生日時、利用端末、接続方法、ファイル容量、関連ファイル、停止した段階、表示されたメッセージ、成功条件と失敗条件を共有します。具体的な情報をそろえることで、通信記録との照合がしやすくなり、必要な対応を判断しやすくなります。
容量を減らす場合は、元データを保持し、共有用途に必要な形状や精度を失わないようにします。ファイルを分割するときも、座標、原点、対象範囲、関連ファイルの対応を管理し、後から正しい位置関係を再現できる状態にしておく必要があります。
点群の業務活用では、取得、処理、軽量化、アップロード、共有までを一つの流れとして設計することが重要です。現場で必要な範囲を計測し、位置情報を持つ点群を効率よく社内業務へつなげたい場合は、LRTK Phoneを活用した計測とデータ管理の運用も検討できます。