GNSS GeoJSON エクスポートの品質: 座標、ジオメトリ、来歴
必要な地理的参照に変換し、土地調査属性の意味を保持して、相互運用可能な GeoJSON を作成します。
GeoJSON が標準化するものを理解してください
GeoJSON は、地理的特徴とそのプロパティのテキストベースの形式です。 RFC 7946 の下では、位置は WGS84 の経度と緯度を 10 進数で使用します。 これは特定の交換規則であり、ジオメトリ配列内に任意の座標ペアを配置する許可ではありません。 予測された東と北は、標準に準拠した輸出の前に変換する必要があります。
エクスポートする前に、ソース参照とファイルの使用目的を特定します。 地元の土地調査グリッド、予測された CRS、および地理的参照はすべて、異なる値を通じて同じサイトを説明する場合があります。 元の土地調査データセットと参照メタデータを保持します。 GeoJSON は、Exchange および Web マッピングに役立ちますが、アーカイブに追加の土地調査の証拠が含まれている場合、完全な観測アーカイブに取って代わるものではありません。
値のラベルを変更するのではなく、変換します
ソース データセットに正しいソース CR を割り当ててから、GeoJSON 地理的参照に適切な変換を実行します。 関連するモデルのバージョンや、該当する場合のエポック情報など、使用した操作を記録します。 WGS84 ラベルを変更されていない投影座標に割り当てても、それらは変換されません。 変換後の代表的な既知のポイントをテストします。
エクスポート境界で軸の順序を明示的に確認してください。 一部のソフトウェアおよび参照定義では、内部で異なる規則を使用しています。 配信された GeoJSON 座標配列は、フォーマットの経度緯度の順序に従う必要があります。 間違った半球にプロットされている点は明らかな警告ですが、微妙な軸または参照ミスでも、もっともらしいジオメトリが生成される可能性があります。 数値範囲のチェックは、文書化された参照処理と一緒に役立ちます。
3 番目の座標の役割を定義します
RFC 7946 では、WGS84 楕円体に対する高さを表すオプションの 3 番目の位置値を許可します。 ジオイドから派生したエンジニアリングの標高をそのスロットに静かに配置して、すべての消費者が正しく解釈すると想定しないでください。 プロジェクトの立面図に別の参照がある場合は、明示的に合意された Exchange ワークフローを使用して、そのユニットと垂直参照を含む明確に名前が付けられたプロパティとして保存します。
欠落した高さをゼロと区別できるままにします。 ゼロの値は実際の座標値であり、高さが不明な一般的なマーカーではありません。 受信アプリケーションが 3 番目の座標を使用しているか無視しているかを確認します。 エクスポートは、ソース ポイント レイヤーが 3 次元であるという理由だけで、説明のつかない数字を追加するのではなく、土地調査の高さを正直に伝える必要があります。
ジオメトリの構造と特徴の意味の検証
各フィーチャが意図したジオメトリ タイプと有効な座標ネストを使用していることを確認します。 ポイント アセットが誤って線になってはいけません。また、調査対象の境界を、明示的な目的なしにその重心まで縮小すべきではありません。 ポリゴンの場合は、適切な検証ツールを使用して、クロージャーとトポロジを確認してください。 技術的妥当性は、ジオメトリが正しい物理オブジェクトを表していることを証明していません。
地物の件数と識別子を元データと照合してください。マルチパートの地物、空のジオメトリ、立ち入りできない区域が、プロジェクトの規則どおりに処理されているか確認します。扱いにくいレコードを説明なく削除してはいけません。除外または変換した地物の問題点を一覧に残し、交換用ファイルが測量データベース全体と異なる理由を別の確認者が理解できるようにします。
有用な属性と識別子を保持
プロパティで安定した機能と観測識別子を使用します。 テキスト識別子は、先頭のゼロまたは長いコードが重要なテキストとして保持します。 受信ワークフローに適した観察日、方法、品質ステータスを含めます。 意味が不明な一般的な精度プロパティを公開しないでください。 値が計測器の見積もり、独立チェック結果、またはプロジェクト分類かどうかを文書化します。
属性は簡潔に保ちますが、ジオメトリを解釈するには十分です。 写真や未処理の GNSS 観測データは、別のアーカイブ、識別子または合意された参照を介してリンクされている場合があります。 受信アプリケーションで特殊文字と null 値をテストします。 アセット識別子の型が変更されたり、不明な値が明らかに測定されたゼロに変換されたりしても、有効な JSON ファイルは操作上の意味を失う可能性があります。
バランス座標の精度とファイル サイズ
意図した使用法と裏付けられた証拠に従って、出力 10 進精度を選択します。 より多くの桁が、より正確な精度を生み出すことはありません。 過度の丸めはジオメトリを変更する可能性がありますが、不要な数字はファイルを拡大し、不当な詳細を暗示します。 プロジェクトを考慮せずに普遍的なルールを適用するのではなく、選択した精度が代表的なポイントと境界に与える影響をテストします。
大規模なデータセットの場合、GeoJSON がすべての用途で最も実用的な配信形式かどうかを確認します。 ブラウザの交換レイヤーと権威ある土地調査アーカイブは、異なる製品にすることができます。 完全なデータセットを適切な形式で保持し、目的のある GeoJSON エクスポートを作成します。 これにより、1 つのファイルですべてのワークフローを処理できるようにするためだけに、参照または観測メタデータを犠牲にすることを回避できます。
独立したコンシューマーでファイルをテスト
JSON 構文、ジオメトリ構造、座標範囲を検証し、目的の Web アプリケーションまたは GIS アプリケーションでファイルを開きます。 既知の場所、識別子、属性をソースと比較します。 サンプルを再インポートし、ジオメトリ値を検査します。 エクスポートが成功しても、受信システムがファイルを意図したとおりに解釈することは示されません。
具体的には、第 3 座標の処理、ヌル値、および添付ファイルの参照を確認してください。 ファイルの範囲と、異常な座標境界に近い機能を確認します。 リリース時に検証結果を保持します。 テストでは、基準の適合性とプロジェクトのデータの意味の両方を確認する必要があります。これらは関連していますが、要件が異なるためです。
出所のある 交換用ファイルを配信
ソース ランドサーベイ、変換操作、座標規則、高さ処理、属性辞書を特定する短いメタデータ ノートを提供します。 観察期間と品質評価を述べます。 ソース データセットと元のリファレンス定義は別々に利用できるようにします。 これにより、受信者は、土地調査の完全な履歴が含まれていると想定せずに GeoJSON を使用できます。
バージョン エクスポートと作成に使用したプロセスを保存します。 座標またはスキーマの修正が行われた場合は、影響を受けるリリースを特定します。 信頼できる GNSS GeoJSON ファイルは、土地調査の証拠を相互運用可能な交換表現に変換した文書化されたものです。 その有用性は、正しい参照処理と、有効な括弧とコンマと同様に明確なセマンティクスに依存します。
パブリケーション前の投影座標をキャッチ
ドラフト GeoJSON ポイントに、6 桁の東座標と 7 桁の北座標のように見える値が含まれているとします。 数値を交換したり、便利な要素で割ったりするのではなく、ソース CR を停止して確認してください。 ファイルには、フォーマットの地理的規則に変換されていない投影された座標が含まれている可能性があります。 ジオメトリ タイプを変更したり、CRS ラベルを追加しても、標準の不一致は解決しません。
正しく参照されたソース データセットに戻り、文書化された変換を実行します。 いくつかの既知のポイントをテストし、エクスポート後に属性を比較します。 修正を説明するのに役立つ場合は、拒否されたドラフトを課題レコードに保存しますが、検証済みのファイルのみを公開します。 この単純な境界チェックにより、シンタックス的に有効な 交換用ファイルが、根本的に解釈できない位置をダウンストリーム Web マップに持ち込むことを防ぎます。
改訂されたファイルに意図された機能数と安定した識別子が含まれていることを確認してください。特に、エクスポートが別の作業層から再作成された場合はなおさらです。 正しい座標変換は、間違ったサブセットをエクスポートすることを防ぎません。 複数のレコードをソースと比較し、完全な範囲を確認します。 リリースで、変換設定と検証結果を維持します。 これにより、1 回限りの修正が反復可能なエクスポート プロセスに変わり、将来のオペレーターは、ワーキング フォルダーに残っている可能性のある拒否されたドラフトから権威あるソースを区別するのに役立ちます。
実践チェックリスト
- 投影されたデータを WGS84 経度緯度に変換します。
- 原因不明の 3 番目の値を使用する代わりに、高さ処理を文書化します。
- 実際の受信アプリケーションで検証します。
