GeoJSON CloudGeoJSON Cloud
Back to Blog
PostGIS 3.7 Hits Beta: Tiger Geocoder Moves Out, Curves Move In—What Web Mappers Should Test

PostGIS 3.7 Hits Beta: Tiger Geocoder Moves Out, Curves Move In—What Web Mappers Should Test

August 9, 2026

What shipped this week

The PostGIS project has published 3.7.0beta1, a same-cycle follow-on to the 3.7.0alpha1 notes that appeared earlier in July. The beta announcement frames the build as best paired with PostgreSQL 19 Beta2 and GEOS 3.15.0beta2, and it lists fixes and enhancements since alpha1.

According to the official notes, runtime requirements are PostgreSQL 14 through 19beta2, GEOS 3.10+, and Proj 6.1+. Full feature use wants GEOS 3.15+; full SFCGAL features want SFCGAL 2.3.0+. That stack is explicitly pre-stable: beta spatial software on beta database and geometry libraries. Treat this as a window for inventory, smoke tests, and upstream feedback—not as a production upgrade signal.

Two changes matter immediately for people who move data from PostGIS into browser maps:

  1. postgis_tiger_geocoder is leaving the core distribution.
  2. Curved-geometry ingest is broader (notably GML arcs and curved inputs to rasterization)—while GeoJSON and typical web clients still expect linearized coordinates.

If your pipeline is roughly “address or CAD/GML in Postgres → QA on a web map → share GeoJSON,” this beta is the right moment to write down dependencies and practice the export steps you will need when 3.7 stabilizes.

Tiger geocoder: what changed and who should care

PostGIS has stated that the 3.6 series is the last to ship postgis_tiger_geocoder inside the core distribution, that 3.7 will ship without it, and that the extension now lives as its own versioned project under the PostGIS/OSGeo umbrella. Versioning is planned around the year of the current Census TIGER dataset, not the PostGIS core version. Those points are summarized on the project’s news index alongside the 3.7 alpha/beta cycle.

Who is affected

You are in scope if any of the following are true:

  • Application SQL or migration scripts run CREATE EXTENSION postgis_tiger_geocoder (or depend on it transitively).
  • Dockerfiles, Ansible roles, or golden AMI/image builds install “full PostGIS” and assume tiger functions are present.
  • Newsroom, civic, or logistics workflows geocode U.S. addresses in Postgres, then export points or service areas as GeoJSON for Leaflet, MapLibre, or a browser editor.
  • Docs or onboarding still say “install PostGIS” as shorthand for “install PostGIS + tiger geocoder + TIGER download steps.”

You are less affected if you geocode outside Postgres (vendor APIs, batch tools, client-side services) and only store final geometries in PostGIS.

Verification checklist (no invented install paths)

Exact package names on Debian/Ubuntu/PGDG, and behavior on managed hosts (RDS, Supabase, and similar), should be confirmed per platform when you test—do not assume the old extension package still rides along with postgis. A practical inventory looks like this:

  1. Extension inventory — On a representative database, list installed extensions and note any postgis_tiger_geocoder (and related tiger helper objects).
  2. Reference search — Grep migrations, dbt macros, stored procedures, and runbooks for tiger function names and norm_addy / geocode call sites.
  3. Image and docs audit — Check base images and internal install guides for “PostGIS includes tiger” language that will be wrong under 3.7.
  4. Separate lifecycle plan — Because tiger versioning will follow Census TIGER years, plan extension upgrades on a data-release calendar, not only on the PostGIS minor-version calendar.
  5. Export habit — Whatever geocoder you keep, freeze a small GeoJSON golden set of geocoded points/polygons for regression after stack changes.

This article does not prescribe package manager commands or upgrade SQL; those need human verification against the new tiger repository and your distributor’s packages when you trial the beta.

Curved geometry: better database ingest, same GeoJSON rules

Beta1’s interchange-relevant enhancements called out in the official notes include:

  • #1986 — ST_GeomFromGML support for GML ArcString and curved polygon rings
  • #1168 — curved geometry inputs to ST_AsRaster
  • Additional NURBS WKT safeguards and topology id/tolerance fixes listed on the same page

That is good news if you receive engineering, utilities, or cadastral data as GML (or other curve-capable paths) and want fewer import dead-ends inside Postgres. It is not the same as “curves work in the browser now.”

RFC 7946 GeoJSON has no native circular arc or NURBS type. Mainstream web map stacks render LineStrings and Polygons as arrays of positions. So the durable pattern remains:

Ingest curves in the database → linearize with an explicit tolerance → export GeoJSON → QA vertex density on a map.

Example pattern (illustrative SQL)

Use your own sample GML and tolerances; this is a workflow sketch, not a benchmark claim:

-- After ST_GeomFromGML (or other curve-capable ingest) into a typed geometry column:
-- 1) Inspect type / curve presence in PostGIS
-- 2) Linearize before web export
SELECT ST_AsGeoJSON(
  ST_CurveToLine(geom, 0.5)  -- tolerance in CRS units; choose deliberately
) AS geojson
FROM cad_import
WHERE id = 42;

What to watch after linearization:

  • Vertex explosion on tight tolerances (large files, slow mobile maps).
  • Visual drift on loose tolerances (arcs that look faceted at city scale).
  • Attribute and CRS discipline — keep properties stable; confirm you are exporting WGS84 lon/lat when the client expects EPSG:4326 GeoJSON.

ST_AsRaster accepting curved inputs helps cartographic or analysis paths that stay inside the database. It does not replace the linearize step for vector web maps.

A practical test plan for web-mapping teams

Use a throwaway cluster or container that matches the project’s stated beta pairings (PostgreSQL 19 Beta2, GEOS 3.15.0beta2, PostGIS 3.7.0beta1). Keep production data away until a stable release and your own regression suite pass.

1. Baseline the extension set

Document what CREATE EXTENSION / packaging currently gives you for postgis, optional raster/topology/sfcgal pieces, and tiger. Re-read the beta1 notes for the dependency floor (PostgreSQL 14+, GEOS 3.10+, Proj 6.1+) versus the “full features” line (GEOS 3.15+, SFCGAL 2.3.0+).

2. Smoke-test a curved GML fragment

Import a minimal GML snippet that includes an ArcString or curved ring via ST_GeomFromGML. Confirm the stored type behaves as you expect, then run ST_CurveToLine at two or three tolerances. Export each result with ST_AsGeoJSON (or your usual ogr2ogr path).

3. Open the exports where you actually QA maps

Load the GeoJSON in the browser client you trust for editing and visual checks. Compare:

  • Does the arc still read as smooth enough at the zoom levels you ship?
  • Did properties survive round-trip?
  • Is the file size acceptable for your audience (newsroom embed, field tablet, internal dashboard)?

Browser editors and converters—including GeoJSON Cloud—are reasonable places to inspect vertex density, fix attributes, and re-export after database-side linearization. They are complements to PostGIS, not hosts for PostGIS 3.7, tiger geocoding, or native circular-arc GeoJSON.

4. Geocoder path (if you use tiger today)

On a separate checkout, follow upstream tiger-project docs (not assumptions from 3.5/3.6 blog posts) for install and TIGER year alignment. Geocode a fixed address list, export GeoJSON, and diff geometry and attributes against your last known-good set.

5. File feedback upstream

Beta exists to surface packaging surprises, topology edge cases, and GML corner cases. Reproducible SQL and small sample files help more than “it broke on our laptop” reports.

What this does not mean

  • Not production-ready by announcement alone. PostGIS beta + PostgreSQL beta + GEOS beta is a testing stack.
  • Not native curve GeoJSON. Linearization remains your responsibility for standard web maps.
  • Not a GeoJSON Cloud feature release. GeoJSON Cloud remains a browser editor/converter for GeoJSON and related formats; it does not run PostGIS or replace database geocoding.
  • Not a promise about managed-service timelines. When cloud vendors and OS packages ship 3.7 is a separate question from the project’s beta tag.

Bottom line

PostGIS 3.7.0beta1 is a timely cue to separate “core PostGIS” from “tiger geocoder” in your mental model and automation, and to practice curve ingest + ST_CurveToLine + GeoJSON export while the release is still in beta. Teams that treat browser maps as the last mile should invest in golden GeoJSON fixtures and tolerance choices now, then upgrade production only after stable releases and platform packages catch up.

Sources and further reading