[postgis-devel] [PostGIS] #2122: [raster] Real extent feature lost after metadata as views

PostGIS trac at osgeo.org
Fri Nov 30 04:51:04 PST 2012

#2122: [raster] Real extent feature lost after metadata as views
 Reporter:  mloskot                                 |       Owner:  dustymugs
     Type:  defect                                  |      Status:  new      
 Priority:  medium                                  |   Milestone:           
Component:  raster                                  |     Version:  trunk    
 Keywords:  regular blocking,raster,extent,padding  |  
 It seems, we've overlooked one feature while migrating from table to view
 for the raster_columns (#1216, #1319). It is quite an important feature.

 With the raster_columns as table, it was possible to set real spatial
 extent of raster data, regardless of physical size of raster blob.
 It means, it was possible to 'cut off' any possible padding
 framing the real raster data.

 With the raster_columns as view, spatial extent is calculated based on
 'worldfile' metadata and actual width and height of raster matrix.

 This is an undesired difference, generally, but seems to mostly affect
 uses of regular blocking.

 Previously, it was possible to specify raster2pgsql with arbitrary block
 If the block size was not divinding the input raster evenly, the loader
 generate padding along the right and bottom edges of right-most and
 bottom-most tiles, but the spatial extent of the whole tiles coverage
 into raster_columns did not include that padding.
 It was extent of real data, ragardless physical pixel dimensions were
 by the padding.

 Currently, with the raster_columns being a view, padding affects spatial

 For example:

  * Input raster: [http://download.osgeo.org/gdal/data/gtiff/ utm.tif] from
 GDAL test data:

 f:\data\Test\pgraster\blocking>gdalinfo utm.tif
 Driver: GTiff/GeoTIFF
 Files: utm.tif
 Size is 512, 512
 Coordinate System is:
 PROJCS["NAD27 / UTM zone 11N",
             SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
 Origin = (440720.000000000000000,3751320.000000000000000)
 Pixel Size = (60.000000000000000,-60.000000000000000)
 Image Structure Metadata:
 Corner Coordinates:
 Upper Left  (  440720.000, 3751320.000) (117d38'28.21"W, 33d54' 8.47"N)
 Lower Left  (  440720.000, 3720600.000) (117d38'20.79"W, 33d37'31.04"N)
 Upper Right (  471440.000, 3751320.000) (117d18'32.07"W, 33d54'13.08"N)
 Lower Right (  471440.000, 3720600.000) (117d18'28.50"W, 33d37'35.61"N)
 Center      (  456080.000, 3735960.000) (117d28'27.39"W, 33d45'52.46"N)
 Band 1 Block=512x16 Type=Byte, ColorInterp=Gray

  * Block 256x256

 raster2pgsql -C -r -t 256x256 public.utm256 utm.tif

 The loader cut the raster evenly, so no padding added, spatial extent the
 same as original:

 test=# SELECT ST_Extent(rast::geometry) FROM utm256;
  BOX(440720 3720600,471440 3751320)
 (1 row)

  * Block 300x300

 raster2pgsql -C -r -t 300x300 public.utm300 utm.tif

 The loader added padding, so spatial extent increased rightwards and

 test=# SELECT ST_Extent(rast::geometry) FROM utm300x300;
  BOX(440720 3715320,476720 3751320)
 (1 row)

 This is a significant change in behaviour, a regression which
 I'm reporting as a bug.

 Apparently, PostGIS Raster driver in GDAL 1.9.2 is affected.
 I tried to export the coverages from the two tables loaded above, on

 set CONN=PG:dbname=test user=mloskot mode=2
 FOR %%t IN (utm256 utm300) DO (
     gdal_translate -of GTIff "%CONN% table=%%t" %%t.tif
         gdalinfo %%t.tif

 First, similarly to the SQL results above, gdalinfo reports changed
 spatial extent for the utm300.tif file.
 Second, the padding strips are exported, whereas in normal situation
 they should be discarded.
 I'm going to attach both files, utm256.tif and utm300.tif:


 I'd like to bring the previous behaviour back.

 I'd like to propose change in the header of serialised format,
 and add 4 slots of 16 bytes:

 struct rt_raster_serialized_t {
     /*---[ 8 byte boundary ]---{ */
     uint32_t size; /* required by postgresql: 4 bytes */
     uint16_t version; /* format version (this is version 0): 2 bytes */
     uint16_t numBands; /* Number of bands: 2 bytes */

     /* }---[ 8 byte boundary ]---{ */
     double scaleX; /* pixel width: 8 bytes */

     /* }---[ 8 byte boundary ]---{ */
     double scaleY; /* pixel height: 8 bytes */

     /* }---[ 8 byte boundary ]---{ */
     double ipX; /* insertion point X: 8 bytes */

     /* }---[ 8 byte boundary ]---{ */
     double ipY; /* insertion point Y: 8 bytes */

     /* }---[ 8 byte boundary ]---{ */
     double skewX; /* skew about the X axis: 8 bytes */

     /* }---[ 8 byte boundary ]---{ */
     double skewY; /* skew about the Y axis: 8 bytes */

     /* }---[ 8 byte boundary ]--- */
     int32_t srid; /* Spatial reference id: 4 bytes */
     uint16_t width; /* pixel columns: 2 bytes */
     uint16_t height; /* pixel rows: 2 bytes */

         /* }---[ 8 byte boundary ]--- */
     uint16_t upperLeftX; /* first column of raster data, Zero if no
 padding leftwards */
     uint16_t upperLeftY; /* first row of raster data, Zero if no padding
 upwards */
     uint16_t lowerRightX; /* last column of raster data, width if no
 padding rightwards */
     uint16_t lowerRightY; /* last row of raster data, height if no padding
 downwards */

 I'm going to post this issue to postgis-devel too and request for

Ticket URL: <http://trac.osgeo.org/postgis/ticket/2122>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.

More information about the postgis-devel mailing list