[gdal-dev] Fwd: [PostGIS] #2122: [raster] Real extent feature lost after metadata as views
Mateusz Loskot
mateusz at loskot.net
Fri Nov 30 05:31:23 PST 2012
Hi,
I've reported ticket to PostGIS Raster about change in the concept of regular
blocking, that may be of interest here, especially the PostGIS Raster driver
developers and users. Details below.
If anyone has comments or ideas to this issue in PostGIS,
please post it either as follow-up to the thread on postgis-devel
or to the PostGIS trac at http://trac.osgeo.org/postgis/ticket/2122
Mat
---------- Forwarded message ----------
From: Mateusz Loskot <mateusz at loskot.net>
Date: 30 November 2012 12:53
Subject: Re: [PostGIS] #2122: [raster] Real extent feature lost after
metadata as views
To: trac at osgeo.org
Cc: PostGIS Development Discussion <postgis-devel at postgis.refractions.net>
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 gdal-dev
mailing list