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 :smile:). You can view, comment on, or merge this pull request online at: https://github.com/osm2pgsql-dev/osm2pgsql/pull/2498 -- Commit Summary -- * Transform all estimated extents to EPSG:3857 -- File Changes -- M src/gen/osm2pgsql-gen.cpp (15) -- Patch Links -- https://github.com/osm2pgsql-dev/osm2pgsql/pull/2498.patch https://github.com/osm2pgsql-dev/osm2pgsql/pull/2498.diff -- Reply to this email directly or view it on GitHub: https://github.com/osm2pgsql-dev/osm2pgsql/pull/2498 You are receiving this because you are subscribed to this thread. Message ID: <osm2pgsql-dev/osm2pgsql/pull/[email protected]>
_______________________________________________ Tile-serving mailing list [email protected] https://lists.openstreetmap.org/listinfo/tile-serving
