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

Mateusz Loskot mateusz at loskot.net
Fri Nov 30 04:53:10 PST 2012


Folks,

I've just reported this ticked and I'd appreciate if we could discuss it
and come up with a usable solution.

Mat

On 30 November 2012 12:51, PostGIS <trac at osgeo.org> wrote:
> #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
>  size.
>  If the block size was not divinding the input raster evenly, the loader
>  would
>  generate padding along the right and bottom edges of right-most and
>  bottom-most tiles, but the spatial extent of the whole tiles coverage
>  written
>  into raster_columns did not include that padding.
>  It was extent of real data, ragardless physical pixel dimensions were
>  increased
>  by the padding.
>
>  Currently, with the raster_columns being a view, padding affects spatial
>  extent.
>
>  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",
>      GEOGCS["NAD27",
>          DATUM["North_American_Datum_1927",
>              SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
>                  AUTHORITY["EPSG","7008"]],
>              AUTHORITY["EPSG","6267"]],
>          PRIMEM["Greenwich",0],
>          UNIT["degree",0.0174532925199433],
>          AUTHORITY["EPSG","4267"]],
>      PROJECTION["Transverse_Mercator"],
>      PARAMETER["latitude_of_origin",0],
>      PARAMETER["central_meridian",-117],
>      PARAMETER["scale_factor",0.9996],
>      PARAMETER["false_easting",500000],
>      PARAMETER["false_northing",0],
>      UNIT["metre",1,
>          AUTHORITY["EPSG","9001"]],
>      AUTHORITY["EPSG","26711"]]
>  Origin = (440720.000000000000000,3751320.000000000000000)
>  Pixel Size = (60.000000000000000,-60.000000000000000)
>  Metadata:
>    AREA_OR_POINT=Area
>  Image Structure Metadata:
>    INTERLEAVE=BAND
>  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;
>               st_extent
>  ------------------------------------
>   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
>  downwards:
>
>  {{{
>  test=# SELECT ST_Extent(rast::geometry) FROM utm300x300;
>               st_extent
>  ------------------------------------
>   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
>  Windows:
>
>  {{{
>  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
>  comments.
>
> --
> 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.



-- 
Mateusz Loskot, http://mateusz.loskot.net



More information about the postgis-devel mailing list