Portable WKT · longitude-first · no sign-up

Address in.
WKT point out.

pointkit geocodes a plain address and hands back a POINT(longitude latitude) WKT string — the portable geometry format that Postgres, SQL Server, Oracle Spatial, SpatiaLite, and most GIS software all read directly.

Also available: Postgres/PostGIS · MySQL POINT · GeoJSON
WKT
{{ heroResultText }}
No SRID attached — that's expected for plain WKT. Wrap it yourself where your tool needs one, e.g. in PostGIS: ST_GeomFromText('{{ heroResultText }}', 4326). (MySQL 8 reads that SRID latitude first, so use pointkit’s MySQL output there instead.)
{{ heroWarningText }}

The format that isn't tied to one database

Every serious spatial system reads WKT, which is exactly why it's worth having on hand even if you already use Postgres or MySQL day to day: it's what you paste into a one-off SQL Server or Oracle Spatial query, what QGIS and ArcGIS import without complaint, and what plenty of internal tools accept as a lowest-common-denominator geometry input.

The catch is the same one every spatial format shares: axis order. WKT is (longitude, latitude). Get a coordinate pair from somewhere that returns lat/long first — a lot of consumer mapping APIs do — and swap them by mistake, and the point silently lands somewhere else on Earth. pointkit geocodes the address directly, so the order is right from the start.

Worked example: one WKT point, four destinations

1600 Amphitheatre Parkway, Mountain View, CA is at latitude 37.4224, longitude -122.0842. As WKT that's POINT(-122.0842 37.4224): longitude, a space, latitude.

PostGIS

SELECT ST_GeomFromText('POINT(-122.0842 37.4224)', 4326);

BigQuery

SELECT ST_GEOGFROMTEXT('POINT(-122.0842 37.4224)');

SQL Server

WKT input is longitude first, but SQL Server's own geography::Point() takes latitude first. Don't mix the two up.

SELECT geography::STGeomFromText('POINT(-122.0842 37.4224)', 4326);
SELECT geography::Point(37.4224, -122.0842, 4326);  -- same point

MySQL 8

MySQL 8 reads WKT latitude first under SRID 4326. To pass it standard WKT, say so explicitly:

SELECT ST_GeomFromText('POINT(-122.0842 37.4224)', 4326, 'axis-order=long-lat');

Python (Shapely)

from shapely import wkt

p = wkt.loads("POINT (-122.0842 37.4224)")
p.x, p.y  # (-122.0842, 37.4224): x is longitude

Axis order by database

TargetOrderExample (37.4224, -122.0842)
MySQL 8.0+, SRID 4326lat, lngST_GeomFromText('POINT(37.4224 -122.0842)', 4326)
MariaDB, MySQL 5.7lng, latST_GeomFromText('POINT(-122.0842 37.4224)', 4326)
Postgres / PostGISlng, latST_GeomFromText('POINT(-122.0842 37.4224)', 4326)
WKTlng, latPOINT(-122.0842 37.4224)
GeoJSONlng, lat{"type":"Point","coordinates":[-122.0842,37.4224]}
Leaflet, Google Mapslat, lngL.marker([37.4224, -122.0842])

WKT FAQ

What is WKT?

Well-Known Text is a plain-text geometry format defined by the Open Geospatial Consortium. A point is written as POINT(longitude latitude). It's read and written by Postgres/PostGIS, SQL Server, Oracle Spatial, SpatiaLite, and most GIS desktop software.

Does WKT include the SRID / coordinate reference system?

No — plain WKT is just the geometry, with no spatial reference attached. Supply that separately, e.g. by wrapping it in ST_GeomFromText('POINT(...)', 4326). pointkit's Postgres output already does this wrapping for you; the WKT here is the bare geometry for anywhere else you need it.

Is WKT longitude-first or latitude-first?

Longitude first: POINT(longitude latitude). Every major spatial format follows this except MySQL/MariaDB's default SRID 4326, which reverses it.

Can I convert a whole file of addresses to WKT at once?

Yes — export the addresses as a CSV and use pointkit's batch converter, which appends a WKT column to the file.