爱囡囡，爱前端

0%

GeoJson规范（RFC 7946）全文翻译

发表于 分类于 ， ，

最近使用 GeoJson 的时候总是感觉一知半解，腾出时间来翻译一遍 GeoJson 的规范，让自己理解的更透彻些。
2015 年，国际互联网工程任务组（IETF）与最初的规范作者共同组建了一个 GeoJson 工作组(GeoJSON WG) 来标准化 GeoJSON。 RFC 7946 于 2016 年 8 月发布，取代了 2008 年的 GeoJSON规范成为 GeoJSON 格式的新标准规范。

摘要

GeoJson 是一种基于 JSON 的地理空间数据交换格式。 它定义了几种类型的 JSON 对象，以及将它们组合起来表示有关地理特征、属性和空间范围的数据的方式。 GeoJson 使用了经纬度参考系统、 WGS84 坐标系统和十进制单位。

本备忘录的状况

这是一个 Internet 标准跟踪文档。

本文档是国际互联网工程任务组(IETF)的产品。 它代表 IETF 社区的一致意见。 它已经接受了公众的审查，并且已经被美国互联网工程指导委员会批准出版。 有关互联网标准的更多资料，请参阅 RFC 7841 第 2 节。

https://tools.ietf.org/html/rfc7841#section-2

有关本文件的现状、任何勘误表，以及如何提供反馈的信息可以在http://www.rfc-editor.org/info/rfc7946获得。

著作权警告

IETF 被确认为文档作者，保留所有权利。

本文档受 BCP 78和 IETF 信托基金有关 IETF 文档的法律规定的约束，这些约束规定在本文档发布之日起生效。 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。 从此文档中提取的代码组件必须包含第 4 节中描述的简化 BSD 许可证文本，并提供的简化 BSD 许可证。

引言

GeoJson 是一种使用 JSON 编码（RFC7159）对各种地理数据结构进行编码的格式。 GeoJson 对象可以表示一个空间区域(Geometry)、一个空间有界实体(Feature)或一系列特征集合(FeatureCollection)。 GeoJson 支持以下几何类型: Point、 LineString、 Polygon、 MultiPoint、 MultiLineString、 MultiPolygon和 GeometryCollection。 特征包含一个 Geometry 对象和其他属性，而特征集合包含一个特征列表。

这种格式从最广泛的意义上讲与地理数据有关，任何具有地理空间界限的特性的东西都可能是一个特征，不管它是否是一个物理结构。 GeoJson 中的概念并不新鲜，它们来自于先前存在的开放地理信息系统标准，并且已经进行了简化，以更好地适应使用 JSON 的 WEB 应用程序开发。

GeoJson 包含了在 OpenGIS 的简单特征实现规范中定义的七种具体的几何类型: 0 维是 Point 和 MultiPoint;1 维曲线 LineString 和 MultiLineString; 2 维曲面 Polygon 和 MultiPolygon;异构的 GeometryCollection。 这些几何类型的 GeoJSON 实例类似于在同一规范中描述的二进制(WKB)和文本(WKT)。

GeoJson 还包含类型 Feature 和 FeatureCollection。 GeoJson 中的 Feature 对象包含一个 Geometry 对象，该对象具有上述几何类型之一和其他属性。 FeatureCollection 对象包含一个 Feature 对象数组。

自 2008 年首次发布GJ2008以来，GeoJSON 格式规范的流行程度一直在稳步增长。 它广泛应用于 JavaScript 网页地图库、基于 json 的文档数据库和 web API。

必需的词汇

本文件中的”必须”、”不得”、”必需”、”应当”、”不应当”、”应该”、”不应该”、”建议”、”不建议”、”可能”和”可选”等关键词应解释为RFC2119所述。

本文件中使用的约定

必须按照RFC7159的指定，将本文档中定义的任何 JSON 对象的成员的顺序视为无关的。

一些示例使用 JavaScript 语言的单行注释(/ /)和省略号(…)的组合作为作者认为不相关的内容的占位符。 当然，在试图验证相应的JSON 代码示例之前，必须删除或替换这些占位符。

本文档中的示例使用空格来帮助说明数据结构，但不是必需的。 不带引号的空格在JSON 中不重要。

GeoJson 规范

本文档取代原来的 GeoJSON 格式规范GJ2008。

定义

  • JSON，以及术语对象、成员、名称、值、数组、数字、 true、 false 和 null，将被解释为在RFC7159中的定义。
  • 在本文档中，术语“几何类型”指七个区分大小写的字符串: “ Point”、“ MultiPoint”、“ LineString”、“ MultiLineString”、“ Polygon”、“ MultiPolygon”和“ GeometryCollection”。
  • 作为另一种速记符号，术语“ GeoJSON 类型”指的是九个区分大小写的字符串: “ Feature”、“ FeatureCollection”以及上面列出的几何类型。
  • “ FeatureCollection”和“ GeometryCollection”中的“ Collection”一词对于数组成员的语义没有任何意义。 这些对象的“ features”和“ geometry”成员分别是标准的有序 JSON 数组，而不是无序集。

例子

一个 GeoJSON类型中的 FeatureCollection 类型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [102.0, 0.5]
      },
      "properties": {
        "prop0": "value0"
      }
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "LineString",
        "coordinates": [
          [102.0, 0.0],
          [103.0, 1.0],
          [104.0, 0.0],
          [105.0, 1.0]
        ]
      },
      "properties": {
        "prop0": "value0",
        "prop1": 0.0
      }
    },
    {
      "type": "Feature",
      "geometry": {
        "type": "Polygon",
        "coordinates": [
          [
            [100.0, 0.0],
            [101.0, 0.0],
            [101.0, 1.0],
            [100.0, 1.0],
            [100.0, 0.0]
          ]
        ]
      },
      "properties": {
        "prop0": "value0",
        "prop1": {
          "this": "that"
        }
      }
    }
  ]
}

译者：使用http://geojson.io/绘制图形如下：

GeoJson 文本

GeoJson 文本是 JSON 文本，由单个 GeoJSON 对象组成。

GeoJson 对象

GeoJson 对象表示一个几何对象、特征或特征集合。

  • 一个 GeoJSON 对象是一个JSON 对象。
  • 一个 GeoJSON 对象有一个名为“ type”的成员。 成员的值必须是 GeoJSON 九种类型之一。
  • 一个 GeoJSON 对象可能有一个“bbox”成员，其值必须是一个边界框数组(参见第 5 节)。
  • GeoJSON 对象可能有其他成员(见第 6 节)。

几何对象

几何对象在坐标空间中表示点、曲线和曲面。 每个 Geometry 对象都是一个 GeoJSON 对象，不管它出现在 GeoJSON 文本的哪个位置。

  • 几何对象的“type”成员的值必须是七种几何类型之一(见第 1.4 节)。
  • 除了“ GeometryCollection”以外的任何类型的 GeoJSON 几何对象都有一个名为“ coordinates”的成员。 “coordinates”成员的值是一个数组。 此数组中元素的结构由几何形状类型决定。 GeoJson 处理器可能将含有空“coordinates”数组的几何对象解释为空对象。

位置

位置是基本的几何构造。 几何对象的“coordinates”成员由以下两部分组成:

  • 在 Point 几何情况下有一个位置。
  • 在 LineString 或 MultiPoint 情况下有一个位置数组。
  • 在 Polygon 或 MultiLineString 情况下有一个 LineString 或 linear ring(见第 3.1.6 节)坐标数组。
  • 在 MultiPolygon情况下有一个 Polygon 坐标数组。

一个位置是一组数字。 必须有两个或两个以上的元素。 前两个元素是经度和纬度，或者叫做 easting 和 northing，精确地按照这个顺序使用十进制数字。 海拔或高度可作为可选的第三个要素。

实现时不应该扩展位置超过三个元素，因为额外元素的语义是不确定和模糊的。 历史上，有些实现使用第四个元素来携带线性参考度量值(有时表示为“ m”)或数字时间戳，但在大多数情况下，解析器不能正确解释这些值。 附加元素的解释和含义超出了本规范的范围，附加元素可能会被解析器忽略。

两个位置之间的直线是笛卡尔坐标系下的直线，也就是坐标系中两点之间最短的直线(见第 4 节)。

换句话说，在(lon0、 lat0)和(lon1、 lat1)之间的一条直线上的每个点不会穿过 180 度经线，这些点可以计算为

1
F(lon, lat) = (lon0 + (lon1 - lon0) * t, lat0 + (lat1 - lat0) * t)

t是大于等于 0小于等于 1的实数。 请注意，这条线可能明显不同于沿着参考椭球体曲面的测地线路径。

这同样适用于可选的高度元素，但条件是高度的方向在坐标参考系是指定的。

请再次注意，这并不意味着高度相等的曲面遵循例如水体的曲率。 同样高度的曲面也不会垂直于铅垂线。

位置和几何图形的例子见附录 a“几何示例“

Point

对于类型“ Point” ，“ coordinates”成员是一个位置。

MultiPoint

对于类型“ MultiPoint” ，“coordinates”成员是位置数组。

LineString

对于类型“ LineString” ，“ coordinates”成员是两个或多个位置的数组。

MultiLineString

对于类型“ MultiLineString” ，“ coordinates”成员是 ”LineString 坐标数组“的数组。

Polygon

为了指定多边形特有的约束，引入线性环的概念是有用的:

  • 线性环是具有四个或更多位置的闭合 LineString。
  • 第一个和最后一个位置是相同的，它们必须包含相同的值; 它们的表示也应该相同。
  • 线性环是曲面的边界或曲面上孔的边界。
  • 线性环必须遵循右手法则，也就是说，外环为逆时针方向，孔为顺时针方向。

注: GJ2008规范没有讨论线性环绕顺序。 为了向后兼容，解析器不应该拒绝不遵循右边规则的多边形。

虽然线性环没有被显式地表示为 GeoJSON 几何类型，但它导致了 Polygon 几何类型定义的规范化表述如下:

  • 对于类型“Polygon” ，“coordinates”成员必须是一个”线性环坐标数组“组成的数组。
  • 对于多边形有一个以上的环，第一个必须是外环，其他的必须是内环。 外环与表面形成边界，内环(如果存在)与表面形成边界孔。

MultiPolygon

对于类型“ MultiPolygon” ，“ coordinates”成员是”Polygon 坐标数组“组成的数组。

GeometryCollection

类型为“ GeometryCollection”的 GeoJSON 对象是一个几何对象。 Geometrycollection 有一个名为“ geometries”的成员。 “geometries”的值是一个数组。 这个数组的每个元素都是一个 GeoJSON 几何对象。 这个数组可能是空的。

与上面描述的其他几何类型不同，GeometryCollection 可以是较小几何对象的异构组合。 例如，小写罗马字体“ i”形状的几何对象可以由一个 Point 和一个 LineString 组成。

Geometrycollections 有不同于单一类型的几何对象(Point、 LineString 和 Polygon)和多部分几何对象(MultiPoint、 MultiLineString 和 MultiPolygon)的语法，但没有不同的语义。 虽然 GeometryCollection 对象没有“coordinates”成员，但它确实有坐标:，其所有部分的坐标都属于该集合。 Geometrycollection 的“geometries”成员描述了这个组合的各个部分。 实现不应该对“geometries”数组应用任何附加语义。

为了最大化互用性，实现应该避免嵌套的 GeometryCollections。 此外，当可以使用单个部件或多部件类型的单个对象(MultiPoint、 MultiLineString 或 MultiPolygon)时，应避免使用由单个部件或单个类型的多个部件组成的 GeometryCollections。

180 度经线切割

在表示跨越 180 度经线的特征时，通过修改它们的几何形状可以提高互操作性。 任何穿过 180 度经线的几何体都应该被切割成两部分，这样任何一部分的表示都不会穿过 180 度经线。

例如，一条从北纬 45 度，东经 170 度延伸到北纬 45 度，西经 170 度的直线应该被切成两段并表示为 MultiLineString。

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "type": "MultiLineString",
  "coordinates": [
    [
      [170.0, 45.0],
      [180.0, 45.0]
    ],
    [
      [-180.0, 45.0],
      [-170.0, 45.0]
    ]
  ]
}

译者：使用http://geojson.io/绘制图形如下：

一个从北纬 40 度，东经 170 度到北纬 50 度，西经 170 度的矩形应该被切割成两个并表示为一个多边形。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
{
  "type": "MultiPolygon",
  "coordinates": [
    [
      [
        [180.0, 40.0],
        [180.0, 50.0],
        [170.0, 50.0],
        [170.0, 40.0],
        [180.0, 40.0]
      ]
    ],
    [
      [
        [-170.0, 40.0],
        [-170.0, 50.0],
        [-180.0, 50.0],
        [-180.0, 40.0],
        [-170.0, 40.0]
      ]
    ]
  ]
}

译者：使用http://geojson.io/绘制图形如下：

不确定性和精确性

在RFC5870中规定，坐标位置上的数值的位数不能被解释为不确定度级别。

特征对象

一个特征对象表示一个空间上有界的对象。 每个特征对象都是一个 GeoJSON 对象，不管它出现在 GeoJSON 文本的哪个位置。

  • 一个特征对象有一个值为“ Feature”的“type”成员。
  • 一个特征对象有一个名为“ geometry”的成员。 geometry成员的值应该是上面定义的几何对象，或者在功能未定位的情况下为JSON 空值。
  • 一个特征对象有一个名为“properties”的成员。 属性成员的值是一个对象(任何JSON 对象或 JSON 空值)。
  • 如果一个特征有一个常用的标识符，那么这个标识符应该包含在特征对象的名为“ id”的成员中，并且这个成员的值是 JSON 字符串或数字。

特征集合对象

类型为“ FeatureCollection”的 GeoJSON 对象是 FeatureCollection 对象。 FeatureCollection 对象有一个名为“ features”的成员。 “features”的值是一个 JSON 数组。 数组的每个元素都是上面定义的特征对象。 这个数组可能为空。

坐标参考系统

所有 GeoJSON 坐标的坐标参考系统是同一个地理经纬度坐标参考系统，使用WGS84基准，以十进制经纬度为单位。 这相当于开放地理空间协会标识的坐标引用系统 URN: OGC: def: crs: OGC: : CRS84。 一个可选的第三位元素应该是 WGS 84 参考椭球体以上或以下的高度（米）。 在没有高程值的情况下，对高度或深度敏感的应用程序应该将第三位元素解释为在该坐标的地面或海平面高度。

注: 备选坐标参考系统在GJ2008中有规定，但已从本规范版本中删除，因为使用不同的坐标参考系统，特别是以 GJ2008 中规定的方式已证明存在互用性问题。 一般来说，GeoJSON 处理软件不需要访问坐标参考系统数据库或网络访问坐标参考系统转换参数。 然而，如果所有参与方事先都有安排而不会有数据被误解的风险，可以使用其他的坐标参考系统。

边界框

GeoJson 对象可能有一个名为“bbox”的成员，包含关于其几何对象、特征对象或特征对象集合的坐标范围的信息。 bbox 成员的值必须是一个长度为 2 * n 的数组，其中 n 是所包含的几何图形中表示的维数，最西南点的坐标轴后跟最东北点的坐标轴。bbox 的坐标轴顺序遵循几何图形的坐标轴顺序。

“bbox”值定义沿着固定的经度、纬度和海拔线作为边缘的形状。

特征对象中的2D bbox 示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
  "type": "Feature",
  "bbox": [-10.0, -10.0, 10.0, 10.0],
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [
        [-10.0, -10.0],
        [10.0, -10.0],
        [10.0, 10.0],
        [-10.0, -10.0]
      ]
    ]
  }
  //...
}

特征集合中 2D bbox 成员示例：

1
2
3
4
5
6
7
{
  "type": "FeatureCollection",
  "bbox": [100.0, 0.0, 105.0, 1.0],
  "features": [
    //...
  ]
}

带有 100m 深度的 3D bbox成员示例：

1
2
3
4
5
6
7
{
  "type": "FeatureCollection",
  "bbox": [100.0, 0.0, -100.0, 105.0, 1.0, 0.0],
  "features": [
    //...
  ]
}

连接线

边界框的四条线完全在坐标参考系中定义。也就是说，组成一个以“西”、“南”、“东”和“北”值为边界的框（四至），最北线上的每一点都可以表示为：

1
2
(lon, lat) = (west + (east - west) * t, north)
0 <= t <= 1

180 度经线

参照一组位于斐济群岛上的 Point 特征对象，它横跨在南纬 16 度到南纬 20 度之间。 包含这些特征的框的西南角是在南纬 20 度 和东经 177 度，西北角是在南纬 16 度和西经 178 度。 这个跨越180 经度线的特征的 GeoJSON 包围框是：

1
"bbox": [177.0, -20.0, -178.0, -16.0]

跨越了5 经度。

同一纬度带的互补包围框，不穿过 180 度经线：

1
"bbox": [-178.0, -20.0, 177.0, -16.0]

跨越了 355 经度。

东北角的纬度总是大于西南角的纬度，但是穿过 180 度经线的边框的东北角经度小于西南角的经度。

两极

一个包含北极的包围框从[最小纬度，西经 180 度]的西南角延伸到[北纬 90 度，东经 180 度]的东北角。在地球仪上看，这个包围框近似于一个被纬线包围着的球帽。

1
"bbox": [-180.0, minlat, 180.0, 90.0]

一个包含南极的包围框从[南纬 90 度，西经 180 度]的西南角延伸到[最大纬度，南纬 180 度]的东北角。

1
"bbox": [-180.0, -90.0, 180.0, maxlat]

一个刚刚接触到北极的包围框，在地球仪上观察时形成一个近似球形的帽子，从最小纬度和最西经度的西南角延伸到北纬 90 度和最东经度的东北角。

1
"bbox": [westlon, minlat, eastlon, 90.0]

类似地，一个刚刚接触到南极的包围框，在地球仪上观察时，形成一个近似球帽的切片，在 GeoJSON 中有以下表示。

1
"bbox": [westlon, -90.0, eastlon, maxlat]

实现时不能使用大于 90 或小于-90 的纬度值来表示一个范围。

扩展 GeoJson

外部成员

本规范中未描述的成员(“外部成员”)可以在 GeoJSON 文档中使用。 注意，对外部成员的支持可能因具体实现而异，并且没有为外部成员定义规范的处理模型。 因此，过于依赖外部成员的实现可能会减少与其他实现的互用性。

例如，在下面显示的(删减的) 特征对象中：

1
2
3
4
5
6
7
{
       "type": "Feature",
       "id": "f1",
       "geometry": {...},
       "properties": {...},
       "title": "Example Feature"
   }

“ title” : “ Example Feature”的名称 : 值对是外部成员。 当外部成员的值为对象时，该对象的所有后代成员本身都是外部成员。GeoJson 语义不适用于外部成员及其后代，无论它们的名称和值如何。 例如，在下面的(删减的) 特征对象中：

1
2
3
4
5
6
7
8
9
10
11
12
13
{
    "type": "Feature",
    "id": "f2",
    "geometry": {...},
    "properties": {...},
    "centerline": {
        "type": "LineString",
        "coordinates": [
            [-170, 10],
            [170, 11]
        ]
    }
}

“centerline”成员不是 GeoJSON 几何对象。

GeoJson 类型不可扩展

实现时不能扩展 GeoJSON 类型的固定集合: FeatureCollection、 Feature、 Point、 LineString、 MultiPoint、 Polygon、 MultiLineString、 MultiLineString、 MultiPolygon、 MultiPolygon和 GeometryCollection。

GeoJson 成员和类型的语义不可变

实现时不能更改 GeoJSON 成员和类型的语义。

GeoJson 的“coordinates”和“geometries”成员定义几何对象。 FeatureCollection 和 Feature 对象不能包含“coordinates”或“geometries”成员。

GeoJson 的“geometry”和“properties”成员定义一个特征对象、特征集合对象和几何对象，不能包含一个“geometry”或“properties”成员。

GeoJson“ features”成员定义一个特征集合对象。 特征对象和几何对象不能包含一个“features”成员。

版本标识

GeoJson 格式可以像这里定义的那样进行扩展，但是没有定义明确的版本控制方案。 改变 GeoJSON 成员的语义或者修改格式的规范不会创建这种格式的新版本; 相反，它定义了一种全新的格式，不能被标识为 GeoJSON。

映射到‘geo’URIs

“ geo” URIs RFC5870定义的地理位置和精确位置，可以映射到GeoJSON 几何对象。

对于本节，如 RFC5870 中所示，“lat”、“ lon”、“ alt”和“ unc”分别是‘ geo’ URIs 中纬度、经度、海拔和不确定值的占位符。

一个具有两个坐标和一个不确定性(u)参数的“ geo” URIs，可以和一个 GeoJSON Point 几何图形互相映射。 GeoJson Point 总是转换为没有不确定性参数的‘ geo’ URIs。

1
2
3
4
5
6
7
8

'geo' URI:

geo:lat,lon

GeoJSON:

{"type": "`Point`", "coordinates": [lon, lat]}

在 'geo’ URIs 和 GeoJSON 之间指定海拔的映射如下所示：

1
2
3
4
5
6
7
8

'geo' URI:

geo:lat,lon,alt

GeoJSON:

{"type": "`Point`", "coordinates": [lon, lat, alt]}

GeoJson 没有不确定性的概念; 因此不确定的 'geo' URIs 无法被映射到 GeoJSON 几何图形。

安全考虑

GeoJson 有 JSON 内容类型所共有的安全问题。 详情请参阅RFC7159 ，第 12 节。 GeoJson 不提供可执行内容。 GeoJson 不提供隐私或完整性服务。

如果敏感数据需要隐私或完整性保护，那么传输必须提供这些保护——例如，传输层安全性(TLS)或 HTTPS。 在某些情况下，存储的数据需要保护，这超出了本文档的范围。

与其他地理数据格式一样，如KMLv2.2，提供关于敏感人物、动物、栖息地和设施的位置的详细信息可能会使它们受到未经授权的跟踪或伤害。 数据提供者应当认识到，如果匿名数据集中的位置未充分模糊，就有可能无意识地识别出个人。数据提供者也应当认识到位置模糊的有效性受到若干因素的限制，不太可能成为抵御攻击的有效防御RFC6772。

互用性考虑因素

I-JSON

GeoJson 文本应遵循 Internet JSON (I-JSON)RFC7493的约束，以实现最大程度的互用性。

坐标精度

GeoJson 文本的字节大小是一个主要的互用性考虑因素，坐标值的精度对文本的大小有很大的影响。 通过将坐标精度从小数点后 6 位提高到小数点后 15 位，一个包含许多详细多边形的 GeoJSON 文本几乎可以膨胀两倍。 对于以度数为单位的地理坐标，6位小数(例如 sprintf 中常见的默认位置)大约等于 10 厘米，这个精度远低于目前的 GPS 系统。 实现时应该考虑使用超出必要精度的代价。

此外，WGS 84基准面是大地水准面的一个相对粗略的近似值，相对于平行于地球平均海平面的表面，高度变化可达5 米(但一般在 2 至 3 米之间)。

IANA 考虑

GeoJson 文本的媒体类型是“ application / geo + json” ，并在RFC6838中描述的“ Media Types”注册表中注册。 同一注册表中的“ application / vnd.geo + json“ 应该将其状态更改为“OBSOLETED” ，并指向媒体类型“ application / geo + json”和添加到此 RFC 的引用。

  • 类型名称: application
  • 子类型名称: geo + json
  • 所需参数: n/a
  • 可选参数: n/a
  • 编码考虑因素: 二进制
  • 安全考虑因素: 参见上文第 10 节
  • 互用性考虑因素: 参见上文第 11 节
  • 发布的规范: RFC7946
  • 使用此媒体类型的应用程序: 目前没有已知的应用程序使用此媒体类型。 这种媒体类型适用于目前使用“ application / vnd.geo + json”或“ application / json”媒体类型的 GeoJSON 应用程序，其中包括几个类别: web 地图、地理空间数据库、地理数据处理 api、数据分析和存储服务以及数据传输。

附加信息:

  • 幻数: n / a
  • 文件扩展名:.json .geojson
  • Macintosh 文件类型代码: n / a
  • 对象标识符: n / a
  • Windows 剪贴板名称: GeoJSON
  • Macintosh 统一类型标识符: public.geojson conforms to public.json
  • 联系人详细信息: Sean Gillies (Sean.Gillies@gmail. com)
  • 预期用途: COMMON
  • 使用限制: 无
  • 作者: 见RFC7946“作者地址”一节。
  • 变更管理者: 互联网工程任务组

参考文献

标准参考资料

  • [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.

  • [RFC6838] Freed, N., Klensin, J., and T. Hansen, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, http://www.rfc-editor.org/info/rfc6838.

  • [RFC7159] Bray, T., Ed., “The JavaScript Object Notation (JSON) Data Interchange Format”, RFC 7159, DOI 10.17487/RFC7159, March 2014, http://www.rfc-editor.org/info/rfc7159.

  • [RFC7493] Bray, T., Ed., “The I-JSON Message Format”, RFC 7493, DOI 10.17487/RFC7493, March 2015, http://www.rfc-editor.org/info/rfc7493.

  • [WGS84] National Imagery and Mapping Agency, “Department of Defense World Geodetic System 1984: Its Definition and Relationships with Local Geodetic Systems”, Third Edition, 1984.

参考资料

  • [GJ2008] Butler, H., Daly, M., Doyle, A., Gillies, S., Schaub, T., and C. Schmidt, “The GeoJSON Format Specification”, June 2008.

  • [KMLv2.2] Wilson, T., “OGC KML”, OGC 07-147r2, Version 2.2.0, April 2008.

  • [RFC5870] Mayrhofer, A. and C. Spanring, “A Uniform Resource Identifier for Geographic Locations (‘geo’ URI)”, RFC 5870, DOI 10.17487/RFC5870, June 2010, http://www.rfc-editor.org/info/rfc5870.

  • [RFC6772] Schulzrinne, H., Ed., Tschofenig, H., Ed., Cuellar, J.,Polk, J., Morris, J., and M. Thomson, “Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information”, RFC 6772, DOI 10.17487/RFC6772, January 2013, http://www.rfc-editor.org/info/rfc6772.

  • [RFC7464] Williams, N., “JavaScript Object Notation (JSON) Text Sequences”, RFC 7464, DOI 10.17487/RFC7464, February 2015, http://www.rfc-editor.org/info/rfc7464.

  • [SFSQL] OpenGIS Consortium, Inc., “OpenGIS Simple Features Specification For SQL Revision 1.1”, OGC 99-049, May 1999. [Sweeney] Sweeney, L., “k-anonymity: a model for protecting privacy”, International Journal on Uncertainty, Fuzziness and Knowledge-based Systems 10 (5), 2002; 557-570, DOI 10.1142/S0218488502001648, 2002.

  • [WFSv1] Vretanos, P., “Web Feature Service Implementation Specification”, OGC 04-094, Version 1.1.0, May 2005.

附录 A. 几何对象实例

下面的每个示例都表示一个有效且完整的 GeoJSON 对象

Points

点坐标按x、 y 顺序排列(向东、向北为投影坐标，经度和纬度为地理坐标) :

1
2
3
4
{
  "type": "Point",
  "coordinates": [100.0, 0.0]
}

译者：使用http://geojson.io/绘制图形如下：

LineStrings

Linestring 的坐标是一个位置数组(见第 3.1.1 节)

1
2
3
4
5
6
7
{
  "type": "LineString",
  "coordinates": [
    [100.0, 0.0],
    [101.0, 1.0]
  ]
}

译者：使用http://geojson.io/绘制图形如下：

Polygons

一个多边形的坐标是一个 linear ring 数组(见 3.1.6 节)的坐标数组。 数组中的第一个元素表示最外环。 任何后续元素都表示内部环(或孔)。

没有孔的情况:

1
2
3
4
5
6
7
8
9
10
11
12
{
  "type": "Polygon",
  "coordinates": [
    [
      [100.0, 0.0],
      [101.0, 0.0],
      [101.0, 1.0],
      [100.0, 1.0],
      [100.0, 0.0]
    ]
  ]
}

译者：使用http://geojson.io/绘制图形如下：

内部有孔的情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "type": "Polygon",
  "coordinates": [
    [
      [100.0, 0.0],
      [101.0, 0.0],
      [101.0, 1.0],
      [100.0, 1.0],
      [100.0, 0.0]
    ],
    [
      [100.8, 0.8],
      [100.8, 0.2],
      [100.2, 0.2],
      [100.2, 0.8],
      [100.8, 0.8]
    ]
  ]
}

译者：使用http://geojson.io/绘制图形如下：

MultiPoints

MultiPoints 的坐标是一个位置数组:

1
2
3
4
5
6
7
{
  "type": "MultiPoint",
  "coordinates": [
    [100.0, 0.0],
    [101.0, 1.0]
  ]
}

译者：使用http://geojson.io/绘制图形如下：

MultiLineStrings

Multilinestring 的坐标是一个 ”LineString 坐标数组“组成的数组:

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "type": "MultiLineString",
  "coordinates": [
    [
      [100.0, 0.0],
      [101.0, 1.0]
    ],
    [
      [102.0, 2.0],
      [103.0, 3.0]
    ]
  ]
}

译者：使用http://geojson.io/绘制图形如下：

MultiPolygons

MultiPolygons 的坐标是”Polygon 坐标数组“组成的数组:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
{
  "type": "MultiPolygon",
  "coordinates": [
    [
      [
        [102.0, 2.0],
        [103.0, 2.0],
        [103.0, 3.0],
        [102.0, 3.0],
        [102.0, 2.0]
      ]
    ],
    [
      [
        [100.0, 0.0],
        [101.0, 0.0],
        [101.0, 1.0],
        [100.0, 1.0],
        [100.0, 0.0]
      ],
      [
        [100.2, 0.2],
        [100.2, 0.8],
        [100.8, 0.8],
        [100.8, 0.2],
        [100.2, 0.2]
      ]
    ]
  ]
}

译者：使用http://geojson.io/绘制图形如下：

GeometryCollections

Geometrycollection 的“ Geometry”数组中的每个元素都是上面描述的几何对象之一:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
  "type": "GeometryCollection",
  "geometries": [
    {
      "type": "Point",
      "coordinates": [100.0, 0.0]
    },
    {
      "type": "LineString",
      "coordinates": [
        [101.0, 0.0],
        [102.0, 1.0]
      ]
    }
  ]
}

译者：使用http://geojson.io/绘制图形如下：

附录 B. 对之前 GeoJSON 格式规范的修改

本附录简要总结了 2008 规范GJ2008中的非编辑性变更。

规范更改

  • 取消了坐标参考系统的规格，即不再使用GJ2008的“ crs”成员。
  • 在没有高程值的情况下，对高度或深度敏感的应用程序应将第三个位置解释为在当地的地面或海平面(见第 4 节)。
  • 实现时不应扩展位置数组超过 3 个元素(参见3.1.1 节)。
  • 两个位置之间的直线是笛卡尔坐标直线(见3.1.1 节)。
  • 多边形环必须遵循右手定位法则(逆时针方向外环，顺时针内环)。
  • “ bbox”数组的值是“[ west，south，east，north ]” ，而不是“[ minx，miny，maxx，maxy ]”(参见第 5 节)。
  • Feature 对象的“ id”成员是一个字符串或数字(见第 3.2 节)。
  • 可以使用扩展，但不能改变 GeoJSON 成员和类型的语义(参见第 6 节)。
  • GeoJSON 对象不能包含其他类型的定义成员(参见第 7.1 节)。
  • GeoJSON 的媒体类型是“ application / geo + json”。

增加 GeoJSON 文本的定义

  • 添加了映射到 geo’ URIs 的规则。
  • 增加了I-JSON RFC7493限制的建议。
  • 提醒实施者注意坐标精度过高对互用性的影响。
  • 注意到几何集合的互用性问题。 这些对象应该谨慎使用(见3.1.8 节)。

附录 C. GeoJSON 文本序列

在这个规范中定义的所有 GeoJSON 对象—— FeatureCollection、 Feature 和 Geometry ——只包含一个 JSON 对象。 然而，在某些情况下，应用程序可能需要表示这些对象的集合或序列(超过在 FeatureCollection 中对 Feature 对象的分组) ，例如，为了有效地“stream”大量的 Feature 对象。 这种集合或序列的定义超出了本规范的范围。

如果需要这样的表示，则需要能够表示这些集合或序列的新媒体类型。 在定义这样的媒体类型时，基于“ JSON 文本序列(JSON)”RFC7464可能是有用的，这样规范就不需要考虑如何表示多个JSON 对象，只需定义它如何应用于GeoJSON 对象。

鸣谢

在 2015 年 10 月之前，GeoJSON 格式是GeoJSON 邮件列表的讨论结果，在 2015 年 10 月之后，在IETF的 GeoJSON 工作组 中，GeoJSON 格式是 http://lists.GeoJSON.org/listinfo.cgi/ ，GeoJSON-GeoJSON.org 的讨论结果。

本文档中的材料是根据 http://geojson.org/geojson-spec.html 修改而来的，http://creativecommons.org/licenses/by/3.0/us/ 授权许可。

作者联系方式

翻译完成

翻译工作大部分是机翻完成，然后根据自己的理解做了修改和补充。

👆 全文结束，棒槌时间到 👇