Opened 10 years ago

Last modified 16 months ago

#2914 new defect

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

Reported by: strk Owned by: Bborie Park
Priority: medium Milestone: PostGIS Fund Me
Component: raster Version: 2.1.x
Keywords: Cc: EvenR


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)

Change History (13)

comment:1 by strk, 10 years ago

Milestone: PostGIS 2.1.4
Priority: mediumblocker

comment:2 by strk, 10 years ago

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.

comment:3 by strk, 10 years ago

Cc: EvenR added

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.

comment:4 by robe, 10 years ago

Component: postgisraster
Owner: changed from pramsey to Bborie Park

comment:5 by strk, 10 years ago

The workarounds for identity matrix handling could be removed by fixing GDAL upstream, see

comment:6 by strk, 10 years ago

I confirm that this fix to GDAL fixes the PostGIS run too:

comment:7 by strk, 10 years ago

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

comment:8 by robe, 10 years ago

Milestone: PostGIS 2.1.4PostGIS 2.2.0

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

comment:9 by Bborie Park, 9 years ago

Milestone: PostGIS 2.2.0PostGIS Future

comment:10 by robe, 7 years ago

Milestone: PostGIS FuturePostGIS Fund Me

Milestone renamed

comment:11 by Algunenano, 5 years ago

Priority: blockermedium

I'm sure this isn't a blocker.

comment:12 by arthurbazin, 16 months ago

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.

comment:13 by robe, 16 months ago


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)
Note: See TracTickets for help on using tickets.