RFC 7946 — The GeoJSON Format
GeoJSON exchanges geographic geometries and features as JSON. This reference connects its format requirements to LongitudeOne's encoding capabilities so users can prepare compatible coordinates and distinguish geometry encoding from complete Feature handling.
Normative source
| Field | Source |
|---|---|
| Organization | Internet Engineering Task Force (IETF) |
| Identifier and title | RFC 7946, The GeoJSON Format |
| Publication | August 2016, Standards Track |
| Authoritative text | RFC Editor publication |
| Edition scope | RFC 7946, which supersedes the 2008 GeoJSON specification (section 1.3) |
| Corrections | RFC Editor errata checked on 2026-10-11; five reports have status Reported, with no verified correction incorporated here |
All section citations refer to the published RFC. Reported errata are proposals, not silently substituted requirements. In particular, this page retains the published winding directions and ellipsoidal-height rule.
Purpose and scope
This reference covers geometry objects and the constraints relevant to their encoding. Feature metadata, bounding boxes and foreign members are identified to make the boundary of LongitudeOne's assessed support explicit. The implementation records below describe a release candidate, not a blanket RFC conformance certification.
Relevant requirements
These are normative summaries; their obligation levels follow section 1.1.
| Subject | Requirement summary | RFC section |
|---|---|---|
| Types | Geometry types are Point, LineString, Polygon, their three Multi types and GeometryCollection. Types cannot be extended. | 1.4; 7 |
| Positions | Longitude precedes latitude; optional third ordinate is height. Extra ordinates SHOULD NOT be used; M has no defined semantics. | 3.1.1 |
| CRS | Coordinates use WGS 84 degrees, equivalent to CRS84; height is metres relative to the WGS 84 ellipsoid. | 4 |
| Structure | Geometry uses coordinates; GeometryCollection uses geometries. Non-empty lines need at least two positions. | 3.1; 3.1.4; 3.1.8 |
| Rings | At least four positions, identical endpoints, counterclockwise exterior and clockwise holes. Parsers SHOULD NOT reject opposite winding. | 3.1.6 |
| Empty values | Empty coordinate arrays MAY be interpreted as null objects; collections may be empty. Feature geometry may be JSON null. | 3.1; 3.1.8; 3.2 |
| Interoperability | Antimeridian-crossing geometries SHOULD be cut; nested, singleton and homogeneous collections SHOULD be avoided. | 3.1.8–3.1.9 |
| Features | Feature requires geometry and properties; FeatureCollection contains a features array. | 3.2–3.3 |
| Bounds | Optional bbox has twice the coordinate dimension, following coordinate axis order. | 5 |
| Extensions | Foreign members MAY be added; standard member and type semantics MUST NOT change. | 6.1; 7.1 |
Informative example: a geometry object ready for interchange, without Feature metadata or an embedded reference identifier:
{"type":"Point","coordinates":[2.35,48.86,30]}
LongitudeOne support
Encoder below means Spatial Encoder 1.0.0-RC.0 (the 1.x release
candidate), revision 73c55f338c64b3037006a1b6d86c00943c4a7426 at its release tag. The assessed implementation
and test links are pinned to revision
7680a3bb017cef797660210a7b3eab49a94eb1c5, whose lib/, tests/ and docs/
are unchanged from that tag. The local historical checkout is named
spatial-writer; the package and GitHub repository are now
longitude-one/spatial-encoder. No support for an older Writer release or a
future stable release is inferred.
The records concern GeoJsonStrategy encoding only. No DBMS integration is
assessed. The Spatial Decoder 1.x guide
documents WKT/EWKT decoding, not a GeoJSON decoding promise; GeoJSON decoding
remains Not assessed in this reference.
| Feature | Implementation scope | Status | Limitations | Implementation decision | Extensions | Evidence |
|---|---|---|---|---|---|---|
| Geometry types | Encoder | Supported | Geometry objects only | Seven-type dispatch | None documented | Encoder implementation |
| Coordinates | Encoder | Partially supported | XY/XYZ only; caller supplies CRS/units | Preserve ordinates; reject M | None documented | Strategy; Point tests |
| Polygon rings | Encoder | Partially supported | No general topology validation | Signed XY area; reject zero area | None documented | Approved policy; Polygon tests |
| Empty values | Encoder | Partially supported | Restrictions below | Preserve emptiness; reject invalid Multi members | None documented | Strategy guide |
| Collection guidance | Encoder | Partially supported | Does not apply simplification SHOULD | Preserve nesting, order and members | None documented | Collection tests |
| Antimeridian cutting | Encoder | Unsupported | Caller must prepare cut geometry | Preserve supplied positions | None documented | Strategy guide |
| Feature/FeatureCollection | Encoder | Unsupported | Application composition required | Geometry-only strategy | None documented | Strategy guide |
| Bounds/foreign members | Encoder | Unsupported | No bbox or extra-member input | Output type and geometry members only | None documented | Encoder implementation |
Caller responsibilities and limitations
Reference handling is a LongitudeOne implementation decision. The encoder preserves coordinates without projection, axis swapping or unit conversion. It neither checks SRID/authority compatibility nor writes reference metadata. Even unknown or non-4326 identifiers are accepted. The caller must supply WGS 84 longitude/latitude and appropriate height before encoding; omitted metadata is not evidence of a transformation. Geography and Geometry values both encode using the same GeoJSON geometry names.
Measured coordinates are unsupported. XYM and XYZM inputs throw
UnsupportedDimensionException, including empty values. M is neither discarded
nor reinterpreted as altitude. Unsupported types, including Triangle, curved
types and PolyhedralSurface, are rejected rather than renamed as a supported
GeoJSON type. See the strategy contract.
Polygon validation follows an approved project policy. Exterior signed XY area must be positive, interior area negative, and zero area is rejected. The encoder does not reverse or repair rings. The approved decision distinguishes this algorithm from the RFC's requirements. Nonzero area does not establish simplicity, absence of self-intersections or hole containment; those checks remain the caller's responsibility. Z is preserved but does not participate in orientation.
Empty encoding is representation-specific. Empty geometries use
coordinates: []; empty GeometryCollections use geometries: []. Empty members
are retained in GeometryCollections, but MultiPoint rejects empty Point members,
MultiLineString rejects empty or singleton lines, and MultiPolygon rejects empty
Polygon members. No member is silently omitted. Consumers may treat an empty
coordinate array as null; this is not a universal round-trip guarantee for WKT
EMPTY or a Feature's null geometry.
Interoperability recommendations are deliberately not applied automatically. Collections retain nesting, singleton and homogeneous forms. Antimeridian coordinates are retained without cutting or unwrapping, which can result in long-way-around display by consumers. These documented limitations do not authorize changing RFC semantics; callers prepare the desired representation.
Failures and extensions. Non-finite numbers encounter the JSON encoding
failure path, yielding JsonEncodingException rather than partial output.
The assessed strategy adds no foreign-member, alternate-CRS or measured-position
extension. This is scoped to this encoder and is not an ecosystem-wide absence
claim.