GeoJSON to WKT Converter

How the GeoJSON to WKT Converter works, and what it assumes

The input is read as JSON first and then checked as GeoJSON, which are two different things: a document can parse perfectly and still be meaningless. The structural check follows RFC 7946 — that the type is one of the nine GeoJSON types, that coordinates are nested to the depth the type requires, that every position is two or three numbers, and that linear rings have at least four positions and are closed.

A bare geometry converts directly. A Feature gives up its geometry, and its properties are left behind, because WKT describes shape and nothing else. A FeatureCollection holding one geometry converts to that geometry; one holding several is written as a GEOMETRYCOLLECTION, since a single WKT value holds a single geometry. Features whose geometry is null are skipped rather than counted.

Positions with a third element are written with the Z dimension tag. The coordinate precision setting rounds every ordinate to a fixed number of decimal places, which is worth using: at the equator the sixth decimal place of a degree is about eleven centimetres and the seventh about eleven millimetres, which is finer than most data was ever measured to. An SRID prefix is added only when you ask for one, producing the EWKT that PostGIS reads.

Using the GeoJSON to WKT Converter

• Writing an INSERT or an UPDATE that calls ST_GeomFromText with geometry that arrived as GeoJSON.
• Pasting a geometry into a database client or a query tool that will not accept GeoJSON.
• Shortening a geometry for a bug report, where WKT is far easier to read in a paragraph than nested JSON arrays.
• Reducing coordinate precision before storing geometry, where seven decimal places of longitude is centimetres nobody measured.

A worked example

This Feature:

{
  "type": "Feature",
  "properties": { "name": "Trafalgar Square" },
  "geometry": { "type": "Point", "coordinates": [-0.12805, 51.50800] }
}

converts, with an SRID of 4326 and five decimal places, to:

SRID=4326;POINT (-0.12805 51.508)

The name is gone, because WKT has no room for attributes. In a database that name belongs in its own column beside the geometry, which is where a spatial table would keep it anyway. The trailing zero of 51.50800 is dropped because it carries no information.

Where this comes up in GIS work

1. Paste your GeoJSON into the input box, open a .geojson or .json file, or select Load example.
2. Leave SRID empty for plain WKT, or enter a code such as 4326 to produce EWKT for PostGIS.
3. Choose how many decimal places to keep, or leave it on Full precision.
4. Select Convert to WKT, or press Ctrl + Enter (Cmd + Enter on a Mac).
5. Copy the WKT or download it as a .wkt file.

When the output looks wrong

A linear ring must be closed: the last position has to repeat the first

GeoJSON requires every polygon ring to end at its starting position. Add the first position again at the end of the ring. Unlike the WKT reader, this tool will not close it for you, because doing so would change the geometry you are storing.

Several geometries were combined into a GEOMETRYCOLLECTION

WKT holds one geometry per value, while a FeatureCollection holds many. If you need one row per feature, convert them one at a time; most databases handle a collection badly in spatial indexes and predicates.

Feature properties are not part of WKT and were left behind

WKT describes shape only. Attributes such as names and identifiers have to travel in their own columns, which is exactly how a spatial table stores them anyway.

A position may hold at most three values

A GeoJSON position is longitude, latitude and optionally elevation. A fourth value, usually a measure or a timestamp, is not valid GeoJSON and is rejected rather than silently written into the WKT as an M ordinate.

Questions about the GeoJSON to WKT Converter