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

[Pierre Racine]

My 10 cents to this wonderful discussion.

1) I'm amazed that after years of discussion and an agreement passed BEFORE the release of PostGIS 2.0 this problem comes to live again... Must be a lack of testing somewhere.

2) On my side I always took for granted that the extent column in raster_columns (created by raster2pgsql.py) was reflecting the extent INCLUDING the padding. If not I would have considered this a bug. It was never specified anywhere that this extent should be the one of the not padded raster. This is why I don't see where there is a backward compatibility problem. I see it more like we are doing the right way now. One can always achieve backward compatibility if it was relying on this bad extent by reviving the old raster table so his application can write whatever it wants in it.

3) If a compromise is to be reached I would go for two extents proposition. The actual extent constraint is the TRUE extent of what is in the DB, however it was produced. The new one would reflect the extent of the original source raster that was loaded (and might not exist anymore). I don't see how we will ever be able to recompute (or reapply) this new "with_value" extent. (On the contrary with the actual extent which one can easily compute with ST_Union(ST_Extent(rast::geometry)))

I think choosing to load a raster with the -t option and padding (there is a ticket #826 for adding the option of not padding), CHANGE and DETERMINE the nature of the stored raster and we do not have to keep information about the old raster. This is a user (or application) decision. (I agree that right now, because we have no option other than padding, we too often change this nature. This is why I would consider this ticker a higher priority.)

If what is stored is a regularly tiled raster. Bravo! If not, too bad. An application reading a table of raster has to be able to deal with the fact the coverage might not be regularly tiled (and be able to compute its own necessary memory space based on what is in the db). This is unavoidable and this is what the GDAL driver do now.

As I said in a previous mail this week: it is a misconception to consider a raster table a raster (always regularly tiled). A raster table is more like a folder containing a bunch of raster (a raster coverage) with all the unforeseeable the arrangement of these many rasters may have (unalignement, overlaps, uncompletion).

So on my side:

-1 for adding a new constraint since you can revert to the raster column table to support old application developed BEFORE the first official release (we have to remember this).

Pierre