点群から生成したメッシュをOBJ形式で保存し、3次元データの閲覧環境や共有環境へアップロードした際に、作成時には分かれていた面グループが一つに統合されることがあります。地表面、構造物、法面、施工範囲、除外範囲などを分けていたにもかかわらず、アップロード後には全体が一つのメッシュとして選択される状態です。
面グループが統合されると、必要な範囲だけを表示したり、特定の部位へ属性を付けたりする操作が難しくなります。出来形の確認対象と周辺地形を分けたい場合や、施工前後の範囲を切り替えたい場合には、業務上の支障につながることもあります。
ただし、面グループが統合されたからといって、OBJファイルが必ず破損しているとは限りません。作成元の書き出し設定、OBJ内部のグループ定義、アップロード先の読み込み仕様、名称の重複、データ軽量化処理など、複数の要因が考えられます。作成元の画面では分かれて見えていても、OBJへ分割情報が書き込まれていなければ、アップロード後に元の状態を復元することは困難です。
この記事では、「点群 OBJ アップロード」で検索している実務担当者に向けて、面グループが統合される主な原因と4つの対策を解説します。特定のソフトウェアやサービスに依存せず、一般的なOBJの構造と3次元データ処理の流れに沿って、確認すべきポイントを整理します。
点群OBJで面グループが必要になる場面
OBJは、3次元形状を構成する頂点や面などを記録できるファイル形式です。点群そのものをOBJとして扱うケースもありますが、実務では、計測した点群から三角形メッシュを生成し、その結果をOBJとして書き出す運用が多く見られます。
点群から作成したメッシュは、単に形状を表示できればよいとは限りません。地表面と構造物を分けたい場合、計測対象と周辺部を分けたい場合、施工済み範囲と未施工範囲を分けたい場合など、複数の範囲を個別に管理する必要があります。
このような区分に利用される情報の一つが面グループです。面グループが維持されていれば、一つのOBJファイル内に複数の範囲を収めながら、表示や選択の単位を分けられる可能性があります。
例えば、造成現場の点群から作成したメッシュを、切土範囲、盛土範囲、既設構造物、周辺地形に分けているとします。アップロード後にも区分が維持されれば、確認したい範囲だけを表示し、不要な部分を一時的に非表示にできます。
一方、すべての面が一つに統合されると、既設構造物だけを選択したり、施工対象だけを差し替えたりすることが難しくなります。見た目は正しくても、運用上必要な編集単位や確認単位が失われている状態です。
面グループは、形状そのものとは別の管理情報です。頂点座標と面の構成が正しく保存されていれば、外観は問題なく表示できます。しかし、どの面がどの区分に属するかという情報が失われると、作成時の管理構造は再現できません。
そのため、点群OBJのアップロードでは、形状、座標、材質だけでなく、面グループやオブジェクトの区切りが維持されているかも確認することが重要です。
面グループとオブジェクトや材質の違い
面グループが統合される原因を調べる前に、面グループ、オブジェクト、材質、スムージンググループの違いを整理しておく必要があります。作成元の画面では似た機能に見えることがありますが、OBJ内では異なる情報として扱われます。
OBJでは、一般にグループを示す記述によって、後続する面を論理的なまとまりに分けます。グループが切り替わると、それ以降に記録される面が別のグループへ属する形になります。
オブジェクトを示す記述は、より大きな形状単位の区切りとして使われます。作成元で複数のオブジェクトに分かれていても、書き出し設定によっては一つのオブジェクト内の複数グループへ変換されることがあります。反対に、作成元のグループが、書き出し後には複数のオブジェクトとして保存される場合もあります。
材質は、面の色や表面表現に関係する情報です。材質の割り当てが変わる箇所を、アップロード先が別のメッシュとして扱うことがあります。その場合、面グループが異なっていても同じ材質を使用していると、一つに統合される可能性があります。
スムージンググループは、隣接する面の陰影を滑らかにつなげるか、角を明確に見せるかといった表示に関係します。部材の選択単位や管理単位を分けるための情報ではありません。
作成元で「グループ」と呼ばれている機能が、そのままOBJの面グループへ変換されるとは限りません。表示用のレイヤー、選択セット、分類、部材一覧などは、作成環境の内部だけで利用される情報であり、OBJ書き出し時に省略される場合があります。
点群の分類情報についても同様です。地表、植生、構造物などに点群を分類していても、メッシュ生成時にすべてを一つの面として再構成すれば、分類結果がOBJの面グループへ自動的に引き継がれるとは限りません。
面グループが統合された場合は、作成元で何を使って区分していたのか、その情報がOBJ内の何に変換されたのか、アップロード先が何を分割基準としているのかを分けて確認する必要があります。
面グループが統合される主な原因
面グループが統合される現象は、主に四つの段階で発生します。
一つ目は、作成元からOBJを書き出す段階です。作成画面では複数の区分に分かれていても、書き出し設定によってグループ情報が省略されることがあります。
二つ目は、アップロード先がOBJを解析する段階です。OBJ内にグループ情報があっても、アップロード先がその情報を読み込まず、すべての面を一つのメッシュとして処理する場合があります。
三つ目は、名称を識別する段階です。複数のグループに同じ名前が付いていると、読み込み側が同じグループの続きだと判断し、離れた面まで一つにまとめることがあります。
四つ目は、最適化や軽量化を行う段階です。重複頂点の削除、ポリゴン削減、材質統合などによって、グループ境界が失われることがあります。
原因を正しく切り分けるには、作成元、書き出したOBJ、再読み込み後、アップロード後という順に状態を比較します。アップロード後の結果だけを見ても、どの段階で情報が失われたかは判断できません。
原因1｜面グループ情報がOBJに出力されていない
最も基本的な原因は、作成元で設定した面グループがOBJファイルへ出力されていないことです。
作成元では、レイヤーや部材一覧を使って複数の範囲を分けていることがあります。しかし、それらが作成環境独自の管理情報である場合、OBJへ書き出したときに引き継がれない可能性があります。
OBJの書き出し画面には、オブジェクトを統合する設定、グループを保持する設定、材質を出力する設定、頂点を共有する設定などが用意されていることがあります。すべての形状を一つのオブジェクトとして出力する設定が有効になっていると、作成元の区分が失われる場合があります。
また、グループを保持する設定があっても、どの種類のグループを対象にしているかを確認する必要があります。面の選択グループが出力される場合もあれば、オブジェクト階層だけが出力され、表示レイヤーは無視される場合もあります。
点群からメッシュを生成した時点で、分類情報が失われるケースもあります。点群を地面と構造物に分けていても、それらをまとめて一度にメッシュ化すると、一続きの面として生成される可能性があります。
生成されたメッシュに面グループを設定し直さず、そのままOBJへ書き出せば、OBJ内には一つの面集合しか残りません。アップロード先には元の点群分類を知る手掛かりがないため、元の区分を復元することは困難です。
この原因を確認するには、書き出したOBJを再度読み込みます。再読み込みした段階ですでに一つに統合されている場合は、アップロード先より前の段階で情報が失われていると考えられます。
OBJをテキストとして確認する方法もあります。グループやオブジェクトを示す記述が一つしかない場合や、そもそも記述が存在しない場合は、面グループが出力されていない可能性があります。
原因2｜アップロード先がグループ定義を使用していない
OBJ内に面グループが正しく記録されていても、アップロード先がその情報を利用するとは限りません。
OBJは広く利用されている形式ですが、読み込み側がすべての記述へ同じように対応するとは限りません。形状表示に必要な頂点と面だけを読み込み、グループ、オブジェクト、材質などの管理情報を一部省略することがあります。
アップロード先によっては、面グループではなくオブジェクトの区切りだけを別部材として認識します。この場合、一つのオブジェクト内に複数の面グループがあっても、アップロード後は一つのメッシュになります。
別の環境では、材質の切り替わりを分割基準にすることがあります。複数の面グループへ同じ材質が割り当てられていると、同じ材質を持つ面が統合される可能性があります。
アップロード時に、OBJを閲覧用の内部形式へ変換する環境もあります。表示速度を高めるために、頂点番号の並べ替え、重複頂点の削除、ポリゴンの再構成、材質の統合などが行われることがあります。
内部変換後の形式が面グループに対応していなければ、OBJ内に記録されていた区分は引き継がれません。見た目の形状や色は再現されていても、選択単位は一つになることがあります。
アップロード後にグループが統合された場合は、見た目だけでなく、一覧上の構造や選択単位も確認します。複数色で表示されていても、クリックすると全体が選択される場合は、材質だけが維持され、面グループは統合されている可能性があります。
アップロード先の仕様が分からない場合は、小規模なテストデータを使って確認します。面グループだけを変えたデータ、オブジェクトだけを分けたデータ、材質だけを変えたデータを用意すると、どの情報が分割基準として利用されるかを判断しやすくなります。
原因3｜グループ名やオブジェクト名が重複している
グループ情報が出力され、アップロード先も対応しているにもかかわらず統合される場合は、名称の重複を確認します。
OBJ内で同じグループ名が複数回使用されていると、読み込み側が同一グループの続きとして扱うことがあります。位置が離れていても、名称が同じであれば一つのグループとしてまとめられる可能性があります。
例えば、複数の工区をそれぞれ独立して作成していても、すべてのグループ名が「地形」になっていると、アップロード先では一つの地形グループへ統合される場合があります。
オブジェクト名についても同様です。複製した形状に同じ名前が残っていたり、自動的に付けられた仮名称が重複していたりすると、読み込み側が同じオブジェクトとして扱う可能性があります。
名称の一部だけを変える方法にも注意が必要です。空白、全角と半角の違い、特殊な記号、末尾の記号などで区別している場合、アップロード時の文字処理によって同じ名称へ変換されることがあります。
大文字と小文字だけで区別する方法も避けた方が安全です。作成元では別名として認識されても、アップロード先が大文字と小文字を区別しなければ、同じ名前として処理されます。
名称が長すぎる場合、読み込み時に途中までしか使用されず、異なる名称が同じ文字列へ短縮される可能性もあります。特に、名称の末尾だけで連番を付けていると、末尾が省略された際に重複が生じます。
作成元で表示されている名前と、OBJへ出力される名前が異なる場合もあります。画面上の表示名ではなく、内部名がOBJへ書き込まれる仕組みでは、表示上は重複がなくてもファイル内では同じ名称になっていることがあります。
書き出し後にOBJ内のグループ名とオブジェクト名を確認し、同じ名称が意図せず繰り返されていないかを調べることが重要です。
原因4｜最適化や頂点統合で境界が失われている
OBJの容量を抑えたり表示を軽くしたりするために、ポリゴン削減や頂点統合を行うことがあります。これらの処理は有効ですが、設定によっては面グループの境界を失う原因になります。
隣り合うグループが同じ位置に頂点を持っている場合、重複頂点を削除する処理によって頂点が共有されることがあります。頂点を共有しただけでグループが必ず消えるわけではありませんが、最適化処理がグループ情報を保持しない場合は、境界が失われる可能性があります。
ポリゴン削減では、形状を近似しながら面数を減らします。グループ境界を保護せずに処理すると、境界付近の頂点や面が再構成され、異なるグループをまたぐ面が生成される場合があります。
点群からメッシュを再生成するときにも注意が必要です。複数の分類や区分をまとめて再メッシュ化すると、元の境界をまたぐ三角形が作られることがあります。一度連続したメッシュになった後では、どの面が元の分類に属していたかを判断しにくくなります。
材質統合も影響する場合があります。アップロード先が材質ごとにメッシュを分ける仕様であるとき、複数の材質を一つへまとめると、分割基準も失われます。
三角形化や法線の再計算そのものが、必ずグループ統合を起こすわけではありません。ただし、それらと同時にオブジェクト結合や頂点統合が実行されると、結果として面グループが一つになる場合があります。
作成元へ再読み込みした時点ではグループが維持され、アップロード後だけ統合される場合は、アップロード時の自動最適化が影響している可能性があります。
重要な境界を確実に残したい場合は、論理的な面グループだけに依存せず、独立したオブジェクトや別ファイルとして分離する方法を検討する必要があります。
対策1｜書き出し設定でグループ情報を維持する
一つ目の対策は、OBJを書き出す際に、面グループやオブジェクトの情報を維持する設定を選ぶことです。
最初に、作成元で使用している区分がOBJへ出力可能な情報かを確認します。表示レイヤーや一時的な選択状態ではなく、面グループまたは独立オブジェクトとして設定されている必要があります。
書き出し画面にグループ保持、オブジェクト保持、材質出力、オブジェクト結合などの設定がある場合は、目的に合わせて選択します。すべての形状を結合する設定が有効になっていると、作成元で分けた区分が一つになる可能性があります。
複数のオブジェクトを一つのOBJへ保存すること自体は問題ではありません。重要なのは、OBJ内にオブジェクトやグループの区切りが記録される設定になっているかどうかです。
頂点統合の設定も確認します。境界をまたいで頂点を共有させたくない場合は、グループやオブジェクトの境界で頂点を分けて出力します。ただし、頂点を分けるとファイル容量が増えることがあるため、必要な区分だけを対象にします。
材質を分割基準として利用する場合は、材質情報も正しく出力します。OBJと材質情報の参照関係が切れていると、アップロード先がすべてを同じ材質として処理し、結果として統合する可能性があります。
書き出し後は、必ず再読み込みを行います。作成元の画面で分かれていることを確認するだけでは不十分です。書き出したOBJを新しいデータとして読み込み、グループ数、オブジェクト数、名称、選択単位が維持されているかを確認します。
再読み込み時点で統合されている場合は、アップロードを繰り返すのではなく、書き出し設定を見直します。この段階で問題を解決すれば、大容量データを何度もアップロードする手間を減らせます。
対策2｜名称を一意にして統合を防ぐ
二つ目の対策は、グループ名とオブジェクト名を一意にすることです。
名称には、区分の種類だけでなく、工区、位置、対象、連番などを組み合わせます。単に「地形」「構造物」とするのではなく、どの範囲かを識別できる規則を設けます。
例えば、工区を示す文字列、対象種別、連番を一定の順序で並べると、名称の重複を防ぎやすくなります。更新版を管理する必要がある場合は、版を識別できる情報も追加します。
ただし、日付や版だけで名前を分けると、更新のたびに名称が変わり、過去データとの対応が分かりにくくなることがあります。固定の区分識別子と、更新情報を分けて管理する方法が有効です。
名称に使用する文字も統一します。空白や特殊な記号だけで区別する方法は避け、読み込み環境が変わっても置換されにくい文字を中心に構成します。
全角と半角の違い、大文字と小文字の違いだけで名称を分ける方法も避けます。作成元では別名になっていても、アップロード先では同じ名称として処理される可能性があります。
名称は必要以上に長くしないことも重要です。先頭部分がすべて同じで、末尾だけが異なる長い名称は、読み込み時に短縮されると重複するおそれがあります。
複製したオブジェクトは、名称が自動的に変更されているか確認します。画面上では連番が付いていても、OBJへ書き出す内部名が元のまま残る場合があります。
名称を整理した後は、書き出したOBJ内で実際の記述を確認します。作成元の一覧だけを見て判断せず、ファイルへ書き込まれた名称が一意になっていることを確認します。
命名規則を手順書として残しておくと、複数の担当者が作業する場合でも重複を防ぎやすくなります。
対策3｜重要な区分を独立オブジェクトや別ファイルにする
三つ目の対策は、業務上必ず分ける必要がある区分を、面グループだけで管理しないことです。
面グループは、一つのOBJ内で複数の範囲を効率よく整理できる便利な情報です。しかし、アップロード先が面グループに対応していない場合や、自動最適化で情報が省略される場合には、区分を維持できません。
施工範囲と周辺地形、地表面と構造物、計測対象と除外範囲など、アップロード後に必ず個別操作したい区分は、独立オブジェクトとして作成します。
アップロード先がオブジェクトの区切りにも対応していない場合や、確実に個別管理したい場合は、OBJファイル自体を分けます。別ファイルであれば、それぞれを独立したデータとしてアップロードしやすくなります。
ファイルを分けると、表示の切り替え、差し替え、更新、削除などを範囲ごとに行いやすくなります。一部だけを再計測した場合も、対象ファイルだけを更新できる可能性があります。
ただし、細かく分けすぎるとファイル管理が複雑になります。常に同時に表示する範囲や、同じ更新周期で扱う範囲まで分割する必要はありません。
分割単位は、実務上の操作単位に合わせます。個別に表示したいか、属性を別々に付けたいか、更新時期が異なるか、数量確認の範囲が異なるかを基準に判断します。
別ファイルにする場合は、座標系、原点、単位を統一します。各ファイルを別々の原点へ移動すると、アップロード後に正しい位置関係を再現できなくなる可能性があります。
ファイル名にも一意な命名規則を使用します。グループ名、オブジェクト名、ファイル名の対応を記録しておけば、どの範囲がどのデータに含まれているかを確認しやすくなります。
面グループ、オブジェクト、別ファイルの三段階を使い分けることで、互換性と管理性のバランスを取りやすくなります。
対策4｜小規模データで再読み込みと試験アップロードを行う
四つ目の対策は、本番データを処理する前に、小規模な検証用OBJを作成することです。
面グループの扱いは、作成元とアップロード先の組み合わせによって変わることがあります。設定名だけを見ても、実際にどの情報が維持されるかを判断できない場合があります。
検証用データには、少なくとも二つ以上の範囲を用意します。それぞれへ異なるグループ名を付け、可能であればオブジェクト名と材質も分けます。
最初に、作成元からOBJを書き出し、同じ環境へ再読み込みします。ここで区分が消えていれば、書き出し設定またはメッシュ生成方法に原因があります。
再読み込み後も区分が維持されている場合は、そのOBJをアップロードします。アップロード後には、外観だけでなく、選択単位、一覧構造、表示切り替え、属性の付与単位を確認します。
グループ名だけを変えたデータ、オブジェクトだけを分けたデータ、材質だけを変えたデータを用意すると、アップロード先がどの情報を分割基準にしているかを判断できます。
例えば、面グループを変えても一つに統合され、オブジェクトを分けると別々に読み込まれる場合は、面グループではなくオブジェクト単位でデータを作る必要があります。
材質を変えたときだけ分かれる場合は、材質が分割基準になっている可能性があります。ただし、材質を管理区分の代わりに使用すると、色や表面表現の変更が区分構造へ影響するため、運用上の注意が必要です。
検証時には、書き出し条件と結果を記録します。グループ数、オブジェクト数、材質数、頂点統合の有無、ポリゴン削減の有無、アップロード後の選択単位などを残します。
条件が確定してから本番データを書き出せば、大容量OBJの再処理や再アップロードを減らせます。特に通信環境が不安定な現場や、処理時間が長いデータでは、小規模検証が有効です。
アップロード前に確認したいOBJ内部の記述
OBJはテキスト形式で記録されるため、必要に応じてファイル内部の記述を確認できます。
ただし、大容量のOBJを一般的なテキスト編集環境で開くと、動作が重くなることがあります。編集する必要はなく、検索機能を使ってグループやオブジェクトの記述だけを確認する方法でも十分です。
最初に確認したいのは、グループを示す記述が存在するかどうかです。作成元で複数の面グループを設定したにもかかわらず、OBJ内に一つしか記録されていない場合は、書き出し時に統合されています。
次に、オブジェクトを示す記述を確認します。複数の独立オブジェクトを作成していた場合は、期待する数の区切りが記録されているかを調べます。
グループ名とオブジェクト名が重複していないかも確認します。同じ名称が何度も使われている場合、それが意図した構造か、書き出し時の名称変換によるものかを判断します。
材質を分割基準として利用する場合は、材質の切り替えが正しく記録されているかを確認します。すべての面へ同じ材質が割り当てられていると、材質単位で読み込む環境では一つに統合される可能性があります。
面の記述がどのグループ指定の後に並んでいるかも重要です。グループ名だけが複数記録されていても、面の記述が意図したグループへ配置されていなければ、正しく分割されません。
OBJを直接編集して修正することも技術的には可能ですが、大容量データでは面の範囲や頂点参照を誤って変更するおそれがあります。基本的には、作成元の設定を修正して再書き出しする方が安全です。
ファイル内部の確認は、原因を判断するための検査として利用します。グループ定義が正しければアップロード先を確認し、定義が不足していれば書き出し設定を見直すという切り分けができます。
大容量の点群OBJを扱うときの注意点
点群から生成した高密度メッシュは、頂点数や面数が多くなりやすく、書き出し、アップロード、解析、表示に時間がかかります。
面グループを維持するために境界ごとに頂点を分けると、同じ位置へ複数の頂点が作成されることがあります。その結果、OBJの容量が増える可能性があります。
すべての細かな境界を残そうとすると、グループ数や頂点数が増え、アップロード後の管理も複雑になります。計測時の区分をそのまま残すのではなく、実務上必要な管理単位へ整理することが大切です。
ポリゴン削減を行う場合は、処理前後でグループ数を比較します。形状の見た目だけを確認すると、境界情報が消えていることに気づかない場合があります。
削減処理後には、再読み込みして選択単位を確認します。境界付近の面が別グループへ移動していないか、複数グループが一つになっていないかも確認します。
ファイル分割を行う場合は、座標基準をそろえます。容量を小さくするためにローカル座標へ変換する場合は、すべてのファイルへ同じ変換条件を適用します。
座標値が大きいデータでは、表示環境の内部処理によって位置や形状に影響が出る場合があります。面グループ統合とは別の問題ですが、複数の区分が同じ位置へ重なり、統合されたように見えることがあります。
アップロード前には、座標系、原点、単位、軸方向を確認します。グループ構造の確認と座標の確認を分けて行うことで、原因を混同しにくくなります。
大容量データを一度にアップロードする前に、同じ設定で小さな範囲を書き出して検証します。小規模データで面グループが維持されない場合、本番データでも同じ結果になる可能性があります。
必要な範囲だけを抽出してアップロードする方法も有効です。周辺地形を含めすぎると容量が増え、最適化処理の影響も大きくなる可能性があります。
面グループを維持する実務フロー
点群OBJの面グループを安定して維持するには、作成からアップロード後の確認までを一つの手順として管理します。
最初に、アップロード後に必要となる操作単位を決めます。どの範囲を個別に表示したいか、どの範囲へ属性を付けたいか、どの範囲を更新または差し替えたいかを整理します。
次に、点群またはメッシュを、その操作単位に合わせて分けます。取得日や作業者だけで区分するのではなく、実際の確認業務や更新業務に合わせます。
各グループとオブジェクトには、一意な名称を付けます。命名規則を統一し、同じ名前や文字処理によって同一化されやすい名前を避けます。
OBJを書き出す前に、不要なオブジェクト、非表示の補助形状、重複した面、孤立した頂点などが含まれていないかを確認します。不要なデータが混ざると、統合や最適化の結果を判断しにくくなります。
書き出し時には、グループ保持、オブジェクト保持、材質出力、頂点統合、ポリゴン削減などの設定を確認します。前回使用した設定が残っていても、今回の目的に合っているとは限りません。
書き出したOBJは、作成元へ新規データとして再読み込みします。元のデータを開いたまま確認するのではなく、書き出し結果だけを読み込むことで、OBJに保存された情報を検査できます。
再読み込み後に、グループ数、オブジェクト数、名称、材質、選択単位を確認します。形状や色だけでなく、管理構造が維持されているかを確認することが重要です。
次に、小規模データをアップロードし、アップロード先の分割基準を確認します。面グループが使われない場合は、独立オブジェクトまたは別ファイルへ変更します。
本番データをアップロードした後も、一覧上の構造、選択単位、表示切り替え、属性の付与先を確認します。見た目が正しくても、内部では全体が一つになっている可能性があります。
採用した設定は、書き出し手順として記録します。使用した区分方法、命名規則、分割単位、軽量化条件、アップロード後の確認項目を残しておくと、更新作業でも同じ構造を再現しやすくなります。
まとめ
点群OBJをアップロードした際に面グループが統合される原因は、主に四つあります。
一つ目は、作成元のグループ情報がOBJへ出力されていないことです。画面上で区分されていても、OBJへ記録されなければ、アップロード後に再現することはできません。
二つ目は、アップロード先が面グループを分割基準として利用していないことです。オブジェクトや材質だけを認識する環境では、面グループが存在していても一つのメッシュとして読み込まれる可能性があります。
三つ目は、グループ名やオブジェクト名の重複です。同じ名称が複数回使われていると、離れた範囲まで同一グループとして統合される場合があります。
四つ目は、ポリゴン削減、頂点統合、材質統合などの最適化処理によって境界情報が失われることです。
対策としては、書き出し設定でグループ情報を維持すること、名称を一意にすること、重要な区分を独立オブジェクトや別ファイルとして分離すること、小規模データで再読み込みと試験アップロードを行うことが有効です。
特に重要なのは、どの段階で面グループが失われたかを切り分けることです。作成元、書き出したOBJ、再読み込み後、アップロード後の順に確認すれば、原因を絞り込みやすくなります。
点群OBJのアップロードでは、形状が表示できることだけでなく、業務で必要な選択単位や更新単位が維持されているかを確認する必要があります。現場で取得した点群の作成、確認、共有までを効率化したい場合は、LRTK Phoneを活用した3次元計測とデータ運用も検討できます。