Skip to content

Transform all estimated extents to EPSG:3857 - #2498

Draft
Nakaner wants to merge 1 commit into
osm2pgsql-dev:masterfrom
Nakaner:gen-transform-extent
Draft

Transform all estimated extents to EPSG:3857#2498
Nakaner wants to merge 1 commit 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?

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