点群OBJの「階層構造」とは何か
点群OBJをアップロードしたあと、現場区画や計測範囲ごとに分けていたデータが一つにまとまり、元の分類が分からなくなることがあります。書き出し前の画面では複数のオブジェクトやグループに分かれていたにもかかわらず、アップロード先では単一のモデルや一つの点群として表示される状態です。
この問題を正しく切り分けるには、最初に「階層構造」という言葉が何を指しているのかを整理する必要があります。実務で階層と呼ばれるものには、オブジェクト単位の分類、グループ単位の分類、材質による表示区分、フォルダーによるファイル分類、名称による管理分類などがあります。これらは似ていますが、OBJファイル内で扱われる仕組みは同じではありません。
OBJは、頂点座標や点、線、面などの幾何要素に加え、テクスチャ座標や法線などをテキストで記録できる形式です。ファイル内では、オブジェクト名を示すo、グループを示すg、材質の適用を切り替えるusemtlなどによって要素を論理的に区別できます。ただし、oやgは一般的な編集環境のツリー表示と同じ親子階層を表すものではなく、基本的には平面的な識別やグループ化のための記述です。
一般的な三次元データの編集環境で使われる親子関係、階層ごとの座標変換、表示状態、ロック状態、独自属性、作業履歴などが、OBJへそのまま保存されるとは限りません。たとえば上位階層に「A工区」、その下に「地表面」「構造物」「仮設物」を配置し、それぞれに個別の位置変換や表示設定を与えていても、その編集環境固有のツリー情報はOBJの標準的な記述だけでは再現できません。
そのため、OBJの階層保持を考える際は、元の編集環境と同じツリー構造を完全に再現することよりも、アップロード後に必要な単位を識別し、選択し、再分類できる手掛かりを残すことが現実的な目標になります。何を保持したいかを決めずに書き出すと、座標や形状は読み込めても、工区や部材の区別が消えて業務で使いにくくなる可能性があります。
点群をOBJで表す場合は、点の座標をvで定義するだけでなく、その頂点番号を点要素として参照するpの記述が使われます。vは頂点データの定義であり、p、l、fなどの要素記述がどのように出力されているかによって、読み込み先での扱いが変わります。書き出し元によっては点群向けの独自拡張や、標準仕様に含まれない頂点色の記法を使うこともあるため、OBJという拡張子だけで互換性を判断しないことが重要です。
アップロード先が点要素のpに対応していない場合や、gやoを点要素の分類として利用しない場合は、複数の区分が一つの点群へ統合されることがあります。反対に、面要素のfは読み込めても点要素は無視する実装も考えられます。点群OBJでは、ファイルが開けるかどうかだけでなく、点の要素、分類名、色、座標が意図どおり解釈されるかを確認する必要があります。
階層を保持するには、OBJの記述だけを見るのではなく、書き出し元、出力されたファイルの中身、アップロード時の変換、アップロード先の分類機能という一連の流れを確認します。どこか一つの段階で分類が統合または無視されると、それ以降の工程で元の区分を復元することが難しくなります。
階層構造が失われる主な原因
階層構造が失われる原因として最初に確認したいのが、書き出し時の統合処理です。元のデータが複数のレイヤーやオブジェクトに分かれていても、OBJ出力時に一つのオブジェクトとして書き出す設定や、同一材質の要素をまとめる設定が有効になっていると、分類境界が減少することがあります。
重複頂点の統合は、分類消失と常に同じ意味ではありません。OBJの面や点要素がグループごとに正しく参照されていれば、頂点を共有していても分類を残せる場合があります。ただし、書き出し元や変換先が頂点配列だけを基準に再構成する実装では、グループ境界が期待どおり残らないことがあります。最適化を行う場合は、どの情報が維持されるかを試験データで確認します。
二つ目の原因は、OBJ内に分類記述が出力されていないことです。画面上でフォルダーやレイヤーに分かれていても、書き出されたOBJにoやgが含まれていなければ、読み込み先が元の分類を推定することは困難です。点群として扱う場合は、pの点要素が出力されているか、各点要素が意図したoやgの区分内に記述されているかも確認します。
三つ目は、アップロード先がoやgを読み分けないケースです。OBJの読み込み方法はシステムによって異なり、すべての記述が同じように扱われるとは限りません。oだけを分割単位として使う、gだけを使う、材質単位で形状をまとめる、すべてを単一モデルへ統合するなど、実装によって結果が変わります。
四つ目は、アップロード時の変換処理です。閲覧や配信を軽くするためにOBJを別の内部形式へ変換する仕組みでは、頂点の並べ替え、面の三角形化、点の間引き、名称の正規化、重複要素の整理などが行われる場合があります。変換処理が分類名を引き継がなければ、元のOBJにoやgが残っていても、表示時には一つに見える可能性があります。
五つ目は、名称の衝突や文字の扱いです。空白、記号、全角文字、非常に長い名称、同一名称の繰り返しなどを読み込み先がどのように処理するかは一様ではありません。名称が省略、置換、正規化された結果、別々の区分が同じ名前になる可能性があります。名称の対応状況を確認できない場合は、英数字とアンダースコアを中心とした短い識別子で試験します。
六つ目は、点要素そのものの互換性です。vの行が多数存在していても、標準的な点要素として参照するpがなく、読み込み先が未参照頂点を表示しない場合は、点群として認識されない可能性があります。また、pに対応しない読み込み先では、分類以前に点が欠落することもあります。
七つ目は、材質や色を階層の代わりに使っていることです。usemtlとMTLは主に面や曲面の外観を指定する仕組みであり、親子階層を保存する仕組みではありません。点群の色に独自の頂点色記法を使っている場合も、読み込み先がその拡張に対応していなければ色分けが失われます。色が消えた結果、分類まで消えたように見えるケースを区別する必要があります。
八つ目は、関連ファイルの不足や参照先の不一致です。OBJがmtllibで参照するMTL、MTLが参照する画像ファイルなどが欠けると、材質やテクスチャによる表示上の区別が失われます。形状や点の分類情報が残っていても、色分けだけが消える場合があるため、階層情報の欠落と外観情報の欠落を分けて確認します。
九つ目は、圧縮ファイルやフォルダー構成の扱いです。OBJにはアップロード用ZIPの標準的な梱包方法が定められているわけではありません。サブフォルダーを含められるか、どの階層を起点に参照を解決するかはアップロード先の仕様によります。圧縮方法を一般論で決めず、対象システムが案内する構成に合わせる必要があります。
このように、階層構造が失われる原因はOBJの仕様だけではありません。書き出し設定、点要素の有無、名称、関連ファイル、アップロード先の対応範囲、内部変換が連続して影響します。原因を一つに決めつけず、工程ごとに確認することが早期解決につながります。
保持方法1：OBJ内のo・g・usemtlを確認する
一つ目の保持方法は、書き出されたOBJに必要な分類記述と要素記述が含まれているかを確認することです。元データの画面で階層が見えているだけでは、OBJへ分類が保存されたことにはなりません。アップロード前のファイルをテキストとして開き、o、g、p、f、mtllib、usemtlなどの記述を確認します。
oは、名前付きオブジェクトを示す記述です。工区単位、構造物単位、計測日単位など、アップロード後にも区別したい範囲ごとに異なる名称が出力されているかを確認します。ただし、複数のoが記述されていても、読み込み先が別オブジェクトとして表示するとは限りません。
gは要素を論理的なグループへまとめる記述です。OBJのgは編集環境のフォルダーツリーのような入れ子階層ではありません。名称を複数並べて一つの要素を複数グループへ所属させられる記法もあるため、書き出し元と読み込み先がどのように扱うかを確認します。アップロード先が一つ目のグループ名しか使わない、複数グループを統合する、gを無視するなどの違いも考えられます。
点群として出力されている場合は、vで定義した頂点番号がpで参照されているかを確認します。たとえばp 1 2 3は、先に定義された頂点を点要素として参照します。頂点の定義だけが並び、点、線、面などの要素記述がない場合、読み込み先によっては未参照頂点として扱われ、表示されない可能性があります。
usemtlは、以降の対応要素へ適用する材質名を指定する記述です。材質を使って面モデルを色分けしている場合は、材質の切り替えが正しく記録され、mtllibで参照するMTLに同じ材質名が定義されているかを確認します。ただし、材質区分は親子階層ではなく外観の割り当てです。同じ材質を使う離れた要素が、読み込み先で同じ表示区分へまとめられる可能性があります。
点群OBJでは、usemtlを分類保持の中心にしないほうが安全です。標準的なMTLは面や曲面の外観を扱うことを主眼としており、点要素への材質適用を利用できるかは読み込み先によります。点の色をv x y z r g bのような拡張記法で保存している場合も、それは元のOBJ仕様に含まれる必須機能ではなく、対応状況に差があります。
名称は重複させず、規則的に付けます。「地表面」のような名称を複数箇所で使うより、「A工区_地表面」「B工区_地表面」のように上位区分も含めた名称にしたほうが、一覧が平坦化されたあとでも識別しやすくなります。
アップロード先で親子関係を表現できない場合でも、名称に分類順序を含めれば、一覧上で並べやすくなります。たとえば「01_A工区_現況」「01_A工区_構造物」「02_B工区_現況」のように、区分番号を先頭へ付ける方法です。番号は桁数をそろえると、文字列として並べ替えた際にも順序が崩れにくくなります。
日本語名称や空白を使用できるかどうかは、書き出し元とアップロード先の両方で確認します。文字化けや名称欠落が発生する場合は、元データを保管したうえで、アップロード用の複製だけを英数字とアンダースコア中心の名称へ置き換えて検証します。
OBJ内を確認した結果、oやgが一度も出現せず、点や面の要素が一つの連続した区分として記述されている場合は、書き出し段階ですでに管理上の分類が失われている可能性があります。その場合はアップロード先だけを調整するのではなく、元データへ戻って書き出し条件を見直します。
保持方法2：書き出し時に結合・統合を避ける
二つ目の保持方法は、OBJを書き出す際に不要な結合や統合を行わないことです。複数のオブジェクトを一つの区分として出力すると、後から分割するための名称や境界が残らない場合があります。
書き出し元に、選択した要素を一つにまとめる設定、材質単位で統合する設定、同一名称を結合する設定などがある場合は、その目的を確認します。ファイル容量を小さくするために有効な設定でも、分類保持を重視する業務では適さないことがあります。
重複頂点の統合は、必ずしもオブジェクト分類を消す処理ではありません。面や点要素が適切なグループへ所属していれば、頂点を共有しながら分類を残せる場合があります。ただし、アップロード先が要素単位ではなく頂点集合として点群を再構成する場合は、境界が曖昧になる可能性があります。設定名だけで判断せず、出力後のo、g、p、fを確認します。
階層を保持したい場合は、まず最適化を最小限にした状態で書き出し、アップロード後に分類が残るかを確認します。分類が保持できたことを確認してから、点の間引き、重複除去、不要要素の削除などを段階的に追加すると、どの処理が分類消失の原因なのか判断しやすくなります。
元データの親子関係にも注意が必要です。子要素が親要素の位置、回転、縮尺を継承している場合、OBJへの書き出し時に変換後の座標へ確定されることがあります。形状の位置は正しくても、元の親子関係や個別の変換値は失われます。これは書き出し不良とは限らず、OBJが一般的なシーングラフを保存する形式ではないことによる制約です。
アップロード後に必要なのが絶対的な位置関係なのか、編集環境と同じ親子構造なのかを区別します。位置関係だけが必要であれば、各要素を共通座標上へ確定して書き出す方法が考えられます。親子構造そのものが必要な場合は、OBJだけに依存せず、構成表、命名規則、別形式の管理データなどを併用します。
点群の間引き処理も慎重に実施します。複数の計測範囲を結合してから一括で間引くと、区分ごとの点密度や境界が変わることがあります。工区や計測日ごとの区別を優先する場合は、区分単位で処理条件を記録し、分類を残した状態で書き出したほうが追跡しやすくなります。
複数のオブジェクトやグループが同一名称になっていないかも確認します。書き出し元では別レイヤーにあるため区別できていても、OBJへ保存される識別名が同じであれば、読み込み時に名称が衝突する可能性があります。出力前に一意の名称を付けます。
書き出し設定を変更した際は、元データを上書きせず、設定名や作成日を含めて別ファイルとして保存します。比較対象を残しておけば、どの設定で分類が維持され、どの設定で統合されたのかを検証できます。
本番データをいきなり出力するのではなく、三つ程度の明確な区分を持つ小規模な試験データを作ると効率的です。試験データには異なるo、g、ファイル名を設定し、点群の場合はpが出力されるかも確認します。この結果を基に本番の書き出し方を決めることで、大容量データの再処理を減らせます。
保持方法3：ファイル分割と命名規則で論理階層を残す
三つ目の保持方法は、OBJ内の分類記述だけに依存せず、管理単位ごとにファイルを分割することです。アップロード先がoやgを読み分けない場合でも、ファイル自体が分かれていれば、少なくとも登録単位として区別できる可能性が高まります。
たとえば工区、階、構造物、計測日、作業種別など、実務上まとめて表示、非表示、差し替え、確認したい単位ごとにOBJを分けます。一つの大きなOBJへすべてを格納するよりも、更新対象だけを再出力しやすくなります。
ただし、アップロード先が複数ファイルを一つのモデルへ自動統合する場合は、ファイル分割だけで個別選択を保証できません。ファイル単位が登録後も維持されるか、小規模な試験で確認します。
細かく分割しすぎると管理するファイル数が増え、アップロード漏れや選択ミスが起きやすくなります。分割単位は、アップロード後に独立して操作したい範囲を基準に決めます。計測点一つずつのような細分化ではなく、業務上の確認単位と更新単位を一致させることが重要です。
ファイル名には、上位区分から下位区分へ順番に情報を入れます。たとえば現場識別、工区、分類、計測日、版番号の順に統一します。すべての情報を長く詰め込むのではなく、担当者が見て区分を判断でき、同じ規則で検索できる長さに整えます。
日付の表記は、年、月、日の順で桁数をそろえると並びを確認しやすくなります。版番号についても「修正版」「最終版」だけに頼らず、更新順序を判断できる番号を付けます。「最終」「最終2」のような曖昧な名前は避け、旧版と新版の対応を管理表へ残します。
ファイル名とOBJ内のoやgの名称は、できるだけ対応させます。ファイル名では「A区_地表」、OBJ内では「測定1」のように異なる名称を使うと、アップロード後の確認に時間がかかります。共通の識別子を含めておけば、表示一覧、OBJ内部、管理台帳を照合しやすくなります。
親子階層を表現したい場合は、名称に上位区分を繰り返して持たせる方法が有効です。アップロード後に一覧が平坦化されても、名称を見ればどの上位区分へ属するかを判断できます。これはOBJへ本来の親子階層を保存する方法ではなく、平坦化された分類から論理構成を再現するための手掛かりです。
複数ファイルを同じ位置へ配置する場合は、座標の基準と原点の扱いをそろえます。ファイルを分割した結果、各ファイルが個別のローカル原点へ移動して出力されると、アップロード後に相対位置がずれる可能性があります。分割前と同じ共通座標を保持できているか、基準点の座標で照合します。
OBJには座標値の単位を一意に伝える標準的な単位フィールドがありません。メートル、ミリメートルなどの解釈は書き出し元と読み込み先の設定や運用に依存します。ファイル名や構成表に単位を記録し、アップロード先の読み込み単位をそろえます。
ファイル分割はデータ更新にも有効です。たとえば地表面だけを再計測した場合、構造物や基準点を含む全体を作り直すのではなく、対象区分のOBJだけを更新できます。ただし、旧版と新版を同時に登録すると重複表示になるため、差し替え、非表示、削除、保管のルールを決めます。
分割したファイルの一覧は、別途管理表やテキスト形式の構成情報として残します。各ファイルの名称、分類、作成日、座標基準、想定単位、点数または面数、更新履歴などを記録しておけば、アップロード後に分類が平坦化されても元の構成を確認できます。
保持方法4：関連ファイルと相対パスを崩さずにまとめる
四つ目の保持方法は、OBJと関連ファイルの参照関係を維持した状態でアップロードすることです。ただし、MTLやテクスチャは親子階層を保存するファイルではありません。主な役割は面や曲面の外観を定義することであり、ここで守るのは階層そのものではなく、分類の補助として利用している色や材質の手掛かりです。
OBJではmtllibによってMTLファイルを参照し、usemtlによって材質名を切り替えます。MTLから画像ファイルを参照する場合もあります。関連ファイルが不足すると、形状は表示できても色や材質による区別が失われる可能性があります。
OBJ内に記載されたMTLファイル名と実際のファイル名が一致しているかを確認します。大文字と小文字、空白、記号、拡張子の違いを区別する環境もあります。ファイル名を変更した場合は、OBJやMTL内の参照先も対応させます。
フォルダーを使用する場合は、参照元から参照先までの関係を変えないようにします。作成時にはOBJとMTLが同じフォルダーにあったのに、アップロード準備で別の場所へ移動すると、読み込み先が参照を解決できない場合があります。画像ファイルだけを別フォルダーへ整理した場合も同様です。
相対パスの解釈は読み込み先によって異なることがあります。絶対パスが書き込まれている場合、作業端末では読めてもアップロード先では同じ保存場所が存在しないため、参照できません。アップロード用フォルダーだけで完結する構成へ整理し、別の場所へコピーしても表示できるかを確認します。
圧縮してまとめる場合は、アップロード先が指定する梱包方法に従います。OBJ、MTL、画像を同じ階層へ置く必要があるのか、サブフォルダーを利用できるのか、圧縮ファイル内に複数のOBJを入れられるのかは、対象システムの仕様によります。一般的なOBJの仕様だけからZIP構成を決めることはできません。
一つの圧縮ファイルに複数の独立したOBJを入れる場合は、同名のMTLや画像ファイルが衝突しないようにします。別々のOBJが同じ名称のMTLを参照していると、展開や取り込みの方法によっては意図しないファイルが参照される可能性があります。
同じ名称を使用する必要がある場合は、OBJごとにフォルダーを分けて参照関係を維持するか、ファイル名に区分識別子を追加します。ただし、サブフォルダーを利用できるかは事前に確認します。対応していない場合は、一つの階層へまとめたうえで名称を一意にする必要があります。
アップロード前には、作業用端末の元フォルダーとは別の確認用フォルダーへ関連ファイル一式をコピーし、そのコピーだけから読み込めるかを確認すると効果的です。元の保存場所にあるファイルを暗黙的に参照している場合、作業環境では正常でもアップロード先では表示できません。
材質や色は分類の補助手段として有効ですが、それだけを階層保持の手段にしないことが重要です。材質が読み込まれない場合でも区分を追跡できるように、オブジェクト名、グループ名、ファイル名、構成表を組み合わせます。
点群OBJでは、MTLよりも頂点色の独自拡張を使う場合があります。色値がvの座標に続いて記録されていても、すべての読み込み先が同じ解釈をするとは限りません。色が業務上の分類に必要な場合は、対応状況を試験し、色以外の識別方法も残します。
保持方法5：アップロード後の再構成ルールを用意する
五つ目の保持方法は、アップロード先で元の階層が完全には引き継がれないことを前提に、再構成できるルールを準備することです。OBJは複雑な親子関係を保存するためのシーングラフ形式ではないため、書き出し設定だけで元の編集環境を完全再現しようとすると限界があります。
再構成ルールでは、どの名称を上位分類として扱うか、どのファイルを同じ管理単位へまとめるか、どの順番で表示するかを決めます。名称の先頭に工区番号、中央にデータ種別、末尾に版番号を付けている場合は、それぞれの部分を分類条件として利用できます。
アップロード先にフォルダー作成、タグ付け、属性登録、グループ化などの機能がある場合は、OBJ内の名称やファイル名を見ながら再分類します。これらの機能がない場合でも、ファイル名や登録順序を統一すれば、一覧上で関連データを近くに配置しやすくなります。
手動で再構成する場合は、担当者ごとに判断が変わらないようにします。「似た名前をまとめる」といった曖昧な方法ではなく、識別子のどの部分を上位区分として扱うか、旧版をどの状態へ移すかなど、再現可能なルールを定めます。
アップロード対象が多い場合は、OBJとは別に構成情報を用意します。構成情報には、ファイル名、o名、g名、上位分類、下位分類、計測日、版番号、座標基準、想定単位などを記録します。アップロード先が直接読み込めない形式であっても、確認表として利用できます。
再構成後は、元の管理単位数と一致しているかを確認します。元データに十個の区分があったのに、アップロード先では九個しか確認できない場合、統合、欠落、名称衝突、登録漏れのいずれかが発生している可能性があります。見た目だけで判断せず、区分数、ファイル数、点数などを数値で照合します。
位置関係についても確認します。分類が残っていても、一部のファイルだけ原点や単位が異なっていれば、別の場所や異なる縮尺で表示されます。各区分の代表点や基準点を使い、座標が一致しているかを確認します。
再構成ルールは一度決めて終わりではありません。書き出し元やアップロード先の更新、変換設定の変更によって、同じOBJでも読み込み結果が変わる可能性があります。運用開始後も、大容量データや新しい書き出し条件を使う前に小規模な試験を行います。
元データ、アップロード用データ、アップロード後の登録データを区別して保存することも重要です。アップロード用に名称変更や分割を行った場合、どの元データから作成したのか分からなくならないように対応関係を残します。問題が発生した際に元の分類まで戻れる状態を維持することが、確実な再構成につながります。
自動化できる環境では、ファイル名の識別子を使って登録先を振り分ける方法も考えられます。ただし、アップロード先が公開している機能や仕様を確認せず、名称だけで自動処理できると断定しないことが重要です。まず手動で再現できるルールを整え、その後に対象システムの機能へ合わせて自動化を検討します。
点群特有の注意点
点群OBJでは、一般的な面モデルとは異なる注意点があります。点群は多数の座標を中心に構成され、面や材質を持たない場合があります。標準的なOBJで点を表す場合は、vで座標を定義し、pで点要素として参照します。vだけが存在するファイルを点群として表示するかどうかは読み込み先の実装に依存します。
点要素のpを複数のoやgへ分けていても、アップロード先が点を一つの配列へまとめ、分類情報を保持しない場合は、グループ境界が見えなくなる可能性があります。反対に、点要素へ対応していない読み込み先では、点群そのものが表示されないことがあります。
点の色や属性にも注意します。元のOBJ仕様には一般的な点群形式のような豊富な点属性を格納する仕組みがありません。頂点座標にRGB値を続ける記法などが利用されることはありますが、拡張的な扱いであり、すべての書き出し元と読み込み先で互換性が保証されるわけではありません。
点群の分類を確実に残したい場合は、一つのファイル内で多数のグループに分けるだけでなく、管理単位ごとのファイル分割も検討します。特に計測日、工区、構造物、地表面など、独立して表示や更新を行いたい範囲は、ファイル単位で分けると追跡しやすくなります。
一方で、分割した点群は共通座標を維持する必要があります。個別ファイルごとに点群の中心を原点へ移動してしまうと、アップロード後に正しい位置で重ね合わせられません。書き出し時には、すべてのファイルが同じ座標基準と単位解釈を使用しているかを確認します。
座標値が大きい場合や原点から遠い位置にある場合は、表示側の内部計算や描画方式によって位置の揺らぎが見えることがあります。これは階層消失とは別の問題ですが、複数ファイルの位置が合わないことで分類構成が崩れたように見える場合があります。原点移動を行うときは、全ファイルへ同じ変換を適用し、変換量を記録します。
単位の不一致にも注意します。OBJの座標値だけでは、それがメートルかミリメートルかを読み込み先へ確実に伝えられません。あるファイルをメートル、別のファイルをミリメートルとして扱うと、大きさが大幅に異なります。書き出し時と読み込み時の単位設定をそろえ、構成表へ記録します。
点群の間引き率は、分類ごとに用途へ合わせて決めます。すべてを同じ率にすることが常に最適とは限りませんが、工区ごとに条件が異なる場合は、その理由と処理値を記録します。点密度の差によって境界が不自然に見えたとき、分類消失と間引き条件の違いを切り分けられるようにします。
点の重複除去を行う場合も、分類境界を確認します。同じ位置に異なる計測日の点が存在する場合、一方を削除すると時系列比較に必要な情報が失われます。重複に見える点が本当に不要なのか、別分類として保持すべき点なのかを判断してから処理します。
点群の分類は、見た目だけでは確認しにくいことがあります。表示切り替え、代表点の座標確認、区分ごとの点数照合などを組み合わせ、意図した範囲だけを個別に選択できるかを検証します。色分けが利用できる場合も、色だけでなく名称やファイル単位で照合します。
点群をOBJへ変換する前に、元形式が持つ分類や属性をどこまで維持できるかも確認します。変換元に点分類、時刻、反射強度などがあっても、OBJへそのまま移せるとは限りません。OBJアップロード後に必要な属性が多い場合は、OBJだけで運用できるかを事前に評価する必要があります。
事前検証と運用手順
点群OBJのアップロードで階層消失を防ぐには、本番作業の前に検証手順を決めておくことが重要です。最初に、保持したい分類を明確にします。元の編集環境に存在するすべての階層を残そうとするのではなく、アップロード後の業務に必要な単位を選びます。
次に、三つ程度の分類を持つ試験データを作成します。それぞれに一意のオブジェクト名、グループ名、ファイル名を設定します。点群の場合は、点要素のpが出力される構成、複数のgへ分けた構成、ファイルを分割した構成を比較すると、対応範囲を把握しやすくなります。
書き出したOBJを確認し、oやgなどの分類記述が存在するかを調べます。点群ではvだけでなくpがあるか、面モデルではfがあるかを確認します。分類の切り替わりが意図した点要素や面要素の範囲と一致しているか、名称が重複していないかも見ます。
材質を利用する場合は、mtllibとusemtlの対応を確認します。MTLに必要な材質名が定義され、画像参照がアップロード用フォルダー内で完結しているかを確認します。点群の色が独自の頂点色記法で保存されている場合は、その読み込み結果を別途確認します。
その後、OBJと関連ファイルだけを新しい確認用フォルダーへコピーし、そのフォルダーだけから読み込めるかを確認します。元の作業環境に依存せず表示できれば、アップロードに必要な参照ファイルがそろっている可能性が高まります。
試験アップロード後は、分類数、名称、位置、縮尺、色、表示切り替えの可否を確認します。分類名が残らない場合は、o、g、ファイル分割のどの方法が利用できるかを切り分けます。点が表示されない場合は、pへの対応、点数上限、変換条件などを確認します。
試験結果は設定記録として残します。書き出し時の結合条件、点の間引きや重複除去の有無、ファイル分割方法、名称規則、関連ファイルの構成、アップロード後の結果を記録しておけば、担当者が変わっても同じ手順を再現できます。
本番データでは、元データを保管したまま、アップロード専用の複製を作成します。複製側で名称整理、不要要素の削除、ファイル分割、軽量化を行います。元データへ直接変更を加えると、分類が失われた際に戻せなくなるため注意が必要です。
大容量のOBJは、一度にすべてアップロードせず、管理単位ごとに段階的に確認する方法が有効です。最初の一ファイルで名称、座標、単位、点の表示が正しいことを確認し、その後に残りを登録します。ただし、分割アップロードが利用できるかは対象システムの仕様を確認します。
アップロード完了後は、元データと登録結果を照合します。管理単位数が一致しているか、各区分が同じ位置にあるか、古い版が重複していないか、関連ファイルが欠落していないかを確認します。点群では区分ごとの点数も参考になりますが、アップロード時に間引きが行われる場合は完全一致しないことがあるため、変換条件と合わせて判断します。
更新時のルールも決めます。全体を再登録するのか、変更した区分だけを差し替えるのか、旧版を残すのかを明確にします。更新方法が統一されていないと、分類保持に成功していても新旧データが混在して管理しにくくなります。
最終的には、OBJ内の分類情報だけに依存しない運用が安全です。名称規則、ファイル分割、関連ファイルの管理、構成情報、アップロード後の照合を組み合わせることで、どこか一つの情報が失われても元の分類を追跡できます。
まとめ
点群OBJをアップロードした際に階層構造が失われる主な理由は、OBJが一般的な編集環境の親子ツリーを保存する形式ではないこと、書き出し時に分類が統合されること、アップロード先がoやgを読み分けないこと、点要素のpへ対応していないこと、内部変換で名称や分類が引き継がれないことなどです。
対策の第一歩は、保持したいものがオブジェクト名、グループ名、ファイル単位、材質による表示区分のどれなのかを明確にすることです。そのうえで、OBJ内のo、g、p、f、mtllib、usemtlを確認し、書き出し時の不要な統合を避けます。
一つのOBJ内で分類が維持されない場合は、管理単位ごとにファイルを分け、名称へ上位区分を含めます。OBJ、MTL、画像などの関連ファイルは参照関係を崩さずにまとめます。ただし、MTLやテクスチャは階層を保存するものではなく、色や材質による識別を補助するものとして扱います。
重要なのは、元の編集環境と同じ階層ツリーが表示されたかどうかだけで成功を判断しないことです。アップロード後に工区、計測日、構造物、地表面などの必要な単位を識別でき、個別に確認や更新ができる状態であれば、実務上必要な論理構成を維持できています。
点群OBJでは、vの頂点定義だけでなく、点要素を示すpの有無と読み込み先の対応状況を確認することが欠かせません。頂点色などの拡張記法も含め、書き出し元とアップロード先の組み合わせによって結果が変わるため、小規模な試験データで分類数、名称、座標、単位、点の表示、関連ファイルの読み込みを確認してから本番へ進みます。
現場で取得したデータを点群として整理し、その後のアップロードや共有まで一連の流れで扱う際は、取得時点から工区名、計測日、管理番号などを統一しておくことが重要です。LRTK Phoneを活用する場合も、計測後のファイル名、座標基準、分類方法をあらかじめ決めておくことで、点群OBJへ変換した後の整理や照合作業を進めやすくなります。