点群データをOBJ形式で書き出し、クラウド上の三次元ビューアーや管理システムへアップロードしようとした際に、エラーで受け付けられないことがあります。ファイルの拡張子は正しく、テキストとして開けば多数の座標値が記録されているにもかかわらず、「有効な形状がありません」「モデルを読み込めません」「対応していないデータです」などと表示される場合は、OBJ内に面情報が存在しないことが原因かもしれません。
OBJは点群専用のファイル形式ではなく、頂点、線、面、法線、テクスチャ座標などを記述できる汎用的な三次元形式です。そのため、頂点座標だけを保存した面なし点群OBJも作成できます。しかし、アップロード先がOBJをポリゴンメッシュとして読み込む設計になっている場合、頂点だけのOBJは有効なモデルとして認識されません。
面なし点群OBJのアップロード問題を解決するには、単に拡張子を変更するのではなく、OBJの内部構造とアップロード先の対応条件を確認する必要があります。点要素を明示したOBJに直す方法、点群から面を生成する方法、点群向け形式へ変換する方法、各点を小さな面に置き換える方法など、目的に応じた対処が求められます。
この記事では、「点群 OBJ アップロード」で困っている実務担当者に向けて、面なし点群OBJが受け付けられない主な原因と4つの変換策を解説します。変換前の確認方法、座標や容量に関する注意点、再アップロード後の検証方法まで整理し、元の計測情報をできるだけ損なわずに利用するための考え方を紹介します。
面なし点群OBJとはどのようなデータか
面なし点群OBJとは、三次元空間上の位置を表す頂点座標が記録されている一方で、複数の頂点を結んでポリゴンを構成する面情報が記録されていないOBJファイルです。ファイルをテキストとして確認すると、頂点を示す行が大量に並んでいますが、面を構成するための参照情報がありません。
三次元データでは、点群とポリゴンメッシュが混同されることがありますが、両者の構造は異なります。点群は、それぞれ独立した点の位置を記録したデータです。点と点の間にどのような表面が存在するかは、基本的に定義されていません。一方、ポリゴンメッシュは、複数の頂点を三角形や四角形などの面で接続し、対象物の表面を表現します。
OBJはポリゴンメッシュの受け渡しに利用されることが多いため、OBJ対応と記載されたシステムでも、実際には面を持つモデルだけを対象としている場合があります。OBJという拡張子を認識できることと、OBJで表現可能なすべての要素を読み込めることは同じではありません。
頂点だけのOBJであっても、ファイルとして直ちに不正とは限りません。点の位置を保存する目的で利用できる場合もあります。ただし、読み込み側が点描画に対応していなければ、座標が存在していても表示されません。頂点が面や線から参照されていないため、未使用の情報として無視されることもあります。
また、面なし点群OBJには、座標だけが記録されたものと、座標に加えて色が記録されたものがあります。さらに、点として扱うための参照情報を持つものと、頂点行だけで構成されるものがあります。外見上は同じOBJでも内部構造が異なるため、アップロードできない原因を調べる際は、面の有無だけでなく、点要素や属性の記述方法まで確認することが重要です。
面なし点群OBJをアップロードできない主な原因
面なし点群OBJをアップロードできない理由は、一つとは限りません。代表的な原因として、アップロード先が面情報を必須としていること、頂点だけのデータを点として認識しないこと、頂点カラーなどの追加属性を解釈できないこと、座標値やファイル容量が処理条件に合わないことが挙げられます。
実務では、アップロード画面に表示されるエラーだけで原因を断定するのは困難です。「ファイル形式が不正です」という表示でも、拡張子が間違っているとは限りません。内部に有効な面がない、読み取れない数値が含まれている、必要な要素が不足しているなど、複数の状態が同じエラーにまとめられている場合があります。
原因を効率よく切り分けるには、元データを複製し、点数を減らした検証用ファイルを用意します。少数の頂点だけを含む面なしOBJでも失敗する場合は、容量ではなく構造上の非互換が疑われます。少数点では成功し、全点では失敗する場合は、容量、点数、座標範囲、処理時間などの影響を確認します。
さらに、同じ点を使い、面なし版と簡単な面を持つ版を作って比較する方法も有効です。面を持つ版だけが成功するなら、アップロード先がポリゴンを必須としている可能性があります。点要素を明示した版だけが成功するなら、頂点行だけでは点として扱われていなかったと考えられます。
原因を切り分けず、同じ条件で何度も書き出しても改善しません。変換を始める前に、どの要素が不足しているのか、どの条件で失敗するのかを小さなデータで確認することが、結果的に作業時間の短縮につながります。
原因1はアップロード先が面情報を必須としている
もっとも考えやすい原因は、アップロード先がOBJをポリゴンメッシュとしてのみ扱っていることです。このような環境では、ファイル内から面を構成する情報を探し、三角形や四角形を内部データへ変換します。面が一つも見つからなければ、読み込み対象が存在しないと判断されることがあります。
頂点座標が数百万点記録されていても、読み込み処理が面だけを対象にしている場合、すべての頂点が未使用として扱われます。その結果、アップロード直後にエラーになる場合もあれば、処理は完了したように見えてプレビューに何も表示されない場合もあります。
面情報が必須かどうかは、アップロード画面の対応形式一覧だけでは分からないことがあります。「OBJ対応」と記載されていても、それが点、線、面のどこまでを含むのかは実装によって異なります。仕様説明にポリゴン数、三角形数、テクスチャなどの記載が中心となっている場合は、メッシュモデルを前提としている可能性があります。
この原因に対しては、点群から面を生成し、ポリゴンメッシュへ変換する方法が考えられます。ただし、面を生成する処理は単なる保存形式の変更ではありません。元の点群には存在しなかった点同士の接続関係を推定し、計測されていない隙間を補間することがあります。
地面、床、壁、法面など、連続した表面を持つ対象では面生成が有効です。一方、樹木、電線、配管、足場、フェンスなど、細い部材や複雑な重なりが多い対象では、本来つながっていない点の間に面が作られる可能性があります。アップロードを成功させるためだけに全面を自動生成すると、実際の形状と異なるモデルになるため注意が必要です。
原因2は頂点だけでは点として認識されない
面なし点群OBJの中には、頂点座標を記録した行だけで構成され、各頂点を点として描画するための情報が明示されていないものがあります。一部の表示環境は、このような未使用頂点を自動的に点群として描画します。しかし、別の環境では、面や線などから参照されていない頂点を表示対象にしません。
そのため、同じOBJを作成元の確認画面では表示できても、アップロード先では空のモデルになることがあります。この違いは、ファイルが壊れているからではなく、頂点の扱いに関する実装差によって生じます。
OBJでは、頂点番号を参照して点を示す構造を記述できます。アップロード先が点要素に対応している場合は、頂点だけを並べた状態よりも、どの頂点を点として扱うかを明示した状態の方が認識されやすくなります。ただし、点要素自体に対応していない環境では、この変換を行っても読み込めません。
また、点が読み込まれていても、表示上の点サイズが非常に小さく設定されていると、何もないように見えることがあります。モデルの位置や表示倍率によっては、拡大しないと点を確認できません。アップロード成功の表示が出ている場合は、全体表示、点サイズ、背景色、カメラ位置なども確認する必要があります。
点要素の対応状況が分からない場合は、数十点程度の小さなサンプルを作ります。頂点だけのOBJ、点要素を明示したOBJ、簡単な三角形を含むOBJを用意し、それぞれの結果を比較すると、読み込み側がどの構造に対応しているかを判断しやすくなります。
原因3は頂点カラーや追加属性の記述が合わない
点群データでは、各点の座標だけでなく、赤、緑、青などの色を保持することがあります。OBJへ書き出す際に、頂点座標の後ろへ色の値を追加する方法が使われる場合がありますが、この記述をすべての読み込み環境が同じように解釈するとは限りません。
読み込み側が座標値だけを想定している場合、追加された色の値を不正な列として扱い、頂点行全体の解析に失敗する可能性があります。ファイル全体が拒否される場合もあれば、座標だけが読み込まれ、色が失われる場合もあります。
色の数値範囲にも注意が必要です。書き出し条件によって、色が0から1の範囲で表現される場合と、0から255の範囲で表現される場合があります。読み込み側の想定と異なると、色が白飛びする、暗くなる、すべて同じ色になるなどの問題が発生します。
さらに、座標と色のほかに、強度、分類、時刻、法線などの情報が独自に追加されていると、一般的なOBJの読み込み処理では扱えない場合があります。拡張的な記述を作成元では利用できても、アップロード先では非対応というケースです。
原因を確認するには、元データを残したまま、検証用の複製から追加属性を外し、座標だけを記録した小さなOBJを作ります。座標だけの状態で読み込めるなら、色または追加属性の記述が影響している可能性が高いと判断できます。
色や分類を実務で利用する必要がある場合は、属性を削除して終わりにするのではなく、それらを保持できる点群向け形式へ変換する方法を検討します。見た目だけを共有する場合と、属性を解析に使う場合では、適切な変換方法が異なります。
原因4は座標値やファイル容量が処理条件を超えている
面がないこと以外にも、座標値やファイル容量が原因でアップロードに失敗することがあります。OBJはテキスト形式で座標を記録するため、点数が多いほどファイルが大きくなります。小数桁が長い場合は、同じ点数でも容量が増加します。
アップロード可能な容量以内であっても、読み込み時に内部形式へ展開されることで、より多くのメモリが必要になる場合があります。送信は完了しても、サーバー側または端末側の解析中に処理が停止することがあります。大容量の点群OBJでは、アップロード上限だけでなく、点数、解析時間、内部メモリの条件も考える必要があります。
座標値が原点から大きく離れている場合も注意が必要です。測量座標などの大きな数値をそのまま使用すると、表示処理の数値精度によって、点が揺れる、形状が崩れる、位置がずれるなどの現象が発生することがあります。読み込み自体は成功しても、モデルが遠くに配置され、初期画面では見えないこともあります。
単位の不一致もよくある問題です。作成側がメートルを想定し、読み込み側が別の単位として扱うと、モデルが極端に大きくなったり小さくなったりします。カメラの表示範囲や切断範囲から外れ、何も表示されないように見える場合があります。
座標値の中に数値として解釈できない文字、未定義値、無限大を表す値などが含まれていると、少数の異常点でもファイル全体の処理が止まる可能性があります。外れ点によって座標範囲が極端に広がり、本来の点群が画面上で非常に小さく表示されることもあります。
対策としては、不要な外れ点を確認し、作業範囲の近くへ一時的に原点を移動し、必要な精度を保てる範囲で小数桁を整理します。ただし、座標を移動した場合は、元の位置へ戻すための移動量、座標系、単位を必ず記録してください。
変換前に確認すべきOBJの内部構造
変換を行う前に、元のOBJを上書きせず、変更前のファイルを保管します。点群から面を生成したり、点を間引いたり、座標を移動したりすると、処理前の状態へ完全に戻せない場合があります。必ず複製を作り、作業用ファイルに対して変換を行います。
最初に確認するのは、頂点、点、線、面がそれぞれ含まれているかです。大容量ファイルを最初から最後まで目視する必要はありません。先頭部分、途中、末尾を確認し、要素の種類ごとの行数を集計すれば、構造の概要を把握できます。
頂点は存在しているものの、点と面がどちらも存在しない場合は、座標だけを保存したOBJです。点要素が存在する場合は、アップロード先の点描画対応を確認します。面要素が存在するのに読み込めない場合は、面が参照する頂点番号の不整合、無効な面、重複面など、別の問題が考えられます。
次に、各頂点行の列数を確認します。すべての行が座標値だけなのか、色などの追加値を含むのか、途中から列数が変化していないかを見ます。1行だけ形式が異なる場合でも、読み込み処理が停止する可能性があります。
座標範囲の確認も欠かせません。各軸の最小値と最大値を調べると、単位違い、外れ点、想定外の位置を発見しやすくなります。対象範囲が数十メートル程度のはずなのに、数千キロメートル相当の広がりがある場合は、外れ点や異なる座標系のデータが混在している可能性があります。
点数、ファイル容量、小数桁、改行、文字コードも確認します。ファイル名には、元データ、変換方法、間引き率、原点移動の有無などが分かる情報を付けると管理しやすくなります。元の座標系や変換条件は、ファイルとは別に記録しておくと、後工程で位置を復元できます。
変換策1は点要素を明示したOBJへ再出力する
アップロード先がOBJの点要素に対応している場合は、頂点座標だけのOBJを、各頂点が点として明示されたOBJへ再出力します。この方法では、点同士を面で接続しないため、元の点群の離散的な構造を維持できます。
変換の基本は、既存の頂点座標を残し、各頂点番号を点として参照する情報を追加することです。頂点番号の開始位置や参照順序を誤ると、存在しない頂点を参照して読み込みエラーになるため、変換後に頂点数と参照数を確認します。
この方法は、地表を勝手に補間したくない場合に適しています。樹木、設備、配管、電線、フェンスなど、本来連続面ではない対象を点のまま保持したいときにも有効です。点の位置を変えずに読み込み側へ用途を明示できるため、対応環境であれば比較的影響の少ない変換です。
一方、点の大きさ、形、色などの見え方は表示側に依存します。OBJ内に点が記録されていても、表示側の点サイズが小さすぎると、拡大しなければ確認できません。点カラーの記述に対応していなければ、単色で表示される場合もあります。
まず、数十点または数百点程度の小さなファイルで確認します。点要素を明示した小容量OBJが表示できたら、点数を段階的に増やします。小さいファイルは成功し、大きなファイルだけが失敗する場合は、点要素ではなく容量や処理負荷が問題になっている可能性があります。
この方法を選ぶ前提は、アップロード先が点要素を受け付けることです。面のみ対応する環境では解決しないため、最小データによる事前検証が重要です。
変換策2は点群から面を生成してメッシュOBJにする
アップロード先が面を持つOBJだけを扱う場合は、点群から三角形などの面を生成し、ポリゴンメッシュへ変換します。道路、地面、法面、床、壁、屋根など、連続した表面を持つ対象では利用しやすい方法です。
ただし、面生成はデータ形式だけを変更する処理ではありません。どの点とどの点を接続するかを計算し、点のない部分にも面を作る可能性があります。生成された面は実測点そのものではなく、点群を基に推定された表面です。
面を生成する前には、重複点、孤立点、外れ点、不要な背景を確認します。ノイズが多い状態で面を作ると、細長い三角形、針状の突起、裏返った面、本来離れている場所を結ぶ面などが発生しやすくなります。
点の密度に大きな差がある場合も注意が必要です。高密度部分に合わせて細かな面を作ると、全体の面数が増えて容量が大きくなります。低密度部分に合わせると、段差や角部などの細かな形状が失われます。必要な精度とアップロード後の操作性を考え、面の細かさを調整します。
穴埋め処理を強く行うと、計測できていない場所まで面でふさがれる場合があります。構造物の開口部、遮蔽部分、対象物の裏側などに存在する穴は、単なる欠陥ではなく、計測情報がないことを示している可能性があります。見た目を整える目的で穴を埋める場合は、元の点群と区別して管理する必要があります。
面生成後は、法線の向きも確認します。面の向きが反転していると、片側から見たときに消えたり、照明が不自然になったりします。重複面や交差面が多いと、表示時にちらつくことがあります。
完成したメッシュOBJは、元の点群より軽くなる場合もありますが、設定によっては非常に多くの面を持つデータになります。アップロード先の処理条件に合わせ、必要に応じて簡略化した共有用データを別に作成します。
変換策3は点群向けのファイル形式へ変換する
アップロード先が点群向けの形式に対応している場合は、面なしOBJを無理にメッシュへ変えず、点群を扱うために設計された形式へ変換する方法が適しています。候補として、PLY、LAS、LAZ、XYZ、E57などがあります。
それぞれの形式で保持できる情報は異なります。座標だけを保存するもの、色を保持できるもの、強度や分類を保持できるもの、圧縮に対応するものなどがあります。どの形式を選ぶかは、アップロード先の対応状況と、後工程で必要な属性によって決まります。
点群向け形式を使う利点は、点を無理に面へ変換しなくてよいことです。点の分布、密度、色、分類などを利用する作業では、メッシュOBJよりも点群の特性を保ちやすくなります。
測量座標を扱う場合は、座標系や単位の情報をどのように引き継ぐかを確認します。形式によっては座標情報を保持できても、読み込み側で設定が必要な場合があります。変換後に表示位置が変わったとき、形式変換の問題なのか、座標系の指定不足なのかを切り分けられるよう、元の設定を記録してください。
色を保持する場合は、変換前後で代表的な点の値を比較します。見た目が似ていても、色の数値範囲や並び順が変わっている可能性があります。強度や分類を使う場合も、属性名だけでなく、値が正しく対応していることを確認します。
テキスト型の点群形式は内容を確認しやすい一方、点数が多いと容量が増えやすくなります。圧縮可能な形式は容量を抑えやすいものの、アップロード先が解凍と読み込みに対応している必要があります。対応形式が複数ある場合は、容量、保持属性、処理速度を小さなサンプルで比較すると判断しやすくなります。
変換策4は各点を小さな面や立体に置き換える
アップロード先がメッシュOBJだけに対応し、点群のような見た目を残したい場合は、各点を小さな三角形、四角形、薄い板、立方体などへ置き換える方法があります。すべての点が面を持つ形状になるため、面情報を必須とする読み込み環境でもモデルとして認識されやすくなります。
この方法は、点同士を連続した面でつなげない点が特徴です。点群から地表のような面を推定するのではなく、それぞれの点を独立した小さな形状へ変換します。そのため、本来つながっていない点を誤って接続する問題を避けやすくなります。
一方で、データ量が大きく増えることが最大の注意点です。1点を三角形にするだけでも、各点に複数の頂点と面情報が必要になります。立方体へ変換すれば、さらに多くの面が作られます。元の点群が数百万点ある場合、そのまま変換すると実用的でない容量になる可能性があります。
この変換を使う場合は、用途に応じて点を間引きます。全体形状を確認するだけなら、密度を下げても目的を満たせる場合があります。細部を確認する区域だけ高密度で残し、その他を粗くする方法も考えられます。
小さな面の大きさは、点間隔と表示縮尺に合わせます。大きすぎると隣の点と重なり、表面のように見えてしまいます。小さすぎると遠距離から見えません。座標単位を誤って設定すると、点の代わりとなる形状が極端に大きくなるため、単位の確認が必要です。
薄い面を一定方向に向けた場合、見る角度によってほとんど見えなくなることがあります。複数方向へ面を配置すると見えやすくなりますが、その分だけ面数が増えます。常に見えることを優先するなら立体化が考えられますが、容量とのバランスを取らなければなりません。
色付き点群では、それぞれの小さな面に元の点の色を割り当てることで、点群に近い外観を再現できる可能性があります。ただし、読み込み先が頂点色や材質のどちらに対応しているかを確認する必要があります。
用途に合う変換策を選ぶ判断基準
4つの変換策は、アップロード先の条件と利用目的を基準に選びます。元の点の位置をできるだけ変えず、点群として表示したい場合は、点要素を明示したOBJへの再出力が候補です。ただし、アップロード先が点要素に対応していなければ利用できません。
地面や壁面などを連続した表面として利用し、面積、断面、陰影などを確認したい場合は、メッシュOBJへの変換が適しています。ただし、生成面には補間が含まれるため、実測点と生成面を区別して扱います。
色、強度、分類などの点群属性を維持したい場合は、点群向け形式への変換を優先します。OBJへ無理に情報を詰め込むより、属性を明確に保持できる形式を選んだ方が、後工程での誤解を減らせます。
メッシュ専用の環境で点の配置を見せたいものの、連続面を作りたくない場合は、各点を小さな面や立体へ置き換える方法が考えられます。ただし、点数が多い場合は大幅な間引きが必要です。
一つの変換ファイルですべての目的を満たそうとする必要はありません。解析用には属性を保持した点群形式を使い、共有用には簡略化したメッシュOBJを使うなど、用途別に成果物を分ける方法があります。
大切なのは、アップロードに成功することだけを目的にしないことです。表示できても、座標が変わっている、縮尺が違う、色が失われている、未計測部分に面が作られている場合は、実務上の品質を満たしていません。変換前に、保持すべき情報と許容できる変更を決めておく必要があります。
再アップロード前後に確認するポイント
変換後のファイルは、いきなり全体をアップロードするのではなく、小さな範囲で試します。少数の点または面を含む検証用データを作成し、アップロード、解析、表示まで正常に完了するかを確認します。
小容量データが成功したら、点数や面数を段階的に増やします。ある規模を超えたところで失敗する場合は、構造ではなく容量や処理負荷が原因と考えられます。分割が可能な環境であれば、対象範囲を複数のファイルへ分ける方法も検討します。
アップロード後は、全体表示を行い、モデルが想定位置に存在するかを確認します。何も表示されない場合でも、遠くへ配置されている、極端に小さい、表示範囲外にある可能性があります。原点付近と元の座標付近の両方を確認してください。
縮尺の確認には、既知の2点間距離を利用します。変換前後で距離が一致しない場合は、単位変換や座標倍率に問題があります。見た目だけでは小さな倍率違いに気づきにくいため、数値で確認することが重要です。
座標を原点付近へ移した場合は、記録した移動量と一致しているかを確認します。他の測量データや設計データと重ねる用途では、元の座標へ正しく戻せることが必要です。
メッシュ化した場合は、穴、段差、角部、薄い部材、裏面を確認します。本来空いている場所が面でふさがれていないか、離れた対象物同士が接続されていないかを見ます。法線が反転していないか、重複面によるちらつきがないかも確認します。
色付きデータでは、代表的な場所の色が変換前後で一致するかを見ます。色が保持されていても、補間や値域の違いによって見え方が変わる場合があります。点群向け形式へ変換した場合は、色以外の属性も必要に応じて照合します。
最後に、アップロード後の操作性を確認します。表示できても、回転や拡大のたびに処理が止まる状態では実務利用が難しくなります。表示用途に対して過剰な点数や面数がないかを判断し、必要であれば共有用データを別途軽量化します。
点群OBJの変換作業を安定させる運用方法
面なし点群OBJのトラブルを繰り返さないためには、書き出し条件と確認手順を標準化することが重要です。担当者ごとに異なる条件で変換すると、同じ現場のデータでも容量、座標、属性、見え方が変わり、原因調査が難しくなります。
書き出し時には、座標系、単位、原点移動、小数桁、点の間引き率、色の保持、面生成の有無を記録します。メッシュを作る場合は、面の細かさ、穴埋め、簡略化の条件も残します。
ファイル名だけで変換条件をすべて表現しようとすると長くなり、誤解が生じます。元のファイル名と対応する管理記録を作り、元の点数、変換後の点数または面数、座標範囲、作成日、用途を残すと確認しやすくなります。
元データ、作業用データ、アップロード用データは分けて保存します。特に、点群から生成したメッシュは元の計測点と同じものではありません。生成面であることが分かる名称と説明を付け、元の点群を別に保管します。
アップロード先が複数ある場合は、すべてに同じOBJを使うのではなく、用途別の出力条件を用意します。点群対応環境には点群向け形式、メッシュ対応環境にはメッシュOBJ、簡易共有には軽量化データというように分けると、互換性と操作性を両立しやすくなります。
形式変換を何度も繰り返すと、座標精度や属性が少しずつ失われる可能性があります。中間ファイルをさらに変換するのではなく、可能な限り元の高品質な点群から各用途の成果物を直接作成します。
検証用の小さな標準データを用意しておくことも有効です。頂点だけのOBJ、点要素を持つOBJ、面を持つOBJ、色付きデータなどを準備し、アップロード先の更新や運用変更があったときに読み込み結果を比較します。これにより、システム側の条件が変わった場合も早く把握できます。
まとめ
面なし点群OBJをアップロードできない場合は、拡張子だけを見てファイル破損と判断せず、内部にどの要素が記録されているかを確認する必要があります。頂点座標が存在していても、面情報を必須とするアップロード先では有効なモデルとして認識されません。頂点だけのOBJを点として扱うかどうか、頂点カラーや追加属性を解釈できるかどうかにも実装差があります。
主な変換策は、点要素を明示したOBJへ再出力する方法、点群から面を生成してメッシュOBJにする方法、点群向けのファイル形式へ変換する方法、各点を小さな面や立体に置き換える方法の4つです。
元の点を維持したい場合は点要素の明示、連続した表面として利用したい場合はメッシュ化、色や分類などの属性を使いたい場合は点群向け形式、メッシュ専用環境で点の配置を見せたい場合は小さな面への置き換えが候補になります。
変換前には元データを保管し、頂点数、面の有無、点要素、追加属性、座標範囲、単位、ファイル容量を確認してください。変換後は小さな検証用データからアップロードし、表示の成否だけでなく、座標、縮尺、色、点数、面数、穴、角部が正しく保たれているかを確認します。
点群OBJのアップロードを安定させるには、取得段階から座標系、単位、対象範囲、必要な密度、最終的な利用方法を整理しておくことが大切です。現場で取得した点群をクラウド上の確認や後工程へつなげる運用を検討する際は、計測からデータ整理までを進められるLRTK Phoneの活用も選択肢になります。