You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Spec text: allow <authority>:<code> crs in 2.0, mirror Parquet field
Updates the column-metadata table and the crs / crs Parquet property
subsections to:
- permit either inline PROJJSON or an <authority>:<code> string,
- disallow srid:<id> and projjson:<key> on the writer side,
- preserve the reader SHOULD-tolerate language for the disallowed forms,
- require the GeoParquet column-metadata crs and the Parquet
logical-type crs to mirror each other exactly,
- document the null/no-CRS corner case explicitly,
- note that authority-code OGC:CRS84 / EPSG:4326 are equivalent to
OGC:CRS84 in §OGC:CRS84 details.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: format-specs/geoparquet.md
+36-12Lines changed: 36 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,7 +49,7 @@ Each geometry column in the dataset MUST be included in the `columns` field abov
49
49
| -------------- | ------------ | ----------- |
50
50
| encoding | string |**REQUIRED.** Name of the geometry encoding format. Only `"WKB"` is supported. |
51
51
| geometry_types |\[string]|**REQUIRED.** The geometry types of all geometries, or an empty array if they are not known. |
52
-
| crs | object\|null |[PROJJSON](https://proj.org/specifications/projjson.html) objectrepresenting the Coordinate Reference System (CRS) of the geometry. If the field is not provided, the default CRS is [OGC:CRS84](https://www.opengis.net/def/crs/OGC/1.3/CRS84), which means the data in this column must be stored in longitude, latitude based on the WGS84 datum. |
52
+
| crs | object\|string\|null |[PROJJSON](https://proj.org/specifications/projjson.html) object, or an `<authority>:<code>` string (e.g. `"EPSG:4326"`), representing the Coordinate Reference System (CRS) of the geometry. The value MUST equal the Parquet logical-type `crs` property in the same form. If the field is not provided, the default CRS is [OGC:CRS84](https://www.opengis.net/def/crs/OGC/1.3/CRS84), which means the data in this column must be stored in longitude, latitude based on the WGS84 datum. |
53
53
| orientation | string | Winding order of exterior ring of polygons. If present must be `"counterclockwise"`; interior rings are wound in opposite order. If absent, no assertions are made regarding the winding order. |
54
54
| edges | string | Describes how to interpret the edges of the geometries. Must be one of `planar`, `spherical`, `vincenty`, `thomas`, `andoyer`, `karney`. The default value is `planar`.
55
55
| bbox |\[number]| Bounding Box of the geometries in the file, formatted according to [RFC 7946, section 5](https://tools.ietf.org/html/rfc7946#section-5). |
@@ -59,27 +59,49 @@ Each geometry column in the dataset MUST be included in the `columns` field abov
59
59
60
60
The Coordinate Reference System (CRS) is an optional parameter for each geometry column defined in GeoParquet format.
61
61
62
-
The CRS MUST be provided in [PROJJSON](https://proj.org/specifications/projjson.html) format, which is a JSON encoding of [WKT2:2019 / ISO-19162:2019](https://docs.opengeospatial.org/is/18-010r7/18-010r7.html), which itself implements the model of [OGC Topic 2: Referencing by coordinates abstract specification / ISO-19111:2019](http://docs.opengeospatial.org/as/18-005r4/18-005r4.html). Apart from the difference of encodings, the semantics are intended to match WKT2:2019, and a CRS in one encoding can generally be represented in the other.
62
+
In GeoParquet 2.0 the CRS is carried both on the Parquet `GEOMETRY`/`GEOGRAPHY` logical type's `crs` property and (mirrored) on the GeoParquet column-metadata `crs` field. The two MUST be equal and MUST be in the same form.
63
63
64
-
If the `crs` key does not exist, all coordinates in the geometries MUST use longitude, latitude based on the WGS84 datum, and the default value is [OGC:CRS84](https://www.opengis.net/def/crs/OGC/1.3/CRS84) for CRS-aware implementations. Note that a missing `crs` key has different meaning than a `crs` key set to `null` (see below).
64
+
The CRS MAY be expressed in one of two forms:
65
65
66
-
[OGC:CRS84](https://www.opengis.net/def/crs/OGC/1.3/CRS84) is equivalent to the well-known [EPSG:4326](https://epsg.org/crs_4326/WGS-84.html) but changes the axis from latitude-longitude to longitude-latitude.
66
+
1.**Inline [PROJJSON](https://proj.org/specifications/projjson.html)** — a complete CRS definition, which is a JSON encoding of [WKT2:2019 / ISO-19162:2019](https://docs.opengeospatial.org/is/18-010r7/18-010r7.html), itself implementing the model of [OGC Topic 2: Referencing by coordinates abstract specification / ISO-19111:2019](http://docs.opengeospatial.org/as/18-005r4/18-005r4.html). This is the canonical form.
67
+
2.**An `<authority>:<code>` string** — e.g. `"OGC:CRS84"`, `"EPSG:4326"`, `"EPSG:3857"`, `"IGNF:ATI"`. The authority and code MUST be one published by a recognized CRS authority (well-known authorities include OGC, EPSG, ESRI, and IGNF; see <https://spatialreference.org/> for an index).
67
68
68
-
See below for additional details about representing or identifying OGC:CRS84.
69
+
If the `crs` key does not exist, all coordinates in the geometries MUST use longitude, latitude based on the WGS84 datum, and the default value is [OGC:CRS84](https://www.opengis.net/def/crs/OGC/1.3/CRS84) for CRS-aware implementations. Note that a missing `crs` key has different meaning than a `crs` key set to `null` (see below).
69
70
70
-
The value of this key may be explicitly set to `null`to indicate that there is no CRS assigned to this column (CRS is undefined or unknown).
71
+
[OGC:CRS84](https://www.opengis.net/def/crs/OGC/1.3/CRS84) is equivalent to the well-known [EPSG:4326](https://epsg.org/crs_4326/WGS-84.html) but changes the axis from latitude-longitude to longitude-latitude. See below for additional details about representing or identifying OGC:CRS84, including when it arrives as an `<authority>:<code>` string rather than as PROJJSON.
71
72
72
-
The `crs`field of GeoParquet MUST reflect the crs of the Parquet `crs` property on the GEOMETRY or GEOGRAPHY logical type.
73
+
The value of this key may be explicitly set to `null` to indicate that there is no CRS assigned to this column (CRS is undefined or unknown). Because the Parquet core specification has no native way to express "no CRS" (an absent Parquet `crs`defaults to OGC:CRS84), a writer that sets the GeoParquet column-metadata `crs` to `null` MUST omit the Parquet logical-type `crs` property; the GeoParquet `null` is authoritative and overrides Parquet's default-to-OGC:CRS84 interpretation in this case.
73
74
74
75
##### `crs` Parquet property
75
76
76
-
The Parquet Geospatial definitions have a [crs customization](https://github.com/apache/parquet-format/blob/apache-parquet-format-2.12.0/Geospatial.md#crs-customization) section
77
-
that gives flexibility for how to specify the crs.
77
+
The Parquet Geospatial definitions have a [crs customization](https://github.com/apache/parquet-format/blob/apache-parquet-format-2.12.0/Geospatial.md#crs-customization) section that permits four forms: inline PROJJSON, `<authority>:<code>`, `srid:<identifier>`, and `projjson:<key_name>`.
78
+
79
+
GeoParquet 2.0 is more restrictive:
80
+
81
+
- A GeoParquet 2.0 writer MUST use one of:
82
+
- inline PROJJSON, or
83
+
- an `<authority>:<code>` string.
84
+
- A GeoParquet 2.0 writer MUST NOT use `srid:<identifier>` (no authority context; ambiguous across systems) or `projjson:<key_name>` (indirect reference via another metadata key; no ergonomic benefit over inline PROJJSON).
85
+
- A GeoParquet 2.0 writer SHOULD prefer inline PROJJSON. It is self-describing, requires no external CRS registry, and matches the GeoParquet 1.x convention.
86
+
- A GeoParquet 2.0 writer MAY use `<authority>:<code>` when:
87
+
- the CRS is precisely identified by a well-known authority entry, AND
88
+
- the writing environment lacks a PROJJSON generator (e.g., pure-SQL pipelines, lightweight browser-side writers), OR
89
+
- reducing per-file metadata size is desirable (e.g., very many very small files).
78
90
79
-
The GeoParquet 2.0 specification gives less flexibility. To comply with
80
-
GeoParquet 2.0 if there is a non-default crs then the crs field in the Parquet geometry or geography type MUST be an in-line projjson representation of the crs. This is allowed by the Parquet specification, though it is not explicitly articulated.
91
+
A GeoParquet 2.0 reader MUST handle both writer-permitted forms (inline PROJJSON and `<authority>:<code>`).
81
92
82
-
Readers of geospatial Parquet data SHOULD try to parse other crs representations in the Parquet metadata.
93
+
Readers of geospatial Parquet data SHOULD additionally try to parse the other Parquet-core `crs` representations (`srid:<identifier>` and `projjson:<key_name>`) when encountered. Such files are not conformant GeoParquet 2.0, but supporting them improves interoperability with the broader Parquet geospatial ecosystem.
94
+
95
+
The GeoParquet column-metadata `crs` field and the Parquet logical-type `crs` property MUST mirror each other exactly:
96
+
97
+
| Parquet logical-type `crs`| GeoParquet column-metadata `crs`| Meaning |
The two fields MUST NOT disagree in form (one being PROJJSON while the other is `<authority>:<code>`) or in value.
83
105
84
106
#### epoch
85
107
@@ -232,6 +254,8 @@ It is reasonable for implementations to require that one of the above `id` eleme
232
254
233
255
Note: EPSG:4326 and OGC:CRS84 are equivalent with respect to this specification because this specification specifically overrides the coordinate axis order in the `crs` to be longitude-latitude.
234
256
257
+
When the CRS arrives in the `<authority>:<code>` form, the values `"OGC:CRS84"` and `"EPSG:4326"` are likewise equivalent to OGC:CRS84 for the purposes of this specification.
258
+
235
259
## Version Compatibility
236
260
237
261
GeoParquet version numbers follow [SemVer](https://semver.org), meaning patch releases are for bugfixes, minor releases represent backwards compatible changes, and major releases represent breaking changes. For this specification, a backwards compatible change means that a file written with the older specification will always be compatible with the newer specification. Minor releases are also guaranteed to be forward compatible up the the next major release. Forward compatiblity means that an implementation that is only aware of the older specification MUST be able to correctly interpret data written according to the newer specification, OR recognize that it cannot correctly interpret that data.
0 commit comments