Skip to content

Transform all estimated extents to EPSG:3857 - #2498

Draft
Nakaner wants to merge 2 commits into
osm2pgsql-dev:masterfrom
Nakaner:gen-transform-extent
Draft

Transform all estimated extents to EPSG:3857#2498
Nakaner wants to merge 2 commits into
osm2pgsql-dev:masterfrom
Nakaner:gen-transform-extent

Conversation

@Nakaner

@Nakaner Nakaner commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

If the database table contains geometries in EPGS:4326, ST_EstimateExtent would return a wrong extent for tile-based processing.

My use case: I upgrade our OSM Carto fork for WMS at Geofabrik. I port our existing simplification/generalisation toolchain to osmpgsql-gen. All database tables (except those polygon layers which use the raster-union strategy) are in EPSG:4326.

When osm2pgsql-gen retrieves the extent from the database, it is projection-agnostic. But tiling isn't. Tiling happens in EPSG:3857.

I don't know if the patch to the raster extents works at all. Tests pass but they passed even with a syntax error in the SQL query for vector layer extents (i.e. coverage of this part of the code needs to be improved by someone at some point in time 😄).

If the database table contains geometries in EPGS:4326,
ST_EstimateExtent would return a wrong extent for tile-based processing.
@joto

joto commented Jul 29, 2026

Copy link
Copy Markdown
Collaborator

Haven't look at it in detail yet, but ST_SRID(way) is definitely wrong, because it hardcodes the geometry column. Also: What happens if table is empty?

@Nakaner

Nakaner commented Jul 31, 2026

Copy link
Copy Markdown
Contributor Author

Haven't look at it in detail yet, but ST_SRID(way) is definitely wrong, because it hardcodes the geometry column.

Oh, sorry, that way should not have made it into the pull request. I pushed a new commit.

What happens if table is empty?

If the table is empty, NULL are returned by both the old and the new query. However, if geometries have no SRID set, the ST_Transform throws an error: "ST_Transform: Input geometry has unknown (0) SRID". I pushed a new commit fixing this.

Old implementation (for empty tables, it does not matter if the geometry column has an SRID set or not):

CREATE TABLE test (osm_id BIGINT NOT NULL, geom geometry(Point, 3857));
ANALYZE test;
SELECT ST_XMin(e), ST_YMin(e), ST_XMax(e), ST_YMax(e) FROM ST_EstimatedExtent('public', 'test', 'geom') AS e; -- NULLs returned
SELECT ST_XMin(e), ST_YMin(e), ST_XMax(e), ST_YMax(e)
  FROM ST_Transform(
    ST_SetSRID(
      ST_EstimatedExtent('public', 'test', 'geom'), 
      (SELECT ST_SRID(geom) FROM public.test LIMIT 1)
    ),
  3857) e; -- NULLs returned

If the SQL query returns NULLs, an invalid extent will be returned (and logged as "Source table empty, nothing to do.").

By looking on the code a second time, I found that an unset SRID will cause an error. I fixed this in a new commit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants