More consistent spelling and punctuation for JSON types

format-specs/geoparquet.md

@@ -39,7 +39,7 @@ All file-level metadata should be included under the "geo" key in the parquet me
 | ------------------ | ------ | -------------------------------------------------------------------- |
 | version     		 | string | **REQUIRED** The version of the GeoParquet metadata standard used when writing.   |
 | primary_column     | string | **REQUIRED** The name of the "primary" geometry column.                |
-| columns            | Map<key, [Column Metadata](#column-metadata)> | **REQUIRED** Metadata about geometry columns, with each key is the name of a geometry column in the table. |
+| columns            | object<key, [Column Metadata](#column-metadata)> | **REQUIRED** Metadata about geometry columns, with each key is the name of a geometry column in the table. |
 
 At this level, additional implementation-specific fields (e.g. library name) are allowed, and thus readers should be robust in ignoring those.
 
@@ -60,13 +60,13 @@ Each geometry column in the dataset must be included in the columns field above
 
 | Field Name | Type | Description |
 | --- | --- | --- |
-| encoding | string | **REQUIRED** Name of the geometry encoding format. Currently only 'WKB' is supported. |
+| encoding | string | **REQUIRED** Name of the geometry encoding format. Currently only `"WKB"` is supported. |
 | geometry_types | \[string] | **REQUIRED** The geometry types of all geometries, or an empty array if they are not known. |
-| crs | JSON object | **OPTIONAL** [PROJJSON](https://proj.org/specifications/projjson.html) JSON object representing the Coordinate Reference System (CRS) of the geometry. If the crs field is not included then the data in this column must be stored in longitude, latitude based on the WGS84 datum, and CRS-aware implementations should assume a default value of [OGC:CRS84](https://www.opengis.net/def/crs/OGC/1.3/CRS84). |
-| orientation | string | **OPTIONAL** 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. |
-| edges | string | **OPTIONAL** Name of the coordinate system for the edges. Must be one of 'planar' or 'spherical'. The default value is 'planar'. |
+| crs | object | **OPTIONAL** [PROJJSON](https://proj.org/specifications/projjson.html) object representing the Coordinate Reference System (CRS) of the geometry. If the crs field is not included then the data in this column must be stored in longitude, latitude based on the WGS84 datum, and CRS-aware implementations should assume a default value of [OGC:CRS84](https://www.opengis.net/def/crs/OGC/1.3/CRS84). |
+| orientation | string | **OPTIONAL** 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. |
+| edges | string | **OPTIONAL** Name of the coordinate system for the edges. Must be one of `"planar"` or `"spherical"`. The default value is `"planar"`. |
 | bbox | \[number] | **OPTIONAL** Bounding Box of the geometries in the file, formatted according to [RFC 7946, section 5](https://tools.ietf.org/html/rfc7946#section-5). |
-| epoch | double | **OPTIONAL** Coordinate epoch in case of a dynamic CRS, expressed as a decimal year. |
+| epoch | number | **OPTIONAL** Coordinate epoch in case of a dynamic CRS, expressed as a decimal year. |
 
 #### crs
 
@@ -99,15 +99,15 @@ In a dynamic CRS, coordinates of a point on the surface of the Earth may
 change with time. To be unambiguous, the coordinates must always be qualified
 with the epoch at which they are valid.
 
-The optional "epoch" field allows to specify this in case the "crs" field
+The optional `epoch` field allows to specify this in case the `crs` field
 defines a a dynamic CRS. The coordinate epoch is expressed as a decimal year
 (e.g. 2021.47). Currently, this specification only supports an epoch per
 column (and not per geometry).
 
 #### encoding
 
 This is the binary format that the geometry is encoded in.
-The string 'WKB', signifying Well Known Binary is the only current option, but future versions
+The string `"WKB"`, signifying Well Known Binary is the only current option, but future versions
 of the spec may support alternative encodings. This should be the ["OpenGIS® Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture"](https://portal.ogc.org/files/?artifact_id=18241) WKB representation (using codes for 3D geometry types in the \[1001,1007\] range). This encoding is also consistent with the one defined in the ["ISO/IEC 13249-3:2016 (Information technology - Database languages - SQL multimedia and application packages - Part 3: Spatial)"](https://www.iso.org/standard/60343.html) standard.
 
 Note that the current version of the spec only allows for a subset of WKB: 2D or 3D geometries of the standard geometry types (the Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, and GeometryCollection geometry types). This means that M values or non-linear geometry types are not yet supported.
@@ -121,44 +121,42 @@ This follows the precedent of [GeoPackage](https://geopackage.org), see the [not
 #### geometry_types
 
 This field captures the geometry types of the geometries in the
-column, when known. Accepted geometry types are: "Point", "LineString",
-"Polygon", "MultiPoint", "MultiLineString", "MultiPolygon",
-"GeometryCollection".
+column, when known. Accepted geometry types are: `"Point"`, `"LineString"`,
+`"Polygon"`, `"MultiPoint"`, `"MultiLineString"`, `"MultiPolygon"`,
+`"GeometryCollection"`.
 
 In addition, the following rules are used:
 
-- In case of 3D geometries, a " Z" suffix gets added (e.g. ["Point Z"]).
-- A list of multiple values indicates that multiple geometry types are present (e.g. ["Polygon", "MultiPolygon"]).
+- In case of 3D geometries, a `" Z"` suffix gets added (e.g. `["Point Z"]`).
+- A list of multiple values indicates that multiple geometry types are present (e.g. `["Polygon", "MultiPolygon"]`).
 - An empty array explicitly signals that the geometry types are not known.
-- The geometry types in the list must be unique (e.g. ["Point", "Point"] is not valid).
+- The geometry types in the list must be unique (e.g. `["Point", "Point"]` is not valid).
 
 It is expected that this field is strictly correct. For
 example, if having both polygons and multipolygons, it is not sufficient to
-specify ["MultiPolygon"], but it is expected to specify
-["Polygon", "MultiPolygon"]. Or if having 3D points, it is not sufficient to
-specify ["Point"], but it is expected to list ["Point Z"].
+specify `["MultiPolygon"]`, but it is expected to specify
+`["Polygon", "MultiPolygon"]`. Or if having 3D points, it is not sufficient to
+specify `["Point"]`, but it is expected to list `["Point Z"]`.
 
 #### orientation
 
-This attribute indicates the winding order of polygons. The only available value is:
-
-- "counterclockwise": All vertices of exterior polygon rings MUST be ordered in the counterclockwise direction and all interior rings MUST be ordered in the clockwise direction.
+This attribute indicates the winding order of polygons. The only available value is `"counterclockwise"`. All vertices of exterior polygon rings MUST be ordered in the counterclockwise direction and all interior rings MUST be ordered in the clockwise direction.
 
 If no value is set, no assertions are made about winding order or consistency of such between exterior and interior rings or between individual geometries within a dataset.  Readers are responsible for verifying and if necessary re-ordering vertices as required for their analytical representation.
 
 Writers are encouraged but not required to set orientation="counterclockwise" for portability of the data within the broader ecosystem.
 
-It is recommended to always set the orientation (to counterclockwise) if `edges` is 'spherical' (see below).
+It is recommended to always set the orientation (to counterclockwise) if `edges` is `"spherical"` (see below).
 
 #### edges
 
 This attribute indicates how to interpret the edges of the geometries: whether the line between two points is a straight cartesian line or the shortest line on the sphere (geodesic line). Available values are:
-- planar: use a flat cartesian coordinate system.
-- spherical: use a spherical coordinate system and radius derived from the spheroid defined by the coordinate reference system.
+- `"planar"`: use a flat cartesian coordinate system.
+- `"spherical"`: use a spherical coordinate system and radius derived from the spheroid defined by the coordinate reference system.
 
-If no value is set, the default value to assume is 'planar'.
+If no value is set, the default value to assume is `"planar"`.
 
-Note if `edges` is 'spherical' then it is recommended that `orientation` is always ensured to be 'counterclockwise'. If it is not set, it is not clear how polygons should be interpreted within spherical coordinate systems, which can lead to major analytical errors if interpreted incorrectly.
+Note if `edges` is `"spherical"` then it is recommended that `orientation` is always ensured to be `"counterclockwise"`. If it is not set, it is not clear how polygons should be interpreted within spherical coordinate systems, which can lead to major analytical errors if interpreted incorrectly.
 In this case, software will typically interpret the rings of a polygon such that it encloses at most half of the sphere (i.e. the smallest polygon of both ways it could be interpreted). But the specification itself does not make any guarantee about this.
 
 #### bbox