エクスポートを生き残る GNSS フィールド コーディング ディクショナリの構築
生産前にフィーチャ コードと属性を定義して、土地調査の観測が一貫した有用な GIS データまたは CAD データになるようにします。
最終データセットから開始
フィールド コーディング ディクショナリは、観測点をその意味に接続します。 フィーチャを分類する方法と、記録する属性を乗組員に指示します。 クライアント データセットまたは設計ワークフローから始めます。ただし、すぐに入力できるという理由だけで選択された略語のリストではありません。 最終的なシステムが期待する機能、必須フィールド、およびエクスポート規則を特定してから、実用的なフィールド フォームに戻します。
座標品質を特徴の意味から分離します。 あいまいなコードで正確に測定されたポイントは、アセット管理に使用できない場合があります。 逆に、詳細な資産の説明は、その調整がプロジェクトの基準を満たしていることを証明していません。 辞書は、その機能とその位置を解釈するために必要な観測コンテキストの両方の種類の情報を保存するのに役立つはずです。 他方向けの即興フリー テキスト ノートの中に 1 つを隠さないでください。
コードの定義 明確な定義
意図したフィーチャクラスごとに制御コードを使用し、平易な言語定義を提供します。 カバーの中心とフレームのエッジ、またはチャネル バンクとその反転などの詳細な違いを説明してください。 オペレーターは、選択する頭字語だけでなく、占有すべき物理ポイントを知る必要があります。 フィールドで混乱しやすい機能のスケッチまたは例の写真を含めます。
語彙を管理しやすいものにします。 ほぼ同一のコードを含む辞書は、乗組員の速度を落として一貫性のない選択肢を増やす可能性があります。 区別が属性に属している場合、代わりに、制御された属性値を持つ安定した機能コードを使用します。 生産中にコードの意味を変更しないでください。 定義を変更する必要がある場合は、新しいバージョンを発行し、以前の解釈を使用したセッションを特定して、オフィスがレコードを意図的に調整できるようにします。
有用な属性を設計する
必要な属性、許可される値、および単位を指定します。 パイプの直径のフィールドは、ラベルのない数字と物語の説明を混同しないでください。 条件フィールドには、クライアントが資産間での比較が必要なカテゴリーが一致している必要があります。 必要に応じて明示的な不明または非観測状態を含めます。これにより、乗組員は必須のフィールドを満たすためだけに値を発明することを余儀なくされないようにします。
直接観察と、ドローイング、ラベル、または別の人物から得た情報を区別します。 現場の検査官は、資産のカバーを確認できますが、その下に埋め込まれた構造物は確認できません。 辞書は、サポートされていない説明を奨励するのではなく、その不確実性を目に見えるようにする必要があります。 ワークフローに必要な別のソース フィールドまたは信頼フィールドを使用します。 これにより、測定されたもの、観察されたもの、推測されたものの違いが維持されます。
コントローラーの動作をテストする
実際のフィールド アプリケーションでディクショナリを作成し、代表的なレコードでテストします。 必須フィールド、ドロップダウン値、テキストの長さ、特殊文字を確認してください。 オペレーターが、座標を失ったり、説明のつかない重複を作成したりすることなく、エントリを修正できることを確認します。 適切に設計されたスプレッドシート スキーマは、コントローラー フォームに変換すると異なる動作をする可能性があるため、デバイス テストは設計の不可欠な部分です。
関数が使用されている場合は、ラインワークまたは機能接続テストを含めます。 エクスポートでどのように開始、継続、および終了のアクションが表示されるかを確認します。 個々の座標が有効であっても、シーケンス マーカーが欠落していると、無関係な点を結ぶ線が生成される可能性があります。 将来のディクショナリまたはソフトウェアのリビジョンを、本番環境に到達する前に、同じ予想される解釈に対してチェックできるように、既知の小さなテスト データセットを保持します。
エクスポートとインポートの確認
目的のルートを介してテスト レコードをエクスポートし、宛先の GIS または CAD ソフトウェアで開きます。 コード、属性名、単位、文字エンコーディング、および null 値を確認してください。 1 つのプログラムによって切り捨てられたフィールドが、2 つの異なる意味を黙ってマージしないようにしてください。 宛先が特定のジオメトリ タイプを想定している場合は、フィーチャ コードが自動的に正しいオブジェクトを作成すると仮定するのではなく、エクスポートがそのタイプを作成することを確認します。
属性とともに座標参照情報を保持します。 GeoJSON 配信の場合は、投影グリッド値を経度と緯度のフィールドにコピーするのではなく、該当する形式の要件に従い、座標を適切に変換します。 宛先システムの既知のデータに対して場所をテストします。 ファイルのインポートが成功すると、構文が受け入れられたことを証明するだけです。 機能の意味または座標の解釈が転送を生き残ったことを証明するものではありません。
実例を通して訓練する
実際のサイト機能の小さなセットを使って乗組員と一緒に辞書を見直します。 オペレーターに、どのポイントを占有し、不確かな属性をどのように記録するかを説明してもらいます。 解釈の違いは、生産前の有用なフィードバックです。 必要に応じて定義と例を更新してから、承認されたバージョンを発行します。 トレーニングでは、暗記されたキーボード ショートカットだけでなく、コードを物理機能に接続する必要があります。
は、珍しいコードのクイック リファレンスと、追加をリクエストする制御方法を提供します。 即興の新しい略語は、新しい基準として黙って受け入れられるのではなく、レビューのためにフラグを立てるべきです。 無料のテキスト ノートは、例外的なコンテキストで利用できるようにしますが、後で欠落しているすべての定義を修復するためにそれらに依存しないでください。 一貫性は、何百もの短い矛盾するメモから推測するよりも、収集時に簡単に作成できます。
辞書をプロジェクト データとして管理
各ジョブに辞書バージョンを保存し、作成に使用したソースを保存します。 変更されたフィールドの名前変更や許可された値の変更など、承認された変更を記録します。 複数の乗組員が同時に作業する場合は、全員が同じアクティブ バージョンであることを確認します。 あるコントローラーが古い定義を使用するか、別の乗組員が必須と見なす属性を省略した場合、共有コード名だけでは十分ではありません。
クルーがまだサイトを再訪できるうちに、初期の生産記録のサンプルを確認します。 欠落している値、予期しないコード、一貫性のない物理的なポイントの選択を探します。 そのレビューを使用して、ワークフローを迅速に修正してください。 辞書が成功すると、エクスポート後の土地調査の理解が容易になり、オフィスの解釈が減り、座標とクライアントがそれを表現することを期待する実際の機能との間の接続が維持されます。
排水機能のコード定義
排水アセットの場合、単に排水するというラベルの付いたコードはあいまいすぎる可能性があります。 プロジェクトは、さまざまな物理ポイントを表し、さまざまな分析をサポートするため、カバー センター、アクセシブル インバート、チャネル エッジの個別の定義が必要になる場合があります。 占有する場所と、属性に属する寸法または観測値を定義します。 承認されたフィールド アクセスから必要な機能を観察できない場合は、不明な状態を含めます。
宛先 GIS または CAD ワークフローで、結果のレコードをテストします。 ポイントと線が意図したとおりに接続され、観測されていない反転がゼロの高さまたは別の誤解を招く値に変換されないことを確認します。 この例は、単にデータ入力を高速化するのではなく、辞書が意味を保護する方法を示しています。 乗組員は、各アセットで解釈を発明する必要はなく、オフィスは、正確な座標が説明する機能の物理的な部分を推測する必要はありません。
実践チェックリスト
- 各コードに関連付けられた物理ポイントを定義します。
- 実際のコントローラーで属性と接続性をテストします。
- 宛先ソフトウェアで完全なエクスポートを確認します。
