Converting GeoJSON, WKT, and CSV Geometry, with a Lat/Lon Swap Detector

The Problem

Geometry arrives in whatever format the last tool spat out — GeoJSON from a web API, WKT from a database, a CSV of coordinates from a GPS export — and you need it in a different one, plus a quick sanity check: how many vertices, what's the bounding box, roughly how big is this thing. Pasting it into a public converter means shipping possibly-sensitive geometry to someone else's server. This does all three formats locally, and flags the one bug that bites everyone.

The Approach

Three hand-rolled parsers, zero dependencies. GeoJSON (bare geometry, Feature, or FeatureCollection, with a note when it uses the first of several features and a warning on a legacy crs member). A tokenizing WKT parser for all seven simple-feature types, case-insensitive and whitespace-tolerant, that swallows Z/M values. And CSV with header auto-skip, selectable lon/lat vs lat/lon column order, and a choice of interpreting rows as a path, a polygon (auto-closed, with a note), or loose points. Parse errors surface as readable messages — with position info from the WKT tokenizer — instead of a blank screen [1][2].

Geometry pasted as WKT with GeoJSON output, vertex count, bounding box, and geodesic area inspection
Figure 1: WKT in, GeoJSON out, with vertex count, bbox, and geodesic length/area alongside.

The lat/lon swap detector

Swapped axes is the most common geometry bug in existence, and it's insidious because the data still parses — it just plots your California parcel somewhere in the Arctic Ocean. GeoJSON and WKT are longitude-first by specification; spreadsheets, GPS apps, and human habit are latitude-first. So the two conventions collide constantly. The tool's heuristic: if a “longitude” magnitude never exceeds 90 while a “latitude” does exceed 90, that's the signature of lat,lon data being read as lon,lat — because latitude can't exceed 90° but longitude routinely does. It names the problem instead of silently computing a nonsense area, and there's a whole details block on lon-first specs versus lat-first habits, because everyone gets bitten eventually.

The length and area math

Length is haversine great-circle distance summed over vertices (R = 6,371,008.8 m). Area is the spherical polygon formula with holes subtracted — the same Chamberlain & Duquette approach most GIS “geodesic area” functions use on a sphere [3]. Both land within about 0.3% of ellipsoidal values at mid-latitudes: fine for a QA gut-check, not for a record boundary, and the tool says exactly that rather than implying survey precision.

Single file, vanilla JS, input persisted in localStorage, copy buttons on all three output formats. It pairs naturally with the traverse tool (which exports here) and the coordinate converter.

The tool: GeoJSON / WKT / CSV Geometry Converter & Inspector.

References

  1. [1] RFC 7946 — The GeoJSON Format. https://datatracker.ietf.org/doc/html/rfc7946
  2. [2] OGC Simple Features — WKT specification. https://www.ogc.org/standards/sfa
  3. [3] Chamberlain & Duquette (JPL), Some Algorithms for Polygons on a Sphere — spherical area formula.