Transform all estimated extents to EPSG:3857 - #2498
Conversation
If the database table contains geometries in EPGS:4326, ST_EstimateExtent would return a wrong extent for tile-based processing.
|
Haven't look at it in detail yet, but |
Oh, sorry, that
If the table is empty, 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 returnedIf the SQL query returns 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. |
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 😄).