GNSS 調査のための GIS フィールド フォームの設計
屋外測定チームに不足している情報を発明することを強制せずに、オブジェクトのアイデンティティ、観測の証拠、有用な検証を保持するフォームを構築します。
フォームがサポートする決定から始めます
フィールド フォームは、オブジェクトを識別するために必要な情報を収集し、その位置を解釈し、プロジェクトの次の決定をサポートする必要があります。 可能なフィールドの長いリストではなく、データセットのユーザーから始めます。 メンテナンス インベントリ、地形の土地調査、調査プロットの記録には、さまざまな属性が必要です。 各フィールドの目的を定義し、誰も使用または検証しない値を削除します。
フィールド チームとオフィス チームと、いくつかの重要な情報について同意します。 物理観測点、特徴タイプ、安定した識別子を含めます。 メタデータの配置を説明的なアセット属性とは別にしておきます。 フォームは、乗組員が一貫して完了することができ、レビュアーがすべてのボックスがいっぱいになったときだけでなく、証拠を後で理解できる場合に成功します。
機能を観測から分離します
物理的資産または区画は、何度も訪れることがあります。 安定した機能識別子を指定し、訪問または測定ごとに個別の観測識別子を使用します。 これは、オブジェクトを複製せずに履歴をサポートします。 新しい GNSS 座標は、新しいアセットを表すのではなく、既存のレコードを改善する可能性があります。 データ モデルは、その区別を可能にする必要があります。
訪問時に観測日、演算子、方法、レビュー状況を記録します。 明示的なキーを使用して、写真とメモを同じ観測または機能にリンクします。 ファイルの順序やおおよその時間の一致に頼らないでください。 明確なアイデンティティ関係により、正しい座標が間違ったアセットに付加されたり、後で更新すると元の証拠が消去されるリスクが軽減されます。
フィールドの種類と単位を意図的に使用してください
意味に応じて、数値、テキスト、日付、およびコード化されたフィールドを選択します。 先行ゼロを含む識別子は、通常、算術ではなくテキスト処理を必要とします。 測定には、定義された単位と物理参照が必要です。 深さフィールドは、それがパイプ クラウン、インバート、センターライン、または別の特定のポイントを参照しているかどうかを理解していない限り、不完全です。
目的のエクスポート形式を早期にテストしてください。 長い識別子、特殊文字、日付、および 10 進値は、アプリケーションによって異なる動作をする場合があります。 ユニット ラベルをフォームに表示したままにし、1 つのフィールド内でユニットを混合しないようにします。 適切に設計されたスキーマは、屋外での測定作業の前に多くのエラーを防ぎます。一方、一般的なメモの列は、サイトにアクセスできなくなった後、オフィス チームが意味を再構築することになります。
フィールドでわかることを検証
乗組員が合理的に確立できる情報の必須フィールドを使用します。 不明な状態または観測されていない状態に、適切な理由を指定します。 アクセスできないチャンバーまたは読み取れないラベルの値を要求すると、推測が促進される可能性があります。 検証は証拠の質を改善する必要があります。真実性を犠牲にしてフォームを完全に見せるのではありません。
プロジェクトの定義に基づいて、賢明な範囲と関係チェックを適用します。 たとえば、オフセットから派生した観測値には、オフセットの証拠フィールドが必要です。 タスクに関して合意されていない任意の数値制限は避けてください。 異常ではあるが正当なケースをテストして、フォームが実際の観察を拒否したり、誤ったカテゴリーに押し付けたりしないようにします。
可能な場合は、位置決めの出所を自動的にキャプチャします
サポートされている機器ワークフローによって提供される座標参照、方法、補正ステータス、および関連する品質のメタデータを保存します。 これらのフィールドを理解しやすくし、その意味を文書化します。 レシーバー インジケータは、万能保証ではありません。 プロジェクトの受け入れ評価では、自動的に記録された値に加えて、観測条件と独立チェックを考慮する必要があります。
乗組員は、障害物、柔らかい地面、不確かなターゲット、および代替方法に注意してください。 位置がオフセットから派生した場合は、測定された参照と導出を保持します。 すべてのレコードを 1 つの座標と 1 つの一般的な品質ラベルに縮小しないでください。 レビュー担当者は、直接観察と派生位置または暫定的な位置を区別するのに十分な情報を必要としています。
オフライン コレクションとリカバリのためのデザイン
識別子、写真、編集の作成など、接続なしでフォームをテストします。 同期が再開されると、レコードがリンクされたままになることを確認します。 2 人の乗組員が同じ機能を更新した場合の競合の処理方法を定義します。 安定したオフィス接続中にのみ機能するワークフローは、信頼できるローカル ストレージが最も重要な現場条件で失敗する可能性があります。
中断されたセッションやデバイスの交換のための実際のリカバリー プロセスを維持します。 データベースの関係を壊す可能性のある手動コピーではなく、サポートされているバックアップと同期の方法を使用してください。 非同期記録を認識し、転送の成功を確認するように乗組員を訓練します。 目標は、ネットワーク接続が消えても、フィールド観察からレビューされたデータセットまでの証拠チェーンを維持することです。
完全なキャプチャからオフィスへのワークフローを操縦
生産前に代表的なサンプルを収集します。 通常の機能、不明な値、オフセット観測、複数の写真、再訪を含めます。 サンプルをエクスポートし、受信 GIS またはアセット システムにロードします。 フォームを作成した人だけでなく、データを処理して使用する人と一緒にレビューしてください。
識別子、単位、日付、コード化された値、および添付ファイルのリンクを確認します。 レビュアーが、追加の説明なしに乗組員が観察したことを再構築できるかどうかを尋ねます。 実際の混乱に基づいてフォームを修正します。 パイロットは、技術的に有効なスキーマでは検出できない用語やワークフローの問題を明らかにすることが多く、それらを早期に修正する方が、何千もの一貫性のない記録を修復するよりもはるかに安価です。
フォームを制御プロジェクト アセットとして維持
フォームとそのデータ ディクショナリにバージョンを割り当てます。 フィールド、コード、検証ルールの変更を記録します。これには、有効な日付が含まれます。 スキーマが進化したら、古いレコードを解釈できるようにします。 コードの意味を静かに変更すると、すべてのデータベース行が技術的に有効なままであっても、履歴データが誤解を招く可能性があります。
フォーム定義、スキーマ、キャプチャ ガイダンス、およびデータセットを使用したレビュー プロセスを提供します。 未解決の問題と修正の背後にある証拠を保持します。 信頼できる GNSS フィールド フォームは、他の人が理解できるように、物理オブジェクト、観察方法、および記述記録を結び付けます。 その値は、フィールドの数やインターフェイスの視覚的な洗練からではなく、一貫した意味とトレーサビリティから得られます。
不明なアセット ケースをテストします
乗組員が予想される場所でカバーを見つけたが、ラベルが見つからず、所有者がそのアイデンティティをまだ確認できないとします。 このフォームは、暫定的な特徴関係、写真、および未解決のステータスを含む新しい観察を可能にする必要があります。 要点を保存する唯一の方法であるという理由だけで、乗組員に近くのデータベース レコードを選択するように強制するべきではありません。
Office Reviewer は、証拠を所有者の記録と比較し、後でアイデンティティを解決できます。 暫定識別子を保持し、承認されたマージを相互参照します。 これにより、インベントリが改善されると同時に、元の観測が保護されます。 パイロット中にこのケースをテストすると、フォームが正直な不確実性をサポートしているか、単にサポートされていない仮定を隠す完全なレコードを奨励するかが明らかになります。
未解決のアイデンティティと欠落している観察結果を区別するレビュー フィールドを含めます。 乗組員は何かを観察しました。その証拠は、アセット マッチが開いたままであるという理由だけで破棄されるべきではありません。 レビュアーは、訪問時の日付、位置、写真を保存しながら、後で関係を解決できます。 受信システムがこの状態を表すことができるかどうかをテストします。 それができない場合は、輸入要件を満たすためだけに不確実性を偽のアセット マッチに変換するようにフィールド フォームを強制するのではなく、コンパニオン イシュー テーブルに同意します。
実践チェックリスト
- 安定した機能 ID を訪問観測 ID から分離します。
- 証拠がない理由で、未知の値を許可します。
- パイロット オフライン キャプチャと受信システムのインポート。
