# RFC Errata

Found 4 records.

## Status: Reported (4)

#### RFC 7946, "The GeoJSON Format", August 2016

Source of RFC: geojson (art)
Errata ID: 5069

**Status: Reported
Type: Technical
Publication Format(s) : TEXT**

Reported By: Clark Archer

Date Reported: 2017-07-14

Section 3.1.6 says:

3.1.6. Polygon To specify a constraint specific to Polygons, it is useful to introduce the concept of a linear ring: o A linear ring is a closed LineString with four or more positions. o The first and last positions are equivalent, and they MUST contain identical values; their representation SHOULD also be identical. o A linear ring is the boundary of a surface or the boundary of a hole in a surface. o A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e., exterior rings are counterclockwise, and holes are clockwise. Note: the [GJ2008] specification did not discuss linear ring winding order. For backwards compatibility, parsers SHOULD NOT reject Polygons that do not follow the right-hand rule. Though a linear ring is not explicitly represented as a GeoJSON geometry type, it leads to a canonical formulation of the Polygon geometry type definition as follows: o For type "Polygon", the "coordinates" member MUST be an array of linear ring coordinate arrays. o For Polygons with more than one of these rings, the first MUST be the exterior ring, and any others MUST be interior rings. The exterior ring bounds the surface, and the interior rings (if present) bound holes within the surface.

It should say:

3.1.6. Polygon To specify a constraint specific to Polygons, it is useful to introduce the concept of a linear ring: o A linear ring is a closed LineString with four or more positions. o The first and last positions are equivalent, and they MUST contain identical values; their representation SHOULD also be identical. o A linear ring is the boundary of a surface or the boundary of a hole in a surface. o A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e., exterior rings are clockwise, and holes are counterclockwise. Note: the [GJ2008] specification did not discuss linear ring winding order. For backwards compatibility, parsers SHOULD NOT reject Polygons that do not follow the right-hand rule. Though a linear ring is not explicitly represented as a GeoJSON geometry type, it leads to a canonical formulation of the Polygon geometry type definition as follows: o For type "Polygon", the "coordinates" member MUST be an array of linear ring coordinate arrays. o For Polygons with more than one of these rings, the first MUST be the exterior ring, and any others MUST be interior rings. The exterior ring bounds the surface, and the interior rings (if present) bound holes within the surface.

Notes:

This is only for the bullet point describing the right-hand rule for linear rings. It seems like the clockwise/counterclockwise descriptions are the opposite of the right-hand rule. Walking an exterior ring in a counterclockwise direction would have the exterior of the ring to the right of the observer.

Errata ID: 7261

**Status: Reported
Type: Technical
Publication Format(s) : TEXT**

Reported By: mark hedley

Date Reported: 2022-12-08

Section 4 says:

An OPTIONAL third-position element SHALL be the height in meters above or below the WGS84 reference ellipsoid.

It should say:

An OPTIONAL third-position element SHALL be the height in meters above or below the EGM2008 geoid vertical datum, the height is defined with respect to the EGM2008 vertical coordinate reference system (providing close approximation to altitude above global mean sea level).

Notes:

Vertical coordinates, where used within GeoJSON shall be interpreted as with respect to the EGM2008 vertical datum. Transformations from WGS84 vertical coordinate values to EGM2008 coordinate values shall not be implemented (unless by prior arrangement between involved parties) .

There is specification information within the EPSG registry on both the EGM2008 vertical datum:

https://epsg.org/crs_3855/EGM2008-height.html

and on the compound of WGS84 latitude longitude with EGM2008 altitude

https://epsg.org/crs_9518/WGS-84-EGM2008-height.html

Common usage of altitude vertical coordinates is with respect to mean sea level. However, the original text within rfc7946 state that a vertical coordinate is with respect to the WGS84 reference ellipsoid.

The WGS84 reference ellipsoid is an oblate spheroid that only partially approximates mean sea level. The EGM2008 (superseding EGM96) vertical datum provides

"Zero-height surface resulting from the application of the EGM2008 geoid model to the WGS 84 ellipsoid." (https://epsg.org/crs_3855/EGM2008-height.htm)

EGM2008 closely models mean sea level as a global vertical datum.

Distortions are global position dependent, discrepancies can range from less than a metre to 10s of metres. For example, at a location of (50.218 -5.327 (WGS84)) the discrepancy between a WGS84 vertical coordinate and a EGM2008 vertical coordinate is 53.4 metres.

This is a really significant vertical discrepancy for a positional coordinate.

The update within this errata matches the specification to the widespread and common use of vertical position with respect to mean sea level, as measured by national mapping agencies and satellite earth observations.

Errata ID: 7253

**Status: Reported
Type: Technical
Publication Format(s) : TEXT**

Reported By: Tim Schaub

Date Reported: 2022-11-18

Section 5.2 says:

Consider a set of point Features within the Fiji archipelago, straddling the antimeridian between 16 degrees S and 20 degrees S. The southwest corner of the box containing these Features is at 20 degrees S and 177 degrees E, and the northwest corner is at 16 degrees S and 178 degrees W.

It should say:

Consider a set of point Features within the Fiji archipelago, straddling the antimeridian between 16 degrees S and 20 degrees S. The southwest corner of the box containing these Features is at 20 degrees S and 177 degrees E, and the northeast corner is at 16 degrees S and 178 degrees W.

Notes:

In the antimeridian-crossing example, the text says that the "northwest" corner is at 16 degrees S and 178 degrees W. It should say this is the "northeast" corner instead.

Errata ID: 8046

**Status: Reported
Type: Technical
Publication Format(s) : TEXT**

Reported By: John Andrea

Date Reported: 2024-07-24

Section 5 says:

Example of a 2D bbox member on a Feature: { "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] ] ] } //... }

It should say:

Example of a 2D bbox member on a Feature: { "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], [-10.0, -10.0] ] ] } //... }

Notes:

The bounding box as a polygon is currently missing a corner.