GeoXMind

GeoJSON 是面向 Web 的地理对象交换格式

依据 RFC 7946 说明 GeoJSON 对几何、坐标、边界框和坐标参考的约束及使用边界。

GeoJSON 是面向 Web 的地理对象交换格式

GeoJSON 用 JSON 对象交换地理要素和几何。RFC 7946 规定了它的对象类型、坐标顺序、坐标参考和互操作边界，使浏览器、服务端与地理工具能够在不共享专用二进制格式的情况下传递空间数据。它适合网络交换，但不是保存任意坐标系统、拓扑关系或海量数据的万能容器。

对象类型构成清晰的层次

GeoJSON 对象必须有 type 成员。几何对象包括 Point、MultiPoint、LineString、MultiLineString、Polygon、MultiPolygon 和 GeometryCollection。它们通过 coordinates 或 geometries 描述空间形状。

Feature 在几何之外增加 properties，并可带有 id。geometry 可以为 null，表示要素存在但没有可用几何。FeatureCollection 用 features 数组组织多个 Feature，适合一次传递一个要素集合。

类型层次不能随意混用。GeometryCollection 的成员是几何对象，不是 Feature；FeatureCollection 的成员是 Feature，不是裸几何。接收端应按类型校验结构，而不是只要能找到 coordinates 就接受。

properties 的业务结构由应用定义，RFC 不规定字段模式、单位或空值语义。跨系统交换时仍需要数据字典或 JSON Schema 等补充约定，说明标识、时间、分类和数值单位。

位置顺序是经度在前纬度在后

一个位置由数字数组表示，前两个元素依次是经度和纬度，或更一般地说是横轴坐标和纵轴坐标。在 RFC 7946 的地理坐标语境中，不能按照日常书写习惯把纬度放在前面。坐标顺序颠倒可能仍落在合法数值范围内，因此不一定立即报错，却会把对象放到错误地区。

第三个元素通常表示高程，但其具体解释和单位需要交换双方约定。额外元素的语义缺乏统一标准，接收软件也可能忽略。若业务依赖时间、测量误差或其他维度，更稳妥的做法是把它们作为有明确定义的属性交换。

LineString 至少需要形成一条位置序列。Polygon 由线性环数组构成，首尾位置应相同；第一个环表示外环，后续环表示孔。环方向在规范中有推荐规则，但解析器为了兼容可能不会仅因方向相反就拒绝数据。生产系统仍应输出一致方向并校验闭合、有效性和自相交。

坐标参考被限定为 WGS 84

RFC 7946 使用 WGS 84 地理坐标，经纬度以十进制度表达。旧版 GeoJSON 曾出现自定义 crs 成员，但现行 RFC 删除了替代坐标参考系的机制。把投影坐标写入 coordinates 再附加私有 crs 字段，不属于标准互操作行为。

源数据若处于 Web Mercator、地方投影或工程坐标系，应在输出前执行明确的坐标操作，并确认轴顺序、基准转换和有效区域。仅把元数据标签改成 WGS 84 不会改变数值本身。

WGS 84 的经纬坐标不意味着线段在所有应用中自动成为大地线，也不意味着平面几何运算天然准确。规范把两个位置之间的线段定义为特定的笛卡尔直线插值方式；跨大范围的距离、面积和路径计算仍要由具备相应测地语义的软件处理。

反经线需要在交换前处理

跨越正负 180 度经线的几何容易在平面显示中绕地球长边连接。RFC 建议切分跨越反经线的几何，使各部分不直接跨越该边界。一个原本的 Polygon 可能因此表达为 MultiPolygon，一条线也可能成为 MultiLineString。

切分不仅影响显示，也影响包围盒和空间查询。若不处理，最小经纬范围可能看起来覆盖几乎整个世界，使地图缩放、索引筛选和范围统计失真。切分后应保留业务标识，确保多个几何部分仍属于同一要素。

极区附近同样要谨慎。经度在极点处缺乏通常方向意义，常规二维包围盒难以表达球面邻近关系。GeoJSON 可以传递坐标，但并不替应用解决所有球面拓扑问题。

边界框是提示而不是几何替代

GeoJSON 对象可带 bbox 成员，按各维最小值后接各维最大值的顺序排列。它可以帮助客户端快速定位范围或做初步筛选，但不能替代对象的真实几何，也不能证明拓扑关系。

跨反经线的边界框允许东侧经度小于西侧经度，以表达较短的跨线范围。若软件只按普通最小值和最大值理解，就可能得到相反区域。交换双方需要测试这一边界情形。

由数据计算出的边界框应与几何保持一致。几何更新后忘记更新 bbox 会产生缓存、视图和筛选错误。若无法可靠维护，省略边界框通常比提供过期值更安全。

精度、体积与安全需要约束

增加小数位只会增大文件，不会恢复源数据不存在的测量精度。经纬度保留多少位，应结合原始分辨率、定位精度和隐私要求决定。过度精细的坐标可能泄露敏感位置，也可能让用户误以为数据比实际更准确。

大型 FeatureCollection 需要完整解析、传输和内存管理，复杂多边形还会增加渲染成本。大数据发布可采用分页、空间切片、流式格式或服务查询，让客户端只接收当前范围需要的要素。是否仍使用 GeoJSON，应由数据量和交互方式决定。

解析端要限制嵌套深度、坐标数量和属性大小，并把业务属性视为不可信输入。JSON 本身不允许执行代码，但属性内容进入 HTML、日志或查询时仍需对应的转义和校验。

GDAL 等工具能读取和写出 GeoJSON，并处理坐标转换、字段映射和几何类型。实际行为受驱动和版本影响，命令行或程序流程应记录版本、源参考系、目标参考系、精度和无效几何处理方式。互操作不是文件能够打开就结束，还要验证坐标位置、属性类型、空值和边界对象。

资料依据