On this page
Check coordinate order and dimensions first
The source date shown in this guide identifies an RFC 7946 documentation check on 22 October 2026, not an original publication date. Follow the citation for the standard being discussed.
For interoperable RFC 7946 GeoJSON, use WGS 84 geographic coordinates in decimal degrees. The first value is longitude and the second is latitude. An optional third value is height in meters relative to the WGS 84 reference ellipsoid. A projected easting and northing pair is not automatically standard GeoJSON coordinates merely because it has two numbers. Record any source-specific transform separately and do not infer units from a value.
| Check | Safe observation | Review question |
|---|---|---|
| Axis order | First value is longitude and second is latitude | Did the producer document this, or did a parser assume it? |
| Two-dimensional position | Two numeric elements | Is height absent or dropped? |
| Three-dimensional position | Third numeric element present | Is it WGS 84 ellipsoidal height or unknown? |
| Four or more elements | Extra dimensions present | Are they outside the agreed GeoJSON contract? |
| Coordinate reference | WGS 84 decimal-degree claim or unresolved | Is a transform being assumed? |
| Numeric range | Checked against the domain rule | Are out-of-range values held, not clipped? |
| Precision | Digits preserved | Is uncertainty separate from decimal length? |
Synthetic Point
{
"type": "Point",
"coordinates": [12.34, 56.78]
}The first value in this synthetic Point is longitude and the second latitude. Do not fix axis order by swapping every value without preserving the source and documenting the transformation. Use synthetic coordinates before exposing a real location.
Validate geometry-specific nesting
A position is not interchangeable with a list of positions. The nesting level depends on the geometry type defined by Internet Engineering Task Force, (opens in a new tab).
| Geometry type | Coordinate structure | Minimum structural review |
|---|---|---|
| Point | One position | Two or three numeric elements under the agreed dimension rule |
| MultiPoint | Array of positions | Each child is a valid position |
| LineString | Array of positions | At least two positions |
| MultiLineString | Array of LineString arrays | Each line has required positions |
| Polygon | Array of linear-ring arrays | Each ring is closed and has at least four positions |
| MultiPolygon | Array of Polygon coordinate arrays | Apply polygon checks to every ring |
| GeometryCollection | Array of geometry objects | Validate each child; do not assume homogeneity |
RFC 7946 defines a linear ring as a closed LineString with at least four positions; the first and last must be identical. The first polygon ring is exterior and later rings are holes. The preferred right-hand rule is counterclockwise exterior and clockwise holes, but parsers should not reject opposite winding, so record it as a review finding.
Synthetic Polygon
{
"type": "Polygon",
"coordinates": [
[
[10.0, 20.0],
[11.0, 20.0],
[11.0, 21.0],
[10.0, 21.0],
[10.0, 20.0]
]
]
}The synthetic ring closes because its first and last positions are identical. Report the ring number, closure, position count, and winding. Do not silently reorder the source.
Review features, properties, and bounding boxes together
A Feature has type Feature, a Geometry object or null in geometry, and an object or null in properties. A FeatureCollection has a features array of Features. These are structural rules, not evidence that a property is accurate, current, identifying, or shareable.
| Field | Record | Do not infer |
|---|---|---|
| type | Feature, FeatureCollection, or declared geometry type | That a custom type replaces a GeoJSON type |
| id | Optional string or number when included | That the identifier is stable or non-identifying |
| geometry | Geometry object or null | That null means outside coverage rather than not collected |
| properties | Object or null | That property names describe geometry correctly |
| bbox | Axis order, dimension count, and source reference | That the box proves geometry or coverage is complete |
| foreign members | Name, purpose, and handling rule | That an extension changes GeoJSON semantics |
Synthetic two-dimensional bbox
{
"type": "Feature",
"geometry": null,
"properties": {"fixture": true},
"bbox": [10.0, 20.0, 11.0, 21.0]
}RFC 7946 says a bbox has length two times the number of dimensions and follows geometry axis order. The synthetic two-dimensional example has four values. Check the same coordinate interpretation when height exists, and do not automatically call null geometry malformed. Ask why it is unlocated, whether the dataset permits it, and whether properties disclose more than needed.
Handle antimeridian, precision, and reference-system edge cases
RFC 7946 recommends cutting antimeridian-crossing geometries so neither part crosses it in the representation. A line from 170 degrees east to 170 degrees west can be a two-part MultiLineString. This is an interoperability choice, not permission to move a feature or assume its route.
| Observation | Safe interpretation | Next action |
|---|---|---|
| Line crosses near the antimeridian | Possible crossing | Compare the source rule and test a MultiLineString cut |
| Polygon ring is not closed | Incomplete structure | Preserve source; request correction or documented repair |
| Winding disagrees with the preferred rule | Winding unresolved | Record rings and decide whether a derivative may normalize |
| Bbox has four values for 3D geometry | Dimension mismatch | Recalculate or hold; do not drop height |
| Coordinate has many decimal places | Digits, not proven uncertainty | Preserve it; request an uncertainty statement |
| Foreign CRS member appears | Non-standard reference context | Verify the prior arrangement and transform rule |
| Coordinate is outside the domain range | Domain or axis finding | Hold for source review; do not clip |
RFC 7946 removes the old arbitrary-CRS extension mechanism because alternatives caused interoperability problems, while allowing prior arrangements. Record a transform as a named operation with source and target systems; do not overwrite original coordinates.
The RFC says digit count is not uncertainty. Keep precision, measurement uncertainty, capture method, and positional accuracy as separate fields. Structurally valid geometry can still be approximate or generalized.
Keep location diagnostics safe and the next step qualified
Coordinates can reveal a home, route, device pattern, or rare event without names. A public worksheet can record geometry type, ring number, axis checks, dimension and bbox state, and a stable evidence reference. Do not copy a precise point or distinctive property just to show validation ran.
Pair this review with the data provenance log for source and rights evidence and export guidance for export behavior. This guide owns coordinate order, geometry structure, bbox, antimeridian, precision, and reference-system findings.
This article is not a map, geocoder, coordinate transformer, or location service. It is a static GeoJSON worksheet that separates structural observations from positional accuracy, privacy, and ownership decisions.
After the owner has a supported non-health scope, authority to describe the collection, and a controlled GeoJSON review packet, the qualified appraisal request path may be a next preparation step. It does not validate coordinates, transform a CRS, assess positional accuracy, create a quote, match a buyer, issue a legal opinion, or grant a license. Keep precise locations and related properties within the owner-approved handling boundary.
Takeaways
- Check longitude and latitude order before interpreting any geometry.
- Validate nesting, minimum positions, ring closure, winding, and multipart structure by geometry type.
- Treat bbox axes and dimensions as part of the same coordinate contract.
- Handle antimeridian cuts, non-standard reference systems, precision, and uncertainty as explicit review states.
- Keep precise locations separate from public diagnostics, rights review, privacy review, and any appraisal request.