点群OBJを安全にアップロードする必要性
建設現場で取得した点群データは、掘削前後の地形比較、盛土の進捗確認、残土量の概算、出来形の記録などに利用できます。点群をOBJ形式で保存してクラウドへ送信すれば、現場事務所へ戻る前に関係者と三次元情報を共有し、現場で即土量を確認するための処理へつなげることも可能です。
一方、点群OBJは写真や帳票より容量が大きくなりやすく、計測範囲や点密度によっては送信に時間がかかります。通信が不安定な場所では、途中切断、再送、重複登録、未完了データの残存などが起こり得ます。アップロードボタンを用意するだけでは、安定した運用にはなりません。
点群OBJには、地形、構造物、施工範囲、計測位置など、現場に関係する情報が含まれることがあります。保存先や権限の設定を誤ると、別現場への登録、意図しない上書き、権限のない利用者による取得などにつながる可能性があります。
大容量ファイルを業務システムのアプリケーションサーバーで受け取り、その後に保存領域へ転送する構成では、サーバーの通信帯域、メモリー、処理時間を消費します。複数現場から同時に送信されると、ログイン、現場情報の閲覧、解析結果の表示など、別の処理へ影響する場合があります。
そこで利用できるのが、利用者の端末からオブジェクトストレージなどの保存領域へ直接送る方式です。業務システムは認証、権限確認、保存先の決定、アップロード状態の管理を担当し、実際の大容量データは署名付きURLなどを使って保存領域へ送ります。
ただし、直接アップロードにすれば自動的に安全になるわけではありません。署名付きURLを発行する前の権限確認、保存先の一意化、上書き防止、有効期限の設計、アップロード後の検証、未完了データの整理までを一つの流れとして設計する必要があります。
また、署名付きURLは有効期限内であれば同じ操作に複数回使える実装があります。一回発行したURLが必ず一回だけ使えるとは限りません。利用可能回数を制御したい場合は、URLだけに頼らず、業務システム側の申請状態、保存先の条件付き作成、オブジェクトの版管理などを組み合わせます。
現場で即土量を確認する業務では、速さだけでなく、どの計測データを使ったのかが追跡できることも重要です。別の計測回、異なる座標基準、未検証のOBJを使えば、送信自体が成功していても判断を誤る可能性があります。安全なアップロードは、正しい数量を確認するための入口として設計します。
署名付きURLの基本的な仕組み
署名付きURLとは、特定の保存先に対する特定の操作を、限られた時間だけ許可するためのURLです。具体的な名称、署名方式、固定できる条件、有効期限の判定方法は、採用する保存サービスやAPIによって異なります。
一般的な流れでは、利用者が業務システムへログインし、点群OBJのアップロードを申請します。業務システムは、利用者が対象現場へデータを登録できるかを確認し、問題がなければ今回の申請専用の保存先を決めます。その後、書き込み操作に必要な条件を付けた署名付きURLを端末へ返します。
端末は、そのURLを使って保存領域へ直接リクエストを送ります。この方式では、保存領域全体へアクセスできる長期認証情報を端末へ渡さずに済みます。ただし、署名付きURL自体は、知っている人が有効期間内に利用できる一時的な認証情報として扱う必要があります。
許可する操作は、可能な範囲で新規アップロードに限定します。読み取り、削除、一覧取得、別の保存先への書き込みまで許可する必要はありません。保存先も、現場全体の広い階層ではなく、今回の申請で決めた一つのオブジェクトキーへ限定します。
アップロードの完了通知は、端末から業務システムへ送る方法と、保存領域側のイベント通知を利用する方法があります。ただし、どちらの通知も、そのまま正式登録の根拠にはしません。通知を受けた業務システムが、対象保存先の存在、容量、チェックサム、申請状態を確認してから検証処理を開始します。
完了通知は重複して届く可能性があります。端末の再試行と保存領域側の通知が重なっても、同じアップロード識別子に対して検証処理が二重に動かないよう、処理を冪等にします。
保存領域にファイルが存在する状態と、業務で利用できる状態は分けます。アップロード済み、検証中、検証合格、確認待ち、検証失敗、無効、旧版などの状態を持たせ、検証前のデータが自動的に正式版へ切り替わらないようにします。
署名付きURLは、大容量ファイルを直接送るための手段であると同時に、権限を一時的かつ限定的に委譲する手段です。URLの発行だけを切り離さず、申請、送信、検証、利用開始、期限切れデータの整理までを一連の処理として管理します。
アップロード前に整理する点群OBJの構成
OBJは、頂点、面、法線、テクスチャ座標などの三次元形状情報をテキストで表現できる形式です。点群として頂点を中心に出力する場合もあれば、点群から生成した三角形の面を含む場合もあります。同じ拡張子であっても、内容や対応範囲は出力元によって異なります。
重要なのは、一般的なOBJの標準情報だけでは、測量で必要になる単位、測地座標系、高さの基準、上方向などが一意に定まらないことです。座標値が記録されていても、それがメートルか別の単位か、どの座標参照系か、標高か別の高さかをOBJだけから確実に判断できない場合があります。
そのため、土量計算へ使うOBJには、現場識別子、計測日時、計測範囲、座標参照系、単位、高さの基準、出力設定、原データの識別子などを別の管理情報として関連付けます。コメント行や独自拡張へ書き込むだけでは、別のソフトで失われる可能性があるため、業務システム側でも保持します。
OBJが材質情報を参照する場合は、MTLファイルや画像ファイルが必要になることがあります。OBJ本体だけを送ると、形状は読み込めても色や外観を再現できない場合があります。一方、土量計算が主目的であれば、材質や画像を必須にせず、計算用データと閲覧用データを分ける方法もあります。
複数ファイルを成果一式として扱う場合は、共通の計測識別子を付けます。ファイル名の一致だけで関連付けると、名称変更や重複によって取り違えが起こるため、システムが発行した識別子を利用します。
関連ファイルを圧縮して一つにまとめる場合は、圧縮後の容量だけでなく、展開後の総容量、ファイル数、階層の深さ、ファイル名の長さ、相対パスを検証します。上位階層を指すパス、絶対パス、想定外の拡張子、過大な展開容量を許可しないようにします。
OBJやMTLに記載された外部参照も無条件には処理しません。許可した成果一式の内部にある相対参照だけを受け付け、外部URL、端末内の絶対パス、保存領域外へ抜ける参照は無効として扱います。
軽量化を行う場合は、容量だけを基準にしません。点を減らしすぎると、法肩、法尻、掘削底、段差、小さな起伏など、数量に影響する形状が失われる可能性があります。対象地形、計測目的、必要な確認精度に合わせ、軽量化前後で表示と計算結果を比較します。
元データと加工後データは区別して保管します。点の間引き、外れ値除去、座標変換、不要範囲の削除、面生成などを行った場合は、処理内容、使用した設定、実行日時、元データの識別子を記録します。
手順1 利用者とアップロード対象を確認する
最初の手順は、署名付きURLを発行する前に、利用者の権限とアップロード対象を確認することです。ログイン済みという理由だけで、すべての現場へ点群OBJを登録できる状態にはしません。
業務システムは、利用者が対象現場に参加しているか、点群データの登録権限を持っているか、アカウントが有効かを確認します。現場から外れた担当者や、権限変更後の担当者へ新しいURLを発行しないよう、URL発行時点で判定します。
申請情報には、元のファイル名、申告容量、許可する拡張子、データ種別、現場識別子、工区、計測日時、計測段階、単位、座標参照系、高さの基準などを含めます。土量計算へ使う場合は、掘削前、施工途中、完了後などの区分も登録します。
元のファイル名は表示用として保存できますが、そのまま保存先のキーには使いません。同名ファイル、長すぎる名称、制御文字、区切り文字、見分けにくい文字が含まれる可能性があるためです。保存先にはシステムが発行した一意の識別子を使います。
一意の保存先を使っても、同じURLによる再送や同時送信を考慮する必要があります。新規作成だけを許可できる条件付き書き込み、保存領域の版管理、申請状態の確認などを利用し、意図しない上書きを防ぎます。
申請時には、ファイル容量の下限と上限を確認します。容量がゼロのファイル、運用上限を超えるファイル、許可していない関連ファイルにはURLを発行しません。ただし、端末が申告した容量や種類は信頼せず、アップロード後に実体と照合します。
拡張子や送信時のコンテンツ形式だけで安全と判断しないことも重要です。OBJとして許可する記述、頂点数、面数、行長、数値範囲、関連ファイル数など、後段の検証条件をあらかじめ決めます。
端末側で送信前チェックサムを算出する場合は、対象ファイルを確定してから申請します。申請後に再出力、軽量化、座標変換などを行った場合は、容量とチェックサムが変わるため、新しい申請として扱います。
一つの申請には、一つの成果または明確に定義した一式を割り当てます。再送が必要な場合は、古い申請を無効または再送待ちへ変更し、どの試行が正式候補なのかが分かるようにします。
手順2 保存先と有効期限を限定した署名付きURLを発行する
利用者と対象を確認したら、今回の保存先に必要な操作だけを許可する署名付きURLを発行します。署名を作る主体には、必要最小限の権限だけを与え、広い保存領域へ自由に書き込める権限を持たせないようにします。
新規登録であれば、読み取り、削除、一覧取得は原則として不要です。保存サービスが新規作成と上書きを別の権限や条件で制御できる場合は、新規作成だけを許可します。上書きが必要な業務では、既存データを直接置き換えるのではなく、新しい版として保存する方が履歴を残しやすくなります。
署名付きURLは、保存先とHTTPメソッドだけでなく、必要に応じてコンテンツ形式、チェックサム関連ヘッダー、暗号化関連ヘッダーなども署名条件へ含めます。ただし、固定できる条件は保存サービスや署名方式によって異なるため、採用するAPIの仕様に合わせます。
有効期限は、想定容量、通信速度、再試行方法、分割数を踏まえて決めます。短すぎる期限は失敗を増やし、長すぎる期限は漏えい時に利用できる時間を広げます。固定値だけで決めず、実データと現場の通信環境を使って調整します。
注意したいのは、有効期限を過ぎた瞬間に進行中の通信が必ず切断されるとは限らないことです。リクエスト開始時に期限を判定する方式もあれば、再接続や各分割リクエストの開始時に判定される方式もあります。採用サービスの仕様を確認し、再接続時や次の分割送信時に期限切れとなる前提で設計します。
署名付きURLは、一回限りのトークンとは限りません。有効期限内に同じURLが再利用され、同じ保存先へ再度書き込まれる実装があります。一回だけ受け付けたい場合は、未使用、送信中、完了、無効などの申請状態を業務システム側で管理し、条件付き書き込みや版管理を併用します。
署名に使った認証情報の有効期限が、URLに設定した期限より先に切れることもあります。URLの表示上の期限だけでなく、署名主体の認証情報、組織ポリシー、保存領域側の制限を含めて実効期限を考えます。
署名付きURLの全文は、画面、通常ログ、分析基盤、問い合わせ記録へ残しません。必要なログには、アップロード識別子、保存先の内部識別子、発行時刻、有効期限、発行者、結果コードなどを保存し、署名部分は除外または確実に伏せます。
端末へ返す情報には、URL、アップロード識別子、期限、必要なヘッダー、送信方式、完了通知用の識別子を含めます。URLそのものを利用者がコピーして別の場所へ貼り付ける操作は、通常の業務画面では不要です。
手順3 点群OBJを保存領域へ直接アップロードする
署名付きURLを取得したら、端末から保存領域へ点群OBJを直接送信します。送信には暗号化された接続を使い、証明書エラーを無視して続行する設定は避けます。
送信前には、対象ファイルが申請時から変わっていないか、必要な関連ファイルがそろっているか、有効期限に余裕があるかを確認します。端末の時計がずれていると、画面に表示する残り時間や再発行判定を誤る可能性がありますが、署名の実際の期限判定は保存サービス側で行われる方式もあります。端末時刻だけを失敗原因と決めつけず、応答コードとサービス仕様を確認します。
アップロード中は、送信済み容量、全体容量、進捗率、開始時刻、再試行状態を表示します。処理中という表示だけでは、正常に進んでいるのか停止しているのか判断しにくいためです。
大容量ファイルでは、保存サービスが提供する分割アップロードや再開可能なアップロードを利用します。単純に端末側でファイルを分けて同じURLへ送るのではなく、開始、各部分の送信、確定、中止というAPIの流れに合わせます。
分割アップロードでは、通常、アップロード識別子と各部分の番号を管理します。各部分に対して個別の署名付きURLまたは認可済みリクエストが必要になる方式もあります。開始や確定の操作まで端末へ広い権限を与えず、業務システムが必要な操作だけを仲介する構成を検討します。
通信が切れた場合は、保存領域へ送信済み部分を問い合わせ、未送信部分だけを再送します。端末側の記録だけを正しいとみなさず、保存領域側の状態と照合します。
再試行は、通信の一時切断、期限切れ、権限不足、容量超過、署名条件の不一致、チェックサム不一致など、原因に応じて分けます。一時的な通信障害には間隔を広げながら再試行し、期限切れでは新しいURLを取得します。権限不足や条件不一致を無制限に繰り返しても解決しません。
端末では失敗と表示されても、保存領域にはオブジェクトが作成されている場合があります。再送前に、申請状態、保存先の存在、容量、チェックサムを確認し、重複登録や上書きを防ぎます。
ブラウザから直接アップロードする場合は、正規画面で必要な送信元だけをCORS設定で許可します。ただし、CORSはブラウザ上の送信元制御であり、署名付きURLそのものの認証や一回限りの利用を保証する仕組みではありません。URLの権限制限、有効期限、保存先限定、サーバー側検証を別に実施します。
エラー画面には、利用者が次に行う操作を表示します。通信を確認する、新しいURLを取得する、ファイルを再選択する、管理者へ連絡するなどを案内し、内部の保存先名称、署名付きURL全文、認証情報は表示しません。
手順4 容量とチェックサムでファイルを検証する
アップロード完了後は、保存されたファイルを未検証領域で確認します。端末から完了通知が届いたという理由だけで、正式なデータとして扱いません。
最初に、保存先が申請時に決めた場所と一致するか、オブジェクトが存在するか、実容量が申告容量と一致するかを確認します。許容差を設ける場合は、その理由と範囲を明確にします。
次に、チェックサムで内容の同一性と転送時の完全性を確認します。保存サービスがアップロード時のチェックサム検証を提供している場合は、その機能を利用します。端末側の値と保存後の値を独自に比較する場合は、同じアルゴリズム、同じ対象バイト列、同じ表現形式を使います。
チェックサムには目的の違いがあります。転送中の偶発的な破損確認にはサービスが対応するCRC系などを利用でき、申請時のファイルと保存後のファイルが同一であることを追跡するには、必要に応じてSHA-256などの値を管理できます。採用する方式は処理負荷と目的を踏まえて決めます。
保存サービスが返すETagを、常にファイル全体のMD5値だと決めつけてはいけません。分割アップロード、暗号化方式、サービス実装によって意味が異なる場合があります。完全性確認には、そのサービスが正式に提供するチェックサム項目を使います。
容量とチェックサムの確認後に、OBJとしての内容を検証します。拡張子だけで判断せず、許可した記述を解析できるか、頂点が存在するか、座標が有限の数値か、参照する頂点番号が範囲内かを確認します。
極端に長い行、過大な頂点数や面数、深い参照関係、異常な数値、解析に長時間を要する構造などにも上限を設けます。検証用パーサーが大量のメモリーやCPUを消費しないよう、時間、メモリー、行数、ファイル数を制限します。
未知のOBJ命令や独自拡張を無条件に実行または解釈しません。業務で必要な記述を許可リスト化し、未対応の記述は拒否または警告として扱います。使用する解析ライブラリは更新し、検証処理は業務システム本体から分離した環境で動かすことも検討します。
圧縮ファイルや関連ファイルを受け付ける場合は、展開先から外へ出るパス、絶対パス、外部URL、想定外拡張子を拒否します。運用上必要であれば、マルウェア検査や隔離環境での解析も組み合わせます。
座標値の範囲だけから、単位や座標参照系を自動確定しないことも重要です。OBJ自体に必要な測量メタデータが含まれない場合があるため、申請時の管理情報と照合し、不明なものは確認待ちにします。
土量計算へ使う場合は、計測範囲、基準面との重なり、高さの基準、単位、欠損、外れ値を確認します。OBJが正常に読み込めることと、数量計算に適していることは別の判定です。
材質ファイルや画像を受け付ける場合は、成果一式の内部参照だけで解決できるかを確認します。欠けている関連ファイルが表示だけに影響するのか、解析にも影響するのかを区別します。
検証に失敗したファイルは、正式データと分離した状態に置きます。失敗理由、容量、チェックサム、申請識別子、検証日時を記録し、再送、メタデータ修正、管理者確認のどれが必要かを利用者へ示します。
手順5 検証済みデータを土量計算と共有に利用する
検証に合格したら、点群OBJを利用可能な状態へ変更します。状態変更は、検証処理の完了と同じトランザクションまたは整合性を保てる処理で行い、途中状態のデータが正式版として見えないようにします。
利用可能にするときは、アップロード申請、利用者、現場、工区、計測日時、計測段階、単位、座標参照系、高さの基準、チェックサム、原データとの関係を記録します。
土量計算では、現況面だけでなく比較対象の基準面が重要です。掘削前地形、設計面、前回計測面のどれを使うかで結果が変わります。計算結果には、使用した現況データと基準データの識別子を残します。
計算範囲も記録します。点群全体ではなく特定の掘削範囲だけを対象にした場合は、その境界を保存します。重機、車両、資材、仮設物、植生などを除外した場合は、除外範囲と処理方法も残します。
同じOBJでも、外れ値処理、補間方法、基準面、範囲設定によって結果が変わります。再計算時は以前の値を上書きせず、新しい計算版として登録します。
現場で即土量を確認するための概算値と、契約数量、出来形、検査資料などに使う値は、同じ扱いにしない方が安全です。用途、確認状態、未計測範囲、欠損の有無を画面上に表示し、数値だけが独り歩きしないようにします。
外部共有では、アップロード用の署名付きURLを閲覧用に転用しません。アップロードと閲覧では必要な操作が異なるため、共有対象、閲覧者、有効期限を限定した別の仕組みを使います。
元の点群OBJを渡す必要がない場合は、閲覧用に変換したデータ、画像、計算結果、限定した範囲だけを共有します。共有終了後にアクセスを停止できるよう、共有履歴と期限を管理します。
正式版、旧版、確認待ち、検証失敗、無効の状態を画面で区別します。土量計算を開始するときは、どの版を選択しているかを利用者が確認できるようにします。
大容量の点群OBJを安定して送信する方法
大容量の点群OBJでは、採用する保存サービスが提供する分割アップロードまたは再開可能なアップロードを利用します。ファイルを一定単位へ分けるだけでなく、開始、部分送信、一覧確認、確定、中止という処理全体を管理します。
分割単位が小さすぎるとリクエスト数と管理負荷が増え、大きすぎると一部分の再送にも時間がかかります。想定容量、通信速度、端末性能、サービスの最小単位や最大部分数を踏まえて設定します。
開始時に発行されるアップロード識別子は、現場、利用者、申請、保存先と関連付けます。各部分について、番号、容量、チェックサム、送信状態、応答情報を記録します。
すべての部分がそろったことを確認してから、保存領域側で一つのオブジェクトとして確定します。確定後は、全体容量と全体チェックサムを確認し、検証処理へ進めます。
未完了の分割データは正式なOBJではありません。一定期間更新されていない未完了アップロードを中止し、残った部分を整理する仕組みを用意します。端末が処理を中断しただけでは、保存領域側の部分データが自動的に消えない方式もあります。
端末を再起動した場合でも再開できるよう、アップロード識別子と送信済み部分を安全に保持します。ただし、署名付きURL全文を長期保存するのではなく、再開時に業務システムへ状態を問い合わせ、権限を再確認して必要なURLだけを再発行します。
並列送信は速度向上に役立つ場合がありますが、回線、端末、保存サービスへ過大な負荷をかけることもあります。固定の最大並列数を設け、失敗率や通信状態に応じて調整します。
アップロード前の軽量化は有効な場合がありますが、土量に影響する形状を失わないことが前提です。軽量化の設定を版として残し、原データと計算用データを追跡できるようにします。
署名付きURLの漏えいを防ぐ運用
署名付きURLは、一時的な認証情報として扱います。メール、チャット、問い合わせ票、画面画像、ブラウザの履歴共有、アクセス解析などへ不用意に残さないようにします。
通常ログにはURL全文を記録せず、署名部分を除いた識別情報と処理結果を記録します。プロキシ、負荷分散装置、監視サービス、エラー収集サービスがクエリ文字列を保存していないかも確認します。
業務画面から外部サイトへ遷移する際に、URLが参照元情報として送られないようにします。署名付きURLを通常の画面URLとして表示せず、アップロード処理の内部だけで使用する構成が基本です。
利用者向けの問い合わせ手順では、署名付きURLが映った画面画像や開発者向け通信記録をそのまま送らないよう案内します。管理者が確認する場合も、閲覧権限と保存期間を限定します。
有効期限は短いほどよいと単純には決められません。短すぎる期限は再発行と失敗を増やし、利用者が別経路で送ろうとする原因にもなります。実際の容量と通信状況を基に、必要な時間へ限定します。
URL発行回数、失敗回数、異なる場所からの利用、想定外の容量、同一保存先への繰り返し書き込みなどを監視します。ただし、通信が不安定な現場では再発行が増えるため、回数だけで不正と断定せず、利用者、現場、時間帯、失敗理由を合わせて確認します。
署名付きURLの失効方法はサービスによって異なります。発行後に個別URLだけを即時失効できない方式もあるため、短い期限、署名主体の認証情報管理、保存領域のポリシー、申請状態、必要に応じたネットワーク制限などを組み合わせます。
開発用、検証用、本番用の保存領域は分離します。検証環境の利用者や処理が本番データへ書き込めないようにし、本番用URLを検証環境で発行しない構成にします。
検証前のデータと検証済みのデータも分けます。未検証領域は外部公開せず、解析処理に必要な主体だけが読み取れるようにします。合格後は状態変更または安全な移動処理によって利用領域へ反映します。
点群OBJのアップロードで起こりやすい問題
よくある問題の一つは、有効期限に関する誤解です。進行中の一回の通信が期限到達と同時に必ず止まるとは限らず、再接続や次の部分送信で失敗する場合があります。採用サービスの判定時点を確認し、端末の表示だけで原因を断定しません。
署名条件と実際のリクエストが一致しない問題もあります。コンテンツ形式、チェックサム、暗号化関連ヘッダーなどを署名へ含めた場合、端末が同じ値を送らなければ拒否されることがあります。署名時と送信時でヘッダー生成を共通化します。
同じURLの再利用による上書きも注意点です。端末が再試行したとき、既存オブジェクトを置き換える操作になる場合があります。一意の保存先、条件付き作成、版管理、申請状態を組み合わせます。
分割アップロードでは、部分データは送信済みでも確定処理が終わっていない状態があります。端末側の進捗が百パーセントでも、保存領域側で全体オブジェクトが確定しているとは限りません。確定応答と保存後の属性を確認します。
チェックサム不一致は、通信中の問題だけでなく、申請後のファイル変更、対象バイト列の違い、文字列表現の違いでも起こります。端末とサーバーでアルゴリズムと対象を統一します。
ETagを一律に全体ファイルのハッシュとして比較すると、分割アップロードで誤判定する場合があります。保存サービスが提供する正式なチェックサム項目を確認します。
OBJのアップロードには成功しても、単位、座標参照系、高さの基準が不明で利用できないことがあります。OBJの座標値だけでは測量条件を確定できないため、申請メタデータを必須にします。
点群が画面外へ離れて表示される場合は、座標参照系、原点、軸方向、単位、座標変換を確認します。極端に小さい、または大きい場合も単位の取り違えを疑います。
土量が想定と大きく異なる場合は、計算式だけでなく、基準面、計算範囲、欠損、外れ値、重機や資材の混入、点の間引き、補間方法を確認します。
水面、反射しやすい面、暗部、植生、重機の陰などでは点が不足することがあります。アップロードが正常であっても、計測対象を十分に表現しているとは限りません。検証ではデータ形式だけでなく、対象範囲の被覆状況も確認します。
材質や画像が不足すると表示が変わる場合があります。土量計算に不要な不足なのか、成果一式として不完全なのかを区別し、利用目的に応じて警告または失敗とします。
利用者向けのエラーには、次の操作を示します。再試行、新しいURLの取得、再出力、メタデータ修正、管理者確認のどれが必要かを明確にし、同じ操作を無制限に繰り返させないようにします。
現場で即土量を確認するためのデータ管理
現場で即土量を確認する目的は、点群OBJを保存することではなく、施工判断に必要な数量を、根拠が分かる状態で早く確認することです。
計測、ファイル生成、申請、アップロード、検証、解析、土量計算、共有を一つの識別子でつなげます。途中で手作業による名称変更や別フォルダーへの移動が多いと、別現場、別工区、旧版との取り違えが起こりやすくなります。
計測時点で、現場、工区、目的、日時、施工段階、座標参照系、単位、高さの基準を設定し、その情報をアップロード申請へ引き継ぎます。
掘削途中の残土量を確認する場合は、掘削前の基準データと現在の計測データを関連付けます。盛土の進捗では、施工前地盤、計画面、現在面を区別します。
同じ現場で複数回計測するときは、計測ごとに一意の識別子を付けます。ファイル名だけで判断せず、計測日時、施工段階、検証状態、正式版を画面で確認できるようにします。
点群全体をアップロードしても、土量の対象が一部だけという場合があります。計算範囲を保存し、どこを対象にした数値かを追跡できるようにします。
点群内の重機、車両、資材、仮設物、植生を除外した場合は、除外範囲と方法を残します。自動除外を使う場合も、適用した設定と確認結果を記録します。
施工途中の配車判断に使う概算と、正式な数量確認に使う値では、必要な確認手順が異なります。用途を表示し、未計測範囲や欠損がある場合は警告します。
アップロード完了後に自動解析を始める場合は、同じデータに処理が重複しないようにします。一つのデータ識別子に対して、受付、検証中、解析中、完了、失敗の状態を管理します。
失敗した解析を再実行できるようにする一方、同じ入力から複数の正式結果が無秩序に作られないよう、再実行回数と版を記録します。
画面には、アップロード中、検証中、解析中、計算完了、確認待ち、失敗を表示します。担当者が状況を把握できれば、同じファイルを何度も送る操作を減らせます。
点群OBJと計算結果の履歴を残す方法
点群OBJを業務で利用する場合は、最新版だけでなく、計測と計算の履歴を管理します。施工中は地形が変化するため、過去データが比較や説明に必要になることがあります。
再計測したOBJは既存ファイルへ上書きせず、新しい版として登録します。初回計測、再計測、補正後、確認済み、無効などの状態を分けます。
加工した場合は、外れ値除去、点の間引き、座標変換、不要範囲の削除、面生成などの処理を記録します。元データ、加工後データ、計算用データの関係を追跡できるようにします。
土量計算結果にも版を付けます。基準面、計算範囲、除外範囲、補間方法などを変えて再計算した場合、以前の値を消さず、変更理由とともに残します。
計算結果には、現況データ、基準データ、計算範囲、除外条件、計算日時、実行者、使用した処理設定を関連付けます。数値だけを保存すると、後から差の理由を説明できません。
正式版を変更する場合は、変更者、変更日時、理由を記録します。旧版は削除せず、通常の選択肢から外した状態にします。
検証失敗ファイルは、原因調査に必要な期間だけ隔離保管します。大容量ファイルを無期限に残さず、失敗理由、容量、チェックサム、申請情報を残したうえで、定めた期間後に整理します。
保存期間は、未完了の分割データ、検証失敗データ、正式な計測成果、計算結果、共有用変換データで分けます。契約、発注者の条件、社内規定に保存要件がある場合は、それを優先します。
履歴管理の目的は、単に古いファイルを残すことではありません。現在の正式版、旧版、計算の根拠、変更理由を判断できる状態にすることです。
安全なアップロード環境を定着させるポイント
安全な仕組みでも、現場担当者が使いにくいと、別のファイル共有手段へ流れる可能性があります。安全性と操作性を同時に設計します。
担当者の操作は、計測データを選び、対象現場と計測段階を確認して送信する流れへまとめます。署名付きURLの発行や更新はシステム側で処理し、利用者にURLを扱わせないようにします。
期限が不足している場合は、新しいURLを取得します。ただし、自動再発行の前にも利用者の権限と申請状態を確認します。
通信が不安定な場合は、一時停止と再開を可能にします。再開時は保存領域側の状態を確認し、未送信部分だけを送ります。
エラーは原因別に案内します。通信、期限、権限、条件不一致、容量、チェックサム、形式、座標メタデータなどを区別し、次の行動を表示します。
管理者向けには、成功率、失敗理由、平均容量、送信時間、再発行回数、未完了アップロード数、検証失敗数を確認できるようにします。特定現場で失敗が多い場合は、通信方法、分割単位、期限、端末設定を見直します。
運用開始後は、実際の点群OBJの容量と通信環境を基に設定を調整します。机上の小さなテストファイルだけでなく、現場で想定される容量を使って確認します。
試験では、通信中断、端末再起動、期限切れ、同一URL再利用、重複通知、同時送信、上書き競合、チェックサム不一致、未完了分割データの整理も確認します。
解析ライブラリや保存サービスの仕様変更にも対応できるよう、依存関係、対応形式、署名方式、チェックサム方式を定期的に見直します。
利用者と管理者には、署名付きURLを共有しないこと、未検証データを正式値として扱わないこと、概算と正式数量を区別することを周知します。
まとめ
点群OBJを署名付きURLで安全にアップロードするには、URLを発行してファイルを送るだけでは不十分です。利用者確認、保存先の一意化、権限の限定、上書き防止、有効期限、送信後の検証、土量計算への引き渡しまでを一体として設計します。
手順1では、利用者が対象現場へ登録できるかを確認し、容量、形式、計測情報、単位、座標参照系、高さの基準を申請として登録します。保存先はシステム側で一意に決めます。
手順2では、今回の保存先へ必要な操作だけを許可する署名付きURLを発行します。署名付きURLは一回限りとは限らないため、申請状態、条件付き書き込み、版管理を組み合わせます。
手順3では、端末から保存領域へ暗号化通信で直接送信します。大容量データでは、採用サービスの分割アップロードや再開可能なアップロードを使い、各部分の状態を管理します。
手順4では、容量、正式なチェックサム、OBJの内容、関連ファイル、解析負荷、測量メタデータを検証します。ETagを一律に全体ファイルのハッシュとして扱わず、保存サービスが提供する検証方法を確認します。
手順5では、検証済みデータだけを土量計算や共有へ利用します。現況データ、基準面、計算範囲、除外条件、処理設定を結果と関連付け、再計算は新しい版として残します。
現場で即土量を確認するには、送信速度だけでなく、データの正しさ、用途、版、根拠が明確であることが重要です。計測からアップロード、検証、計算、共有までをつなげることで、施工途中の判断に利用しやすくなります。
点群OBJの運用環境を検討する際は、実際のファイル容量、通信条件、座標情報の管理方法、検証手順を確認してください。LRTK Phoneを活用する場合も、対象業務で必要な精度、対応形式、クラウド共有の権限、保存期間などを事前に確認し、現場の運用ルールと合わせて導入することが大切です。