EQUATOR GNSS / BY TECHNOGISドイツ · インドネシア
データと品質

構造化された GNSS 土地調査アーカイブにジオパッケージを使用する

土地調査レイヤー、リファレンス メタデータ、観察関係をポータブル パッケージで整理して、明確なリリースとバックアップ プロセスを維持します。

構造化された GNSS 土地調査アーカイブにジオパッケージを使用する

プロジェクトでのパッケージの役割を定義

GeoPackage は、標準ベースの SQLite コンテナーです。 地理空間情報。 1 つのポータブル ファイルに複数の関連レイヤを整理するのに役立ちますが、ファイル形式だけでは完全な土地調査アーカイブは作成されません。 パッケージが、稼働中のデータベース、受理済みの配信、または長期的な Exchange スナップショットのいずれであるかを決定します。 各ロールには、明確な更新ルールとリリース ルールが必要です。

プロジェクトに必要なジオメトリ レイヤー、非空間テーブル、サポート ファイルをリストします。 生の GNSS 観測と専用機器のログを、必要に応じて適切な元の形式で保管してください。 ジオパッケージは、その証拠を置き換えるふりをすることなく、その証拠をインデックス化または参照できます。 アーカイブは、空間製品と、それらがどのように生成されたかを理解するために必要な情報の両方を保持する必要があります。

さらに学ぶ 意味を失わずに GNSS データを GIS へ出力する

物理的な意味の周りのレイヤーを設計

測地基準点、観測点、資産、地形の傾きの変化を示す線、および目的に応じて派生した製品を分けます。 レイヤーの順序や座標の一致に頼るのではなく、安定した識別子と明示的な関係を使用してください。 1 つのアセットに複数の観測レコードが含まれている場合があり、コントロール マークには、承認された座標リリースの履歴がある場合があります。 スキーマは、これらの区別をサポートする必要があります。

ドキュメントのジオメトリ タイプと各レイヤーに必要な属性。 関係のないオブジェクトは、ジオメトリ タイプを共有するという理由だけで、一般的なポイント テーブルに格納しないでください。 レイヤー セマンティクスをクリアすると、検証や後の更新が容易になります。 受信者は、どのレコードが直接の観察、受理された位置、または解釈であるかを、元の著者にすべての表について説明するように求めることなく、判断できる必要があります。

さらに学ぶ プロジェクトの結果を確実に処理して配信するための GNSS プロジェクト フォルダの整理

リファレンス定義と出所を維持

各空間レイヤーに適切な CR を保存し、それを解釈するために必要なより広い土地調査メタデータを提供します。 データムの実現、座標エポック、ローカル グリッド パラメータ、および関連する垂直参照を含めます。 標準の CRS 識別子は、土地調査の処理中に適用されるすべての操作をキャプチャしない場合があります。 プロジェクトのメタデータに変換とジオイド モデルのバージョンを記録します。

座標が変換されるときは、ソース観測またはトレース可能なソース識別子を保持します。 配送変換中は、元の座標レコードのみを上書きしないでください。 異なるレイヤーが異なる参照を使用する場合は、その理由を述べ、その関係をテストします。 1 つのコンテナーは複数のレイヤーを保持できますが、その利便性は、互換性のない空間または高さの定義を隠してはなりません。

さらに学ぶ GNSS 土地調査で重要なシェープファイルの制限 プロジェクト結果の配信

属性と関係を意図的に使用する

フィールドタイプ、ユニット、コード化された値、および不明な状態を定義します。 先頭のゼロまたは長いコードを保持するために、必要なときに識別子をテキストとして保持します。 観測アイデンティティからフィーチャ アイデンティティを分離します。 選択したソフトウェアでサポートされている機能を使用し、重要な関係が転送に耐えられることを確認します。 1 つのアプリケーションで機能するデータベース設計は、別のツールでは理解できない拡張機能に依存している可能性があります。

制約をテストし、再訪問や置き換えられた観測などの代表的な記録と結合します。 レビューの状態と修正の理由を保持します。 新しい座標が受け入れられるたびに、古い証拠を削除する必要があるスキーマは避けてください。 アーカイブにより、後のレビュー担当者は、現在の位置がどのように選択され、どのような観察結果がその前にあったかを理解できるようにする必要があります。

さらに学ぶ GNSS GeoJSON エクスポートの品質: 座標、ジオメトリ、来歴

ニューメキシコ州Midnight Meadowのドローンオルソ画像。
ニューメキシコ州Midnight Meadowのドローンオルソ画像。 · USGS / Public Domain

添付ファイルと外部証拠を明示的に処理

写真とドキュメントがサポートされているメカニズムを介して埋め込むか、または安定した参照で外部に保存するかを決定します。 選択した規則を記録し、受信ワークフローでテストします。 ディレクトリ構造が保持されている場合は、相対パスが移植可能である場合がありますが、別のコンピュータでは絶対的なパスが破損することがよくあります。 データベース ファイルにすべてのリンクされた画像が自動的に含まれるとは思わないでください。

パッケージ外にある生のファイル、レポート、その他の証拠のマニフェストを作成します。 安定した機能または観測識別子を介してそれらをリンクします。 最終ディレクトリから配信されたコピーをテストします。 受信者は、特定のポイントに対応するフォルダー名またはカメラ ファイル名を推測せずに、裏付けとなる証拠を見つけることができるはずです。

さらに学ぶ 意味を失わずに GNSS データを GIS へ出力する

作業データとリリースのスナップショットを保護

ツールとファイルの状態に適した明確なバックアップ プロセスを使用します。 積極的に変更するデータベースをやみくもにコピーし、結果が一貫したリリースになると想定することは避けてください。 編集を完了し、転送可能なスナップショットを作成するためのソフトウェアのサポートされている方法に従ってください。 受信者が無意識に未完成のファイルを使用しないように、作業と発行済みのバージョンを区別できるようにします。

パッケージのバージョン、観測範囲、および有効なリリース日を記録します。 更新が発行されたときに、以前のリリースを保持します。 複数の人が同時に編集する必要がある場合は、ファイルベースのワークフローがプロジェクトに適しているかどうか、または別の管理対象データベースの配置がより適切かどうかを評価します。 ポータビリティは貴重ですが、調整された所有権と更新ルールの必要性を取り除くものではありません。

さらに学ぶ プロジェクトの結果を確実に処理して配信するための GNSS プロジェクト フォルダの整理

パッケージとその内容を検証

適切なツールを使用して規格の適合性を確認し、土地調査の意味を個別に検証します。 レイヤ カウント、ジオメトリ タイプ、CRS 定義、識別子、属性、および関係を確認します。 代表的な座標とレコードをソースと比較します。 技術的に有効なジオパッケージには、誤って割り当てられた参照、または間違ったアセットにリンクされたポイントが含まれている可能性があります。

意図する受信アプリケーションでパッケージを開き、重要なワークフローをテストします。 レイヤー、フィールド値、添付ファイルの参照が利用可能であることを確認します。 不明な値、日付、長い識別子を調べます。 パッケージから簡略化されたエクスポートが作成された場合は、ソース コンテナーのすべての品質プロパティを継承すると仮定するのではなく、そのエクスポートを個別に検証します。

さらに学ぶ GNSS 土地調査で重要なシェープファイルの制限 プロジェクト結果の配信

ポータブル ファイルを使用したドキュメントの配信

データ ディクショナリ、レイヤー ガイド、参照定義、ソース マニフェスト、レビュー ステータス ルール、未解決の問題を提供します。 どのレイヤーがリリースに対して権威があり、どのレイヤーが派生するかを述べます。 後で観察を追加する方法と、受け入れられた位置がどのように修正されるかを説明します。 ポータブル ファイルは、他のチームがスキーマをリバース エンジニアリングせずに維持できる場合に最も役立ちます。

発行されたパッケージをアーカイブし、証拠と検証結果をサポートします。 それを作成するプロセスを保持します。 GeoPackage は、GNSS Land Survey のプロジェクト結果の整理を容易にすることができますが、信頼できるアーカイブ値は、文書化されたデータ モデルと追跡可能な観測履歴から得られます。 コンテナーはその動作をサポートしています。 自動的には実行されません。

さらに学ぶ GNSS GeoJSON エクスポートの品質: 座標、ジオメトリ、来歴

2 番目のワークステーションでパッケージをテストする

リリース前に、目的の配信構造を別のテスト場所にコピーし、作成者の作業フォルダーにアクセスせずに開きます。 レイヤー、結合、写真、メタデータをチェックします。 これにより、元のコンピューターのパスまたはアプリケーションの状態によって隠された依存関係が明らかになります。 現在の位置だけでなく、歴史関係が行使されるように、再訪と置き換えられた観察をテストに含めます。

パッケージのデザインまたはマニフェストを介して、欠落している依存関係を記録して解決します。 受信ツールが非標準の拡張機能を解釈できない場合は、完全なアーカイブを保存しながら、合意された相互運用可能なビューを提供します。 修正後、影響を受けたチェックのみを繰り返します。 この実用的なポータビリティ テストにより、プロジェクトの結果の配信がレビュー可能になり、整理されたファイルがオーサリング ワークステーションを離れるとすぐに、整理されたファイルが不完全なアーカイブになる可能性が減ります。

有効な検証ノートに、テストの場所とアプリケーションの受信バージョンを含めます。 テストでは、単にファイルがどこかに開かれていることを証明するのではなく、プロジェクトの結果ワークフローを意図的に配信することを実証する必要があります。 外部の証拠がパッケージの外に残っている場合は、コピー後にマニフェストと相対パスを確認してください。 ポータブル コンテナとポータブル アーカイブは関連していますが、実績は異なります。 受信者が必要な証拠を見つけて、著者のプライベート ワークスペースにアクセスせずに信頼できるレイヤーを理解できれば、完全な配信が準備ができます。

さらに学ぶ 意味を失わずに GNSS データを GIS へ出力する

実践チェックリスト

実践チェックリスト

  1. 権威あるレイヤーと観測関係を定義します。
  2. 外部ファイルを文書化し、アタッチメントの移植性をテストします。
  3. 制御リリースのスナップショットを作成して検証します。
EQUATOR GNSS

GNSS の構成を計画する

EQ10 と EQ20 の受信機仕様を比較し、プロジェクトに必要な構成とサポートをご相談ください。

GNSS 受信機を比較

参考資料

  1. GDAL Documentation — GeoPackage Vector
  2. QGIS Documentation — Working with Projections
  3. NOAA NGS — User Guidelines for Single Base Real Time GNSS Positioning