PostGIS-ready · SRID 4326 · no sign-up

Address in.
Postgres geometry out.

pointkit geocodes a plain address and hands back a ready-to-run ST_GeomFromText literal — correct longitude/latitude axis order, SRID 4326. Works with any PostGIS geometry or geography column.

Also available: MySQL POINT · WKT · GeoJSON
Postgres · ST_GeomFromText
{{ heroResultText }}
INSERT INTO places (name, geom) VALUES ('example', {{ heroResultText }});
{{ heroWarningText }}

Why axis order breaks silently

WKT, and therefore ST_GeomFromText, expects coordinates as (longitude, latitude). Most geocoders and mapping APIs return (latitude, longitude). Swap them by mistake and Postgres accepts the geometry without complaint — the row just lands somewhere on the other side of the equator from where it should. There's no error to catch it, only a support ticket weeks later when someone notices a customer's pin is in the ocean.

pointkit geocodes the address and outputs the literal in the order Postgres expects, every time, so this class of bug never ships.

Worked example: an address into PostGIS

1600 Amphitheatre Parkway, Mountain View, CA is at latitude 37.4224, longitude -122.0842. PostGIS wants longitude first.

Create the table

CREATE EXTENSION IF NOT EXISTS postgis;

CREATE TABLE places (
  id   serial PRIMARY KEY,
  name text,
  geom geometry(Point, 4326)
);

Insert the point

INSERT INTO places (name, geom)
VALUES ('Googleplex', ST_GeomFromText('POINT(-122.0842 37.4224)', 4326));

Check the order

ST_X is longitude and ST_Y is latitude. If lng comes back as 37.4224, the point went in backwards.

SELECT name, ST_X(geom) AS lng, ST_Y(geom) AS lat FROM places;

Fix rows that went in swapped

A geometry column doesn't check that latitude is within ±90°, so swapped rows go in without an error. ST_FlipCoordinates swaps x and y back. This query finds every swapped row whose longitude is beyond ±90° (western North America, east Asia, Australia and New Zealand); check the rest by eye, because flipping a correct row breaks it.

UPDATE places
SET geom = ST_FlipCoordinates(geom)
WHERE ST_Y(geom) NOT BETWEEN -90 AND 90;

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])

Postgres & PostGIS FAQ

Does this require the PostGIS extension?

Yes. geometry, geography and ST_GeomFromText all come from PostGIS; plain Postgres has none of them. Enable it once with CREATE EXTENSION postgis; — it’s available on Supabase, Amazon RDS, Google Cloud SQL, Azure and most other hosts.

geometry or geography column — does it matter?

The literal is the same either way. Cast it as needed: ST_GeomFromText(...)::geography if the column is geography, or leave it as-is for a geometry column. geography is usually the better default for real-world addresses since it accounts for the Earth's curvature in distance calculations.

What SRID does pointkit use?

4326 (WGS 84), the standard reference system for GPS and web-mapping coordinates, and PostGIS's default. Axis order is longitude, then latitude, matching what ST_GeomFromText and WKT expect.

Can I convert a whole table of addresses at once?

Yes — export the addresses as a CSV and use pointkit's batch converter, which appends a geometry column to the file. For Postgres that column holds EWKT (SRID=4326;POINT(lng lat)), which a geometry or geography column accepts as a plain value, so you can load it back in with COPY or an ORM import.