[raster] ST_Rescale: Could not create GDAL transformation object for output dataset creation

[strk]

Obtained with this query:

with data as ( 
   SELECT ST_AddBand(
          ST_MakeEmptyRaster(10, 10, 0, 0, 1, -1, 0, 0, 4326),
          1, '8BUI', 0, 0
        ) r 
 ), 
 meta as ( 
   SELECT st_metadata(st_rescale(r,2.0,-2.0)) m from data 
 ) select (m).* from meta;

Note that using a SRID=0 fixes the issue (see #2911)

[strk]

Figured out, the problem is that the ST_Rescale call ends up calling _st_gdalwarp passing NULL srs for both source and destination when they are the same. The core then does not enter the special case of default georeference, but doesn't have an SRS to initialize GDAL with either.

[strk]

Worse than that, by passing not-null SRS even when source and destination have the same one only serves the purpose of failing later, as the "default geotransform" is not appreciated by GDAL (or so it looks). So we're back to the point that default geotransform need special handling, no matter reprojection being involved.

[strk]

The workarounds for identity matrix handling could be removed by fixing GDAL upstream, see ​http://lists.osgeo.org/pipermail/gdal-dev/2014-September/039980.html

[strk]

I confirm that this fix to GDAL fixes the PostGIS run too: ​https://github.com/OSGeo/gdal/pull/40

[robe]

So is this still a PostGIS issue or has it been fixed in GDAL? In which case we should mark this as PostGIS GDAL?

Anyrate pushing to 2.2. Push back to whereever it goes

[robe]

Milestone renamed

[Algunenano]

I'm sure this isn't a blocker.

[arthurbazin]

Hi, is there any workaround ? Because none of the ST_Rescale, ST_Resize and ST_Resample functions work on my server…

POSTGIS="3.2.1 3.2.1" [EXTENSION] PGSQL="130" GEOS="3.10.2-CAPI-1.16.0" PROJ="7.2.1" GDAL="GDAL 3.4.2, released 2022/03/08" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" RASTER

Constraints are good but nothing can be done…

If you have a workaround, it would be a pleasure to have the information.

Note that I have a standalone version of GDAL on the same machine. If you know some troubles that can be linked, I can try to change some parameters.

Thank you really much.

[robe]

@arthurbazin,

What does your query look like. I ran the above query, and it doesn't fail on my system, so I think this is a non-issue. Are you still getting an error?

I get:

upperleftx | upperlefty | width | height | scalex | scaley | skewx | skewy | srid | numbands
------------+------------+-------+--------+--------+--------+-------+-------+------+----------
          0 |          0 |     5 |      5 |      2 |     -2 |     0 |     0 | 4326 |        1
(1 row)

this is running with:

POSTGIS="3.3.2 3.3.2" [EXTENSION] PGSQL="150" GEOS="3.11.1-CAPI-1.17.1" SFCGAL="SFCGAL 1.4.1, CGAL 5.3, BOOST 1.78.0" PROJ="7.2.1" GDAL="GDAL 3.4.3, released 2022/04/22" LIBXML="2.9.9" LIBJSON="0.12" LIB
PROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" RASTER PostgreSQL 15.1, compiled by Visual C++ build 1914, 64-bit
(1 row)