为何GeoJSON采用数组而非带键对象存储坐标？

首先看GeoJSON官网给出的示例：

{
  "type": "Feature",
  "geometry": {
    "type": "Point",
    "coordinates": [125.6, 10.1]
  },
  "properties": {
    "name": "Dinagat Islands"
  }
}

其中coordinates字段要求经度（longitude）和纬度（latitude）分别位于数组的第一个和第二个索引位置。针对这一设计，我有以下困惑：

• 经度与纬度并非同一概念，从纯编程角度看，将二者放在同一列表中似乎不合逻辑，尽管这种形式类似传统坐标表示。
• 使用列表的索引访问变量比通过对象中清晰标记的键更易出现人为错误。我曾协助一位同时使用Leaflet、ArcGIS和GeoJSON的开发者，他就误将经度和纬度的索引弄反，且其中一个库对经纬度的顺序要求相反，加剧了混淆。若用带键对象存储，则不会出现此类问题（除非在部分语言中通过索引访问键，但这是普遍避免的不良实践）。
• 从性能角度看，GeoJSON大多通过JavaScript映射类库处理。查阅资料发现，JavaScript数组与对象的性能差异并不显著，不足以成为牺牲语义性的理由。

设计决策原因与数组存储优势 #

1. 遵循地理领域传统惯例
   GeoJSON的坐标顺序延续了地理信息行业的长期规范——先经度后纬度的格式源自WGS84等通用坐标系的标准表示，熟悉地理数据的从业者对此已经形成共识，这样的设计能降低学习和跨系统转换的成本。

2. 提升数据紧凑性与传输效率
   数组形式比键值对对象更节省存储空间和传输带宽：比如[125.6,10.1]对比{"lon":125.6,"lat":10.1}，在包含大量点、线、面的地理数据集中，这种字节差异会被大幅放大，直接减少数据传输的负载，这对于需要频繁交换地理数据的场景来说非常关键。

3. 兼容现有GIS生态系统
   早期的GIS工具、空间数据库（如PostGIS）以及编程语言的地理处理库，几乎都采用数组/有序列表存储坐标。GeoJSON作为通用交换格式，必须适配这些现有系统才能快速推广，如果改用键值对，反而会增加与旧系统对接的转换工作量。

4. 简化空间运算逻辑
   在距离计算、投影转换等空间运算场景中，数组的固定索引顺序能让算法更简洁：很多地理算法会直接按索引读取坐标值，无需额外解析键名，在高频运算的场景下，这种简化能积累出可观的效率提升。

内容的提问来源于stack exchange，提问作者Dainank