WKT to GeoJSON Converter

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

The converter reads Well-Known Text with its own parser rather than a regular expression, so it reports the exact line and column of the first problem instead of failing silently. It accepts every OGC Simple Features geometry type, the Z, M and ZM dimension tags, EMPTY geometries, both MULTIPOINT spellings, and the SRID=4326; prefix that PostGIS writes.

The coordinates themselves are copied across unchanged. WKT writes X before Y, and so does GeoJSON, so nothing is reordered: a position written -0.1276 51.5072 becomes [-0.1276, 51.5072]. A Z value is kept as the third element of the position, which is where RFC 7946 puts elevation. An M value has nowhere to go in GeoJSON and is dropped, and the tool says so rather than writing a measure into the elevation slot.

Two checks happen on the way through. A polygon ring that does not end where it started is closed for you and reported, because GeoJSON requires closed rings and an unclosed one is rejected by strict readers. And no coordinate reference system is written out at all: RFC 7946 fixes GeoJSON at WGS 84 longitude and latitude, so an SRID is read, reported and left behind rather than being recorded in a member that the standard removed.

Using the WKT to GeoJSON Converter

• Turning a geometry column from a PostGIS, SQL Server or Oracle Spatial query into something Leaflet, OpenLayers or Mapbox can draw.
• Pasting a boundary out of a bug report or a support ticket to see what it actually covers.
• Producing test fixtures for an API that takes GeoJSON, from geometry you already have as WKT.
• Checking that a geometry written by hand parses at all, and that its rings are closed.

A worked example

A polygon with a hole, as a spatial database would hand it to you:

POLYGON ((0 0, 10 0, 10 10, 0 10, 0 0), (2 2, 4 2, 4 4, 2 4, 2 2))

becomes, wrapped as a Feature:

{
  "type": "Feature",
  "properties": {},
  "geometry": {
    "type": "Polygon",
    "coordinates": [
      [[0, 0], [10, 0], [10, 10], [0, 10], [0, 0]],
      [[2, 2], [4, 2], [4, 4], [2, 4], [2, 2]]
    ]
  }
}

The first ring is the outer boundary and the second is the hole, which is the rule in both formats. If the input were POINT (30), the tool would report Invalid WKT at line 1, column 10: Expected a number but found ')'.

Where this comes up in GIS work

1. Paste your WKT into the input box, open a .wkt or .txt file, or select Load example.
2. Choose what to wrap the result in: a bare geometry, a Feature, or a FeatureCollection.
3. Choose Pretty or Minified output.
4. Select Convert to GeoJSON, or press Ctrl + Enter (Cmd + Enter on a Mac).
5. Copy the GeoJSON or download it as a .geojson file.

When the output looks wrong

This position has more than 2 ordinates, which does not match an untagged (2D) geometry

The geometry carries a third or fourth number but no Z, M or ZM tag, so the parser cannot tell which ordinate is which. Add the tag, as in POINT Z (30 10 5), rather than leaving it to be guessed.

Ring 1 was not closed, so its first position was repeated at the end

GeoJSON requires a linear ring to end where it starts. The converter closes the ring for you and says so; nothing is lost, but it is worth fixing at the source, because whatever wrote the geometry is producing invalid WKT.

The SRID was read but not written out

GeoJSON has no CRS member any more: RFC 7946 fixes it at WGS 84 longitude and latitude. If the SRID is not 4326, the numbers are in some other system and have to be reprojected before the output is meaningful GeoJSON.

The output draws in the wrong place, out in the ocean

Almost always latitude and longitude the wrong way round. WKT is X then Y, so a point in London is POINT (-0.1276 51.5072), not POINT (51.5072 -0.1276). The second form puts you 51 degrees east of Greenwich, in Kazakhstan.

Questions about the WKT to GeoJSON Converter