点群OBJアップロードで処理順が変わる理由
点群データをOBJ形式でアップロードすると、ファイルを選択した順番や送信を開始した順番と、処理が完了して画面に表示される順番が一致しないことがあります。最初に送ったファイルが処理中のまま残り、後から送ったファイルが先に表示されても、それだけでアップロード失敗やシステム異常と断定することはできません。
OBJは、三次元形状の頂点、点、線、面、法線、テクスチャ座標などを記述できるテキスト形式です。ただし、点要素だけで構成されたOBJ、面を持つOBJ、材質情報を伴うOBJなどへの対応範囲は、作成ソフトやアップロード先の実装によって異なります。そのため、拡張子が同じOBJであっても、同じ手順、同じ所要時間、同じ表示結果になるとは限りません。([Paul Bourke][1])
点群を点要素として書き出したデータと、点群から三角形などの面を生成したデータでは、内部構成が異なります。頂点数、点要素数、面数、法線、テクスチャ座標、材質、関連画像の有無もファイルごとに異なるため、読み込みや変換に必要な処理量は容量だけでは判断できません。
アップロード後に行われる作業も、単なるファイル転送だけとは限りません。利用するサービスによっては、受信後に形式確認、構文解析、頂点や面の整理、座標範囲の計算、表示用データへの変換、サムネイル生成などが実行されます。ただし、実際の処理内容と順序はサービスごとに異なるため、特定の工程が必ず行われるとは断定できません。
先にアップロードしたOBJが大きく、頂点や面が多い場合、その解析に時間がかかることがあります。その直後に容量が小さく構造も単純なOBJを送ると、後から送ったファイルが先に完了する場合があります。受付順が同じでも、処理負荷や割り当てられた処理環境が異なれば、完了順は変わり得ます。
ブラウザから複数ファイルを送る場合も、画面で選択した順に一件ずつ転送されるとは限りません。複数通信が並行して行われる仕組みでは、小さいファイルが先に送信を終えることがあります。一部の通信だけ速度が低下したり、再送が発生したりすれば、そのファイルだけ受付や処理開始が遅れる可能性もあります。
アップロード先が複数の処理を並行して進める方式であれば、受付順と完了順はさらに一致しにくくなります。また、一覧画面が受付日時ではなく、更新日時、完了日時、名称などで並べ替えられている場合、実際の処理順とは別の順番に見えることもあります。
したがって、点群OBJアップロードでは、順番が必ず維持されることを前提にしない運用が安全です。重要なのは、どのファイルがどの現場、取得日、区画、用途、版に対応するかを、表示位置に頼らず追跡できる状態にすることです。
処理順の変化によって起こりやすい実務上の問題
処理順が変わったときに起こりやすいのは、確認対象の取り違えです。担当者がアップロード順を記憶し、画面の上から同じ順番で並ぶと考えていると、完了順が入れ替わった際に別のデータを確認する可能性があります。
同じ現場で連続して取得した点群は、見た目が似ることがあります。道路の隣接区画、造成面、法面、構造物周辺などは、表示角度によって違いが分かりにくくなります。ファイル名が自動生成された文字列や単純な連番のままだと、サムネイルだけで対象を特定しなければなりません。
新旧データの混在も問題になります。最初に送った旧版の処理が遅れている間に修正版を追加すると、修正版が先に完了する場合があります。その後に旧版が表示されると、似た名称や似た形状のデータが複数並びます。版の識別ができなければ、古いデータを最新データとして共有するおそれがあります。
重複アップロードも起こりやすい問題です。処理中の表示が長く続くと、担当者が失敗したと判断し、同じファイルを再送することがあります。実際には最初の処理が続いており、後から両方が完了すると、同じ内容のデータが複数登録されます。
重複したデータの片方に確認結果やコメントが記録され、もう片方では別の担当者が作業を進めると、情報が分散します。どちらを正式版とするか分からなくなり、誤った版で計測や数量確認を進める原因になります。
関連ファイルの対応が崩れることもあります。標準的なOBJでは、OBJがMTLファイルを参照し、MTLファイルがテクスチャ画像を参照する構成が用いられます。参照されるMTLや画像の名称、配置、内容を変更したのに参照記述を更新しなければ、形状は表示されても材質や画像が正しく反映されない場合があります。OBJファイルそのものを改名しただけで必ず参照が切れるわけではなく、実際に参照されているファイル名との整合を確認する必要があります。([loc.gov][2])
複数人で作業する現場では、確認の重複と漏れが同時に発生することもあります。一人が処理の遅いファイルを待つ間に別の担当者が後から完了したファイルを確認すると、担当範囲が重なる可能性があります。その一方で、最後に完了したファイルが誰にも確認されず残ることがあります。
処理順の変化に対応するには、画面上の並び順を管理するのではなく、ファイルそのものを識別し、受付から確認完了までの状態を記録する必要があります。その基本となるのが、次に説明する四つの管理方法です。
管理方法1 ファイル名と管理番号を統一する
一つ目の管理方法は、アップロード順に依存しないファイル名と管理番号を付けることです。画面の上から何番目に表示されているかではなく、名称を見れば対象を判断できる状態にします。
ファイル名には、現場、取得日、測定範囲、データ用途、版番号などを一定の順序で含めます。担当者が自由に名称を付けると、同じ意味の情報が異なる位置に入ったり、略称がばらばらになったりします。案件開始時に命名規則を決め、関係者が同じ形式を使うことが重要です。
取得日は年を含む形式で統一すると管理しやすくなります。月日だけでは年度をまたいで保管したときに判断しにくくなります。数字の桁数をそろえれば、ファイル名による並べ替えでも時系列が崩れにくくなります。
測定範囲には、図面や施工計画で使用している正式な区画名を使います。「手前」「奥」「右側」といった表現は、見る方向や担当者によって意味が変わります。測点、工区、階、構造物名など、関係者が共通して理解できる名称を使用します。
データ用途も識別できるようにします。同じ範囲の点群でも、全体確認用、計測用、軽量表示用、加工前、不要点除去後など、目的が異なることがあります。用途が分からないまま共有すると、間引いた軽量データを精密な確認に使うなどの誤りにつながります。
版番号は新旧データを区別するために欠かせません。「最新版」「修正版」「最終版」だけでは、追加修正が発生したときに関係が分からなくなります。連続した版番号を付け、更新のたびに番号を進めます。
修正内容は別の管理記録にも残します。不要点を除去したのか、座標を変換したのか、対象範囲を追加したのかによってデータの意味は異なります。版番号と変更内容を組み合わせることで、旧版との差を確認できます。
ファイル名とは別に、アップロード処理ごとの管理番号を付ける方法も有効です。同じOBJを再処理した場合でも、管理番号が異なれば最初の処理と再処理を区別できます。アップロード先で受付番号が発行される場合は、その番号を作業記録へ転記します。
自動番号がない場合は、案件内で重複しない番号を事前に割り当てます。日付と連番を組み合わせるなど、誰でも継続して使える形式にします。番号の採番者や採番場所も決め、同じ番号が二重に使われないようにします。
関連ファイルを含むOBJでは、参照関係を保ったまま名称を管理します。OBJ内のMTL参照、MTL内の画像参照を確認し、参照対象の名称を変える場合は記述も合わせて更新します。変更後はアップロード前に一度データを開き、形状、材質、色、画像が想定どおり表示されるか確認します。
元データとアップロード用データも分けて保管します。取得直後の点群や最初に書き出したOBJを直接上書きすると、問題が起きた際に元の状態へ戻れません。元データは変更せず、加工したデータを別名で保存します。
ファイル名に情報を詰め込みすぎると読みにくくなります。現場、日付、範囲、用途、版など、ファイル単体で判断するために必要な要素を名称へ含め、担当者、処理状態、確認結果などは別の記録で管理する方法が実用的です。
ファイル名と管理番号が統一されていれば、処理完了順が変わっても対象を追跡できます。これは処理順の入れ替わりに対する基本的な対策です。
管理方法2 アップロード単位と投入順を管理する
二つ目の管理方法は、大量の点群OBJを一度に送らず、確認可能な単位に分けてアップロードすることです。処理対象が増えるほど完了順の入れ替わりが起こりやすく、未処理、処理中、完了済みの区別も難しくなります。
一度にアップロードするファイル数は、ファイル容量、内部構成、通信環境、過去の処理時間、確認担当者の作業量を考慮して決めます。少数のファイルごとに処理単位を作り、その単位の受付を確認してから次へ進むと、状況を把握しやすくなります。
分割の基準には、現場、取得日、工区、構造物、測定目的などを使えます。同じ日に取得したデータでも、道路部分、法面部分、構造物周辺など用途が異なる場合は、別の単位として処理したほうが確認しやすくなります。
ファイル容量だけを基準に分割する方法には注意が必要です。同じ容量でも、頂点数、点要素数、面数、法線、材質情報、関連画像の数などによって処理負荷は異なります。容量は目安の一つとし、内部構成や過去の実績も考慮します。
広い現場全体を一つのOBJにまとめると、送信、解析、表示のすべてに時間がかかる場合があります。全体を一体で扱う必要がなければ、業務上の確認範囲に合わせて分割することを検討します。
ただし、細かく分割しすぎると、ファイル数が増えてアップロード漏れや確認漏れが起きやすくなります。分割単位は、アップロード先で扱いやすい大きさだけでなく、現場で一つの対象として確認したい範囲にも合わせます。
同じ座標基準で書き出せば、分割したOBJ同士の位置関係を維持しやすくなります。分割の際に各ファイルを別々の原点へ移動すると、後から重ね合わせるための変換情報が必要になります。分割方法と座標の扱いは一体で決めます。
アップロード完了と処理完了を区別することも大切です。ブラウザ上で送信が終了していても、アップロード先では解析や表示変換が続いている場合があります。一覧に名称が表示された時点を業務上の完了とせず、処理状態と内容確認の結果を確認します。
最初の処理単位に処理中のデータが多数残った状態で次の単位を追加すると、待ち件数が増え、どのファイルが通常より遅いのか判断しにくくなります。次の単位を投入する条件を事前に決めます。
たとえば、現在の単位について全件の受付番号が記録されていることを確認してから次へ進む方法があります。より厳密に管理する場合は、前の単位がすべて処理完了した後に次のアップロードを始めます。
作業時間を短縮するために並行処理を行う場合でも、処理単位を明確に分けます。担当者ごとに工区を割り当て、管理番号の範囲も分けておけば、完了順が交差しても対象を判断できます。
再処理するファイルは、新規アップロードと同じ単位に混ぜないほうが管理しやすくなります。再処理は不具合原因を確認するための作業でもあるため、通常処理とは分け、変更内容と結果を記録します。
処理単位を小さくする目的は、単にアップロード時間を短くすることではありません。処理順が変化しても、どこまで受付済みで、どこまで確認済みなのかを明確にすることが目的です。
管理方法3 受付から確認完了までの状態を記録する
三つ目の管理方法は、点群OBJごとに処理状態を記録することです。アップロードしたかどうかだけではなく、未着手、送信中、受付済み、処理中、処理完了、内容確認済み、再処理待ち、使用停止などの段階を区別します。
処理順が変わる環境では、アップロード開始時刻だけを見ても現在の状況は分かりません。先に送ったファイルが処理中のまま残り、後から送ったファイルが確認済みになることもあります。各ファイルの状態を個別に追跡する必要があります。
記録する情報には、管理番号、ファイル名、現場名、測定範囲、版番号、アップロード開始時刻、受付結果、現在の状態、処理完了時刻、確認担当者、確認結果などがあります。再処理を行った場合は、再処理理由と変更条件も残します。
状態の名称は関係者間で統一します。「済み」だけでは、送信が済んだのか、処理が済んだのか、内容確認まで済んだのか判断できません。「受付済み」「処理完了」「内容確認済み」のように段階を明確にします。
処理完了と内容確認完了は分けます。OBJが画面に表示されたとしても、データ全体が正しく読み込まれているとは限りません。対象範囲、座標位置、向き、単位、材質、欠損、不要点などを確認した後に内容確認済みへ変更します。
処理中の表示が長く続いた場合も、担当者の判断だけで再送信しないようにします。再処理を始める条件がなければ、同じファイルが重複して登録されます。まず受付番号、送信完了の有無、エラー表示、ファイル容量、類似データの実績などを確認します。
すべてのOBJに同じ待ち時間を適用するのが適切とは限りません。大容量のデータ、面数の多いデータ、関連ファイルの多いデータは処理時間が長くなる可能性があります。過去の所要時間を記録しておけば、通常範囲か異常の疑いがあるかを判断しやすくなります。
処理時間の記録は運用改善にも使えます。特定の書き出し条件だけ時間がかかる、関連画像が多い場合に遅くなる、一定以上の規模で再処理が増えるといった傾向を把握できます。ただし、原因を断定する前に、通信状況やサービス側の混雑など他の要因も確認します。
複数人で作業する場合、状態記録は共有できる場所で管理します。個人の手元にしか記録がないと、別の担当者が同じファイルを再度アップロードする可能性があります。更新者と更新時刻も残し、誰が見ても現在の状態を確認できるようにします。
確認担当者も事前に割り当てます。処理が完了した順に空いている人が確認するだけの運用では、担当の重複や漏れが発生しやすくなります。ファイルまたは処理単位ごとに担当者を決めておけば、完了順が変わっても引き取り先が明確です。
作業終了時には、アップロードしたすべての管理番号を照合します。画面に表示されているファイルだけを数えるのではなく、受付記録にある全件について、処理完了、確認済み、再処理予定、使用停止などの状態が付いていることを確認します。
状態記録は障害発生時の説明にも役立ちます。いつ送信し、いつ受付され、どの段階で止まり、どの条件で再処理したかが分かれば、元データ、通信、アップロード先の処理を切り分けやすくなります。
管理方法4 完了後の照合と再処理ルールを決める
四つ目の管理方法は、処理完了後の確認手順と、不具合が発生した場合の再処理ルールを統一することです。完了順が変わっても、一件ずつ同じ手順で照合すれば、取り違えや確認漏れを防ぎやすくなります。
最初に確認するのは、処理されたデータと管理記録が一致しているかです。ファイル名、管理番号、現場名、取得日、測定範囲、版番号を照合します。サムネイルの見た目や表示位置だけで判断しないことが重要です。
次に、対象範囲がすべて読み込まれているかを確認します。一部の点や面が欠けていないか、意図しない範囲が含まれていないか、極端に離れた位置へ不要点が残っていないかを見ます。
遠く離れた不要点が含まれていると、表示画面がデータ全体へ合わせられ、確認したい部分が小さく見える場合があります。この症状を直ちに単位不良や縮尺不良と断定せず、まずデータ全体の座標範囲を確認します。
座標位置も重要です。複数時期の点群や設計データと重ねる場合は、共通の座標基準が維持されている必要があります。原点を移動したデータと現場座標を保持したデータが混在すると、そのままでは正しい位置に重ならないことがあります。
単位にも注意します。OBJの座標値自体には、一般にメートルやミリメートルといった単位を強制する共通の仕組みがないため、書き出し側と読み込み側の想定が異なると、形状が極端に大きくまたは小さく見えることがあります。案件で使用する単位を決め、書き出し条件と読み込み条件をそろえます。
面を含むOBJでは、面の向きや法線、面の欠損が表示結果に影響することがあります。見る方向によって一部が消える、表面が不自然に暗くなる場合は、アップロード先の表示設定だけでなく、面の生成状態や法線も確認します。
材質や画像を使う場合は、OBJが参照するMTLと、MTLが参照する画像がそろっているかを確認します。形状だけを利用する業務では材質が必須でない場合もありますが、色や画像を判断材料にする用途では、欠落が確認精度に影響します。
不具合が見つかった場合、同じOBJを直ちに再送するのではなく、原因候補を整理します。元ファイルが不完全なのか、点だけのOBJにアップロード先が対応しているか、関連ファイルが不足しているか、通信に問題があったか、座標や単位が異なるかを切り分けます。
再処理では、一度に複数の条件を変更しないことが大切です。名称、書き出し条件、座標、分割範囲、点密度を同時に変えると、何が結果に影響したか分かりにくくなります。変更内容を一つずつ記録し、結果を比較します。
再処理したデータには新しい版番号を付けます。旧版と同じ名称のまま登録すると、処理結果を区別できません。管理記録には、旧版の管理番号、再処理理由、変更点、新しい管理番号を残します。
旧版を削除する時期も決めます。新しい版が正常に表示される前に旧版を削除すると、比較や原因調査ができません。一方で旧版を一覧に残したままにすると、誤使用の可能性があります。
新しい版の内容確認が完了した後に、旧版を使用停止として区別します。必要に応じて保管場所を分け、通常の共有画面には正式版だけを残す方法もあります。削除の可否や保管期間は、案件の記録ルールに合わせます。
最終的に使用するデータには、処理完了だけでなく内容確認済みであることが分かる状態を付けます。アップロードに成功したデータと、業務で使用できることを確認したデータを明確に区別します。
点群OBJアップロード前に確認するデータ条件
四つの管理方法を安定して運用するには、アップロード前のデータ条件もそろえる必要があります。名称と状態が正しく管理されていても、担当者ごとに異なる条件でOBJを書き出すと、処理時間や表示結果の差が大きくなります。
最初に確認するのは書き出す対象範囲です。点群取得時には、目的範囲以外の地面、空間、車両、人、樹木、資材、仮設物などが含まれることがあります。不要な範囲をすべて残すと、ファイル容量や要素数が増え、送信や表示に時間がかかる可能性があります。
ただし、不要点を削除しすぎると、位置確認や比較に必要な周辺形状まで失われます。施工対象だけでなく、基準となる構造物や地物を必要に応じて残します。削除範囲はOBJを何に利用するかを考えて決めます。
座標基準も統一します。現場座標を維持するのか、ローカル原点へ移動するのかを案件ごとに決めます。複数の点群を重ねる場合や設計データと比較する場合は、同じ基準または再現可能な変換条件で書き出す必要があります。
処理上の理由から座標を移動する場合は、移動量、回転、変換方法を記録します。担当者が個別に原点を変更すると、後から元の位置へ戻せなくなる可能性があります。
点群密度も確認します。必要以上に高密度な点群をOBJへ変換すると、ファイル容量や要素数が増え、処理時間が長くなる場合があります。概略確認、形状確認、寸法確認、数量算出など、用途と必要精度に応じて密度を判断します。
間引きを行った場合は元データを残し、間引き条件を記録します。軽量表示用データと計測用データを混同しないよう、ファイル名にも用途を含めます。間引いたデータが特定の計測に適するかは、必要精度と処理方法に基づいて判断します。
点群から面を生成する場合は、穴埋めや平滑化の条件にも注意が必要です。見た目が滑らかでも、実際に取得できていない部分が補間されている可能性があります。現況判断や計測に使う場合は、補間範囲と生成条件を把握します。
関連画像や材質情報を使う場合は、OBJ、MTL、画像がすべてそろい、参照名が一致しているかを確認します。OBJだけを別のフォルダーへ移動した結果、MTLや画像へ到達できなくなることがあります。アップロード先が関連ファイルをどの方法で受け付けるかも事前に確認します。
点だけで構成されたOBJについては、アップロード先が点要素または頂点のみのデータを受け付けるか確認します。OBJ対応と表示されていても、面を持つメッシュだけを対象としている実装があります。少量の試験データで、受付、表示、座標、属性の扱いを確認してから本番データを投入すると安全です。
ファイル自体が正常に開けることも事前に確認します。書き出しが途中で止まった場合や、保存先の空き容量が不足した場合、拡張子はOBJでも内容が不完全な可能性があります。
アップロード前に一度データを開き、対象範囲、座標位置、向き、単位、材質、欠損の有無を確認します。これにより、アップロード後に問題が起きた際、元ファイルの問題と送信後の処理問題を切り分けやすくなります。
複数人で点群OBJを扱う場合の管理方法
複数人でアップロードや確認を行う場合は、個人作業より明確な役割分担が必要です。同じ現場のデータを複数担当者が扱うと、処理順の変化だけでなく、重複送信や確認漏れも発生しやすくなります。
まず、アップロード担当者と確認担当者を明確にします。一人が送信し、別の担当者が確認する場合は、どの時点で作業を引き渡すかを決めます。受付番号が発行され、共有記録への登録が完了した時点を引き渡し基準とすると分かりやすくなります。
同じデータを複数人が同時にアップロードしないよう、担当範囲を分けます。工区、取得日、構造物、データ用途などで分担し、担当する管理番号の範囲も決めます。
作業開始時には、共有記録へ担当中であることを記載します。これにより、ほかの担当者が同じファイルを処理することを防ぎやすくなります。中断する場合も状態を戻すか、引き継ぎ先を記録します。
再処理の判断を行う担当者も決めます。処理が遅いことに気づいた人がそれぞれ再送信すると、重複データが増えます。最初のアップロード担当者または管理責任者が、記録を確認したうえで再処理を判断する運用が安全です。
確認結果は口頭連絡だけで終わらせず、管理記録へ残します。どのファイルを確認したのか、問題がなかったのか、再処理が必要なのかを明確にします。
「表示がおかしい」といった曖昧な記録では、次の担当者が状況を再現できません。全体が表示されない、一部が欠ける、材質だけが反映されない、位置がずれる、操作が重い、処理中から変わらないなど、症状を具体的に記録します。
正式版を決定する権限も明確にします。各担当者が個別に最新版を判断すると、複数の正式版が生まれる可能性があります。確認担当者が内容を確認し、管理責任者が正式版として確定するなど、段階を分けます。
作業終了時には、処理中のデータが残っていないか確認します。翌日へ持ち越す場合は、管理番号、現在の状態、最後に確認した時刻、次回の確認担当者を記録します。これにより、処理の遅れていたデータが放置されることを防ぎます。
処理順が変わった場合のトラブル別対応
アップロード順と完了順が変わっただけで、すべてのOBJが正常に処理されている場合は、順番を元に戻すこと自体を目的にする必要はありません。管理番号とファイル名を照合し、処理結果を一件ずつ確認します。
一つのファイルだけ処理中のまま残っている場合は、すぐに再送信せず、ほかのファイルとの違いを確認します。容量が大きい、要素数が多い、面や関連画像が多いなどの条件があれば、処理に時間がかかっている可能性があります。ただし、これらだけで原因を断定せず、エラー表示やサービス側の案内も確認します。
明確な処理失敗が表示された場合は、最初に元ファイルが正常に開けるか確認します。次に、点だけのOBJへの対応、関連ファイルの不足、参照名、書き出し条件、座標範囲、ファイルの破損などを確認します。
形状は表示されるものの材質や画像が反映されない場合は、OBJが参照するMTL名、MTLが参照する画像名、ファイルの配置、アップロード方法を調べます。名称変更やフォルダー移動によって参照先が見つからなくなっている可能性があります。
データが極端に小さく表示される場合は、遠く離れた位置に不要点がないかを確認します。表示範囲が不要点まで含めて調整されると、確認したい形状が小さく見えます。
形状そのものが極端に大きい、または小さい場合は、書き出し側と読み込み側の単位解釈を確認します。単位だけでなく、座標変換時の倍率が誤っていないかも確認します。
複数のOBJが正しい位置に重ならない場合は、座標基準、原点移動、回転、倍率の有無を確認します。各ファイルを画面上で手作業により合わせる前に、共通座標または記録済みの変換条件で再現できるかを確認します。
同じ名称のファイルが複数表示された場合は、管理番号、版番号、アップロード時刻で区別します。内容を確認せずに削除すると、正式版や必要な比較データを消すおそれがあります。
重複送信と判断できた場合も、確認結果やコメントがどちらかに記録されていないかを調べます。必要な情報を正式版へ集約し、使用停止の表示や削除を行う順序を決めます。
処理順の変化によるトラブルでは、画面上の順番を直すことより、データの内容、状態、版、参照関係を正しく識別することが優先されます。
点群取得から共有までを効率化する考え方
点群OBJアップロードの処理順を管理するには、アップロード時だけ対策するのではなく、点群を取得する段階から情報を整理することが重要です。
取得時の現場名、日時、区画、測定目的、座標基準が曖昧であれば、後から適切なファイル名を付けることも難しくなります。似た範囲を連続して取得した場合、事務所へ戻ってから形状だけを見て判別できないことがあります。
現場で点群を取得した直後に、対象範囲と取得目的を記録します。工区名や構造物名を図面と対応させ、必要に応じて再取得の有無も残します。
点群取得、不要点整理、座標確認、OBJ書き出し、名称設定、事前確認、アップロード、処理確認という流れを標準化すれば、担当者が変わっても同じ基準で作業しやすくなります。
各工程には完了条件を設けます。点群取得の完了はデータが保存された時点ではなく、必要範囲が取得できていることを確認した時点とします。OBJ書き出しの完了はファイルが生成された時点ではなく、正常に開け、必要な要素が含まれていることを確認した時点とします。
アップロードの完了も、ファイル送信が終わった時点とは分けて考えます。処理が完了し、管理記録との照合と内容確認が終わった時点を業務上の完了とします。
このように工程ごとの完了条件を明確にすると、処理順が変わった場合でも、どの段階に問題があるか判断しやすくなります。
現場で取得した点群を早い段階で確認できれば、欠損や取得範囲の誤りにも気づきやすくなります。再取得が必要な場合、現場作業の終了前に判断できれば、移動や再手配の負担を抑えやすくなります。
LRTK Phoneを活用する場合も、取得したデータに現場名、測定範囲、座標基準、用途、版などの管理情報を対応させ、アップロード後まで一貫して追跡できる運用が重要です。機器や仕組みを導入するだけでなく、名称、版、状態、確認手順をそろえることで、点群データを実務で扱いやすくなります。
まとめ
点群OBJアップロードでは、送信した順番と処理が完了する順番が一致しないことがあります。ファイル容量、頂点や面などの要素数、関連情報、通信状況、アップロード先の処理方式が異なるため、後から送信したデータが先に完了しても、それだけで異常とは断定できません。
一つ目の管理方法は、現場名、取得日、範囲、用途、版を含むファイル名と管理番号を統一することです。画面の並び順ではなく、名称と番号によって対象を識別します。
二つ目は、アップロード対象を確認可能な単位へ分け、投入順を管理することです。大量のOBJを一度に送らず、工区や用途ごとに区切ることで、処理状態を把握しやすくなります。
三つ目は、受付済み、処理中、処理完了、内容確認済みなどの状態を記録することです。アップロードしたという事実だけでなく、現在どの段階にあるかを共有します。
四つ目は、完了後の照合項目と再処理ルールを決めることです。対象範囲、座標、単位、欠損、面、材質、参照ファイルなどを確認し、不具合があれば変更内容を記録したうえで別の版として再処理します。
この四つを組み合わせれば、処理完了順が入れ替わっても、ファイルの取り違え、確認漏れ、重複送信、旧版の誤使用を防ぎやすくなります。
さらに安定した運用を目指すには、点群を取得する時点から現場名、区画、用途、座標基準を整理し、書き出し、アップロード、確認まで同じ情報を引き継ぐことが大切です。現場での点群取得からデータ共有までを一連の作業として効率化する際には、LRTK Phoneを活用した運用も選択肢になります。