GNSS GeoJSON 导出质量：坐标、几何和出处
通过转换到所需的地理参考并保留土地测量属性的含义来创建可互操作的 GeoJSON。
了解 GeoJSON 标准化的内容
GeoJSON 是一种基于文本的地理特征及其属性的格式。 在 RFC 7946 下，位置按顺序使用 WGS84 经度和纬度以十进制数。 这是一个特定的交换约定，不允许将任何坐标对放置在几何数组中。 在符合标准的出口之前，预计的东方和北方必须进行改造。
在导出之前确定文件的源引用和预期用途。 当地的土地调查网格、投影的 CRS 和地理参考资料可以通过不同的值来描述同一地点。 保留原始土地调查数据集和参考元数据。 GeoJSON 对交换和网络测绘很有用，但当该档案包含额外的土地调查证据时，它不应取代完整的观测档案。
转换值而不是重新标记它们
将正确的源 CRS 分配给源数据集，然后对 GeoJSON 地理参考执行适当的转换。 记录所使用的操作，包括相关的型号版本和适用的时代信息。 将 WGS84 标签分配给不变的投影坐标不会转换它们。 测试代表在转换后的已知点。
在导出边界处显式检查轴顺序。 一些软件和参考定义在内部使用不同的约定。 交付的 GeoJSON 坐标数组必须遵循格式的经纬度顺序。 在错误的半球中绘制的点是一个明显的警告，但更微妙的轴或参考错误仍然可以产生看起来似是而非的几何形状。 数字范围检查与记录的参考处理一起有用。
定义第三个坐标的作用
RFC 7946 允许表示相对于 WGS84 椭球的高度的可选的第三位置值。 不要在该插槽中默默地放置一个地理衍生的工程高程，并假设每个消费者都会正确解释它。 如果项目的高程有另一个参考，请将其保留为带有单元和垂直参考的明确命名的属性，或使用明确同意的交换工作流。
将缺失的高度与零区分开来。 零值是一个实坐标值，而不是未知高程的通用标记。 查看接收应用程序是否使用或忽略第三个坐标。 出口应该诚实地传达土地调查的高度，而不是仅仅因为源点层是三维的而添加一个无法解释的数字。
验证几何结构和特征意义
检查每个要素是否使用预期的几何类型和有效的坐标嵌套。 点资产不应意外成为一条线，并且在没有明确目的的情况下，不应将被调查的边界缩减为其质心。 对于多边形，通过合适的验证工具查看闭包和拓扑。 技术有效性并不能证明几何代表正确的物理对象。
将地理要素的数量及标识符与源数据核对。确认多部件对象、空几何以及无法进入的区域均按项目规则处理。不要在没有说明的情况下删除难以处理的记录。为排除或转换的要素保留问题清单，使其他审查人员能够理解交换文件与完整测量数据库存在差异的原因。
继续学习 为 GNSS 点观测设计地理数据库模式
保留有用的属性和标识符
在属性中使用稳定的特征和观测标识符。 将文本标识符保留为前导零或长代码的文本。 包括适合接收工作流的观察日期、方法和质量状态。 不要公开其含义不明确的通用准确性属性； 记录值是工具估算、独立检查结果还是项目分类。
保持属性简洁，但足以解释几何图形。 照片和未处理的 GNSS 观测数据可能保留在另一个档案中，通过标识符或商定的参考资料链接。 在接收应用程序中测试特殊字符和空值。 如果资产标识符更改类型或未知值被转换为明显测量的零，则有效的 JSON 文件仍可能失去操作意义。
平衡坐标精度和文件大小
根据预期用途和支持的证据选择输出小数精度。 更多的数字不会产生更高的准确性。 过多的舍入会改变几何形状，而不必要的数字会放大文件并暗示不必要的细节。 测试所选精度对代表点和边界的影响，而不是在不考虑项目的情况下应用通用规则。
对于大型数据集，请查看 GeoJSON 是否是每次使用最实用的交付格式。 浏览器交换层和权威土地调查档案可以是不同的产品。 以合适的格式保留完整的数据集，并创建有目的的 GeoJSON 导出。 这避免了牺牲引用或观察元数据，以使一个文件服务于每个工作流。
在独立使用者中测试文件
验证 JSON 语法、几何结构和坐标范围，然后在预期的 Web 或 GIS 应用程序中打开该文件。 将已知位置、标识符和属性与源进行比较。 重新导入样本并检查几何值。 成功的导出消息不会说明接收系统按预期解释文件。
具体检查第三坐标处理、空值和附件引用。 查看文件的范围和异常坐标边界附近的任何特征。 与版本保持验证结果。 测试应确认标准符合性和项目的数据含义，因为这些是相关但不同的要求。
提供出处的交换文件
提供简短的元数据说明，标识源土地测量、转换操作、坐标约定、高度处理和属性字典。 陈述观察期和质量评估。 将源数据集和原始参考定义分开使用。 这使收件人在不包含完整的土地调查历史的情况下使用 GeoJSON。
版本 导出并保留用于创建它的进程。 如果进行了坐标或模式校正，请识别受影响的版本。 可靠的 GNSS GeoJSON 文件是将土地调查证据转换为可互操作的交换表示的记录在案。 它的有用性取决于正确的参考处理和清晰的语义，以及有效的括号和逗号。
继续学习 为 GNSS 点观测设计地理数据库模式
在发布前捕获投影坐标
假设 GeoJSON 点草图包含看起来像六位数东坐标和七位数北坐标的值。 停止并查看源 CRS，而不是交换数字或将它们除以一个方便的因素。 该文件可能包含尚未转换为格式的地理约定的投影坐标。 更改几何类型或添加 CRS 标签并不能解决该标准不匹配的问题。
返回到正确引用的源数据集并执行记录的转换。 测试几个已知点并在导出后比较属性。 如果有助于解释更正，但仅释放已验证的文件，请在问题记录中保留被拒绝的草稿。 这种简单的边界检查阻止了语法上有效的交换文件将根本无法解释的位置携带到下游的 Web 地图中。
检查修改后的文件是否包含预期的特征计数和稳定的标识符，特别是如果导出是从不同的工作层重新创建的。 正确的坐标转换不能防止导出错误的子集。 将几条记录与来源进行比较并查看完整范围。 将转换设置和验证结果与版本保持一致。 这将一次性更正变成可重复的导出过程，并帮助未来的操作员将权威来源与可能仍保留在工作文件夹中的被拒绝的草稿区分开来。
实用检查清单
- 将投影数据转换为 WGS84 经纬度。
- 文档高度处理而不是使用无法解释的第三个值。
- 在实际接收应用程序中进行验证。
