Transform all estimated extents to EPSG:3857

[Nakaner]

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 😄).

[joto]

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]

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

CREATETABLEtest (osm_id BIGINTNOT 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 returnedSELECT 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) FROMpublic.testLIMIT1)
),
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.